Softwire Working Group M. Boucadair Internet-Draft France Telecom Updates: 6052 (if approved) C. Bao Intended status: Standards Track CERNET Center/Tsinghua Expires: March 10, 2012 University N. Skoberne Viris X. Li CERNET Center/Tsinghua University September 7, 2011 Embedding Port Information in IPv4-Translatable IPv6 Prefixes and IPv4- Embedded IPv6 Addresses draft-boucadair-softwire-stateless-rfc6052-update-00 Abstract RFC6052 specifies the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa. In particular, RFC6052 specifies the address format to build IPv4-converted and IPv4- translatable IPv6 addresses. In order to be deployed in the context of stateless 4/6 solutions, RFC6052 should be updated so that IPv4- embedded IPv6 addresses convey the port information. This document identifies a set of requirements to be taken into account when updating RFC6052 for that purpose. A companion effort, document at [I-D.bsd-softwire-stateless-port-index-analysis], is required to converge on one or a set of algorithms to be used by all stateless solutions. 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." Boucadair, et al. Expires March 10, 2012 [Page 1] Internet-Draft RFC6052 Update September 2011 This Internet-Draft will expire on March 10, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Boucadair, et al. Expires March 10, 2012 [Page 2] Internet-Draft RFC6052 Update September 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability Scope . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . . 4 2. Why Update RFC6052? . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Analysis of Port Indexing Algorithms . . . . . . . . . . . . . 7 5. Address and Prefix Format . . . . . . . . . . . . . . . . . . . 7 5.1. Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Address+Port Translation Algorithms . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Boucadair, et al. Expires March 10, 2012 [Page 3] Internet-Draft RFC6052 Update September 2011 1. Introduction Several solutions have been proposed in the past to embed the port information in an IPv4-embedded IPv6 address or IPv4-translatable IPv6 prefix (see [I-D.bsd-softwire-stateless-port-index-analysis]). For interoperability purposes, the softwire WG should converge to one address format to be used in the context of stateless 4/6 solutions. This document specifies such address format based on the conclusions of the analysis documented at [I-D.bsd-softwire-stateless-port-index-analysis]. This document focuses exclusively on unicast; multicast-related considerations are out of scope. For further information about the motivations for stateless solutions, the reader is invited to refer to [I-D.operators-softwire-stateless-4v6-motivation]. 1.1. Terminology This document makes use of the following term: o IPv4-translatable IPv6 address/prefix: denotes an IPv6 address/ prefix assigned to an IPv6 node for use with stateless IPv4-IPv6 translation [RFC6052]. 1.2. Applicability Scope The prefix and address format, defined in this document, can be used by both encapsulation and translation solutions. The usage of this format in an encapsulation or translation mode is out of scope of this document. 1.3. 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 RFC 2119 [RFC2119]. 2. Why Update RFC6052? [RFC6052] specifies the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa. In particular, [RFC6052] specifies the address format to build IPv4-converted and IPv4-translatable IPv6 addresses. To be deployed in the context of Boucadair, et al. Expires March 10, 2012 [Page 4] Internet-Draft RFC6052 Update September 2011 stateless 4/6 solutions, [RFC6052] should be updated so that IPv4- translatable IPv6 addresses convey the port information. RFC6052 discusses the transport of the port range information in an IPv4-embedded IPv6 address but the conclusion was the following (excerpt from [RFC6052]): "There have been proposals to complement stateless translation with a port-range feature. Instead of mapping an IPv4 address to exactly one IPv6 prefix, the options would allow several IPv6 nodes to share an IPv4 address, with each node managing a different range of ports. If a port range extension is needed, it could be defined later, using bits currently reserved as null in the suffix." This document identifies a set of requirements to be taken into account when updating [RFC6052] for that purpose. 3. Requirements In addition to the requirements discussed in [RFC6052], below are listed additional requirements to be met when including the port information in an IPv4-embedded IPv6 prefix/address: REQ#1: The administrative entity operating the stateless solution MUST be able to select the length of the prefix to be used to build IPv4-translatable IPv6 addresses/prefixes. REQ#2: When extending the IPv6 address with the port, the same format MUST be used to build both IPv4-translatable IPv6 prefixes and IPv4-converted IPv6 addresses. REQ#3: Some service providers may require the ability to unambiguously distinguish IPv4 traffic from native IPv6 traffic (e.g., multi-topology contexts where IPv4 and IPv6 traffic may be conveyed over different paths). This can be implemented using two distinct prefixes or by having a dedicated flag in the address to identify IPv4-translatable IPv6 addresses. Boucadair, et al. Expires March 10, 2012 [Page 5] Internet-Draft RFC6052 Update September 2011 REQ#4: When only one single IPv6 prefix is assigned for both native IPv6 communications and the transport of IPv4 packets, the IPv4-translatable IPv6 prefix MUST have a length < /64. REQ#5: The algorithm that computes how port information is conveyed in IPv4-embedded IPv6 addresses MUST be standardized for the sake of interoperability. Note: Do we allow the support of multiple algorithms? REQ#6: The allocation policy of IPv4-translatable IPv6 prefixes embedding the port information MUST preserve proper prefix aggregation. In particular, instantiating fragmented entries (due to prefixes embedding the port information) into routing and forwarding tables MUST be avoided. For more information about the shrink of RIBs, the reader is invited to refer to Section 4.8 of [I-D.narten-radir-problem-statement]. REQ#7: Service Providers SHOULD be able to support different classes of customers: i.e., be able to assign port ranges of different sizes to customers without requiring any per- customer state to be instantiated in network elements involved in data transfer. IPv4 port usage may not be homogeneous among all customers. Therefore, differentiated classes may be defined by Service Providers for that purpose. Each of these classes can be characterized by given size of port sets. REQ#8: Applications requiring even/odd and port contiguity (e.g., RTP/RTCP) SHOULD NOT be broken due to the port set assignment scheme. Traditionally the voice/video applications that use RTP and RTCP would specify only the RTP port that the application would use for streaming the RTP data. The inherent assumption is that the RTCP traffic will be sent on the next higher port. Even though RFC3605 defines a new attribute for explicitly specifying the RTCP attribute for the SDP-based applications, but since it is not a MUST to use this attribute, there are still applications that are not compliant with Boucadair, et al. Expires March 10, 2012 [Page 6] Internet-Draft RFC6052 Update September 2011 this RFC. There are also non-SDP based applications that use RTP/RTCP like H323, that make the assumption that RTCP streaming will happen on RTP+1 port. Section 4.4 of [I-D.narten-radir-problem-statement] may inspire an additional requirement for the stateless IPv4/IPv6 interconnection function: loose interaction between the IPv4 address pool and the stateless IPv4/IPv6 interconnection function. 4. Analysis of Port Indexing Algorithms The conclusions of [I-D.bsd-softwire-stateless-port-index-analysis] will be inserted here. 5. Address and Prefix Format 5.1. Prefix Only Network-Specific Prefix (NSP) is allowed to be used to build IPv4-translatable IPv6 addresses/prefixes. 5.2. Format Below is provided the address format as defined in [RFC6052]: +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |32| prefix |v4(32) | u | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |40| prefix |v4(24) | u |(8)| suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |48| prefix |v4(16) | u | (16) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |56| prefix |(8)| u | v4(24) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |64| prefix | u | v4(32) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |96| prefix | v4(32) | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ This format is provided as a reminder. Appropriate modifications will be documented in future version of this document. /96 prefixes do not allow to embed the port information. Boucadair, et al. Expires March 10, 2012 [Page 7] Internet-Draft RFC6052 Update September 2011 5.3. Address+Port Translation Algorithms This section specifies how to encode (resp. extract) an IPv4 address and port number in (resp. from) an IPv4-embedded IPv6 address. This section will be completed according to the conclusions of [I-D.bsd-softwire-stateless-port-index-analysis]. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations Security considerations discussed in [RFC6052] should be taken into account. 8. Acknowledgments Many thanks to C. Jacquent for his review. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. 9.2. Informative References [I-D.bsd-softwire-stateless-port-index-analysis] Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port Indexing Algorithms", September 2011, . Boucadair, et al. Expires March 10, 2012 [Page 8] Internet-Draft RFC6052 Update September 2011 [I-D.narten-radir-problem-statement] Narten, T., "On the Scalability of Internet Routing", draft-narten-radir-problem-statement-05 (work in progress), February 2010. [I-D.operators-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-operators-softwire-stateless-4v6-motivation-02 (work in progress), June 2011. Authors' Addresses Mohamed Boucadair France Telecom Email: mohamed.boucadair@orange-ftgroup.com Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing China Phone: +86 10-62785983 Email: congxiao@cernet.edu.cn Nejc Skoberne Viris Smartinska cesta 130 Ljubljana 1000 SI Phone: +386 31 883 217 Email: nejc@viris.si Boucadair, et al. Expires March 10, 2012 [Page 9] Internet-Draft RFC6052 Update September 2011 Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing China Phone: +86 10-62785983 Email: xing@cernet.edu.cn Boucadair, et al. Expires March 10, 2012 [Page 10]