idnits 2.17.1 draft-bcx-behave-address-fmt-extension-10.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 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 (January 28, 2017) is 2642 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) == Missing Reference: 'PSID' is mentioned on line 387, but not defined == Unused Reference: 'RFC6144' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC6346' is defined on line 524, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-06 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 behave C. Bao 3 Internet-Draft X. Li 4 Intended status: Standards Track CERNET Center/Tsinghua 5 Expires: August 1, 2017 University 6 January 28, 2017 8 Extended IPv6 Addressing for Encoding Port Range 9 draft-bcx-behave-address-fmt-extension-10 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 set identification 16 (PSID) which allows several IPv6 nodes to share a single IPv4 address 17 with each node managing a different range of ports. This address 18 format extension can be used for IPv4/IPv6 translation, as well as 19 IPv4 over 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 August 1, 2017. 38 Copyright Notice 40 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Port Mapping Algorithm . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Mathematical representation of the Algorithm . . . . . . . 4 72 2.2. Bit Representation of the Algorithm . . . . . . . . . . . 5 73 2.3. Example of the Algorithm . . . . . . . . . . . . . . . . . 5 74 2.3.1. PSID with fixed prefix length . . . . . . . . . . . . 5 75 2.3.2. PSID with variable prefix length . . . . . . . . . . . 6 76 2.4. Features of the Algorithm . . . . . . . . . . . . . . . . 6 77 3. Extended IPv4-translatable IPv6 Address . . . . . . . . . . . 6 78 3.1. Address Format . . . . . . . . . . . . . . . . . . . . . . 7 79 3.2. Considerations of Using a Shorter Prefix length . . . . . 8 80 3.3. Mapping Extended IPv4-translatable IPv6 Address to 81 RFC1918 Space . . . . . . . . . . . . . . . . . . . . . . 9 82 4. DHCP Options Extensions . . . . . . . . . . . . . . . . . . . 9 83 5. Comparisons with MAP . . . . . . . . . . . . . . . . . . . . . 10 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 This document discusses an extension of the address format defined in 95 [RFC6052]. In Section 2.2, the IPv4-embedded IPv6 address format is 96 defined which composed of a variable length prefix, the embedded IPv4 97 address, and a variable length suffix, as presented in the following 98 diagram, in which PL designates the prefix length: 100 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 101 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 102 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 103 |32| prefix |v4(32) | u | suffix | 104 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 105 |40| prefix |v4(24) | u |(8)| suffix | 106 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 107 |48| prefix |v4(16) | u | (16) | suffix | 108 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 109 |56| prefix |(8)| u | v4(24) | suffix | 110 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 111 |64| prefix | u | v4(32) | suffix | 112 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 113 |96| prefix | v4(32) | 114 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 116 Figure 1: Address Format 118 In [RFC6052] Section 3.5, it states: 120 "There have been proposals to complement stateless translation 121 with a port-range feature. Instead of mapping an IPv4 address to 122 exactly one IPv6 prefix, the options would allow several IPv6 123 nodes to share an IPv4 address, with each node managing a 124 different range of ports. If a port range extension is needed, it 125 could be defined later, using bits currently reserved as null in 126 the suffix." 128 This document defines such a suffix encoding scheme and the 129 corresponding port mapping algorithm. 131 1.1. Applicability Scope 133 The address format extension presented in this document is used for 134 IPv4/IPv6 stateless translation and dual IPv4/IPv6 stateless 135 translation without prefix delegation [I-D.xli-behave-divi]. The 136 address format used for dual IPv4/IPv6 stateless translation and 137 encapsulation with prefix delegation should refer to 138 [I-D.ietf-softwire-map-t] [I-D.ietf-softwire-map]. 140 1.2. Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 2. Port Mapping Algorithm 148 2.1. Mathematical representation of the Algorithm 150 There exist many port mapping algorithms and each one may have 151 advantages and disadvantages, as well as has its best application 152 scenario. Since different PSID MUST have non-overlapped port range, 153 the two extreme cases are: (1) the port number is not continue for 154 each PSID, but uniformly distributed cross the whole port range 155 (0-65535); (2) the port number is continue in a single range for each 156 PSID. The port mapping algorithm proposed here is called generalized 157 modulus algorithm and it is flexible, meets these two cases and 158 simple. 160 For given sharing ratio (R) and the maximum number of continue ports 161 (M), the generalized modulus algorithm is defined as 163 1. The port number (P) of a given PSID (K) is composed of 165 P = R*M*j + M*K + i 167 Where 168 o PSID: K=0 to R-1 169 o Port range index: j = (1024/M)/R to ((65536/M)/R)-1, if the 170 well-known port numbers (0-1023) are excluded. 171 o Port continue index: i=0 to M-1 173 2. The PSID (K) of a given port number (P) is determined by 175 K = (floor(P/M)) % R 177 Where 178 o % is modular operator 179 o floor(arg) is a function returns the largest integer not 180 greater than arg 182 3. The well-known port number (0-1023) can be used, if additional 183 port mapping rule is defined. 185 2.2. Bit Representation of the Algorithm 187 Given sharing ratio (R=2^k), the maximum number of continue ports 188 (M=2^m), for any PSID (K) available ports (P) can be represented as: 190 0 8 15 191 +---------------+----------+------+-------------------+ 192 | P | 193 ----------------+-----------------+-------------------+ 194 | A (j) | PSID (K) | M (i) | 195 +---------------+----------+------+-------------------+ 196 |<----a bits--->|<-----k bits---->|<------m bits----->| 197 |<---c bits--->|<-----(k+m-c) bits--->| 199 Figure 2: Bit representation 201 Where j and i are the same indexes defined in the port mapping 202 algorithm. 204 For any port number, the PSID can be obtained by bit mask operation 205 and therefore the generalized modulus algorithm does not introduce 206 the computational complexity. 208 Note that in above figure there is a PSID prefix length (c). Based 209 on this definition, PSID is also in CIDR style and more ports can be 210 assigned to a single CE when PSID prefix length (c < k). 212 When m=0, the generalized modulus algorithm becomes modulus 213 operation. When a=0, the generalized modulus algorithm becomes 214 division operation. 216 2.3. Example of the Algorithm 218 2.3.1. PSID with fixed prefix length 220 For example, for R=128 (k=7), M=4 (m=2) 222 Port range-1 | Port rang-2 | Port 223 ------------------------------------------------------------------- 224 PSID=0 | 1024, 1025, 1026, 1027, | 1536, 1537, 1538, 1539, | 2048 225 PSID=1 | 1028, 1029, 1030, 1031, | 1540, 1541, 1542, 1543, | .... 226 PSID=2 | 1032, 1033, 1034, 1035, | 1544, 1545, 1546, 1547, | .... 227 PSID=3 | 1036, 1037, 1038, 1039, | 1548, 1549, 1550, 1551, | .... 228 ... 229 PSID=127 | 1532, 1533, 1534, 1535, | 2044, 2045, 2046, 2047, | .... 231 Figure 3: Example 1 233 2.3.2. PSID with variable prefix length 235 For example, different PSIDs have different prefix length (c) 237 Host | PSID prefix | Number of ports 238 ------------------------------------------------------- 239 Host0 | 000/2 | 2x8192 240 Host1 | 010/3 | 1x8192 241 Host2 | 011/3 | 1x8192 242 Host3 | 100/1 | 4x8192 243 ------------------------------------------------------- 245 Figure 4: Example 2 247 2.4. Features of the Algorithm 249 The generalized modulus operation has the following features: 251 1. There is no waste of the port number, except the well-known 252 ports. 254 2. The algorithm is flexible, the control parameters are sharing 255 ratio (R), the continue port range (M) and PSID prefix length 256 (c). 258 3. It does not introduce algorithm complexity. 260 4. It allows service providers to define their own address sharing 261 ratio, the theoretical value is from 1:1 to 1:65536 and a more 262 practical value is from 1:1 to 1:4096. 264 5. It supports deployments using differentiated port ranges. 266 6. It supports differentiated port ranges within a single shared 267 IPv4 address. 269 7. It support excluding the well known ports 0-1023. 271 8. It supports assigning well known ports to a CE. 273 9. It supports legacy RTP/RTCP compatibility. 275 3. Extended IPv4-translatable IPv6 Address 276 3.1. Address Format 278 Based on the port mapping algorithm, the extended address format is 279 shown in the following figure. 281 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 282 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 283 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 284 |32| prefix |v4(32) | u | PSID | 0 | Q | 285 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 286 |40| prefix |v4(24) | u |(8)| PSID | 0 | Q | 287 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 288 |48| prefix |v4(16) | u | (16) | PSID | 0 | Q | 289 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 290 |56| prefix |(8)| u | v4(24) | PSID | 0 | Q | 291 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 292 |64| prefix | u | v4(32) |PSID |0| Q | 293 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 295 Figure 5: Address Format 297 Where PL designates the prefix length. 299 The PSID is placed right after the IPv4 address, since the 300 combination of the IPv4 address and the PSID represents the more 301 specifics in CIDR style which is sharing an IPv4 address with others. 303 The PSID prefix length (Q=c) is encoded in the last octet (bits 120- 304 127) to indicate the number of ports can be used. When Q=0, the 305 extended address format will become the address format defined in 306 [RFC6052]. The relations between Q, the sharing ratio (R), the 307 maximum continue port range (M) and the number of ports can be shown 308 in the following figure. 310 Q Ratio | Maximum M | # of Ports 311 ------------------------------------------ 312 0 1:1 65,536 65,536 313 1 1:2 32,786 32,786 314 2 1:4 16,384 16,384 315 3 1:8 8,192 8,192 316 4 1:16 4,096 4,096 317 5 1:32 2,048 2,048 318 6 1:64 1,024 1,024 319 7 1:128 512 512 320 8 1:256 256 256 321 9 1:512 128 128 322 10 1:1,024 64 64 323 11 1:2,048 32 32 324 12 1:4,096 16 16 325 ------------------------------------------ 327 Figure 6: Port range 329 Since newly defined IPv6 addresses with suffix are more specifics 330 compared with the original address format defined in [RFC6052], the 331 routing considerations in that document are also applied here. 332 Furthermore, the port range is embedded in the extended IPv4- 333 translatable IPv6 addresses and bound to the PSID therefore the 334 packets containing extended IPv4-translatable IPv6 addresses as the 335 destination can be routed to different IPv6 nodes. 337 3.2. Considerations of Using a Shorter Prefix length 339 Since IPv4 address plus variable length PSID represents the more 340 specifics, the prefix length (PL) defined in [RFC6052] can be 341 shorter. In these cases, the interface identifier (IID: second 64 342 bits) will not contains PSID and therefore can be used for regular 343 prefix delegation, as shown in the following figure. 345 +--+---+---+----+----+-------+----+----+----+---+---+---+------+ 346 |PL| 0-----24---28---32------56---60---64---72------96-----120-| 347 +--+---+---+----+----+-------+----+----+----+---+---+---+------+ 348 |24| prefix| v4(32) | PSID | u | | Q | 349 +--+---+---+----+----+-------+----+----+----+---+---+---+------+ 350 |28| prefix | v4(32) |PSID| u | | Q | 351 +--+---+---+----+----+-------+----+----+----+---+---+---+------+ 352 |32| prefix | v4(32) | u | | Q | 353 +--+---+---+----+----+-------+----+----+----+---+---+---+------+ 355 Figure 7: Shorter PL 357 Note that PL can take any value. For example, 358 o PL=24: Q=8, R=256 359 o PL=25: Q=7, R=128 360 o PL=26: Q=6, R=64 361 o PL=27: Q=5, R=32 362 o PL=28: Q=4, R=16 363 o PL=29: Q=3, R=8 364 o PL=30: Q=2, R=4 365 o PL=31: Q=1, R=2 366 o PL=32: Q=0, R=1 368 However, there will be a waste of the IPv6 address space in order to 369 represent the IPv4-converted addresses. 371 3.3. Mapping Extended IPv4-translatable IPv6 Address to RFC1918 Space 373 Based on the algorithm defined in this document, a public IPv4 374 address and PSID can be mapped to extended IPv4-translatable IPv6 375 address and vise versa. 377 On the other hand, it is also possible to map the extended IPv4- 378 translatable IPv6 address to [RFC1918] address space. In this case, 379 one public IPv4 address can be mapped to several RFC1918 addresses 380 and used by IPv4 or dual stack hosts. 382 For public IPv4 address a.b.c.d, 384 o If R <= 256, the corresponding RFC1918 address is 10.c.d.PSID 385 (PSID has 8 bits) 387 o Otherwise, the corresponding RFC1918 address is 10.d.[PSID] (PSID 388 has 16 bits) 390 4. DHCP Options Extensions 392 Based on the address format and the port mapping algorithm defined in 393 this document, the IPv6 host needs to get the corresponding 394 parameters via DHCPv6 [RFC3315][RFC3633] or others signaling scheme. 395 These parameters are: 397 1. The IPv6 prefix 399 2. The IPv6 prefix length 401 3. The IPv4 prefix 403 4. The IPv4 prefix length 404 5. The sharing ratio (R) 406 6. The maximum number of continue ports (M) 408 7. The PSID (K) 410 8. The PSID length (c) 412 5. Comparisons with MAP 414 There are common parts and differences between this document and the 415 address format defined in [I-D.ietf-softwire-map] 416 [I-D.ietf-softwire-map-t]. 418 1. The address format extension defined in this document is used for 419 single and dual stateless translation without prefix delegation, 420 while MAP is used for encapsulation and dual stateless 421 translation with prefix delegation. 423 2. The address format extension defined in this document uses same 424 IPv6 prefix for the source address from a CE to any destination 425 (IPv4-translatable address) and the destination address from a CE 426 to the outside IPv4 Internet (IPv4-converted address), while MAP 427 uses different IPv6 prefixes, due to the requirements of prefix 428 delegation. 430 3. The address format extension defined in this document uses same 431 IPv6 prefix for all CEs, so there is no need to define prefix 432 encoding scheme (e.g. CE index, or EA-bits), while MAP defines 433 the prefix encoding scheme, due to the requirements of prefix 434 delegation. 436 4. Due to the nature of using same IPv6 prefix for both IPv4- 437 translatable address and IPv4-converted address, there is no 438 referral problem and mesh scenarios can be supported without 439 additional mapping rules, while MAP does require additional 440 mapping rule for supporting mesh scenario. 442 5. The address format extension defined in this document and MAP 443 share the same suffix coding scheme (IPv4 address + PSID). 445 6. The AFT and MAP share the same port mapping algorithm 446 (generalized modulus algorithm). 448 6. IANA Considerations 450 This memo adds no new IANA considerations. 452 7. Security Considerations 454 There is no special security consideration. 456 8. Acknowledgements 458 Thanks to Wojciech Dec, Remi Despres, Ole Troan, Rajiv Asati, 459 Chongfeng Xie, Qiong Sun, Fred Baker, Wing Dan, M. Boucadair and all 460 the friends for the fruitful discussions during the unification of 461 the port mapping algorithm of 462 [I-D.mdt-softwire-mapping-address-and-port]. Also thanks to Wentao 463 Shang, Guoliang Han, Yu Zhai, Haotao Zhang and Weicai Wang for their 464 contributions. 466 9. References 468 9.1. Normative References 470 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 471 and E. Lear, "Address Allocation for Private Internets", 472 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 473 . 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 477 RFC2119, March 1997, 478 . 480 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 481 C., and M. Carney, "Dynamic Host Configuration Protocol 482 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, 483 July 2003, . 485 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 486 Host Configuration Protocol (DHCP) version 6", RFC 3633, 487 DOI 10.17487/RFC3633, December 2003, 488 . 490 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 491 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 492 DOI 10.17487/RFC6052, October 2010, 493 . 495 9.2. Informative References 497 [I-D.ietf-softwire-map] 498 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 499 Murakami, T., and T. Taylor, "Mapping of Address and Port 500 with Encapsulation (MAP)", draft-ietf-softwire-map-13 501 (work in progress), March 2015. 503 [I-D.ietf-softwire-map-t] 504 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 505 T. Murakami, "Mapping of Address and Port using 506 Translation (MAP-T)", draft-ietf-softwire-map-t-08 (work 507 in progress), December 2014. 509 [I-D.mdt-softwire-mapping-address-and-port] 510 Bao, C., Troan, O., Matsushima, S., Murakami, T., and X. 511 Li, "Mapping of Address and Port (MAP)", 512 draft-mdt-softwire-mapping-address-and-port-03 (work in 513 progress), January 2012. 515 [I-D.xli-behave-divi] 516 Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- 517 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-06 518 (work in progress), January 2014. 520 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 521 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 522 April 2011, . 524 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 525 the IPv4 Address Shortage", RFC 6346, DOI 10.17487/ 526 RFC6346, August 2011, 527 . 529 Authors' Addresses 531 Congxiao Bao 532 CERNET Center/Tsinghua University 533 Room 225, Main Building, Tsinghua University 534 Beijing, 100084 535 China 537 Phone: +86 10-62785983 538 Email: congxiao@cernet.edu.cn 539 Xing Li 540 CERNET Center/Tsinghua University 541 Room 225, Main Building, Tsinghua University 542 Beijing, 100084 543 China 545 Phone: +86 10-62785983 546 Email: xing@cernet.edu.cn