Softwire Working Group M. Boucadair Internet-Draft France Telecom Intended status: Informational C. Bao Expires: March 11, 2012 CERNET Center/Tsinghua University N. Skoberne Viris X. Li CERNET Center/Tsinghua University September 8, 2011 Requirements for Extending IPv6 Addressing with Port Sets draft-boucadair-softwire-stateless-requirements-00 Abstract This document identifies a set of requirements to be taken into consideration in the design of stateless 4/6 solutions. In particular, these requirements cover the way IPv4-embedded IPv6 address and prefix are to be built when embedding the port information. A companion effort, documented 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." This Internet-Draft will expire on March 11, 2012. Copyright Notice Boucadair, et al. Expires March 11, 2012 [Page 1] Internet-Draft Stateless A+P Requirements September 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Boucadair, et al. Expires March 11, 2012 [Page 2] Internet-Draft Stateless A+P Requirements 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 identifies a set of requirements to be taken into account. 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. 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. 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. Boucadair, et al. Expires March 11, 2012 [Page 3] Internet-Draft Stateless A+P Requirements September 2011 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. 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. Boucadair, et al. Expires March 11, 2012 [Page 4] Internet-Draft Stateless A+P Requirements September 2011 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 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. 3. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 4. Security Considerations Security considerations discussed in [RFC6052] should be taken into account. 5. Acknowledgments Many thanks to C. Jacquenet for his review. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Boucadair, et al. Expires March 11, 2012 [Page 5] Internet-Draft Stateless A+P Requirements September 2011 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. 6.2. Informative References [I-D.bsd-softwire-stateless-port-index-analysis] Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port Indexing Algorithms", draft-bsd-softwire-stateless-port-index-analysis-00 (work in progress), 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 Boucadair, et al. Expires March 11, 2012 [Page 6] Internet-Draft Stateless A+P Requirements September 2011 Nejc Skoberne Viris Smartinska cesta 130 Ljubljana 1000 SI Phone: +386 31 883 217 Email: nejc@viris.si 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 11, 2012 [Page 7]