Internet Engineering Task Force T. Tsou Internet-Draft C. Zhou Intended status: Standards Track T. Taylor Expires: June 6, 2011 Huawei Technologies Q. Chen China Telecom December 8, 2010 "Gateway-Initiated" 6rd draft-tsou-softwire-gwinit-6rd-02 Abstract This document proposes a modification to the 6rd deployment model for IPv6. 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 uses tunnels from operator-owned "6rd Gateways" collocated with the operator's IPv4 network edge. The tunnels may be provisioned or automatic. The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. It also allows the 6rd prefix portion of the prefixes delegated to customer devices to be longer than can generally be achieved by basic 6rd. The gateway initiated 6rd model reuses the protocol defined in RFC 5969. Status of this Memo 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 6, 2011. Copyright Notice Tsou, et al. Expires June 6, 2011 [Page 1] Internet-Draft "Gateway-Initiated" 6rd December 2010 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, as 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 are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 3.1. 6rd Prefix Delegation . . . . . . . . . . . . . . . . . . 6 3.2. Troubleshooting and Traceability . . . . . . . . . . . . . 7 3.3. Address Selection . . . . . . . . . . . . . . . . . . . . 8 3.4. Gateway Initiated 6rd Configuration . . . . . . . . . . . 8 3.4.1. Configuration For IPv6-in-IPv4 Tunneling . . . . . . . 8 3.4.2. Configuration For Other Tunneling Technologies . . . . 8 3.5. Transition Considerations . . . . . . . . . . . . . . . . 9 3.6. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . 9 3.7. Security Considerations . . . . . . . . . . . . . . . . . 9 3.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 9 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Normative References . . . . . . . . . . . . . . . . . . . 9 4.2. informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Tsou, et al. Expires June 6, 2011 [Page 2] Internet-Draft "Gateway-Initiated" 6rd December 2010 1. Introduction 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 | Relay | | 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. As a consequence, the routers in the IPv4 network have to carry a route for every customer site. In a large network, this can lead to very large routing tables. Further, the need to provision an IPv4 address for every 6rd user 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. 1.1. 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 [RFC2119]. 1.2. Terminology 6rd prefix As in [RFC5969], an IPv6 prefix selected by the service provider for use by a 6rd domain. customer device Either a single customer-owned router serving as the interface between the customer network and the provider network, or, in the absence of such a device, an individual host in the customer network. 6rd Gateway A device functioning as a gateway initiated 6rd tunnel endpoint, collocated with the provider IPv4 network edge. A typical 6rd Gateway has virtual or point-to-point links to many customer devices, an interface to the provider IPv4 network, and a virtual 6rd interface. Tsou, et al. Expires June 6, 2011 [Page 3] Internet-Draft "Gateway-Initiated" 6rd December 2010 gateway initiated 6rd delegated prefix The prefix calculated by the network for delegation to a customer device, obtained by combining the 6rd prefix, a 6rd Gateway Identifier used for routing from the 6rd Border Relay to the serving 6rd Gateway, and a Gateway-scoped customer device identifier. Like the 6rd delegated prefix in [RFC5969], this prefix can be considered logically equivalent to a DHCPv6 IPv6 delegated prefix [RFC3633]. 6rd domain As in [RFC5969], with the substitution of the 6rd Gateway for the 6rd CE as a component of the domain. 6rd Border Relay (BR) As in [RFC5969]. 6rd virtual interface As in [RFC5969], with the substitution of the 6rd Gateway for the 6rd CE. 6rd Gateway IPv4 address The IPv4 address configured on the 6rd Gateway as part of the provider network. This address may be global or private [RFC1918] within the 6rd domain. If IPv6- in-IPv4 tunnels are used, this address is used in compressed form as the Gateway Identifier portion of the gateway initiated 6rd delegated prefix. 2. Problem Statement Consider a fixed broadband 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 dual-stack, it will be natural for that equipment to request IPv4 addresses, and pretty well impossible for the operator to avoid assigning them. However, the operator has an Tsou, et al. Expires June 6, 2011 [Page 4] Internet-Draft "Gateway-Initiated" 6rd December 2010 opportunity to avoid assigning IPv4 addresses to customer devices running IPv6 only, if some other means is available for routing IPv6 traffic through the IPv4 network to and from that site. 3. Proposed Solution For basic 6rd, the 6rd-CE described in [RFC5969] initiates a 6-in-4 tunnel to the Border Relay 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 Gateway to perform this task. The functions of the 6rd Gateway are: o to generate and allocate gateway initiated 6rd delegated prefixes for IPv6-capable customer devices; o to forward outgoing IPv6 packets through a tunnel to a Border Relay, which extracts and forwards them to an IPv6 network as for 6rd; o to extract incoming IPv6 packets tunneled from the 6rd Border Relay and forward them to the correct user device. In the proposed solution, there is only one tunnel between each 6rd Gateway and the Border Relay, which greatly reduces the number of tunnels the Border Relay 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 6rd Gateway uses layer 2. +-------+ +---------------------+ +---------+ +-----+ | | | | | | |IPv6 | | | +---------+ IPv4 +--------+ | IPv6 | |Cust |_|Access |_| 6rd GW | Metro | Border |_| core | |Dev | |network| |(IP edge)| network | Relay | | network | +-----+ | | +---------+ +--------+ | | | | | | | | +-------+ +---------------------+ +---------+ Figure 2: Gateway Initiated 6rd At the IP Edge The elements of the proposed solution are these: Tsou, et al. Expires June 6, 2011 [Page 5] Internet-Draft "Gateway-Initiated" 6rd December 2010 o IPv6 packets are tunneled between the 6rd Gateway and the 6rd Border Relay. The tunnel may be provisioned or may be an automatic IPv6-in-IPv4 tunnel as in basic 6rd, depending on the operator's requirements. Provisioned tunnels may cost less in smaller-scale deployments, while automatic tunneling becomes preferable as the number of customer devices and hence 6rd Gateways in a 6rd domain becomes large. o The IPv6 prefix delegated to the customer device contains a Gateway identifier which the 6rd Border Relay can map to a tunnel connecting to the serving 6rd Gateway. In the case of IPv6-in- IPv4 tunnels, this identifier is the compressed 6rd Gateway IPv4 address, and the Border Relay uses the expanded address as the IPv4 destination address for the encapsulated packets. o The IPv6 prefix delegated to the customer device also contains an index that is unique to that customer device. As a result, the 6rd Gateway can map the IPv6 destination address uniquely to the Layer 2 address of the customer device, either on the basis of the complete routing prefix or by extracting the the customer device index portion of that prefix. Incidentally to this, the 6rd Gateway serves as an IPv4 aggregation point for all of the customer sites it serves. 3.1. 6rd Prefix Delegation Referring back to Figure 2, prefix delegation to the customer equipment occurs in the normal fashion through the Gateway/IP edge, using SLAAC or DHCPv6. Each delegated prefix MUST contain a 6rd prefix valid for the 6rd domain, the Gateway Identifier for the 6rd Gateway, and an index that identifies the specific customer device. Figure 3 shows the structure of a complete IPv6 address based on the gateway initiated 6rd delegated prefix, in a form analogous to Figure 1 of [RFC5969]. | p bits | o bits | n bits |m bits | 128-p-o-n-m bits | +----------------+------------+---------+-------+------------------+ | | Gateway |Customer | | | | 6rd prefix | identifier | device |subnet | interface ID | | | | index | ID | | +-----------+------------+--------------+--------------------------+ |<------ GI 6rd delegated prefix ------>| Figure 3: Gateway Initiated 6rd Delegated Prefix The 6rd Gateway is responsible for generating the 6rd delegated Tsou, et al. Expires June 6, 2011 [Page 6] Internet-Draft "Gateway-Initiated" 6rd December 2010 prefix. The 6rd prefix portion is a preconfigured value (see Section 3.4). The 6rd Gateway MUST append to this its configured Gateway Identifier. In the case of IPv6-in-IPv4 tunneling, this identifier will be the low-order bits of its IPv4 address on the virtual link between itself and the Border Relay, where the number of bits is based on the length of the IPv4 address mask for 6rd Gateway addresses within the 6rd domain. Finally, the 6rd Gateway MUST append an index value which is unique for each customer device to which the 6rd Gateway delegates a prefix. The length of the index value is configured on the 6rd Gateway (see Section 3.4). The index value MAY be assigned permanently or MAY be assigned only for the period during which the customer device is connected to the network. With the present proposal, there is no concern about IPv4 address lifetimes, as there is with basic 6rd. The Gateway/IP edge will be assigned a permanent value for its Gateway identifier (e.g., IPv4 address), using the operator's normal network provisioning processes. However, since the customer device is never assigned an IPv4 address, AAA has to be modified to use the delegated IPv6 prefix to track the customer. 3.2. Troubleshooting and Traceability The operator can apply the normal tools for troubleshooting for the portion of the path between the 6rd Gateway and the 6rd Border Relay, depending on the tunneling technology that has been deployed. Since no IPv4 address is assigned to individual customer devices, however, IPv4-based tools cannot be used to identify debug problems extending beyond the 6rd Gateway to the customer device. If the customer device supports IPv6 anycast, it is possible to test end-to-end connectivity from the 6rd BR using IPv6 Echo requests and responses. If the device does not support IPv6 anycast, end-to-end testing requires knowledge of a specific IPv6 address that the customer device has assigned to its interface with the network. For the purpose of such testing, the 6rd Border Relay needs an IPv6 address that it can identify as its own either in an ICMPv6 echo request that it receives or in an echo response from the customer device. The 6rd Gateway must be able to select the tunnel to the correct 6rd BR based on this address. For IPv6-in-IPv4 tunneling, these requirements can be met in the same way as in [RFC5969] if the 6rd Gateways and Border Relays in a 6rd domain share the same IPv4 address space and a common mask. For other tunneling technologies, IPv6 prefixes for the BRs can be generated using the same principles as for the prefixes assigned to customer devices provided that the BRs are assigned identifiers within the Gateway Identifier numbering space. The 6rd Gateways need to be able to map from Gateway Identifiers to the corresponding BR tunnels. Tsou, et al. Expires June 6, 2011 [Page 7] Internet-Draft "Gateway-Initiated" 6rd December 2010 3.3. Address Selection No change from [RFC5969]. 3.4. Gateway Initiated 6rd Configuration 3.4.1. Configuration For IPv6-in-IPv4 Tunneling For IPv6-in-IPv4 tunneling, Section 7 of [RFC5969] applies, except that the 6rd Gateway rather than the 6rd CE is configured with the IPv4MaskLen, 6rdPrefix, 6rdPrefixLen, and 6rdBRIPv4Address. In addition to these values, each 6rd Gateway MUST be configured with CustDevIndexLen, the number of bits used to represent the customer device index portion of the gateway initiated 6rd delegated prefix. The IPv4MaskLen is redefined to be the number of high-order bits that are identical across all IPv4 addresses assigned to 6rd Gateways in the 6rd domain. No special configuration of customer equipment, in particular, customer edge routers, is required. Hence the 6rd DHCPv4 option is inapplicable. Border Relay configuration is unchanged from [RFC5969]. The discussion of Neighbour Unreachability Detection in [RFC5969] is inapplicable. The considerations on IPv6 in IPv4 encapsulation in Section 9 of [RFC5969] apply with the substitution of the 6rd Gateway for the 6rd CE. 3.4.2. Configuration For Other Tunneling Technologies For other tunneling technologies, the following differences apply relative to the previous section. o IPv4MaskLen is generalized to GWIDLen, defined as the number of bits in the Gateway Identifier portion of the delegated prefix. o Each 6rd Gateway is configured with its own Gateway Identifier value. o For troubleshooting purposes (see Section 3.2), each 6rd Border Relay is configured either with a complete IPv6 prefix the use of which is restricted to the 6rd domain, or with a Gateway Identifier value that it can use to construct such a prefix. Correspondingly, the 6rd Gateways are configured with mappings Tsou, et al. Expires June 6, 2011 [Page 8] Internet-Draft "Gateway-Initiated" 6rd December 2010 between the BR prefixes (or their Gateway Identifier portion) and the tunnels connecting to them. 3.5. Transition Considerations No change from [RFC5969]. This technique can co-exist with dual- stack operation at the customer site, assuming that the 6rd Gateway is configured as the default outgoing gateway for IPv6 traffic. 3.6. IPv6 Address Space Usage The discussion of Section 11 of [RFC5969] is modified with the following example. In essence, the restriction of IPv4 addressing to the 6rd Gateways rather than individual customer devices allows for a greater degree of address compression, even if some of that is taken back by the need to allocate bits for a customer device index. 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 6rd prefix can be 29 bits for a /56 delegated prefix, or 21 bits if /48 delegated prefixes need to be allocated. 3.7. Security Considerations No change from [RFC5969]. 3.8. IANA Considerations This memo makes no request of IANA. 4. References 4.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. Tsou, et al. Expires June 6, 2011 [Page 9] Internet-Draft "Gateway-Initiated" 6rd December 2010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. 4.2. informative References [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. Authors' Addresses Tina Tsou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: tena@huawei.com Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: cathyzhou@huawei.com Tsou, et al. Expires June 6, 2011 [Page 10] Internet-Draft "Gateway-Initiated" 6rd December 2010 Tom Taylor Huawei Technologies 1852 Lorraine Ave.t Ottawa, Ontario K1H 6Z8 Canada Phone: Email: tom111.taylor@bell.net Qi Chen China Telecom 109, Zhongshan Ave. West, Tianhe District, Guangzhou 510630 P.R. China Phone: Email: chenqi.0819@gmail.com Tsou, et al. Expires June 6, 2011 [Page 11]