RFC 5969
IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
Okay bestie, let's get the vibes straight first 💖 This is RFC 5969, and it's all about IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification 🎀 It was written by W. Townsley and O. Troan, both from Cisco ✨ It's a Standards Track document (ISSN: 2070-1721) and it's dated August 2010 📅 The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅
Abstract ✨
Okay so this doc specifies an automatic tunneling mechanism that's built to help push IPv6 out to end users through a service provider's IPv4 network infrastructure 🦋 The highlights are automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and a service that's equivalent to native IPv6 at the sites the mechanism serves. It's giving native IPv6 energy, no cap 🌈
Status of This Memo ✨
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF) 🎀 It represents the consensus of the IETF community, and it got public review before it was approved for publication by the Internet Engineering Steering Group (IESG) 🫶 If you want more on Internet Standards, check Section 2 of RFC 5741 📚
Info about the current status of this document, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5969 💜
Copyright Notice ✨
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 📜 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💖
Table of Contents ✨
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 6rd Prefix Delegation . . . . . . . . . . . . . . . . . . . . 5
5. Troubleshooting and Traceability . . . . . . . . . . . . . . . 7
6. Address Selection . . . . . . . . . . . . . . . . . . . . . . 7
7. 6rd Configuration . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Customer Edge Configuration . . . . . . . . . . . . . . . 8
7.1.1. 6rd DHCPv4 Option . . . . . . . . . . . . . . . . . . 9
7.2. Border Relay Configuration . . . . . . . . . . . . . . . . 10
8. Neighbor Unreachability Detection . . . . . . . . . . . . . . 11
9. IPv6 in IPv4 Encapsulation . . . . . . . . . . . . . . . . . . 12
9.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . 13
9.2. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 13
10. Transition Considerations . . . . . . . . . . . . . . . . . . 14
11. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . . 171. Introduction ✨
The original idea and the name of the mechanism (6rd) come from [RFC5569], which details a successful commercial "rapid deployment" of 6rd by a residential service provider 🏠 It's recommended reading, bestie 📖 This document describes the 6rd mechanism, which has been extended for use in more general environments. Throughout this document, the term 6to4 refers to the mechanism described in [RFC3056], and 6rd is the mechanism defined here 🦋
6rd is a protocol mechanism for deploying IPv6 to sites via a service provider's (SP's) IPv4 network 🎀 It builds on 6to4 [RFC3056], with the key difference that it uses an SP's own IPv6 address prefix instead of a well-known prefix (2002::/16) 👑 Because it uses the SP's IPv6 prefix, the operational domain of 6rd is limited to the SP network and stays under its direct control. From the view of customer sites and the IPv6 Internet at large, the IPv6 service is equivalent to native IPv6 ✨
The 6rd mechanism relies on an algorithmic mapping between the IPv6 and IPv4 addresses that are assigned for use within the SP network 🧮 This mapping lets IPv4 tunnel endpoints be determined automatically from IPv6 prefixes, which is what makes 6rd stateless 💖
6rd sees the IPv4 network as a link layer for IPv6, and it supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) [RFC2491] model 🌸
A 6rd domain is made up of 6rd Customer Edge (CE) routers and one or more 6rd Border Relays (BRs) 🧚 IPv6 packets encapsulated by 6rd follow the IPv4 routing topology within the SP network among CEs and BRs. BRs are only traversed for IPv6 packets that are destined to or arriving from outside the SP's 6rd domain 🛣️ Since 6rd is stateless, BRs may be reached using anycast for failover and resiliency (in a similar fashion to [RFC3068]) 🔥
On the "customer-facing" (i.e., "LAN") side of a CE, IPv6 is implemented the same way it would be for any native IP service delivered by the SP. Further considerations for IPv6 operation on the LAN side of the CE are out of scope for this document 🙈 On the "SP-facing" (i.e., "WAN") side of the 6rd CE, the WAN interface itself, encapsulation over Ethernet, ATM or PPP, and control protocols such as PPPoE, IPCP, DHCP, etc. all stay unchanged from current IPv4 operation 💅 Although 6rd was designed mainly to support IPv6 deployment to a customer site (such as a residential home network) by an SP, it can equally be applied to an individual IPv6 host acting as a CE 🫶
6rd relies on IPv4 and is designed to deliver production-quality IPv6 alongside IPv4, with as little change to IPv4 networking and operations as possible 🌈 Native IPv6 deployment within the SP network itself may continue for the SP's own purposes while it delivers IPv6 service to sites supported by 6rd. Once the SP network and operations can support fully native IPv6 access and transport, 6rd may be discontinued 🦋
6rd uses the same encapsulation and base mechanism as 6to4, and it could be viewed as a superset of 6to4 (6to4 could be achieved by setting the 6rd prefix to 2002::/16) ✨ Unlike 6to4, though, 6rd is for use only in an environment where a service provider closely manages the delivery of IPv6 service. 6to4 routes with the 2002::/16 prefix may exist alongside 6rd in the 6rd CE router, and doing so may offer some efficiencies when communicating directly with 6to4 routers 🍓
The 6rd link model can be extended to support IPv6 multicast, but IPv6 multicast support is left for future consideration 🔮
How this mechanism should be used, along with other deployment and operational considerations, is out of scope for this document 🙃
2. Requirements Language ✨
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 RFC 2119 [RFC2119] 💜
That's part 1 done, bestie 🫶 Section 3 (Terminology) is up next, so stay tuned 🦋✨
3. Terminology ✨
Okay bestie, let's get the vocab down first 💅 Here's what each term means:
- 6rd prefix 🌸: An IPv6 prefix the service provider picks for a 6rd domain. There is exactly one 6rd prefix for a given 6rd domain. An SP may deploy 6rd with a single 6rd domain or with multiple 6rd domains.
- 6rd Customer Edge (6rd CE) 🎀: A device acting as a Customer Edge router in a 6rd deployment. In residential broadband, this kind of device is sometimes called a "Residential Gateway" (RG) or "Customer Premises Equipment" (CPE). A typical 6rd CE serving a residential site has one WAN side interface, one or more LAN side interfaces, and a 6rd virtual interface. Within the 6rd context, it can also just be called a "CE" ✨
- 6rd delegated prefix 🦋: The IPv6 prefix the CE calculates for use inside the customer site. It's made by combining the 6rd prefix with the CE IPv4 address that came from IPv4 configuration methods. You can think of it as logically equivalent to a DHCPv6 IPv6 delegated prefix [RFC3633] 🧚
- 6rd domain 🌈: A set of 6rd CEs and BRs connected to the same virtual 6rd link. An SP can run a single 6rd domain or use several. Each domain needs its own separate 6rd prefix.
- CE LAN side 🏠: The part of a 6rd CE that serves the "Local Area Network (LAN)" or "customer-facing" side of the CE. The CE LAN side interface is fully IPv6 enabled 💖
- CE WAN side 🛰️: The part of a 6rd CE that serves the "Wide Area Network (WAN)" or "Service Provider-facing" side of the CE. The CE WAN side is IPv4-only.
- 6rd Border Relay (BR) 🚪: A 6rd-enabled router managed by the service provider, sitting at the edge of a 6rd domain. A Border Relay router has at least one of each of these: an IPv4-enabled interface, a 6rd virtual interface acting as an endpoint for the 6rd IPv6 in IPv4 tunnel, and an IPv6 interface connected to the native IPv6 network. Within the 6rd context, it can also be called a "BR" 👑
- BR IPv4 address 🔢: The IPv4 address of the 6rd Border Relay for a given 6rd domain. CEs use this address to send packets to a BR when they want to reach IPv6 destinations outside the 6rd domain.
- 6rd virtual interface 🫧: An internal multi-point tunnel interface where 6rd encapsulation and decapsulation of IPv6 packets inside IPv4 happens. A typical CE or BR implementation only needs one. A BR operating in multiple 6rd domains may need more than one, but never more than one per 6rd domain.
- CE IPv4 address 💜: The IPv4 address given to the CE as part of normal IPv4 Internet access (configured via DHCP, PPP, or otherwise). It may be global or private [RFC1918] within the 6rd domain. A 6rd CE uses this address to create the 6rd delegated prefix, and to send and receive IPv4-encapsulated IPv6 packets 🫶
4. 6rd Prefix Delegation 🎀
Here's the main event: the 6rd delegated prefix for a customer site is built by mashing together the 6rd prefix and all or part of the CE IPv4 address. The CE creates it automatically for the customer site once IPv4 service is up, and then it's used the same way as a prefix you'd get through DHCPv6 prefix delegation [RFC3633] 💅
Okay, the comparison that makes it click: 6to4 does something similar, but it grabs an entire IPv4 address and drops it into a fixed spot after a well-known /16 IPv6 prefix. 6rd is more flexible 🦋 The IPv6 prefix, plus where the IPv4 address bits go and how many of them get used, can all change from one 6rd domain to the next. The SP gets to adjust the size of the 6rd prefix, how many bits the 6rd mechanism uses, and how many bits are left over to hand out to customer sites. Also, to support stateless address auto-configuration on the CE LAN side, a 6rd delegated prefix SHOULD be /64 or shorter 🌸
The 6rd delegated prefix is made by sticking the 6rd prefix together with a consecutive set of bits from the CE IPv4 address, in order. Its length equals the length of the 6rd prefix (n) plus the number of bits taken from the CE IPv4 address (o) 🧚
Here's the layout of an IPv6 address (see Section 2.5.4 of [RFC4291]) with a 6rd prefix and an embedded CE IPv4 address:
| n bits | o bits | m bits | 128-n-o-m bits |
+---------------+--------------+-----------+------------------------+
| 6rd prefix | IPv4 address | subnet ID | interface ID |
+---------------+--------------+-----------+------------------------+
|<--- 6rd delegated prefix --->|
Figure 1Let's do an example 🍓 Say the 6rd prefix is /32 and 24 bits of the CE IPv4 address are used (for instance, all CE IPv4 addresses can be aggregated under 10.0.0.0/8). Then the size of the 6rd delegated prefix for each CE is automatically calculated to be /56 (32 + 24 = 56) ✨
Embedding fewer than the full 32 bits of a CE IPv4 address only works when an aggregated block of IPv4 addresses is available for a given 6rd domain. That's a stretch with global IPv4 addresses, but it's super likely in a deployment where CEs get private addresses 🙈 And if private addresses overlap within a given 6rd deployment, the deployment can be split into separate 6rd domains, most likely along the same topology lines the NAT-based IPv4 deployment would need anyway. In that case, each domain gets its own different 6rd prefix 🌈
Each 6rd domain can also use a different encoding of the embedded IPv4 address, even inside the same service provider. For example, if an SP has multiple IPv4 address blocks with different levels of aggregation, the number of IPv4 bits needed to encode the 6rd delegated prefix can vary from block to block. In that situation, different 6rd prefixes (and so separate 6rd domains) can be used to support the different encodings 👑
Now, the warning label ⚠️ Since 6rd delegated prefixes are picked algorithmically from an IPv4 address, changing the IPv4 address changes the IPv6 delegated prefix too. That ripples through the site's network and could be disruptive 💀 So it's recommended that the service provider assign CE IPv4 addresses with relatively long lifetimes 🫶
6rd IPv6 address assignment, and so the IPv6 service itself, is tied to the IPv4 address lease. That means the 6rd service is tied to it for authorization, accounting, and so on. For example, the 6rd delegated prefix has the same lifetime as its associated IPv4 address. The prefix lifetimes advertised in Router Advertisements, or used by DHCP on the CE LAN side, MUST be equal to or shorter than the IPv4 address lease time. If the IPv4 lease time isn't known, the lifetime of the 6rd delegated prefix SHOULD follow the defaults specified in [RFC4861] 🔥
5. Troubleshooting and Traceability 🔍
A 6rd IPv6 address and its associated IPv4 address for a given customer can always be figured out algorithmically by the service provider that runs the given 6rd domain. That's super useful for looking up logs and other data at an SP that might have more robust operational tools for IPv4 than for IPv6 💖 It also means IPv4 data path, node, and endpoint monitoring can be applied to IPv6 too 🧚
The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast address [RFC4291] for their own 6rd delegated prefix. This lets, for example, IPv6 ICMP echo messages be sent to the 6rd virtual interface itself, for extra troubleshooting of the internal operation of 6rd at a given CE or BR 🛠️ For the BR, the IPv4 address used to calculate the 6rd delegated prefix is the configured BR IPv4 address 🌸
6. Address Selection 🦋
All addresses assigned from 6rd delegated prefixes should be treated as native IPv6. No changes to the source address selection or destination address selection policy table [RFC3484] are necessary. Easy, no notes 💅✨
7. 6rd Configuration ⚙️
For a given 6rd domain, the BR and CE MUST be configured with the following four 6rd elements 👑 The configured values for these four 6rd elements are identical for all CEs and BRs within a given 6rd domain, so everyone's on the same page 🫶
IPv4MaskLen🎭: The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. For example, if there are no identical bits,IPv4MaskLenis 0 and the entire CE IPv4 address is used to create the 6rd delegated prefix. If there are 8 identical bits (for example, the private IPv4 address range 10.0.0.0/8 is being used),IPv4MaskLenis equal to 8, andIPv4MaskLenhigh-order bits are stripped from the IPv4 address before the corresponding 6rd delegated prefix is constructed.6rdPrefix🌈: The 6rd IPv6 prefix for the given 6rd domain.6rdPrefixLen🔢: The length of the 6rd IPv6 prefix for the given 6rd domain.6rdBRIPv4Address🚪: The IPv4 address of the 6rd Border Relay for a given 6rd domain.
7.1. Customer Edge Configuration ✨
okay so the four 6rd elements have to be the SAME across every CE in a 6rd domain 🫶 (all the CEs have to agree, bestie). There are a bunch of ways to get those values onto a CE: the Broadband Forum's "TR-69" [TR069] Residential Gateway management interface, an XML object pulled down once IPv4 is up, a DNS record, an SMIv2 MIB [RFC2578], PPP IPCP, or an admin just typing them in by hand 💅. This doc is all about getting them through one single DHCP option. A CE that does IPv4 configuration by DHCP SHOULD implement this option 💖. Other config and management methods can borrow the same format too, so CEs that support lots of methods stay consistent and easy to build 🧚.
The only other thing the CE needs to work out its 6rd delegated prefix and get IPv6 going is its own IPv4 address 🦋. That CE IPv4 address comes along with getting IPv4 Internet access (through DHCP, PPP, or whatever else). It can be global or private [RFC1918] inside the 6rd domain, no judgment 🌸.
A single 6rd CE MAY be connected to more than one 6rd domain, just like any router can have several IPv6-enabled SP-facing interfaces with their own sets of delegated prefixes from DHCPv6 prefix delegation or other means 👑. Each domain the CE is in needs its own set of 6rd config elements, and it'll generate its own 6rd delegated prefix for that domain 🌈.
7.1.1. 6rd DHCPv4 Option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_6RD | option-length | IPv4MaskLen | 6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 6rdPrefix |
| (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rdBRIPv4Address(es) |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2Here's the breakdown of the option fields, straight from the spec 📋:
option-code OPTION_6RD (212)
option-length The length of the DHCP option in octets (22
octets with one BR IPv4 address).
IPv4MaskLen The number of high-order bits that are identical
across all CE IPv4 addresses within a given 6rd
domain. This may be any value between 0 and 32.
Any value greater than 32 is invalid.
6rdPrefixLen The IPv6 prefix length of the SP's 6rd IPv6
prefix in number of bits. For the purpose of
bounds checking by DHCP option processing, the
sum of (32 - IPv4MaskLen) + 6rdPrefixLen MUST be
less than or equal to 128.
6rdBRIPv4Address One or more IPv4 addresses of the 6rd Border
Relay(s) for a given 6rd domain.
6rdPrefix The service provider's 6rd IPv6 prefix
represented as a 16-octet IPv6 address. The bits
in the prefix after the 6rdPrefixlen number of
bits are reserved and MUST be initialized to zero
by the sender and ignored by the receiver.Okay, so the IPv4MaskLen and 6rdPrefixLen bounds-checking rule is the big one 🔥. Add (32 - IPv4MaskLen) to 6rdPrefixLen and the total MUST be less than or equal to 128. Anything past 32 for IPv4MaskLen is just invalid, full stop 🙅♀️.
The CE MUST include a Parameter Request List Option [RFC2132] asking for the OPTION_6RD 🎀. Since the option carries exactly one IPv4MaskLen/6rdPrefixLen/6rdPrefix block, and DHCP can't send more than one instance of the same option, OPTION_6RD can only provision a single 6rd domain 💜. Setting up a CE router that's in multiple 6rd domains is out of scope for this spec 🙈.
Getting the OPTION_6RD DHCP option is basically the signal that 6rd service is available 🌸. By default, a 6rd-capable CE that gets a valid 6rd DHCP option will configure the 6rd virtual interface and the associated delegated prefix for its LAN side ✨. The CE MUST be able to turn 6rd off, and when it's off, any 6rd DHCP option that shows up gets silently ignored 🫥.
How a CE handles multiple BR IPv4 addresses is left for future work 🔮. In that case, a CE MUST support at least one BR IPv4 address, and it MAY support more than one 🦋.
When 6rd is turned on, a typical CE router installs a default route to the BR, a black hole route for the 6rd delegated prefix, and routes for any LAN-side assigned and advertised prefixes 🧚. Here's an example with a CE IPv4 address of 10.100.100.1, a BR IPv4 address of 10.0.0.1, an IPv4MaskLen of 8, 2001:db8::/32 as the 6rdPrefix, and one /64 prefix on a LAN-side interface. The typical CE routing table ends up looking like this 💅:
::/0 -> 6rd-virtual-int0 via 2001:db8:0:100:: (default route)
2001:db8::/32 -> 6rd-virtual-int0 (direct connect to 6rd)
2001:db8:6464:100::/56 -> Null0 (delegated prefix null route)
2001:db8:6464:100::/64 -> Ethernet0 (LAN interface)7.2. Border Relay Configuration
The 6rd BR MUST be configured with the same 6rd elements as the 6rd CEs in the same domain 🫶.
For better reliability and load balancing, the BR IPv4 address can be an anycast address shared across a 6rd domain 🌈. 6rd is stateless, so any BR can be used at any time ✨. If the BR IPv4 address is anycast, the relay MUST use that anycast IPv4 address as the source address in packets it relays to CEs 💖.
Since 6rd uses provider address space, no specific routes have to be advertised externally for 6rd to work, whether in IPv6 or IPv4 BGP 👑. But if anycast is used for the 6rd IPv4 relays, the anycast addresses must be advertised in the service provider's IGP 🎀.
8. Neighbor Unreachability Detection
Neighbor Unreachability Detection (NUD) for tunnels is described in Section 3.8 of [RFC4213] 🔍. In 6rd, all CEs and BRs can be treated as connected to the same virtual link, which makes them neighbors of each other 🧚. This section explains how to use neighbor unreachability detection without hurting the scalability of a 6rd deployment 💅.
A typical 6rd deployment can have a huge number of CEs in the same domain 😭. Reachability between CEs is based on IPv4 routing, and sending NUD or any periodic packets between 6rd CE devices is NOT RECOMMENDED, unless you're doing isolated troubleshooting of the 6rd mechanism 🙅♀️.
Checking whether a given 6rd CE can reach its BR isn't needed for 6rd to run properly 🌸. But if a CE has alternate paths to the BR to pick from, it could be useful 🦋. Sending NUD messages to a BR, especially periodic ones from tons of CEs, could overload the BR's control message processing path and hurt the scalability of the 6rd deployment 💀. So instead, a CE that needs to figure out BR reachability MUST use a method that lets the reachability detection packets follow a normal data forwarding path, without special processing by the BR ✨. Here's one method that does that 👇.
- The CE builds a payload of any size and content to send to the BR (for example, a zero-length null payload, a padded payload meant to test a certain MTU, a NUD message, and so on) 🎀. The exact format of the payload doesn't matter, because the BR won't process it directly 🫶.
- The payload is encapsulated with an inner IPv6 header and an outer IPv4 header, like so 💖:
- The IPv6 destination address is set to an address from the CE's 6rd delegated prefix that is assigned to a virtual interface on the CE.
- The IPv6 source address is also set to an address from the CE's 6rd delegated prefix, and it can be the same one used as the IPv6 destination address.
- The IPv4 header is then added the same way it would be for any packet headed to the BR. That means the IPv4 destination address is the BR's, and the source address is the CE IPv4 address.
- The CE sends the constructed packet out the interface where BR reachability is being monitored 🚀. When the BR receives it successfully, the BR MUST decapsulate and forward the packet normally 👑. The IPv4 header comes off as usual, which reveals the IPv6 destination as the CE, so the packet gets forwarded to that CE through the 6rd mechanism. In that step, the IPv4 destination is the originating CE's, and the IPv4 source is the BR's 🦋.
- When the constructed IPv6 packet reaches the CE's IPv6 address, one round trip to and from the BR is complete 🌈. That happens without the BR processing the message outside its normal data forwarding path 🧚. The CE then processes the IPv6 packet accordingly, like updating keepalive timers, metrics, and so on ⭐.
The payload can be empty or contain values that matter to the CE 🍓. Sending a proper NUD message can be convenient for some implementations (the BR will decrement the IPv6 hop limit, so keep that in mind) 🔥. Since the BR forwards the packet like any other data packet without processing the payload itself, the payload format is up to the implementer 💅.
9. IPv6 in IPv4 Encapsulation
IPv6 in IPv4 encapsulation and forwarding manipulations (for example, handling packet markings, checksumming, and so on) are done as specified in Section 3.5 of "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213], which is the same mechanism 6to4 [RFC3056] uses 🦋. ICMPv4 errors are handled as specified in Section 3.4 of [RFC4213] 🙈. By default, the IPv6 Traffic Class field MUST be copied to the IPv4 ToS (Type of Service) field 💜. That default behaviour MAY be overridden by configuration ✨. For more on IP Differentiated Services and tunneling, check out [RFC2983] and [RFC3168] 🎀.
IPv6 packets from a CE get encapsulated in IPv4 packets when they leave the site through the CE WAN-side interface 🚀. The CE IPv4 address MUST be configured to send and receive packets on this interface 🫶.
The 6rd link is modeled as an NBMA link, similar to other automatic IPv6-in-IPv4 tunneling mechanisms like [RFC5214] 🌈. All 6rd CEs and BRs are defined as off-link neighbors of one another 🧚. The link-local address of a 6rd virtual interface doing the 6rd encapsulation would, if needed, be formed as described in Section 3.7 of [RFC4213] 🌸. But no communication using link-local addresses will actually happen 🙅♀️✨.
9.1. Maximum Transmission Unit 📏✨
Okay so MTU and fragmentation for IPv6-in-IPv4 tunnels get a whole deep dive in Section 3.2 of RFC 4213 [RFC4213] 🤓. 6rd's scope is limited to a service provider network 🏠. IPv4 Path MTU discovery MAY be used to adjust the MTU of the tunnel as described in Section 3.2.2 of RFC 4213 [RFC4213], or the 6rd Tunnel MTU might be explicitly configured 💅.
The use of an anycast source address could lead to any ICMP error message generated on the path being sent to a different BR 🙈. Therefore, using dynamic tunnel MTU Section 3.2.2 of [RFC4213] is subject to IPv4 Path MTU blackholes 🕳️. Not ideal, bestie.
Multiple BRs using the same anycast source address could send fragmented packets to the same IPv6 CE at the same time 😭. If those fragmented packets from different BRs happen to use the same fragment ID, incorrect reassembly might occur 💀. So for this reason, a BR using an anycast source address MUST set the IPv4 Don't Fragment flag 🛑✨.
If the MTU is well-managed, so that the IPv4 MTU on the CE WAN side interface is set so that no fragmentation occurs within the boundary of the SP, then the 6rd Tunnel MTU should be set to the known IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes) 🧮. For example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel MTU might be set to 1480 bytes 🎀. Absent more specific information, the 6rd Tunnel MTU SHOULD default to 1280 bytes 🌸.
9.2. Receiving Rules 🛡️
Okay, this part is about stopping spoofing, and it's giving security queen 👑. In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet against the IPv4 source address it is encapsulated by, according to the configured parameters of the 6rd domain 🔍. If the two source addresses do not match, the packet MUST be dropped, and a counter gets incremented to indicate that a potential spoofing attack may be underway 🚨. Additionally, a CE MUST allow forwarding of packets sourced by the configured BR IPv4 address ✅.
By default, the CE router MUST drop packets received on the 6rd virtual interface (i.e., after decapsulation of IPv4) for IPv6 destinations not within its own 6rd delegated prefix 🚫🧚.
10. Transition Considerations 🌈
An SP network can migrate to IPv6 at its own pace, with little or no effect on customers being provided IPv6 via 6rd 🐢💖. When native IPv6 connectivity is available, an administrator can choose to disable 6rd 🔌.
The SP can choose to provision a separate IPv6 address block for native service, or reuse the 6rd prefix block itself 🤔. If the SP uses a separate address block, moving from 6rd to native IPv6 is seen as a normal IPv6 renumbering event for the customer 📦. Renumbering may also be avoided by injecting the 6rd delegated prefix into the SP's IPv6 routing domain 🧠. Further considerations with regards to transitioning from 6rd to native IPv6 are not covered in this protocol specification, so that's a plot for another day 📖.
11. IPv6 Address Space Usage 🧁
As 6rd uses service-provider address space, 6rd uses the normal address delegation a service provider gets from its Regional Internet Registry (RIR), and no global allocation of a single 6rd IANA-assigned address block like the 6to4 2002::/16 is needed 🦋.
The service provider's prefix must be short enough to encode the unique bits of all IPv4 addresses within a given 6rd domain, and still provide enough IPv6 address space to the residential site 🏡. Assuming a worst case scenario using the full 32 bits for the IPv4 address, assigning a /56 for customer sites would mean that each service provider using 6rd would require a /24 for 6rd in addition to other IPv6 addressing needs 😵💫. Assuming that 6rd would be stunningly successful and taken up by almost all Autonomous System (AS) number holders (32K today), then the total address usage of 6rd would be equivalent to a /9 🤯. If the SP instead delegated /60s to sites, the service provider would require a /28, and the total global address consumption by 6rd would be equivalent to a /13 📉. Again, this assumes that 6rd is used by all AS number holders in the IPv4 Internet today at the same time, that none have used any of 6rd's address compression techniques, and that none have moved to native IPv6 and reclaimed the 6rd space that was being used for other purposes 🫠.
To ease concerns about address usage, 6rd allows for leaving out redundant IPv4 prefix bits in the encoding of the IPv4 address inside the 6rd IPv6 address ✂️✨. This is most useful where the IPv4 address space is very well aggregated 🧩. For example, to provide each customer with a /60, if a service provider has all its IPv4 customers under a /12, then only 20 bits need to be used to encode the IPv4 address, and the service provider would only need a /40 IPv6 allocation for 6rd 🧮. If private address space is used, then a 10/8 would require a /36. If multiple 10/8 domains are used, then up to 16 could be supported within a /32 💜.
If a service provider has a non-aggregatable IPv4 space and requires the use of the full 32-bit IPv4 address in the encoding of the 6rd IPv6 address, the 6rd prefix MUST be no longer than /32 in order to offer a 6rd delegated prefix of at least /64 🫶.
The 6rd address block can be reclaimed when all users of it have transitioned to native IPv6 service ♻️. This may require renumbering of customer sites and use of additional address space during the transition period 😅.
12. Security Considerations 🔐💀
Okay, this section is serious, so buckle up 😤. A 6to4 relay router as specified in [RFC3056] can be used as an open relay 🚪. It can be used to relay IPv6 traffic and as a traffic anonymizer 🕶️. By restricting the 6rd domain to within a provider network, a CE only needs to accept packets from a single or small set of known 6rd BR IPv4 addresses, so many of the threats against 6to4 as described in [RFC3964] do not apply 🙌.
When applying the receiving rules in Section 9.2, IPv6 packets are just as well protected against spoofing as IPv4 packets are within an SP network 🔒.
A malicious user that is aware of a 6rd domain and the BR IPv4 address could use this information to construct a packet that would cause a Border Relay to reflect tunneled packets outside of the domain that it is serving 👀. If the attacker constructs the packet accordingly, and can inject a packet with an IPv6 source address that looks as if it originates from within another 6rd domain, forwarding loops between 6rd domains may be created, allowing the malicious user to launch a packet amplification attack between 6rd domains [RoutingLoop] 😱🔁.
One possible mitigation for this is to simply not allow the BR IPv4 address to be reachable from outside the SP's 6rd domain 🧱. In this case, carefully constructed IPv6 packets still could be reflected off a single BR, but the looping condition will not occur 🙅♀️. Tunneled packets with the BR IPv4 address as the source address might also be filtered, to prohibit 6rd tunnels from exiting the 6rd domain 🚧.
To avoid forwarding loops via other internal relays, the BR should employ outgoing and incoming IPv4 packet filters, filtering out all known relay addresses for internal 6rd BRs, ISATAP routers, or 6to4 relays, including the well-known anycast address space for 6to4 🧹.
Another possible mitigation to the routing loop issue is described in [V6OPS-LOOPS] 🛠️.
The BR MUST install a null route [RFC4632] for its 6rd delegated prefix, created based on its BR IPv4 address, with the exception of the IPv6 Subnet-Router anycast address 🕳️🫧.
13. IANA Considerations 📋
IANA assigned a new DHCP Option code point for OPTION_6RD (212), with a data length of 18 + N (OPTION_6RD with N/4 6rd BR addresses) 🎫✨.
14. Acknowledgements 💌
This RFC is based on Remi Despres' original idea described in [RFC5569], and the work done by Rani Assaf, Alexandre Cassen, and Maxime Bizon at Free Telecom 🙌. Brian Carpenter and Keith Moore documented 6to4, which all of this work is based upon 🫶. We thank Fred Templin for his review and contributions, and for sharing his experience with ISATAP 🥰. Review and encouragement have been provided by many others, and in particular Chris Chase, Thomas Clausen, Wouter Cloetens, Wojciech Dec, Bruno Decraene, Remi Despres, Alain Durand, Washam Fan, Martin Gysi, David Harrington, Jerry Huang, Peter McCann, Alexey Melnikov, Dave Thaler, Eric Voit, and David Ward 💖🌟.
15. References 📚
15.1. Normative References 💅
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter,
"IPv6 over Non-Broadcast Multiple Access (NBMA)
networks", RFC 2491, January 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)",
RFC 4861, September 2007.15.2. Informative References 📚
okay bestie, these are the "extra credit" refs 🎀 not required reading, but they're where the good background lives 💅
- [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
- [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
- [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
- [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
- [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
- [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
- [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
- [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
- [RoutingLoop] Nakibly and Arov, "Routing Loop Attacks using IPv6 Tunnels", August 2009,
http://www.usenix.org/event/woot09/tech/full_papers/nakibly.pdf. - [TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue 1 Amendment 2", December 2007.
- [V6OPS-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, May 2010.
Authors' Addresses 🫶
these are the people who wrote it, so you know who to thank (or ask questions 🧚)
- Mark Townsley Cisco Paris, France EMail:
mark@townsley.net - Ole Troan Cisco Bergen, Norway EMail:
ot@cisco.com
📦 where this page comes from
- ietf: rfc5969 2010-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms