idnits 2.17.1 draft-li-intarea-nat64-prefix-dhcp-option-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2017) is 2580 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 6877 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 intarea Working Group L. Li 3 Internet-Draft Y. Cui 4 Intended status: Standards Track C. Liu 5 Expires: September 27, 2017 J. Wu 6 Tsinghua University 7 F. Baker 9 J. Palet Martinez 10 Consulintel, S.L. 11 March 26, 2017 13 DHCPv6 Options for Discovery NAT64 Prefixes 14 draft-li-intarea-nat64-prefix-dhcp-option-01 16 Abstract 18 Several IPv6 transition mechanisms require the usage of stateless or 19 stateful translators (commonly named as NAT64) able to allow IP/ICMP 20 communication between IPv4 and IPv6 networks. 22 Those translators are using either a default Well-Known Prefix (WKP), 23 and/or one or several additional Network Specific Prefix (NSP), which 24 need to be configured into the nodes willing to use the translator. 25 Different translators will likely have different IPv6 prefixes, to 26 attract traffic to the correct translator. Thus, an automatic 27 translator prefix discovery method is necessary. 29 This document defines a DHCPv6-based method to inform DHCPv6 clients 30 the set of IPv6 and IPv4 prefixes it serves. This DHCPv6 option can 31 be used by several transition mechanisms such as SIIT, 464XLAT, EAM. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 27, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 69 3. New DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. NAT64 Prefix List Option Format . . . . . . . . . . . . . 4 71 3.2. NAT64 Prefix Option Format . . . . . . . . . . . . . . . 4 72 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Message Flow Illustration . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 9.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 Stateless IP/ICMP Translation (SIIT) [RFC7915] describes the basic 85 translation mechanism (NAT64), which is actually used as the base for 86 most of the related translation protocols. 88 Stateful NAT64 [RFC6146] describes how to allow IPv6-only clients to 89 contact IPv4 servers using unicast UDP, TCP or ICMP. 91 464XLAT [RFC6877] describes an IPv4-over-IPv6 solution as one 92 technique for IPv4 service extension and encouragement of IPv6 93 deployment. The 464XLAT architecture uses IPv4/IPv6 translation, 94 described in [RFC6144], and standardized in [RFC6052], [RFC7915], and 95 [RFC6146]. It encourages the IPv6 transition by making IPv4 service 96 reachable across IPv6-only networks and providing IPv6 and IPv4 97 connectivity to single-stack IPv4 or IPv6 servers and peers. In the 98 464XLAT architecture, the CLAT (customer-side NAT46 translator) must 99 determine which of potentially several PLAT (provider-side NAT64 100 translator) IPv6 prefix to use in order to send a packet to the PLAT 101 with connectivity to its destination. 103 [RFC7050] describes a mechanism to learn the PLAT-side IPv6 prefix 104 for protocol translation by DNS64 [RFC6147]. Although it supports 105 multiple PLAT-side prefix by responding with multiple AAAA records to 106 a DNS64 query, it does not support mapping IPv4 prefixes to IPv6 107 prefix, which would be required, for example, if one PLAT has 108 connectivity to the general Internet following a default route, 109 another has connectivity to a BGP peer, and a third has connectivity 110 to a network using private addressing [RFC1918]. Therefore, in the 111 scenario with multiple PLATs, [RFC7050] does not directly support 112 destination-based IPv4 routing among PLATs; instead, the DNS64 113 database must contain equivalent information. It also requires the 114 additional deployment of DNS64 service in customer-side networks, 115 which is not required in 464XLAT deployment. Indeed, this scenario, 116 which may become very common in wired access networks, has not even 117 been considered by [RFC7051]. 119 464XLAT is in fact, a usage case of Stateful NAT64. 121 Explicit Address Mappings for Stateless IP/ICMP Translation [RFC7757] 122 extends SIIT with an Explicit Address Mapping (EAM) algorithm to 123 facilitate stateless IP/ICMP translation between arbitrary (non- 124 IPv4-translatable) IPv6 endpoints and IPv4. 126 This document proposes a method for the translator (NAT64) IPv6 127 prefix discovery based on DHCPv6, which is widely deployed and 128 supported in customer networks. It defines two new DHCPv6 options 129 for use by a DHCPv6 client to discover the translator IPv6 130 prefix(es). Also, the proposed mechanism can deal with the scenario 131 with multiple independent DNS64 databases supporting separate 132 translators. 134 2. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. New DHCPv6 Option 141 3.1. NAT64 Prefix List Option Format 143 The NAT64 Prefix List Option is a container for NAT64 Prefix 144 Option(s). A NAT64 Prefix List Option MAY contain multiple NAT64 145 Prefix Options. 147 The format of the NAT64 Prefix List Option is: 149 0 1 2 3 150 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | OPTION_NAT64_PREFIX_LIST | option-length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 + NAT64_PREFIX-options + 156 | (see Figure 2) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 1: Format of NAT64 Prefix List Option 161 o option-code: OPTION_NAT64_PREFIX_LIST (TBA1) 163 o option-length: length of NAT64_PREFIX-options, specified in 164 octets. 166 o NAT64_PREFIX-options: one or more OPTION_NAT64_PREFIX options. 168 3.2. NAT64 Prefix Option Format 170 The NAT64 Prefix Option is encapsulated in the NAT64 Prefix List 171 Option. This option allows the mapping of destination IPv4 address 172 ranges (contained in the IPv4 Prefix List) to a NAT64 IPv6 prefix. 173 If there is more than one such prefix, each prefix comes in its own 174 option, with its associated IPv4 prefix list. In this way, the 175 DHCPv6 client can select the NAT64 with the corresponding destination 176 IPv4 address. 178 The format of the NAT64 Prefix Option is: 180 0 1 2 3 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | OPTION_NAT64_PREFIX | option-length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | NAT64-Type | NAT64-prelen | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | NAT64-prefix | 188 | (variable length) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | NAT64-suffix | 191 | (variable length) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 . (optional) . 194 . IPv4 Prefix List (variable length) . 195 . (see Figure 3) . 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 2: Format of NAT64 Prefix Option 200 0 1 2 3 201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | IPv4-prelen | IPv4 Prefix (32 bits) | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | (cont.) | IPv4-prelen | IPv4 Prefix (32 bits) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | IPv4 Prefix (cont.) | ... | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | ... | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 3: Format of IPv4 Prefix List field 214 o option-code: OPTION_NAT64_PREFIX (TBA2) 216 o type-field: NAT64-Type (TBA3) 218 o option-length: 4 + length of NAT64-prefix + length of NAT64-suffix 219 + length of IPv4 Prefix List, specified in octets. 221 o NAT64-prelen: length of NAT64-prefix, in octets. The values 222 allowed are: 4, 5, 6, 7, 8 or 12, as indicated in Section 2.2 of 223 [RFC6052]. 225 o NAT64-prefix: The NAT64 IPv6 prefix to be used by the DHCPv6 226 client for the IPv6 address synthesis. MUST follow the 227 specifications of [RFC6052]. 229 o NAT64-suffix: The NAT64 suffix to be used by the DHCPv6 client for 230 the IPv6 address synthesis, specified in Section 2.2 of [RFC6052]. 231 The length of this field, in octets is 12 - NAT64-prelen. Not 232 used in case of using the WKP (i.e., 64:ff9b::/96) or any other 233 NSP (Network-Specific Prefix) which a length of 96 bits (/96). 235 o IPv4 Prefix List: This is an optional field. The format of the 236 IPv4 Prefix List is shown in Figure 3. It is a list of zero or 237 more IPv4 Prefixes. Each entry is formed by IPv4-prelen and IPv4 238 Prefix. The total length of the field is 5*number of IPv4 239 prefixes. 241 o IPv4-prelen: The length of the IPv4 Prefix. 243 o IPv4 Prefix: The destination-based IPv4 Prefix. The length is 4 244 octets. 246 4. Client Behavior 248 The client requests the OPTION_NAT64_PREFIX_LIST option using the 249 Option Request option (ORO) in every Solicit, Request, Renew, Rebind, 250 and Information-request message. The NAT64-Type field defines the 251 mechanism being used. If the DHCPv6 server includes the 252 OPTION_NAT64_PREFIX_LIST option in its response, the DHCPv6 client 253 may use the contained NAT64-prefix to translate the destination IPv4 254 address into the destination IPv6 address. 256 When receiving the OPTION_NAT64_PREFIX option with IPv4 Prefix List, 257 the DHCPv6 client MUST record the received IPv6 prefix and the 258 corresponding IPv4 prefixes in IPv4 Prefix List. When receiving the 259 OPTION_NAT64_PREFIX option without IPv4 Prefix List, the DHCPv6 260 client MUST treat the IPv6 prefix and the default IPv4 prefix 261 0.0.0.0/0 as one of the records. 263 If the DHCPv6 client loses contact with the DHCPv6 server, the DHCPv6 264 client SHOULD clear the prefix(es) it learned from the DHCPv6 server. 266 When translating the destination IPv4 address into the destination 267 IPv6 address, DHCPv6 client MUST search an IPv4 routing database 268 using the longest-match-first rule and select the IPv6 prefix 269 offering that IPv4 prefix. 271 In order to make sure that the client has the right information, only 272 a single container with all the current NAT64 Prefix List Option is 273 allowed. When a new one is received, the client MUST clear the 274 previous NAT64 Prefix List Option information and use only the new 275 one. 277 5. Message Flow Illustration 279 The figure below shows an example of message flow for a Client 280 learning IPv6 prefixes using DHCPv6. 282 In this example, two IPv6 prefixes are provided by the DHCPv6 server. 283 The first IPv6 prefix is 2001:db8:122:300::/56, the corresponding 284 IPv4 prefixes are 192.0.2.0/24 and 198.51.100.0/24. The second IPv6 285 prefix is 2001:db8:122::/48, the corresponding IPv4 prefix is 286 192.0.2.128/25. 288 When the DHCPv6 client receives the packet with destination IPv4 289 address 192.0.2.1, according to the rule of longest prefix match, the 290 NAT64 with IPv6 prefix 2001:db8:122::/48 is chosen. In the same way, 291 the NAT64 with IPv6 prefix 2001:db8:122::/48 is chosen. 293 +---------------+ +-----------------+ 294 | DHCPv6 Client | | DHCPv6 server | 295 +---------------+ +-----------------+ 296 | DHCPv6 query for IPv6 prefix | 297 |--------------------------------------------------->| 298 | ORO with OPTION_NAT64_PREFIX_LIST | 299 | | 300 | DHCPv6 response with: | 301 | NAT64PREFIX{ | 302 | NAT64-v6-pre = 2001:db8:122:300::/56 | 303 | NAT64-v4-pre = 192.0.2.0/24 | 304 | NAT64-v4-pre = 198.51.100.0/24} | 305 | NAT64PREFIX{ | 306 | NAT64-v6-pre = 2001:db8:122::/48 | 307 | NAT64-v4-pre = 192.0.2.128/25} | 308 |<---------------------------------------------------| 309 | | 310 | 311 | +-----------------+ +-----------------+ 312 | | NAT64 1 | | NAT64 2 | 313 | +-----------------+ +-----------------+ 314 | NAT64-v6-pre = NAT64-v6-pre = 315 | 2001:db8:122:300::/56 2001:db8:122::/48 316 | NAT64-v4-pre = NAT64-v4-pre = 317 | 192.0.2.0/24 192.0.2.128/25 318 | 198.51.100.0/24 | 319 | | | 320 | Dest IPv4 addr: | | 321 | 192.0.2.1 | | 322 | Dest IPv6 addr: | | 323 | 2001:db8:122:300::c000:201 | | 324 |----------------------------->| | 325 | | | 326 | | 327 | Dest IPv4 addr: 192.0.2.193 | 328 | Dest IPv6 addr: 2001:db8:122::c000:2c1 | 329 |--------------------------------------------------->| 331 Figure 4: Example of the process flow 333 6. Security Considerations 335 Considerations for security in this type of environment are primarily 336 around the operation of the DHCPv6 protocol and the databases it 337 uses. 339 In the DHCPv6 server, should the database be compromised, it will 340 deliver incorrect data to its DHCPv6 clients. In the DHCPv6 client, 341 should its database be compromised by attack or polluted by an 342 incorrect DHCPv6 server database, it will route data incorrectly. In 343 both cases, the security of the systems and their databases in an 344 operational matter, not managed by protocol. 346 However, the operation of the DHCPv6 protocol itself is also required 347 to be correct - the server and its clients must recognize valid 348 requests and reject invalid ones. Therefore, DHCPv6 exchanges MUST 349 be secured as described in [RFC3315]. 351 7. IANA Considerations 353 We request that IANA allocate two DHCPv6 option codes for use by 354 OPTION_V6_PLATPREFIX_LIST and OPTION_V6_PLATPREFIX from the "Option 355 Codes" table. Similarly, a request to IANA for assigning the 356 NAT64-Type field codes. The following initial values are assigned in 357 this document (values are 16-bit unsigned intergers). 359 Name | Value | RFC 360 -----------------+---------+--------- 361 Unspecified | 0x00 | RFC6052 362 SIIT | 0x01 | RFC7915 363 Stateful NAT64 | 0x02 | RFC6146 364 EAM-SIIT | 0x03 | RFC7757 366 8. Acknowledgements 368 The authors will like to recognize the inputs from Tore Anderson in a 369 previous version of this work. Mohamed Boucadair provided very 370 significant inputs. 372 9. References 374 9.1. Normative References 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 382 C., and M. Carney, "Dynamic Host Configuration Protocol 383 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 384 2003, . 386 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 387 Combination of Stateful and Stateless Translation", 388 RFC 6877, DOI 10.17487/RFC6877, April 2013, 389 . 391 9.2. Informative References 393 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 394 and E. Lear, "Address Allocation for Private Internets", 395 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 396 . 398 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 399 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 400 DOI 10.17487/RFC6052, October 2010, 401 . 403 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 404 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 405 April 2011, . 407 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 408 NAT64: Network Address and Protocol Translation from IPv6 409 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 410 April 2011, . 412 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 413 Beijnum, "DNS64: DNS Extensions for Network Address 414 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 415 DOI 10.17487/RFC6147, April 2011, 416 . 418 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 419 the IPv6 Prefix Used for IPv6 Address Synthesis", 420 RFC 7050, DOI 10.17487/RFC7050, November 2013, 421 . 423 [RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of 424 Solution Proposals for Hosts to Learn NAT64 Prefix", 425 RFC 7051, DOI 10.17487/RFC7051, November 2013, 426 . 428 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 429 Mappings for Stateless IP/ICMP Translation", RFC 7757, 430 DOI 10.17487/RFC7757, February 2016, 431 . 433 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 434 "IP/ICMP Translation Algorithm", RFC 7915, 435 DOI 10.17487/RFC7915, June 2016, 436 . 438 Authors' Addresses 440 Lishan Li 441 Tsinghua University 442 Beijing 100084 443 P.R.China 445 Phone: +86-15201441862 446 Email: lilishan9248@126.com 448 Yong Cui 449 Tsinghua University 450 Beijing 100084 451 P.R.China 453 Phone: +86-10-6260-3059 454 Email: yong@csnet1.cs.tsinghua.edu.cn 456 Cong Liu 457 Tsinghua University 458 Beijing 100084 459 P.R.China 461 Phone: +86-10-6278-5822 462 Email: gnocuil@gmail.com 464 Jianping Wu 465 Tsinghua University 466 Beijing 100084 467 P.R.China 469 Phone: +86-10-6278-5983 470 Email: jianping@cernet.edu.cn 472 Fred Baker 473 Goleta, CA 93117 474 United States 476 Email: fredbaker.ietf@gmail.com 477 Jordi Palet Martinez 478 Consulintel, S.L. 479 La Navata - Galapagar 28420 480 Spain 482 Email: jordi.palet@consulintel.es