Requirements for IP address and port APIs

Development Networking
10

The requirements discussion so far is strong on host-facing needs (string parse, scope, classification predicates, client stacks). I want to add one framing requirement: that scope is only part of the job.

The thread’s property and “subnet/CIDR” discussion is mostly host and interface thinking. Prefix and address values show up far wider, and this is where a single CIDR-style wrapper around an address usually falls short. Concise inventory:

Host / link

  • Interface address assignment
  • Link-local + zone/scope
  • On-link subnet / point-to-point / host route
  • Loopback and router-id style addresses

Routing / control plane

  • Connected, static, IGP, and BGP destinations
  • Aggregates, defaults, more-specifics
  • RIB/FIB keys and next-hop addresses
  • FlowSpec-style prefix match components

Policy / filtering

  • Prefix-lists (exact / length-bounded / more-specific)
  • Route policy match/set
  • ACL / security-group CIDR operands
  • Source validation (e.g. expected source prefixes)

Registries / authorization

  • RIR allocations and assignments
  • IRR route / route6 objects
  • RPKI ROAs (and related resource bindings)
  • Working example: asroutes — IRR lookup by origin AS, results as canonical networks

Planning / isolation / ops

  • IPAM pools and delegations
  • VRF / tenant / VPC route entries
  • VPN NLRI (prefix plus routing-instance context)
  • Telemetry, collectors, and logging keys

That is why the focus should stay on the object model, and why Swift on Server (and multiplatform currency generally) must be in scope—not only app and interface APIs.

What that implies for standard types

  1. IPAddress and Port are necessary but not sufficient if every routing, policy, IRR, and IPAM library must invent incompatible network types on top.

  2. A canonical network / prefix type is first-class currency, not an afterthought wrapper around an address. Control-plane data (routes, IRR objects, many filters) is prefix-shaped, not “interface with a mask.”

  3. Classification helpers (isLoopback, isBroadcast, isPrivate, …) are useful on address-shaped values (host identities—including interface addresses and host match keys). They are the wrong center of design for network/route-shaped values—e.g. a route or prefix-list entry is not a broadcast-domain object, so isBroadcast on a hybrid “CIDR” type is a meaning collision.

  4. Parse and equality must respect form

    • bare a.b.c.d → address with implied host-length context (/32 / /128)
    • 192.0.2.77/24 → address + prefix context (host bits identity-bearing)
    • 192.0.2.0/24 → canonical network
    • host+prefix → network is an explicit lossy projection; not silent ==

  5. Performance, Span, and platform coverage matter—they do not replace a clear model of what the value is.

Concrete server-side implementation: asroutes is a small multiplatform CLI/library that queries an IRRd service for route/route6 objects by origin AS and returns canonical network values—not interface assignments, and not a hybrid “print as host, equal as network” blob. That is normal Swift on Server control-plane work. If the standard model only optimizes host predicates and a fuzzy subnet helper, tools like this must invent a second foundation on day one (or abuse address-shaped types as routes).

I’m not asking v1 to ship every algorithm above. I am asking that requirements treat address and network as distinct, multiplatform currency for apps and control plane, with interface classification as one consumer among many—not the only one.

2 Likes