Summary

  • RFC 3964 showed that 6to4 could correctly decapsulate a packet while deleting the outer IPv4 address that best located its tunnel entry; a matching embedded prefix narrowed spoofing but did not authenticate a relay, operator or actor.
  • The practical control was to retain an outer–inner packet receipt, the concrete relay instance and each admission decision before decapsulation, then keep forwarding, delivery and attribution as separate results.

At the beginning of this story, a packet has four addresses. At the end, ordinary observers see two.

The example in RFC 3964 is almost austere. One 6to4 site sends an IPv6 packet whose source begins 2002:0800:0001; its IPv4 carrier leaves 8.0.0.1 for 8.0.0.2. The receiver removes the IPv4 header and forwards the original IPv6 packet. The transformation is correct. It is also irreversible unless somebody records the association first. Downstream, the outer source that located the last tunnel entrance is gone.

This was not an accidental side effect around the edges of 6to4. It followed from the design. RFC 3056 let a site with a public IPv4 address construct 2002:V4ADDR::/48. When two 6to4 sites communicated directly, the embedded V4ADDR supplied the IPv4 tunnel destination. When a 6to4 site talked to native IPv6, a relay stood between the two worlds. IPv4 routing delivered the outer packet; IPv6 routing carried the inner one after the envelope had been removed.

That gave 6to4 an elegant deployment property. No universal registry had to allocate each temporary site prefix. The address itself supplied a route hint. But it also made one packet participate in two authority systems. The outer header answered, “Which IPv4 endpoint handed this packet to the tunnel boundary?” The inner header answered, “Which IPv6 source does the packet claim?” Those questions overlap only in limited cases.

A comparison, not an identity proof

RFC 3964 required an important consistency check. If the inner source was a 6to4 address, the relay could compare the IPv4 value embedded in 2002:V4ADDR::/48 with the outer IPv4 source. A mismatch meant the packet should be discarded. Encapsulators and decapsulators also had to reject inappropriate special-purpose, multicast, broadcast, loopback or non-global values. The relevant address classes were grounded in IPv4 router rules such as RFC 1812 and are now recorded in the IANA IPv4 Special-Purpose Address Space registry.

The check mattered. An attacker who wanted to forge a particular 6to4 prefix also had to make the outer IPv4 source agree. Source filtering near the origin, as specified by BCP 38 / RFC 2827 and extended for multihomed networks by BCP 84 / RFC 3704, could make that harder.

But agreement is not authentication. A passing comparison proves that two address fields were consistent under one device's rules at one moment. It does not prove who controlled the source, whether the endpoint was an authorised router, whether the address assignment was current, or what application caused the packet. Ingress filtering is another bounded receipt: it can show plausibility against an attachment or route set, not human identity.

The reverse direction exposed the deeper limit. A native IPv6 source sending toward a 6to4 site has no 2002: source prefix to compare with the relay's outer IPv4 address. RFC 3964 said the 6to4 router could not easily tell whether the packet came from a legitimate relay or from a spoofing third party. The tunnel delivered a frame, but the frame did not carry a relay credential.

This resembles the trust problem around IPv6 Neighbor Discovery described in RFC 3756: being close enough to send a control or data packet is not the same as being authorised to occupy that role. In 6to4, the apparent “link” was the public IPv4 Internet.

The header that became link-layer detail

RFC 3964's sharpest operational sentence appears in its discussion of attacks on native IPv6. A 6to4 relay, it says, typically did not log the IPv4 addresses because they were treated like link-layer addresses. After decapsulation, an attack launched by an IPv4 node could therefore continue as an IPv6 packet while its src_v4 trace was lost.

That distinction prevents two opposite errors. The outer source was not definitive attribution: it might be spoofed, might name a relay rather than the origin, or might be an anycast address shared by many relays. Yet it remained valuable evidence. Deleting an imperfect clue does not make the surviving inner claim more trustworthy. It merely makes later reconstruction poorer.

