6rd officially stands for “IPv6 Rapid Deployment”, although the initials of the person behind it are also “RD” (Rémi Després).
6rd was first deployed by an ISP in France, called Free (that is the name of the ISP, not the cost of the service – they are a commercial provider). They made IPv6 available to most of their 1.5 million subscribers in a five week period, as described in RFC 5569, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)”, January 2010. This is an informational RFC with little technical content. The technical details of 6rd are available in RFC 5969, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol Specification”, August 2010. RFC 5969 is a Standards Track document, and is not a replacement for RFC 5569.
From RFC 5969:
6rd specifies a protocol mechanism to deploy IPv6 to sites via a service provider's (SP's) IPv4 network. It builds on 6to4 [RFC3056], with the key differentiator that it utilizes an SP's own IPv6 address prefix rather than a well-known prefix (2002::/16). By using the SP's IPv6 prefix, the operational domain of 6rd is limited to the SP network and is under its direct control. From the perspective of customer sites and the IPv6 Internet at large, the IPv6 service provided is equivalent to native IPv6.
The 6rd mechanism relies upon an algorithmic mapping between the IPv6 and IPv4 addresses that are assigned for use within the SP network. This mapping allows for automatic determination of IPv4 tunnel endpoints from IPv6 prefixes, allowing stateless operation of 6rd.
6rd is a tunnel technology that is a variant of the 6to4 tunnel. The main difference is that 6rd allows the provider to restrict the users to relay routers that are under the control of the ISP, as opposed to ones chosen at random. This addresses some of the reliability and security issues with 6to4.
There are a lot of terms used in discussing 6rd:
6rd prefix – An IPv6 address prefix chosen by the ISP for a 6rd domain. Each 6rd domain has exactly one IPv6 prefix, but a single ISP can deploy any number of 6rd domains. In the above example, the 6rd prefix was 2a00:380::/28.
6rd Customer Edge (6rd CE or just CE) – A 6rd compliant Customer Premises Equipment (CPE), also called a Residential Gateway (RG). The WAN interface connects to the ISP (usually via PPP, e.g. over DSL) and receives native IPv4, with IPv6 tunneled. It also has a LAN interface, with IPv4 and IPv6. It should send Router Advertisements via the LAN interface. It also runs a DHCPv4 server for IPv4 autoconfiguration of internal nodes, and a NAT44 gateway to map between the internal address block and the external IPv4 address on the WAN interface. The external IPv4 address can be public or shared address space (100.64/10).
6rd delegated prefix – the 64-bit IPv6 address prefix derived from the IPv4 external address on the WAN interface of the CE. It consists of the 6rd domain’s IPv6 prefix, followed by some or all of the bits in the IPv4 external address, then 0 or more bits of user-managed subnet ID. If there are some bits that are the same in the external IPv4 address of all customers in the 6rd domain (e.g. the IPv4 prefix), that can be discarded (so in 10/8, the first 8 bits are usually not included).
6rd domain – a set of 6rd CEs (CPEs) and BRs (Border Relays) connected to the same virtual 6rd link. Each domain requires a separate 6rd prefix. An internal node belongs to exactly one 6rd domain. The domain it belongs to determines the first part of the Ipv6 prefix for each CPE, as well as what BRs the node can use.
6rd Border Relay (BR) – a 6rd-enabled router managed by the SP at the edge of a 6rd domain. It has at least one of each of the following:
- an IPv4-enabled interface. A CE sends packets to the IPv4 interface of the BR to reach IPv6 destinations outside of the 6rd domain.
- a 6rd pseudo interface (tunnel endpoint), one per 6rd domain the router is connected to. This is the point at which encapsulation (adding IPv4 Packet Header) or decapsulation (Removing IPv4 Packet Header) of packets takes place.
- an IPv6 interface connected to the native IPv6 network (and indirectly to the IPv6 Internet)
CE LAN Side Interface – Dual-Stack. Connected to the internal network – serves DHCPv4 and Router Advertisements to nodes in the internal network.
CE WAN Side Interface – IPv4-only. Sends and receives regular IPv4 traffic and IPv4-encapsulated IPv6 packets.
All BR and CE in a given 6rd domain must use the same values for the following four items:
IPv4MaskLen – the number of high order bits that are identical agree all CE IPv4 addresses in a given 6rd domain. For example, if CEs use 10/8, then IPv4MaskLen is 10. I they use Shared Address Space (100.64/10) then IPv4MaskLen is 10.
6rdPrefix – the 6rd IPv6 prefix for the given 6rd domain.
6rdPrefixLen – the length of the 6rd prefix for the given 6rd domain.
6rdBRIPv4Address – the IPv4 address of the 6rd Border Relay for a given 6rd domain.
6to4 tunnels all use the generic “2002::/16” prefix. Each tunnel endpoint requires a public IPv4 address. Each 6rd deployment uses a distinct IPv6 prefix that is a function of the IPv4 addresses used by that ISP. Normally (and in the original deployment at Free) each customer has a public IPv4 address. The IPv6 address a particular node gets is derived from the customer’s IPv4 address as assigned by the ISP. If the assigned IPv4 address is not stable (e.g. changes from time to time) then the customer’s IPv6 prefix also changes. This can lead to problems since IPv6 addresses are public and can be used as destinations (not just sources), and can be published in DNS. It is important that ISPs that deploy IPv6 provide static IPv4 addresses (i.e. ones that are stable, or don’t change over time) to their customers.
Like 6to4, tunnels are automatically created (you don’t need to manually configure them as with 6in4). The ISP customer has an external IPv4 address. This address is the one assigned to the WAN (outside) interface of the CPE box (ISP modem/router at the customer site), and can also be used for “Hide Mode” NAT44. Normally this is a public IPv4 address, but it does not have to be for 6rd. 6rd is intended to route an entire block (e.g. one or more /64s) of IPv6 to a group of nodes behind the CPE (it is not designed to provide a single node in an IPv4-only network with a /128 IPv6 address, like Teredo). It can provide any number of /64s to each customer (e.g. 16 /64s, 256 /64s, in theory up to 65,536 /64s), depending on address structure.
For example, let’s say a customer was assigned the public IPv4 address 18.104.22.168/32, and the ISP has a /28 block of IPv6 for this 6rd domain, which is 2a00:380::/28.
The customer’s IPv4 address in hex is 91fd6430. Combined with the ISP’s /28 6rd prefix, this results in 16 /64 blocks of IPv6 addresses (2a00:389:1fd6:4300::/60) being routed to the customer site. The customer controls the bottom 4 bits of the IPv6 prefix, and within each subnet, they control all 64 bits of the Interface Identifier, as usual. The cusotmer’s CPE (and optionally internal routers) advertise one of those /64 blocks in each subnet. The customer’s routers can have the /64 prefix they advertise assigned via DHCPv6 Prefix Delegation (or various other management schemes). Individual nodes in one of those subnets can assign 64-bit Interface Identifiers as usual (manual assignment, DHCPv6 stateful address assignment, or autonomous generation via SLAAC with random values or EUI-64). To the outside world, these appear to be normal native IPv6 addresses. Internally the customer’s network is native Dual Stack network. As usual, the tunnel exists only between the ISP and the WAN interface of the customer’s CPE. Each internal node has its own autonomously generated Link-Local IPv6 address, plus one or more global unicast IPv6 addresses. IPv4 is handled as usual, with NAT44 and a DHCPv4 server in the CPE providing private addresses for internal nodes hidden behind the single public IPv4 address.
It is possible to use less than 32 bits of the IPv4 address in generating the IPv6 prefix, if part of that address is the same for all of the customers in the 6rd domain. For example, the ISP may have a /16 block of IPv4, 145.253/16 (65,534 public addresses). They could use only the unique least significant 16 bits of each address (in the case of the customer above that would be 100.48) to generate that customer’s IPv6 prefix. This greatly reduces the size of the ISP’s IPv6 allocation block.
If the ISP is using the entire 32 bits of the customer’s IPv4 address, and wants to allocate a /60 block (sixteen /64 blocks) per customer, then they need a /28 IPv6 allocation. They can instead use only the low 16 bits of each customer’s IPv4 address (since the first 16 bits of each customer’s address is really the same there is no need to use those bits in deriving a unique IPv6 prefix for each customer). Now the ISP only needs a /36 block of IPv6 to be able to allocate a /60 (16 subnets) to each of their customers. This is much more practical.
If the ISP wants to allocate a /56 block (256 subnets) to each customer, using same /16 block of IPv4, then they need a /32 block of IPv6 for this 6rd domain.
6rd for Customers with No Public IPv4 Address
Let’s say the ISP no longer has enough IPv4 public addresses to give each customer one public address. The ISP can use CGN to provide each customer with one of the addresses in the Shared Address Space block 100.64/10 (this consists of all addresses from 100.64.0.1 to 22.214.171.124). This should be used for the NAT44 located in the ISP, instead of 10/8, because the customer may be using 10/8 (or some subset of that) internally, and then their NAT44 would break. With NAT44 the internal address block cannot conflict with the external address block, so if the CGN assigned you the address 10.1.2.3/32 for the WAN interface of your CPE (from the block 10/8), you would not be able to use 10/8, or 10.1/16 or 10.1.2/24 for your internal address block. That is why the new 100.64/10 block was reserved. It is exactly like the RFC 1918 private address ranges, except that it is reserved for only Service Providers to use – this means no home users should ever use it, so it is safe to deploy on the client side of a CGN. If you do use it in your home or company network, don’t complain if CGN doesn’t work for you.
If the ISP uses the entire 100.64/10 block there are 22 “unique address bits” in the customer’s WAN addresses. If the ISP allocates a /60 to each customer (4 additional bits), then there are 22 + 4 = 26 bits unique to each customer. The ISP would then need a 64 – 26 = 38 bit prefix (a /38 block of IPv6) just for that 6rd domain. If they allocate a /56 to each customer (8 additional bits instead of 4), then there are 22 + 8 = 30 bits unique to each customer. The ISP would then need a 64 – 30 = 34 bit prefix (a /34 block of IPv6) for jsut that 6rd domain.
The 100.64/10 block contains 222 – 2 (4,194,302) usable addresses. If the ISP has 10 million customers they would need three 6rd domains, and a CGN for each one. Each 6rd domain would require a separate /38 block of IPv6 (if providing 16 subnets per customer) or a /34 block of IPv6 (if providing 256 subnets per customer).
The 6rd CE routers and the 6rd relay routers would all need to be able to handle private addresses (some only handle public addresses).
6rd Node Address Syntax
| n bits | o bits | m bits | 128-n-o-m bits | +---------------+--------------+-----------+------------------------+ | 6rd prefix | IPv4 address | subnet ID | interface ID | +---------------+--------------+-----------+------------------------+ |<--- 6rd delegated prefix --->|
In the above, the first n bits contain the 6rd prefix (e.g. 2a00:380::/28)
The next o bits contain the IPv4 prefix. Up to 32 bits, usually 32 – ‘CIDR prefix length of the IPv4 address’.
The next m bits contain the user managed subnet ID (up to 16 bits)
The bottom 128-n-o-m bits (usually 64 bits) contain the Interface Identifier.
Example 1: 6rd prefix is 2a00:380::/28 (n=28), IPv4 address = 126.96.36.199/32 (n=32, address is 91fd6430 in hex), then the delegated prefix is 2a00:389:1fd6:4300::/60. m is 64-28-32 = 4 (i.e. 24 = 16 subnets behind each CPE).
Example 2: 6rd prefix is a 2001:db8::/32 (m=32 bits), the IPv4 external address is 100.64.1.2/10 (o=22, address is 64400102 in hex), then the delegated prefix is 2001:db8:4001:0200::/54. m is 64-32-22 = 10 (i.e. 210 1024 subnets behind each CPE).
For each 6rd domain the ISP deploys, they deploy one or more BRs linked to it, and any number of CEs that use those BRs (one per customer). If they have enough IPv4 public addresses to assign one to each customer, each customer sees only one level of NAT44 (the one in their CE). If the ISP does not have enough IPv4 public addresses to assign one to each customer, they also deploy a CGN, ideally using 100.64/10 on the customer side of the CGN, and one or more public IPv4 addresses on the WAN side of the CGN. In that case, each customer sees two layers of NAT4 – the one in their CE and the one at the ISP. The ISP must also deploy their end of the 6in4 tunnel.
For IPv4, The WAN gateway of each CE gets either a public IPv4 address, or one of the shared address space addresses from 100.64/10. The CE does one layer of NAT44 to hide the internal nodes behind it. If CGN is not deployed, then internal nodes are behind one layer of NAT44. If CGN is deployed, then internal nodes are behind two layers of NAT44 (also called NAT444). The LAN interface also provides DHCPv4 (and often relayed DNS).
For IPv6, the WAN gateway of each CE contains a 6in4 tunnel endpoint. The LAN side of each CE has one or more /64 blocks routed to it. Each subnet has a source of Router Advertisements advertising a 64-bit prefix consisting of the delegated prefix followed by one of the available Subnet IDs. Additional internal subnets (if any) also each have a source of Router Advertisements advertising other /64 prefixes (each consisting of the 6rd delegated prefix and one of the available Subnet IDs). All nodes in all internal subnets have both an autonomously generated Link Local unicast address, plus one or more global unicast addresses valid for that subnet’s prefix (manually assigned, assigned via DHCPv6, and/or autonomously generated via SLAAC).
So even if the ISP deployed CGN on your IPv4, every node in your (possibly multiple subnet) network has one or more valid IPv6 global unicast addresses. Any protocol that has trouble with NAT44 or NAT444 can be moved to global IPv6. The only tunneling is between the ISP and the CE.
Note that even if private or shared space IPv4 addresses are used for the WAN address of the CEs, the generated 6rd prefix is still globally unique, so long as the portion of the IPv4 address used is unique for each CE.
Cisco and other vendors are aggressively marketing 6rd systems for ISPs. While not as good as DS-Lite (which never has more than one NAT44 layer, and the IPv6 is never tunneled), 6rd is less disruptive and expensive (no need to deploy native IPv6 to the customer), and configuration is pretty much automated. It is far better than deploying CGN without any IPv6. It does require a 6rd compliant CE device for each customer, which includes a source of Router Advertisements. Ideally it should also include at least some user-configurable firewall controls.
6rd is much more secure and reliable than 6to4 (due to only using only BRs tied to the 6rd domain), and does not require a public IPv4 address on each CE.
Just be sure that the IPv4 address assigned to each CE is stable (doesn’t change over time).