idnits 2.17.1 draft-ietf-behave-v4v6-bih-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC3338, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2767, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 495 has weird spacing: '...address trans...' == Line 496 has weird spacing: '... app res. ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == 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 (April 12, 2011) is 4762 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 2767 (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 3338 (Obsoleted by RFC 6535) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: October 14, 2011 April 12, 2011 9 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) 10 draft-ietf-behave-v4v6-bih-04 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. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 14, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Acknowledgement of previous work . . . . . . . . . . . . . 5 70 2. Components of the Bump-in-the-Host . . . . . . . . . . . . . . 6 71 2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 7 72 2.2. Protocol translator . . . . . . . . . . . . . . . . . . . 8 73 2.3. Extension Name Resolver . . . . . . . . . . . . . . . . . 8 74 2.3.1. Special exclusion sets for A and AAAA records . . . . 9 75 2.3.2. DNSSEC support . . . . . . . . . . . . . . . . . . . . 9 76 2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 10 77 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10 78 3. Behavior and network Examples . . . . . . . . . . . . . . . . 12 79 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16 80 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 16 81 4.2. Socket bindings . . . . . . . . . . . . . . . . . . . . . 16 82 4.3. ICMP Message Handling . . . . . . . . . . . . . . . . . . 16 83 4.4. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 16 84 4.5. Multi-interface . . . . . . . . . . . . . . . . . . . . . 17 85 4.6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18 86 4.7. DNS cache . . . . . . . . . . . . . . . . . . . . . . . . 18 87 5. Considerations due ALG requirements . . . . . . . . . . . . . 19 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 7. Changes since RFC2767 and RFC3338 . . . . . . . . . . . . . . 21 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 94 Appendix A. Implementation option for the ENR . . . . . . . . . . 25 95 Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 26 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 98 1. Introduction 100 This document describes Bump-in-the-Host (BIH), a successor and 101 combination of the Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the- 102 API (BIA) [RFC3338] technologies, which enable IPv4-only legacy 103 applications to communicate with IPv6-only servers by synthesizing 104 IPv4 addresses from AAAA records. 106 The supported class of applications includes those that use DNS for 107 IP address resolution and that do not embed IP address literals in 108 protocol payloads. This essentially includes legacy client-server 109 applications using the DNS that are agnostic to the IP address family 110 used by the destination and that are able to do NAT traversal. The 111 synthetic IPv4 addresses shown to applications are taken from the 112 RFC1918 private address pool in order to ensure that possible NAT 113 traversal techniques will be initiated. 115 IETF recommends using dual-stack or tunneling based solutions for 116 IPv6 transition and specifically recommends against deployments 117 utilizing double protocol translation. Use of BIH together with a 118 NAT64 is NOT RECOMMENDED [I-D.arkko-ipv6-transition-guidelines]. 120 BIH includes two major implementation options: a protocol translator 121 between the IPv4 and the IPv6 stacks of a host, or an API translator 122 between the IPv4 socket API module and the TCP/IP module. 123 Essentially, IPv4 is translated into IPv6 at the socket API layer or 124 at the IP layer. 126 When BIH is implemented at the socket API layer, the translator 127 intercepts IPv4 socket API function calls and invokes corresponding 128 IPv6 socket API function calls to communicate with IPv6 hosts. 130 When BIH is implemented at the networking layer the IPv4 packets are 131 intercepted and converted to IPv6 using the IP conversion mechanism 132 defined in Stateless IP/ICMP Translation Algorithm (SIIT) 133 [I-D.ietf-behave-v6v4-xlate]. The protocol translation has the same 134 benefits and drawbacks as SIIT. 136 The location of the BIH refers essentially to the location of the 137 protocol translation function. The location of DNS synthesis is 138 orthogonal to the location of protocol translation, and may or may 139 not happen at the same level. 141 BIH can be used whenever an IPv4-only application needs to 142 communicate with an IPv6-only server, independently of the address 143 families supported by the access network. Hence the access network 144 can be IPv6-only or dual-stack capable. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119] . 150 This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767] 151 and [RFC3338]. 153 1.1. Acknowledgement of previous work 155 This document is a direct update to and directly derivative from 156 Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's Bump- 157 in-the-Stack [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin 158 Kim, Alain Durand, and Erik Nordmark's Bump-in-the-API [RFC3338], 159 which similarly provide a dual stack host means to communicate with 160 other IPv6 hosts using existing IPv4 applications. 162 2. Components of the Bump-in-the-Host 164 Figure 1 shows the architecture of a host in which BIH is implemented 165 as a socket API layer translator, i.e., as a "Bump-in-the-API". 167 +----------------------------------------------+ 168 | +------------------------------------------+ | 169 | | | | 170 | | IPv4 applications | | 171 | | | | 172 | +------------------------------------------+ | 173 | +------------------------------------------+ | 174 | | Socket API (IPv4, IPv6) | | 175 | +------------------------------------------+ | 176 | +-[ API translator]------------------------+ | 177 | | +-----------+ +---------+ +------------+ | | 178 | | | Ext. Name | | Address | | Function | | | 179 | | | Resolver | | Mapper | | Mapper | | | 180 | | +-----------+ +---------+ +------------+ | | 181 | +------------------------------------------+ | 182 | +--------------------+ +-------------------+ | 183 | | | | | | 184 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 185 | | | | | | 186 | +--------------------+ +-------------------+ | 187 +----------------------------------------------+ 189 Figure 1: Architecture of a dual stack host using protocol 190 translation at socket layer 192 Figure 2 shows the architecture of a host in which BIH is implemented 193 as a network layer translator, i.e., a "Bump-in-the-Stack". 195 +------------------------------------------------------------+ 196 | +------------------------------------------+ | 197 | | IPv4 applications | | 198 | | Host's main DNS resolver | | 199 | +------------------------------------------+ | 200 | +------------------------------------------+ | 201 | | TCP/UDP | | 202 | +------------------------------------------+ | 203 | +------------------------------------------+ +---------+ | 204 | | IPv4 | | | | 205 | +------------------------------------------+ | Address | | 206 | +------------------+ +---------------------+ | Mapper | | 207 | | Protocol | | Extension Name | | | | 208 | | Translator | | Resolver | | | | 209 | +------------------+ +---------------------+ | | | 210 | +------------------------------------------+ | | | 211 | | IPv4 / IPv6 | | | | 212 | +------------------------------------------+ +---------+ | 213 +------------------------------------------------------------+ 215 Figure 2: Architecture of a dual-stack host using protocol 216 translation at the network layer 218 Dual stack hosts defined in RFC 2893 [RFC2893] need applications, 219 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed 220 hosts in this document have an API or network-layer translator to 221 allow existing IPv4 applications to communicate with IPv6-only peers. 222 The BIH architecture consists of an Extension Name Resolver, an 223 Address Mapper, and depending on implementation either a Function 224 Mapper or a Protocol Translator. It is worth noting that Extension 225 Name Resolver's placement is orthogonal decision to placement of 226 protocol translation. For example, the Extension Name Resolver may 227 reside in the socket API while protocol translation takes place at 228 the networking layer. 230 2.1. Function Mapper 232 The function mapper translates an IPv4 socket API function into an 233 IPv6 socket API function. 235 When detecting IPv4 socket API function calls from IPv4 applications, 236 the function mapper intercepts the function calls and invokes IPv6 237 socket API functions that correspond to the IPv4 socket API 238 functions. 240 The function mapper MUST NOT perform function mapping when the 241 application is initiating communications to the address range used by 242 local synthesis and the address mapping table does not have an entry 243 mathching the address. 245 See Appendix B for a list of functions that MUST be intercepted by 246 the function mapper. 248 2.2. Protocol translator 250 The protocol translator translates IPv4 into IPv6 and vice versa 251 using the IP conversion mechanism defined in SIIT 252 [I-D.ietf-behave-v6v4-xlate]. To avoid unnecessary fragmentation, 253 host's IPv4 module should be configured with small enough MTU (IPv6 254 link MTU - 20 bytes). 256 Protocol translation SHOULD NOT be performend for IPv4 packets sent 257 to IPv4 address range used by local synthesis and for which mapping 258 table entry does not exist. The implementation SHOULD attempt to 259 route such packet via IPv4 interfaces instead. 261 2.3. Extension Name Resolver 263 The Extension Name Resolver (ENR) returns a proper answer in response 264 to the IPv4 application's name resolution request. 266 In the case of the socket API layer implementation option, when an 267 IPv4 application tries to do a forward lookup to resolve names via 268 the resolver library (e.g., gethostbyname()), BIH intercepts the 269 function call and instead calls the IPv6 equivalent functions (e.g., 270 getnameinfo()) that will resolve both A and AAAA records. This 271 implementation option is name resolution protocol agnostic, and hence 272 supports techniques such as "hosts-file", NetBIOS, mDNS, and 273 essentially anything underlying operating system uses. 275 In the case of the network layer implementation option, the ENR 276 intercepts the A query and creates an additional AAAA query with 277 essentially the same content. The ENR will then collect replies to 278 both A and AAAA queries and, depending on results, either return an A 279 reply unmodified or synthesize a new A reply. The network layer 280 implementation option will only be able to catch applications' name 281 resolution requests that result in actual DNS queries, hence is more 282 limited when compared to socket API layer implementation option. 284 In either implementation option, if only AAAA records are available 285 for the queried name, the ENR asks the address mapper to assign a 286 local IPv4 address corresponding to each IPv6 address. In the case 287 of the API layer implementation option, the ENR will simply the make 288 API (e.g. gethostbyname) return the synthetic address. In the case 289 of the network-layer implementation option, the ENR synthesizes an A 290 record for the assigned IPv4 address, and delivers it up the stack. 292 If there is a real A record available, the ENR SHOULD NOT synthesize 293 IPv4 addresses. By default an ENR implementation MUST NOT synthesize 294 IPv4 addresses when real A records exist. 296 If the response contains a CNAME or a DNAME record, then the CNAME or 297 DNAME chain is followed until the first terminating A or AAAA record 298 is reached. 300 Application | Network | ENR behavior 301 query | response | 302 ------------+----------+------------------------ 303 A | A | 304 A | AAAA | 305 A | A/AAAA | 307 Figure 3: ENR behavior illustration 309 2.3.1. Special exclusion sets for A and AAAA records 311 An ENR implementation MAY by default exclude certain IPv4 and IPv6 312 addresses seen on received A and AAAA records. The addresses to be 313 excluded by default SHOULD include martian addresses such as those 314 that should not appear in the DNS or on the wire. Additional 315 addresses MAY be excluded based on possibly configurable local 316 policies. 318 2.3.2. DNSSEC support 320 When the ENR is implemented at the network layer, the A record 321 synthesis can cause essentially the same issues as are described in 322 [I-D.ietf-behave-dns64] section 3. To avoid unwanted discarding of 323 synthetic A records on the host's main resolver, the host's main 324 resolver MUST send DNS questions with the CD "Checking Disabled" bit 325 cleared. The ENR can support DNSSEC as any resolver on a host. 327 When the ENR is implemented at the socket API level, there are no 328 problems with DNSSEC, as the ENR itself uses socket APIs for DNS 329 resolution. 331 DNSSEC can also be supported by configuring the (stub) resolver on a 332 host to trust validations done by the ENR located at network layer or 333 alternatively the validating resolver can implement ENR on itself. 335 In order to properly support DNSSEC, the ENR SHOULD be implemented at 336 the socket API level. If the socket API level implementation is not 337 possible, DNSSEC support SHOULD be provided by other means. 339 2.3.3. Reverse DNS lookup 341 When an application initiates a reverse DNS query for a PTR record, 342 to find a name for an IP address, the ENR MUST check whether the 343 queried IP address can be found in the Address Mapper's mapping table 344 and is a local IP address. If an entry is found and the queried 345 address is locally generated, the ENR MUST initiate a corresponding 346 reverse DNS query for the real IPv6 address. In the case application 347 requested reverse lookup for an address not part of the local IPv4 348 address pool, e.g., a global address, the request MUST be forwarded 349 unmodified to the network. 351 For example, when an application initiates a reverse DNS query for a 352 synthesized locally valid IPv4 address, the ENR needs to intercept 353 that query. The ENR asks the address mapper for the IPv6 address 354 that corresponds to the IPv4 address. The ENR shall perform a 355 reverse lookup procedure for the destination's IPv6 address and 356 return the name received as a response to the application that 357 initiated the IPv4 query. 359 2.4. Address Mapper 361 The address mapper maintains a local IPv4 address pool. The pool 362 consists of private IPv4 addresses as per section 4.3. Also, the 363 address mapper maintains a table consisting of pairs of locally 364 selected IPv4 addresses and destinations' IPv6 addresses. 366 When the extension name resolver, translator, or the function mapper 367 requests the address mapper to assign an IPv4 address corresponding 368 to an IPv6 address, the address mapper selects and returns an IPv4 369 address out of the local pool, and registers a new entry into the 370 table. The registration occurs in the following 3 cases: 372 (1) When the extension name resolver gets only AAAA records for the 373 target host name in the dual stack or IPv6-only network and there is 374 no existing mapping entry for the IPv6 addresses. One or more local 375 IPv4 addresses will be returned to application and mappings for local 376 IPv4 addresses to real IPv6 addresses are created. 378 (2) When the extension name resolver gets both A records and AAAA 379 records, but the A records contain only excluded IPv4 addresses. 380 Behavior will follow the case (1). 382 (3) When the function mapper gets a socket API function call 383 triggered by a received IPv6 packet and there is no existing mapping 384 entry for the IPv6 source address (for example, client sent UDP 385 request to anycast address but response was received from unicast 386 address). 388 Other possible combinations are outside of BIH and BIH is not 389 involved in those. 391 3. Behavior and network Examples 393 Figure 4 illustrates a very basic network scenario. An IPv4-only 394 application is running on a host attached to the IPv6-only Internet 395 and is talking to an IPv6-only server. Communication is made 396 possible by Bump-In-the-Host. 398 +----+ +-------------+ 399 | H1 |----------- IPv6 Internet -------- | IPv6 server | 400 +----+ +-------------+ 401 v4 only 402 application 404 Figure 4: Network Scenario #1 406 Figure 5 illustrates a possible network scenario where an IPv4-only 407 application is running on a host attached to a dual-stack network, 408 but the destination server is running on a private site that is 409 numbered with public IPv6 addresses and private IPv4 addresses 410 without port forwarding setup on the NAT44. The only means to 411 contact the server is to use IPv6. 413 +----------------------+ +------------------------------+ 414 | Dual Stack Internet | | IPv4 Private site (Net 10) | 415 | | | | 416 | | | +----------+ | 417 | | | | | | 418 | +----+ +---------+ | | | 419 | | H1 |-------- | NAT44 |-------------| Server | | 420 | +----+ +---------+ | | | 421 | v4 only | | +----------+ | 422 | application | | Dual Stack | 423 | | | 10.1.1.1 | 424 | | | AAAA:2009::1 | 425 | | | | 426 +----------------------+ +------------------------------+ 428 Figure 5: Network Scenario #2 430 Illustrations of host behavior in both implementation options are 431 given here. Figure 6 illustrates the setup where BIH is implemented 432 as a bump in the API, and figure 7 illustrates the setup where BIH is 433 implemented as a bump in the stack. 435 "dual stack" "host6" 436 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name 437 appli- API | ENR Address Function| (v6/v4) Server 438 cation | Mapper Mapper | 439 | | | | | | | | 440 <> | | | 441 | | | | | | | | 442 |------->|------->| Query of IPv4 address for host6. | | 443 | | | | | | | | 444 | | |------------------------------------------------->| 445 | | | Query of 'A' records and 'AAAA' for host6 | 446 | | | | | | | | 447 | | |<-------------------------------------------------| 448 | | | Reply with the 'AAAA' record. | | 449 | | | | | | | 450 | | |<> | 451 | | | | | | | 452 | | |+++++++>| Request one IPv4 address | 453 | | | | corresponding to the IPv6 address. 454 | | | | | | | 455 | | | |<> | 456 | | | | | | | 457 | | |<+++++++| Reply with the IPv4 address. | 458 | | | | | | | 459 |<-------|<-------| Reply with the IPv4 address | 460 | | | | | | | 461 | | | | | | | 462 <> | | | 463 | | | | | | | 464 |=======>|=========================>|An IPv4 Socket API function call 465 | | | | | | | 466 | | | |<+++++++| Request IPv6 addresses| 467 | | | | | corresponding to the | 468 | | | | | IPv4 addresses. | 469 | | | | | | | 470 | | | |+++++++>| Reply with the IPv6 addresses. 471 | | | | | | | 472 | | | | |<> 473 | | | | | | | 474 | An IPv6 Socket API function call.|=======================>| 475 | | | | | | | 476 | | | | |<> | 478 | | | | | | | 479 | An IPv6 Socket API function call.|<=======================| 480 | | | | | | | 481 | | | | |<> 482 | | | | | | | 483 | | | |<+++++++| Request IPv4 addresses| 484 | | | | | corresponding to the | 485 | | | | | IPv6 addresses. | 486 | | | | | | | 487 | | | |+++++++>| Reply with the IPv4 addresses. 488 | | | | | | | 489 |<=======|<=========================| An IPv4 Socket function call. 490 | | | | | | | 492 Figure 6: Example of BIH as API addition 494 "dual stack" "host6" 495 IPv4 stub TCP/ ENR address translator IPv6 496 app res. IPv4 mapper 497 | | | | | | | | 498 <> | | 499 |-->| | | | | | | 500 | |----------->| Query of 'A' records for "host6". | Name 501 | | | | | | | | Server 502 | | | |------------------------------------------->| 503 | | | | Query of 'A' records and 'AAAA' for "host6" 504 | | | | | | | | | 505 | | | |<-------------------------------------------| 506 | | | | Reply only with 'AAAA' record. | 507 | | | | | | | | 508 | | | |<> | 509 | | | | | | | | 510 | | | |-------->| Request one IPv4 address | 511 | | | | | corresponding to each IPv6 address. 512 | | | | | | | | 513 | | | | |<> | 514 | | | | | | | | 515 | | | |<--------| Reply with the IPv4 address. 516 | | | | | | | | 517 | | | |<> 518 | | | | | | | | 519 | |<-----------| Reply with the 'A' record. | | 520 | | | | | | | | 521 |<--|<>| | | 524 | | | | | | | | 525 |=======>|========================>| An IPv4 packet. | 526 | | | | | | | | 527 | | | | |<------| Request IPv6 addresses 528 | | | | | | corresponding to the IPv4 529 | | | | | | addresses. | 530 | | | | | | | | 531 | | | | |------>| Reply with the IPv6| 532 | | | | | | addresses. | 533 | | | | | | | | 534 | | | | | |<> 535 | | | | | | | | 536 | | | |An IPv6 packet. |==========>|========>| 537 | | | | | | | | 538 | | | | | <> 539 | | | | | | | | 540 | | | |An IPv6 packet. |<==========|<========| 541 | | | | | | | | 542 | | | | | |<> 543 | | | | | | | | 544 |<=======|=========================| An IPv4 packet. | 545 | | | | | | | | 547 Figure 7: Example of BIH at the network layer 549 4. Considerations 551 4.1. Socket API Conversion 553 IPv4 socket API functions are translated into IPv6 socket API 554 functions that are semantically as identical as possible and vice 555 versa. See Appendix B for the API list intercepted by BIH. However, 556 IPv4 socket API functions are not fully compatible with IPv6 since 557 IPv4 supports features that are not present in IPv6, such as 558 SO_BROADCAST. 560 4.2. Socket bindings 562 BIH SHOULD select a source address for a socket from the recommended 563 source address pool if a socket used for communications has not been 564 explicitly bound to any IPv4 address. 566 Binding of explicitly bound socket MUST NOT be changed by the BIH. 568 4.3. ICMP Message Handling 570 When an application needs ICMP messages values (e.g., Type, Code, 571 etc.) sent from the network layer, ICMPv4 message values MAY be 572 translated into ICMPv6 message values based on SIIT 573 [I-D.ietf-behave-v6v4-xlate], and vice versa. 575 4.4. IPv4 Address Pool and Mapping Table 577 The address pool consists of the private IPv4 addresses as per 578 [RFC1918]. This pool can be implemented at different granularities 579 in the node, e.g., a single pool per node, or at some finer 580 granularity such as per-user or per-process. In the case of a large 581 number of IPv4 applications communicating with a large number of IPv6 582 servers, the available address space may be exhausted if the 583 granularity is not fine enough. This should be a rare event and 584 chances will decrease as IPv6 support increases. The applications 585 may use IPv4 addresses they learn for much longer period than DNS 586 time-to-live indicates. Therefore, the mapping table entries should 587 be kept active for a long period of time. For example, a web browser 588 may initiate one DNS query and then create multiple TCP sessions over 589 time to the address it learns. When address mapping table clean-up 590 is required the BIH may utilize techniques used by network address 591 translators, such as described in [RFC2663], [RFC5382], and 592 [RFC5508]. 594 The RFC1918 address space was chosen because generally legacy 595 applications understand it as a private address space. A new 596 dedicated address space would run a risk of not being understood by 597 applications as private. 127/8 and 169.254/16 are rejected due to 598 possible assumptions applications may make when seeing those. 600 The RFC1918 addresses used by the BIH have a risk of conflicting with 601 addresses used in host's possible IPv4 interfaces and corresponding 602 local networks. The conflicts can be mitigated, but not fully 603 avoided, by using less commonly used portions of the RFC1918 address 604 space. Addresses from 172.16/12 are thought to be less likely to be 605 in conflict than addresses from 10/8 or 192.168/16 spaces. A source 606 address can usually be selected in non-conflicting manner, but small 607 possibility exist for synthesized destination addresses being in 608 conflict with real addresses used in local IPv4 networks. 610 The RECOMMENDED IPv4 addresses are following: 612 Primary source addresses: 172.21.112.0/30. Source addresses have to 613 be allocated because applications use getsockname() calls and in the 614 network layer mode an IP address of the IPv4 interface has to be 615 shown (e.g., by 'ifconfig'). More than one address is allocated to 616 allow implementation flexibility, e.g., for cases where a host has 617 multiple IPv6 interfaces. The source addresses are from different 618 subnets than destination addresses to that ensure applications would 619 not make on-link assumptions and would instead enable NAT traversal 620 functions. 622 Secondary source addresses: 10.170.224.0/20. These addresses are 623 recommended a if host has conflict with primary source addresses. 625 Primary destination addresses: 10.170.160.0/20. The address mapper 626 will select destination addresses primarily out of this pool. 628 Secondary destination addresses: 172.21.80.0/20. The address mapper 629 will select destination addresses out of this pool if the node has a 630 dual-stack connection conflicting with primary destination addresses. 632 4.5. Multi-interface 634 In the case of dual-stack destinations BIH MUST NOT do protocol 635 translation from IPv4 to IPv6 when the host has any IPv4 interfaces, 636 native or tunneled, available for use. 638 It is possible that an IPv4 interface is activated during BIH 639 operation, for example if a node moves to a coverage area of an IPv4- 640 enabled network. In such an event, BIH MUST stop initiating protocol 641 translation sessions for new connections and BIH MAY disconnect 642 active sessions. The choice of disconnection is left for 643 implementations and it may depend on whether IPv4 address conflict 644 occurs between addresses used by BIH and addresses used by the new 645 IPv4 interface. 647 4.6. Multicast 649 Protocol translation for multicast is not supported. 651 4.7. DNS cache 653 When BIH shuts down, e.g., due to an IPv4 interface becoming 654 available, BIH MUST flush the node's DNS cache of possible locally 655 generated entries. This cache may be in the ENR itself, but also 656 possibly host's caching stub resolver. 658 5. Considerations due ALG requirements 660 No ALG functionality is specified herein as ALG design is generally 661 not encouraged for host-based translation and as BIH is intended for 662 applications that do not include IP addresses in protocol payloads. 664 6. Security Considerations 666 The security considerations of BIH mostly relies on that of 667 [I-D.ietf-behave-v6v4-xlate-stateful]. 669 In the socket-layer implementation approach, the differences are due 670 to the address translation occurring at the API and not in the 671 network layer. That is, since the mechanism uses the API translator 672 at the socket API layer, hosts can utilize the security of the 673 network layer (e.g., IPsec) when they communicate with IPv6 hosts 674 using IPv4 applications via the mechanism. As such, there is no need 675 for DNS ALG as in NAT-PT, so there is no interference with DNSSEC 676 either. 678 In the network-layer implementation approach, IPv4-using IKE will not 679 work. This means IPv4-based IPsec/IKE using VPN solutions cannot 680 work through BIH. However, transport and application layer solutions 681 such as TLS or SSL-VPN do work through BIH. 683 The use of address pooling may open a denial-of-service attack 684 vulnerability. So BIH should employ the same sort of protection 685 techniques as NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] does. 687 7. Changes since RFC2767 and RFC3338 689 This document combines and obsoletes both [RFC2767] and [RFC3338]. 691 The changes in this document mainly reflect the following components: 693 1. Supporting IPv6-only network connections 695 2. The IPv4 address pool uses private address instead of reserved 696 IPv4 addresses (0.0.0.1 - 0.0.0.255) 698 3. Extending ENR and address mapper to operate differently 700 4. Adding an alternative way to implement the ENR 702 5. Standards track instead of experimental/informational 704 6. Supporting reverse (PTR) queries 706 8. Acknowledgments 708 The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou, 709 Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of 710 this document. 712 The efforts of Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco 713 Cortes, Marnix Goossens, Ala Hamarsheh, Ed Jankiewizh, Suresh 714 Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu, 715 Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, and 716 James Woodyatt in reviewing this document are gratefully 717 acknowledged. 719 Special acknowledgements go to Dave Thaler for his extensive review 720 and support. 722 The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, 723 Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. 724 The authors of RFC3338 acknowledged implementation contributions by 725 Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation 726 (www.i2soft.net). 728 The authors of Bump-in-the-Wire (BIW) (draft-ietf-biw-00.txt, October 729 2006), P. Moster, L. Chin, and D. Green, are acknowledged. Some 730 ideas and clarifications from BIW have been adapted to this document. 732 9. References 734 9.1. Normative References 736 [I-D.ietf-behave-dns64] 737 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 738 "DNS64: DNS extensions for Network Address Translation 739 from IPv6 Clients to IPv4 Servers", 740 draft-ietf-behave-dns64-11 (work in progress), 741 October 2010. 743 [I-D.ietf-behave-v6v4-xlate] 744 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 745 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 746 progress), September 2010. 748 [I-D.ietf-behave-v6v4-xlate-stateful] 749 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 750 NAT64: Network Address and Protocol Translation from IPv6 751 Clients to IPv4 Servers", 752 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 753 progress), July 2010. 755 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 756 E. Lear, "Address Allocation for Private Internets", 757 BCP 5, RFC 1918, February 1996. 759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 760 Requirement Levels", BCP 14, RFC 2119, March 1997. 762 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 763 (IPv6) Specification", RFC 2460, December 1998. 765 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 766 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 767 RFC 2767, February 2000. 769 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 770 IPv6 Hosts and Routers", RFC 2893, August 2000. 772 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 773 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 774 RFC 3338, October 2002. 776 9.2. Informative References 778 [I-D.arkko-ipv6-transition-guidelines] 779 Arkko, J. and F. Baker, "Guidelines for Using IPv6 780 Transition Mechanisms during IPv6 Deployment", 781 draft-arkko-ipv6-transition-guidelines-14 (work in 782 progress), December 2010. 784 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 785 Translator (NAT) Terminology and Considerations", 786 RFC 2663, August 1999. 788 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 789 Stevens, "Basic Socket Interface Extensions for IPv6", 790 RFC 3493, February 2003. 792 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 793 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 794 RFC 5382, October 2008. 796 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 797 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 798 April 2009. 800 Appendix A. Implementation option for the ENR 802 It is not necessary to implement the ENR at the kernel level, but it 803 can be implemented instead at the user space by setting the host's 804 default DNS server to point to 127.0.0.1. DNS queries would then 805 always be sent to the ENR, which furthermore ensures that both A and 806 AAAA queries are sent to the actual DNS server and A queries are 807 always answered and required mappings created. 809 Appendix B. API list intercepted by BIH 811 The following functions are the API list which SHOULD be intercepted 812 by BIH module when implemented at socket layer. Please note that 813 this list may not be fully exhaustive. 815 The functions that the application uses to pass addresses into the 816 system are: 818 bind() 820 connect() 822 sendmsg() 824 sendto() 826 gethostbyaddr() 828 getnameinfo() 830 The functions that return an address from the system to an 831 application are: 833 accept() 835 recvfrom() 837 recvmsg() 839 getpeername() 841 getsockname() 843 gethostbyname() 845 getaddrinfo() 847 The functions that are related to socket options are: 849 getsocketopt() 851 setsocketopt() 853 As well, raw sockets for IPv4 and IPv6 MAY be intercepted. 855 Most of the socket functions require a pointer to the socket address 856 structure as an argument. Each IPv4 argument is mapped into 857 corresponding an IPv6 argument, and vice versa. 859 According to [RFC3493], the following new IPv6 basic APIs and 860 structures are required. 862 IPv4 new IPv6 863 ------------------------------------------------ 864 AF_INET AF_INET6 865 sockaddr_in sockaddr_in6 866 gethostbyname() getaddrinfo() 867 gethostbyaddr() getnameinfo() 868 inet_ntoa()/inet_addr() inet_pton()/inet_ntop() 869 INADDR_ANY in6addr_any 871 Figure 8 873 BIH MAY intercept inet_ntoa() and inet_addr() and use the address 874 mapper for those. Doing that enables BIH to support literal IP 875 addresses. However, IPv4 address literals can only be used after a 876 mapping entry between the IPv4 address and corresponding IPv6 address 877 has been created. 879 The gethostbyname() and getaddrinfo() calls return a list of 880 addresses. When the name resolver function invokes getaddrinfo() and 881 getaddrinfo() returns multiple IP addresses, whether IPv4 or IPv6, 882 they SHOULD all be represented in the addresses returned by 883 gethostbyname(). Thus if getaddrinfo() returns multiple IPv6 884 addresses, this implies that multiple address mappings will be 885 created; one for each IPv6 address. 887 Authors' Addresses 889 Bill Huang 890 China Mobile 891 53A,Xibianmennei Ave., 892 Xuanwu District, 893 Beijing 100053 894 China 896 Email: bill.huang@chinamobile.com 898 Hui Deng 899 China Mobile 900 53A,Xibianmennei Ave., 901 Xuanwu District, 902 Beijing 100053 903 China 905 Email: denghui02@gmail.com 907 Teemu Savolainen 908 Nokia 909 Hermiankatu 12 D 910 FI-33720 TAMPERE 911 Finland 913 Email: teemu.savolainen@nokia.com