Requirements for IP address and port APIs

Development Networking
18

Thanks @MahdiBM for the updates and for walking through the equality change.

One clarification up front, so nothing is misread:

My posts on this thread (and in the Networking Workgroup) are about workgroup requirements and deliverables—not personal concerns about swift-endpoint as a product.
I’m glad when any prior-art package experiments with equality, printing, or ports; that helps the group see tradeoffs. I am not asking anyone to treat “address @camunro’s package issues” as the agenda. The agenda is shared currency types and constraints the NWG can stand behind.

On CIDR / forms specifically: improving hybrid-wrapper Equatable so host bits participate in identity is a useful step toward the parse/equality requirements I listed earlier (address-with-context vs canonical network, lossy projection). That does not by itself close the broader requirements around distinct forms, canonical network currency, and prefix length as currency—those remain workgroup design questions, not a single-package changelog.

Storage (InlineArray vs integers)

I’ve written up a more careful walkthrough on the #networking Slack (thought experiment from a classless math library angle: bits + explicit length, hot-path mask/containment, adapters for octets). Summary for the Forums record:

  • Classless work is bit strings + prefix length, not “an open bag of octets” as the primary model.
  • Fixed-width unsigned integers (UInt32 / UInt128) make mask/containment natural; the payload is already inline (part of the value).
  • A fixed byte array (or InlineArray) still needs a layout definition and usually reintroduces integers for every prefix operation—or reimplements shifts across bytes.
  • Network byte order belongs at I/O / adapter boundaries; forcing NBO interpretation on every in-process containment check is the wrong default for large control-plane sets.
  • So: InlineArray (or raw octets) as an adapter / projection API is reasonable; as the primary model of address currency without a math story, it is feature-led rather than domain-led.

Hiding the storage type behind the API is fine as an implementation strategy. Hiding it does not remove the need to choose a domain model for equality, masking, and generic algorithms. “Use UInt_ as big-endian byte storage” still needs a clear story for host arithmetic vs wire octets—that’s the same endian discussion, not a free pass.

I’m not asking the Forums to re-litigate every Slack message. I am asking that storage not be treated as settled solely by one package’s experiment list, and that NWG notes capture the math-vs-host/context split.

If anyone wants to dig into the storage write-up, the detailed walkthrough is on the Networking Slack; I welcome more comments and questions there.

DomainName / DNS

Domain names are a separate system (resolution, caching, encoding, operational policy). They are valuable software—and out of scope for the IP address / port currency deliverable the workgroup has been scoping (progressive disclosure: address and port first; richer topology later). Folding DomainName into the same early surface confuses two problem spaces.

What I’d like the workgroup to keep on the board

  1. Forms (at least: address / address+context / canonical network) and explicit lossy projections.
  2. PrefixLength (or equivalent) as currency, not only an Int tag.
  3. Progressive disclosure without erasing control-plane uses of prefix math.
  4. Storage/representation as a follow-on design choice informed by (1)–(3), not the other way around.

Happy to keep iterating on those as requirements, regardless of which package anyone is dogfooding this week.

1 Like