idnits 2.17.1 draft-ietf-behave-v4v6-bih-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The abstract seems to contain references ([RFC3338], [RFC2767]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 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 directly say this. It does mention RFC3338 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2767, but the abstract doesn't seem to directly say this. It does mention RFC2767 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 494 has weird spacing: '...address trans...' == 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 (October 19, 2010) is 4931 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) == Missing Reference: 'DNS64' is mentioned on line 316, but not defined ** 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) -- Obsolete informational reference (is this intentional?): RFC 2553 (Obsoleted by RFC 3493) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 4 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: April 22, 2011 October 19, 2010 9 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) 10 draft-ietf-behave-v4v6-bih-01 12 Abstract 14 This document describes the "Bump-In-the-Host" (BIH), a host based 15 IPv4 to IPv6 protocol translation mechanism that allows a subset of 16 applications supporting only IPv4 to communicate with peers that are 17 reachable only with IPv6. A host may be connected to IPv6-only or 18 dual-stack access network. Essentially BIH makes the IPv4 19 applications think they talk to IPv4 peers and hence hides the 20 existence of IPv6 from those applications. 22 Acknowledgement of previous work 24 This document is an update to and directly derivative from Kazuaki 25 TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI [RFC2767] and 26 from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and 27 Erik Nordmark's [RFC3338], which similarly provides a dual stack host 28 means to communicate with other IPv6 host using existing IPv4 29 appliations. This document combines and updates both [RFC2767] and 30 [RFC3338]. 32 The changes in this document reflect five components 34 1. Supporting IPv6 only network connections 36 2. IPv4 address pool use private address instead of the 37 unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255) 39 3. Extending ENR and address mapper to operate differently 41 4. Adding an alternative way to implement the ENR 43 5. Going for standards track instead of experimental/ 44 informational 46 Status of this Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on April 22, 2011. 62 Copyright Notice 64 Copyright (c) 2010 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 This document may contain material from IETF Documents or IETF 78 Contributions published or made publicly available before November 79 10, 2008. The person(s) controlling the copyright in some of this 80 material may not have granted the IETF Trust the right to allow 81 modifications of such material outside the IETF Standards Process. 82 Without obtaining an adequate license from the person(s) controlling 83 the copyright in such materials, this document may not be modified 84 outside the IETF Standards Process, and derivative works of it may 85 not be created outside the IETF Standards Process, except to format 86 it for publication as an RFC or to translate it into languages other 87 than English. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 2. Components of the Bump-in-the-Host . . . . . . . . . . . . . . 6 93 2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 7 94 2.2. Translator . . . . . . . . . . . . . . . . . . . . . . . . 8 95 2.3. Extension Name Resolver . . . . . . . . . . . . . . . . . 8 96 2.3.1. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9 97 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 9 98 3. Behavior and network Examples . . . . . . . . . . . . . . . . 11 99 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 15 100 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 15 101 4.2. ICMP Message Handling . . . . . . . . . . . . . . . . . . 15 102 4.3. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 15 103 4.4. Multi-interface . . . . . . . . . . . . . . . . . . . . . 16 104 4.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 16 105 4.6. DNS cache . . . . . . . . . . . . . . . . . . . . . . . . 16 106 5. Considerations due ALG requirements . . . . . . . . . . . . . 17 107 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 108 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 110 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 111 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 112 Appendix A. Implementation option for the ENR . . . . . . . . . . 21 113 Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 22 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 116 1. Introduction 118 While IPv6 support is being widely introduced throughout the 119 Internet, classes of applications are going to remain IPv4-only. 120 This document describes a Bump-in-the-Host (BIH), successor and 121 combination of Bump-in-the-Stack (BIS) [RFC2767] and Bump-in-the-API 122 (BIA) [RFC3338] technologies, which enables accommodation of 123 significant set of the legacy IPv4-only applications in the IPv6- 124 world. 126 Bump-In-the-Host is not recommended to be used in double translation 127 scenarios if the server is dual-stack enabled. The class of IPv4- 128 only applications the described host-based protocol translation 129 solution provides Internet connectivity over IPv6-only network access 130 includes those applications that use DNS for IP address resolution 131 and that do not embed IP address literals in protocol payloads. This 132 includes essentially all DNS using legacy client-server model 133 applications, which are agnostic on IP address family used by the 134 destination, but not other classes of applications. The transition 135 towards IPv6-only Internet is made easier by decreasing number of key 136 applications that must be updated to IPv6. 138 BIH technique includes two major implementation options: a protocol 139 translator between the IPv4 and the IPv6 stacks of a host or between 140 the socket API module and the TCP/IP module. Essentially, IPv4 is 141 translated into IPv6 at the socket API level or at the IP level. 143 When the BIH is implemented at the socket API layer, and IPv4 144 applications communicate with IPv6 peers, the API translator 145 intercepts the socket API functions from IPv4 applications and 146 invokes the IPv6 socket API functions to communicate with the IPv6 147 hosts, and vice versa. 149 When the BIH is implemented at the networking layer, the IPv4 packets 150 are intercepted and converted to IPv6 using the IP conversion 151 mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate]. The 152 translation has the same benefits and drawbacks as SIIT. 154 In order to support communication between IPv4 applications and the 155 target IPv6 peers, pooled IPv4 addresses as defined in section 4.3 156 will be assigned through the extension name resolver. 158 The BIH can be used whenever an IPv4-only application needs to 159 communicate with a peer reachable only with IPv6, independently of 160 the address families supported by the access network. Hence the 161 access network can be IPv6-only or dual-stack capable. 163 In the case BIH enabled host has a possibility to choose between 164 IPv4-only path or path including IPv4 to IPv6 protocol translation, 165 the host MUST select IPv4-only path. However, lacking IPv4-only path 166 and on request BIH will attempt protocol translation also in the case 167 a destination has IPv4 addresses in addition to IPv6. 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119] . 173 This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767] 174 and [RFC3338]. 176 2. Components of the Bump-in-the-Host 178 Figure 1 shows the architecture of the host in which BIH is 179 implemented as socket API layer translator, i.e. as the original 180 "Bump-in-the-API". 182 +----------------------------------------------+ 183 | +------------------------------------------+ | 184 | | | | 185 | | IPv4 applications | | 186 | | | | 187 | +------------------------------------------+ | 188 | +------------------------------------------+ | 189 | | Socket API (IPv4, IPv6) | | 190 | +------------------------------------------+ | 191 | +-[ API translator]------------------------+ | 192 | | +-----------+ +---------+ +------------+ | | 193 | | | Ext. Name | | Address | | Function | | | 194 | | | Resolver | | Mapper | | Mapper | | | 195 | | +-----------+ +---------+ +------------+ | | 196 | +------------------------------------------+ | 197 | +--------------------+ +-------------------+ | 198 | | | | | | 199 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 200 | | | | | | 201 | +--------------------+ +-------------------+ | 202 +----------------------------------------------+ 204 Figure 1: Architecture of the dual stack host using BIH at socket 205 layer 207 Figure 2 shows the architecture of the host in which BIH is 208 implemented as network layer translator, i.e. as the original "Bump- 209 in-the-Stack". 211 +-------------------------------------------------------------+ 212 | +-------------------------------------------------------+ | 213 | | IPv4 applications | | 214 | +-------------------------------------------------------+ | 215 | +-------------------------------------------------------+ | 216 | | TCP/IPv4 | | 217 | | +---------------------------------------------------+ | 218 | | | +-----------+ +---------+ +---------------+ | 219 | | | | Extension | | Address | | Translator | | 220 | | | | Name | | Mapper | +---------------+ | 221 | | | | Resolver | | | +---------------+ | 222 | | | | | | | | IPv6 | | 223 | +---+ +-----------+ +---------+ +---------------+ | 224 | +-------------------------------------------------------+ | 225 | | Network card drivers | | 226 | +-------------------------------------------------------+ | 227 +-------------------------------------------------------------+ 228 +-------------------------------------------------------------+ 229 | Network cards | 230 +-------------------------------------------------------------+ 232 Figure 2: Architecture of the dual-stack host using BIH at network 233 layer 235 Dual stack hosts defined in RFC2893 [RFC2893] need applications, 236 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed 237 hosts in this document have an API or network layer translator to 238 communicate with other IPv6 hosts using existing IPv4 applications. 239 The BIH translator consists of an extension name resolver, an address 240 mapper, and depending on implementation either a function mapper or a 241 protocol translator. 243 2.1. Function Mapper 245 Function mapper translates an IPv4 socket API function into an IPv6 246 socket API function, and vice versa. 248 When detecting IPv4 socket API function calls from IPv4 applications, 249 function mapper intercepts the function calls and invokes new IPv6 250 socket API functions which correspond to the IPv4 socket API 251 functions. Those IPv6 API functions are used to communicate with the 252 target IPv6 peers. When detecting IPv6 socket API function calls 253 triggered by the data received from the IPv6 peers, function mapper 254 works symmetrically in relation to the previous case. 256 2.2. Translator 258 Translator translates IPv4 into IPv6 and vice versa using the IP 259 conversion mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate]. 261 When receiving IPv4 packets from IPv4 applications, translator 262 converts IPv4 packet headers into IPv6 packet headers, then, if 263 required, fragments the IPv6 packets (because header length of IPv6 264 is typically 20 bytes larger than that of IPv4), and sends them to 265 IPv6 networks. When receiving IPv6 packets from the IPv6 networks, 266 translator works symmetrically to the previous case, except that 267 there is no need to fragment the packets. 269 The translator module has to adjust transport protocol checksums when 270 translating between IPv4 and IPv6. In the IPv6 to IPv4 direction the 271 translator also has to calculate IPv4 header checksum. 273 2.3. Extension Name Resolver 275 Extension Name Resolver returns a proper answer in response to the 276 IPv4 application's name resolution request. 278 In the case of socket API implementation option, when an IPv4 279 application in an IPv6 only network tries to do forward lookup to 280 resolve names via the resolver library (e.g. gethostbyname()), BIH 281 intercept the function call and instead calls the IPv6 equivalent 282 functions (e.g. getnameinfo()) that will resolve both A and AAAA 283 records. 285 If only AAAA record is available for the name queried, ENR requests 286 the address mapper to assign a local IPv4 address corresponding to 287 the IPv6 address, creates an A record for the assigned IPv4 address, 288 and returns the A record to the IPv4 application. 290 If both A and AAAA record are available in the IPv6 only network, ENR 291 does not require address mapper to assign IPv4 address, but instead 292 asks address mapper to store relationship between the A and AAAA 293 records, and then directly passes the received A record to the IPv4 294 application. Note: this is a scenario where a host should use 295 encapsulation instead to avoid protocol translation taking place at a 296 host. 298 If only an A record is available it will be passed unmodified to the 299 application so that the application learns a record exists for the 300 destination. However, the application will not be able to use the 301 address for communications if the host is in IPv6-only access 302 network. If the application tries to send data to such an IPv4 303 address destination unreachable/host unreachable error will be 304 returned, which allows application to behave accordingly. 306 Application | Network | ENR behaviour 307 query | response | 308 ------------+----------+--------------------- 309 A | A | 310 A | AAAA | 311 A | A/AAAA | 313 Figure 3: ENR behaviour illustration 315 NOTE: An implementation option is to have ENR support in host's 316 (stub) DNS resolver itself as described in [DNS64], in which case 317 record synthesis is not needed and advanced functions such as DNSSEC 318 are possible. If the ENR is implemented at the network layer, same 319 limitations arise as when DNS record synthesis is done on the 320 network. A host also has an option to implement recursive DNS server 321 function. 323 2.3.1. Reverse DNS lookup 325 When an application initiates a reverse DNS query for a PTR record 326 (in-addr.arpa), to find a name for an IP address, the ENR MUST check 327 whether the queried IP address can be found in the Address Mapper's 328 mapping table and is a local IP address. If an entry is found and 329 the queried address is locally generated, the ENR must initiate 330 corresponding reverse DNS query for the real IPv6 address (ip6.arpa). 331 In the case application requested reverse lookup for an address not 332 part of the local IPv4 address pool, e.g. a global address, the 333 request shall be forwarded unmodified to the network. 335 For example, when an application initiates reverse DNS query for a 336 synthesized locally valid IPv4 address, the ENR needs to intercept 337 that query. The ENR will ask the address mapper for the IPv6 address 338 that corresponds to the IPv4 address. The ENR shall perform reverse 339 lookup procedure for the destination's IPv6 address and return the 340 name received as a response to the application that initiated the 341 IPv4 query. 343 2.4. Address Mapper 345 Address mapper ("the mapper" later on), maintains a local IPv4 346 address pool in the case of dual stack network and IPv6 only network. 347 The pool consists of private IPv4 addresses as per section 4.3. 348 Also, mapper maintains a table consisting of pairs of locally 349 selected IPv4 addresses and destinationss' IPv6 addresses. 351 When the extension name resolver, translator, or the function mapper 352 requests mapper to assign an IPv4 address corresponding to an IPv6 353 address, mapper selects and returns an IPv4 address out of the local 354 pool, and registers a new entry into the table. The registration 355 occurs in the following 3 cases: 357 (1) When the extension name resolver gets only an 'AAAA' record for 358 the target host name in the dual stack or IPv6 only network and there 359 is no existing mapping entry for the IPv6 address. A local IPv4 360 address will be returned to application and mapping for local IPv4 361 address to real IPv6 address is created. 363 (2) When the extension name resolver gets both an 'A' record and an 364 'AAAA' record for the target host name in the IPv6 only network and 365 there is no existing apping entry for the IPv6 address. In this case 366 local IPv4 address does not need to be selected, but mapping entry 367 has to be created between IPv4 and IPv6 addresses from 'A' and 'AAAA' 368 records. The IPv4 address will be returned to an application. Note: 369 this is a scenario where IPv4 communications, native or encapsulated, 370 are preferred over translation. 372 (3) When the function mapper gets a socket API function call 373 triggered by received IPv6 packet and there is no existing mapping 374 entry for the IPv6 source address (Editor's note: can this ever 375 happen in case of client-server nature of BIH?). 377 Other possible combinations are outside of BIH and BIH is not 378 involved in those. 380 NOTE: There is one exception. When initializing the table the mapper 381 registers a pair of its own IPv4 address and IPv6 address into the 382 table. 384 3. Behavior and network Examples 386 Figure 4 illustrates the very basic network scenario. An IPv4-only 387 application is running on a host attached to IPv6-only Internet and 388 is talking to IPv6 enabled server. A communication is made possible 389 by bump in the host. 391 It is worth noting that while the IPv6 server may additionally have 392 IPv4 addresses, those are unreachable for the host not having any 393 direct IPv4 connectivity, and hence can be considered irrelevant. 395 +----+ +-------------+ 396 | H1 |----------- IPv6 Internet -------- | IPv6 server | 397 +----+ +-------------+ 398 v4 only 399 application 401 Figure 4: Network Scenario #1 403 Figure 5 illustrates a possible network scenario where an IPv4-only 404 application is running on a host attached to a dual-stack network, 405 but the destination server is running on a private site that is 406 numbered with public IPv6 addresses and private IPv4 addresses 407 without port forwarding setup on NAT44. The only means to contact to 408 server is to use IPv6. 410 +----------------------+ +------------------------------+ 411 | Dual Stack Internet | | IPv4 Private site (Net 10) | 412 | | | | 413 | | | +----------+ | 414 | | | | | | 415 | +----+ +---------+ | | | 416 | | H1 |-------- | NAT44 |-------------| Server | | 417 | +----+ +---------+ | | | 418 | v4 only | | +----------+ | 419 | application | | Dual Stack | 420 | | | etc. 10.1.1.1 | 421 | | | AAAA:2009::1 | 422 | | | | 423 +----------------------+ +------------------------------+ 425 Figure 5: Network Scenario #2 427 Illustrations of host behavior in both implementation options are 428 given here. Figure 6 illustrates the setup where BIH is implemented 429 as a bump in the API, and figure 7 illustrates the setup where BIH is 430 implemented as a bump in the stack. 432 "dual stack" "host6" 433 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name 434 appli- API | ENR Address Function| (v6/v4) Server 435 cation | Mapper Mapper | 436 | | | | | | | | 437 <> | | | 438 | | | | | | | | 439 |--------|------->| Query of 'A' records for host6. | | 440 | | | | | | | | 441 | | |--------|--------|---------|--------------|------>| 442 | | | Query of 'A' records and 'AAAA' for host6 | 443 | | | | | | | | 444 | | |<-------|--------|---------|--------------|-------| 445 | | | Reply with the 'AAAA' record. | | 446 | | | | | | | 447 | | |<> | 448 | | | | | | | 449 | | |+++++++>| Request one IPv4 address | 450 | | | | corresponding to the IPv6 address. 451 | | | | | | | 452 | | | |<> | 453 | | | | | | | 454 | | |<+++++++| Reply with the IPv4 address. | 455 | | | | | | | 456 | | |<> 457 | | | | | | | 458 |<-------|--------| Reply with the 'A' record.| | 459 | | | | | | | 460 | | | | | | | 461 <> | | | 462 | | | | | | | 463 |========|========|========|=======>|An IPv4 Socket API function Call 464 | | | | | | | 465 | | | |<+++++++| Request IPv6 addresses| 466 | | | | | corresponding to the | 467 | | | | | IPv4 addresses. | 468 | | | | | | | 469 | | | |+++++++>| Reply with the IPv6 addresses. 470 | | | | | | | 471 | | | | |<> 472 | | | | | | | 473 | An IPv6 Socket API function call.|=========|=============>| 474 | | | | | | | 475 | | | | |<> | 477 | | | | | | | 478 | An IPv6 Socket API function call.|<========|==============| 479 | | | | | | | 480 | | | | |<> 481 | | | | | | | 482 | | | |<+++++++| Request IPv4 addresses| 483 | | | | | corresponding to the | 484 | | | | | IPv6 addresses. | 485 | | | | | | | 486 | | | |+++++++>| Reply with the IPv4 addresses. 487 | | | | | | | 488 |<=======|========|========|========| An IPv4 Socket function call. 489 | | | | | | | 491 Figure 6: Example of BIH as API addition 493 "dual stack" "host6" 494 IPv4 TCP/ ENR address translator IPv6 495 appli- IPv4 mapper 496 cation 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 the IPv6 address. 512 | | | | | | | 513 | | | |<> | 514 | | | | | | | 515 | | |<--------| Reply with the IPv4 address. 516 | | | | | | | 517 | | |<> 518 | | | | | | | 519 |<-----|-------| Reply with the 'A' record. | | 520 | | | | | | | 521 | | | | | | | 522 <>| | | 523 | | | | | | | 524 |======|=======|=========|======>| An IPv4 packet. | 525 | | | | | | | 526 | | | |<------| Request IPv6 addresses 527 | | | | | corresponding to the IPv4 528 | | | | | addresses. | 529 | | | | | | | 530 | | | |------>| Reply with the IPv6| 531 | | | | | addresses. | 532 | | | | | | | 533 | | | | |<> 534 | | | | | | | 535 | | |An IPv6 packet. |===========|========>| 536 | | | | | | | 537 | | | | <> | 539 | | | | | | | 540 | | |An IPv6 packet. |<==========|=========| 541 | | | | | | | 542 | | | | |<> 543 | | | | | | | 544 |<=====|=======|=========|=======| An IPv4 packet. | 545 | | | | | | | 547 Figure 7: Example of BIH at network layer 549 4. Considerations 551 4.1. Socket API Conversion 553 IPv4 socket API functions are translated into semantically as same 554 IPv6 socket API functions as possible and vice versa. See Appendix B 555 for the API list intercepted by BIH. However, IPv4 socket API 556 functions are not fully compatible with IPv6 since the IPv6 has new 557 advanced features. 559 4.2. ICMP Message Handling 561 When an application needs ICMP messages values (e.g., Type, Code, 562 etc.) sent from a network layer, ICMPv4 message values MAY be 563 translated into ICMPv6 message values based on SIIT 564 [I-D.ietf-behave-v6v4-xlate], and vice versa. It can be implemented 565 using raw socket. 567 4.3. IPv4 Address Pool and Mapping Table 569 The address pool consists of the private IPv4 addresses as per 570 [RFC1918]. This pool can be implemented at different granularity in 571 the node e.g., a single pool per node, or at some finer granularity 572 such as per user or per process. However, if a number of IPv4 573 applications communicate with IPv6 hosts, the available address 574 spaces may be exhausted. As a result, it will be impossible for IPv4 575 applications to communicate with IPv6 nodes. It requires smart 576 management techniques for address pool. For example, it is desirable 577 for the mapper to free the oldest entry and reuse the IPv4 address or 578 IPv6 address for creating a new entry. In case of a per-node address 579 mapping table, it MAY cause a larger risk of running out of address. 581 The RFC1918 address space was chosen because generally legacy 582 applications understand that as a private address space. A new 583 dedicated address space would run a risk of not being understood by 584 applications as private. 127/8 or 169.254/16 are rejected due 585 possible assumptions applications may make when seeing those. 587 The RFC1918 addresses have a risk of conflicting with other 588 interfaces. The conflicts can be mitigated by using least commonly 589 used network number of the RFC1918 address space. Addresses from 590 172.16/12 prefix are thought to be less likely to conflict than 591 addresses from 10/8 or 192.168/16 spaces, hence the used IPv4 592 addresses are following (Editor's comment: this is first and almost 593 random proposals): 595 Source addresses: 172.21.112.0/30. Source address have to be 596 allocated because applications use getsockname() calls and as in the 597 BIS mode an IP address of the IPv4 interface has to be shown. More 598 than one address is allocated to allow implementation flexibility, 599 e.g. for cases where a host has multiple IPv6 interfaces. The source 600 addresses are from different subnet than destination addresses to 601 ensure applications do not do on-link assumptions and do enable NAT 602 traversal functions. 604 Primary destination addresses: 172.21.80.0/20. Address mapper will 605 select destination addresses primarily out of this pool. 607 Secondary destination addresses: 10.170.160.0/20. Address mapper 608 will select destination addresses out of this pool if the node has 609 dual-stack connection conflicting with primary destination addresses. 611 4.4. Multi-interface 613 In the case of dual-stack destinations BIH must do protocol 614 translation from IPv4 to IPv6 only when the host does not have any 615 IPv4 interfaces, native or tunneled, available for use. 617 It is possible that an IPv4 interface is activated during BIH 618 operation, for example if a node moves to a coverage area of IPv4 619 enabled network. In such an event BIH must stop initiating protocol 620 translation sessions for new connections and BIH may disconnect 621 active sessions. The choice of disconnection is left for 622 implementatations and it may depend on whether IPv4 address conflict 623 situation occurs between addresses used by BIH and addresses used by 624 new IPv4 interface. 626 4.5. Multicast 628 Protocol translation for multicast is not supported. 630 4.6. DNS cache 632 When BIH module shuts down, e.g. due IPv4 interface becoming 633 available, BIH must flush node's DNS cache of possible locally 634 generated entries. 636 5. Considerations due ALG requirements 638 No ALG functionality is specified herein as ALG design is generally 639 not encouraged for host based translation and as BIH is intended for 640 applications not including IP addresses in protocol payloads. 642 6. Security Considerations 644 The security consideration of BIH mostly relies on that of 645 [I-D.ietf-behave-v6v4-xlate-stateful]. 647 In the socket layer implementation approach the differences are due 648 to the address translation occurring at the API and not in the 649 network layer. That is, since the mechanism uses the API translator 650 at the socket API level, hosts can utilize the security of the 651 network layer (e.g., IPSec) when they communicate with IPv6 hosts 652 using IPv4 applications via the mechanism. As well, there is no need 653 for DNS ALG as in NAT-PT, so there is no interference with DNSSEC 654 either. 656 In the network layer implementation approach hosts cannot utilize the 657 security above network layer when they communicate with IPv6 hosts 658 using IPv4 applications via BIH and encrypt embedded IP addresses, or 659 when the protocol data is encrypted using IP addresses as keys. In 660 these cases it is impossible for the mechanism to translate the IPv4 661 data into IPv6 and vice versa. Therefore it is highly desirable to 662 upgrade to the applications modified into IPv6 for utilizing the 663 security at communication with IPv6 hosts. 665 The use of address pooling may open a denial of service attack 666 vulnerability. So BIH should employ the same sort of protection 667 techniques as NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] does. 669 7. Acknowledgments 671 The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou, 672 Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of 673 this document. 675 The efforts of Suresh Krishnan, Mohamed Boucadair, Yiu L. Lee, James 676 Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng, 677 Christian Vogt, Jan M. Melen, and Ed Jankiewizh in reviewing this 678 document are gratefully acknowledged. 680 Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly 681 appreciated 683 The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, 684 Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. 685 The authors of RFC3338 acknowledged implementation contributions by 686 Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation 687 (www.i2soft.net). 689 The authors of Bump-in-the-Wire (draft-ietf-biw-00.txt, October 690 2006), P. Moster, L. Chin, and D. Green, are acknowledged. Few ideas 691 and clarifications from BIW have been adapted to this document. 693 8. References 695 8.1. Normative References 697 [I-D.ietf-behave-v6v4-xlate] 698 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 699 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 700 progress), September 2010. 702 [I-D.ietf-behave-v6v4-xlate-stateful] 703 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 704 NAT64: Network Address and Protocol Translation from IPv6 705 Clients to IPv4 Servers", 706 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 707 progress), July 2010. 709 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 710 E. Lear, "Address Allocation for Private Internets", 711 BCP 5, RFC 1918, February 1996. 713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, March 1997. 716 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 717 (IPv6) Specification", RFC 2460, December 1998. 719 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 720 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 721 RFC 2767, February 2000. 723 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 724 IPv6 Hosts and Routers", RFC 2893, August 2000. 726 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 727 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 728 RFC 3338, October 2002. 730 8.2. Informative References 732 [RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, 733 "Basic Socket Interface Extensions for IPv6", RFC 2553, 734 March 1999. 736 Appendix A. Implementation option for the ENR 738 It is not necessary to implement the ENR at the kernel level, but it 739 can be implemented instead at the user space by setting the host's 740 default DNS server to point to 127.0.0.1. DNS queries would then 741 always be sent to the ENR, which furthermore ensures both A and AAAA 742 queries are sent to the actual DNS server and A queries are always 743 answered and required mappings created. 745 Appendix B. API list intercepted by BIH 747 The following functions are the API list which SHOULD be intercepted 748 by BIH module when implemented at socket layer. 750 The functions that the application uses to pass addresses into the 751 system are: 753 bind() 755 connect() 757 sendmsg() 759 sendto() 761 The functions that return an address from the system to an 762 application are: 764 accept() 766 recvfrom() 768 recvmsg() 770 getpeername() 772 getsockname() 774 The functions that are related to socket options are: 776 getsocketopt() 778 setsocketopt() 780 The functions that are used for conversion of IP addresses embedded 781 in application layer protocol (e.g., FTP, DNS, etc.) are: 783 recv() 785 send() 787 read() 789 write() 791 As well, raw sockets for IPv4 and IPv6 MAY be intercepted. 793 Most of the socket functions require a pointer to the socket address 794 structure as an argument. Each IPv4 argument is mapped into 795 corresponding an IPv6 argument, and vice versa. 797 According to [RFC2553], the following new IPv6 basic APIs and 798 structures are required. 800 IPv4 new IPv6 801 ------------------------------------------------ 802 AF_INET AF_INET6 803 sockaddr_in sockaddr_in6 804 gethostbyname() getaddrinfo() 805 gethostbyaddr() getnameinfo() 806 inet_ntoa()/inet_addr() inet_pton()/inet_ntop() 807 INADDR_ANY in6addr_any 809 Figure 8 811 BIH MAY intercept inet_ntoa() and inet_addr() and use the address 812 mapper for those. Doing that enables BIH to support literal IP 813 addresses. 815 The gethostbyname() call return a list of addresses. When the name 816 resolver function invokes getaddrinfo() and getaddrinfo() returns 817 multiple IP addresses, whether IPv4 or IPv6, they SHOULD all be 818 represented in the addresses returned by gethostbyname(). Thus if 819 getaddrinfo() returns multiple IPv6 addresses, this implies that 820 multiple address mappings will be created; one for each IPv6 address. 822 Authors' Addresses 824 Bill Huang 825 China Mobile 826 53A,Xibianmennei Ave., 827 Xuanwu District, 828 Beijing 100053 829 China 831 Email: bill.huang@chinamobile.com 833 Hui Deng 834 China Mobile 835 53A,Xibianmennei Ave., 836 Xuanwu District, 837 Beijing 100053 838 China 840 Email: denghui02@gmail.com 842 Teemu Savolainen 843 Nokia 844 Hermiankatu 12 D 845 FI-33720 TAMPERE 846 Finland 848 Email: teemu.savolainen@nokia.com