INTERNET-DRAFT Z. Xiaoyu Intended Status: Informational France Telecom Expires: November 27, 2010 May 26, 2010 Aplusp Lite - A light weight aplusp approach draft-xiaoyu-aplusp-lite-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License 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 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. Z. Xiaoyu Expires November 27, 2010 [Page 1] INTERNET DRAFT aplusp-lite May 26, 2010 Abstract This document proposes a solution aimed at providing IPv4 continuity in IPv6 environment. The proposed solution is expected to alleviate the public IPv4 depletion problem while maximize the benefits from IPv6 deployment, and meet the desired service availability and reliability with affordable cost. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IGF Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Outgoing traffic process . . . . . . . . . . . . . . . . . 7 5.2. Incoming traffic process . . . . . . . . . . . . . . . . . 7 5.3. Fragmentation process . . . . . . . . . . . . . . . . . . . 7 5.4. Load balance and failover . . . . . . . . . . . . . . . . . 7 6. HGF Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Outgoing traffic processing . . . . . . . . . . . . . . . . 8 6.2. Incoming traffic processing . . . . . . . . . . . . . . . . 8 6.3. Fragmentation processing . . . . . . . . . . . . . . . . . 9 6.4. Traffic optimization . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . 10 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Z. Xiaoyu Expires November 27, 2010 [Page 2] INTERNET DRAFT aplusp-lite May 26, 2010 1. Introduction It is commonly agreed that the public IPv4 address depletion is inevitable, and the daily updated current consumption of public IPv4 address is available at http://www.potaroo.net/tools/ipv4/index.html. Although IPv6 is regarded as the ultimate solution for this problem, the current Internet is far from IPv6 dominant. To support the huge amount of IPv4 legacies, many solutions, typically aplusp [I- D.boucadair-port-range][I-D.ymbk-aplusp] and ds-lite [I-D.ietf- softwire-dual-stack-lite]are proposed to provide IPv4 continuity over IPv6 network. However, both kinds of solutions are facing challenges in terms of complexity, reliability, functionality, routing optimization and expense in large scale deployment. By keeping the port range based public IPv4 sharing principle in aplusp and employing a ds-lite flavor mapping table which records specific relationship between shared IPv4 address block and delegated IPv6 prefix, this document proposes a light weight solution called aplusp-lite, to meet operational requirements for network operators, particularly the broadband network service providers. 1.1. Terminology 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]. 2. Overview There are 2 elements in the aplusp-lite solution: HGF and IGF, as depicted in Figure 1: Z. Xiaoyu Expires November 27, 2010 [Page 3] INTERNET DRAFT aplusp-lite May 26, 2010 +----------------------------------------------+ | +-------+ +---------+ | | | host | | host | | | +---+---+ | +-----+ | | | | | | HGF | | | | V | +-----+ | | | +--------------+ +----+----+ | | | home gateway | | | | | +-----+ | | | | | | HGF | | | | | | +-----+ | | | | +------+-------+ | | | | | | | ->IPv4-in-IPv6 Tunnel<- | | | | | | V V | | ----------------------------- | | / ISP IPv6 network \ | | | +-----+ | | | | | IGF | | | | \ +-----+ / | | --------------+-------------- | | | | | V | | +------------------------+ | | | IPv4/IPv6 Internet | | | +------------------------+ | +----------------------------------------------+ Figure 1 Aplusp-lite architecture - Home Gateway Function (HGF): This function resident in the customer's home gateway or in any other networked node in case no home gateway is present. - Interconnection Gateway Function (IGF): This function is the interconnection point of the ISP IPv6 network and IPv4 Internet. The principle behinds aplusp-lite is very simple: - A public IPv4 address is shared by multiple customers with different allocated TLIs. - Network Address Translation (NAT) and Application Layer Gateway (ALG) functions may be performed by the HGF, for IPv4 to IPv4 communications. - IPv4 traffic is encapsulated in IPv6 and exchanged between HGF and IGF through IPv4-in-IPv6 encapsulation, with the 'Next Header' field of the basic IPv6 header set to 4. - IGF forwards IPv4 traffic destined to the shared public IPv4 Z. Xiaoyu Expires November 27, 2010 [Page 4] INTERNET DRAFT aplusp-lite May 26, 2010 address to appropriate HGF by consulting transport layer information. 3. Tunneling IPv4-in-IPv6 tunneling MUST be done in accordance to [RFC2473] and [RFC4213]. Traffic classes ([RFC2474]) from the IPv4 headers SHOULD be carried over to the IPv6 headers and vice versa. 4. Addressing All IPv6 addresses mentioned in this document MUST conform to [RFC4787]. The network service provider MUST correlate its public IPv4 sharing plan with IPv6 allocation policy for aplusp-lite customers, as depicted in Figure 2. +---------------+----------+---------------------+ | IPV4-POOL | TLI-MASK | PREFIX | +---------------+----------+---------------------+ | 192.0.2.0/24| 6| 2001:DB8::/42| +---------------+----------+---------------------+ | | | | +---------------+----------+---------------------+ Figure 2 IPv4/IPv6 address allocation mapping - IPV4-POOL is the public IPv4 address pool to be shared by aplusp-lite customers. In this document the first address of this pool is the network address. - TLI-MASK is the mask used for dividing the transport layer identifiers associated with each public IPv4 address in the IPV4-POOL into equal sized none-overlapping sets. These sets are then assigned to different customers to share the same public IPv4 address. In this document the first TLI set is the set started with 0. - PREFIX is the IPv6 address space taken from the one allocated to a given Service Provider, and is to be delegated to customers with aplusp-lite device. The rationale behind Figure 2 is: If the M'th TLI set of the N'th IPv4 address in IPV4-POOL is allocated to a customer, the IPv6 prefix [PREFIX][N][M], represented as DG-PREFIX hereafter, must be assigned to that customer accordingly, and vice versa. In the DG-PREFIX, both N and M start counting from 0, N occupies the same number of bits as the variable bits of the IPv4 address in the Z. Xiaoyu Expires November 27, 2010 [Page 5] INTERNET DRAFT aplusp-lite May 26, 2010 pool, and M occupies the same number of bits as the value of TLI- MASK. DG-PREFIX is then able to be deduced from IPv4 address and TLI information, which is essential for the IGF to determine the IPv6 address of the appropriate customer where the IPv4 packet under processing should be forwarded to. The DG-PREFIX should be shorter than or equal to 64. In the former case, all 1s are appended to the DG-PREFIX to form a 64 bits prefix. The 64 bits prefix is dedicated used for aplusp-lite IPv4-in-IPv6 encapsulation, represented as AL-PREFIX. The IPv6 address of the tunnel endpoints used for IPv4-in-IPv6 encapsulation, represented as ENC-ADDR hereafter, is formed through appending any valid IPv6 interface identifier to the calculated AL- PREFIX. It is recommended to use a randomized identifier generated through the algorithm defined in [RFC4941], represented as RAND-IID hereafter. The final ENC-ADDR format is depicted in Figure 3. 0 63 127 +--------+---+---+- - - - -+---------------------+ | PREFIX | N | M | All 1s | RAND-IID | +--------+---+---+- - - - -+---------------------+ | DG-PREFIX | | +----------------+---------+ | | AL-PREFIX | | +--------------------------+---------------------+ | ENC-ADDR | +------------------------------------------------+ Figure 3 IPv6 address used for encapsulation Take the entry provided in Figure 2 as example, if the TLI set [1024- 2047] along with the IPv4 address 192.0.2.2 is allocated to an aplusp-lite customer, the IPv6 address used for IPv4-in-IPv6 encapsulation can be calculated as following: - 192.0.2.2 is the 3rd address of the IPV4-POOL, so N=2 and occupies 8 bits (the least significant 8 bits of the IPv4 address in this pool are variable). - TLI set [1024-2047] is the 2nd set associated with the address, so M=1 and occupies 6 bits (TLI-MASK is 6 bits). - Append 8 bits with value 2 and 6 bits with value 1 to the PREFIX (2001:DB8::/42), the final prefix DG-PREFIX is 2001:DB8:0000:8100::/56 (56=42+8+6). - Add 8 bits 1s padding to DG-PREFIX, the final AL-PREFIX is 2001:DB8:0000:81FF::/64. - Add the randomized interface identifier to AL-PREFIX, the ENC- ADDR is calculated as 2001:DB8:0000:81FF:[RAND-IID]. Z. Xiaoyu Expires November 27, 2010 [Page 6] INTERNET DRAFT aplusp-lite May 26, 2010 5. IGF Behavior IGF is the interconnection point of ISP IPv6 network and the IPv4 Internet, and is responsible for delivering the IPv4 traffic originated from the HGF to the IPv4 Internet (outgoing) through IPv4 connectivity, and for delivering the IPv4 traffic destined to the shared public IPv4 address pool to appropriate HGF (incoming) through IPv4-in-IPv6 tunnel. A dedicated IPv6 prefix, represented as IGF-PREFIX hereafter, should be associated with an IGF. IPv6 traffic destined to this prefix should be routed to the associated IGF through IPv6 routing. The IPv6 address used to identify the IGF as IPv4-in-IPv6 tunnel end points, represented as IGF-ADDR hereafter, should be formed by appending any valid interface identifier to the IGF-PREFIX, and a randomized one as described in [RFC4941] is recommended. The IGF-ADDR can be provisioned to HGF through Point-to-Point Protocol (PPP) extensions or specific Dynamic Host Configuration Protocol (DHCP) options, in the similar way as [I-D.ietf-softwire-ds- lite-tunnel-option] and [I-D.boucadair-pppext-portrange-option]. 5.1. Outgoing traffic process IPv4 traffic originated from HGF is encapsulated using IPv4-in-IPv6 scheme and forwarded to IGF through IPv6 transfer capabilities. The IGF de-capsulates the encapsulated packet and forward it through IPv4. 5.2. Incoming traffic process Upon receipt of an IPv4 packet destined to a shared IPv4 address pool and for which the IGF is responsible, the IGF will encapsulate it into IPv6 and deliver it through IPv6 connectivity. The source IPv6 address used for encapsulation is set to IGF-ADDR, and the destination is set to the ENC-ADDR that had been calculated by using the destination address and TLI contained in the IPv4 packet and through the algorithm described in Section 5. 5.3. Fragmentation process It should be noted that the TLI information is only contained in the first fragment of fragmented packets, and the IGF must record this information for processing subsequent fragments, like what a traditional NAT [RFC3022] will do. 5.4. Load balance and failover Z. Xiaoyu Expires November 27, 2010 [Page 7] INTERNET DRAFT aplusp-lite May 26, 2010 Since the mapping table provided in Figure 2 is statically defined and can be provisioned to all IGFs, a session can be handed over from one IGF to another without disruption. Each IGF can use its own IGF-PREFIX and announce itself as on the forwarding path of that prefix in IPv6 routing. The IGF can also announce itself as on the forwarding path of other IGF-PREFIX(es), but with higher routing metrics. The IPv6 routing is then able to forward the IPv4-in-IPv6 encapsulated packets to the appropriate IGF base on the destination IPv6 address and the routing metrics, thus load balancing can be achieved in a pre-defined manner. In case the IGF with lower metrics for an IGF-PREFIX is failed, the IPv6 routing will choose another one automatically, thus failover can be achieved also. All the IGFs can use the same IGF-PREFIX even with the same metrics, and let the IPv6 routing to choose appropriate one at per packet basis, thus to achieve pure routing based load balance and failover. It should be noted that in this case all the fragments of a fragmented packet should be processed by the same IGF, to avoid undesired retransmission. A function node dedicated for fragment processing can be employed to simplify the implementation. 6. HGF Behavior In all aplusp based solutions including the one proposed in this document, both the shared public IPv4 address and available TLI set are provisioned to HGF, through Point-to-Point Protocol (PPP) extensions defined in [I-D.boucadair-pppext-portrange-option], or specific DHCP options. The HGF is responsible for performing NAT and/or ALG functions, as well as supporting NAT Traversal mechanisms such as [UPnP-IGD]. The HGF MAY also discover the IGF-PREFIX through DNS queries, as defined in [I-D.wing-behave-learn-prefix], and the IGF-ADDR is calculated from the discovered IGF-PREFIX through the same algorithm as IGF. 6.1. Outgoing traffic processing For IPv4-to-IPv4 outgoing communications, the HGF performs NAT using the IPv4 address and TLI set assigned to it, encapsulates the resulting IPv4 packet into an IPv6 one, and delivers it through IPv6 connectivity. The destination IPv6 address used for encapsulation should be set to IGF-ADDR. 6.2. Incoming traffic processing Upon receipt of IPv4-in-IPv6 packet destined to the ENC-ADDR of this Z. Xiaoyu Expires November 27, 2010 [Page 8] INTERNET DRAFT aplusp-lite May 26, 2010 HGF, the HGF de-capsulates the packet and processes the resulting IPv4 packet as a traditional NAT [RFC3022], and finally delivers it using IPv4 to the appropriate internal host. 6.3. Fragmentation processing It should be noted that the IPv4-in-IPv6 encapsulation normally add 40 bytes overload (basic IPv6 header) to the original packet, thus the result IPv6 packet may exceed the Maximum Transmission Unit (MTU) of the transmission path. To avoid unnecessary fragmentation, the HGF should adjust the application perceived MTU through participating Path MTU Discovery (PMTUD) [RFC1191] or modifying MSS parameter in TCP session setup stage. 6.4. Traffic optimization The IPv4/IPv6 address allocation mapping table as provided in TABLE I may also be provisioned to HGF. In this case the ENC-ADDR should be used as destination IPv6 address in encapsulation, and the IGF-ADDR is used only if the destination IPv4 address does not fall in any pool of the table. By employing this mechanism the IPv4-to-IPv4 communications between aplusp-lite customers can be processed without the intervention of a IGF in the path. 7. Security Considerations This document has the same security consideration as [I-D.ymbk- aplusp]. 8. IANA Considerations This document makes no request to IANA. 9. Conclusions Based on the aplusp concept, this document proposed a new approach of delivering traffic destined to a shared public IPv4 address to the appropriate customer. The proposed approach only maintains few static states in the operator network, and is able to rely on IPv6 routing to achieve load balancing, failover and traffic path optimization. This approach allows for a high performance and reliable network service at low cost compared to NAT-based solutions. Furthermore, by keeping the NAT and ALG in customer premises, the end-to-end nature of Internet is preserved at customer basis, which can provide better compatibility to existing applications. It should be noted that the proposed approach brings some links between IPv4 and IPv6 addressing, which is somehow inflexible, and Z. Xiaoyu Expires November 27, 2010 [Page 9] INTERNET DRAFT aplusp-lite May 26, 2010 special cautions should be taken to avoid operational problems when designing the public IPv4 sharing plan and IPv6 allocation policy. 10. References 10.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.boucadair-port-range] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture", draft-boucadair-port-range-02 (work in progress), July 2009. [I-D.ymbk-aplusp] Maennel, O., Bush, R., Cittadini, L., and S. Bellovin, "The A+P Approach to the Broadband Provider IPv4 Address Shortage", draft-ymbk-aplusp-00 (work in progress), October 2008. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, Y., and R. Bush, "Dual- stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-01 (work in progress), July 2009. 10.2. Informative References [RFC1191] J. Mogul and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2473] Conta, A. and Derring, S., "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2474] Nichols, K., Blake, S., et, al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [RFC3022] P. Srisuresh and K. Egevang: "Traditional IP Network Address Translator (Traditional NAT)", RFC3022, January 2001. [RFC4213] Nordmark, E. and Gilligan, R., "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC4213, October 2005. [RFC4787] Jennings, C. and Audet, F. (Editors), "Network Address Z. Xiaoyu Expires November 27, 2010 [Page 10] INTERNET DRAFT aplusp-lite May 26, 2010 Translation (NAT) Behavioral Requirements for Unicast UDP", RFC4787, January 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [I-D.boucadair-dhcpv6-shared-address-option] Boucadair, M., Levis, P., Grimault, J., Savolainen, T., and G. Bajko, "Dynamic Host Configuration Protocol(DHCPv6) Options for Shared IP Addresses Solutions", draft-boucadair-dhcpv6-shared- address-option-00 (work in progress), May 2009. [I-D.ietf-softwire-ds-lite-tunnel-option] D. Hankins and T. Mrugalski: "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Options for Dual-Stack Lite", http://tools.ietf.org/html/draft-ietf-softwire-ds-lite- tunnel-option-02, March 2, 2010. [I-D.boucadair-pppext-portrange-option] Boucadair, M., Levis, P., Grimault, J., and A. Villefranque, "Port Range Configuration Options for PPP IPCP", draft-boucadair- pppext-portrange-option-01 (work in progress), July 2009. [I-D.dhankins-softwire-tunnel-option] Hankins, D., "Dynamic Host Configuration Protocol Option for Softwires", draft- dhankins-softwire-tunnel-option-01 (work in progress), August 2008. [I-D.bajko-v6ops-port-restricted-ipaddr-assign] Bajko, G. and T. Savolainen, "Port Restricted IP Address Assignment", draft-bajko-v6ops-port-restricted-ipaddr-assign-01 (work in progress), October 2008. [I-D.wing-behave-learn-prefix] D. Wing: "Learn the IPv6 Prefix of a Network's IPv6/IPv4 Translator", http://tools.ietf.org/html/draft-wing-behave-learn- prefix-04, October 26, 2009. [UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway Device Standardized Gateway Device Protocol", September 2006, . Author's Addresses Xiaoyu ZHAO France Telecom 2 Science Institute South Rd., Haidian District, Beijing, 100190 China Email: Xiaoyu.zhao@orange-ftgroup.com Z. Xiaoyu Expires November 27, 2010 [Page 11] INTERNET DRAFT aplusp-lite May 26, 2010 Z. Xiaoyu Expires November 27, 2010 [Page 12]