Summary

  • 6rd builds a customer's IPv6 prefix from a provider prefix and selected bits of the customer's IPv4 address. That makes the old address plan part of the new service's capacity and continuity contract.
  • A provider-controlled domain removes dependence on anonymous public relays, but it is not simply a collection of customers behind one gateway. Customers inside the same domain can communicate through direct tunnels.
  • Stateless forwarding still needs consistent configuration, address validation and a migration decision. Keeping the derived prefixes when moving to native IPv6 can avoid renumbering, but requires those prefixes to be carried by native routing.

An address change that reaches another protocol

The consequential change in a 6rd network need not begin with its IPv6 service. It can begin with an IPv4 address being reassigned. The IPv6 prefix used by the customer is calculated from that address. Change the input and the calculation gives a different result. An operation that looks routine in the access network can therefore reach into customer LANs using another protocol.

That is not an accidental flaw concealed by the name “IPv6 Rapid Deployment”. It is part of the bargain described in RFC 5969. The operator reuses an IPv4 infrastructure to carry IPv6 packets and derives the necessary addressing information algorithmically. It does not have to maintain a separate per-flow translation table at a border relay. In exchange, the structure of the IPv4 network remains an input to the IPv6 product.

This distinction matters when a launch is presented as independence from the old network. 6rd can make IPv6 available before the access infrastructure becomes natively IPv6-capable. Availability, however, is not the same as independence. The old network supplies transport, part of the address calculation and, where addresses are leased, a limit on how long the result can safely be used.

The claim here is architectural, not a report that a particular operator has caused an outage. The specification establishes the dependency. It does not establish how often present-day operators change addresses, how their equipment implements every option or how much revenue has been affected.

The bits have already allocated some of the product

A 6rd delegated prefix consists of the provider's 6rd prefix followed by the relevant suffix of the CE router's IPv4 address. CE means customer-edge router. The IPv4MaskLen parameter identifies common high-order IPv4 bits that do not need to be repeated in every customer's IPv6 prefix.

The arithmetic is compact: the delegated-prefix length is 6rdPrefixLen plus 32 minus IPv4MaskLen. In the specification's example, a provider using IPv4 addresses from 10/8 can omit the common first eight bits. A /32 IPv6 6rd prefix plus the remaining 24 IPv4 bits produces a /56 delegated prefix. The remaining IPv6 space is then available for addressing within the customer site.

For a commercial decision-maker, the point is not to memorise the formula. It is that an access-network addressing choice affects what the customer can subdivide. Using more bits to distinguish endpoints leaves fewer bits for subnetting. A later attempt to reorganise the underlying address space can be a product change even if the IPv6 service's name and advertised headline remain untouched.

There are two different limits to keep apart. The DHCP option's encoding requires the relevant prefix lengths to fit within 128 bits. The addressing discussion recommends a delegated prefix of /64 or shorter to permit stateless address autoconfiguration. Passing the first bound does not establish a sensible site-addressing offer. Syntactic validity is not a substitute for deciding how many customer networks the service should support.

Private IPv4 addressing does not dissolve that responsibility. Overlapping IPv4 spaces can be used in separate 6rd domains, but the domains need distinct 6rd prefixes. An address meaningful in one domain is not automatically an unambiguous identity in another. Nor is this mechanism a licence to treat one shared IPv4 address and several port ranges as equivalent to several independently derived 6rd site prefixes.

A fast deployment was a specific organisational achievement

The historical attraction is visible in RFC 5569, an Informational account of the early Free/Iliad deployment. It reports five weeks between the decision of 7 November 2007 and the operational deployment on 11 December. More than 1.5 million customers were eligible to use IPv6 if they activated the service. Eligibility is not a measurement of simultaneous users, take-up or application performance.

The account describes circumstances that made speed possible: control over customer equipment software, relays and an existing access network. It also records an address-plan evolution, from an initial /32 arrangement with /64 site prefixes to a later /26 allocation and /60 site prefixes allowing 16 LANs per customer. That is a reported historical choice, not a formula saying that /26 plus 32 bits equals /60.

The RFC 5569 errata are useful here. Verified editorial erratum 2023 corrects a passage so that the later allocation is described as something that happened, rather than an anticipated improvement. The other verified entries are editorial corrections, not new performance evidence. They do not turn the deployment account into a present-day promise of address availability or allocation entitlement.

The lesson is narrower, and stronger, than “transition tunnels are fast”. This launch combined an algorithm with control over the equipment and configuration needed to use it. Copying the algorithm does not demonstrate that another organisation has the same authority over its installed base, the same addressing room or an equally inexpensive path out.

A DHCP timer becomes an IPv6 boundary

RFC 5969 explicitly connects a customer's derived prefix lifetime to the IPv4 address lifetime. Where an IPv4 lease time is available, lifetimes advertised to LAN hosts or delegated through DHCPv6 must not exceed it. Where the IPv4 lifetime is unknown, the document recommends the defaults in RFC 4861. Unknown is not permission to advertise an indefinitely dependable prefix.

This is a protocol lease, not a commercial lease of IPv4 assets. Confusing the two would hide the immediate mechanism. An address allocation can remain part of an operator's inventory while the particular customer assignment changes. It is the assignment used in the derivation that matters to this customer's IPv6 continuity.

Longer-lived IPv4 assignments are consequently recommended. That does not prove that every customer must receive a permanently fixed address. It says that shortening the assignment's life creates consequences elsewhere which an IPv4-only accounting view can miss. A design can save relay state while transferring coordination work to address management, customer equipment and support.

