idnits 2.17.1 draft-huang-behave-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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 520 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 (July 28, 2010) is 5021 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 301, but not defined == Missing Reference: 'SIIT' is mentioned on line 596, but not defined == Missing Reference: 'BIS' is mentioned on line 611, but not defined == Missing Reference: 'NAT-PT' is mentioned on line 671, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** 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: 8 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave 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: January 29, 2011 July 28, 2010 9 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) 10 draft-huang-behave-bih-01 12 Abstract 14 This document describes the "Bump-In-the-Host" (BIH), a host based 15 protocol translation mechanism that allows a subset of applications 16 supporting only one IP address family to communicate with peers that 17 are reachable or supporting only the other address family. 19 This specification addresses scenarios where a host is provided dual 20 stack or IPv6 only network connectivity. In the dual stack network 21 case, single address family applications in the host sometime will 22 communicate directly with other hosts using the different address 23 family. In the case of IPv6 only network or IPv6 only destination, 24 IPv4 originated communications have to be translated into IPv6. The 25 BIH makes the IPv4 applications think they talk to IPv4 peers and 26 hence hides the IPv6 from those applications. 28 Acknowledgement of previous work 30 This document is an update to and directly derivative from Kazuaki 31 TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI [RFC2767] and 32 from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and 33 Erik Nordmark's [RFC3338], which similarly provides a dual stack host 34 means to communicate with other IPv6 host using existing IPv4 35 appliations. This document combines and updates both [RFC2767] and 36 [RFC3338]. 38 The changes in this document reflect five components 40 1. Supporting IPv6 only network connections 42 2. IPv4 address pool use private address instead of the 43 unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255) 45 3. Extending ENR and address mapper to operate differently 47 4. Adding an alternative way to implement the ENR 48 5. Going for standards track instead of experimental/ 49 informational 51 Status of this Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on January 29, 2011. 68 Copyright Notice 70 Copyright (c) 2010 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 This document may contain material from IETF Documents or IETF 84 Contributions published or made publicly available before November 85 10, 2008. The person(s) controlling the copyright in some of this 86 material may not have granted the IETF Trust the right to allow 87 modifications of such material outside the IETF Standards Process. 88 Without obtaining an adequate license from the person(s) controlling 89 the copyright in such materials, this document may not be modified 90 outside the IETF Standards Process, and derivative works of it may 91 not be created outside the IETF Standards Process, except to format 92 it for publication as an RFC or to translate it into languages other 93 than English. 95 Table of Contents 97 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 98 2. Components of the Bump-in-the-Host . . . . . . . . . . . . . . 6 99 2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 7 100 2.2. Translator . . . . . . . . . . . . . . . . . . . . . . . . 8 101 2.3. Extension Name Resolver . . . . . . . . . . . . . . . . . 8 102 2.3.1. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9 103 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 9 104 3. Behavior and network Examples . . . . . . . . . . . . . . . . 12 105 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16 106 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 16 107 4.2. ICMP Message Handling . . . . . . . . . . . . . . . . . . 16 108 4.3. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 16 109 4.4. Internally Assigned IPv4 Addresses . . . . . . . . . . . . 17 110 5. Considerations due ALG requirements . . . . . . . . . . . . . 18 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 112 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 113 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 114 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 115 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 116 Appendix A. Implementation option for the ENR . . . . . . . . . . 22 117 Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 23 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 120 1. Introduction 122 While IPv6 support is being widely introduced throughout the 123 Internet, a class of applications are going to remain IPv4-only. 124 This document describes a Bump-in-the-Host (BIH), successor and 125 combination of Bump-in-the-Stack (BIS) [RFC2767] and Bump-in-the-API 126 (BIA) [RFC3338] technologies, which enables accommodation of 127 significant set of the legacy IPv4-only applications in the IPv6- 128 world. 130 Bump-In-the-Host is not a general purpose translation solution. The 131 class of IPv4-only applications the described host-based NAT46 132 protocol translation solution provides Internet connectivity over 133 IPv6-only network access includes those applications that use DNS for 134 IP address resolution and that do not embed IP address literals in 135 protocol payloads. This includes essentially all DNS using legacy 136 client-server model applications, which are agnostic on IP address 137 family used by the destination, but not other classes of 138 applications. The transition towards IPv6-only Internet is made 139 easier by decreasing number of key applications that must be updated 140 to IPv6. 142 BIH technique includes two major implementation options: inserts a 143 protocol translator between the IPv4 and the IPv6 stacks of a host or 144 between the socket API module and the TCP/IP module. Essentially, 145 IPv4 is translated into IPv6 at the socket API level or at the IP 146 level. 148 When the BIH is implemented at the socket API layer, and IPv4 149 applications communicate with IPv6 peers, the API translator 150 intercepts the socket API functions from IPv4 applications and 151 invokes the IPv6 socket API functions to communicate with the IPv6 152 hosts, and vice versa. 154 When the BIH is implemented at the networking layer, the IPv4 packets 155 are intercepted and converted to IPv6 using the IP conversion 156 mechanism defined in SIIT [RFC2765]. The translation has the same 157 benefits and drawbacks as SIIT. 159 In order to support communication between IPv4 applications and the 160 target IPv6 hosts, pooled IPv4 addresses will be assigned through the 161 extension name resolver. 163 The BIH can be used whenever an IPv4-only application needs to 164 communicate with an IPv6 peer, independently of the address families 165 supported by the access network. Hence the access network can be 166 IPv6-only or dual-stack capable. 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119] . 172 This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767] 173 and [RFC3338]. 175 2. Components of the Bump-in-the-Host 177 Figure 1 shows the architecture of the host in which BIH is 178 implemented as socket API layer traslator, i.e. as the original 179 "Bump-in-the-API". 181 +----------------------------------------------+ 182 | +------------------------------------------+ | 183 | | | | 184 | | IPv4 applications | | 185 | | | | 186 | +------------------------------------------+ | 187 | +------------------------------------------+ | 188 | | Socket API (IPv4, IPv6) | | 189 | +------------------------------------------+ | 190 | +-[ API translator]------------------------+ | 191 | | +-----------+ +---------+ +------------+ | | 192 | | | Ext. Name | | Address | | Function | | | 193 | | | Resolver | | Mapper | | Mapper | | | 194 | | +-----------+ +---------+ +------------+ | | 195 | +------------------------------------------+ | 196 | +--------------------+ +-------------------+ | 197 | | | | | | 198 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 199 | | | | | | 200 | +--------------------+ +-------------------+ | 201 +----------------------------------------------+ 203 Figure 1: Architecture of the dual stack host using BIH at socket 204 layer 206 Figure 2 shows the architecture of the host in which BIH is 207 implemented as network layer translator, i.e. as the original "Bump- 208 in-the-Stack". 210 +-------------------------------------------------------------+ 211 | +-------------------------------------------------------+ | 212 | | IPv4 applications | | 213 | +-------------------------------------------------------+ | 214 | +-------------------------------------------------------+ | 215 | | TCP/IPv4 | | 216 | | +---------------------------------------------------+ | 217 | | | +-----------+ +---------+ +---------------+ | 218 | | | | extension | | address | | translator | | 219 | | | | name | | mapper | +---------------+ | 220 | | | | resolver | | | +---------------+ | 221 | | | | | | | | IPv6 | | 222 | +---+ +-----------+ +---------+ +---------------+ | 223 | +-------------------------------------------------------+ | 224 | | Network card drivers | | 225 | +-------------------------------------------------------+ | 226 +-------------------------------------------------------------+ 227 +-------------------------------------------------------------+ 228 | Network cards | 229 +-------------------------------------------------------------+ 231 Figure 2: Architecture of the dual-stack host using BIH at network 232 layer 234 Dual stack hosts defined in RFC2893 [RFC2893] need applications, 235 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed 236 hosts in this document have an API or network layer translator to 237 communicate with other IPv6 hosts using existing IPv4 applications. 238 The BIH translator consists of an entension name resolver, an address 239 mapper, and depending on implementation either a function mapper or 240 an protocol translator. 242 2.1. Function Mapper 244 Function mapper translates an IPv4 socket API function into an IPv6 245 socket API function, and vice versa. 247 When detecting the IPv4 socket API functions from IPv4 applications, 248 it intercepts the function call and invokes new IPv6 socket API 249 functions which correspond to the IPv4 socket API functions. Those 250 IPv6 API functions are used to communicate with the target IPv6 251 hosts. When detecting the IPv6 socket API functions from the data 252 received from the IPv6 hosts, it works symmetrically in relation to 253 the previous case. 255 2.2. Translator 257 Translator translates IPv4 into IPv6 and vice versa using the IP 258 conversion mechanism defined in SIIT [RFC2765]. 260 When receiving IPv4 packets from IPv4 applications, translator 261 converts IPv4 packet headers into IPv6 packet headers, then, if 262 required, fragments the IPv6 packets (because header length of IPv6 263 is typically 20 bytes larger than that of IPv4), and sends them to 264 IPv6 networks. When receiving IPv6 packets from the IPv6 networks, 265 translator works symmetrically to the previous case, except that 266 there is no need to fragment the packets. 268 2.3. Extension Name Resolver 270 Extension Name Resolver returns a proper answer in response to the 271 IPv4 or IPv6 application's request. 273 In the case of socket API implementation option, when an IPv4 274 application in an IPv6 only network tries to do forward lookup to 275 resolve names via the resolver library (e.g. gethostbyname()), BIH 276 intercept the function call and instead calls the IPv6 equivalent 277 functions (e.g. getnameinfo()) that will resolve both A and AAAA 278 records. 280 If only AAAA record is available for the name queried, ENR requests 281 the address mapper to assign an IPv4 address corresponding to the 282 IPv6 address, creates an A record for the assigned IPv4 address, and 283 returns the A record to the IPv4 application. 285 If both A and AAAA record are available in the IPv6 only network, ENR 286 does not require address mapper to assign IPv4 address, but instead 287 asks address mapper to store relationship between the A and AAAA 288 records, and then directly passes the received A record to the IPv4 289 application. 291 Application | Network | ENR behaviour 292 query | response | 293 ------------+----------+--------------------- 294 A | A | 295 A | AAAA | 296 A | A/AAAA | 298 Figure 3: ENR behaviour illustration 300 NOTE: An implementation option is to have ENR support in host's 301 (stub) DNS resolver itself as described in [DNS64], in which case 302 record synthesis is not needed and advanced functions such as DNSSEC 303 are possible. If the ENR is implemented in network layer, same 304 limitations arise as when DNS record synthesis is done on network. A 305 host also has option to implement recursive DNS server by itself. 307 2.3.1. Reverse DNS lookup 309 When an application initiates a reverse DNS query for a PTR record, 310 to find a name for an IP address, the ENR MUST check whether the 311 queried IP address can be found in the cache of the Address Mapper 312 and is a local IP address. If an entry is found and queried address 313 is locally generated, the ENR must initiate corresponding reverse DNS 314 query for the real IP address. 316 For example, when application initiates reverse DNS query for a 317 synthesized locally valid IPv4 address, the ENR needs to intercept 318 that query query. The ENR shall do reverse query for the 319 destination's IPv6 address and return the name received as response 320 to IPv6 reverse query to application that initiated the IPv4 query. 322 2.4. Address Mapper 324 Address mapper ("the mapper" later on ), maintains an IPv4 address 325 pool in the case of dual stack network and IPv6 only network. The 326 pool consists of private IPv4 addresses as per [RFC1918]. Also, 327 mapper maintains a table consisting of pairs of these locally 328 selected IPv4 addresses and a destinations's IPv6 addresses. 330 When the extension name resolver, translator, or the function mapper 331 requests mapper to assign an IPv4 address corresponding to an IPv6 332 address, mapper selects and returns an IPv4 address out of the pool, 333 and registers a new entry into the table dynamically. The 334 registration occurs in the following 3 cases: 336 (1) When the extension name resolver gets only an 'AAAA' record for 337 the target host name in the dual stack or IPv6 only network and there 338 is not a mapping entry for the IPv6 address. 340 (2) When the extension name resolver gets both an 'A' record and an 341 'AAAA' record for the target host name in the IPv6 only network and 342 there is not a mapping entry for the IPv6 address. But it doesn't 343 need an IPv4 address out of the pool, just registers both IPv4 and 344 IPv6 address from 'A' and 'AAAA' records into a new entry into the 345 table. 347 (3) When the function mapper gets a socket API function call from the 348 data received and there is not a mapping entry for the IPv6 source 349 address. 351 When the resolver, translator, or the function mapper requests mapper 352 to assign an IPv4 address corresponding to an IPv6 address, mapper, 353 if required, selects and returns an IPv4 address out of the pool, and 354 registers a new entry into the table dynamically. The following 355 table describes how mappings are created into the table in each 356 possible scenario: 358 Mapping table | Access | Peer | Created 359 entry for |link type | support| address mapping 360 -------------------+-------------+------------------------------- 361 (1) real IPv4 |IPv4 or DS | v4 | < no mapping needed > 362 (2) real IPv6 |IPv6 or DS | v6 | < no mapping needed > 363 (3) real IPv4 |IPv6 | v4 & v6| real IPv4 -> real IPv6 364 (4) real IPv6 |IPv4 | v4 & v6| real IPv6 -> real IPv4 365 (5) local IPv4 |IPv6 or DS | v6 | local IPv4 -> real IPv6 366 (6) local IPv6 |IPv4 or DS | v4 | local IPv6 -> real IPv4 367 (7) real IPv4 |IPv6 | v4 | out of scope 368 (8) real IPv6 |IPv4 | v6 | out of scope 370 Figure 4: Address Mapper's mapping table illustration 372 Below are examples for all eight scenarios: 374 (1) When the resolver gets an 'A' reply for application's 'A' query 375 on access network supporting IPv4, there is no need to create mapping 376 (or just stub mapping real IPv4 -> real IPv4). 378 (2) When the resolver gets an 'AAAA' reply for application's 'AAAA' 379 query on access network supporting IPv6, there is no need to create 380 mapping (or just stub mapping real IPv6 -> real IPv6). 382 (3) When the resolver gets both 'A' and 'AAAA' replies for 383 application's 'A' query on IPv6-only access, there shall be mapping 384 for real IPv4 to real IPv6. 386 (4) When the resolver gets both 'A' and 'AAAA' replies for 387 application's 'AAAA' query on IPv4-only access, there shall be 388 mapping for real IPv6 to real IPv4. 390 (5) When the resolver gets only an 'AAAA' record for the target host 391 name for application's 'A' request on IPv6 only or DS access network, 392 a local IPv4 address will be given to application and mapping for 393 local IPv4 address to real IPv6 address is created. 395 (6) When the resolver gets only an 'A' record for the target host 396 name for application's 'AAAA' request on IPv4 only or DS access 397 network, a local IPv6 address will be given to application and 398 mapping for local IPv6 address to real IPv4 address is created. 400 (7) When the resolver gets only an 'A' record for the target host 401 name for application's 'A' request on IPv6 only access network, a 402 double translation would be required and thus is out of the scope of 403 this document. 405 (8) When the resolver gets only an 'AAAA' record for the target host 406 name for application's 'AAAA' request on IPv4 only access network, a 407 double translation would be required and thus is out of the scope of 408 this document. 410 NOTE: There is only one exception. When initializing the table, 411 mapper registers a pair of its own IPv4 address and IPv6 address into 412 the table statically. 414 3. Behavior and network Examples 416 Figure 5 illustrates the very basic network scenario. An IPv4-only 417 application is running on a host attached to IPv6-only Internet and 418 is talking to IPv6 enabled server. A communication is made possible 419 by bump in the host. 421 +----+ +-------------+ 422 | H1 |----------- IPv6 Internet -------- | IPv6 server | 423 +----+ +-------------+ 424 v4 only 425 application 427 Figure 5: Network Scenario #1 429 Figure 6 illustrates a possible network scenario where an IPv4-only 430 application is running on a host attached to a dual-stack network, 431 but the destination server is running on a private site that is 432 numbered with public IPv6 addresses and private IPv4 addresses 433 without port forwarding setup on NAT44. The only means to contact to 434 server is to use IPv6. 436 +----------------------+ +------------------------------+ 437 | Dual Stack Internet | | IPv4 Private site (Net 10) | 438 | | | | 439 | | | +----------+ | 440 | | | | | | 441 | +----+ +---------+ | | | 442 | | H1 |-------- | NAT44 |-------------| Server | | 443 | +----+ +---------+ | | | 444 | v4 only | | +----------+ | 445 | application | | Dual Stack | 446 | | | etc. 10.1.1.1 | 447 | | | AAAA:2009::1 | 448 | | | | 449 +----------------------+ +------------------------------+ 451 Figure 6: Network Scenario #2 453 Illustrations of host behavior in both implementation options are 454 given here. Figure 7 illustrates the setup where BIH is implemented 455 as a bump in the API, and figure 8 illustrates the setup where BIH is 456 implemented as a bump in the stack. 458 "dual stack" "host6" 459 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name 460 appli- API | ENR Address Function| (v6/v4) Server 461 cation | Mapper Mapper | 462 | | | | | | | | 463 <> | | | 464 | | | | | | | | 465 |--------|------->| Query of 'A' records for host6. | | 466 | | | | | | | | 467 | | |--------|--------|---------|--------------|------>| 468 | | | Query of 'A' records and 'AAAA' for host6 | 469 | | | | | | | | 470 | | |<-------|--------|---------|--------------|-------| 471 | | | Reply with the 'AAAA' record. | | 472 | | | | | | | 473 | | |<> | 474 | | | | | | | 475 | | |+++++++>| Request one IPv4 address | 476 | | | | corresponding to the IPv6 address. 477 | | | | | | | 478 | | | |<> | 479 | | | | | | | 480 | | |<+++++++| Reply with the IPv4 address. | 481 | | | | | | | 482 | | |<> 483 | | | | | | | 484 |<-------|--------| Reply with the 'A' record.| | 485 | | | | | | | 486 | | | | | | | 487 <> | | | 488 | | | | | | | 489 |========|========|========|=======>|An IPv4 Socket API function Call 490 | | | | | | | 491 | | | |<+++++++| Request IPv6 addresses| 492 | | | | | corresponding to the | 493 | | | | | IPv4 addresses. | 494 | | | | | | | 495 | | | |+++++++>| Reply with the IPv6 addresses. 496 | | | | | | | 497 | | | | |<> 498 | | | | | | | 499 | An IPv6 Socket API function call.|=========|=============>| 500 | | | | | | | 501 | | | | |<> | 503 | | | | | | | 504 | An IPv6 Socket API function call.|<========|==============| 505 | | | | | | | 506 | | | | |<> 507 | | | | | | | 508 | | | |<+++++++| Request IPv4 addresses| 509 | | | | | corresponding to the | 510 | | | | | IPv6 addresses. | 511 | | | | | | | 512 | | | |+++++++>| Reply with the IPv4 addresses. 513 | | | | | | | 514 |<=======|========|========|========| An IPv4 Socket function call. 515 | | | | | | | 517 Figure 7: Example of BIH as API addition 519 "dual stack" "host6" 520 IPv4 TCP/ ENR address translator IPv6 521 appli- IPv4 mapper 522 cation 523 | | | | | | | 524 <> | | 525 | | | | | | | 526 |------|------>| Query of 'A' records for "host6". | Name 527 | | | | | | | Server 528 | | |---------|-------|-----------|---------|--->| 529 | | | Query of 'A' records and 'AAAA' for "host6" 530 | | | | | | | | 531 | | |<--------|-------|-----------|---------|----| 532 | | | Reply only with 'AAAA' record. | 533 | | | | | | | 534 | | |<> | 535 | | | | | | | 536 | | |-------->| Request one IPv4 address | 537 | | | | corresponding to the IPv6 address. 538 | | | | | | | 539 | | | |<> | 540 | | | | | | | 541 | | |<--------| Reply with the IPv4 address. 542 | | | | | | | 543 | | |<> 544 | | | | | | | 545 |<-----|-------| Reply with the 'A' record. | | 546 | | | | | | | 547 | | | | | | | 548 <>| | | 549 | | | | | | | 550 |======|=======|=========|======>| An IPv4 packet. | 551 | | | | | | | 552 | | | |<------| Request IPv6 addresses 553 | | | | | corresponding to the IPv4 554 | | | | | addresses. | 555 | | | | | | | 556 | | | |------>| Reply with the IPv6| 557 | | | | | addresses. | 558 | | | | | | | 559 | | | | |<> 560 | | | | | | | 561 | | |An IPv6 packet. |===========|========>| 562 | | | | | | | 563 | | | | <> | 565 | | | | | | | 566 | | |An IPv6 packet. |<==========|=========| 567 | | | | | | | 568 | | | | |<> 569 | | | | | | | 570 |<=====|=======|=========|=======| An IPv4 packet. | 571 | | | | | | | 573 Figure 8: Example of BIH at network layer 575 4. Considerations 577 Other considerations in [RFC3338] are still the same, here only 578 clarify the section of IPv4 Address Pool and Mapping Table and 579 Internally Assigned IPv4 or IPv6 Addresses to support private IPv4 580 address. 582 4.1. Socket API Conversion 584 IPv4 socket API functions are translated into semantically the same 585 IPv6 socket API functions and vice versa. IP addresses embedded in 586 application layer protocols (e.g., FTP) can be translated in API 587 functions. Its implementation depends on operating systems. 589 NOTE: Basically, IPv4 socket API functions are not fully compatible 590 with IPv6 since the IPv6 has new advanced features. 592 4.2. ICMP Message Handling 594 When an application needs ICMP messages values (e.g., Type, Code, 595 etc.) sent from a network layer, ICMPv4 message values MAY be 596 translated into ICMPv6 message values based on [SIIT], and vice 597 versa. It can be implemented using raw socket. 599 4.3. IPv4 Address Pool and Mapping Table 601 The address pool consists of the private IPv4 addresses as per 602 [RFC1918]. This pool can be implemented at different granularity in 603 the node e.g., a single pool per node, or at some finer granularity 604 such as per user or per process. However, if a number of IPv4 605 applications communicate with IPv6 hosts or IPv6 applications 606 communicate with IPv4 hosts, the available address spaces will be 607 exhausted. As a result, it will be impossible for IPv4 applications 608 to communicate with IPv6 nodes. It requires smart management 609 techniques for address pool. For example, it is desirable for the 610 mapper to free the oldest entry and reuse the IPv4 address or IPv6 611 address for creating a new entry. This issues is the same as [BIS]. 612 In case of a per-node address mapping table, it MAY cause a larger 613 risk of running out of address. 615 The RFC1918 address space was chosen because generally legacy 616 applications understand that as a private address space. A new 617 dedicated address space would run a risk of not being understood by 618 applications as private. The RFC1918 addresses have a risk of 619 conflicting with other interfaces. The conflicts can be mitigated by 620 using least commonly used network number of the RFC1918 address space 621 (TO BE SELECTED) and, if possible, cease using BIH on IPv6-interface 622 after an IPv4-enabled interface is activated. 624 4.4. Internally Assigned IPv4 Addresses 626 The IPv4 addresses, which are internally assigned to IPv6 target 627 hosts out of the pool, are the private IPv4 addresses. IPv4 628 addresses, which are internally assigned to IPv6 target hosts out of 629 the spool, never flow out from the host, and so do not negatively 630 affect other hosts. 632 The internally assigned IPv4 address, which applications see as the 633 source address, MUST be from different subnet than the IPv4 addresses 634 used by the address synthesis function. This approach ensures legacy 635 applications realize they are not on the same link with their 636 destination node and if needed, will trigger NAT traversal procedures 637 such as keepalive message sending. 639 5. Considerations due ALG requirements 641 Support for IP-embedding applications, such as FTP and RTSP, requires 642 implementation of Application Layer Gateway functions. No ALG 643 functionality is specified herein as ALG design is generally not 644 encouraged for host based translation and as BIH is intented for 645 applications not including IP addresses in protocol payload. 647 6. Security Considerations 649 The security consideration of BIH mostly relies on that of [RFC2766]. 651 In the socket layer implementation approach the differences are due 652 to the address translation occurring at the API and not in the 653 network layer. That is, since the mechanism uses the API translator 654 at the socket API level, hosts can utilize the security of the 655 network layer (e.g., IPsec) when they communicate with IPv6 hosts 656 using IPv4 applications via the mechanism. As well, there is no need 657 for DNS ALG as in NAT-PT, so there is no interference with DNSSEC 658 either. 660 In the network layer implementation approach hosts can not utilize 661 the security above network layer when they communicate with IPv6 662 hosts using IPv4 applications via BIH and encrypt embedded IP 663 addresses, or when the protocol data is encrypted using IP addresses 664 as keys. In these cases it is impossible for the mechanism to 665 translate the IPv4 data into IPv6 and vice versa. Therefore it is 666 highly desirable to upgrade to the applications modified into IPv6 667 for utilizing the security at communication with IPv6 hosts. 669 The use of address pooling may open a denial of service attack 670 vulnerability. So BIH should employ the same sort of protection tec 671 hniques as [NAT-PT] does. 673 7. Acknowledgments 675 The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou, 676 Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of 677 this document. 679 The efforts of Suresh Krishnan, Mohamed Boucadair, Yiu L. Lee, James 680 Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng, 681 Christian Vogt, Jan M. Melen, in reviewing this document are 682 gratefully acknowledged. 684 Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly 685 appreciated 687 The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, 688 Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. 689 The authors of RFC3338 acknowledged implementation contributions by 690 Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation 691 (www.i2soft.net). 693 8. References 695 8.1. Normative References 697 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 698 E. Lear, "Address Allocation for Private Internets", 699 BCP 5, RFC 1918, February 1996. 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, March 1997. 704 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 705 (IPv6) Specification", RFC 2460, December 1998. 707 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 708 (SIIT)", RFC 2765, February 2000. 710 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 711 Translation - Protocol Translation (NAT-PT)", RFC 2766, 712 February 2000. 714 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 715 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 716 RFC 2767, February 2000. 718 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 719 IPv6 Hosts and Routers", RFC 2893, August 2000. 721 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 722 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 723 RFC 3338, October 2002. 725 8.2. Informative References 727 [RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, 728 "Basic Socket Interface Extensions for IPv6", RFC 2553, 729 March 1999. 731 Appendix A. Implementation option for the ENR 733 It is not necessary to implement the ENR at the kernel level, but it 734 can be implemented instead at the user space by setting the default 735 DNS server to point to 127.0.0.1. DNS queries would then always be 736 sent to the ENR, which furthermore ensures both A and AAAA queries 737 are sent to the actual DNS server and A queries are always answered 738 and required mappings created. 740 Appendix B. API list intercepted by BIH 742 The following functions are the API list which SHOULD be intercepted 743 by BIH module when implemented at socket layer. 745 The functions that the application uses to pass addresses into the 746 system are: 748 bind() 750 connect() 752 sendmsg() 754 sendto() 756 The functions that return an address from the system to an 757 application are: 759 accept() 761 recvfrom() 763 recvmsg() 765 getpeername() 767 getsockname() 769 The functions that are related to socket options are: 771 getsocketopt() 773 setsocketopt() 775 The functions that are used for conversion of IP addresses embedded 776 in application layer protocol (e.g., FTP, DNS, etc.) are: 778 recv() 780 send() 782 read() 784 write() 786 As well, raw sockets for IPv4 and IPv6 MAY be intercepted. 788 Most of the socket functions require a pointer to the socket address 789 structure as an argument. Each IPv4 argument is mapped into 790 corresponding an IPv6 argument, and vice versa. 792 According to [RFC2553], the following new IPv6 basic APIs and 793 structures are required. 795 IPv4 new IPv6 796 ------------------------------------------------ 797 AF_INET AF_INET6 798 sockaddr_in sockaddr_in6 799 gethostbyname() getaddrinfo() 800 gethostbyaddr() getnameinfo() 801 inet_ntoa()/inet_addr() inet_pton()/inet_ntop() 802 INADDR_ANY in6addr_any 804 Figure 9 806 BIH MAY intercept inet_ntoa() and inet_addr() and use the address 807 mapper for those. Doing that enables BIH to support literal IP 808 addresses. 810 The gethostbyname() call return a list of addresses. When the name 811 resolver function invokes getaddrinfo() and getaddrinfo() returns 812 multiple IP addresses, whether IPv4 or IPv6, they SHOULD all be 813 represented in the addresses returned by gethostbyname(). Thus if 814 getaddrinfo() returns multiple IPv6 addresses, this implies that 815 multiple address mappings will be created; one for each IPv6 address. 817 Authors' Addresses 819 Bill Huang 820 China Mobile 821 53A,Xibianmennei Ave., 822 Xuanwu District, 823 Beijing 100053 824 China 826 Email: bill.huang@chinamobile.com 828 Hui Deng 829 China Mobile 830 53A,Xibianmennei Ave., 831 Xuanwu District, 832 Beijing 100053 833 China 835 Email: denghui02@gmail.com 837 Teemu Savolainen 838 Nokia 839 Hermiankatu 12 D 840 FI-33720 TAMPERE 841 Finland 843 Email: teemu.savolainen@nokia.com