The right record is relational. Before decapsulation, an operator can retain the ingress interface, concrete tunnel endpoint, outer IPv4 pair, inner IPv6 pair, packet time, protocol, applicable route epoch and the result of each check. After decapsulation, a new record should state whether the inner packet was forwarded, dropped or rate-limited. A complaint from the destination can then be joined back to the tunnel-boundary receipt. Without that join, a downstream observer may blame the inner address, while an abuse report may blame a relay that only forwarded the wrapper.

RFC 6169 later generalized the problem: inner addresses are not filtered by the network carrying the outer packet unless the tunnel endpoints perform equivalent checks, and security devices that are unaware of the tunnel can lose policy visibility. RFC 3964 supplied a concrete early case in which the transformation itself divided the evidence.

Anycast made reachability easy and instance identity hard

RFC 3068 assigned 192.88.99.1 as a 6to4 relay anycast address. IPv4 routing could select a nearby relay; a failed relay could withdraw its route and another could take over. The aim was operational simplicity. The RFC also admitted the cost: when a 6to4 router sent to the anycast address, identifying the specific relay was hard.

The address therefore proved less than its familiar shape suggested. A route to 192.88.99.1 showed that routing had selected some advertised path. It did not prove which physical instance would receive the packet, that the instance was willing to relay it, that it had native IPv6 reachability, that it performed RFC 3964's checks, or that the return path would use the same operator.

The 2011 operational advisory, RFC 6343, documented the consequences. Forward and return traffic commonly traversed different relays. A route could lead to an unwilling or broken relay. Stateful filters could reject a return path whose outer source differed. Unmanaged relays became sources of black holes and complaints. The convenience layer had hidden a multi-operator transaction without creating a shared receipt.

The standards history eventually narrowed the recommended surface. RFC 7526 formally deprecated anycast 6to4 and 192.88.99.1 in 2015. It did not deprecate the base RFC 3056 mechanism or 2002::/16. That precision matters. A policy document can retire one discovery and relay model without proving that every route, host, configured tunnel or residual packet has disappeared.

Correct handling was still not completed delivery

RFC 3964 catalogued denial of service, reflection, packet laundering, local IPv4 broadcast, theft of service and administrative abuse. It also prescribed checks: compare outer and embedded source values where that comparison is meaningful; refuse invalid IPv4 destinations; do not relay 6to4 traffic back into 6to4; reject traffic for someone else's local prefix; constrain routes and relay scope.

Those controls should not be collapsed into one green “valid” state. A packet can pass the address comparison and fail a special-address check. It can pass all admission checks and be dropped by later IPv6 policy. A relay can forward it and still lack a return path. A destination can receive it without the application accepting it. A relay operator can receive an abuse complaint without having originated the traffic.

The evidence chain is therefore longer than the tunnel:

  1. IPv4 routing selected an endpoint or anycast path.
  2. A concrete interface received a protocol-41 packet.
  3. The outer and inner headers were observed together.
  4. Each address, direction and relay rule produced its own verdict.
  5. Decapsulation produced an IPv6 packet.
  6. IPv6 forwarding admitted and sent it onward.
  7. The destination received or rejected it.
  8. An application produced an effect.
  9. Separate evidence connected the event to an authorised actor.

The tunnel could complete step five while leaving steps six through nine unresolved. That is the historical lesson in RFC 3964: a technically successful transformation can be the moment at which the best remaining clue to provenance is discarded.

Sources and limits

The principal evidence is RFC 3964's full text, RFC Editor record and errata record. Two verified technical errata correct an attack-example destination and a mistyped anycast prefix; neither proves a deployed failure. Historical context comes from RFCs 3056 and 3068; filtering context from RFCs 2827 and 3704; later operational and retirement context from RFCs 6343 and 7526; and broader tunnel, router and Neighbor Discovery context from RFCs 6169, 1812 and 3756.

These records establish protocol design, stated threats and later standards guidance. They do not establish a named attack, vendor defect, relay population, traffic volume, universal filtering practice or victim outcome.