Summary

  • RFC 7157 separates IPv6 multihoming into three choices that IPv4 NAPT often centralised: source address, next hop and DNS recursive context.
  • A useful operating receipt records the three decisions for one connection attempt; none of the component records, or even one successful request, proves the whole policy surface correct.

The packet looked ordinary until the operator asked which network it belonged to. The destination had come from a resolver learned on the corporate VPN. The source address belonged to the home broadband prefix. The default router led towards a mobile backup. Every component was individually valid. Their combination was not.

That is the revealing frame in RFC 7157, IPv6 Multihoming without Network Address Translation. Published in March 2014 as an Informational RFC reflecting IETF consensus, it lists O. Troan as editor alongside David Miles, Satoru Matsushima, Takashi Okimoto and Dan Wing. The credit is precise: Trøan helped edit a collective analysis. It does not make him the inventor of multihoming, the operator of a cited network or the owner of later standards.

The document starts from a mundane feature of IPv4 NAPT. The translating border box does more than conserve addresses. It commonly performs source-address selection, next-hop resolution and, optionally, DNS resolution. An inside host sees one private address; the box hides the choice of provider-facing address and path, and may also mediate the name service. The three functions feel like one because one device contains them.

IPv6 changes the visibility of that arrangement. A small site or host connected to two providers can receive a global prefix from each. A laptop can keep Wi-Fi and mobile access active, or retain a public connection while a VPN supplies a separate namespace. End-to-end addressing no longer requires every flow to cross an invisible translator. But a larger address space does not decide which source, door and map belong together.

RFC 7157 names the resulting multi-prefix requirement. Before the first packet, the host needs the appropriate source address, the correct next hop and the correct recursive DNS server for the intended destination. Providers often apply ingress filtering. If a packet bearing provider A’s source prefix exits through provider B, the packet may be discarded even though both the source and router are valid in isolation.

The first decision is therefore not “does this interface have an address?” It is “which candidate source fits this destination and provisioning context?” RFC 6724 supplies default source- and destination-address selection algorithms plus an administrative policy table. RFC 7157 observes that the defaults may not deterministically choose the source appropriate to a particular provider. RFC 7078 defines a DHCPv6 option for distributing address-selection policy. That adds a configuration channel, not a certificate of use.

A DHCP reply can show which policy bytes arrived; it cannot show that the host accepted them, that the relevant table remained current or that this packet followed them.

The second decision is the door. Router Advertisements can leave a host with multiple valid default routers. Choosing one at random is not harmless when upstreams enforce source-prefix boundaries or expose different closed services. RFC 7157 describes the need for routing information or policy that associates traffic with an appropriate next hop. RFC 8028 later makes one ordering rule explicit for multi-prefix hosts: source-address selection occurs before first-hop selection, and the host should present the packet to a router that advertised the selected source prefix.

RFC 8028 is by Fred Baker and Brian Carpenter; its acknowledgement of important text from Ole Troan is contribution evidence, not authorship transfer.

The third decision is the map. A host may learn one recursive resolver from each network. A corporate name can exist only inside the VPN namespace; a service provider may return an address meaningful only on its own access network. Sending every question to whichever resolver replies first can yield an answer that is syntactically sound but operationally misplaced. RFC 7157 discusses policy tied to domain space and cites RFC 6731’s DHCPv6 mechanism for DNS selection. The resolver answer must remain attached to the context that produced it.

These three selections have an order, but not a single owner. An application expresses a destination name and intent. Resolver policy selects a name-service context and returns candidates. Host policy selects a source. Routing logic selects a first hop. A gateway and upstream filters make further acceptance decisions. The application finally sees a response or a timeout. Collapsing all of this into “IPv6 worked” removes the very evidence needed to repair the next failure.

The same caution applies to the alternatives. RFC 7157 says NAT and NPTv6 should be avoided where possible to preserve end-to-end transparency, but its conclusion also says NPTv6 may be required as an intermediate solution. That is not a contradiction. It is an honest boundary between an architectural aim and an incomplete deployment path. RFC 6296 describes stateless prefix translation; neither its existence nor RFC 7157’s preference supplies a universal answer for every site.

Later work gave a name to the bundle that must not be mixed accidentally. RFC 7556 defines a Provisioning Domain as a consistent set of network configuration: source prefixes, resolvers, DNS suffixes, default gateways and related information. RFC 8801 later lets Router Advertisements carry an FQDN-based PvD identifier and makes optional JSON information available to systems and applications. These mechanisms help preserve association. They do not turn an identifier into proof that the network is reachable, trustworthy or suitable for a particular transaction.

The operational object that matters is not a green network icon. It is a connection-attempt receipt. For one attempt, retain the destination name, resolver and provisioning domain; the answer set and TTL; the chosen destination and source; the source-policy version; candidate and selected routers; advertised prefixes and lifetimes; local route and neighbour state; filter decisions; retry changes; and, where available, an upstream or remote observation. Use one attempt identifier and monotonic timestamps so that the joins survive wall-clock drift.

Each field answers one question. An assigned address proves configuration state, not selection. A selected source proves a local decision, not upstream acceptance. A Router Advertisement proves received information, not that the advertised router carried the packet. A DNS answer proves one resolver’s response in one context, not delivery. A server response proves one path succeeded at one moment, not that every fallback, destination or namespace is correct.

That distinction is the durable value of Trøan’s RFC 7157 role. The document does not celebrate complexity for its own sake. It shows what the old box had bundled, then asks the open architecture to expose enough policy for the parts to coordinate. Transparency is not the absence of control. It is control whose inputs, decisions and limits can be inspected separately.

Sources