idnits 2.17.1 draft-ietf-behave-v4v6-bih-06.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 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document obsoletes RFC3338, but the abstract doesn't seem to directly say this. It does mention RFC3338 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 504 has weird spacing: '...address trans...' == Line 505 has weird spacing: '... app res. ...' == 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 (August 10, 2011) is 4644 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 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 2767 (Obsoleted by RFC 6535) -- Obsolete informational reference (is this intentional?): RFC 3338 (Obsoleted by RFC 6535) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave WG B. Huang 3 Internet-Draft H. Deng 4 Obsoletes: 3338, 2767 China Mobile 5 (if approved) T. Savolainen 6 Intended status: Standards Track Nokia 7 Expires: February 11, 2012 August 10, 2011 9 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) 10 draft-ietf-behave-v4v6-bih-06 12 Abstract 14 Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol 15 translation mechanism that allows a class of IPv4-only applications 16 that work through NATs to communicate with IPv6-only peers. The host 17 on which applications are running may be connected to IPv6-only or 18 dual-stack access networks. BIH hides IPv6 and makes the IPv4-only 19 applications think they are talking with IPv4 peers by local 20 synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC 21 3338. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 11, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Acknowledgement of previous work . . . . . . . . . . . . . 5 71 2. Components of the Bump-in-the-Host . . . . . . . . . . . . . . 6 72 2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 7 73 2.2. Protocol translator . . . . . . . . . . . . . . . . . . . 8 74 2.3. Extension Name Resolver . . . . . . . . . . . . . . . . . 8 75 2.3.1. Special exclusion sets for A and AAAA records . . . . 9 76 2.3.2. DNSSEC support . . . . . . . . . . . . . . . . . . . . 9 77 2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9 78 2.3.4. DNS cache in network-layer ENR . . . . . . . . . . . . 10 79 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10 80 3. Behavior and Network Examples . . . . . . . . . . . . . . . . 12 81 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 16 83 4.2. Socket bindings . . . . . . . . . . . . . . . . . . . . . 16 84 4.3. ICMP Message Handling . . . . . . . . . . . . . . . . . . 16 85 4.4. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 16 86 4.5. Multi-interface . . . . . . . . . . . . . . . . . . . . . 17 87 4.6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18 88 5. Considerations due ALG requirements . . . . . . . . . . . . . 19 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 7.1. Implications on End-to-End Security . . . . . . . . . . . 21 92 7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 21 93 7.3. Attacks on BIH . . . . . . . . . . . . . . . . . . . . . . 21 94 7.4. DNS considerations . . . . . . . . . . . . . . . . . . . . 22 95 8. Changes since RFC2767 and RFC3338 . . . . . . . . . . . . . . 23 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 100 Appendix A. API list intercepted by BIH . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 103 1. Introduction 105 This document describes Bump-in-the-Host (BIH), a successor and 106 combination of the Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the- 107 API (BIA) [RFC3338] technologies, which enable IPv4-only legacy 108 applications to communicate with IPv6-only servers by synthesizing 109 IPv4 addresses from AAAA records. Section 8 describes the reasons 110 for updating RFC2767 and RFC3338. 112 The supported class of applications includes those that use DNS for 113 IP address resolution and that do not embed IP address literals in 114 protocol payloads. This includes legacy client-server applications 115 using the DNS that are agnostic to the IP address family used by the 116 destination and that are able to do NAT traversal. The synthetic 117 IPv4 addresses shown to applications are taken from the RFC1918 118 private address pool in order to ensure that possible NAT traversal 119 techniques will be initiated. 121 IETF recommends using dual-stack or tunneling based solutions for 122 IPv6 transition and specifically recommends against deployments 123 utilizing double protocol translation. Use of BIH together with a 124 NAT64 is NOT RECOMMENDED [RFC6180]. 126 BIH includes two major implementation options: a protocol translator 127 between the IPv4 and the IPv6 stacks of a host, or an API translator 128 between the IPv4 socket API module and the TCP/IP module. 129 Essentially, IPv4 is translated into IPv6 at the socket API layer or 130 at the IP layer. 132 When BIH is implemented at the socket API layer, the translator 133 intercepts IPv4 socket API function calls and invokes corresponding 134 IPv6 socket API function calls to communicate with IPv6 hosts. 136 When BIH is implemented at the networking layer the IPv4 packets are 137 intercepted and converted to IPv6 using the IP conversion mechanism 138 defined in Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]. 139 The protocol translation has the same benefits and drawbacks as SIIT. 141 The location of the BIH refers to the location of the protocol 142 translation function. The location of DNS synthesis is orthogonal to 143 the location of protocol translation, and may or may not happen at 144 the same level. 146 BIH can be used whenever an IPv4-only application needs to 147 communicate with an IPv6-only server, independently of the address 148 families supported by the access network. Hence the access network 149 can be IPv6-only or dual-stack capable. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 [RFC2119] . 156 This document uses terms defined in [RFC2460] and [RFC4213]. 158 1.1. Acknowledgement of previous work 160 This document is a direct update to and directly derivative from 161 Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's Bump- 162 in-the-Stack [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin 163 Kim, Alain Durand, and Erik Nordmark's Bump-in-the-API [RFC3338], 164 which similarly provide a dual stack host means to communicate with 165 other IPv6 hosts using existing IPv4 applications. Section 7 covers 166 the changes since those documents. 168 2. Components of the Bump-in-the-Host 170 Figure 1 shows the architecture of a host in which BIH is implemented 171 as a socket API layer translator, i.e., as a "Bump-in-the-API". 173 +----------------------------------------------+ 174 | +------------------------------------------+ | 175 | | | | 176 | | IPv4 applications | | 177 | | | | 178 | +------------------------------------------+ | 179 | +------------------------------------------+ | 180 | | Socket API (IPv4, IPv6) | | 181 | +------------------------------------------+ | 182 | +-[ API translator]------------------------+ | 183 | | +-----------+ +---------+ +------------+ | | 184 | | | Ext. Name | | Address | | Function | | | 185 | | | Resolver | | Mapper | | Mapper | | | 186 | | +-----------+ +---------+ +------------+ | | 187 | +------------------------------------------+ | 188 | +--------------------+ +-------------------+ | 189 | | | | | | 190 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 191 | | | | | | 192 | +--------------------+ +-------------------+ | 193 +----------------------------------------------+ 195 Figure 1: Architecture of a dual stack host using protocol 196 translation at socket layer 198 Figure 2 shows the architecture of a host in which BIH is implemented 199 as a network layer translator, i.e., a "Bump-in-the-Stack". 201 +------------------------------------------------------------+ 202 | +------------------------------------------+ | 203 | | IPv4 applications | | 204 | | Host's main DNS resolver | | 205 | +------------------------------------------+ | 206 | +------------------------------------------+ | 207 | | TCP/UDP | | 208 | +------------------------------------------+ | 209 | +------------------------------------------+ +---------+ | 210 | | IPv4 | | | | 211 | +------------------------------------------+ | Address | | 212 | +------------------+ +---------------------+ | Mapper | | 213 | | Protocol | | Extension Name | | | | 214 | | Translator | | Resolver | | | | 215 | +------------------+ +---------------------+ | | | 216 | +------------------------------------------+ | | | 217 | | IPv4 / IPv6 | | | | 218 | +------------------------------------------+ +---------+ | 219 +------------------------------------------------------------+ 221 Figure 2: Architecture of a dual-stack host using protocol 222 translation at the network layer 224 Dual stack hosts defined in RFC 4213 [RFC4213] need applications, 225 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed 226 hosts in this document have an API or network-layer translator to 227 allow existing IPv4 applications to communicate with IPv6-only peers. 228 The BIH architecture consists of an Extension Name Resolver, an 229 Address Mapper, and depending on implementation either a Function 230 Mapper or a Protocol Translator. It is worth noting that the 231 Extension Name Resolver's placement is orthogonal to the placement of 232 protocol translation. For example, the Extension Name Resolver may 233 reside in the socket API while protocol translation takes place at 234 the networking layer. 236 2.1. Function Mapper 238 The function mapper translates an IPv4 socket API function into an 239 IPv6 socket API function. 241 When detecting IPv4 socket API function calls from IPv4 applications, 242 the function mapper MUST intercept the function calls and invoke IPv6 243 socket API functions that correspond to the IPv4 socket API 244 functions. 246 The function mapper MUST NOT perform function mapping when the 247 application is initiating communications to the address range used by 248 local synthesis and the address mapping table does not have an entry 249 mathching the address. 251 See Appendix A for an informational list of functions that would be 252 appropriate to intercept by the function mapper. 254 2.2. Protocol translator 256 The protocol translator translates IPv4 into IPv6 and vice versa 257 using the IP conversion mechanism defined in SIIT [RFC6145]. To 258 avoid unnecessary fragmentation, the host's IPv4 module should be 259 configured with a small enough MTU (IPv6 link MTU - 20 bytes). 261 Protocol translation cannot be performed for IPv4 packets sent to the 262 IPv4 address range used by local synthesis and for which a mapping 263 table entry does not exist. The implementation SHOULD attempt to 264 route such packets via IPv4 interfaces instead. 266 2.3. Extension Name Resolver 268 The Extension Name Resolver (ENR) returns an answer in response to 269 the IPv4 application's name resolution request. 271 In the case of the socket API layer implementation option, when an 272 IPv4 application tries to do a forward lookup to resolve names via 273 the resolver library (e.g., gethostbyname()), BIH intercepts the 274 function call and instead calls the IPv6 equivalent functions (e.g., 275 getaddrinfo()) that will resolve both A and AAAA records. This 276 implementation option is name resolution protocol agnostic, and hence 277 supports techniques such as "hosts-file", NetBIOS, mDNS, and anything 278 else the underlying operating system uses. 280 In the case of the network layer implementation option, the ENR 281 intercepts the A query and creates an additional AAAA query with 282 similar content. The ENR will then collect replies to both A and 283 AAAA queries and, depending on results, either return an A reply 284 unmodified or synthesize a new A reply. The network layer 285 implementation option will only be able to catch applications' name 286 resolution requests that result in actual DNS queries, hence is more 287 limited when compared to the socket API layer implementation option. 288 Hence the socket API layer option is RECOMMENDED. 290 In either implementation option, if there is a real IPv4 address 291 available, the ENR SHOULD NOT synthesize IPv4 addresses. By default 292 an ENR implementation MUST NOT synthesize IPv4 addresses when real 293 IPv4 addresses exist. 295 If only IPv6 addresses are available for the queried name, the ENR 296 asks the address mapper to assign a local IPv4 address corresponding 297 to each IPv6 address. 299 In the case of the API layer implementation option, the ENR will 300 simply make the API (e.g. gethostbyname) return the synthetic 301 address. In the case of the network-layer implementation option, the 302 ENR synthesizes an A record for the assigned IPv4 address, and 303 delivers it up the stack. If the response contains a CNAME or a 304 DNAME record, then the CNAME or DNAME chain is followed until the 305 first terminating A or AAAA record is reached. 307 Application | Network | ENR behavior 308 query | response | 309 ---------------+-----------------------+---------------------------- 310 IPv4 address(es) | IPv4 address(es) | return real IPv4 address(es) 311 IPv4 address(es) | IPv6 address(es) | synthesize IPv4 address(es) 312 IPv4 address(es) | IPv4/IPv6 address(es) | return real IPv4 address(es) 314 Figure 3: ENR behavior illustration 316 2.3.1. Special exclusion sets for A and AAAA records 318 An ENR implementation SHOULD by default exclude certain IPv4 and IPv6 319 addresses seen on received A and AAAA records. The addresses to be 320 excluded by default MAY include addresses such as those that should 321 not appear in the DNS or on the wire (see [RFC6147] section 5.1.4 and 322 [RFC5735]). Additional addresses MAY be excluded based on possibly 323 configurable local policies. 325 2.3.2. DNSSEC support 327 When the ENR is implemented at the network layer, the A record 328 synthesis can cause similar issues as are described in [RFC6147] 329 section 3. The main resolver of a host running BIH SHOULD NOT 330 perform validation of A records, as it will be impossible to validate 331 synthetic A records created by ENR. The ENR may support DNSSEC. 333 When the ENR is implemented at the socket API level, there are no 334 issues with DNSSEC use, as the ENR itself uses socket APIs for DNS 335 resolution. This approach is RECOMMENDED. 337 DNSSEC can also be supported by configuring the (stub) resolver on a 338 host to trust validations done by the ENR located at network layer or 339 alternatively the validating resolver can implement the ENR itself. 341 2.3.3. Reverse DNS lookup 343 When an application requests a reverse lookup for an IPv4 address, 344 the ENR MUST check whether the queried IPv4 address can be found in 345 the Address Mapper's mapping table and is a local IPv4 address. If 346 an entry is found and the queried address is locally generated, the 347 ENR MUST initiate a corresponding reverse lookup for the real IPv6 348 address. In the case where the application requested a reverse 349 lookup for an address not part of the local IPv4 address pool, e.g., 350 a global address, the request MUST be passed on unmodified. 352 For example, when an application requests a reverse lookup for a 353 synthesized locally valid IPv4 address, the ENR needs to intercept 354 that query. The ENR asks the address mapper for the IPv6 address 355 that corresponds to the IPv4 address. The ENR shall perform a 356 reverse lookup procedure for the destination's IPv6 address and 357 return the name received as a response to the application that 358 initiated the IPv4 query. 360 2.3.4. DNS cache in network-layer ENR 362 When BIH shuts down, e.g., due to an IPv4 interface becoming 363 available, BIH MUST flush the node's DNS cache of possible locally 364 generated entries. This cache may be in the network-layer ENR 365 itself, but also possibly host's caching stub resolver. 367 2.4. Address Mapper 369 The address mapper maintains a local IPv4 address pool. The pool 370 consists of private IPv4 addresses per section 4.3. Also, the 371 address mapper maintains a table consisting of pairs of locally 372 selected IPv4 addresses and destinations' IPv6 addresses. 374 When the extension name resolver, translator, or the function mapper 375 requests the address mapper to assign an IPv4 address corresponding 376 to an IPv6 address, the address mapper selects and returns an IPv4 377 address out of the local pool, and registers a new entry into the 378 table. The registration occurs in the following 3 cases: 380 (1) When the extension name resolver gets only IPv6 addresses for the 381 target host name and there is no existing mapping entry for the IPv6 382 addresses. One or more local IPv4 addresses will be returned to the 383 application and mappings for local IPv4 addresses to real IPv6 384 addresses are created. 386 (2) When the extension name resolver gets both IPv4 and IPv6 387 addresses, but the IPv4 addresses contain only excluded IPv4 388 addresses (e.g., 127.0.0.1). The behavior will follow case (1). 390 (3) When the function mapper gets a socket API function call 391 triggered by a received IPv6 packet and there is no existing mapping 392 entry for the IPv6 source address (for example, the client sent a UDP 393 request to an anycast address but a response was received from a 394 unicast address). 396 Other possible combinations are outside of BIH and BIH is not 397 involved in those. 399 3. Behavior and Network Examples 401 Figure 4 illustrates a very basic network scenario. An IPv4-only 402 application is running on a host attached to the IPv6-only Internet 403 and is talking to an IPv6-only server. Communication is made 404 possible by Bump-In-the-Host. 406 +----+ +-------------+ 407 | H1 |----------- IPv6 Internet -------- | IPv6 server | 408 +----+ +-------------+ 409 v4 only 410 application 412 Figure 4: Network Scenario #1 414 Figure 5 illustrates a possible network scenario where an IPv4-only 415 application is running on a host attached to a dual-stack network, 416 but the destination server is running on a private site that is 417 numbered with public IPv6 addresses and private IPv4 addresses 418 without port forwarding set up on the NAT44. The only means to 419 contact the server is to use IPv6. 421 +----------------------+ +------------------------------+ 422 | Dual Stack Internet | | IPv4 Private site (Net 10) | 423 | | | IPv6 routed site | 424 | +---------+ +----------+ | 425 | +-| NAT44 |-------------+ | | 426 | +----+ | +---------+ | | | 427 | | H1 |---------+ | | | Server | | 428 | +----+ | +-----------+ | | | 429 | v4 only +-|IPv6 Router|-----------+ | | 430 | application +-----------+ +----------+ | 431 | | | Dual Stack | 432 | | | 10.1.1.1 | 433 | | | 2001:DB8::1 | 434 +----------------------+ +------------------------------+ 436 Figure 5: Network Scenario #2 438 Illustrations of host behavior in both implementation options are 439 given here. Figure 6 illustrates a setup where BIH (including the 440 ENR) is implemented at the sockets API layer, and Figure 7 441 illustrates a setup where BIH (including the ENR) is implemented at 442 the network layer. 444 "dual stack" "host6" 445 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name 446 appli- API | ENR Address Function| (v6/v4) Server 447 cation | Mapper Mapper | 448 | | | | | | | | 449 <> | | | 450 | | | | | | | | 451 |------->|------->| Query IPv4 addresses for host6. | | 452 | | | | | | | | 453 | | |------------------------------------------------->| 454 | | | Query 'A' and 'AAAA' records for host6 | 455 | | | | | | | | 456 | | |<-------------------------------------------------| 457 | | | Reply with the 'AAAA' record. | | 458 | | | | | | | 459 | | |<> | 460 | | | | | | | 461 | | |+++++++>| Request one IPv4 address | 462 | | | | corresponding to the IPv6 address. 463 | | | | | | | 464 | | | |<> | 465 | | | | | | | 466 | | |<+++++++| Reply with the IPv4 address. | 467 | | | | | | | 468 |<-------|<-------| Reply with the IPv4 address | 469 | | | | | | | 470 | | | | | | | 471 <> | | | 472 | | | | | | | 473 |=======>|=========================>|An IPv4 Socket API function call 474 | | | | | | | 475 | | | |<+++++++| Request IPv6 addresses| 476 | | | | | corresponding to the | 477 | | | | | IPv4 addresses. | 478 | | | | | | | 479 | | | |+++++++>| Reply with the IPv6 addresses. 480 | | | | | | | 481 | | | | |<> 482 | | | | | | | 483 | An IPv6 Socket API function call.|=======================>| 484 | | | | | | | 485 | | | | |<> | 487 | | | | | | | 488 | An IPv6 Socket API function call.|<=======================| 489 | | | | | | | 490 | | | | |<> 491 | | | | | | | 492 | | | |<+++++++| Request IPv4 addresses| 493 | | | | | corresponding to the | 494 | | | | | IPv6 addresses. | 495 | | | | | | | 496 | | | |+++++++>| Reply with the IPv4 addresses. 497 | | | | | | | 498 |<=======|<=========================| An IPv4 Socket function call. 499 | | | | | | | 501 Figure 6: Example of BIH as API addition 503 "dual stack" "host6" 504 IPv4 stub TCP/ ENR address translator IPv6 505 app res. IPv4 mapper 506 | | | | | | | | 507 <> | | 508 |-->| | | | | | | 509 | |----------->| Query 'A' records for "host6". | Name 510 | | | | | | | | Server 511 | | | |------------------------------------------->| 512 | | | | Query 'A' and 'AAAA' records for "host6" 513 | | | | | | | | | 514 | | | |<-------------------------------------------| 515 | | | | Reply only with 'AAAA' record. | 516 | | | | | | | | 517 | | | |<> | 518 | | | | | | | | 519 | | | |-------->| Request one IPv4 address | 520 | | | | | corresponding to each IPv6 address. 521 | | | | | | | | 522 | | | | |<> | 523 | | | | | | | | 524 | | | |<--------| Reply with the IPv4 address. 525 | | | | | | | | 526 | | | |<> 527 | | | | | | | | 528 | |<-----------| Reply with the 'A' record. | | 529 | | | | | | | | 530 |<--|<>| | | 533 | | | | | | | | 534 |=======>|========================>| An IPv4 packet. | 535 | | | | | | | | 536 | | | | |<++++++| Request IPv6 addresses 537 | | | | | | corresponding to the IPv4 538 | | | | | | addresses. | 539 | | | | | | | | 540 | | | | |++++++>| Reply with the IPv6| 541 | | | | | | addresses. | 542 | | | | | | | | 543 | | | | | |<> 544 | | | | | | | | 545 | | | |An IPv6 packet. |==========>|========>| 546 | | | | | | | | 547 | | | | | <> 548 | | | | | | | | 549 | | | |An IPv6 packet. |<==========|<========| 550 | | | | | | | | 551 | | | | | |<> 552 | | | | | | | | 553 | | | | |<++++++|Request IPv4 addresses 554 | | | | | |corresponding to the | 555 | | | | | | IPv6 addresses. | 556 | | | | | | | | 557 | | | | |++++++>| Reply with the IPv4 addresses. 558 | | | | | | | | 559 |<=======|=========================| An IPv4 packet. | 560 | | | | | | | | 562 Figure 7: Example of BIH at the network layer 564 4. Considerations 566 4.1. Socket API Conversion 568 IPv4 socket API functions are translated into IPv6 socket API 569 functions that are semantically as identical as possible and vice 570 versa. See Appendix B for the API list intercepted by BIH. However, 571 some IPv4 socket API functions are not fully compatible with IPv6 572 since IPv4 supports features that are not present in IPv6, such as 573 SO_BROADCAST. 575 4.2. Socket bindings 577 BIH SHOULD select a source address for a socket from the recommended 578 source address pool if a socket used for communications has not been 579 explicitly bound to any IPv4 address. 581 The binding of an explicitly bound socket MUST NOT be changed by the 582 BIH. 584 4.3. ICMP Message Handling 586 When an application needs ICMP messages values (e.g., Type, Code, 587 etc.) sent from the network layer, ICMPv4 message values MAY be 588 translated into ICMPv6 message values based on SIIT [RFC6145], and 589 vice versa. 591 4.4. IPv4 Address Pool and Mapping Table 593 The address pool consists of the private IPv4 addresses as per 594 [RFC1918]. This pool can be implemented at different granularities 595 in the node, e.g., a single pool per node, or at some finer 596 granularity such as per-user or per-process. In the case of a large 597 number of IPv4 applications communicating with a large number of IPv6 598 servers, the available address space may be exhausted if the 599 granularity is not fine enough. This should be a rare event and 600 chances will decrease as IPv6 support increases. The applications 601 may use IPv4 addresses they learn for a much longer period than DNS 602 time-to-live indicates. Therefore, the mapping table entries should 603 be kept active for a long period of time. For example, a web browser 604 may initiate one DNS query and then create multiple TCP sessions over 605 time to the address it learns. When address mapping table clean-up 606 is required the BIH may utilize techniques used by network address 607 translators, such as described in [RFC2663], [RFC5382], and 608 [RFC5508]. 610 The RFC1918 address space was chosen because generally legacy 611 applications understand it as a private address space. A new 612 dedicated address space would run a risk of not being understood by 613 applications as private. 127/8 and 169.254/16 are rejected due to 614 possible assumptions applications may make when seeing those. 616 The RFC1918 addresses used by the BIH have a risk of conflicting with 617 addresses used in the host's possible IPv4 interfaces and 618 corresponding local networks. The conflicts can be mitigated, but 619 not fully avoided, by using less commonly used portions of the 620 RFC1918 address space. Addresses from 172.16/12 are thought to be 621 less likely to be in conflict than addresses from 10/8 or 192.168/16 622 spaces. A source address can usually be selected in a non- 623 conflicting manner, but a small possibility exists for synthesized 624 destination addresses being in conflict with real addresses used in 625 local IPv4 networks. 627 The RECOMMENDED IPv4 addresses are following: 629 Primary source addresses: 172.21.112.0/20. Source addresses have to 630 be allocated because applications use getsockname() calls and in the 631 network layer mode an IP address of the IPv4 interface has to be 632 shown (e.g., by 'ifconfig'). More than one address is allocated to 633 allow implementation flexibility, e.g., for cases where a host has 634 multiple IPv6 interfaces. The source addresses are from different 635 subnets than destination addresses to ensure applications would not 636 make on-link assumptions and would instead enable NAT traversal 637 functions. 639 Secondary source addresses: 10.170.224.0/20. These addresses are 640 recommended if a host has a conflict with primary source addresses. 642 Primary destination addresses: 10.170.160.0/20. The address mapper 643 will select destination addresses primarily out of this pool. 645 Secondary destination addresses: 172.21.80.0/20. The address mapper 646 will select destination addresses out of this pool if the node has a 647 dual-stack connection conflicting with primary destination addresses. 649 4.5. Multi-interface 651 In the case of dual-stack destinations BIH MUST NOT do protocol 652 translation from IPv4 to IPv6 when the host has any IPv4 interfaces, 653 native or tunneled, available for use. 655 It is possible that an IPv4 interface is activated during BIH 656 operation, for example if a node moves to a coverage area of an IPv4- 657 enabled network. In such an event, BIH MUST stop initiating protocol 658 translation sessions for new connections and BIH MAY disconnect 659 active sessions. The choice of disconnection is left for 660 implementations and it may depend on whether IPv4 address conflict 661 occurs between addresses used by BIH and addresses used by the new 662 IPv4 interface. 664 4.6. Multicast 666 Protocol translation for multicast is not supported. 668 5. Considerations due ALG requirements 670 No ALG functionality is specified herein as ALG design is generally 671 not encouraged for host-based translation and as BIH is intended for 672 applications that do not include IP addresses in protocol payloads. 674 6. IANA Considerations 676 There are no actions for IANA. 678 7. Security Considerations 680 The security considerations of BIH follows closely, but not 681 completely, those of NAT64 [RFC6146] and DNS64 [RFC6147]. The 682 following sections are copied from RFC6146 and RFC6147 and modified 683 for BIH scenario. 685 7.1. Implications on End-to-End Security 687 Any protocols that protect IP header information are essentially 688 incompatible with BIH. This implies that end-to-end IPsec 689 verification will fail when the Authentication Header (AH) is used 690 (both transport and tunnel mode) and when ESP is used in transport 691 mode. This is inherent in any network-layer translation mechanism. 692 End-to-end IPsec protection can be restored, using UDP encapsulation 693 as described in [RFC3948]. The actual extensions to support IPsec 694 are out of the scope of this document. 696 7.2. Filtering 698 BIH creates binding state using packets flowing from the IPv4 side to 699 the IPv6 side. In accordance with the procedures defined in this 700 document following the guidelines defined in [RFC4787], a BIH 701 implementation MUST offer "Endpoint-Independent Mapping". 703 Implementations MAY also provide support for "Address-Dependent 704 Mapping" following the guidelines defined in [RFC4787]. 706 The security properties, however, are determined by which packets the 707 BIH allows in and which it does not. The security properties are 708 determined by the filtering behavior and by the possible filtering 709 configuration in the filtering portions of the BIH, not by the 710 address mapping behavior. 712 7.3. Attacks on BIH 714 The BIH implementation itself is a potential victim of different 715 types of attacks. In particular, the BIH can be a victim of DoS 716 attacks. The BIH implementation has a limited number of resources 717 that can be consumed by attackers creating a DoS attack. The BIH has 718 a limited number of IPv4 addresses that it uses to create the 719 bindings. Even though the BIH performs address and port translation, 720 it is possible for an attacker to consume the synthetic IPv4 address 721 pool by triggering a host to issue DNS queries for names that cause 722 ENR to synthesise A records. DoS attacks can also affect other 723 limited resources available in the host running BIH such as memory or 724 link capacity. For instance, it is possible for an attacker to 725 launch a DoS attack on the memory of the BIH running device by 726 sending fragments that the BIH will store for a given period. If the 727 number of fragments is high enough, the memory of the host could be 728 exhausted. BIN implementations MUST implement proper protection 729 against such attacks, for instance, allocating a limited amount of 730 memory for fragmented packet storage. 732 Another consideration related to BIH resource depletion refers to the 733 preservation of binding state. Attackers may try to keep a binding 734 state alive forever by sending periodic packets that refresh the 735 state. In order to allow the BIH to defend against such attacks, the 736 BIH implementation MAY choose not to extend the session entry 737 lifetime for a specific entry upon the reception of packets for that 738 entry through the external interface. 740 7.4. DNS considerations 742 BIH operates in combination with the DNS, and is therefore subject to 743 whatever security considerations are appropriate to the DNS mode in 744 which the BIH is operating (i.e., authoritative, recursive, or stub- 745 resolver mode). 747 BIH has the potential to interfere with the functioning of DNSSEC, 748 because BIH modifies DNS answers, and DNSSEC is designed to detect 749 such modifications and to treat modified answers as bogus. 751 8. Changes since RFC2767 and RFC3338 753 This document combines and obsoletes both [RFC2767] and [RFC3338]. 755 The changes in this document mainly reflect the following components: 757 1. Supporting IPv6-only network connections 759 2. The IPv4 address pool uses private address instead of reserved 760 IPv4 addresses (0.0.0.1 - 0.0.0.255) 762 3. Extending ENR and address mapper to operate differently 764 4. Adding an alternative way to implement the ENR 766 5. Standards track instead of experimental/informational 768 6. Supporting reverse (PTR) queries 770 9. Acknowledgments 772 The authors thank the discussion from Gang Chen, Dapeng Liu, Bo Zhou, 773 Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of 774 this document. 776 The efforts of Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco 777 Cortes, Marnix Goossens, Ala Hamarsheh, Ed Jankiewizh, Suresh 778 Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu, 779 Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, Dave 780 Harrington, and James Woodyatt in reviewing this document are 781 gratefully acknowledged. 783 Special acknowledgements go to Dave Thaler for his extensive review 784 and support. 786 The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, 787 Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. 788 The authors of RFC3338 acknowledged implementation contributions by 789 Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation 790 (www.i2soft.net). 792 The authors of Bump-in-the-Wire (BIW) (draft-ietf-biw-00.txt, October 793 2006), P. Moster, L. Chin, and D. Green, are acknowledged. Some 794 ideas and clarifications from BIW have been adapted to this document. 796 10. References 798 10.1. Normative References 800 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 801 E. Lear, "Address Allocation for Private Internets", 802 BCP 5, RFC 1918, February 1996. 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, March 1997. 807 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 808 (IPv6) Specification", RFC 2460, December 1998. 810 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 811 for IPv6 Hosts and Routers", RFC 4213, October 2005. 813 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 814 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 815 RFC 4787, January 2007. 817 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 818 Algorithm", RFC 6145, April 2011. 820 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 821 NAT64: Network Address and Protocol Translation from IPv6 822 Clients to IPv4 Servers", RFC 6146, April 2011. 824 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 825 Beijnum, "DNS64: DNS Extensions for Network Address 826 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 827 April 2011. 829 10.2. Informative References 831 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 832 Translator (NAT) Terminology and Considerations", 833 RFC 2663, August 1999. 835 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 836 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 837 RFC 2767, February 2000. 839 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 840 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 841 RFC 3338, October 2002. 843 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 845 Stevens, "Basic Socket Interface Extensions for IPv6", 846 RFC 3493, February 2003. 848 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 849 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 850 RFC 3948, January 2005. 852 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 853 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 854 RFC 5382, October 2008. 856 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 857 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 858 April 2009. 860 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 861 BCP 153, RFC 5735, January 2010. 863 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 864 Transition Mechanisms during IPv6 Deployment", RFC 6180, 865 May 2011. 867 Appendix A. API list intercepted by BIH 869 The following informational list includes API functions that would be 870 appropriate to intercept by BIH module when implemented at socket 871 layer. Please note that this list may not be fully exhaustive. 873 The functions that the application uses to pass addresses into the 874 system are: 876 bind() 878 connect() 880 sendmsg() 882 sendto() 884 gethostbyaddr() 886 getnameinfo() 888 The functions that return an address from the system to an 889 application are: 891 accept() 893 recvfrom() 895 recvmsg() 897 getpeername() 899 getsockname() 901 gethostbyname() 903 getaddrinfo() 905 The functions that are related to socket options are: 907 getsocketopt() 909 setsocketopt() 911 As well, raw sockets for IPv4 and IPv6 MAY be intercepted. 913 Most of the socket functions require a pointer to the socket address 914 structure as an argument. Each IPv4 argument is mapped into 915 corresponding an IPv6 argument, and vice versa. 917 According to [RFC3493], the following new IPv6 basic APIs and 918 structures are required. 920 IPv4 new IPv6 921 ------------------------------------------------ 922 AF_INET AF_INET6 923 sockaddr_in sockaddr_in6 924 gethostbyname() getaddrinfo() 925 gethostbyaddr() getnameinfo() 926 inet_ntoa()/inet_addr() inet_pton()/inet_ntop() 927 INADDR_ANY in6addr_any 929 Figure 8 931 BIH MAY intercept inet_ntoa() and inet_addr() and use the address 932 mapper for those. Doing that enables BIH to support literal IP 933 addresses. However, IPv4 address literals can only be used after a 934 mapping entry between the IPv4 address and corresponding IPv6 address 935 has been created. 937 The gethostbyname() and getaddrinfo() calls return a list of 938 addresses. When the name resolver function invokes getaddrinfo() and 939 getaddrinfo() returns multiple IP addresses, whether IPv4 or IPv6, 940 they SHOULD all be represented in the addresses returned by 941 gethostbyname(). Thus if getaddrinfo() returns multiple IPv6 942 addresses, this implies that multiple address mappings will be 943 created; one for each IPv6 address. 945 Authors' Addresses 947 Bill Huang 948 China Mobile 949 53A,Xibianmennei Ave., 950 Xuanwu District, 951 Beijing 100053 952 China 954 Email: bill.huang@chinamobile.com 956 Hui Deng 957 China Mobile 958 53A,Xibianmennei Ave., 959 Xuanwu District, 960 Beijing 100053 961 China 963 Email: denghui02@gmail.com 965 Teemu Savolainen 966 Nokia 967 Hermiankatu 12 D 968 FI-33720 TAMPERE 969 Finland 971 Email: teemu.savolainen@nokia.com