idnits 2.17.1 draft-ietf-behave-v4v6-bih-09.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 558 has weird spacing: '...address trans...' == Line 559 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 (January 16, 2012) is 4477 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: July 19, 2012 January 16, 2012 9 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) 10 draft-ietf-behave-v4v6-bih-09 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 July 19, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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. 173 Real IPv6 address 175 An IPv6 address of a remote node a host has learned, for example, 176 from DNS response to an AAAA query. 178 Synthetic IPv4 address 180 An IPv4 address that has meaning only inside a host and that is 181 used to provide IPv4 representation of remote node's real IPv6 182 address. 184 1.2. Acknowledgement of previous work 186 This document is a direct derivative from Kazuaki TSHUCHIYA, 187 Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's Bump-in-the-Stack 188 [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain 189 Durand, and Erik Nordmark's Bump-in-the-API [RFC3338], which 190 similarly provides IPv4-only applications on dual-stack hosts the 191 means to operate over IPv6. Section 8 covers the changes since those 192 documents. 194 2. Components of the Bump-in-the-Host 196 Figure 1 shows the architecture of a host in which BIH is implemented 197 as a socket API layer translator, i.e., as a "Bump-in-the-API". 199 +----------------------------------------------+ 200 | +------------------------------------------+ | 201 | | | | 202 | | IPv4 applications | | 203 | | | | 204 | +------------------------------------------+ | 205 | +------------------------------------------+ | 206 | | Socket API (IPv4, IPv6) | | 207 | +------------------------------------------+ | 208 | +-[ API translator]------------------------+ | 209 | | +-----------+ +---------+ +------------+ | | 210 | | | Ext. Name | | Address | | Function | | | 211 | | | Resolver | | Mapper | | Mapper | | | 212 | | +-----------+ +---------+ +------------+ | | 213 | +------------------------------------------+ | 214 | +--------------------+ +-------------------+ | 215 | | | | | | 216 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 217 | | | | | | 218 | +--------------------+ +-------------------+ | 219 +----------------------------------------------+ 221 Figure 1: Architecture of a dual stack host using protocol 222 translation at socket layer 224 Figure 2 shows the architecture of a host in which BIH is implemented 225 as a network layer translator, i.e., a "Bump-in-the-Stack". 227 +------------------------------------------------------------+ 228 | +------------------------------------------+ | 229 | | IPv4 applications | | 230 | | Host's main DNS resolver | | 231 | +------------------------------------------+ | 232 | +------------------------------------------+ | 233 | | TCP/UDP | | 234 | +------------------------------------------+ | 235 | +------------------------------------------+ +---------+ | 236 | | IPv4 | | | | 237 | +------------------------------------------+ | Address | | 238 | +------------------+ +---------------------+ | Mapper | | 239 | | Protocol | | Extension Name | | | | 240 | | Translator | | Resolver | | | | 241 | +------------------+ +---------------------+ | | | 242 | +------------------------------------------+ | | | 243 | | IPv4 / IPv6 | | | | 244 | +------------------------------------------+ +---------+ | 245 +------------------------------------------------------------+ 247 Figure 2: Architecture of a dual-stack host using protocol 248 translation at the network layer 250 Dual stack hosts defined in RFC 4213 [RFC4213] need applications, 251 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed 252 hosts in this document have an API or network-layer translator to 253 allow legacy IPv4 applications to communicate with IPv6-only peers. 254 The BIH architecture consists of an Extension Name Resolver, an 255 Address Mapper, and depending on implementation either a Function 256 Mapper or a Protocol Translator. It is worth noting that the 257 Extension Name Resolver's placement is orthogonal to the placement of 258 protocol translation. For example, the Extension Name Resolver may 259 reside in the socket API while protocol translation takes place at 260 the network layer. 262 The choice between the socket API and the network layer architectures 263 varies case by case. While the socket API architecture alternative 264 is the recommended one, it may not always be possible to choose. 265 This may be the case, for example, when the used operating system 266 does not allow modifications to be done for API implementations, but 267 does allow addition of virtual network interfaces and related 268 software modules. On the other hand, sometimes it may not be 269 possible to introduce protocol translators inside the operating 270 system, but it may be easy to modify implementations behind the API 271 provided for applications. The choice of architecture also depends 272 on who is creating implementation of BIH. For example, an 273 application framework provider, an operating system provider, and a 274 device vendor may all choose different approaches due their different 275 positions. 277 2.1. Function Mapper 279 The function mapper translates an IPv4 socket API function into an 280 IPv6 socket API function. 282 When detecting IPv4 socket API function calls from IPv4 applications, 283 the function mapper MUST intercept the function calls and invoke IPv6 284 socket API functions that correspond to the IPv4 socket API 285 functions. 287 The function mapper MUST NOT perform function mapping when the 288 application is initiating communications to the address range used by 289 local synthesis and the address mapping table does not have an entry 290 mathching the address. 292 See Appendix A for an informational list of functions that would be 293 appropriate to intercept by the function mapper. 295 2.2. Protocol translator 297 The protocol translator translates IPv4 into IPv6 and vice versa 298 using the IP conversion mechanism defined in SIIT [RFC6145]. To 299 avoid unnecessary fragmentation, the host's IPv4 module SHOULD be 300 configured with a small enough MTU (MTU of the IPv6 enabled link - 20 301 bytes). 303 Protocol translation cannot be performed for IPv4 packets sent to the 304 IPv4 address range used by local synthesis and for which a mapping 305 table entry does not exist. The implementation SHOULD attempt to 306 route such packets via IPv4 interfaces instead. 308 2.3. Extension Name Resolver 310 The Extension Name Resolver (ENR) returns an answer in response to 311 the IPv4 application's name resolution request. 313 In the case of the socket API layer implementation alternative, when 314 an IPv4 application tries to do a forward lookup to resolve names via 315 the resolver library (e.g., gethostbyname()), BIH intercepts the 316 function call and instead calls the IPv6 equivalent functions (e.g., 317 getaddrinfo()) that will resolve both A and AAAA records. This 318 implementation alternative is name resolution protocol agnostic, and 319 hence supports techniques such as "hosts-file", NetBIOS, mDNS, and 320 anything else the underlying operating system uses. 322 In the case of the network layer implementation alternative, the ENR 323 intercepts the A query and creates an additional AAAA query with 324 similar content. The ENR will then collect replies to both A and 325 AAAA queries and, depending on results, either return an A reply 326 unmodified or synthesize a new A reply. If no reply for A query is 327 received after ENR implementation specific timeout, after reception 328 of positive AAAA response, the ENR MAY choose to proceed as if there 329 were only AAAA record available for the destination. 331 The network layer implementation alternative will only be able to 332 catch applications' name resolution requests that result in actual 333 DNS queries, hence is more limited when compared to the socket API 334 layer implementation alternative. Hence the socket API layer 335 alternative is RECOMMENDED. 337 In either implementation alternative, if DNS A record reply contains 338 non-excluded real IPv4 addresses the ENR MUST NOT synthesize IPv4 339 addresses. 341 The ENR asks the address mapper to assign a synthetic IPv4 address 342 corresponding to each received IPv6 address if the A record query 343 resulted in negative response, all received real IPv4 addresses were 344 excluded, or the A query timed out. The timeout value is 345 implementation specific and may be short in order to provide good 346 user experience. 348 In the case of the API layer implementation alternative, the ENR will 349 simply make the API (e.g. gethostbyname) return the synthetic IPv4 350 address. In the case of the network-layer implementation 351 alternative, the ENR synthesizes an A record for the assigned 352 synthetic IPv4 address, and delivers it up the stack. If the 353 response contains a CNAME or a DNAME record, then the CNAME or DNAME 354 chain is followed until the first terminating A or AAAA record is 355 reached. 357 Application | Network | ENR behavior 358 query | response | 359 ---------------+-----------------------+---------------------------- 360 IPv4 address(es) | IPv4 address(es) | return real IPv4 address(es) 361 IPv4 address(es) | IPv6 address(es) | synthesize IPv4 address(es) 362 IPv4 address(es) | IPv4/IPv6 address(es) | return real IPv4 address(es) 364 Figure 3: ENR behavior illustration 366 2.3.1. Special exclusion sets for A and AAAA records 368 An ENR implementation SHOULD by default exclude certain real IPv4 and 369 IPv6 addresses seen on received A and AAAA records. The addresses to 370 be excluded by default MAY include addresses such as those that 371 should not appear in the DNS or on the wire (see [RFC6147] section 372 5.1.4 and [RFC5735]). Additional addresses MAY be excluded based on 373 possibly configurable local policies. 375 2.3.2. DNSSEC support 377 When the ENR is implemented at the network layer, the A record 378 synthesis can cause similar issues as are described in [RFC6147] 379 section 3. While running BIH, the main resolver of the host SHOULD 380 NOT perform validation of A records as synthetic A records created by 381 ENR would fail in validation. While not running BIH, host's resolver 382 can use DNSSEC in the same way that any other resolver can. The ENR 383 MAY support DNSSEC, in which case the (stub) resolver on a host can 384 be configured to trust validations done by the ENR located at the 385 network layer. In some cases the host's validating stub resolver can 386 implement the ENR by itself. 388 When the ENR is implemented at the socket API level, there are no 389 issues with DNSSEC use, as the ENR itself uses socket APIs for DNS 390 resolution. This approach is RECOMMENDED. 392 2.3.3. Reverse DNS lookup 394 When an application requests a reverse lookup (PTR query) for an IPv4 395 address, the ENR MUST check whether the queried IPv4 address can be 396 found in the Address Mapper's mapping table and is a synthetic IPv4 397 address. If an entry is found and the queried IPv4 address is 398 synthetic, the ENR MUST initiate a corresponding reverse lookup for 399 the real IPv6 address. In the case where the application requested a 400 reverse lookup for an address not part of the synthetic IPv4 address 401 pool, e.g., a global address, the request MUST be passed on 402 unmodified. 404 For example, when an application requests a reverse lookup for a 405 synthetic IPv4 address, the ENR needs to intercept that query. The 406 ENR asks the address mapper for the real IPv6 address that 407 corresponds to the synthetic IPv4 address. The ENR shall perform a 408 reverse lookup procedure for the destination's IPv6 address and 409 return the name received as a response to the application that 410 initiated the IPv4 query. 412 2.3.4. DNS caches and synthetic IPv4 addresses 414 When BIH shuts down or address mapping table entries are cleared for 415 any reason, DNS cache entries for synthetic IPv4 addresses MUST be 416 flushed. There may be a DNS cache in the network-layer ENR itself, 417 but also at the host's stub resolver. 419 2.4. Address Mapper 421 The address mapper maintains an IPv4 address pool that can be used 422 for IPv4 address synthesis. The pool consists of [RFC1918] IPv4 423 addresses as per section 4.4. Also, the address mapper maintains a 424 table consisting of pairs of synthetic IPv4 addresses and 425 destinations' real IPv6 addresses. 427 When the extension name resolver, translator, or the function mapper 428 requests the address mapper to assign a synthetic IPv4 address 429 corresponding to an IPv6 address, the address mapper selects and 430 returns an IPv4 address out of the local pool, and registers a new 431 entry into the table. The registration occurs in the following three 432 cases: 434 (1) When the extension name resolver gets only IPv6 addresses for the 435 target host name and there is no existing mapping entry for the IPv6 436 addresses. One or more synthetic IPv4 addresses will be returned to 437 the application and mappings for synthetic IPv4 addresses to real 438 IPv6 addresses are created. 440 (2) When the extension name resolver gets both real IPv4 and IPv6 441 addresses, but the real IPv4 addresses contain only excluded IPv4 442 addresses (e.g., 127.0.0.1). The behavior will follow case (1). 444 (3) When the function mapper is triggered by a received IPv6 packet 445 and there is no existing mapping entry for the IPv6 source address 446 (for example, the client sent a UDP request to an anycast address but 447 a response was received from a unicast address). 449 Other possible combinations are outside of BIH and BIH is not 450 involved in those. 452 3. Behavior and Network Examples 454 Figure 4 illustrates a very basic network scenario. An IPv4-only 455 application is running on a host attached to the IPv6-only Internet 456 and is talking to an IPv6-only server. Communication is made 457 possible by Bump-In-the-Host. 459 +----+ +-------------+ 460 | H1 |----------- IPv6 Internet -------- | IPv6 server | 461 +----+ +-------------+ 462 v4 only 463 application 465 Figure 4: Network Scenario #1 467 Figure 5 illustrates a possible network scenario where an IPv4-only 468 application is running on a host attached to a dual-stack network, 469 but the destination server is running on a private site that is 470 numbered with public IPv6 addresses and not globally reachable IPv4 471 addresses, such as [RFC1918] addresses, without port forwarding set 472 up on the NAT44. The only means to contact the server is to use 473 IPv6. 475 +----------------------+ +------------------------------+ 476 | Dual Stack Internet | | IPv4 Private site (Net 10) | 477 | | | IPv6 routed site | 478 | +---------+ +----------+ | 479 | +-| NAT44 |-------------+ | | 480 | +----+ | +---------+ | | | 481 | | H1 |---------+ | | | Server | | 482 | +----+ | +-----------+ | | | 483 | v4 only +-|IPv6 Router|-----------+ | | 484 | application +-----------+ +----------+ | 485 | | | Dual Stack | 486 | | | 10.1.1.1 | 487 | | | 2001:DB8::1 | 488 +----------------------+ +------------------------------+ 490 Figure 5: Network Scenario #2 492 Illustrations of host behavior in both implementation alternatives 493 are given here. Figure 6 illustrates a setup where BIH (including 494 the ENR) is implemented at the sockets API layer, and Figure 7 495 illustrates a setup where BIH (including the ENR) is implemented at 496 the network layer. 498 "dual stack" "host6" 499 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name 500 appli- API | ENR Address Function| (v6/v4) Server 501 cation | Mapper Mapper | 502 | | | | | | | | 503 <> | | | 504 | | | | | | | | 505 |------->|------->| Query IPv4 addresses for host6. | | 506 | | | | | | | | 507 | | |------------------------------------------------->| 508 | | | Query 'A' and 'AAAA' records for host6 | 509 | | | | | | | | 510 | | |<-------------------------------------------------| 511 | | | Reply with the 'AAAA' record. | | 512 | | | | | | | 513 | | |<> | 514 | | | | | | | 515 | | |+++++++>| Request synthetic IPv4 address | 516 | | | | corresponding to the IPv6 address. 517 | | | | | | | 518 | | | |<> 519 | | | | | | | 520 | | |<+++++++| Reply with the synthetic IPv4 address. 521 | | | | | | | 522 |<-------|<-------| Reply with the IPv4 address | 523 | | | | | | | 524 | | | | | | | 525 <> | | | 526 | | | | | | | 527 |=======>|=========================>|An IPv4 Socket API action 528 | | | | | | | 529 | | | |<+++++++| Request IPv6 addresses| 530 | | | | | corresponding to the | 531 | | | | | synthetic IPv4 addresses. 532 | | | | | | | 533 | | | |+++++++>| Reply with the IPv6 addresses. 534 | | | | | | | 535 | | | | |<> 536 | | | | | | | 537 | An IPv6 Socket API action |=======================>| 538 | | | | | | | 539 | | | | |<> | 541 | | | | | | | 542 | An IPv6 Socket API action |<=======================| 543 | | | | | | | 544 | | | | |<> 545 | | | | | | | 546 | | | |<+++++++| Request synthetic IPv4 addresses 547 | | | | | corresponding to the | 548 | | | | | IPv6 addresses. | 549 | | | | | | | 550 | | | |+++++++>| Reply with the IPv4 addresses. 551 | | | | | | | 552 |<=======|<=========================| An IPv4 Socket API action 553 | | | | | | | 555 Figure 6: Example of BIH as API addition 557 "dual stack" "host6" 558 IPv4 stub TCP/ ENR address translator IPv6 559 app res. IPv4 mapper 560 | | | | | | | | 561 <> | | 562 |-->| | | | | | | 563 | |----------->| Query 'A' records for "host6". | Name 564 | | | | | | | | Server 565 | | | |------------------------------------------->| 566 | | | | Query 'A' and 'AAAA' records for "host6" 567 | | | | | | | | | 568 | | | |<-------------------------------------------| 569 | | | | Reply only with 'AAAA' record. | 570 | | | | | | | | 571 | | | |<> | 572 | | | | | | | | 573 | | | |-------->| Request synthetic IPv4 address 574 | | | | | corresponding to each IPv6 address. 575 | | | | | | | | 576 | | | | |<> 577 | | | | | | | | 578 | | | |<--------| Reply with the synthetic IPv4 address. 579 | | | | | | | | 580 | | | |<> 581 | | | | | | | | 582 | |<-----------| Reply with the 'A' record. | | 583 | | | | | | | | 584 |<--|<>| | | 587 | | | | | | | | 588 |=======>|========================>| An IPv4 packet. | 589 | | | | | | | | 590 | | | | |<++++++| Request IPv6 addresses 591 | | | | | | corresponding to the 592 | | | | | | synthetic IPv4 addresses. 594 | | | | | | | | 595 | | | | |++++++>| Reply with the IPv6| 596 | | | | | | addresses. | 597 | | | | | | | | 598 | | | | | |<> 599 | | | | | | | | 600 | | | |An IPv6 packet. |==========>|========>| 601 | | | | | | | | 602 | | | | | <> 603 | | | | | | | | 604 | | | |An IPv6 packet. |<==========|<========| 605 | | | | | | | | 606 | | | | | |<> 607 | | | | | | | | 608 | | | | |<++++++| Request synthetic IPv4 609 | | | | | | addresses corresponding 610 | | | | | | to the IPv6 addresses. 611 | | | | | | | | 612 | | | | |++++++>| Reply with the IPv4 addresses. 613 | | | | | | | | 614 |<=======|=========================| An IPv4 packet. | 615 | | | | | | | | 617 Figure 7: Example of BIH at the network layer 619 4. Considerations 621 4.1. Socket API Conversion 623 IPv4 socket API functions are translated into IPv6 socket API 624 functions that are semantically as identical as possible and vice 625 versa. See Appendix B for the API list intercepted by BIH. However, 626 some IPv4 socket API functions are not fully compatible with IPv6 627 since IPv4 supports features that are not present in IPv6, such as 628 SO_BROADCAST. 630 4.2. Socket bindings 632 BIH SHOULD select a source address for a socket from the recommended 633 source address pool if a socket used for communications has not been 634 explicitly bound to any IPv4 address. 636 The binding of an explicitly bound socket MUST NOT be changed by the 637 BIH. 639 4.3. ICMP Message Handling 641 ICMPv4 and ICMPv6 messages MUST be translated as defined by SIIT 642 [RFC6145]. In the network layer implementation alternative, protocol 643 translator MUST translate ICMPv6 packets to ICMPv4 and vice versa, 644 and in the socket API implementation alternative, the socket API MUST 645 handle conversions in similar fashion. 647 4.4. IPv4 Address Pool and Mapping Table 649 The address pool consists of the [RFC1918] private IPv4 addresses. 650 This pool can be implemented at different granularities in the node, 651 e.g., a single pool per node, or at some finer granularity such as 652 per-user or per-process. In the case of a large number of IPv4 653 applications communicating with a large number of IPv6 servers, the 654 available address space may be exhausted if the granularity is not 655 fine enough. This should be a rare event and chances will decrease 656 as IPv6 support increases. The applications may use IPv4 addresses 657 they learn for a much longer period than DNS time-to-live indicates. 658 Therefore, the mapping table entries should be kept active for a long 659 period of time. For example, a web browser may initiate one DNS 660 query and then create multiple TCP sessions over time to the address 661 it learns. When address mapping table clean-up is required, the BIH 662 may utilize techniques used by network address translators, such as 663 described in [RFC2663], [RFC5382], and [RFC5508]. 665 The RFC1918 address space was chosen because generally legacy 666 applications understand it as a private address space. A new 667 dedicated address space would run a risk of not being understood by 668 applications as private. 127/8 and 169.254/16 are rejected due to 669 possible assumptions applications may make when seeing those. 671 The RFC1918 addresses used by the BIH have a risk of conflicting with 672 addresses used in the host's possible IPv4 interfaces and 673 corresponding local networks. The conflicts can be mitigated, but 674 not fully avoided, by using less commonly used portions of the 675 RFC1918 address space. Addresses from 172.16/12 are thought to be 676 less likely to be in conflict than addresses from 10/8 or 192.168/16 677 spaces. A source address can usually be selected in a non- 678 conflicting manner, but a small possibility exists for synthesized 679 destination addresses being in conflict with real addresses used in 680 attached IPv4 networks. 682 The RECOMMENDED IPv4 addresses are following: 684 Primary source addresses: 172.21.112.0/20. Source addresses have to 685 be allocated because applications use getsockname() calls and in the 686 network layer mode an IP address of the IPv4 interface has to be 687 shown (e.g., by 'ifconfig'). More than one address is allocated to 688 allow implementation flexibility, e.g., for cases where a host has 689 multiple IPv6 interfaces. The source addresses are from different 690 subnets than destination addresses to ensure applications would not 691 make on-link assumptions and would instead enable NAT traversal 692 functions. 694 Secondary source addresses: 10.170.224.0/20. These addresses are 695 recommended if a host has a conflict with primary source addresses. 697 Primary destination addresses: 10.170.160.0/20. The address mapper 698 will select destination addresses primarily out of this pool. 700 Secondary destination addresses: 172.21.80.0/20. The address mapper 701 will select destination addresses out of this pool if the node has a 702 dual-stack connection conflicting with primary destination addresses. 704 4.5. Multi-interface 706 In the case of dual-stack destinations BIH MUST NOT do protocol 707 translation from IPv4 to IPv6 when the host has any IPv4 interfaces, 708 native or tunneled, available for use. 710 It is possible that an IPv4 interface is activated during BIH 711 operation, for example if a node moves to a coverage area of an IPv4- 712 enabled network. In such an event, BIH MUST stop initiating protocol 713 translation sessions for new connections and BIH MAY disconnect 714 active sessions. The choice of disconnection is left for 715 implementations and it may depend on whether IPv4 address conflict 716 occurs between addresses used by BIH and addresses used by the new 717 IPv4 interface. 719 4.6. Multicast 721 Protocol translation for multicast is not supported. 723 5. Application-Level Gateway requirements considerations 725 No Application-Level Gateway (ALG) functionality is specified herein 726 as ALG design is generally not encouraged for host-based translation 727 and as BIH is intended for applications that do not include IP 728 addresses in protocol payloads. 730 6. IANA Considerations 732 There are no actions for IANA. 734 7. Security Considerations 736 The security considerations of BIH follows closely, but not 737 completely, those of NAT64 [RFC6146] and DNS64 [RFC6147]. The 738 following sections are copied from RFC6146 and RFC6147 and modified 739 for BIH scenario. 741 7.1. Implications on End-to-End Security 743 Any protocols that protect IP header information are essentially 744 incompatible with BIH. This implies that end-to-end IPsec 745 verification will fail when the Authentication Header (AH) is used 746 (both transport and tunnel mode) and when ESP is used in transport 747 mode. This is inherent in any network-layer translation mechanism. 748 End-to-end IPsec protection can be restored, using UDP encapsulation 749 as described in [RFC3948]. The actual extensions to support IPsec 750 are out of the scope of this document. 752 7.2. Filtering 754 BIH creates binding state using packets flowing from the IPv4 side to 755 the IPv6 side. In accordance with the procedures defined in this 756 document following the guidelines defined in [RFC4787], a BIH 757 implementation MUST offer "Endpoint-Independent Mapping". 759 Implementations MAY also provide support for "Address-Dependent 760 Mapping" following the guidelines defined in [RFC4787]. 762 The security properties, however, are determined by which packets the 763 BIH allows in and which it does not. The security properties are 764 determined by the filtering behavior and by the possible filtering 765 configuration in the filtering portions of the BIH, not by the 766 address mapping behavior. 768 7.3. Attacks on BIH 770 The BIH implementation itself is a potential victim of different 771 types of attacks. In particular, the BIH can be a victim of DoS 772 attacks. The BIH implementation has a limited number of resources 773 that can be consumed by attackers creating a DoS attack. The BIH has 774 a limited number of IPv4 addresses that it uses to create the 775 bindings. Even though the BIH performs address translation, it is 776 possible for an attacker to consume the synthetic IPv4 address pool 777 by triggering a host to issue DNS queries for names that cause ENR to 778 synthesise A records. DoS attacks can also affect other limited 779 resources available in the host running BIH such as memory or link 780 capacity. For instance, it is possible for an attacker to launch a 781 DoS attack on the memory of the BIH running device by sending 782 fragments that the BIH will store for a given period. If the number 783 of fragments is large enough, the memory of the host could be 784 exhausted. BIH implementations MUST implement proper protection 785 against such attacks, for instance, allocating a limited amount of 786 memory for fragmented packet storage. 788 Another consideration related to BIH resource depletion refers to the 789 preservation of binding state. Attackers may try to keep a binding 790 state alive forever by sending periodic packets that refresh the 791 state. In order to allow the BIH to defend against such attacks, the 792 BIH implementation MAY choose not to extend the session entry 793 lifetime for a specific entry upon the reception of packets for that 794 entry through the external interface. However, such an action would 795 not allow one-way communication sessions to stay alive. 797 7.4. DNS considerations 799 BIH operates in combination with the DNS, and is therefore subject to 800 whatever security considerations are appropriate to the DNS mode in 801 which the BIH is operating (i.e. recursive or stub-resolver mode). 803 BIH has the potential to interfere with the functioning of DNSSEC, 804 because BIH modifies DNS answers, and DNSSEC is designed to detect 805 such modifications and to treat modified answers as bogus. 807 8. Changes since RFC2767 and RFC3338 809 This document combines and obsoletes both [RFC2767] and [RFC3338]. 811 The changes in this document mainly reflect the following: 813 1. RFC1918 addresses used used for synthesis 815 The RFC3338 used unassigned IPv4 addresses (e.g., 0.0.0.1 - 816 0.0.0.255) for synthetic IPv4 addresses. Those addresses should 817 not have been used and that may cause problems with applications. 818 It is preferable to use RFC1918 defined addresses instead, as 819 described in Section 4.4. 821 2. Support for reverse (PTR) DNS queries 823 Neither RFC2767 or RFC3338 included support for reverse (PTR) DNS 824 queries. This document adds the support at Section 2.3.3. 826 3. DNSSEC support 828 RFC2767 did not include DNSSEC considerations, which are now 829 included in Section 2.3.2 831 4. Architectural recommendation 833 This document recommends socket API layer implementation option 834 over network layer translation, i.e. recommends approach 835 introduced in RFC2767 over the approach of RFC3338. 837 5. Standards track document 839 RFC2767 is classified as Informational RFC and RFC3338 as 840 Experimental RFC. It was discussed and decided in the IETF that 841 this technology should be on the standards track. 843 6. Set of other extensions and improvements 845 Set of lesser extensions, improvements, and clarifications have 846 been introduced. These include but are not limited to: IPv4 and 847 IPv6 address exclusion sets at Section 2.3.1, host's DNS cache 848 considerations, ENR behaviour updates, updated security 849 considerations, example updates, and deployment scenario updates. 851 9. Acknowledgments 853 The authors thank the discussion from Gang Chen, Dapeng Liu, Bo Zhou, 854 Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of 855 this document. 857 The efforts of Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco 858 Cortes, Ralph Droms, Stephen Farrell, Fernando Gont, Marnix Goossens, 859 Wassim Haddad, Ala Hamarsheh, Dave Harrington, Ed Jankiewizh, Suresh 860 Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu, 861 Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, and 862 James Woodyatt in reviewing this document are gratefully 863 acknowledged. 865 Special acknowledgements go to Dave Thaler for his extensive review 866 and support. 868 The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, 869 Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. 870 The authors of RFC3338 acknowledged implementation contributions by 871 Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation 872 (www.i2soft.net). 874 The authors of Bump-in-the-Wire (BIW) (draft-ietf-biw-00.txt, October 875 2006), P. Moster, L. Chin, and D. Green, are acknowledged. Some 876 ideas and clarifications from BIW have been adapted to this document. 878 10. References 880 10.1. Normative References 882 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 883 E. Lear, "Address Allocation for Private Internets", 884 BCP 5, RFC 1918, February 1996. 886 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 887 Requirement Levels", BCP 14, RFC 2119, March 1997. 889 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 890 (IPv6) Specification", RFC 2460, December 1998. 892 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 893 for IPv6 Hosts and Routers", RFC 4213, October 2005. 895 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 896 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 897 RFC 4787, January 2007. 899 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 900 Algorithm", RFC 6145, April 2011. 902 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 903 NAT64: Network Address and Protocol Translation from IPv6 904 Clients to IPv4 Servers", RFC 6146, April 2011. 906 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 907 Beijnum, "DNS64: DNS Extensions for Network Address 908 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 909 April 2011. 911 10.2. Informative References 913 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 914 Translator (NAT) Terminology and Considerations", 915 RFC 2663, August 1999. 917 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 918 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 919 RFC 2767, February 2000. 921 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 922 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 923 RFC 3338, October 2002. 925 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 927 Stevens, "Basic Socket Interface Extensions for IPv6", 928 RFC 3493, February 2003. 930 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 931 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 932 RFC 3948, January 2005. 934 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 935 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 936 RFC 5382, October 2008. 938 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 939 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 940 April 2009. 942 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 943 BCP 153, RFC 5735, January 2010. 945 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 946 Transition Mechanisms during IPv6 Deployment", RFC 6180, 947 May 2011. 949 Appendix A. API list intercepted by BIH 951 The following informational list includes some of the API functions 952 that would be appropriate to intercept by BIH module when implemented 953 at the socket API layer. Please note that this list is not fully 954 exhaustive, as the function names and services that are available on 955 different APIs vary significantly. 957 The functions that the application uses to pass addresses into the 958 system are: 960 bind() 962 connect() 964 sendmsg() 966 sendto() 968 gethostbyaddr() 970 getnameinfo() 972 The functions that return an address from the system to an 973 application are: 975 accept() 977 recvfrom() 979 recvmsg() 981 getpeername() 983 getsockname() 985 gethostbyname() 987 getaddrinfo() 989 The functions that are related to socket options are: 991 getsocketopt() 993 setsocketopt() 995 As well, raw sockets for IPv4 and IPv6 may be intercepted. 997 Most of the socket functions require a pointer to the socket address 998 structure as an argument. Each IPv4 argument is mapped into 999 corresponding an IPv6 argument, and vice versa. 1001 According to [RFC3493], the following new IPv6 basic APIs and 1002 structures are required. 1004 IPv4 new IPv6 1005 ------------------------------------------------ 1006 AF_INET AF_INET6 1007 sockaddr_in sockaddr_in6 1008 gethostbyname() getaddrinfo() 1009 gethostbyaddr() getnameinfo() 1010 inet_ntoa()/inet_addr() inet_pton()/inet_ntop() 1011 INADDR_ANY in6addr_any 1013 Figure 8 1015 BIH may intercept inet_ntoa() and inet_addr() and use the address 1016 mapper for those. Doing that enables BIH to support literal IP 1017 addresses. However, IPv4 address literals can only be used after a 1018 mapping entry between the IPv4 address and corresponding IPv6 address 1019 has been created. 1021 The gethostbyname() and getaddrinfo() calls return a list of 1022 addresses. When the name resolver function invokes getaddrinfo() and 1023 getaddrinfo() returns multiple IP addresses, whether IPv4 or IPv6, 1024 they should all be represented in the addresses returned by 1025 gethostbyname(). Thus if getaddrinfo() returns multiple IPv6 1026 addresses, this implies that multiple address mappings will be 1027 created; one for each IPv6 address. 1029 Authors' Addresses 1031 Bill Huang 1032 China Mobile 1033 53A,Xibianmennei Ave., 1034 Xuanwu District, 1035 Beijing 100053 1036 China 1038 Email: bill.huang@chinamobile.com 1040 Hui Deng 1041 China Mobile 1042 53A,Xibianmennei Ave., 1043 Xuanwu District, 1044 Beijing 100053 1045 China 1047 Email: denghui02@gmail.com 1049 Teemu Savolainen 1050 Nokia 1051 Hermiankatu 12 D 1052 FI-33720 TAMPERE 1053 Finland 1055 Email: teemu.savolainen@nokia.com