RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
✨ RFC 3056: Connection of IPv6 Domains via IPv4 Clouds 🎀
Network Working Group 🌸 Request for Comments: 3056 Category: Standards Track Date: February 2001 Authors: B. Carpenter and K. Moore 💜
Bestie, the header doesn't list any RFCs that this one obsoletes or updates, so that part is empty. 🙈
Okay so the whole point of this RFC is getting IPv6 sites to talk to each other across the old IPv4 internet without anyone having to set up tunnels by hand 🦋 It's a ~~tunnel-free~~ 6to4 scheme, and it's giving transition tool, not forever solution 💅
Table of Contents 🧚
1. Introduction................................................. 2
1.1. Terminology................................................ 4
2. IPv6 Prefix Allocation....................................... 5
2.1 Address Selection........................................... 6
3. Encapsulation in IPv4........................................ 6
3.1. Link-Local Address and NUD................................. 7
4. Maximum Transmission Unit.................................... 7
5. Unicast scenarios, scaling, and transition to normal prefixes 8
5.1 Simple scenario - all sites work the same................... 8
5.2 Mixed scenario with relay to native IPv6................... 9
5.2.1 Variant scenario with ISP relay.......................... 12
5.2.2 Summary of relay router configuration.................... 12
5.2.2.1. BGP4+ not used........................................ 12
5.2.2.2. BGP4+ used............................................ 12
5.2.2.3. Relay router scaling.................................. 13
5.2.3 Unwilling to relay....................................... 13
5.3 Sending and decapsulation rules............................ 13
5.4 Variant scenario with tunnel to IPv6 space................. 14
5.5 Fragmented Scenarios....................................... 14
5.6 Multihoming................................................ 16
5.7 Transition Considerations.................................. 16
5.8 Coexistence with firewall, NAT or RSIP..................... 16
5.9 Usage within Intranets..................................... 17
5.10 Summary of impact on routing.............................. 18
5.11. Routing loop prevention.................................. 18
6. Multicast and Anycast....................................... 19
7. ICMP messages............................................... 19
8. IANA Considerations......................................... 19
9. Security Considerations..................................... 19
Acknowledgements............................................... 20
References..................................................... 20
Authors' Addresses............................................. 22
Intellectual Property.......................................... 22
Full Copyright Statement....................................... 23Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨
Copyright Notice ©️
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract 🌈
Okay this memo describes an optional interim mechanism that lets IPv6 sites talk to each other over the IPv4 network without any explicit tunnel setup 🦋 It can also reach native IPv6 domains through relay routers. Basically it treats the wide area IPv4 network like a unicast point-to-point link layer, which is so clever 🧚 It's meant as a start-up transition tool for the period when IPv4 and IPv6 are living together, and it is not intended as a permanent solution 💀
The document defines a way to hand an interim unique IPv6 address prefix to any site that has at least one globally unique IPv4 address 💖 It also specifies an encapsulation mechanism for sending IPv6 packets over the global IPv4 network using that prefix.
The motivation here is to let isolated IPv6 domains or hosts, sitting on an IPv4 network with no native IPv6 support, talk to other IPv6 domains or hosts with minimal manual configuration 🎀 This happens before they can get native IPv6 connectivity. As a bonus, it gives an interim globally unique IPv6 address prefix to any site with at least one globally unique IPv4 address, even if that site is behind an IPv4 Network Address Translator (NAT). Iconic 👑
1. Introduction ✨
This memo specifies an optional interim mechanism that lets IPv6 sites talk to each other over the IPv4 network without explicit tunnel setup 🦋 It can also let them talk to native IPv6 domains through relay routers. Effectively, the wide area IPv4 network is treated as a unicast point-to-point link layer. It's a start-up transition tool for the co-existence period of IPv4 and IPv6, not a permanent fix 💅
The document defines a method for assigning an interim unique IPv6 address prefix to any site with at least one globally unique IPv4 address 🌸 It also specifies how to encapsulate IPv6 packets so they can travel over the global IPv4 network using that prefix. It describes scenarios for using these prefixes during the IPv4-to-IPv6 co-existence phase too. Note that these scenarios are only part of the total transition picture, okay? 🙈 This is an interim solution, so sites should migrate to native IPv6 prefixes and native IPv6 connectivity when they can. That becomes possible as soon as the site's ISP offers native IPv6 connectivity 🫶
The basic mechanism in this document applies to sites rather than individual hosts. It will scale indefinitely by limiting the number of sites served by a given relay router (see Section 5.2) 📈 It introduces no new entries in the IPv4 routing table, and exactly one new entry in the native IPv6 routing table (see Section 5.10). Literally no notes on routing tables, very clean 💜
Even though the mechanism is specified for an IPv6 site, it can also be applied to an individual IPv6 host or a very small site, as long as it has at least one globally unique IPv4 address 🧚 However, that latter case raises serious scaling issues, which are the subject of further study [SCALE]. Bestie, that's a whole other drama 💀
The motivation is to let isolated IPv6 sites or hosts, attached to a wide area network with no native IPv6 support, communicate with other such IPv6 domains or hosts with minimal manual configuration 🎀
IPv6 sites or hosts connected this way do not need IPv4-compatible IPv6 addresses [MECH] or configured tunnels 🦋 This means IPv6 gets real independence from the underlying wide area network and can step over many hops of IPv4 subnets 🌈 The abbreviated name of this mechanism is 6to4 (not to be confused with [6OVER4]) ✨ The 6to4 mechanism is typically implemented almost entirely in border routers, with no specific host modifications except a suggested address selection default 💅 Only a modest amount of router configuration is required, which is giving low-effort energy 🙌
Sections 2 to 4 of this document specify the 6to4 scheme technically 📜 Section 5 discusses some, but not all, usage scenarios, including routing aspects, for 6to4 sites. Scenarios for isolated 6to4 hosts are not discussed in this document 🙈 Sections 6 to 9 discuss other general considerations 🫶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥
1.1. Terminology 📖
The terminology of [IPV6] applies to this document 💖
6to4 pseudo-interface: 6to4 encapsulation of IPv6 packets inside IPv4 packets happens at a point that is logically equivalent to an IPv6 interface, with the link layer being the IPv4 unicast network. This point is referred to as a pseudo-interface. Some implementors may treat it exactly like any other interface, and others may treat it like a tunnel end-point 🦋
6to4 prefix: An IPv6 prefix constructed according to the rule in Section 2 below ✨
6to4 address: An IPv6 address constructed using a 6to4 prefix 🌸
Native IPv6 address: An IPv6 address constructed using a different type of prefix than 6to4 🌈
6to4 router (or 6to4 border router): An IPv6 router supporting a 6to4 pseudo-interface. It is normally the border router between an IPv6 site and a wide-area IPv4 network 🧚
6to4 host: An IPv6 host which happens to have at least one 6to4 address. In all other respects it is a standard IPv6 host 💅
Note: an IPv6 node may in some cases use a 6to4 address for a configured tunnel. Such a node may function as an IPv6 host using a 6to4 address on its configured tunnel interface, and it may also serve as an IPv6 router for other hosts via a 6to4 pseudo-interface. These are distinct functions, though 🙈
6to4 site: A site running IPv6 internally using 6to4 addresses, therefore containing at least one 6to4 host and at least one 6to4 router 🏡
Relay router: A 6to4 router configured to support transit routing between 6to4 addresses and native IPv6 addresses 🦋
6to4 exterior routing domain: A routing domain interconnecting a set of 6to4 routers and relay routers. It is distinct from an IPv6 site's interior routing domain, and distinct from all native IPv6 exterior routing domains 👑
2. IPv6 Prefix Allocation 🎀
Okay so suppose a subscriber site has at least one valid, globally unique 32-bit IPv4 address. This memo calls it V4ADDR 💖 This address MUST be duly allocated to the site by an address registry (possibly via a service provider), and it MUST NOT be a private address [RFC 1918]. No private addresses, bestie, that's the rule 🚫
The IANA has permanently assigned one 13-bit IPv6 Top Level Aggregator (TLA) identifier under the IPv6 Format Prefix 001 [AARCH, AGGR] for the 6to4 scheme. Its numeric value is 0x0002, which means it is 2002::/16 when expressed as an IPv6 address prefix 🌈
The subscriber site is then deemed to have the following IPv6 address prefix, without any further assignment procedures being necessary ✨
Prefix length: 48 bits
Format prefix: 001
TLA value: 0x0002
NLA value: V4ADDRThis is illustrated as follows 🧚
| 3 | 13 | 32 | 16 | 64 bits |
+---+------+-----------+--------+--------------------------------+
|FP | TLA | V4ADDR | SLA ID | Interface ID |
|001|0x0002| | | |
+---+------+-----------+--------+--------------------------------+So this prefix has exactly the same format as normal /48 prefixes assigned according to [AGGR] 🦋 It can be abbreviated as 2002:V4ADDR::/48 💜 Inside the subscriber site it can be used exactly like any other valid IPv6 prefix. For example, it works for automated address assignment and discovery through the normal mechanisms such as [CONF, DISC], for native IPv6 routing, or for the "6over4" mechanism [6OVER4] 🔥
Note that if the IPv4 address is assigned dynamically, the corresponding IPv6 prefix will also be dynamic in nature, with the same lifetime 🙈 Heads up, that one's important!
More in part 2 of 5, bestie 🦋💖
2.1 Address Selection ✨
okay so, for 6to4 to work in complex topologies, source and destination address selection must be set up properly 💅 If the source IPv6 host has at least one 2002:: address assigned to it, and the set of IPv6 addresses the DNS returns for the destination host includes at least one 2002:: address, then the source host must pick the right source and destination addresses 🫶 The general address selection mechanisms are still being studied as I write this [SELECT], so this is subject to those. But the main idea that usually makes 6to4 work correctly is this:
If one host has only a 6to4 address, and the other one has both a 6to4 and a native IPv6 address, then the 6to4 address should be used for both. 🦋
If both hosts have a 6to4 address and a native IPv6 address, then either the 6to4 address should be used for both, or the native IPv6 address should be used for both. The choice should be configurable 🎀 The default configuration should be native IPv6 for both 🌸
3. Encapsulation in IPv4 🧚
okay so IPv6 packets from a 6to4 site get wrapped inside IPv4 packets when they leave the site through its external IPv4 connection 🌈 The IPv4 interface carrying the 6to4 traffic is basically the same as an IPv6 interface, so we call it a pseudo-interface. The phrase isn't meant to define how you actually implement it, though 🫶 V4ADDR MUST be configured on the IPv4 interface 💖
IPv6 packets are sent inside IPv4 packets [RFC 791] with an IPv4 protocol type of 41. That's the same number that's been assigned [MECH] for IPv6 packets tunneled inside IPv4 frames 🍓 The IPv4 header holds the Destination and Source IPv4 addresses. One or both of these will be identical to the V4ADDR field of an IPv6 prefix formed as specified above (see section 5 for more details) ✨ The IPv4 packet body holds the IPv6 header and payload 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol 41 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 header and payload ... /
+-------+-------+-------+-------+-------+------+------+The IPv4 Time to Live gets set as normal [RFC 791], and so does the encapsulated IPv6 hop limit [IPv6] 🕰️ Everything else follows Section 4.1.2 of [MECH] 🫶
3.1. Link-Local Address and NUD 🌙
The link-local address of a 6to4 pseudo-interface doing 6to4 encapsulation would, if needed, be formed as described in Section 3.7 of [MECH]. Honestly though, no scenario is known where that address would be useful 🙈 A peer 6to4 gateway can't work out which link-layer (IPv4) address to send to, so yeah 💀
Neighbor Unreachability Detection (NUD) is handled as described in Section 3.8 of [MECH] 💜
4. Maximum Transmission Unit 📦
MTU size considerations are the same as described for tunnels in [MECH] 🍓
If the IPv6 MTU size turns out to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will kick in. It's not ideal, but it isn't necessarily disastrous, unless the fragments get delivered to different IPv4 destinations because of some form of IPv4 anycast 😭 The IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating IPv4 header 🚫
Heads up: the IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating IPv4 header. Keep that one in mind, bestie 🫶
5. Unicast scenarios, scaling, and transition to normal prefixes 🌸
5.1 Simple scenario - all sites work the same 💖
The simplest way to deploy 6to4 is between a bunch of sites that each have at least one connection to a shared IPv4 Internet. That could be the global Internet, or it could be a corporate IP network 🏢 For the global Internet, the sites don't all have to connect to the same Internet service provider, so no drama there ✨ The only real requirement is that any site can send IPv4 packets with protocol type 41 to any of the others 🦋 By definition, each site has an IPv6 prefix in the format defined in Section 2. So it'll create DNS records for these addresses 🧁 For example, site A, which owns IPv4 address 192.1.2.3, will create DNS records with the IPv6 prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48 (i.e., 2002:c001:0203::/48). Site B, which owns address 9.254.253.252, will create DNS records with the IPv6 prefix {FP=001,TLA=0x0002,NLA=9.254.253.252}/48 (i.e., 2002:09fe:fdfc::/48) 💅
When an IPv6 host on site B queries the DNS entry for a host on site A, or otherwise gets its address, it gets an address with the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48 plus whatever SLA and Interface ID applies 🌈 The converse happens when a host on site A queries the DNS for a host on site B. IPv6 packets are formed and sent the normal way within both sites 🫶
_______________________________
| |
| Wide Area IPv4 Network |
|_______________________________|
/ \
192.1.2.3/ 9.254.253.252\
_______________________________/_ ____________________\____________
| / | | \ |
|IPv4 Site A ########## | |IPv4 Site B ########## |
| ____________________# 6to4 #_ | | ____________________# 6to4 #_ |
|| # router # || || # router # ||
||IPv6 Site A ########## || ||IPv6 Site B ########## ||
||2002:c001:0203::/48 || ||2002:09fe:fdfc::/48 ||
||_______________________________|| ||_______________________________||
| | | |
|_________________________________| |_________________________________|Inside a 6to4 site, addresses with the 2002::/16 prefix, apart from those with the local 2002:V4ADDR::/48 prefix, get handled like any other non-local IPv6 address 🧭 That means they go by a default or explicit route toward the 6to4 border router 🚏
When an outgoing packet reaches the 6to4 router, it gets encapsulated as defined in Section 3, following the additional sending rule defined in Section 5.3. Incoming packets get decapsulated according to the additional decapsulation rule defined in Section 5.3. The additional sending and decapsulation rules are the only changes to IPv6 forwarding, and they only happen at border routers 🎀 No IPv4 routing information gets imported into IPv6 routing (nor vice versa) 🙅♀️
In this scenario, any number of 6to4 sites can interoperate with no tunnel configuration and no special requirements from the IPv4 service 🤯 All that's needed is the right DNS entries and the additional sending and decapsulation rules configured in the 6to4 router. This router SHOULD also generate the appropriate IPv6 prefix announcements [CONF, DISC] 📣
Site A and site B will each need to run IPv6 routing internally, but in this simple scenario they don't need to run an IPv6 exterior routing protocol. IPv4 exterior routing does that job for them 🌍
It is RECOMMENDED that in any case each site uses only one IPv4 address per 6to4 router, and that it be the address assigned to the external interface of the 6to4 router 💜 Single-homed sites therefore SHOULD use only one IPv4 address for 6to4 routing. Multi-homed sites are discussed briefly in section 5.6 🌷
Because there's no configuration and the deployment is distributed, there are believed to be no particular scaling issues with the basic 6to4 mechanism, apart from encapsulation overhead 🫧 Specifically, it introduces no new entries in IPv4 routing tables 👑
5.2 Mixed scenario with relay to native IPv6 ✨
okay so bestie, during the transition to IPv6 we can totally expect a mix 🌈 Some sites will look like the model we just talked about, isolated sites whose only connection is the IPv4 Internet. Others will be part of bigger islands of native or tunneled IPv6 that use normal IPv6 TLA address space. 6to4 sites still need to reach those native islands, and the islands need to reach them back 🫶 In the 6to4 model, this happens through IPv6 routers that have both 6to4 and native IPv6 addresses. They act like standard IPv6 routers, but for this document we call them relay routers so they don't get mixed up with routers that only do 6to4 or only do native IPv6 💖
There must be at least one router acting as a relay between the 6to4 domain and a given native IPv6 domain. Nothing fancy here 💅 It's just a normal router that has at least one logical 6to4 pseudo-interface and at least one other IPv6 interface. Since it's a 6to4 router, it also follows the extra sending and decapsulation rules in Section 5.3 🎀
So now we have three separate routing domains to think about 👑
- The internal IPv6 routing domain of each 6to4 site.
- An exterior IPv6 routing domain connecting a given set of 6to4 border routers, relay routers included, to each other. That's the 6to4 exterior routing domain.
- The exterior IPv6 routing domain of each native IPv6 island.
- The internal routing domain of a 6to4 site behaves as described in section 5.1. 🧚
- There are two deployment options for a 6to4 exterior routing domain 🦋
2.1 No IPv6 exterior routing protocol is used. Each 6to4 router that uses a given relay router has a default IPv6 route pointing at that relay router. The relay router MAY apply source address based filters so it only accepts traffic from specific 6to4 routers 🙈
2.2 An IPv6 exterior routing protocol is used. The 6to4 routers that use a given relay router learn native IPv6 routes from it using a routing protocol such as BGP4+ [RFC 2283, BGP4+]. The relay router advertises whatever native IPv6 routing prefixes are appropriate on its 6to4 pseudo-interface. Those prefixes show which parts of the native IPv6 topology the relay router is willing to relay to. Picking them is a routing policy choice, and network operators really need to think carefully about traffic patterns and topology when they decide how far those advertisements reach 🍓 The relay router only peers over BGP with specific 6to4 routers whose traffic it's willing to accept.
Yes this option is more complex, but it gives really solid policy control 😭 BGP4+ policy decides which 6to4 routers get to use which relay router. Iconic behavior honestly 👑
- A relay router MUST advertise a route to 2002::/16 into the native IPv6 exterior routing domain. How far that 2002::/16 advertisement travels through the native IPv6 routing system is a routing policy decision 🌸 Since there will usually be several relay routers advertising it, network operators will need to filter it in a managed way. Bad policy here can lead to unreachability or to weird, perverse traffic patterns 💀
6to4 prefixes more specific than 2002::/16 must not be propagated in native IPv6 routing. The reason is to stop the IPv6 routing table from getting polluted by things from the IPv4 routing table 🧼 So a 6to4 site that also has a native IPv6 connection MUST NOT advertise its 2002::/48 routing prefix on that connection, and all native IPv6 network operators MUST filter out and discard any 2002:: routing prefix advertisements longer than /16 🚫
Sites with at least one native IPv6 connection, plus a 6to4 connection, will therefore have at least one IPv6 prefix that is not a 2002:: prefix ✨ Their DNS entries reflect that, so DNS lookups return multiple addresses. If two of these sites need to talk to each other, the choice between the 6to4 route and the native route depends on IPv6 address selection by the individual hosts (or even by applications) 🔥
Now let's go back to the example from the previous section 🎀 Say an IPv6 host on site B looks up the DNS entry for a host on site A, and the DNS gives back multiple IPv6 addresses with different prefixes.
____________________________ ______________________
| | | |
| Wide Area IPv4 Network | | Native IPv6 |
| | | Wide Area Network |
|____________________________| |______________________|
/ \ //
192.1.2.3/ 9.254.253.252\ // 2001:0600::/48
____________/_ ____________________\_________//_
/ | | \ // |
########## | |IPv4 Site B ########## |
__# 6to4 #_ | | ____________________# 6to4 #_ |
# router # || || # router # ||
########## || ||IPv6 Site B ########## ||
|| ||2002:09fe:fdfc::/48 ||
__Site A_____|| ||2001:0600::/48_________________||
as before | | |
______________| |_________________________________|If the host picks the 6to4 prefix based on some rule for multiple prefixes, it just sends packets to an IPv6 address built from the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48. For two-way connectivity to work, the packets have to come from the prefix {FP=001,TLA=0x0002,NLA=9.254.253.252}/48 💜 The address selection mechanism in Section 2.1 takes care of that for you 🫶
5.2.1 Variant scenario with ISP relay 🌷
The last scenario assumed the relay router belongs to a cooperative 6to4 user site. A variant is an Internet Service Provider that already offers native IPv6 connectivity and runs a relay router itself 🏆 Technically it's the same thing as before. Site B is just an internal 6to4 site of the ISP, and it might only have one system in it, which is the relay router 🧚
5.2.2 Summary of relay router configuration 📋
A relay router takes part in IPv6 unicast routing protocols on its native IPv6 interface, and it may also do that on its 6to4 pseudo-interface. Those are independent routing domains with separate policies, even if the same protocol (probably BGP4+) is used in both places 🦋
A relay router also takes part in IPv4 unicast routing protocols on the IPv4 interface it uses for 6to4. We won't go deeper into that here 🙈
On its native IPv6 interface, the relay router MUST advertise a route to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on that interface. Routing policy inside the native IPv6 routing domain decides how far that advertisement goes, which limits how visible the relay router is in that domain 👀
IPv6 packets that the relay router receives, whose next hop IPv6 address matches 2002::/16, get routed to its 6to4 pseudo-interface and handled according to the sending rule in Section 5.1 💅
5.2.2.1. BGP4+ not used
If BGP4+ isn't deployed in the 6to4 exterior routing domain (option 2.1 of Section 5.2), the relay router gets configured to accept and relay all IPv6 traffic only from its client 6to4 sites 🎀 Each 6to4 router served by the relay router gets configured with a default IPv6 route pointing at the relay router. For example, Site A's default IPv6 route ::/0 would point at the relay router's address under the prefix 2002:09fe:fdfc::/48 ✨
5.2.2.2. BGP4+ used
If BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2 of Section 5.2), the relay router advertises IPv6 native routing prefixes on its 6to4 pseudo-interface, peering only with the 6to4 routers it serves 🌸 (An alternative is that these routes could be advertised along with IPv4 routes using BGP4 over IPv4, rather than running a separate BGP4+ session.) The specific routes that get advertised depend on the applicable routing policy, but they must be chosen from among those reachable through the relay router's native IPv6 interface 🔥 In the simplest case, a default route to the whole IPv6 address space could be advertised. When several relay routers are in use, more specific routing prefixes would be advertised according to the routing policy you want 👑 BGP4+ usage is completely standard, so this document doesn't discuss it any further 💜
5.2.2.3. Relay router scaling 📈
Relay routers can bring scaling issues along with them 😬 In general, a relay router should not try to serve more sites than any other transit router, once you've allowed for the encapsulation overhead 🫶
5.2.3 Unwilling to relay 🙅♀️
It can happen that a site has a router with both 6to4 pseudo-interfaces and native IPv6 interfaces, but the site doesn't want to act as a relay router. That site MUST NOT advertise any 2002:: routing prefix into the native IPv6 domain, and MUST NOT advertise any native IPv6 routing prefixes or a default IPv6 route into the 6to4 domain. Inside the 6to4 domain, it behaves exactly like the basic 6to4 scenario in Section 5.1 🌈
5.3 Sending and decapsulation rules 🚀
The only change to standard IPv6 forwarding is that every 6to4 router (and only 6to4 routers) MUST implement the following additional sending and decapsulation rules ✨
In the sending rule, "next hop" means the next IPv6 node the packet gets sent to. That isn't necessarily the final destination. It's the next IPv6 neighbor that normal IPv6 routing mechanisms point to 🧭 If the final destination is a 6to4 address, it counts as the next hop for this rule. If the final destination is not a 6to4 address and it isn't local, the next hop from routing will be the 6to4 address of a relay router 🦋
ADDITIONAL SENDING RULE for 6to4 routers
if the next hop IPv6 address for an IPv6 packet
does match the prefix 2002::/16, and
does not match any prefix of the local site
then
apply any security checks (see Section 8);
encapsulate the packet in IPv4 as in Section 3,
with IPv4 destination address = the NLA value V4ADDR
extracted from the next hop IPv6 address;
queue the packet for IPv4 forwarding.A simple decapsulation rule for incoming IPv4 packets with protocol type 41 MUST be implemented 🎀
ADDITIONAL DECAPSULATION RULE for 6to4 routers
apply any security checks (see Section 8);
remove the IPv4 header;
submit the packet to local IPv6 routing.5.4 Variant scenario with tunnel to IPv6 space 🌙
A 6to4 site that has no IPv6 connections to the "native" IPv6 Internet can still get effective connectivity to the v6 Internet. It does this through a "configured tunnel" (using the terminology in [MECH]) to a cooperating router that does have IPv6 access but doesn't need to be a 6to4 router 🫶 Those tunnels could be autoconfigured using an IPv4 anycast address, but that's outside the scope of this document 😅 Alternatively, a tunnel broker can be used. This scenario suits a small user-managed site best 🍓
These mechanisms aren't described in detail in this document 🧚
5.5 Fragmented Scenarios
okay so if there are multiple relay routers between native IPv6 and the 6to4 world, different parts of the 6to4 world get served by different relays 🧚✨ the only extra complexity is how you scope the 2002::/16 routing advertisements inside the native IPv6 world. like any BGP4+ advertisement, the scope has to be set correctly by routing policy so traffic to 2002::/16 takes the paths you actually intended 💅
if there are multiple IPv6 stubs all connected by 6to4 over the global IPv4 Internet, it's basically a simple generalization of the basic scenarios in sections 5.1. and 5.2. no new issues show up 🌸 here's the picture:
______________
| AS3 |
|_IPv6 Network_| Both AS1 and AS2 advertise
| AS1 | AS2 | 2002::/16, but only one of
|______|_______| them reaches AS3.
// \\
__________//_ _\\__________ ______________
| 6to4 Relay1 | | 6to4 Relay2 | | IPv6 Network |
|_____________| |_____________| | AS4 |
| | |______________|
________|______________________|________ |
| | ______|______
| Global IPv4 Network |-----| 6to4 Relay3 |
|________________________________________| |_____________|
| | | |
____|___ ___|____ ____|___ ___|____
| 6to4 | | 6to4 | | 6to4 | | 6to4 |
| Site A | | Site B | | Site C | | Site D |
|________| |________| |________| |________|as long as the routing advertisements are configured consistently, there are no known issues with this one 🦋🫶
now the scenario we absolutely cannot have 🙈 if multiple IPv6 stubs are connected through multiple, disjoint IPv4 networks (aka a fragmented IPv4 world), the 6to4 world gets fragmented too. this is the one scenario that must be avoided 💀 the diagram below shows why it breaks: the 2002::/16 advertisement from Relay1 is invisible to Relay2, and vice versa. so Sites A and B have zero connectivity to sites C and D 😭
______________
| AS3 |
|_IPv6 Network_| Both AS1 and AS2 advertise
| AS1 | AS2 | 2002::/16, but sites A and B
|______|_______| cannot reach C and D.
// \\
__________//_ _\\__________
| 6to4 Relay1 | | 6to4 Relay2 |
|_____________| |_____________|
| |
________|_______ _______|________
| IPv4 Network | | IPv4 Network |
| Segment 1 | | Segment 2 |
|________________| |________________|
| | | |
____|___ ___|____ ____|___ ___|____
| 6to4 | | 6to4 | | 6to4 | | 6to4 |
| Site A | | Site B | | Site C | | Site D |
|________| |________| |________| |________|5.6 Multihoming
sites that are multihomed on IPv4 MAY level up the 6to4 scenario 🍓 each IPv4 border router gets its own 2002:: prefix, which gives you a simple form of IPv6 multihoming using multiple prefixes at once and multiple relay routers at once. main character multihoming energy 👑
5.7 Transition Considerations
if the routing advertisement and address selection rules above are followed, a site can migrate from 6to4 to native IPv6 over a long period of co-existence 🌈 no need to kill 6to4 until nobody's using it anymore. the stages go like this:
- run IPv6 on the site using any suitable implementation 💖 true native IPv6, [6OVER4], or tunnels are all fine.
- configure a border router (or a router plus IPv4 NAT) connected to the external IPv4 network so it supports 6to4, including advertising the right 2002:: routing prefix locally. set up IPv6 DNS entries using this prefix too. at this point 6to4 is automatically available and the site has scored a "free" IPv6 prefix 🎀✨
- find a 6to4 relay router that's willing to relay the site's traffic to the native IPv6 world 🦋 it could be another cooperative 6to4 site or an ISP service. if no exterior routing protocol is running in the 6to4 exterior routing domain, the site's 6to4 router gets configured with a default IPv6 route pointing at that relay's 6to4 address. if an exterior routing protocol like BGP4+ is in use, the site's 6to4 router gets configured to set up the appropriate BGP peerings 🧠
- once native external IPv6 connectivity is available, add a second (native) IPv6 prefix to both the border router config and the DNS config 💅 at this point an address selection rule decides when 6to4 gets used and when native IPv6 does.
- when 6to4 usage is determined to have ceased (which could take several years, bestie) 😭 remove the 6to4 configuration.
5.8 Coexistence with firewall, NAT or RSIP
the 6to4 mechanisms seem to be unaffected by a firewall at the border router 🛡️✨
if the site has very limited global IPv4 address space and is running an IPv4 network address translator (NAT), all of the above mechanisms still work 🎀 the NAT box also has to include a fully functional IPv6 router with the 6to4 mechanism. the address used for V4ADDR is just a globally unique IPv4 address allocated to the NAT. in the example from Section 5.1 above, the 6to4 routers would also be the sites' IPv4 NATs, which would own the globally unique IPv4 addresses 192.1.2.3 and 9.254.253.252 🌸
combining a 6to4 router with an IPv4 NAT like this gives the site a globally unique IPv6 /48 prefix automatically, sitting behind the NAT's IPv4 address 🤩 so every host behind the NAT can become an IPv6 host without any extra address space allocation and without the Internet service provider having to do anything. these IPv6 hosts don't need any address translation at all 💜
things get more complicated if a host is more than one NAT hop away from the globally unique IPv4 address space, because only the outermost NAT has a unique IPv4 address 😵💫 all IPv6 hosts in this situation must use addresses derived from the 2002: prefix built from the global IPv4 address of the outermost NAT. the IPv4 addresses of the inner NATs aren't globally unique and play no part in 6to4, and 6to4 encapsulation and decapsulation can only happen at the outermost NAT.
the Realm-Specific IP (RSIP) mechanism [RSIP] can also co-exist with 6to4 🫧 if a 6to4 border router is combined with an RSIP border router, it can support IPv6 hosts using 6to4 addresses, IPv4 hosts using RSIP, or dual stack hosts using both. RSIP handles fine-grained management of dynamic global IPv4 address allocation, and 6to4 gives each host a stable IPv6 global address 🥹 same as with NAT, the IPv4 address used to build the site's 2002: prefix will be one of the global addresses of the RSIP border router.
5.9 Usage within Intranets
nothing stops this whole scenario from being deployed inside a private corporate network as part of its internal move to IPv6 🏢💖 the corporate IPv4 backbone acts as the virtual link layer for individual corporate sites using 2002:: prefixes. the V4ADDR MUST be a duly allocated global IPv4 address, and it MUST be unique within the private network 🔒 that way the Intranet gets globally unique IPv6 addresses even when it's internally using private IPv4 addresses [RFC 1918] ✨
5.10 Summary of impact on routing
IGP (site) routing treats the local site's 2002::/48 prefix exactly like a native IPv6 site prefix assigned to the local site 🧚 there's also an IGP route to the generic 2002::/16 prefix, which points at the site's 6to4 router, unless it's handled as a default route.
EGP (i.e., BGP) routing includes advertisements for the 2002::/16 prefix from relay routers into the native IPv6 domain, and routing policy limits their scope 🦋 this is the only non-native IPv6 prefix advertised by BGP.
6to4 routers need routes to relay routers in order to reach the native IPv6 domain 🌈 in the simplest case there's a manually configured default IPv6 route to a relay router's address under the prefix {FP=001,TLA=0x0002,NLA=V4ADDR}/48, where V4ADDR is the IPv4 address of the relay router. that route could be used to establish a BGP session for exchanging additional IPv6 routes.
by construction, unicast IPv6 traffic inside a 6to4 domain follows exactly the same path as unicast IPv4 traffic 💅
5.11. Routing loop prevention
since 6to4 has no impact on IPv4 routing, it can't cause routing loops in IPv4 🙌 and since 2002: prefixes behave exactly like standard IPv6 prefixes, they won't create any new routing loop mechanisms in IPv6 unless someone misconfigures them. one very dangerous misconfiguration would be announcing the 2002::/16 prefix into a 6to4 exterior routing domain 😱 that would pull all 6to4 traffic into the site making the announcement. its 6to4 router would then send non-local 6to4 traffic back out, and boom, a loop 🔁💀
the 2002::/16 routing prefix can legitimately be advertised into the native IPv6 routing domain by a relay router, and into an IPv6 site's local IPv6 routing domain. so there's a real risk that a misconfiguration could get it advertised into a 6to4 exterior routing domain 🚨
to summarize, the 2002::/16 prefix MUST NOT be advertised to a 6to4 exterior routing domain 🫶
6. Multicast and Anycast
it's not possible to assume wide-area IPv4 multicast is generally available 🥺 so, unlike [6OVER4], the 6to4 mechanism has to assume only unicast capability in its underlying IPv4 carrier network. an IPv6 multicast routing protocol is needed [MULTI] 🌸
the allocated anycast address space [ANYCAST] is compatible with 2002:: prefixes, which means anycast addresses formed with such prefixes may be used inside a 6to4 site ✨
7. ICMP messages
ICMP "unreachable" and other messages returned by the IPv4 routing system go back to the 6to4 router that generated an encapsulated 2002:: packet 📬 however, that router will often be unable to return an ICMPv6 message to the originating IPv6 node, because the "unreachable" message doesn't carry enough information 😩 so the IPv4 network basically looks like an undiagnosable link layer for IPv6 operational purposes 🫠 other considerations are as described in Section 4.1.3 of [MECH].
8. IANA Considerations
no assignments by the IANA are required beyond the special TLA value 0x0002 that's already assigned 🎀
9. Security Considerations 🔐
Okay bestie, security is where things get serious 😭 Implementors have to remember that on top of possible attacks against IPv6, attacks against IPv4 still count too 💅 Using IP security at both the IPv4 and IPv6 levels should still be avoided, for efficiency reasons 🙈 Like, if IPv6 is already encrypted, encrypting IPv4 as well is redundant, unless traffic analysis is actually a threat you're worried about 🔒 And if IPv6 is already authenticated, authenticating IPv4 adds very little ✨
Here's the plot twist: IPv4 security will not protect IPv6 traffic once it leaves the 6to4 domain 💀 So implementing IPv6 security is required even if IPv4 security is available 🫶
By default, 6to4 traffic gets accepted and decapsulated from any source that regular IPv4 traffic is accepted from 🦋 If that's felt to be a security risk for some reason (say, IPv6 spoofing seems more likely than IPv4 spoofing), then extra source-address-based packet filtering could be applied 🛡️ One possible plausibility check is whether the encapsulating IPv4 address matches the encapsulated 2002:: address 👀 If you do run this check, you have to configure exceptions so that traffic from relay routers (Section 5) gets through 🌸 And 2002:: traffic must also be excepted from the checks that are applied to prevent spoofing of "6 over 4" traffic [6OVER4] 💖
⚠️ No matter what, any 6to4 traffic whose source or destination address embeds a V4ADDR that isn't in the format of a global unicast address MUST be silently discarded by both encapsulators and decapsulators 💅 Specifically, that means IPv4 addresses defined in [RFC 1918], broadcast, subnet broadcast, multicast and loopback addresses are all unacceptable 🙅♀️
Acknowledgements 🌈
The basic idea here probably isn't original, and we got invaluable comments from Magnus Ahltorp, Harald Alvestrand, Jim Bound, Scott Bradner, Randy Bush, Matt Crawford, Richard Draves, Jun-ichiro itojun Hagino, Joel Halpern, Tony Hain, Andy Hazeltine, Bob Hinden, Geoff Huston, Perry Metzger, Thomas Narten, Erik Nordmark, Markku Savela, Ole Troan, Sowmini Varadhan, members of the Compaq IPv6 engineering team, and other members of the NGTRANS working group 🫶 Some text has been copied from [6OVER4] ✨ And George Tsirtsis kindly drafted two of the diagrams 🎀
References 📚
- [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
- [AGGR] Hinden., R, O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
- [API] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999.
- [BGP4+] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
- [CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
- [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
- [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [6OVER4] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
- [ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", Work in Progress.
- [MULTI] Thaler, D., "Support for Multicast over 6to4 Networks", Work in Progress.
- [SCALE] Hain, T., "6to4-relay discovery and scaling", Work in Progress.
- [SELECT] Draves, R., "Default Address Selection for IPv6", Work in Progress.
- [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
- [RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Tuniguchi, "Realm Specific IP: Protocol Specification", Work in Progress.
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998.
Authors' Addresses 🖊️
Brian E. Carpenter
IBM
iCAIR, Suite 150
1890 Maple Avenue
Evanston IL 60201, USA
EMail: brian@icair.orgKeith Moore
UT Computer Science Department
1122 Volunteer Blvd, Ste 203
Knoxville, TN 37996-3450
USA
EMail: moore@cs.utk.eduIntellectual Property 🧠
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Full Copyright Statement ©
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society ✨
📦 where this page comes from
- ietf: rfc3056 2001-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms