Internet Engineering Task Force G. Chen Internet-Draft Z. Cao Intended status: Informational China Mobile Expires: April 3, 2012 Oct 2011 Design Principles of a Unified Address Format for 4v6 draft-chen-softwire-4v6-add-format-00 Abstract There are heated discussion over the unified address format and mapping algorithm. In order to converge the solutions, it is desirable to discuss the requirements and principles for the design. This document tries to propose practical principles for 4v6 deployment. The requirements have been derived from this deployment consideration. Based on that, a unified address format has been proposed for easying 4v6 solution implementation . 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 3, 2012. Copyright Notice 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Chen & Cao Expires April 3, 2012 [Page 1] Internet-Draft 4v6-add-format Oct 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Principles for Address Format Design . . . . . . . . . . . 3 2.1. P1: Traffic Classification . . . . . . . . . . . . . . . . 3 2.2. P2: Prefix Delegation Deployment . . . . . . . . . . . . . 4 2.3. P3: Users Privacy Consideration . . . . . . . . . . . . . . 4 2.4. P4: Stateless Behaviour . . . . . . . . . . . . . . . . . . 4 2.5. P5: Coexisting Cases . . . . . . . . . . . . . . . . . . . 4 2.6. P6: Friendly to Network Management . . . . . . . . . . . . 5 3. Requirements for Address Format Design . . . . . . . . . . . . 5 4. Address Format Proposals . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Chen & Cao Expires April 3, 2012 [Page 2] Internet-Draft 4v6-add-format Oct 2011 1. Introduction Currently,4v6 stateless technologies have attracted growing efforts in the IETF communities. The motivation draft [I-D.ietf-softwire-stateless-4v6-motivation] has been formally approved as Softwires WG documents. Several drafts on solution set have been proposed to fit into the 4v6 stateless designing objectives. There is a strong desirable voice to seek a unified address presentation converging the efforts to provide consolidated mapping baseline for either 4v6 encapsulation or 4v6 translation solutions. This draft tries to document some analysises on several principles of unified address design depending on the practical deployment consideration, which is helping to deduce rational address format for 4v6 solutions. A proposed address format would not only facilitate implementation of Encap/Translation, but also meet the demands from potential deployment cases. We believe that only by figuring out the requirements can the group converges on the choice of different solutions. 2. The Principles for Address Format Design Regarding the solution of 4v6 stateless, the community has granted to investigate encap/decap and translation for different use cases. From algorithm perspectives, it could share one common mapping rules but different data packaging. A new designed solutions should not impact customary behaviour on existing network nodes, thereby below principles should be applied for both encapsulation and translation. 2.1. P1: Traffic Classification Usually, operators adopt traffic classification to ensure service quality for different classes of customers. This feature is also helpful for user behavior monitoring and security protection. for example, DIA (Dedicated Internet Access) has been provided by operators for corporations to cater for their Internet communications needs. Service is made possible by means of the edge router features and key systems, like ACL(Access List Control) to classify different traffic by identifying IP Source/Destination. In order to take that fly, five tuples should be identified from IP header and UDP/TCP header. Currently, it has very well supporting in IPv4. All vendors are delivering or committed to support that feature for IPv6. According the situation we have, 4v6 solution should support this feature on IPv6 plane. Chen & Cao Expires April 3, 2012 [Page 3] Internet-Draft 4v6-add-format Oct 2011 As for decrease additional investment and opex required over native IPv6, it is desirable to identify a user based on the first 64 bits. 2.2. P2: Prefix Delegation Deployment Prefix delegation is an important feature both for broadband and mobile network. In mobile network, Prefix delegation is introduced in 3GPP network in Release 10. A UE (CPE) obtains IPv6 prefix from the mobile network. It then initiates DHCPv6 for prefix delegation. Such deployment feature requires flexibilities of 4via6 mapping algorithm allowing the variable length of IPv6 prefix assigned to CE for deriving IPv4 information. This also implicitly means 4v6 nodes only can acquire provisioning parameters from delegated IPv6 prefix. 2.3. P3: Users Privacy Consideration User privacy should be taken into address format designing. RFC4941[RFC4941] has already expressed the concern associated with the embedding of non-changing interface identifiers within IPv6 addresses.Changing the interface identifier over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. Considering that, it is expected that IID should as free as possible to allow this security improvement taken place. 2.4. P4: Stateless Behaviour 4v6 address format should serve for stateless processing purposes. Communications inside 4v6 domain could take an advantage of pre- configured parameters and respective algorithm doing stateless mapping both for source and destination address. However, there is no referable parameter for destination addresses when a 4v6 node has a communication with a node outside 4v6 domain. In this case, there should be a way to express a destination IPv4 address explicitly in corresponding translated IPv6 address. 2.5. P5: Coexisting Cases 4v6 solutions(i.e. encapsulation and translation) would not only coexist with each other, but also can harmonize with other deployment cases. Here lists some coexisting cases. (Note: more coexisting cases are expected to be investigated in future.) o Case 1: Coexisting between 4v6 encapsulation and 4v6 translation o Case 2: Coexisting between 4v6 translation and NAT64 (Single Translation) Chen & Cao Expires April 3, 2012 [Page 4] Internet-Draft 4v6-add-format Oct 2011 o Case 3: Coexisting between 4v6 solutions and SLAAC For the case 1, the different data packaging could naturally distinguish whether received data is encapsulated or translated by inspecting "Next Header" filed in IP header. For the case 2, an address in 4v6 translation should consider to specify a dedicated tag so as to compatible with rfc4941 and differentiate a data flow, which is undergoing single translation processing(i.e. normative NAT64 processing). For the case 3, 4v6 should allow CPE performing SLAAC for connected dual-stack nodes to synthesize IPv6 address. Afterwards, native IPv6 communications could get along with the 4v6 session. A special tag should be used for distinguishing 4v6 packets from other IPv6 packet whose destination start with CPE IPv6 prefixes. 2.6. P6: Friendly to Network Management Besides the end-2-end communication, the address format should be designed in a way that is also friendly to the network manangement plane. Examples for the management plane requirements include the ability to identify different users and the compatible with the address assignment techniques in the domain. In 3GPP network, for example, only the IPv6 prefix is assigned to the devices, used to identify different users. And one family address managment plane is better than two, namly the operating platform does not need to manage both IPv4 and IPv6. But since only IPv6 prefix is assigned, the management plane is defaultly conducted only via IPv6. 3. Requirements for Address Format Design Above principles are trying to provide a guidance to derive the requirements for address format design. Since there are distinct data processing regarding encapsulation and translation solutions, below takes two tables to deduce requirements respectively. Chen & Cao Expires April 3, 2012 [Page 5] Internet-Draft 4v6-add-format Oct 2011 +----------------------------------------------------------------+ | | CE--CE | CE--BR | +----+----------------------------+------------------------------+ | | source | destination | source | destination | +----+----------------------------+------------------------------+ | P1 |inspecting IPv6 address and port information in IPv6 header| +----+----------------------------+------------------------------+ | P2 |variable IPv6| N/A |variable IPv6 | N/A | | | length | | length | | +----+----------------------------+------------------------------+ | P3 | IID should compatible with rfc4941 | N/A | +----+-------------------------------------------+---------------+ | P4 | N/A | inserting IPv4| | | | address in IID| +----+-------------------------------------------+---------------+ | P5 | inserting a tag to indicate 4v6 translation | +----+-----------------------------------------------------------+ Table 1: Requirements for Address Format in 4v6 Translation +----------------------------------------------------------------+ | | CE--CE | CE--BR | +----+----------------------------+------------------------------+ | | source | destination | source | destination | +----+----------------------------+------------------------------+ | P1 | padding additional information in lower 64 bits | +----+----------------------------+------------------------------+ | P2 |variable IPv6| N/A |variable IPv6 | N/A | | | length | | length | | +----+----------------------------+------------------------------+ | P3 | Somewhat contradictory with P1 | +----+-------------------------------------------+---------------+ | P4 | N/A | inserting IPv4| | | | address in IID| +----+-------------------------------------------+---------------+ | P5 | inserting a tag to indicate 4v6 session | +----+-----------------------------------------------------------+ Table 2: Requirements for Address Format in 4v6 Encapsulation Chen & Cao Expires April 3, 2012 [Page 6] Internet-Draft 4v6-add-format Oct 2011 4. Address Format Proposals Considering the requirements for different cases, below table has categorized proposed address format. +----------+-----------------+--------------------+ | |source address | destination address| +----------+-----------------+--------------------+ | CE-CE | t1 | t1 | +----------+-----------------+--------------------+ | CE-BR | t1 | t2 | +----------+-----------------+--------------------+ Table 3: Address Format Category for 4v6 Translation +----------+-----------------+--------------------+ | |source address | destination address| +----------+-----------------+--------------------+ | CE-CE | t3 | t3 | +----------+-----------------+--------------------+ | CE-BR | t3 | t2 | +----------+-----------------+--------------------+ Table 4: Address Format Category for 4v6 Encapsulation Therein, T1, T2 and T3 represent different type of address formats. The following would like to show each of them. <------------64 --------------><8 ><--------56----------> +------------+------------+---+---+---------------------+ |IPv6 prefix |MAX CE index| 0 | V | | +------------+------------+---+---+---------------------+ Figure 1: Type 1 Address Format Chen & Cao Expires April 3, 2012 [Page 7] Internet-Draft 4v6-add-format Oct 2011 <--------- 64 ------------>< 8 ><---- 32 ----><--- 24 -----> +--------------------------+----+-------------+------------+ | BR subnet prefix | V |IPv4 address | suffix | +--------------------------+----+-------------+------------+ Figure 2: Type 2 Address Format <--------- 64 ----------------><8 ><------ L >= 32 -------><56-L> +------------+------------+---+---+---------------+------+-----+ |IPv6 prefix |MAX CE index| 0 | V | IPv4 address | PSID | 0 | +------------+------------+---+---+---------------+------+-----+ Figure 3: Type 3 Address Format o V is a tag to indicate 4v6 solution. o MAX CE index is used to identify each user in IPv6 prefix. for more detailed, see addmapping[I-D.despres-softwire-4rd-addmapping] 5. Security Considerations TBD 6. IANA Considerations TBD 7. References 7.1. Normative References [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. Chen & Cao Expires April 3, 2012 [Page 8] Internet-Draft 4v6-add-format Oct 2011 7.2. Informative References [I-D.despres-softwire-4rd-addmapping] Despres, R., Qin, J., Perreault, S., and X. Deng, "Stateless Address Mapping for IPv4 Residual Deployment (4rd)", draft-despres-softwire-4rd-addmapping-01 (work in progress), September 2011. [I-D.ietf-softwire-stateless-4v6-motivation] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-softwire-stateless-4v6-motivation-00 (work in progress), September 2011. [I-D.murakami-softwire-4v6-translation] Murakami, T., Chen, G., Deng, H., Dec, W., and S. Matsushima, "4via6 Stateless Translation", draft-murakami-softwire-4v6-translation-00 (work in progress), July 2011. Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: chengang@chinamobile.com Zhen Cao China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: caozhen@chinamobile.com Chen & Cao Expires April 3, 2012 [Page 9]