idnits 2.17.1 draft-boucadair-softwire-stateless-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.bsd-softwire-stateless-port-index-analysis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 8, 2011) is 4614 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Informational C. Bao 5 Expires: March 11, 2012 CERNET Center/Tsinghua 6 University 7 N. Skoberne 8 Viris 9 X. Li 10 CERNET Center/Tsinghua 11 University 12 September 8, 2011 14 Requirements for Extending IPv6 Addressing with Port Sets 15 draft-boucadair-softwire-stateless-requirements-00 17 Abstract 19 This document identifies a set of requirements to be taken into 20 consideration in the design of stateless 4/6 solutions. In 21 particular, these requirements cover the way IPv4-embedded IPv6 22 address and prefix are to be built when embedding the port 23 information. 25 A companion effort, documented at 26 [I-D.bsd-softwire-stateless-port-index-analysis], is required to 27 converge on one or a set of algorithms to be used by all stateless 28 solutions. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 11, 2012. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 69 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 Several solutions have been proposed in the past to embed the port 78 information in an IPv4-embedded IPv6 address or IPv4-translatable 79 IPv6 prefix (see [I-D.bsd-softwire-stateless-port-index-analysis]). 81 For interoperability purposes, the softwire WG should converge to one 82 address format to be used in the context of stateless 4/6 solutions. 83 This document identifies a set of requirements to be taken into 84 account. 86 This document focuses exclusively on unicast; multicast-related 87 considerations are out of scope. 89 For further information about the motivations for stateless 90 solutions, the reader is invited to refer to 91 [I-D.operators-softwire-stateless-4v6-motivation]. 93 1.1. Terminology 95 This document makes use of the following term: 97 o IPv4-translatable IPv6 address/prefix: denotes an IPv6 address/ 98 prefix assigned to an IPv6 node for use with stateless IPv4-IPv6 99 translation [RFC6052]. 101 1.2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2. Requirements 109 In addition to the requirements discussed in [RFC6052], below are 110 listed additional requirements to be met when including the port 111 information in an IPv4-embedded IPv6 prefix/address: 113 REQ#1: The administrative entity operating the stateless solution 114 MUST be able to select the length of the prefix to be used to 115 build IPv4-translatable IPv6 addresses/prefixes. 117 REQ#2: When extending the IPv6 address with the port, the same 118 format MUST be used to build both IPv4-translatable IPv6 119 prefixes and IPv4-converted IPv6 addresses. 121 REQ#3: Some service providers may require the ability to 122 unambiguously distinguish IPv4 traffic from native IPv6 123 traffic (e.g., multi-topology contexts where IPv4 and IPv6 124 traffic may be conveyed over different paths). 126 This can be implemented using two distinct prefixes 127 or by having a dedicated flag in the address to 128 identify IPv4-translatable IPv6 addresses. 130 REQ#4: When only one single IPv6 prefix is assigned for both native 131 IPv6 communications and the transport of IPv4 packets, the 132 IPv4-translatable IPv6 prefix MUST have a length < /64. 134 REQ#5: The algorithm that computes how port information is conveyed 135 in IPv4-embedded IPv6 addresses MUST be standardized for the 136 sake of interoperability. 138 Note: Do we allow the support of multiple algorithms? 140 REQ#6: The allocation policy of IPv4-translatable IPv6 prefixes 141 embedding the port information MUST preserve proper prefix 142 aggregation. 144 In particular, instantiating fragmented entries (due 145 to prefixes embedding the port information) into 146 routing and forwarding tables MUST be avoided. For 147 more information about the shrink of RIBs, the reader 148 is invited to refer to Section 4.8 of 149 [I-D.narten-radir-problem-statement]. 151 REQ#7: Service Providers SHOULD be able to support different classes 152 of customers: i.e., be able to assign port ranges of 153 different sizes to customers without requiring any per- 154 customer state to be instantiated in network elements 155 involved in data transfer. 157 IPv4 port usage may not be homogeneous among all 158 customers. Therefore, differentiated classes may be 159 defined by Service Providers for that purpose. Each 160 of these classes can be characterized by given size 161 of port sets. 163 REQ#8: Applications requiring even/odd and port contiguity (e.g., 164 RTP/RTCP) SHOULD NOT be broken due to the port set assignment 165 scheme. 167 Traditionally the voice/video applications that use 168 RTP and RTCP would specify only the RTP port that the 169 application would use for streaming the RTP data. 170 The inherent assumption is that the RTCP traffic will 171 be sent on the next higher port. Even though RFC3605 172 defines a new attribute for explicitly specifying the 173 RTCP attribute for the SDP-based applications, but 174 since it is not a MUST to use this attribute, there 175 are still applications that are not compliant with 176 this RFC. There are also non-SDP based applications 177 that use RTP/RTCP like H323, that make the assumption 178 that RTCP streaming will happen on RTP+1 port. 180 Section 4.4 of [I-D.narten-radir-problem-statement] may inspire an 181 additional requirement for the stateless IPv4/IPv6 interconnection 182 function: loose interaction between the IPv4 address pool and the 183 stateless IPv4/IPv6 interconnection function. 185 3. IANA Considerations 187 This document makes no request of IANA. 189 Note to RFC Editor: this section may be removed on publication as an 190 RFC. 192 4. Security Considerations 194 Security considerations discussed in [RFC6052] should be taken into 195 account. 197 5. Acknowledgments 199 Many thanks to C. Jacquenet for his review. 201 6. References 203 6.1. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, March 1997. 208 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 209 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 210 October 2010. 212 6.2. Informative References 214 [I-D.bsd-softwire-stateless-port-index-analysis] 215 Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port 216 Indexing Algorithms", 217 draft-bsd-softwire-stateless-port-index-analysis-00 (work 218 in progress), September 2011. 220 [I-D.narten-radir-problem-statement] 221 Narten, T., "On the Scalability of Internet Routing", 222 draft-narten-radir-problem-statement-05 (work in 223 progress), February 2010. 225 [I-D.operators-softwire-stateless-4v6-motivation] 226 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 227 Borges, I., and G. Chen, "Motivations for Stateless IPv4 228 over IPv6 Migration Solutions", 229 draft-operators-softwire-stateless-4v6-motivation-02 (work 230 in progress), June 2011. 232 Authors' Addresses 234 Mohamed Boucadair 235 France Telecom 237 Email: mohamed.boucadair@orange-ftgroup.com 239 Congxiao Bao 240 CERNET Center/Tsinghua University 241 Room 225, Main Building, Tsinghua University 242 Beijing 243 China 245 Phone: +86 10-62785983 246 Email: congxiao@cernet.edu.cn 247 Nejc Skoberne 248 Viris 249 Smartinska cesta 130 250 Ljubljana 1000 251 SI 253 Phone: +386 31 883 217 254 Email: nejc@viris.si 256 Xing Li 257 CERNET Center/Tsinghua University 258 Room 225, Main Building, Tsinghua University 259 Beijing 260 China 262 Phone: +86 10-62785983 263 Email: xing@cernet.edu.cn