idnits 2.17.1 draft-ietf-behave-v4v6-bih-02.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 3 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 500 has weird spacing: '...address trans...' == 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 (January 23, 2011) is 4835 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) -- Obsolete informational reference (is this intentional?): RFC 2553 (Obsoleted by RFC 3493) Summary: 5 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: July 27, 2011 January 23, 2011 9 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) 10 draft-ietf-behave-v4v6-bih-02 12 Abstract 14 Bump-In-the-Host (BIH) is a host based IPv4 to IPv6 protocol 15 translation mechanism that allows class of IPv4-only applications 16 that work through NATs to communicate with IPv6-only peers. The host 17 applications are running on may be connected to IPv6-only or dual- 18 stack access networks. BIH hides IPv6 and makes the IPv4-only 19 applications think they are talking with IPv4 peers by local 20 synthetization of A records. 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 July 27, 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. 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 . . . . . . . . . . . . . . . . . . 9 77 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10 78 3. Behavior and network Examples . . . . . . . . . . . . . . . . 11 79 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 15 81 4.2. ICMP Message Handling . . . . . . . . . . . . . . . . . . 15 82 4.3. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 15 83 4.4. Multi-interface . . . . . . . . . . . . . . . . . . . . . 16 84 4.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 16 85 4.6. DNS cache . . . . . . . . . . . . . . . . . . . . . . . . 16 86 5. Considerations due ALG requirements . . . . . . . . . . . . . 17 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 88 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Appendix A. Implementation option for the ENR . . . . . . . . . . 21 93 Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 22 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 96 1. Introduction 98 This document describes a Bump-in-the-Host (BIH), successor and 99 combination of Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the-API 100 (BIA) [RFC3338] technologies, which enables IPv4-only legacy 101 applications to communicate with IPv6-only servers by synthesizing A 102 records from AAAA records. 104 The supported class of applications includes those that use DNS for 105 IP address resolution and that do not embed IP address literals in 106 protocol payloads. This essentially includes legacy client-server 107 applications using the DNS that are agnostic to the IP address family 108 used by the destination and that are able to do NAT traversal. The 109 synthetic IPv4 addresses shown to applications are taken from RFC1918 110 private address pool in order to ensure possible NAT traversal 111 techniques will be initiated. 113 IETF recommends using dual-stack or tunneling based solutions for 114 IPv6 transition and specifically recommends against deployments 115 utilizing double protocol translation. Use of BIH together with a 116 network-side IP translation is NOT RECOMMENDED as a competing 117 technology for tunneling based transition solutions. 119 BIH technique includes two major implementation options: a protocol 120 translator between the IPv4 and the IPv6 stacks of a host or API 121 translator between the IPv4 socket API module and the TCP/IP module. 122 Essentially, IPv4 is translated into IPv6 at the socket API layer or 123 at the IP layer. 125 When the BIH is implemented at the socket API layer the translator 126 intercepts IPv4 socket API function calls and invokes corresponding 127 IPv6 socket API function calls to communicate with the IPv6 hosts. 129 When the BIH is implemented at the networking layer the IPv4 packets 130 are intercepted and converted to IPv6 using the IP conversion 131 mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate]. The protocol 132 layer translation has the same benefits and drawbacks as SIIT. 134 The BIH can be used whenever an IPv4-only application needs to 135 communicate with an IPv6-only server, independently of the address 136 families supported by the access network. Hence the access network 137 can be IPv6-only or dual-stack capable. 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119] . 143 This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767] 144 and [RFC3338]. 146 1.1. Acknowledgement of previous work 148 This document is direct update to and directly derivative from 149 Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI 150 [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain 151 Durand, and Erik Nordmark's [RFC3338], which similarly provides a 152 dual stack host means to communicate with other IPv6 host using 153 existing IPv4 appliations. 155 This document combines and updates both [RFC2767] and [RFC3338] 157 The changes in this document mainly reflect following components 159 1. Supporting IPv6 only network connections 161 2. IPv4 address pool use private address instead of the 162 unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255) 164 3. Extending ENR and address mapper to operate differently 166 4. Adding an alternative way to implement the ENR 168 5. Going for standards track instead of experimental/ 169 informational 171 6. Supporting reverse (PTR) queries 173 2. Components of the Bump-in-the-Host 175 Figure 1 shows the architecture of the host in which BIH is 176 implemented as socket API layer translator, i.e. as the original 177 "Bump-in-the-API". 179 +----------------------------------------------+ 180 | +------------------------------------------+ | 181 | | | | 182 | | IPv4 applications | | 183 | | | | 184 | +------------------------------------------+ | 185 | +------------------------------------------+ | 186 | | Socket API (IPv4, IPv6) | | 187 | +------------------------------------------+ | 188 | +-[ API translator]------------------------+ | 189 | | +-----------+ +---------+ +------------+ | | 190 | | | Ext. Name | | Address | | Function | | | 191 | | | Resolver | | Mapper | | Mapper | | | 192 | | +-----------+ +---------+ +------------+ | | 193 | +------------------------------------------+ | 194 | +--------------------+ +-------------------+ | 195 | | | | | | 196 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 197 | | | | | | 198 | +--------------------+ +-------------------+ | 199 +----------------------------------------------+ 201 Figure 1: Architecture of the dual stack host using BIH at socket 202 layer 204 Figure 2 shows the architecture of the host in which BIH is 205 implemented as network layer translator, i.e. as the original "Bump- 206 in-the-Stack". 208 +-------------------------------------------------------------+ 209 | +-------------------------------------------------------+ | 210 | | IPv4 applications | | 211 | +-------------------------------------------------------+ | 212 | +-------------------------------------------------------+ | 213 | | TCP/IPv4 | | 214 | | +---------------------------------------------------+ | 215 | | | +-----------+ +---------+ +---------------+ | 216 | | | | Extension | | Address | | Translator | | 217 | | | | Name | | Mapper | +---------------+ | 218 | | | | Resolver | | | +---------------+ | 219 | | | | | | | | IPv6 | | 220 | +---+ +-----------+ +---------+ +---------------+ | 221 | +-------------------------------------------------------+ | 222 | | Network card drivers | | 223 | +-------------------------------------------------------+ | 224 +-------------------------------------------------------------+ 225 +-------------------------------------------------------------+ 226 | Network cards | 227 +-------------------------------------------------------------+ 229 Figure 2: Architecture of the dual-stack host using BIH at network 230 layer 232 Dual stack hosts defined in RFC2893 [RFC2893] need applications, 233 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed 234 hosts in this document have an API or network layer translator to 235 communicate with IPv6-only peers using existing IPv4 applications. 236 The BIH translator consists of an Extension Name Resolver, an Address 237 Mapper, and depending on implementation either a Function Mapper or a 238 Protocol Translator. 240 2.1. Function Mapper 242 Function mapper translates an IPv4 socket API function into an IPv6 243 socket API function, and vice versa. 245 When detecting IPv4 socket API function calls from IPv4 applications, 246 function mapper intercepts the function calls and invokes IPv6 socket 247 API functions which correspond to the IPv4 socket API functions. The 248 IPv6 API functions are used to communicate with the target IPv6 249 peers. When detecting IPv6 socket API function calls triggered by 250 the data received from the IPv6 peers, function mapper works 251 symmetrically in relation to the previous case. 253 See Appendix B for list of functions that may be intercepted by the 254 function mapper. 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 layer implementation option, when an IPv4 279 application tries to do forward lookup to resolve names via the 280 resolver library (e.g. gethostbyname()), BIH intercept the function 281 call and instead calls the IPv6 equivalent functions (e.g. 282 getnameinfo()) that will resolve both A and AAAA records. 284 In the case of stack layer implementation option the ENR intercepts 285 the A query and creates additional AAAA query with essentially the 286 same content. The ENR will then collect replies to both A and AAAA 287 queries and depending on results either returns A reply unmodified or 288 drops the real A reply and synthesizes a new A reply. 290 In either implementation options, if only non-excluded AAAA records 291 are available for the queried name, ENR requests the address mapper 292 to assign a local IPv4 address corresponding to the IPv6 address(es). 293 In the case of API layer implementation option the ENR will simply 294 make API (e.g. gethostbyname) to return the synthetic address. In 295 the case of network layer implementation option ENR synthesizes an A 296 record for the assigned IPv4 address, and returns the A record to the 297 IPv4 application. 299 If there is real, non-excluded, A record available, ENR SHOULD NOT 300 synthetize IPv4 addresses to be given to the application. By default 301 ENR implementation MUST NOT synthesize IPv4 addresses when real A 302 records exist. 304 If the response contains a CNAME or a DNAME record, then the CNAME or 305 DNAME chains is followed until the first terminating A or AAAA record 306 is reached. 308 Application | Network | ENR behaviour 309 query | response | 310 ------------+----------+------------------------ 311 A | A | 312 A | AAAA | 313 A | A/AAAA | 315 Figure 3: ENR behaviour illustration 317 2.3.1. Special exclusion sets for A and AAAA records 319 ENR implementation MAY by default exclude certain IPv4 and IPv6 320 addresses seen on received A and AAAA records. The addresses to be 321 excluded by default SHOULD include martian addresses such as those 322 that should not appear in the DNS or on the wire. Additional 323 addresses MAY be excluded based on possibly configurable local 324 policies. 326 2.3.2. DNSSEC support 328 The A record synthesis done by ENR in the network layer model can 329 cause problems for DNSSEC validation possibly done by the host's 330 resolver, as the synthetic responses cannot be succesfully validated. 331 DNSSEC can be supported by configuring the (stub) resolver on a host 332 to trust validations done by the local ENR or alternatively the 333 validating resolver can implement ENR on itself and only SIIT takes 334 place at network layer. 336 When ENR is implemented at the socket API level there is no problems 337 with DNSSEC, as the ENR itself uses socket APIs. 339 2.3.3. Reverse DNS lookup 341 When an application initiates a reverse DNS query for a PTR record 342 (in-addr.arpa), to find a name for an IP address, the ENR MUST check 343 whether the queried IP address can be found in the Address Mapper's 344 mapping table and is a local IP address. If an entry is found and 345 the queried address is locally generated, the ENR must initiate 346 corresponding reverse DNS query for the real IPv6 address (ip6.arpa). 347 In the case application requested reverse lookup for an address not 348 part of the local IPv4 address pool, e.g. a global address, the 349 request shall be forwarded unmodified to the network. 351 For example, when an application initiates reverse DNS query for a 352 synthesized locally valid IPv4 address, the ENR needs to intercept 353 that query. The ENR will ask the address mapper for the IPv6 address 354 that corresponds to the IPv4 address. The ENR shall perform reverse 355 lookup procedure for the destination's IPv6 address and return the 356 name received as a response to the application that initiated the 357 IPv4 query. 359 2.4. Address Mapper 361 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 an AAAA record 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 address. A local IPv4 address 375 will be returned to application and mapping for local IPv4 address to 376 real IPv6 address is created. 378 (2) When the extension name resolver gets both an A record and an 379 AAAA record, but the A record contains 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 received IPv6 packet and there is no existing mapping 384 entry for the IPv6 source address (Editor's note: can this ever 385 happen in case of client-server nature of BIH?). 387 Other possible combinations are outside of BIH and BIH is not 388 involved in those. 390 NOTE: There is one exception. When initializing the table the mapper 391 registers a pair of its own IPv4 address and IPv6 address into the 392 table. 394 3. Behavior and network Examples 396 Figure 4 illustrates the very basic network scenario. An IPv4-only 397 application is running on a host attached to IPv6-only Internet and 398 is talking to IPv6-only server. A communication is made possible by 399 Bump-In-the-Host. 401 +----+ +-------------+ 402 | H1 |----------- IPv6 Internet -------- | IPv6 server | 403 +----+ +-------------+ 404 v4 only 405 application 407 Figure 4: Network Scenario #1 409 Figure 5 illustrates a possible network scenario where an IPv4-only 410 application is running on a host attached to a dual-stack network, 411 but the destination server is running on a private site that is 412 numbered with public IPv6 addresses and private IPv4 addresses 413 without port forwarding setup on NAT44. The only means to contact to 414 server is to use IPv6. 416 +----------------------+ +------------------------------+ 417 | Dual Stack Internet | | IPv4 Private site (Net 10) | 418 | | | | 419 | | | +----------+ | 420 | | | | | | 421 | +----+ +---------+ | | | 422 | | H1 |-------- | NAT44 |-------------| Server | | 423 | +----+ +---------+ | | | 424 | v4 only | | +----------+ | 425 | application | | Dual Stack | 426 | | | etc. 10.1.1.1 | 427 | | | AAAA:2009::1 | 428 | | | | 429 +----------------------+ +------------------------------+ 431 Figure 5: Network Scenario #2 433 Illustrations of host behavior in both implementation options are 434 given here. Figure 6 illustrates the setup where BIH is implemented 435 as a bump in the API, and figure 7 illustrates the setup where BIH is 436 implemented as a bump in the stack. 438 "dual stack" "host6" 439 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name 440 appli- API | ENR Address Function| (v6/v4) Server 441 cation | Mapper Mapper | 442 | | | | | | | | 443 <> | | | 444 | | | | | | | | 445 |--------|------->| Query of 'A' records for host6. | | 446 | | | | | | | | 447 | | |--------|--------|---------|--------------|------>| 448 | | | Query of 'A' records and 'AAAA' for host6 | 449 | | | | | | | | 450 | | |<-------|--------|---------|--------------|-------| 451 | | | Reply with the 'AAAA' record. | | 452 | | | | | | | 453 | | |<> | 454 | | | | | | | 455 | | |+++++++>| Request one IPv4 address | 456 | | | | corresponding to the IPv6 address. 457 | | | | | | | 458 | | | |<> | 459 | | | | | | | 460 | | |<+++++++| Reply with the IPv4 address. | 461 | | | | | | | 462 | | |<> 463 | | | | | | | 464 |<-------|--------| Reply with the 'A' record.| | 465 | | | | | | | 466 | | | | | | | 467 <> | | | 468 | | | | | | | 469 |========|========|========|=======>|An IPv4 Socket API function Call 470 | | | | | | | 471 | | | |<+++++++| Request IPv6 addresses| 472 | | | | | corresponding to the | 473 | | | | | IPv4 addresses. | 474 | | | | | | | 475 | | | |+++++++>| Reply with the IPv6 addresses. 476 | | | | | | | 477 | | | | |<> 478 | | | | | | | 479 | An IPv6 Socket API function call.|=========|=============>| 480 | | | | | | | 481 | | | | |<> | 483 | | | | | | | 484 | An IPv6 Socket API function call.|<========|==============| 485 | | | | | | | 486 | | | | |<> 487 | | | | | | | 488 | | | |<+++++++| Request IPv4 addresses| 489 | | | | | corresponding to the | 490 | | | | | IPv6 addresses. | 491 | | | | | | | 492 | | | |+++++++>| Reply with the IPv4 addresses. 493 | | | | | | | 494 |<=======|========|========|========| An IPv4 Socket function call. 495 | | | | | | | 497 Figure 6: Example of BIH as API addition 499 "dual stack" "host6" 500 IPv4 TCP/ ENR address translator IPv6 501 appli- IPv4 mapper 502 cation 503 | | | | | | | 504 <> | | 505 | | | | | | | 506 |------|------>| Query of 'A' records for "host6". | Name 507 | | | | | | | Server 508 | | |---------|-------|-----------|---------|--->| 509 | | | Query of 'A' records and 'AAAA' for "host6" 510 | | | | | | | | 511 | | |<--------|-------|-----------|---------|----| 512 | | | Reply only with 'AAAA' record. | 513 | | | | | | | 514 | | |<> | 515 | | | | | | | 516 | | |-------->| Request one IPv4 address | 517 | | | | corresponding to the IPv6 address. 518 | | | | | | | 519 | | | |<> | 520 | | | | | | | 521 | | |<--------| Reply with the IPv4 address. 522 | | | | | | | 523 | | |<> 524 | | | | | | | 525 |<-----|-------| Reply with the 'A' record. | | 526 | | | | | | | 527 | | | | | | | 528 <>| | | 529 | | | | | | | 530 |======|=======|=========|======>| An IPv4 packet. | 531 | | | | | | | 532 | | | |<------| Request IPv6 addresses 533 | | | | | corresponding to the IPv4 534 | | | | | addresses. | 535 | | | | | | | 536 | | | |------>| Reply with the IPv6| 537 | | | | | addresses. | 538 | | | | | | | 539 | | | | |<> 540 | | | | | | | 541 | | |An IPv6 packet. |===========|========>| 542 | | | | | | | 543 | | | | <> | 545 | | | | | | | 546 | | |An IPv6 packet. |<==========|=========| 547 | | | | | | | 548 | | | | |<> 549 | | | | | | | 550 |<=====|=======|=========|=======| An IPv4 packet. | 551 | | | | | | | 553 Figure 7: Example of BIH at network layer 555 4. Considerations 557 4.1. Socket API Conversion 559 IPv4 socket API functions are translated into semantically as same 560 IPv6 socket API functions as possible and vice versa. See Appendix B 561 for the API list intercepted by BIH. However, IPv4 socket API 562 functions are not fully compatible with IPv6 since the IPv6 has new 563 advanced features, but IPv4-only application are unlikely to need 564 them. 566 4.2. ICMP Message Handling 568 When an application needs ICMP messages values (e.g., Type, Code, 569 etc.) sent from a network layer, ICMPv4 message values MAY be 570 translated into ICMPv6 message values based on SIIT 571 [I-D.ietf-behave-v6v4-xlate], and vice versa. 573 4.3. IPv4 Address Pool and Mapping Table 575 The address pool consists of the private IPv4 addresses as per 576 [RFC1918]. This pool can be implemented at different granularity in 577 the node e.g., a single pool per node, or at some finer granularity 578 such as per user or per process. In he case of large number of IPv4 579 applications would communicate with large number of IPv6 servers, the 580 available address spaces may be exhausted. This should be quite rare 581 event and changes will decrease as IPv6 support increases. The 582 possible problem can also mitigated with smart management techniques 583 of the address pool. For example, entries with longest inactivity 584 time can be cleared and IPv4 addresess reused for creating new 585 entries. 587 The RFC1918 address space was chosen because generally legacy 588 applications understand that as a private address space. A new 589 dedicated address space would run a risk of not being understood by 590 applications as private. 127/8 or 169.254/16 are rejected due 591 possible assumptions applications may make when seeing those. 593 The RFC1918 addresses have a risk of conflicting with other 594 interfaces. The conflicts can be mitigated by using least commonly 595 used network number of the RFC1918 address space. Addresses from 596 172.16/12 prefix are thought to be less likely to conflict than 597 addresses from 10/8 or 192.168/16 spaces, hence the used IPv4 598 addresses are following (Editor's comment: this is first proposal, 599 educated better quesses are welcome): 601 Source addresses: 172.21.112.0/30. Source address have to be 602 allocated because applications use getsockname() calls and as in the 603 BIS mode an IP address of the IPv4 interface has to be shown (e.g. by 604 'ifconfig'). More than one address is allocated to allow 605 implementation flexibility, e.g. for cases where a host has multiple 606 IPv6 interfaces. The source addresses are from different subnet than 607 destination addresses to ensure applications would not do on-link 608 assumptions and would enable NAT traversal functions. 610 Primary destination addresses: 172.21.80.0/20. Address mapper will 611 select destination addresses primarily out of this pool. 613 Secondary destination addresses: 10.170.160.0/20. Address mapper 614 will select destination addresses out of this pool if the node has 615 dual-stack connection conflicting with primary destination addresses. 617 4.4. Multi-interface 619 In the case of dual-stack destinations BIH must do protocol 620 translation from IPv4 to IPv6 only when the host does not have any 621 IPv4 interfaces, native or tunneled, available for use. 623 It is possible that an IPv4 interface is activated during BIH 624 operation, for example if a node moves to a coverage area of IPv4 625 enabled network. In such an event BIH MUST stop initiating protocol 626 translation sessions for new connections and BIH MAY disconnect 627 active sessions. The choice of disconnection is left for 628 implementatations and it may depend on whether IPv4 address conflict 629 situation occurs between addresses used by BIH and addresses used by 630 new IPv4 interface. 632 4.5. Multicast 634 Protocol translation for multicast is not supported. 636 4.6. DNS cache 638 When BIH module shuts down, e.g. due IPv4 interface becoming 639 available, BIH must flush node's DNS cache of possible locally 640 generated entries. 642 5. Considerations due ALG requirements 644 No ALG functionality is specified herein as ALG design is generally 645 not encouraged for host based translation and as BIH is intended for 646 applications not including IP addresses in protocol payloads. 648 6. Security Considerations 650 The security consideration of BIH mostly relies on that of 651 [I-D.ietf-behave-v6v4-xlate-stateful]. 653 In the socket layer implementation approach the differences are due 654 to the address translation occurring at the API and not in the 655 network layer. That is, since the mechanism uses the API translator 656 at the socket API layer, hosts can utilize the security of the 657 network layer (e.g., IPSec) when they communicate with IPv6 hosts 658 using IPv4 applications via the mechanism. As well, there is no need 659 for DNS ALG as in NAT-PT, so there is no interference with DNSSEC 660 either. 662 In the network layer implementation approach hosts cannot utilize the 663 security above network layer when they communicate with IPv6 hosts 664 using IPv4 applications via BIH and encrypt embedded IP addresses, or 665 when the protocol data is encrypted using IP addresses as keys. In 666 these cases it is impossible for the mechanism to translate the IPv4 667 data into IPv6 and vice versa. Therefore it is highly desirable to 668 upgrade to the applications modified into IPv6 for utilizing the 669 security at communication with IPv6 hosts. 671 The use of address pooling may open a denial of service attack 672 vulnerability. So BIH should employ the same sort of protection 673 techniques as NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] does. 675 7. Acknowledgments 677 The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou, 678 Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of 679 this document. 681 The efforts of Suresh Krishnan, Mohamed Boucadair, Yiu L. Lee, James 682 Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng, 683 Christian Vogt, Jan M. Melen, Ed Jankiewizh, Marnix Goossens, Ala 684 Hamarsheh, and Julien Laganier in reviewing this document are 685 gratefully acknowledged. 687 Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly 688 appreciated 690 The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, 691 Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. 692 The authors of RFC3338 acknowledged implementation contributions by 693 Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation 694 (www.i2soft.net). 696 The authors of Bump-in-the-Wire (draft-ietf-biw-00.txt, October 697 2006), P. Moster, L. Chin, and D. Green, are acknowledged. Few ideas 698 and clarifications from BIW have been adapted to this document. 700 8. References 702 8.1. Normative References 704 [I-D.ietf-behave-v6v4-xlate] 705 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 706 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 707 progress), September 2010. 709 [I-D.ietf-behave-v6v4-xlate-stateful] 710 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 711 NAT64: Network Address and Protocol Translation from IPv6 712 Clients to IPv4 Servers", 713 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 714 progress), July 2010. 716 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 717 E. Lear, "Address Allocation for Private Internets", 718 BCP 5, RFC 1918, February 1996. 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 724 (IPv6) Specification", RFC 2460, December 1998. 726 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 727 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 728 RFC 2767, February 2000. 730 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 731 IPv6 Hosts and Routers", RFC 2893, August 2000. 733 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 734 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 735 RFC 3338, October 2002. 737 8.2. Informative References 739 [RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, 740 "Basic Socket Interface Extensions for IPv6", RFC 2553, 741 March 1999. 743 Appendix A. Implementation option for the ENR 745 It is not necessary to implement the ENR at the kernel level, but it 746 can be implemented instead at the user space by setting the host's 747 default DNS server to point to 127.0.0.1. DNS queries would then 748 always be sent to the ENR, which furthermore ensures both A and AAAA 749 queries are sent to the actual DNS server and A queries are always 750 answered and required mappings created. 752 Appendix B. API list intercepted by BIH 754 The following functions are the API list which SHOULD be intercepted 755 by BIH module when implemented at socket layer. 757 The functions that the application uses to pass addresses into the 758 system are: 760 bind() 762 connect() 764 sendmsg() 766 sendto() 768 The functions that return an address from the system to an 769 application are: 771 accept() 773 recvfrom() 775 recvmsg() 777 getpeername() 779 getsockname() 781 The functions that are related to socket options are: 783 getsocketopt() 785 setsocketopt() 787 The functions that are used for conversion of IP addresses embedded 788 in application layer protocol (e.g., FTP, DNS, etc.) are: 790 recv() 792 send() 794 read() 796 write() 798 As well, raw sockets for IPv4 and IPv6 MAY be intercepted. 800 Most of the socket functions require a pointer to the socket address 801 structure as an argument. Each IPv4 argument is mapped into 802 corresponding an IPv6 argument, and vice versa. 804 According to [RFC2553], the following new IPv6 basic APIs and 805 structures are required. 807 IPv4 new IPv6 808 ------------------------------------------------ 809 AF_INET AF_INET6 810 sockaddr_in sockaddr_in6 811 gethostbyname() getaddrinfo() 812 gethostbyaddr() getnameinfo() 813 inet_ntoa()/inet_addr() inet_pton()/inet_ntop() 814 INADDR_ANY in6addr_any 816 Figure 8 818 BIH MAY intercept inet_ntoa() and inet_addr() and use the address 819 mapper for those. Doing that enables BIH to support literal IP 820 addresses. 822 The gethostbyname() call return a list of addresses. When the name 823 resolver function invokes getaddrinfo() and getaddrinfo() returns 824 multiple IP addresses, whether IPv4 or IPv6, they SHOULD all be 825 represented in the addresses returned by gethostbyname(). Thus if 826 getaddrinfo() returns multiple IPv6 addresses, this implies that 827 multiple address mappings will be created; one for each IPv6 address. 829 Authors' Addresses 831 Bill Huang 832 China Mobile 833 53A,Xibianmennei Ave., 834 Xuanwu District, 835 Beijing 100053 836 China 838 Email: bill.huang@chinamobile.com 840 Hui Deng 841 China Mobile 842 53A,Xibianmennei Ave., 843 Xuanwu District, 844 Beijing 100053 845 China 847 Email: denghui02@gmail.com 849 Teemu Savolainen 850 Nokia 851 Hermiankatu 12 D 852 FI-33720 TAMPERE 853 Finland 855 Email: teemu.savolainen@nokia.com