Internet Engineering Task Force T. Tsou Internet-Draft C. Zhou Intended status: Standards Track T. Taylor Expires: April 19, 2011 Huawei Technologies Q. Chen China Telecom October 16, 2010 "Gateway-Initiated" 6rd draft-tsou-softwire-gwinit-6rd-00 Abstract This document proposes a modification to the 6rd deployment model for IPv6. This model extends existing access tunnels beyond an operator- owned gateway collocated with the operator's IPv4 network edge to the Border Router. This modification makes it unnecessary to provide IPv4 routes to IPv6 UEs. The gateway serves as an aggregation point for IPv4 routing. 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 April 19, 2011. 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, as they describe your rights and restrictions with respect Tsou, et al. Expires April 19, 2011 [Page 1] Internet-Draft "Gateway-Initiated" 6rd October 2010 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 2. An Alternative Proposal . . . . . . . . . . . . . . . . . . . . 3 2.1. Prefix Delegation . . . . . . . . . . . . . . . . . . . . . 5 2.2. Troubleshooting and Traceability . . . . . . . . . . . . . 6 2.3. Address Selection . . . . . . . . . . . . . . . . . . . . . 6 2.4. Gateway-Initiated 6rd Configuration . . . . . . . . . . . . 6 2.5. Transition Considerations . . . . . . . . . . . . . . . . . 6 2.6. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . 6 2.7. Security Considerations . . . . . . . . . . . . . . . . . . 7 2.8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Normative References . . . . . . . . . . . . . . . . . . . 7 3.2. informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Tsou, et al. Expires April 19, 2011 [Page 2] Internet-Draft "Gateway-Initiated" 6rd October 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 | | UE | | 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. 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. The IPv6 prefix of all the users are the same for one ISP, which is less than 32 bits. In 6RD [RFC5969], the IPv4 address of CPE included in the host's IPv6 address is allocated by ISP. Every host needs an IPv4 address (even if the terminals in the Customer Network are all IPv6) which may bring great pressure of IPv4 address shortage for the operators with the number of broadband subscribers increasing at high speed. 2. An Alternative Proposal To release the pressure of IPv4 address shortage, some ISP starts to provide IPv6 access. The backbone network will first support IPv6 in this case. The metro network is not easily to be upgraded to support IPv6 since many devices need to be modified and there may be some impact to the existing services. This proposal only modifies the IP edge device to provide IPv6 access without changing other network devices in the metro network. The number of IPv4 routes can be drastically reduced if the customer end of the tunnel is moved to the gateway between IPv6 on the customer side and the IPv4 network. There is only one tunnel initiated from each Gateway to the Border Router which greatly reduces the tunnel numbers. There are two possible deployment scenarios. The first, shown in Figure 2, collocates the gateway with Tsou, et al. Expires April 19, 2011 [Page 3] Internet-Draft "Gateway-Initiated" 6rd October 2010 the IP edge, with the IPv4 network immediately beyond. This is the typical placement of the Broadband Network Gateway (BNG) in a fixed broadband network, where 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 An alternative deployment assumes that the IP network closest to the customer site is IPv6, but an IPv4 network further out has to be traversed to reached further IPv6 networks. This is shown in Figure 3. In terms comparable to Figure 2, in this case the metro network is running IPv6, the core network is running IPv4, and the Border Router is needed to pass onto adjacent IPv6 metro networks or IPv6 networks belonging other operators. This deployment has a relatively straightforward solution and is out of scope of the present document. +-------+ +------------+ +--------------+ | | | | | | +-----+ | | +----+ IPv6 | +----+ IPv4 +--------+ |Cust |_|Access |_| IP | Metro |_| GW | core | Border | |site | |network| |edge| network | | | network | Router | +-----+ | | +----+ | +----+ +----+---+ | | | | | | | +-------+ +------------+ +--------------+ | | +-------+ | | Other |__| | IPv6 | |network| +-------+ Figure 3: Gateway-Initiated 6rd Beyond the IP Edge In both deployment scenarios, the Gateway serves as an IPv4 aggregation point for all of the customer sites it serves. Tsou, et al. Expires April 19, 2011 [Page 4] Internet-Draft "Gateway-Initiated" 6rd October 2010 2.1. Prefix Delegation Referring back to Figure 2, prefix assignment to the customer equipment occurs in the normal fashion through the Gateway/IP edge, using either PPPoEv6 or DHCPv6. For the bridged mode CPE, the prefix is delegated in the last 64 bits of IPCPv6 message in PPPoE method or acquired through DHCP Server with the BNG's IPv4 address (or IPv4 address designated by BNG) included in the last 64 bits of the delegated 128 bits IPv6 address. When the CPE is in routed mode, there are two ways to delegate the prefix. The first is to allocate 128 bits IPv6 address to the host and CPE should have the IPv4 address in advance. Another way is to allocate prefix only to the host and the host needs to know the BNG's IPv4 address (or the IPv4 address designated by BNG). In spirit of 6rd, the prefixes contain the 32-bit IPv4 address assigned to the gateway. An example format (derived from the IPv6 unicast address structure [RFC3587]) is shown in Figure 4. +----------------------------------------------------------+ |001 | Global IPv6 | Subnet | Indic | IPv4 addr | Host | | | routing prefix | | | | ID | +----+----------------+--------+-------+-----------+-------+ | 3 | 45 bits |16 bits | N bits| 32 bits | 32 - N| +----------------------------------------------------------+ Figure 4: Suggested Customer Site Address Format The first 64 bits in Figure 4 are as defined in [RFC3587]. The N-bit Indicator field which comes next is defined for operator use. The operator will assign a specific indicator value to designate the customer site address format which includes the IPv4 address of the Gateway/IP edge or the IPv4 address designated by the Gateway/IP edge as shown above. Other indicator values could be used to designate alternative address formats. The indicator field is followed by the 32-bit IP address of the Gateway/IP edge (e.g., the BNG) and then by a host identifier that uses the remaining 32 - N bits. If prefix delegation to the customer site is a concern, one could use the format shown in [RFC5969]. However, this requires a much- shortened global IPv6 routing prefix, and hence a much higher degree of IPv6 route aggregation. That may or may not be practical for a given operator. With the present proposal, there is no concern about DHCPv6 lease times. The Gateway/IP edge will be assigned a permanent IPv4 address, using the operator's normal network provisioning processes. Tsou, et al. Expires April 19, 2011 [Page 5] Internet-Draft "Gateway-Initiated" 6rd October 2010 2.2. Troubleshooting and Traceability The first paragraph of Section 5 of [RFC5969] on traceability applies equally well to the present proposal. The second paragraph, on support of anycast addressing, applies with the substitution of the Gateway for the 6rd CE, and use of the Gateway's assigned IPv4 address to derive the virtual interface address. 2.3. Address Selection No change from [RFC5969]. 2.4. Gateway-Initiated 6rd Configuration It is the Gateway/IP edge rather than the 6rd CE that must be configured with the IPv4MaskLen, 6rdPrefix, 6rdPrefixLen, and 6rdBRIPv4Address. The IPv4MaskLen is redefined to be the number of high-order bits that are identical across all IPv4 addresses assigned to network nodes in the IPv4 network. 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. 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 Gateway/IP edge for the CE. 2.5. Transition Considerations No change from [RFC5969]. 2.6. IPv6 Address Space Usage If the 6rd address format is used, there is no change from Section 11 of [RFC5969]. If the address format follows the example given in Figure 4, the address space usage for 6rd is the same as that used for ordinary IPv6 address assignments. Tsou, et al. Expires April 19, 2011 [Page 6] Internet-Draft "Gateway-Initiated" 6rd October 2010 2.7. Security Considerations No change from [RFC5969]. 2.8. IANA Considerations This memo makes no request of IANA. 3. References 3.1. Normative References [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. 3.2. informative References [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 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 April 19, 2011 [Page 7] Internet-Draft "Gateway-Initiated" 6rd October 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 April 19, 2011 [Page 8]