idnits 2.17.1 draft-bcx-address-fmt-extension-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2011) is 4562 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-behave-v6v4-framework' is defined on line 388, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 behave C. Bao, Ed. 3 Internet-Draft X. Li 4 Intended status: Standards Track CERNET Center/Tsinghua 5 Expires: April 25, 2012 University 6 October 23, 2011 8 Extended IPv6 Addressing for Encoding Port Range 9 draft-bcx-address-fmt-extension-02 11 Abstract 13 This document discusses an extension of the algorithmic translation 14 between IPv4 and IPv4-translatable IPv6 addresses. The extended 15 address format contains transport-layer port range information which 16 allows several IPv6 nodes to share a single IPv4 address with each 17 node managing a different range of ports. This address format 18 extension can be used for IPv4/IPv6 translation, as well as IPv4 over 19 IPv6 tunneling. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 14, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Extended IPv4-tranlatable IPv6 Address . . . . . . . . . . . . 3 71 2.1. Port-range Coding Algorithm . . . . . . . . . . . . . . . . 4 72 2.2. Extended Address Format . . . . . . . . . . . . . . . . . . 5 73 2.3. Suffix for Port Range Encoding . . . . . . . . . . . . . . 6 74 2.4. Stateless Suffix Translation Algorithm . . . . . . . . . . 7 75 2.5. Partial-state Suffix Translation Algorithm . . . . . . . . 8 76 2.6. ICMP Packet Handling . . . . . . . . . . . . . . . . . . . 8 77 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 79 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 This document discusses an extension of the address format defined in 88 [I-D.ietf-behave-address-format]. The original address format 89 document specifies how an individual IPv6 address is translated to a 90 corresponding IPv4 address, and vice versa, in cases where an 91 algorithmic mapping is used. To face the IPv4 public address 92 exhaustion, it is desirable to assign fractional IPv4 addresses to 93 IPv6 nodes which can share a single IPv4 address with each node 94 managing a different range of ports. 96 In [I-D.ietf-behave-address-format] Section 3.5, it states: 98 "There have been proposals to complement stateless translation 99 with a port-range feature. Instead of mapping an IPv4 address to 100 exactly one IPv6 prefix, the options would allow several IPv6 101 nodes to share an IPv4 address, with each node managing a 102 different range of ports. If a port range extension is needed, it 103 could be defined later, using bits currently reserved as null in 104 the suffix." 106 This document defines one of such a suffix encoding scheme and the 107 corresponding port-range algorithm. 109 1.1. Applicability Scope 111 The address format extension can be used for both IPv4/IPv6 112 translation and IPv4 over IPv6 tunneling. However, in this document 113 we will use IPv4-translatable addresses in the stateless translation 114 to discuss this specific address format extension. The descriptions 115 of the other algorithms for their specific use case can be defined 116 later. 118 1.2. Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Extended IPv4-tranlatable IPv6 Address 126 In Section 2.2 of [I-D.ietf-behave-address-format], IPv4-embedded 127 IPv6 address format is defined which composed of a variable length 128 prefix, the embedded IPv4 address, and a variable length suffix, as 129 presented in the following diagram, in which PL designates the prefix 130 length: 132 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 133 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 134 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 135 |32| prefix |v4(32) | u | suffix | 136 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 137 |40| prefix |v4(24) | u |(8)| suffix | 138 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 139 |48| prefix |v4(16) | u | (16) | suffix | 140 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 141 |56| prefix |(8)| u | v4(24) | suffix | 142 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 143 |64| prefix | u | v4(32) | suffix | 144 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 145 |96| prefix | v4(32) | 146 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 148 Figure 1: Address Format 150 It is clear that only Prefix lengths (PL) with 32, 40, 48, 56 and 64 151 have suffix portions, with maximum suffix lengths of 56, 48, 40, 32, 152 24, respectively. In order to use different Prefix length and unify 153 the port range encoding method, the suffix should be 24 bits or less. 154 Furthermore, we choose the port-range coding suffix which is directly 155 following the embedded IPv4 address and padding zeros after the 156 suffix. 158 2.1. Port-range Coding Algorithm 160 The address-sharing scheme is shown in the following figure. 162 --------------------------------- 163 -----|IPv4-translatable-0|port-range-0 | 164 / --------------------------------- 165 / --------------------------------- 166 |--------|IPv4-translatable-1|port-range-1 | 167 | --------------------------------- 168 -------------------- | --------------------------------- 169 | IPv4-addr|any ports|-----------|IPv4-translatable-2|port-range-2 | 170 -------------------- | --------------------------------- 171 | --------------------------------- 172 |--------|IPv4-translatable-3|port-range-3 | 173 | --------------------------------- 174 \ ... 175 \ --------------------------------- 176 -----|IPv4-translatable-K|port-range-K | 177 --------------------------------- 178 ... 180 Figure 2: Address Sharing Scheme 182 In the above figure, the IPv4-translatable-0, IPv4-translatable-1, 183 IPv4-translatable-2, ..., IPv4-translatable-K are sharing the same 184 IPv4 address IPv4-addr, but port number range for different IPv4- 185 translatable addresses (i.e. port-range-0, port-range-1, port-range-2 186 , port-range-K) are not overlapped. When an IPv6 node using IPv4- 187 translatable addresses communicates with the IPv4 Internet via a 188 translator, it looks like a single host using IPv4 address (IPv4- 189 addr) communicating with the IPv4 Internet. 191 There exist many port-range coding schemes and each one may have its 192 advantages and disadvantages, as well as has its best application 193 scenario. In this document, we will introduce a simple one, which we 194 believe is suitable for the IPv4/IPv6 stateless translation. This 195 encoding scheme uses the modulus operator to define the port number 196 range. 198 If the sharing ratio is N, then: 200 o Given K (K=0, 1, ..., N-1), the allowed port number (P) are 201 P=j*N + K-1, where j=0, 1, ..., (65536-N)/N. 203 o Given P, the IPv6 node index (K) is 204 K=(P%N) (% is the Modulus Operator). 206 For example, If N=128, then IPv6 node K=5 is only allowed to use port 207 numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 as the 208 source port, while the packets with these port numbers as the 209 destination port number will be send to IPv6 node K=5. 211 The modulus operator has several features: 213 1. The port ranges are not overlapped for different IPv6 nodes. 215 2. The individual ports for each IPv6 node are not continues and the 216 whole 65536 port range is equally shared by IPv6 nodes. 218 3. The port number range can be uniquely determined by given sharing 219 ratio (N) and the IPv6 node index (K). 221 Based on the modulus operator, We need to encode N and K in the 222 suffix as an extended IPv4-translatable IPv6 address. 224 2.2. Extended Address Format 226 Since the transport port number is a 16 bit integer, the sharing 227 ratio (N) and the IPv6 node index (K) can both have the value from 0 228 to 65535. In theory, 32 bits (16 bits for sharing ratio and 16 bits 229 for IPv6 node index) are required for encoding the port range based 230 on the modulus operation. In order to fit into 24 bit or less suffix 231 range, we need to do compression. 233 First, we can use number of bits to represent the sharing ratio when 234 the sharing ratio is bit-wise, hence 4 bits is enough for N. 236 Secondly, if sharing ratio N is very high, each IPv6 node can only 237 use a small number of concurrent sessions. For example, if N=4096, 238 each IPv6 node will have 16 concurrent sessions, which may be too 239 small for most of the applications. Therefore, if we set the maximum 240 sharing ratio N=4096, then 12 bits are enough for the IPv6 node 241 index. In this case, we can design suffix which consists of 16 bits 242 for encoding the port range. 244 Based on the above discussion, the extended address format is shown 245 in the following figure. 247 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 248 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 249 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 250 |32| prefix |v4(32) | u | suffix| zero | 251 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 252 |40| prefix |v4(24) | u |(8)| suffix| zero | 253 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 254 |48| prefix |v4(16) | u | (16) | suffix| zero | 255 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 256 |56| prefix |(8)| u | v4(24) | suffix| zero | 257 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 258 |64| prefix | u | v4(32) | suffix|zer| 259 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 261 Figure 3: Extended Address Format 263 Since different suffixes are more specifics in the original address 264 format defined in [I-D.ietf-behave-address-format], the routing 265 considerations in that document are also applied here. Furthermore, 266 the port range is embedded in the extended IPv4-translatable IPv6 267 addresses and bound to the IPv6 node index (K), therefore the packets 268 containing extended IPv4-translatable IPv6 addresses as the 269 destination can be routed to different IPv6 nodes. 271 2.3. Suffix for Port Range Encoding 273 The most significant 4 bits define the multiplexing ratio and the 274 least significant 12 bits define the IPv6 node index. The 275 multiplexing ratio, the suffix range and the number of corresponding 276 concurrent ports are as shown in the following figure. 278 ratio | suffix range | # of Ports 279 -------------------------------------- 280 1 0000 - 0000 65,536 281 2 1000 - 1001 32,768 282 4 2000 - 2003 16,384 283 8 3000 - 3007 8,192 284 16 4000 - 400f 4,096 285 32 5000 - 501f 2,048 286 64 6000 - 603f 1,024 287 128 7000 - 707f 512 288 256 8000 - 80ff 256 289 512 9000 - 91ff 128 290 1,024 a000 - a3ff 64 291 2,048 b000 - b7ff 32 292 4,096 c000 - cfff 16 293 -------------------------------------- 295 Figure 4: Suffix for Port Range Encoding 297 2.4. Stateless Suffix Translation Algorithm 299 For the stateless translation, the IPv6 nodes are required to follow 300 the port number range defined by the extended IPv4- translatable 301 address format when communicating with the IPv4 Internet. The port 302 number handling algorithm is: 304 o If the packets are from IPv4 to IPv6, the IPv4 source addresses 305 are translated to the IPv4-converted addresses and the source port 306 numbers are unchanged before and after translation; the IPv4 307 destination addresses are translated to the extended IPv4- 308 translatable addresses based on the destination port number and 309 the destination port numbers are unchanged before and after 310 translation. Note that this means that only a specific IPv6 node 311 can receive the packets for a specific port number. When it is 312 port 80, that specific IPv6 node can setup http redirect service 313 for other IPv6 nodes which also provide web services with non- 314 standard port numbers (e.g. 81, 82, etc.). 316 o If the packets are from IPv6 to IPv4, the IPv6 source addresses 317 and the source port numbers are checked, if the source port number 318 matches the port number range defined by the extended IPv4- 319 translatable address format, the IPv6 source addresses (which are 320 the IPv4-translatable addresses) are translated to the IPv4 321 addresses and the source port numbers are unchanged before and 322 after translation; the destination IPv6 addresses (which are the 323 IPv4-converted addresses) are translated to the IPv4 destination 324 addresses and the destination port numbers are unchanged before 325 and after translation. However, if the source port number does 326 not match the port number range defined by the extended IPv4- 327 translatable address format, the packets will be dropped. 329 2.5. Partial-state Suffix Translation Algorithm 331 Stateless translation requires that IPv6 nodes generate source port 332 number in the range defined by the extended IPv4-translatable 333 address. If this condition does not hold, the partial-state suffix 334 translation algorithm can be used. 336 The reason we call this partial-state is that: 338 o The address mapping is fully algorithm based, as defined in 339 section 3.4. The states are used for port number mapping only. 341 o There will be no port mapping table created if the the source port 342 number from IPv6 to IPv4 is in the range defined by the extended 343 IPv4-translatable address. 345 o For the destination port number of the packet from the IPv4 to 346 IPv6, there will be no port mapping table created. 348 The partial-state suffix translation algorithm can be defined later. 350 2.6. ICMP Packet Handling 352 The ICMP errors should be translatable using the same algorithm (that 353 is, an error such as Destination Unreachable includes the original 354 TCP (or UDP) header in the ICMP payload, and the that TCP (or UDP) 355 port number can be used to translate the ICMP packet into an IPv6- 356 encoded packet and back again. 358 Since ICMP echo-request/echo-reply packets only contain 359 identification field, not the transport port numbers, similar to NAT, 360 special actions can be taken for translating the ICMP echo-request/ 361 echo-reply packets, which can be defined later. 363 3. IANA Considerations 365 This memo adds no new IANA considerations. 367 4. Security Considerations 369 There is no special security consideration. 371 5. Acknowledgements 373 6. References 375 6.1. Normative References 377 [I-D.ietf-behave-address-format] 378 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 379 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 380 draft-ietf-behave-address-format-10 (work in progress), 381 August 2010. 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 6.2. Informative References 388 [I-D.ietf-behave-v6v4-framework] 389 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 390 IPv4/IPv6 Translation", 391 draft-ietf-behave-v6v4-framework-10 (work in progress), 392 August 2010. 394 Authors' Addresses 396 Congxiao Bao (editor) 397 CERNET Center/Tsinghua University 398 Room 225, Main Building, Tsinghua University 399 Beijing, 100084 400 China 402 Phone: +86 10-62785983 403 Email: congxiao@cernet.edu.cn 405 Xing Li 406 CERNET Center/Tsinghua University 407 Room 225, Main Building, Tsinghua University 408 Beijing, 100084 409 China 411 Phone: +86 10-62785983 412 Email: xing@cernet.edu.cn