This is also where “IPv6 migration” becomes an inadequate departmental label. The people changing IPv4 leases may not own the customer IPv6 service. A change can be locally correct for address utilisation and still impose a larger change on downstream networks. There need be no malicious decision and no violation of the address formula for that coordination failure to occur.

The domain is wider than the relay

6rd replaces 6to4's fixed global prefix with a provider's own IPv6 prefix and a defined provider domain. That is a meaningful shift in control. It is not evidence that every packet traverses a single, inspectable border device.

Two CEs within the same domain can send IPv6 traffic directly to one another through IPv4 encapsulation. A border relay is needed for traffic crossing between the 6rd domain and an external IPv6 network. The distinction changes both troubleshooting and the scope of acceptable incoming tunnel traffic.

A verified correction makes this unusually clear. RFC 5969 erratum 3049 corrects the security text: a CE must be able to receive not only from the domain's known border relays but also from other CEs in that domain. A rule based on the uncorrected relay-only wording can reject a legitimate path. A drawing with all customers behind a central box can therefore be misleading even if that box exists.

The same errata page contains rejected technical erratum 3869. Its proposed change must not be followed. The validation compares the IPv4 address embedded in an inner IPv6 source with the outer IPv4 source address. It does not compare an entire IPv6 address as though it were an IPv4 address. A mismatch is dropped and counted as a potential spoofing attempt; that counter is a signal to investigate, not proof of an attacker's identity.

All participants also need coherent shared configuration: the prefix, its length, the IPv4 mask length and the border-relay addressing. DHCP option 212 provides a defined way to distribute parameters for a domain. A valid received option normally triggers automatic configuration, but the CE must provide a way to disable that behaviour and ignore the option. A “stateless” design has not removed configuration authority. It has made agreement on a small set of shared inputs especially important.

A reachable relay is not the entire service

Anycast can give several border relays one IPv4 address without requiring per-flow state. That does not make every observation about the address an observation about the whole relay estate.

RFC 5969 warns that routine reachability checks handled by a relay's control plane can become expensive when many CEs send them. If CE-to-BR reachability detection is needed, the prescribed approach uses the forwarding plane without special control-plane processing at the BR. The described loopback arrangement establishes a particular forwarding round trip. It does not prove that every external IPv6 destination is reachable or that all relay instances behave identically.

Packet size introduces another distinction. An ICMP error sent to an anycast IPv4 source may reach a different relay from the one that sent the original packet. Dynamic path-MTU learning can then be unreliable. Anycast border relays must set the Don't Fragment bit when encapsulating; shared source addresses create a separate risk of fragment reassembly mixing traffic from different relays.

The document gives 1480 bytes as a tunnel-MTU example where a well-managed IPv4 path supports 1500 bytes, and recommends 1280 when the relevant MTU is unknown. These are design conditions and guidance, not measurements from a current deployment. A small successful test cannot, by itself, close the question of larger-packet delivery.

The address formula does not certify its destination

RFC 6324, an Informational security analysis published in 2011, examines loops involving automatic IPv6-over-IPv4 tunnels. The important general distinction is between an address that can be calculated and an authorised tunnel endpoint that actually exists. Inconsistent routing assumptions can connect those two ideas incorrectly.

For 6rd, knowledge of provider-specific prefixes is needed; there is no single fixed prefix that identifies all such traffic globally. Private IPv4 space adds scope questions. Checks must fit the actual domains and neighbouring mechanisms. The report discusses operational avoidance and, where appropriate, coherent neighbour information or limited endpoint sets. An ISATAP-specific on-link rule in that report is not automatically a 6rd remedy.

These are conditional failure mechanisms, not a finding that all 6rd installations are looping or being exploited. The IPv6 Hop Limit remains finite. This article has not injected traffic or tested an operator. The RFC 6324 errata query returned no matching entries when checked; absence of errata is not a contemporary security assessment.

The operator's perimeter still matters. RFC 5969 discusses limiting unwanted reachability of border relays and handling other known relays inside the IPv4 domain. Calling the domain “provider-controlled” cannot replace evidence that those boundaries are enforced. Equally, a protocol paper cannot tell a reader whether a named operator has implemented them well.

Exiting the shortcut requires an owner

Native IPv6 does not automatically force every 6rd customer to renumber. RFC 5969 describes both a new-prefix approach and a route-based way to retain the derived delegated prefixes. The second option can preserve customer numbering by injecting the retained prefixes into native routing. It is possible, not free of routing work.

That is the final expression of the original bargain. Address derivation made entry inexpensive by leaning on an existing plan. Keeping those identities on exit can require the network to carry them differently. Reclaiming the old 6rd block also depends on what happens to remaining users, rather than on the completion date of an unrelated hardware upgrade.

Lu Heng's Note 32 on the agency problem offers a useful lens: who controls a decision, and who bears its consequences? Applied here, it asks whether the owner of the IPv4 plan also sees the IPv6 disruption and exit costs. It is not evidence that Lu Heng assessed 6rd or that any particular operator has improper motives.

His Note 36 on BTW's purpose supports keeping that inquiry structural and evidence-bound. There is no need to condemn the shortcut. The question is whether its inherited obligations remain visible after the launch has been counted as a success.

The old address plan survived because it was doing useful work. A credible IPv6 service must account for all of that work, including the part its customers discover only when the plan changes.