| Internet Engineering Task Force | T. Tsou |
| Internet-Draft | Huawei Technologies (USA) |
| Intended status: Informational | C. Zhou |
| Expires: June 01, 2012 | T. Taylor |
| Huawei Technologies | |
| O. Troan | |
| Cisco Systems, Inc. | |
| Q. Chen | |
| China Telecom | |
| December 2011 |
"Gateway-Initiated" 6rd
draft-tsou-softwire-gwinit-6rd-04
This document proposes an alternative 6rd deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned gateway collocated with the operator's IPv4 network edge, rather than from customer equipment. The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 01, 2012.
Copyright (c) 2011 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, as they describe your rights and restrictions with respect to this document.
6rd ([RFC5969]) provides a transition tool for connecting IPv6 devices across an IPv4 network to an IPv6 network, at which point the packets can be routed natively. The network topology is shown in Figure 1.
+--------------+ +-----------------+ +---------+
| | | | | |
+-----+ +-----+ | Provider +--------+ | |
|IPv6 | | 6rd |__| IPv4 | Border |__| IPv6 |
|Host | | CE | | network | Router | | network |
+-----+ +-----+ | +--------+ | |
| Customer LAN | | | | |
+--------------+ +-----------------+ +---------+
Figure 1: 6rd Deployment Topology
In Figure 1, the CE is the customer edge router. It is provisioned with a delegated IPv6 prefix, but also with an IPv4 address so that it is reachable through the IPv4 network. If a public IPv4 address is provisioned to every customer, it will aggravate the pressure due to IPv4 address shortage for operators faced with a high rate of growth in the number of broadband subscribers to their network. It is out of scope of this document if private IPv4 address is provisioned.
This document uses no requirements language.
Consider an operator facing a high subscriber growth rate. As a result of this growth rate, the operator faces pressure on its stock of available public IPv4 addresses. For this reason, the operator is motivated to offer IPv6 access as quickly as possible.
The backbone network will be the first part of the operator's network to support IPv6. The metro network is not so easily upgraded to support IPv6 since many devices need to be modified and there may be some impact to existing services. Thus any means of providing IPv6 access has to minimize the changes required to devices in the metro network.
In contrast to the situation described for basic 6rd [RFC5569], the operator is assumed to be unable to manage IP devices on the customer premises. As a result, the operator cannot assume that any of these devices are capable of supporting 6rd.
If the customer equipment is in bridged mode and IPv6 is deployed to sites via a Service Provider's (SP's) IPv4 network, the IPv6-only host needs a IPv6 address to visit the IPv6 service. In this scenario, 6to4 or 6rd can be used. However, each IPv6-only host may need one corresponding IPv4 address when using public IPv4 address in 6to4 or 6rd, which puts great address pressure on the operators.
If the customer equipment is operating in routing mode, the operator has an opportunity to avoid assigning IPv4 addresses to sites running IPv6 only. Some other means is available for routing IPv6 traffic through the IPv4 network to that site. The Gateway in the existing IPv4 access network should be updated to support IPv6. But the metro network does not need to be updated.
In the 6rd scenario, reachability between CEs in 6rd should go to the BR. But in this gateway-initiated 6rd case, it does not need to go to the BR which only needs gateway to gateway traffic. How the interaction between gateway and gateway works is for further elaboration.
For basic 6rd, the 6rd-CE described in [RFC5969] initiates the 6-in-4 tunnel to the Border Router to carry its IPv6 traffic. To avoid the requirement for customer premises equipment to fulfill this role, it is necessary to move the tunneling function to a network device. This document identifies a functional element termed the 6rd provider edge (6rd PE) to perform this task. The functions of 6rd PE are:
In the proposed solution, there is only one tunnel initiated from each Gateway to the Border Router, which greatly reduces the number of tunnels the Border Router has to handle. The deployment scenario consistent with the problem statement in Section 2 collocates the Gateway with the IP edge of the access network. This is shown in Figure 2, and is the typical placement of the Broadband Network Gateway (BNG) in a fixed broadband network. By assumption, the metro network beyond the BNG is IPv4. Transport between the customer site and the Gateway is over layer 2.
+-------+ +-------------------+ +---------+
+-----+ | | | | | |
|IPv6 | | | +---------+ IPv4 +--------+ | IPv6 |
|Cust |_|Access |_| Gateway | Metro | Border |_| core |
|site | |network| |(IP edge)| network | Router | | network |
+-----+ | | +---------+ +--------+ | |
| | | | | |
+-------+ +-------------------+ +---------+
Figure 2: Gateway-Initiated 6rd At the IP Edge
The elements of the proposed solution are these:
Referring back to Figure 2, prefix assignment to the customer equipment occurs in the normal fashion through the Gateway/IP edge, using either DHCPv6 or SLAAC. Figure 3 illustrates the structure of the assigned prefix, and how the components are derived, within the context of a complete address.
+--------------------+-----------+
| 32 bit Gateway IPv4 address |
+--------------------+-----------+
|<---IPv4MaskLen --->| o bits | Gateway or manually
/ / generated value, unique
Configured / / / for the gateway
| / / |
| / / V
| V p bits | o bits | n bits |m bits | 64 bits |
+----------------+------------+---------+-------+----------------+
| | Gateway |Customer | | |
| Common prefix | identifier | site |subnet | interface ID |
| | | index | ID | |
+----------------+------------+---------+-------+----------------+
|<------ GI 6rd delegated prefix ------>|
Figure 3: Gateway-Initiated 6rd Address Format for a Customer Site
The common prefix, i.e., the first p bits of the GI 6rd delegated prefix, is configured in the Gateway. This part of the prefix is common across multiple customers and multiple Gateways. Multiple common prefix values may be used in a network either for service separation or for scalability.
The Gateway Identifier is equal to the o low-order bits of the Gateway IPv4 address on the virtual link to the Border Router. The number of bits o is equal to 32 - IPv4MaskLen, where the latter is the length of the IPv4 prefix from which the Gateway IPv4 addresses are derived. The value of IPv4MaskLen is configured in both the Gateways and the Border Routers.
The Customer Site Index is effectively a sequence number assigned to an individual customer site served by the Gateway. The value of the index for a given customer site must be unique across the Gateway. The length n of the Customer Site Index is provisioned in the Gateway, and must be large enough to accommodate the number of customer sites that the Gateway is expected to serve.
To give a numerical example, consider a 6rd domain containing ten million IPv6-capable customer devices (a rather high number given that 6rd is meant for the early stages of IPv6 deployment). The estimated number of 6rd Gateways needed to serve this domain would be in the order of 3,300, each serving 30,000 customer devices. Assuming best-case compression for the Gateway addresses, the Gateway Identifier field has length o = 12 bits. If IPv6-in-IPv4 tunneling is being used, this best case is more likely to be achievable than it would be if the IPv4 addresses belonged to the customer devices. More controllably, the customer device index has length n = 15 bits.
Overall, these figures suggest that the length p of the common prefix can be 29 bits for a /56 delegated prefix, or 21 bits if /48 delegated prefixes need to be allocated.
A number of the points in [RFC5969] apply with the simple substitution of the Gateway for the 6rd CE. When it comes to configuration, the definition of IPv4MaskLen changes, and there are other differences as indicated in the previous section. Since special configuration of customer equipment is not required, the 6rd DHCPv6 option is inapplicable.
Since the link for the customer site to the network now extends only as far as the Gateway, Neighbour Unreachability Detection on the part of customer devices is similarly limited in scope.
This memo includes no request to IANA.
No change from [RFC5969].
| [RFC5969] | Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. |
| [RFC5569] | Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. |