idnits 2.17.1 draft-ietf-behave-v4v6-bih-08.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 5 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 559 has weird spacing: '...address trans...' == Line 560 has weird spacing: '... app res. I...' == 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 (December 23, 2011) is 4507 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: June 25, 2012 December 23, 2011 9 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) 10 draft-ietf-behave-v4v6-bih-08 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 document obsoletes RFC 2767 and 21 RFC 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 June 25, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 71 1.2. Acknowledgement of previous work . . . . . . . . . . . . . 5 72 2. Components of the Bump-in-the-Host . . . . . . . . . . . . . . 6 73 2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 8 74 2.2. Protocol translator . . . . . . . . . . . . . . . . . . . 8 75 2.3. Extension Name Resolver . . . . . . . . . . . . . . . . . 8 76 2.3.1. Special exclusion sets for A and AAAA records . . . . 9 77 2.3.2. DNSSEC support . . . . . . . . . . . . . . . . . . . . 10 78 2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 10 79 2.3.4. DNS caches and synthetic IPv4 addresses . . . . . . . 10 80 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 11 81 3. Behavior and Network Examples . . . . . . . . . . . . . . . . 12 82 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16 83 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 16 84 4.2. Socket bindings . . . . . . . . . . . . . . . . . . . . . 16 85 4.3. ICMP Message Handling . . . . . . . . . . . . . . . . . . 16 86 4.4. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 16 87 4.5. Multi-interface . . . . . . . . . . . . . . . . . . . . . 17 88 4.6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18 89 5. Application-Level Gateway requirements considerations . . . . 19 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 7.1. Implications on End-to-End Security . . . . . . . . . . . 21 93 7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 21 94 7.3. Attacks on BIH . . . . . . . . . . . . . . . . . . . . . . 21 95 7.4. DNS considerations . . . . . . . . . . . . . . . . . . . . 22 96 8. Changes since RFC2767 and RFC3338 . . . . . . . . . . . . . . 23 97 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 101 Appendix A. API list intercepted by BIH . . . . . . . . . . . . . 27 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 104 1. Introduction 106 This document describes Bump-in-the-Host (BIH), a successor and 107 combination of the Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the- 108 API (BIA) [RFC3338] technologies, which enable IPv4-only legacy 109 applications to communicate with IPv6-only servers by synthesizing 110 IPv4 addresses from AAAA records. Section 8 describes the reasons 111 for making RFC2767 and RFC3338 obsolete. 113 The supported class of applications includes those that use DNS for 114 IP address resolution and that do not embed IP address literals in 115 application-protocol payloads. This includes legacy client-server 116 applications using the DNS that are agnostic to the IP address family 117 used by the destination and that are able to do NAT traversal. The 118 synthetic IPv4 addresses shown to applications are taken from the 119 RFC1918 private address pool in order to ensure that possible NAT 120 traversal techniques will be initiated. 122 IETF recommends using dual-stack or tunneling based solutions for 123 IPv6 transition and specifically recommends against deployments 124 utilizing double protocol translation. Use of BIH together with a 125 NAT64 is NOT RECOMMENDED [RFC6180]. 127 BIH includes two major implementation alternatives: a protocol 128 translator between the IPv4 and the IPv6 stacks of a host, or an API 129 translator between the IPv4 socket API module and the TCP/IP module. 130 Essentially, IPv4 is translated into IPv6 at the socket API layer or 131 at the IP layer, former of which is the recommended implementation 132 alternative. 134 When BIH is implemented at the socket API layer, the translator 135 intercepts IPv4 socket API function calls and invokes corresponding 136 IPv6 socket API function calls to communicate with IPv6 hosts. 138 When BIH is implemented at the network layer the IPv4 packets are 139 intercepted and converted to IPv6 using the IP conversion mechanism 140 defined in Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]. 141 The protocol translation has the same benefits and drawbacks as SIIT. 143 The location of the BIH refers to the location of the protocol 144 translation function. The location of the IPv4 address and DNS A 145 record synthesis function is orthogonal to the location of the 146 protocol translation, and may or may not happen at the same location. 148 BIH can be used whenever an IPv4-only application needs to 149 communicate with an IPv6-only server, independently of the address 150 families supported by the access network. Hence the access network 151 can be IPv6-only or dual-stack capable. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in 156 [RFC2119] . 158 This document uses terms defined in [RFC2460] and [RFC4213]. 160 1.1. Terminology 162 DNS synthesis 164 DNS, A record, synthesis is a process where A type of DNS record 165 is created by Extension Name Resolver to contain synthetic IPv4 166 address. 168 Real IPv4 address 170 An IPv4 address of a remote node a host has learned, for example, 171 from DNS response to an A query. Real IPv4 address is opposite to 172 synthetic IPv4 address. 174 Real IPv6 address 176 An IPv6 address of a remote node a host has learned, for example, 177 from DNS response to an AAAA query. 179 Synthetic IPv4 address 181 An IPv4 address that has meaning only inside a host and that is 182 used to provide IPv4 representation of remote node's real IPv6 183 address. 185 1.2. Acknowledgement of previous work 187 This document is a direct derivative from Kazuaki TSHUCHIYA, 188 Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's Bump-in-the-Stack 189 [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain 190 Durand, and Erik Nordmark's Bump-in-the-API [RFC3338], which 191 similarly provides IPv4-only applications on dual-stack hosts the 192 means to operate over IPv6. Section 8 covers the changes since those 193 documents. 195 2. Components of the Bump-in-the-Host 197 Figure 1 shows the architecture of a host in which BIH is implemented 198 as a socket API layer translator, i.e., as a "Bump-in-the-API". 200 +----------------------------------------------+ 201 | +------------------------------------------+ | 202 | | | | 203 | | IPv4 applications | | 204 | | | | 205 | +------------------------------------------+ | 206 | +------------------------------------------+ | 207 | | Socket API (IPv4, IPv6) | | 208 | +------------------------------------------+ | 209 | +-[ API translator]------------------------+ | 210 | | +-----------+ +---------+ +------------+ | | 211 | | | Ext. Name | | Address | | Function | | | 212 | | | Resolver | | Mapper | | Mapper | | | 213 | | +-----------+ +---------+ +------------+ | | 214 | +------------------------------------------+ | 215 | +--------------------+ +-------------------+ | 216 | | | | | | 217 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 218 | | | | | | 219 | +--------------------+ +-------------------+ | 220 +----------------------------------------------+ 222 Figure 1: Architecture of a dual stack host using protocol 223 translation at socket layer 225 Figure 2 shows the architecture of a host in which BIH is implemented 226 as a network layer translator, i.e., a "Bump-in-the-Stack". 228 +------------------------------------------------------------+ 229 | +------------------------------------------+ | 230 | | IPv4 applications | | 231 | | Host's main DNS resolver | | 232 | +------------------------------------------+ | 233 | +------------------------------------------+ | 234 | | TCP/UDP | | 235 | +------------------------------------------+ | 236 | +------------------------------------------+ +---------+ | 237 | | IPv4 | | | | 238 | +------------------------------------------+ | Address | | 239 | +------------------+ +---------------------+ | Mapper | | 240 | | Protocol | | Extension Name | | | | 241 | | Translator | | Resolver | | | | 242 | +------------------+ +---------------------+ | | | 243 | +------------------------------------------+ | | | 244 | | IPv4 / IPv6 | | | | 245 | +------------------------------------------+ +---------+ | 246 +------------------------------------------------------------+ 248 Figure 2: Architecture of a dual-stack host using protocol 249 translation at the network layer 251 Dual stack hosts defined in RFC 4213 [RFC4213] need applications, 252 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed 253 hosts in this document have an API or network-layer translator to 254 allow legacy IPv4 applications to communicate with IPv6-only peers. 255 The BIH architecture consists of an Extension Name Resolver, an 256 Address Mapper, and depending on implementation either a Function 257 Mapper or a Protocol Translator. It is worth noting that the 258 Extension Name Resolver's placement is orthogonal to the placement of 259 protocol translation. For example, the Extension Name Resolver may 260 reside in the socket API while protocol translation takes place at 261 the network layer. 263 The choice between the socket API and the network layer architectures 264 varies case by case. While the socket API architecture alternative 265 is the recommended one, it may not always be possible to choose. 266 This may be the case, for example, when the used operating system 267 does not allow modifications to be done for API implementations, but 268 does allow addition of virtual network interfaces and related 269 software modules. On the other hand, sometimes it may not be 270 possible to introduce protocol translators inside the operating 271 system, but it may be easy to modify implementations behind the API 272 provided for applications. The choice of architecture also depends 273 on who is creating implementation of BIH. For example, an 274 application framework provider, an operating system provider, and a 275 device vendor may all choose different approaches due their different 276 positions. 278 2.1. Function Mapper 280 The function mapper translates an IPv4 socket API function into an 281 IPv6 socket API function. 283 When detecting IPv4 socket API function calls from IPv4 applications, 284 the function mapper MUST intercept the function calls and invoke IPv6 285 socket API functions that correspond to the IPv4 socket API 286 functions. 288 The function mapper MUST NOT perform function mapping when the 289 application is initiating communications to the address range used by 290 local synthesis and the address mapping table does not have an entry 291 mathching the address. 293 See Appendix A for an informational list of functions that would be 294 appropriate to intercept by the function mapper. 296 2.2. Protocol translator 298 The protocol translator translates IPv4 into IPv6 and vice versa 299 using the IP conversion mechanism defined in SIIT [RFC6145]. To 300 avoid unnecessary fragmentation, the host's IPv4 module SHOULD be 301 configured with a small enough MTU (MTU of the IPv6 enabled link - 20 302 bytes). 304 Protocol translation cannot be performed for IPv4 packets sent to the 305 IPv4 address range used by local synthesis and for which a mapping 306 table entry does not exist. The implementation SHOULD attempt to 307 route such packets via IPv4 interfaces instead. 309 2.3. Extension Name Resolver 311 The Extension Name Resolver (ENR) returns an answer in response to 312 the IPv4 application's name resolution request. 314 In the case of the socket API layer implementation alternative, when 315 an IPv4 application tries to do a forward lookup to resolve names via 316 the resolver library (e.g., gethostbyname()), BIH intercepts the 317 function call and instead calls the IPv6 equivalent functions (e.g., 318 getaddrinfo()) that will resolve both A and AAAA records. This 319 implementation alternative is name resolution protocol agnostic, and 320 hence supports techniques such as "hosts-file", NetBIOS, mDNS, and 321 anything else the underlying operating system uses. 323 In the case of the network layer implementation alternative, the ENR 324 intercepts the A query and creates an additional AAAA query with 325 similar content. The ENR will then collect replies to both A and 326 AAAA queries and, depending on results, either return an A reply 327 unmodified or synthesize a new A reply. If no reply for A query is 328 received after 300 ms since reception of positive AAAA response, the 329 ENR MAY choose to proceed as if there were only AAAA record available 330 for the destination. 332 The network layer implementation alternative will only be able to 333 catch applications' name resolution requests that result in actual 334 DNS queries, hence is more limited when compared to the socket API 335 layer implementation alternative. Hence the socket API layer 336 alternative is RECOMMENDED. 338 In either implementation alternative, if DNS A record reply contains 339 non-excluded real IPv4 addresses the ENR MUST NOT synthesize IPv4 340 addresses. 342 The ENR asks the address mapper to assign a synthetic IPv4 address 343 corresponding to each received IPv6 address if the A record query 344 resulted in negative response, all received real IPv4 addresses were 345 excluded, or the A query timed out. The timeout value is 346 implementation specific and may be short in order to provide good 347 user experience. 349 In the case of the API layer implementation alternative, the ENR will 350 simply make the API (e.g. gethostbyname) return the synthetic IPv4 351 address. In the case of the network-layer implementation 352 alternative, the ENR synthesizes an A record for the assigned 353 synthetic IPv4 address, and delivers it up the stack. If the 354 response contains a CNAME or a DNAME record, then the CNAME or DNAME 355 chain is followed until the first terminating A or AAAA record is 356 reached. 358 Application | Network | ENR behavior 359 query | response | 360 ---------------+-----------------------+---------------------------- 361 IPv4 address(es) | IPv4 address(es) | return real IPv4 address(es) 362 IPv4 address(es) | IPv6 address(es) | synthesize IPv4 address(es) 363 IPv4 address(es) | IPv4/IPv6 address(es) | return real IPv4 address(es) 365 Figure 3: ENR behavior illustration 367 2.3.1. Special exclusion sets for A and AAAA records 369 An ENR implementation SHOULD by default exclude certain real IPv4 and 370 IPv6 addresses seen on received A and AAAA records. The addresses to 371 be excluded by default MAY include addresses such as those that 372 should not appear in the DNS or on the wire (see [RFC6147] section 373 5.1.4 and [RFC5735]). Additional addresses MAY be excluded based on 374 possibly configurable local policies. 376 2.3.2. DNSSEC support 378 When the ENR is implemented at the network layer, the A record 379 synthesis can cause similar issues as are described in [RFC6147] 380 section 3. While running BIH, the main resolver of the host SHOULD 381 NOT perform validation of A records as synthetic A records created by 382 ENR would fail in validation. While not running BIH, host's resolver 383 can use DNSSEC in the same way that any other resolver can. The ENR 384 MAY support DNSSEC, in which case the (stub) resolver on a host can 385 be configured to trust validations done by the ENR located at the 386 network layer. In some cases the host's validating stub resolver can 387 implement the ENR by itself. 389 When the ENR is implemented at the socket API level, there are no 390 issues with DNSSEC use, as the ENR itself uses socket APIs for DNS 391 resolution. This approach is RECOMMENDED. 393 2.3.3. Reverse DNS lookup 395 When an application requests a reverse lookup (PTR query) for an IPv4 396 address, the ENR MUST check whether the queried IPv4 address can be 397 found in the Address Mapper's mapping table and is a synthetic IPv4 398 address. If an entry is found and the queried IPv4 address is 399 synthetic, the ENR MUST initiate a corresponding reverse lookup for 400 the real IPv6 address. In the case where the application requested a 401 reverse lookup for an address not part of the synthetic IPv4 address 402 pool, e.g., a global address, the request MUST be passed on 403 unmodified. 405 For example, when an application requests a reverse lookup for a 406 synthetic IPv4 address, the ENR needs to intercept that query. The 407 ENR asks the address mapper for the real IPv6 address that 408 corresponds to the synthetic IPv4 address. The ENR shall perform a 409 reverse lookup procedure for the destination's IPv6 address and 410 return the name received as a response to the application that 411 initiated the IPv4 query. 413 2.3.4. DNS caches and synthetic IPv4 addresses 415 When BIH shuts down or address mapping table entries are cleared for 416 any reason, DNS cache entries for synthetic IPv4 addresses MUST be 417 flushed. There may be a DNS cache in the network-layer ENR itself, 418 but also at the host's stub resolver. 420 2.4. Address Mapper 422 The address mapper maintains an IPv4 address pool that can be used 423 for IPv4 address synthesis. The pool consists of [RFC1918] IPv4 424 addresses as per section 4.4. Also, the address mapper maintains a 425 table consisting of pairs of synthetic IPv4 addresses and 426 destinations' real IPv6 addresses. 428 When the extension name resolver, translator, or the function mapper 429 requests the address mapper to assign a synthetic IPv4 address 430 corresponding to an IPv6 address, the address mapper selects and 431 returns an IPv4 address out of the local pool, and registers a new 432 entry into the table. The registration occurs in the following three 433 cases: 435 (1) When the extension name resolver gets only IPv6 addresses for the 436 target host name and there is no existing mapping entry for the IPv6 437 addresses. One or more synthetic IPv4 addresses will be returned to 438 the application and mappings for synthetic IPv4 addresses to real 439 IPv6 addresses are created. 441 (2) When the extension name resolver gets both real IPv4 and IPv6 442 addresses, but the real IPv4 addresses contain only excluded IPv4 443 addresses (e.g., 127.0.0.1). The behavior will follow case (1). 445 (3) When the function mapper is triggered by a received IPv6 packet 446 and there is no existing mapping entry for the IPv6 source address 447 (for example, the client sent a UDP request to an anycast address but 448 a response was received from a unicast address). 450 Other possible combinations are outside of BIH and BIH is not 451 involved in those. 453 3. Behavior and Network Examples 455 Figure 4 illustrates a very basic network scenario. An IPv4-only 456 application is running on a host attached to the IPv6-only Internet 457 and is talking to an IPv6-only server. Communication is made 458 possible by Bump-In-the-Host. 460 +----+ +-------------+ 461 | H1 |----------- IPv6 Internet -------- | IPv6 server | 462 +----+ +-------------+ 463 v4 only 464 application 466 Figure 4: Network Scenario #1 468 Figure 5 illustrates a possible network scenario where an IPv4-only 469 application is running on a host attached to a dual-stack network, 470 but the destination server is running on a private site that is 471 numbered with public IPv6 addresses and not globally reachable IPv4 472 addresses, such as [RFC1918] addresses, without port forwarding set 473 up on the NAT44. The only means to contact the server is to use 474 IPv6. 476 +----------------------+ +------------------------------+ 477 | Dual Stack Internet | | IPv4 Private site (Net 10) | 478 | | | IPv6 routed site | 479 | +---------+ +----------+ | 480 | +-| NAT44 |-------------+ | | 481 | +----+ | +---------+ | | | 482 | | H1 |---------+ | | | Server | | 483 | +----+ | +-----------+ | | | 484 | v4 only +-|IPv6 Router|-----------+ | | 485 | application +-----------+ +----------+ | 486 | | | Dual Stack | 487 | | | 10.1.1.1 | 488 | | | 2001:DB8::1 | 489 +----------------------+ +------------------------------+ 491 Figure 5: Network Scenario #2 493 Illustrations of host behavior in both implementation alternatives 494 are given here. Figure 6 illustrates a setup where BIH (including 495 the ENR) is implemented at the sockets API layer, and Figure 7 496 illustrates a setup where BIH (including the ENR) is implemented at 497 the network layer. 499 "dual stack" "host6" 500 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name 501 appli- API | ENR Address Function| (v6/v4) Server 502 cation | Mapper Mapper | 503 | | | | | | | | 504 <> | | | 505 | | | | | | | | 506 |------->|------->| Query IPv4 addresses for host6. | | 507 | | | | | | | | 508 | | |------------------------------------------------->| 509 | | | Query 'A' and 'AAAA' records for host6 | 510 | | | | | | | | 511 | | |<-------------------------------------------------| 512 | | | Reply with the 'AAAA' record. | | 513 | | | | | | | 514 | | |<> | 515 | | | | | | | 516 | | |+++++++>| Request synthetic IPv4 address | 517 | | | | corresponding to the IPv6 address. 518 | | | | | | | 519 | | | |<> 520 | | | | | | | 521 | | |<+++++++| Reply with the synthetic IPv4 address. 522 | | | | | | | 523 |<-------|<-------| Reply with the IPv4 address | 524 | | | | | | | 525 | | | | | | | 526 <> | | | 527 | | | | | | | 528 |=======>|=========================>|An IPv4 Socket API action 529 | | | | | | | 530 | | | |<+++++++| Request IPv6 addresses| 531 | | | | | corresponding to the | 532 | | | | | synthetic IPv4 addresses. 533 | | | | | | | 534 | | | |+++++++>| Reply with the IPv6 addresses. 535 | | | | | | | 536 | | | | |<> 537 | | | | | | | 538 | An IPv6 Socket API action |=======================>| 539 | | | | | | | 540 | | | | |<> | 542 | | | | | | | 543 | An IPv6 Socket API action |<=======================| 544 | | | | | | | 545 | | | | |<> 546 | | | | | | | 547 | | | |<+++++++| Request synthetic IPv4 addresses 548 | | | | | corresponding to the | 549 | | | | | IPv6 addresses. | 550 | | | | | | | 551 | | | |+++++++>| Reply with the IPv4 addresses. 552 | | | | | | | 553 |<=======|<=========================| An IPv4 Socket API action 554 | | | | | | | 556 Figure 6: Example of BIH as API addition 558 "dual stack" "host6" 559 IPv4 stub TCP/ ENR address translator IPv6 560 app res. IPv4 mapper 561 | | | | | | | | 562 <> | | 563 |-->| | | | | | | 564 | |----------->| Query 'A' records for "host6". | Name 565 | | | | | | | | Server 566 | | | |------------------------------------------->| 567 | | | | Query 'A' and 'AAAA' records for "host6" 568 | | | | | | | | | 569 | | | |<-------------------------------------------| 570 | | | | Reply only with 'AAAA' record. | 571 | | | | | | | | 572 | | | |<> | 573 | | | | | | | | 574 | | | |-------->| Request synthetic IPv4 address 575 | | | | | corresponding to each IPv6 address. 576 | | | | | | | | 577 | | | | |<> 578 | | | | | | | | 579 | | | |<--------| Reply with the synthetic IPv4 address. 580 | | | | | | | | 581 | | | |<> 582 | | | | | | | | 583 | |<-----------| Reply with the 'A' record. | | 584 | | | | | | | | 585 |<--|<>| | | 588 | | | | | | | | 589 |=======>|========================>| An IPv4 packet. | 590 | | | | | | | | 591 | | | | |<++++++| Request IPv6 addresses 592 | | | | | | corresponding to the 593 | | | | | | synthetic IPv4 addresses. 595 | | | | | | | | 596 | | | | |++++++>| Reply with the IPv6| 597 | | | | | | addresses. | 598 | | | | | | | | 599 | | | | | |<> 600 | | | | | | | | 601 | | | |An IPv6 packet. |==========>|========>| 602 | | | | | | | | 603 | | | | | <> 604 | | | | | | | | 605 | | | |An IPv6 packet. |<==========|<========| 606 | | | | | | | | 607 | | | | | |<> 608 | | | | | | | | 609 | | | | |<++++++| Request synthetic IPv4 610 | | | | | | addresses corresponding 611 | | | | | | to the IPv6 addresses. 612 | | | | | | | | 613 | | | | |++++++>| Reply with the IPv4 addresses. 614 | | | | | | | | 615 |<=======|=========================| An IPv4 packet. | 616 | | | | | | | | 618 Figure 7: Example of BIH at the network layer 620 4. Considerations 622 4.1. Socket API Conversion 624 IPv4 socket API functions are translated into IPv6 socket API 625 functions that are semantically as identical as possible and vice 626 versa. See Appendix B for the API list intercepted by BIH. However, 627 some IPv4 socket API functions are not fully compatible with IPv6 628 since IPv4 supports features that are not present in IPv6, such as 629 SO_BROADCAST. 631 4.2. Socket bindings 633 BIH SHOULD select a source address for a socket from the recommended 634 source address pool if a socket used for communications has not been 635 explicitly bound to any IPv4 address. 637 The binding of an explicitly bound socket MUST NOT be changed by the 638 BIH. 640 4.3. ICMP Message Handling 642 ICMPv4 and ICMPv6 messages MUST be translated as defined by SIIT 643 [RFC6145]. In the network layer implementation alternative, protocol 644 translator MUST translate ICMPv6 packets to ICMPv4 and vice versa, 645 and in the socket API implementation alternative, the socket API MUST 646 handle conversions in similar fashion. 648 4.4. IPv4 Address Pool and Mapping Table 650 The address pool consists of the [RFC1918] private IPv4 addresses. 651 This pool can be implemented at different granularities in the node, 652 e.g., a single pool per node, or at some finer granularity such as 653 per-user or per-process. In the case of a large number of IPv4 654 applications communicating with a large number of IPv6 servers, the 655 available address space may be exhausted if the granularity is not 656 fine enough. This should be a rare event and chances will decrease 657 as IPv6 support increases. The applications may use IPv4 addresses 658 they learn for a much longer period than DNS time-to-live indicates. 659 Therefore, the mapping table entries should be kept active for a long 660 period of time. For example, a web browser may initiate one DNS 661 query and then create multiple TCP sessions over time to the address 662 it learns. When address mapping table clean-up is required, the BIH 663 may utilize techniques used by network address translators, such as 664 described in [RFC2663], [RFC5382], and [RFC5508]. 666 The RFC1918 address space was chosen because generally legacy 667 applications understand it as a private address space. A new 668 dedicated address space would run a risk of not being understood by 669 applications as private. 127/8 and 169.254/16 are rejected due to 670 possible assumptions applications may make when seeing those. 672 The RFC1918 addresses used by the BIH have a risk of conflicting with 673 addresses used in the host's possible IPv4 interfaces and 674 corresponding local networks. The conflicts can be mitigated, but 675 not fully avoided, by using less commonly used portions of the 676 RFC1918 address space. Addresses from 172.16/12 are thought to be 677 less likely to be in conflict than addresses from 10/8 or 192.168/16 678 spaces. A source address can usually be selected in a non- 679 conflicting manner, but a small possibility exists for synthesized 680 destination addresses being in conflict with real addresses used in 681 attached IPv4 networks. 683 The RECOMMENDED IPv4 addresses are following: 685 Primary source addresses: 172.21.112.0/20. Source addresses have to 686 be allocated because applications use getsockname() calls and in the 687 network layer mode an IP address of the IPv4 interface has to be 688 shown (e.g., by 'ifconfig'). More than one address is allocated to 689 allow implementation flexibility, e.g., for cases where a host has 690 multiple IPv6 interfaces. The source addresses are from different 691 subnets than destination addresses to ensure applications would not 692 make on-link assumptions and would instead enable NAT traversal 693 functions. 695 Secondary source addresses: 10.170.224.0/20. These addresses are 696 recommended if a host has a conflict with primary source addresses. 698 Primary destination addresses: 10.170.160.0/20. The address mapper 699 will select destination addresses primarily out of this pool. 701 Secondary destination addresses: 172.21.80.0/20. The address mapper 702 will select destination addresses out of this pool if the node has a 703 dual-stack connection conflicting with primary destination addresses. 705 4.5. Multi-interface 707 In the case of dual-stack destinations BIH MUST NOT do protocol 708 translation from IPv4 to IPv6 when the host has any IPv4 interfaces, 709 native or tunneled, available for use. 711 It is possible that an IPv4 interface is activated during BIH 712 operation, for example if a node moves to a coverage area of an IPv4- 713 enabled network. In such an event, BIH MUST stop initiating protocol 714 translation sessions for new connections and BIH MAY disconnect 715 active sessions. The choice of disconnection is left for 716 implementations and it may depend on whether IPv4 address conflict 717 occurs between addresses used by BIH and addresses used by the new 718 IPv4 interface. 720 4.6. Multicast 722 Protocol translation for multicast is not supported. 724 5. Application-Level Gateway requirements considerations 726 No Application-Level Gateway (ALG) functionality is specified herein 727 as ALG design is generally not encouraged for host-based translation 728 and as BIH is intended for applications that do not include IP 729 addresses in protocol payloads. 731 6. IANA Considerations 733 There are no actions for IANA. 735 7. Security Considerations 737 The security considerations of BIH follows closely, but not 738 completely, those of NAT64 [RFC6146] and DNS64 [RFC6147]. The 739 following sections are copied from RFC6146 and RFC6147 and modified 740 for BIH scenario. 742 7.1. Implications on End-to-End Security 744 Any protocols that protect IP header information are essentially 745 incompatible with BIH. This implies that end-to-end IPsec 746 verification will fail when the Authentication Header (AH) is used 747 (both transport and tunnel mode) and when ESP is used in transport 748 mode. This is inherent in any network-layer translation mechanism. 749 End-to-end IPsec protection can be restored, using UDP encapsulation 750 as described in [RFC3948]. The actual extensions to support IPsec 751 are out of the scope of this document. 753 7.2. Filtering 755 BIH creates binding state using packets flowing from the IPv4 side to 756 the IPv6 side. In accordance with the procedures defined in this 757 document following the guidelines defined in [RFC4787], a BIH 758 implementation MUST offer "Endpoint-Independent Mapping". 760 Implementations MAY also provide support for "Address-Dependent 761 Mapping" following the guidelines defined in [RFC4787]. 763 The security properties, however, are determined by which packets the 764 BIH allows in and which it does not. The security properties are 765 determined by the filtering behavior and by the possible filtering 766 configuration in the filtering portions of the BIH, not by the 767 address mapping behavior. 769 7.3. Attacks on BIH 771 The BIH implementation itself is a potential victim of different 772 types of attacks. In particular, the BIH can be a victim of DoS 773 attacks. The BIH implementation has a limited number of resources 774 that can be consumed by attackers creating a DoS attack. The BIH has 775 a limited number of IPv4 addresses that it uses to create the 776 bindings. Even though the BIH performs address translation, it is 777 possible for an attacker to consume the synthetic IPv4 address pool 778 by triggering a host to issue DNS queries for names that cause ENR to 779 synthesise A records. DoS attacks can also affect other limited 780 resources available in the host running BIH such as memory or link 781 capacity. For instance, it is possible for an attacker to launch a 782 DoS attack on the memory of the BIH running device by sending 783 fragments that the BIH will store for a given period. If the number 784 of fragments is large enough, the memory of the host could be 785 exhausted. BIH implementations MUST implement proper protection 786 against such attacks, for instance, allocating a limited amount of 787 memory for fragmented packet storage. 789 Another consideration related to BIH resource depletion refers to the 790 preservation of binding state. Attackers may try to keep a binding 791 state alive forever by sending periodic packets that refresh the 792 state. In order to allow the BIH to defend against such attacks, the 793 BIH implementation MAY choose not to extend the session entry 794 lifetime for a specific entry upon the reception of packets for that 795 entry through the external interface. However, such an action would 796 not allow one-way communication sessions to stay alive. 798 7.4. DNS considerations 800 BIH operates in combination with the DNS, and is therefore subject to 801 whatever security considerations are appropriate to the DNS mode in 802 which the BIH is operating (i.e. recursive or stub-resolver mode). 804 BIH has the potential to interfere with the functioning of DNSSEC, 805 because BIH modifies DNS answers, and DNSSEC is designed to detect 806 such modifications and to treat modified answers as bogus. 808 8. Changes since RFC2767 and RFC3338 810 This document combines and obsoletes both [RFC2767] and [RFC3338]. 812 The changes in this document mainly reflect the following: 814 1. RFC1918 addresses used used for synthesis 816 The RFC3338 used unassigned IPv4 addresses (e.g., 0.0.0.1 - 817 0.0.0.255) for synthetic IPv4 addresses. Those addresses should 818 not have been used and that may cause problems with applications. 819 It is preferable to use RFC1918 defined addresses instead, as 820 described in Section 4.4. 822 2. Support for reverse (PTR) DNS queries 824 Neither RFC2767 or RFC3338 included support for reverse (PTR) DNS 825 queries. This document adds the support at Section 2.3.3. 827 3. DNSSEC support 829 RFC2767 did not include DNSSEC considerations, which are now 830 included in Section 2.3.2 832 4. Architectural recommendation 834 This document recommends socket API layer implementation option 835 over network layer translation, i.e. recommends approach 836 introduced in RFC2767 over the approach of RFC3338. 838 5. Standards track document 840 RFC2767 is classified as Informational RFC and RFC3338 as 841 Experimental RFC. It was discussed and decided in the IETF that 842 this technology should be on the standards track. 844 6. Set of other extensions and improvements 846 Set of lesser extensions, improvements, and clarifications have 847 been introduced. These include but are not limited to: IPv4 and 848 IPv6 address exclusion sets at Section 2.3.1, host's DNS cache 849 considerations, ENR behaviour updates, updated security 850 considerations, example updates, and deployment scenario updates. 852 9. Acknowledgments 854 The authors thank the discussion from Gang Chen, Dapeng Liu, Bo Zhou, 855 Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of 856 this document. 858 The efforts of Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco 859 Cortes, Ralph Droms, Stephen Farrell, Fernando Gont, Marnix Goossens, 860 Wassim Haddad, Ala Hamarsheh, Dave Harrington, Ed Jankiewizh, Suresh 861 Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu, 862 Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, and 863 James Woodyatt in reviewing this document are gratefully 864 acknowledged. 866 Special acknowledgements go to Dave Thaler for his extensive review 867 and support. 869 The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, 870 Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. 871 The authors of RFC3338 acknowledged implementation contributions by 872 Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation 873 (www.i2soft.net). 875 The authors of Bump-in-the-Wire (BIW) (draft-ietf-biw-00.txt, October 876 2006), P. Moster, L. Chin, and D. Green, are acknowledged. Some 877 ideas and clarifications from BIW have been adapted to this document. 879 10. References 881 10.1. Normative References 883 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 884 E. Lear, "Address Allocation for Private Internets", 885 BCP 5, RFC 1918, February 1996. 887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", BCP 14, RFC 2119, March 1997. 890 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 891 (IPv6) Specification", RFC 2460, December 1998. 893 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 894 for IPv6 Hosts and Routers", RFC 4213, October 2005. 896 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 897 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 898 RFC 4787, January 2007. 900 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 901 Algorithm", RFC 6145, April 2011. 903 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 904 NAT64: Network Address and Protocol Translation from IPv6 905 Clients to IPv4 Servers", RFC 6146, April 2011. 907 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 908 Beijnum, "DNS64: DNS Extensions for Network Address 909 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 910 April 2011. 912 10.2. Informative References 914 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 915 Translator (NAT) Terminology and Considerations", 916 RFC 2663, August 1999. 918 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 919 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 920 RFC 2767, February 2000. 922 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 923 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 924 RFC 3338, October 2002. 926 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 928 Stevens, "Basic Socket Interface Extensions for IPv6", 929 RFC 3493, February 2003. 931 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 932 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 933 RFC 3948, January 2005. 935 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 936 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 937 RFC 5382, October 2008. 939 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 940 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 941 April 2009. 943 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 944 BCP 153, RFC 5735, January 2010. 946 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 947 Transition Mechanisms during IPv6 Deployment", RFC 6180, 948 May 2011. 950 Appendix A. API list intercepted by BIH 952 The following informational list includes some of the API functions 953 that would be appropriate to intercept by BIH module when implemented 954 at the socket API layer. Please note that this list is not fully 955 exhaustive, as the function names and services that are available on 956 different APIs vary significantly. 958 The functions that the application uses to pass addresses into the 959 system are: 961 bind() 963 connect() 965 sendmsg() 967 sendto() 969 gethostbyaddr() 971 getnameinfo() 973 The functions that return an address from the system to an 974 application are: 976 accept() 978 recvfrom() 980 recvmsg() 982 getpeername() 984 getsockname() 986 gethostbyname() 988 getaddrinfo() 990 The functions that are related to socket options are: 992 getsocketopt() 994 setsocketopt() 996 As well, raw sockets for IPv4 and IPv6 may be intercepted. 998 Most of the socket functions require a pointer to the socket address 999 structure as an argument. Each IPv4 argument is mapped into 1000 corresponding an IPv6 argument, and vice versa. 1002 According to [RFC3493], the following new IPv6 basic APIs and 1003 structures are required. 1005 IPv4 new IPv6 1006 ------------------------------------------------ 1007 AF_INET AF_INET6 1008 sockaddr_in sockaddr_in6 1009 gethostbyname() getaddrinfo() 1010 gethostbyaddr() getnameinfo() 1011 inet_ntoa()/inet_addr() inet_pton()/inet_ntop() 1012 INADDR_ANY in6addr_any 1014 Figure 8 1016 BIH may intercept inet_ntoa() and inet_addr() and use the address 1017 mapper for those. Doing that enables BIH to support literal IP 1018 addresses. However, IPv4 address literals can only be used after a 1019 mapping entry between the IPv4 address and corresponding IPv6 address 1020 has been created. 1022 The gethostbyname() and getaddrinfo() calls return a list of 1023 addresses. When the name resolver function invokes getaddrinfo() and 1024 getaddrinfo() returns multiple IP addresses, whether IPv4 or IPv6, 1025 they should all be represented in the addresses returned by 1026 gethostbyname(). Thus if getaddrinfo() returns multiple IPv6 1027 addresses, this implies that multiple address mappings will be 1028 created; one for each IPv6 address. 1030 Authors' Addresses 1032 Bill Huang 1033 China Mobile 1034 53A,Xibianmennei Ave., 1035 Xuanwu District, 1036 Beijing 100053 1037 China 1039 Email: bill.huang@chinamobile.com 1041 Hui Deng 1042 China Mobile 1043 53A,Xibianmennei Ave., 1044 Xuanwu District, 1045 Beijing 100053 1046 China 1048 Email: denghui02@gmail.com 1050 Teemu Savolainen 1051 Nokia 1052 Hermiankatu 12 D 1053 FI-33720 TAMPERE 1054 Finland 1056 Email: teemu.savolainen@nokia.com