idnits 2.17.1 draft-hamarsheh-behave-biav2-05.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 abstract seems to contain references ([RFC3338]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 19, 2011) is 4836 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3493' is defined on line 1165, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3338 (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2767 (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network working group A. Hamarsheh 3 Internet-Draft ETRO/Vrije Universiteit Brussel 4 Intended status: Informational M. Goossens 5 Expires: July 23, 2011 ETRO/Vrije Universiteit Brussel 6 January 19, 2011 8 Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA) 9 draft-hamarsheh-behave-biav2-05 11 Abstract 13 This document specifies a mechanism for hosts with any network 14 connectivity (IPv4 only, IPv6 only, or dual IPv4/IPv6 15 connectivity) to run applications of any capability 16 (IPv4 only, IPv6 only, or dual IPv4/IPv6) without any 17 modification to those applications. It is a generalisation 18 of a previous experimental protocol called "Bump-in-the-API" 19 (BIA) [RFC3338]. New mechanism of BIA allows a changeover between 20 the application layer and the IP communication layers from IPv4 21 to IPv6 and vice versa or IPv6 to IPv4 and vice versa, without 22 requiring those applications to be converted in addressing 23 capabilities, effectively shielding the application layer from 24 IPv4 or IPv6 connectivity. This is considered by the authors to 25 be one of the essential conditions for the transition to IPv6 26 in the Internet to be successful. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 23, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described 56 in Section 4.e of the Trust Legal Provisions and are provided 57 without warranty as described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents: 72 1. Motivation and Introduction ................................ 5 73 1.1 Motivation .............................................. 5 74 1.2 Introduction ............................................ 6 75 2. Applicability and Related Techniques ....................... 7 76 2.1 Applicability ........................................... 7 77 2.2 Related Techniques ...................................... 8 78 3. Host Configurations Using BIA .............................. 9 79 3.1 IPv6 Only Host Using BIA ................................ 10 80 3.2 IPv4 Only Host Using BIA ................................ 10 81 3.3 Dual Connectivity Host Using BIA ........................ 11 82 4. BIA Modules ................................................ 12 83 4.1 Name Resolver ........................................... 12 84 4.1.1 IPv4 Only Application on The Local Host .............. 12 85 4.1.2 IPv6 Only Application on The Local Host .............. 13 86 4.1.3 Reverse DNS Lookup ................................... 14 87 4.1.4 Originating Without DNS Lookup ....................... 14 88 4.2 Address Resolver ........................................ 15 89 4.2.1 Mapping .............................................. 15 90 4.2.2 Embedding ............................................ 16 91 4.3 Function Mapper ......................................... 16 92 5. Behavior Examples ......................................... .17 93 5.1 IPv4 Only Application, IPv6 Only Connectivity with an 94 IPv6 Only Peer .......................................... 18 95 5.1.1 Behavior for IPv4 Only Originator Application on IPv6 96 Only Host Communicating to IPv6 Only Peer ............ 18 97 5.1.2 Behavior for IPv4 Only Recipient Application on IPv6 98 Only Host ............................................ 19 99 5.2 IPv4 only Application, IPv6 Only Network and Dual 100 Connectivity Peer ....................................... 21 101 5.2.1 Behavior for IPv4 Only Originator Application on IPv6 102 Only Host Communicating with Dual Connectivity Host .. 21 103 5.2.2 Behavior for IPv4 Only Recipient Application on IPv6 104 Only Host Communicating with Dual Connectivity Host .. 21 105 5.3 IPv6 Only Application, IPv4 Only Connectivity with an 106 IPv4 Only Peer .......................................... 21 107 5.3.1 Behavior for IPv6 Only Originator Application on IPv4 108 Only Host Communicating with IPv4 Only Host .......... 21 109 5.3.2 Behavior for IPv6 Only Recipient Application on IPv4 110 Only Host Communicating with IPv4 Only Host .......... 23 111 5.4 IPv6 Only Application, IPv4 Only Network and Dual 112 Connectivity Peer ....................................... 24 113 5.4.1 Behavior for IPv6 Only Originator Application on IPv4 114 Only Host Communicating with Dual Connectivity Host .. 24 115 5.4.2 Behavior for IPv6 Only Recipient Application on IPv4 116 Only Host Communicating with Dual Connectivity Host .. 24 117 5.5 IPv4 Only Application on Dual Connectivity Host 118 Communicating to IPv6 Only Peer ......................... 24 119 5.5.1 IPv4 Only Originator Application on Dual Connectivity 120 Host Communicating to IPv6 Only Peer ................ 24 121 5.5.2 IPv4 Only Recipient Application on Dual Connectivity 122 Host Communicating to IPv6 Only Peer ................. 24 123 5.6 IPv6 Only Application on Dual Connectivity Host 124 Communicating to IPv4 Only Peer ......................... 24 125 5.6.1 IPv6 Only Originator Application on Dual Connectivity 126 Host Communicating to IPv4 Only Peer ................. 24 127 5.6.2 IPv4 Only Recipient Application on Dual Connectivity 128 Host Communicating to IPv4 Only Peer ................. 24 129 6. Considerations ............................................. 25 130 6.1 Socket API Conversion ................................... 25 131 6.2 Address Mapping and Embedding ........................... 25 132 6.3 ICMP Message Handling ................................... 26 133 6.4 Implementation Issues ................................... 26 134 7. Limitations ................................................ 26 135 8. IANA Considerations ........................................ 26 136 9. Security Considerations .................................... 27 137 10. References ................................................. 27 138 10.1 Normative References ................................... 27 139 10.2 Informative References ................................. 28 140 Authors Addresses .............................................. 29 141 1. Motivation And Introduction 142 1.1 Motivation 144 It is probably important to give a brief analysis first of one of the 145 blocking factors withholding the wide-spread introduction of IPv6 in 146 order to fully understand why the here proposed BIA is considered an 147 essential component in the unlocking of IPv6. 148 At the inception of IPv6 it was - rather naively - presumed that all 149 parties involved with the Internet would be eager to make the 150 changeover and that the transition would happen spontaneously. 151 It is now quite generally acknowledged that some human and commercial 152 factors preventing a spontaneous transition have been largely 153 underestimated. In the transition to IPv6 there are essentially 154 two parties involved: network providers and end-users. 155 The benefits of using IPv6 are almost entirely for the network 156 providers, while the end-users have only potentially indirect 157 benefits from better network operation. No drive to make the 158 changeover should be expected from the majority of end-users, 159 as they have probably little to gain. The network providers can expect 160 benefits,but they are obviously dependent on the willingness of their 161 end-users to make any changeover. The result is some kind of 162 deadlock: no (commercial) network provider is going to force the 163 customers to make the changeover against their will. So making the 164 transition transparent to the end-user is the key in any transition 165 to IPv6. The average end-users are not really aware about what goes on 166 in the network layer, and even if they do, they usually could not care 167 less. It does not matter much to them if their applications are 168 communicating using IPv4 or IPv6. But, while there is no drive to be 169 expected from the end-users for any transition to IPv6, the vast 170 majority would not object to the transition on condition they can go 171 on using their applications as before. 172 While the first impression is that applications are not affected 173 by the changeover on the IP layer from IPv4 to IPv6, this is 174 unfortunately not true. The applications are using IP addresses, 175 and hence should be capable of dealing with the longer IPv6 addresses 176 when having to communicate over IPv6. 177 Expecting all applications to be modified to be capable of dealing 178 with the longer IPv6 addresses is rather naive. Apart from the 179 "standard" Internet applications with rather good support such as 180 web browsers, email programs, etc. that can be expected to be IPv6 181 enabled, there are thousands of other applications, some of them are 182 written by small companies (of which some may be out of business) 183 and others are even "home-made". For some applications, Internet 184 communication is only a side-issue, for example for registering 185 and/or checking for updates, and upgrading to become IPv6 compatible 186 is probably not a high priority. It is to be expected that a large 187 proportion of applications will only be modified to be IPv6 188 compatible when IPv6 usage gets into full swing. And even if the 189 IPv6 capable new versions of application software are made available, 190 it is again rather naive to expect all end-users to do the required 191 updating of all the software on their system. 192 The end-users MAY be willing to accept a changeover to IPv6, but will 193 NOT accept that some of their applications will no longer work as 194 before. From this observation it becomes obvious that it is 195 absolutely essential that provisions are standard installed and 196 enabled on any general purpose machine (the vast majority of systems 197 connected to the Internet) that is provided for IPv6 communication 198 and potentially has to run IPv4-only applications to continue 199 communicating as before when communicating using IPv6. While the 200 demand for mandatory provisions on every general purpose machine 201 capable of communicating using IPv6 may seem a tall order, 202 it should be realized that this approach is much more realistic 203 then expecting all applications to be made IPv6 compatible: 204 compared to thousands of applications that would need conversion 205 requiring all application developers to follow suit, the number of 206 communication stack implementations on general purpose machines is 207 very small and is made by only a handful of developers. 208 While somewhat less of an urgent issue, the solution should be 209 general enough to handle the reverse problem as well: an IPv6 only 210 application should be able to communicate on a machine with IPv4 211 only connectivity, or dual IPv4/IPv6 connectivity when communicating 212 using IPv4 with remote hosts that have IPv4-only connectivity.While 213 this looks like a move in the wrong direction in the context of 214 transition towards IPv6, this capability is also important to break 215 the slowdown of the development of IPv6 compatible applications, 216 as described in [RFC2460]. Little effort is being invested into 217 making applications IPv6 capable, as almost no machines currently 218 have IPv6 connectivity. BIA allows to using these IPv6 capable 219 applications to run on the IPv4 infrastructure, removing the 220 practical limitation that IPv6 applications cannot be used at 221 this time. 222 Other practical issues are blocking the deployment of IPv6, such as 223 the lack of IPv6 support in public access networks, the lack of real 224 auto configuration between IPv4 and IPv6 connectivity, 225 incompatibility in IPv4/IPv6 connectivity of hosts, etc. Solutions to 226 these other practical issues are being investigated currently by 227 the authors. 229 1.2 Introduction 231 The original BIA is an experimental function intended at allowing IPv4 232 only applications on dual stack (dual connectivity) hosts to 233 communicate over IPv6 with remote IPv6 only applications. It was also 234 only usable in the specific context described. 235 The proposed BIA is a generalisation of the original concept, allowing 236 any mixture of IPv4/IPv6 type capable applications to communicate over 237 any IPv4/IPv6 connections with any IPv4/IPv6 type capable remote 238 applications. BIA effectively decouples application IPv4/IPv6 239 capability from IPv4/IPv6 connectivity, and all allows IPv4/IPv6 240 incompatibility between two communicating applications. 241 The concept is quite simple: BIA essentially does internal address 242 translation where necessary between IPv4 and IPv6 addresses in between 243 the application and the communication stack; functionally, it can be 244 compared to an internal NAT [RFC3022] between the communication stack 245 and the application layer. Conceptually BIA is an adaptation layer 246 that needs to be inserted between the application layer and the IP 247 communication stack as an API layer on top of the native API functions, 248 offering the same API functions as the native ones to the application 249 layer. In an optimized implementation, it can probably better be 250 implemented as an internal modification to the API itself. 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in [RFC2119] . 256 This document uses terms defined in [RFC2460], [RFC4213], [RFC2767], 257 [RFC3338], and [I-D.draft-huang-behave-rfc3338bis]. 259 2. Applicability and Related techniques 261 The term IPv4/IPv6 connectivity will be used, rather than stack, since 262 it is the connectivity that specifies whether the machine can 263 communicate using IPv4, IPv6 or both, and not only the implementation 264 of the IP stacks inside the machine; e.g. a dual stack machine has 265 both IPv4 and IPv6 stacks implemented, but may have only IPv4 or IPv6 266 network connectivity due to the type of network it is connected to, 267 or may have to use IPv6 because the remote has only IPv6 connectivity. 269 2.1 Applicability 271 The BIA is a mechanism that should be mandatory installed and enabled 272 on hosts potentially having to run applications with incompatible 273 IPv4/IPv6 addressing capability regarding to their IPv4/IPv6 network 274 connectivity. For example, IPv4 only applications that have to 275 communicate over IPv6; or IPv6 only applications having to communicate 276 over IPv4 only connectivity. It allows an IPv4 only application which 277 is running on the local host to communicate over IPv6 with another 278 IPv4/IPv6 application on another host without any modification. 280 It is important to note that the mechanism assumes that the host knows 281 whether it is connected via dual IPv4/IPv6 connectivity, IPv4 only 282 connectivity, or IPv6 only connectivity (this is an implementation 283 issue and will not be discussed here). Table 1 describes the scenarios 284 of all IPv4/IPv6 capability types of applications running over all 285 possible types of host connectivities. Only the situations with 286 incompatibility between application IPv4/IPv6 capability and IPv4/IPv6 287 connectivity are listed. 289 Source Host Destination Host 290 +---------------+-------------------+ +-------------------+ 291 | Appl. Version | Host Connectivity | Network | Host Connectivity | 292 +---------------+-------------------+ +-------------------+ 293 | IPv4 | IPv6 | <-IPv6-> | IPv6 | 294 +---------------+-------------------+ +-------------------+ 295 | IPv4 | IPv6 | <-IPv6-> | IPv4/IPv6 | 296 +---------------+-------------------+ +-------------------+ 297 | IPv6 | IPv4 | <-IPv4-> | IPv4 | 298 +---------------+-------------------+ +-------------------+ 299 | IPv6 | IPv4 | <-IPv4-> | IPv4/IPv6 | 300 +---------------+-------------------+ +-------------------+ 301 | IPv4 | IPv4/IPv6 | <-IPv6-> | IPv6 | 302 +---------------+-------------------+ +-------------------+ 303 | IPv6 | IPv4/IPv6 | <-IPv4-> | IPv4 | 304 +---------------+-------------------+ +-------------------+ 306 Table 1: List all the scenarios treated by BIA mechanism 308 2.2 Related Techniques 310 The original BIA mechanism is customized for dual stack hosts. BIA is 311 a mechanism that is inserted between the socket API module and the 312 TCP/IP module. The main purpose of this mechanism is to make the IPv4 313 applications communicate with applications that can only communicate 314 using IPv6 (IPv6 only connectivity and/or IPv6 only application) 315 without any modification on those IPv4 applications. This would be 316 achieved by translating the IPv4 socket API functions into IPv6 socket 317 API functions and vice versa. 318 BIS mechanism [RFC2767] allows host to communicate with other IPv6 319 hosts using existing IPv4 applications. It is also customized for dual 320 stack hosts. The technique uses SIIT [RFC2765] to translate the IPv4 321 traffic into IPv6 traffic and vice versa. However, this mechanism uses 322 translator which is inserted between the TCP/IP module and the network 323 card driver. The limitations of this mechanism are similar to the SIIT 324 limitations concerning the IP header translation methods. Its 325 implementation is also fully dependent on the network interface driver. 327 3. Host Configurations using BIA 329 BIA can be installed on three different host configurations regarding 330 to IPv4/IPv6 331 connectivity: 332 1. IPv4 only host: only IPv4 connectivity. 333 2. IPv6 only host: only IPv6 connectivity. 334 3. IPv4/IPv6 host: both IPv4 and IPv6 connectivity. 336 The connectivity of the local host for communication with a remote host 337 is actually decided by several factors: 338 - The implementation of stack(s) in the local (IPv4 only stack, IPv6 339 only stack, or dual stack). 340 - The network connectivity of the local host (IPv4 network connectivity 341 only, IPv6 network connectivity only, both IPv4 and IPv6 network 342 connectivity). 343 - The connectivity of the remote machine (IPv4 only connectivity, IPv6 344 only connectivity, both IPv4 and IPv6 connectivity). 346 This means that the connectivity of a host, even with dual stack 347 implementation, is dynamic: it depends on the network connectivity, 348 which may change (e.g. a laptop that may be regularly connected to 349 different networks over time) and/or the connectivity of the remote 350 host. 351 For example a local host may be limited to IPv6 communication with a 352 remote host because it only has an IPv6 stack implemented, it may 353 have a dual stack implementation but only IPv6 network connectivity, 354 or the remote host may have only IPv6 connectivity. 356 The connectivity of the host will be combined with three possibilities 357 of application addressing capability. 358 - IPv4 only application: only IPv4 addressing capability. 359 - IPv6 only application: only IPv6 addressing capability. 360 - IPv4/IPv6 application: both IPv4 and IPv6 addressing capability. 362 There will be different behavior for BIA depending on the local host 363 IPv4/IPv6 connectivity as well as the application's IPv4/IPv6 364 addressing capability. 366 - IPv4 applications communicating over IPv4 or IPv6 applications 367 communicating over IPv6 are the native situations and do not need 368 consideration here; in this case BIA simply has to perform 369 no action. 371 - For an IPv4 application that needs to communicate using IPv6, 372 the IPv4 application's addressing needs to be converted to IPv6 373 in order to be transmitted to the remote host. The opposite 374 conversion has to be applied when an IPv6 application needs to 375 communicate over IPv4. 377 - For an IPv6 only application on an IPv4/IPv6 host communicating 378 with an IPv4/IPv6 remote host, the mechanism provides an optional 379 feature to make this application able to communicate over IPv4 as 380 well as over IPv6. If this application is trying to communicate 381 over IPv4, the application's addressing needs to be converted to 382 IPv4 in order to be transmitted to the remote host. 384 3.1 IPv6 Only Host Architecture Using BIA 386 IPv4 applications need IPv4 connectivity for communication. BIA is a 387 mechanism that enables hosts that have to communicate using IPv6 to 388 run IPv4 applications. Such hosts MUST have BIA installed and enabled. 389 Figure 1 shows the architecture of the IPv6 host in which BIA 390 is installed. 391 +---------------------------------------------+ 392 | +-------------------+ | 393 | | IPv4 Applications | | 394 | +-------------------+ | 395 | +-[BIA]-----------------------------------+ | 396 | | +-----------------------+ | | 397 | | |Socket API (IPv4, IPv6)| | | 398 | | +-----------------------+ | | 399 | +-----------------------------------------+ | 400 | +-------------------+ | 401 | | IPv6 API | | 402 | +-------------------+ | 403 | | | | 404 | | TCP(UDP)/IPv6 | | 405 | | | | 406 | +-------------------+ | 407 +---------------------------------------------+ 408 Figure 1: the architecture of IPv6 only host 409 In which BIA is installed. 411 3.2 IPv4 Only Host Architecture Using BIA 413 IPv4 only hosts are capable of running IPv4 applications only. BIA 414 can be installed on such machines to allow these hosts to run IPv6 415 only applications as well. Figure 2 shows the host architecture of 416 the IPv4 host in which BIA is installed. 418 +---------------------------------------------+ 419 | +-------------------+ | 420 | | IPv6 Applications | | 421 | +-------------------+ | 422 | +-[BIA]-----------------------------------+ | 423 | | +-----------------------+ | | 424 | | |Socket API (IPv4, IPv6)| | | 425 | | +-----------------------+ | | 426 | +-----------------------------------------+ | 427 | +-------------------+ | 428 | | IPv4 API | | 429 | +-------------------+ | 430 | | | | 431 | | TCP(UDP)/IPv4 | | 432 | | | | 433 | +-------------------+ | 434 +---------------------------------------------+ 435 Figure 2: the architecture of IPv4 only host 436 In which BIA is installed. 438 3.3 Dual Connectivity Host Architecture Using BIA 440 [RFC4213] suggests that dual stack hosts need applications, dual 441 TCP/IP modules and addresses for both IPv4 and IPv6. In such hosts, 442 the BIA will be used only when the received DNS record(s) version is 443 incompatible with the running of the application's IPv4/IPv6 444 capability. For example, if a dual connectivity host is running an 445 IPv4 only application, and this application is going to communicate 446 with an IPv6 only host, then the name resolver will receive the 447 'AAAA' record for the destination host so that the current 448 connectivity will be IPv6, and BIA will translate the IPv4 socket 449 API functions into IPv6 socket API functions and vice versa. 450 BIA always will use the API functions that are compatible with the 451 destination address. Figure 3 shows a dual connectivity host on which 452 BIA is installed. 454 +---------------------------------------------+ 455 | +-------------------+ +-------------------+ | 456 | | IPv4 Applications | | IPv6 Applications | | 457 | +-------------------+ +-------------------+ | 458 | +-[BIA]-----------------------------------+ | 459 | | +-----------------------+ | | 460 | | |Socket API (IPv4, IPv6)| | | 461 | | +-----------------------+ | | 462 | +-----------------------------------------+ | 463 | +-------------------+ +-------------------+ | 464 | | IPv4 API | | IPv6 API | | 465 | +-------------------+ +-------------------+ | 466 | | | | | | 467 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 468 | | | | | | 469 | +-------------------+ +-------------------+ | 470 +---------------------------------------------+ 471 Figure 3: the architecture of dual stack host 472 In which BIA is installed. 473 4. BIA Modules 475 Like BIA, the API translator in BIA consists of three modules, name 476 resolver, address resolver, and function mapper. 478 4.1 Name Resolver 480 In general the name resolver module returns a proper answer in response 481 to the IPv4 or IPv6 application's DNS resolving request. The name 482 resolver has different behaviors depending on the running 483 application's IPv4/IPv6 capability and the IPv4/IPv6 connectivity. 485 4.1.1 IPv4 only application on the local host: 487 - IPv4 Only Host: 488 Since this is the native situation, BIA needs to perform no action. 490 - IPv6 Only Host 491 This behavior of the name resolver occurs when an IPv4 application 492 needs to communicate using IPv6. The application will try to resolve 493 names via the IPv4 resolver library (e.g. gethostbyname). BIA will 494 call the IPv6 equivalent function (e.g. getnameinfo) that will 495 resolve both 'A' and 'AAAA' records. If it got 'AAAA' record(s) only, 496 it requests the address resolver (see below) to assign internal IPv4 497 address(es) corresponding to the IPv6 address(es) of the 'AAAA' 498 record(s), then creates 'A' record(s) for the assigned IPv4 499 address(es), finally returns the created 'A' record(s) of the 500 internal address(es) to the IPv4 application. Note that this behavior 501 is similar to the name resolver behavior in the BIA mechanism, but 502 there are differences in the way internal addresses are assigned and 503 managed (see address resolver further). 504 If both 'A' and 'AAAA' records are received, BIA will discard the 'A' 505 record(s) as these cannot be used with IPv6, and select only the 506 'AAAA' record(s). 508 - IPv4/IPv6 Host: 509 The application will try to resolve names via the IPv4 resolver library 510 (e.g. gethostbyname). BIA will call the IPv6 equivalent function (e.g. 511 getnameinfo) that will resolve both 'A' and 'AAAA' records. If it got 512 'AAAA' record(s) only, it requests the address resolver (see below) to 513 assign internal IPv4 address(es) corresponding to the IPv6 address(es) 514 of the 'AAAA' record(s), then creates 'A' record(s) for the assigned 515 IPv4 address(es), finally returns the created 'A' record(s) of the 516 internal address(es) to the IPv4 application. If it got 'A' record(s) 517 only, the communication will continue as native IPv4 communication, 518 and BIA has to do no operation. If both 'A' and 'AAAA' records are 519 returned, the communication can be effected natively using IPv4 using 520 the 'A' record(s). But as an additional, optional feature, the IPv4 521 application can also be allowed to communicate over IPv6 with IPv6 522 peer(s). In that case, it requests the address resolver (see below) to 523 assign internal IPv4 address(es) corresponding to the IPv6 address(es) 524 of the 'AAAA' record(s), then creates 'A' record(s) for the assigned 525 IPv4 address(es), and finally returns both the original 'A' for the 526 remote AND the created 'A' record(s) of the internal address(es) to 527 the IPv4 application. This extends the communication capabilities 528 of the application to cover both IPv4 and IPv6 communication with 529 the remote(s). 531 4.1.2 IPv6 Application on the local host: 533 - IPv6 Only Host: 534 Since this is the native situation, BIA needs to perform no action. 536 - IPv4 Only Host: 537 This situation occurs when an IPv6 application needs to communicate 538 using IPv4, the application will try to resolve names via the IPv6 539 resolver library (e.g. getnameinfo). BIA will call the IPv4 equivalent 540 function (e.g. gethostbyname). If it got 'A' record(s) only, it 541 requests the address resolver to assign an internal IPv4-embedded 542 IPv6 address(es) [I-D.draft-ietf-behave-address-format] corresponding 543 to the IPv4 ddress(es), then creates 'AAAA' record(s) for the 544 IPv4-embedded IPv6 address(es) and returns these 'AAAA' record(s) to 545 the IPv6 application. 547 - IPv4/IPv6 Host: 548 The application will try to resolve names via the IPv6 resolver library 549 (e.g. gethostinfo) that will resolve both 'A' and 'AAAA' records. If it 550 got 'A' record(s) only, the name resolver will request the address 551 resolver to assign internal IPv4-embedded IPv6 address(es) corresponding 552 to the IPv4 address(es), then creates 'AAAA' record(s) for the 553 IPv4-embedded IPv6 address(es) and returns these 'AAAA' record(s) to 554 the application. If it got 'AAAA' records only, the communication will 555 continue as native IPv6 communication, and BIA has to do no operation. 556 If both 'A' and 'AAAA' records are returned, the communication can be 557 effected natively using IPv6 using the 'AAAA' record(s). But as an 558 additional, optional feature, the IPv6 application can also be allowed 559 to communicate over IPv4 with IPv4 peer(s). In that case, it requests 560 the address resolver to assign internal IPv4-embedded IPv6 address(es), 561 then creates 'AAAA' record(s), and finally returns both the original 562 'AAAA' for the remote AND the created 'AAAA' record(s) of the internal 563 address(es) to the IPv6 application. This extends the communication 564 capabilities of the application to cover both IPv4 and IPv6 565 communication with the remote(s). 567 4.1.3 Reverse DNS lookup 569 For various reasons, applications may do "pointer" lookups, i.e. the 570 application passes the IP address and expects the host name in return. 571 BIA should be able to handle these calls. When address translation 572 (mapping or embedding) was performed on the host IP address, the 573 application will call with the internal address generated by BIA. 574 The DNS call to resolve the name should obviously be made with the 575 external address that corresponds to the translated address, and the 576 name returned for the external address needs to be returned to the 577 application. 579 4.1.4 Originating without DNS lookup 581 Some applications bypass the DNS lookup, and use an IP address directly 582 instead. While often this is bad practice, in some instances this how 583 the software is being operated. For an IPv4 only application making 584 such call, if an address mapping was stored for the supplied IPv4 585 address, that mapping can be used. Otherwise, as no DNS call is made, a 586 correspondence between IPv4 and IPv6 addresses cannot be made by the 587 name and address resolvers, and communication using incompatible 588 application IPv4 capability and IPv6 connectivity is impossible. 589 But for both for IPv4 and IPv6 applications, as a last resort, a 590 "dirty trick" can be attempted however. Using the IP address from the 591 application, a "pointer" DNS lookup can be made. If this succeeds, 592 a forward DNS lookup can be made on the returned name, which may return 593 one or more addresses of the other type required to establish the 594 required IPv4/IPv6 address relationship. If this trick does not 595 succeed, communication will be impossible, unless native communication 596 is available (IPv4 over IPv4 connectivity or IPv6 over IPv6 597 connectivity). 598 It is recommended that address relationships can be manually entered 599 in the mapping table for such occurrences. Such address mappings are in 600 this case external IPv4-to-external IPv6 address mappings, and not 601 relations between an internal and an external address. 603 4.2 Address Resolver 605 The address resolver is only involved with incompatibility between 606 application IPv4/IPv6 capability and host IPv4/IPv6 connectivity. The 607 address resolver has different behavior depending on the name resolver 608 and function mapper requests. Like in the original BIA address mapper, 609 the address resolver in BIA maintains a table of the pairs of an 610 internal IPv4 address and an external IPv6 address in an IPv6 only 611 host. These IPv4 addresses are assigned from an IPv4 address pool for 612 internal addresses, but the mechanism for the pool is different here, 613 as explained further. 614 The key difference between BIA and the BIA mechanism is the ability for 615 the later to address all kinds of remote host connectivity (i.e. IPv4 616 only, IPv6 only and dual IPv4/IPv6 connectivity). Different addressing 617 techniques are used depending on the remote host. The sending host has 618 to take the decision either to map the destination IPv6 address into an 619 internal IPv4 address assigned from the IPv4 address pool, or to embed 620 the IPv4 address into an internal IPv4-embedded IPv6 address. The 621 Address resolver in BIA can receive two possible address types-normally 622 after calling the name resolver and querying the DNS- regarding the 623 remote host(s) for that domain name: 625 - IPv6 Address: in this case it receives 'AAAA' record(s) and the 626 address resolver has to map the IPv6 into an internal IPv4 627 address(es). 628 - IPv4 address: in this case it receives 'A' record(s) and the address 629 resolver has to embed the IPv4 address into an internal IPv6 630 address(es). 632 4.2.1 Mapping 634 This technique is used when an IPv4 application needs to communicate 635 using IPv6. It internally maintains a table of the pairs of IPv4 636 address(es) and IPv6 address(es). The IPv4 addresses are assigned 637 from an IPv4 address pool. These addresses should be selected from 638 a private IPv4 addresses as per [RFC1918] to be used by BIA for 639 mapping purposes (see further). When the name resolver or the 640 function mapper requests it to assign an internal IPv4 address 641 corresponding to an IPv6 address, it selects and returns an IPv4 642 address out of the pool, and registers a new entry into the table 643 dynamically. As in the original BIA, the registration occurs in the 644 following two cases: 646 1. When the name resolver gets only an 'AAAA' record for the target 647 host name and there is not a mapping entry for the IPv6 address. 648 2. When the function mapper gets a socket API function call from the 649 data received and there is not a mapping entry for the IPv6 source 650 address. Address mappings are stored. When the address resolver is 651 called to map an IPv6 external address into an IPv4 internal address, 652 it will first look up the table to check whether there was a previous 653 mapping for that address. If one is found, it will reuse and return 654 that mapping. If not, it will create a new mapping, store that mapping 655 and return the newly created mapping. 657 4.2.2 Embedding 659 Unlike the original BIA, BIA also allows IPv6 only applications to 660 communicate over IPv4. Therefore a correspondence between external 661 IPv4 addresses and internal IPv6 addresses need to be established. 662 The proposed method is "IPv4-in-IPv6" address embedding 663 [I-D.draft-ietf-behave-address-format]. The address resolver is 664 configured to use one of the methodologies that are described in 665 [I-D.draft-ietf-behave-address-format] to create an 666 IPv4-embedded IPv6 address. The new address consists of: Network 667 Specific Prefix (NSP) (32 bits), the IPv4 destination address 668 (32 bits), and finally the suffix (64 bits). Figure 4 demonstrates 669 the IPv4-embedded IPv6 address structure. 670 As the real external IPv4 address is embedded into the internal 671 IPv6 address, no registering is required in this case, as there 672 is always a unique correspondence. 674 | 32 bits | 32 bits | 64 bits | 675 +--------------+--------------+---------------------------+ 676 | NSP | IPv4 Address | Suffix | 677 +--------------+--------------+---------------------------+ 678 Figure 4: The structure of IPv4-embedded IPv6 address 680 4.3 Function Mapper 682 The function mapper has different behavior depending on the host 683 connectivity. In dual connectivity hosts (IPv4 and IPv6 connectivity) 684 the function mapper is used to decide which API functions to call in 685 the current communication. It is important to note that the BIA modules 686 will be invoked just if there is an incompatibility between the running 687 application and the connectivity type. In case of IPv6 only or IPv4 688 only connectivity, the main goal of the function mapper is just like 689 in original BIA mechanism. It is used when conversion is required 690 from IPv4 to IPv6 or the other way around between application layer 691 and communication stack. In that case it translates the API functions 692 used by the application into the API functions needed for the 693 communication, and vice versa. 695 In dual connectivity hosts, deciding which API functions to call 696 depends on the address type of the remote. The following is the 697 behavior of the function mapper running on dual connectivity hosts: 699 1. IPv4 only application communicating over IPv6: in this case it will 700 call the equivalent IPv6 socket API functions. The application will use 701 the IPv4 socket API to communicate with other hosts. Since the 702 application needs to communicate over IPv6, the function mapper 703 intercepts the IPv4 socket API functions and calls the equivalent IPv6 704 socket API functions instead. 706 2. IPv6 only application communicating over IPv4: in this case it will 707 call the equivalent IPv4 socket API functions. The application will use 708 the IPv6 socket API to communicate with other hosts. Since the 709 application needs to communicate over IPv4, the function mapper 710 intercepts the IPv6 socket API functions and calls the equivalent IPv4 711 socket API functions instead. 713 5. Behavior Examples 715 The following sections will describe the behaviors of the hosts and 716 applications that are listed in table 1. 717 In the following sections, the meanings of arrows are as follows: 718 ---> A DNS message for name resolving created by the 719 Applications and the name resolver in the API translator. 720 +++> An IPv4 or IPv4-embedded IPv6 address request to and reply 721 from the address resolver for the name resolver and the 722 function mapper. 723 ===> Data flow by API functions created by the applications 724 and the function mapper in the API translator. 726 5.1 IPv4 Only Application, IPv6 Only Connectivity with an IPv6 727 Only Peer. 728 5.1.1 Behavior for IPv4 Only Originator Application on IPv6 Only Host 729 Communicating to IPv6 Only Peer 731 When an IPv4 application sends a DNS query to its name server, the name 732 resolver intercepts the query and then creates a new query to resolve 733 both 'A' and 'AAAA' records. When only 'AAAA' record(s) is (are) 734 resolved, the name resolver requests the address resolver to get IPv4 735 address(es) corresponding to the IPv6 address(es) for each IPv6 address 736 from the 'AAAA' record. The address resolver first looks up the table 737 of stored entries to check if the correspondence was made previously. 738 If yes,the stored mapping is retrieved and passed to the name resolver. 739 If not, the address resolver creates a new mapping for an internal IPv4 740 address corresponding to the IPv6 external address, stores the mapping, 741 and returns the mapping to the name resolver. The name resolver, upon 742 receiving the internal IPv4 address(es) creates 'A' record(s) for the 743 assigned IPv4 address(es) and returns these to the application. In 744 order for the IPv4 application to send IPv4 packets over IPv6, it 745 calls the IPv4 socket API function. The function mapper detects the API 746 function call from the application. The IPv6 address is required to 747 invoke the IPv6 socket API function, thus the function mapper requests 748 the IPv6 address corresponding for the internal IPv4 address to the 749 address resolver. The address resolver selects the external destination 750 IPv6 address corresponding to the internal IPv4 address from the 751 mapping table and returns it to the function mapper. Using this IPv6 752 address, the function mapper will invoke the IPv6 socket API function 753 corresponding to the IPv4 socket API function received from the 754 application. 755 When a reply is received, this will come in through the IPv6 socket API, 756 and the function mapper requests the address resolver for the IPv4 757 address corresponding to the received IPv6 address. This IPv4 address 758 will be used to translate the IPv6 socket API function call into the 759 corresponding IPv4 socket API function call for the IPv4 application. 760 Figure 5 illustrates the behavior described above. 762 +-[IPv6 Only Host]-----------------+ 763 | API Translator | 764 | +--------+ +--------+ +--------+ | 765 +----+ +---------+ | |Name | |Address | |Function| | +------++---+ 766 |IPv4| | API | | |Resolver| |Resolver| | Mapper | | |IPv6 ||DNS| 767 |App.| | (V4/V6) | | +----|---+ +----|---+ +----|---+ | |Host || | 768 +-|--+ +----|----+ +------|----------|----------|-----+ +---|--++-|-+ 769 | Resolve IPv4 for host 6| | | | | 770 |----------------------->| query 'A' and 'AAAA' for host 6 | | 771 | | |--------------------------------------->| 772 | | | | | | | 773 | | | Reply with 'AAAA' Only | | 774 | | |<---------------------------------------| 775 | | | | | | | 776 | | | Req IPv4 | | | | 777 | | |+++++++++>| | | | 778 | | | Rep IPv4 |{Address Mapping} | | 779 | | |<+++++++++| | | | 780 | Reply with 'A' record | | | | | 781 |<-----------------------| | | | | 782 |An IPv4 API function call | | | | 783 |=============================================>| | | 784 | | | |Req IPv6 | | | 785 | | | |<+++++++++| | | 786 | | | {Lookup} |Rep IPv6 | | | 787 | | | |+++++++++>| | | 788 | | | | IPv6 API function Call| 789 | | | | |===========>| | 790 | | | | | | | 791 | | | | IPv6 API function Call| 792 | | | | |<===========| | 793 | | | | Req IPv4 | | | 794 | | | |<+++++++++| | | 795 | | | {Lookup} | Rep IPv4 | | | 796 | | | |+++++++++>| | | 797 | An IPv4 API function call | | | | 798 |<=============================================| | | 799 | | | | | | | 801 Figure 5: The behavior of the originator communicates with IPv6 802 Application 804 5.1.2 Behavior for IPv4 Only Recipient Application on IPv6 Only Host 806 The IPv6 originator host that started the communication to this host 807 has resolved the address of this IPv6 host with 'AAAA' record(s) 808 through its name server, and has sent an IPv6 packet to this IPv6 809 host. The function mapper requests the internal IPv4 address 810 corresponding to the originator's IPv6 address. The address resolver 811 looks up the mapping table to check for an entry. If one is found, 812 it returns the internal IPv4 address corresponding to the IPv6 813 address. Then the function mapper invokes the corresponding IPv4 814 socket API function for the IPv4 application corresponding to the 815 IPv6 function. If not, the address resolver creates a new mapping 816 for an internal IPv4 address corresponding to the IPv6 external 817 address, stores the mapping, and returns the mapping to the function 818 resolver. The remaining part of the handling is identical to what 819 was described in 5.1.1. Figure 6 illustrates the behavior described 820 above. 822 +-[IPv6 Only Host]-----------------+ 823 | API Translator | 824 | +--------+ +--------+ +--------+ | 825 +---------+ | |Name | |Address | |Function| | +---------+ 826 |IPv4 App | | |Resolver| |Resolver| |Mapper | | |IPv6 Only| 827 | | | +----|---+ +----|---+ +----|---+ | |Host | 828 +----|----+ +------|----------|----------|-----+ +----|----+ 829 | | | | IPv6 API function call 830 | | | |<===================| 831 | | |Req IPv4 | | 832 | | |<+++++++++| | 833 | {Address Mapping}|Rep IPv4 | | 834 | | |+++++++++>| | 835 |IPv4 API function call | | | 836 |<===================================| | 837 |Reply IPv4 data to host 6| | | 838 |===================================>| | 839 | | | | | 840 | | | Req IPv6 | | 841 | | |<+++++++++| | 842 | {Address Lookup} | Rep IPv6 | | 843 | | |+++++++++>| | 844 | | | | | 845 | | | |IPv6 API function call 846 | | | |===================>| 847 | | | | | 849 Figure 6: Behavior of receiving data from IPv6 host 850 5.2 IPv4 Only Application, IPv6 Only Network and Dual Connectivity Peer 852 5.2.1 Behavior for IPv4 Only Originator Application on IPv6 Only Host 853 Communicating with Dual Connectivity Host 855 When an IPv4 application sends a DNS query to its name server, the name 856 resolver intercepts the query and then creates a new query to resolve 857 both 'A' and 'AAAA' records. If both 'A' and 'AAAA' records are 858 resolved, the name resolver will only select the 'AAAA' records and 859 drop the drop the 'A' record(s) and requests the address resolver to 860 assign internal IPv4 address(es) corresponding to the IPv6 address(es). 861 The remaining behavior is exactly like described in 5.1.1. 863 5.2.2 Behavior for IPv4 Only Recipient Application on IPv6 Only Host 864 Communicating with Dual Connectivity Host 866 Exactly the same as in section 5.1.2 868 5.3 IPv6 Only Application, IPv4 Only Connectivity with an IPv4 869 Only Peer 870 5.3.1 Behavior for IPv6 Only Originator Application on IPv4 Only Host 871 Communicating with IPv4 Only Host 873 When an IPv6 application sends a DNS query to its name server to 874 resolve both 'A' and 'AAAA' records, the name resolver intercepts the 875 query and then creates a new query to resolve only 'A' record(s), 876 since it is a IPv4 only host. With only 'A' record(s) resolved, the 877 name resolver requests the address resolver to embed the IPv4 878 address(es) into IPv6 address(es) using the format described in 879 section 4.2.2. The name resolver creates 'AAAA' record(s) for the 880 IPv4 embedded IPv6 address(es) and returns it to the application. 881 In order for the IPv6 application to send IPv6 packets to IPv4 only 882 host, it calls the IPv6 socket API function. The function mapper 883 detects the API function call from the application. The function 884 mapper requires an IPv4 address to invoke the IPv4 socket API 885 function, so it requests the corresponding IPv4 address to the 886 address resolver. The address resolver extracts the destination 887 IPv4 address from the IPv4-embedded IPv6 address and returns it to 888 the function mapper. Using this IPv4 address, the function mapper 889 will invoke the IPv4 socket API function corresponding to the IPv6 890 socket API function. We notice here the address resolver is not 891 going to save any new records to the mapping table. 892 When a reply is received, this will come in through the IPv4 socket 893 API, and the function mapper requests the address resolver for the 894 IPv6 address corresponding to the received IPv4 address. This IPv6 895 address will be used to translate the IPv4 socket API function call 896 into the corresponding IPv6 socket API function call for the IPv6 897 application. Figure 7 illustrates the behavior described above. 899 +-[IPv4 Only Host]-----------------+ 900 | API Translator | 901 | +--------+ +--------+ +--------+ | 902 +----+ +---------+ | |Name | |Address | |Function| | +------++---+ 903 |IPv6| | API | | |Resolver| |Resolver| | Mapper | | |IPv4 ||DNS| 904 |App.| | (V4/V6) | | +----|---+ +----|---+ +----|---+ | |Host || | 905 +-|--+ +----|----+ +------|----------|----------|-----+ +---|--++-|-+ 906 | Resolve IPv6 for host 4| | | | | 907 |----------------------->| query 'A' and 'AAAA' for host 4 | | 908 | | |--------------------------------------->| 909 | | | | | | | 910 | | | Reply with 'A' Only | | 911 | | |<-------------------------------------->| 912 | | | | | | | 913 | | | Req IPv6 | | | | 914 | | |+++++++++>| | | | 915 | | {Embedding} | Rep IPv6 | | | | 916 | | |<+++++++++| | | | 917 |Reply with 'AAAA' record| | | | | 918 |<-----------------------| | | | | 919 |An IPv6 API function call | | | | 920 |=============================================>| | | 921 | | | |Req IPv4 | | | 922 | | | |<+++++++++| | | 923 | | {Extracting}|Rep IPv4 | | | 924 | | | |+++++++++>| | | 925 | | | | IPv4 API function Call| 926 | | | | |===========>| | 927 | | | | | | | 928 | | | | IPv4 API function Call| 929 | | | | |<===========| | 930 | | | | Req IPv6 | | | 931 | | | |<+++++++++| | | 932 | | {Embedding} | Rep IPv6 | | | 933 | | | |+++++++++>| | | 934 | An IPv6 API function call | | | | 935 |<=============================================| | | 937 Figure 7: The behavior of the originator communicates with IPv4 938 Application 939 5.3.2 Behavior for IPv6 Only Recipient Application on IPv4 Only Host 940 Communicating with IPv4 Only Host 942 The IPv4 originator host has resolved the address of this IPv4 host 943 with 'A'records through its name server, and has sent an IPv4 packet 944 to this IPv4 host. The function mapper requests the IPv6 address to 945 the address resolver in order to invoke the IPv6 socket API function 946 to communicate with the IPv6 application. The address resolver embeds 947 the IPv4 address(es) into IPv6 address(es) using the format described 948 in section 4.2.2, and returns this address. Then the function mapper 949 invokes the corresponding IPv6 socket API function for the IPv6 950 application corresponding to the IPv4 function. 952 +-[IPv4 Only Host]-----------------+ 953 | API Translator | 954 | +--------+ +--------+ +--------+ | 955 +---------+ | |Name | |Address | |Function| | +---------+ 956 |IPv6 App | | |Resolver| |Resolver| |Mapper | | |IPv4 Only| 957 | | | +----|---+ +----|---+ +----|---+ | |Host | 958 +----|----+ +------|----------|----------|-----+ +----|----+ 959 | | | | IPv4 API function call 960 | | | |<===================| 961 | | |Req IPv6 | | 962 | | |<+++++++++| | 963 | {Embedding} |Rep IPv6 | | 964 | | |+++++++++>| | 965 |IPv6 API function call | | | 966 |<===================================| | 967 |Reply IPv6 data to host 4| | | 968 |===================================>| | 969 | | | | | 970 | | | Req IPv4 | | 971 | | |<+++++++++| | 972 | {Extracting} | Rep IPv4 | | 973 | | |+++++++++>| | 974 | | | | | 975 | | | |IPv4 API function call 976 | | | |===================>| 977 | | | | | 979 Figure 8: Behavior of receiving data from IPv4 host 980 5.4 IPv6 Only Application, IPv4 Only Network and Dual Connectivity Peer 982 5.4.1 Behavior for IPv6 Only Originator Application on IPv4 Only Host 983 Communicating with Dual Connectivity Host 985 When an IPv6 application sends a DNS query to its name server, the name 986 resolver intercepts the query and then creates a new query to resolve 987 'A' record(s); no 'AAAA' record(s) are returned, as it is an IPv4 only 988 host. When 'A' record(s) is/are resolved, the name resolver will 989 request the address resolver to embed the IPv4 address(es) into IPv6 990 address(es) using the format that is describes in section 4.2.2. 991 The remaining processing is as in 5.3.1. 993 5.4.2 Behavior for IPv6 Only Recipient Application on IPv4 Only Host 994 Communicating with Dual Connectivity Host 996 Exactly the same as in section 5.3.2 997 5.5 IPv4 Only Application on Dual Connectivity Host Communicating to 998 IPv6 Only Peer 1000 5.5.1 IPv4 Only Originator Application on Dual Connectivity Host 1001 Communicating to IPv6 Only Peer 1003 Exactly the same as in section 5.1.1 1005 5.5.2 IPv4 Only Recipient Application on Dual Connectivity Host 1006 Communicating to IPv6 Only Peer 1008 Exactly the same as in section 5.1.2 1009 5.6 IPv6 Only Application on Dual Connectivity Host Communicating 1010 to IPv4 Only Peer 1012 5.6.1 IPv6 Only Originator Application on Dual Connectivity Host 1013 Communicating to IPv4 Only Peer 1015 Exactly the same as in section 5.3.1 1017 5.6.2 IPv4 Only Recipient Application on Dual Connectivity Host 1018 Communicating to IPv4 Only Peer 1020 Exactly the same as in section 5.3.2 1021 6. Considerations 1023 6.1 Socket API Conversion 1025 This document uses the socket API conversion specified in [RFC3338]. 1027 6.2 Address Mapping and Embedding 1029 There are some considerations as to the choice and management of the 1030 internal addresses: 1031 - For a diversity of reasons, several applications store the addresses 1032 of machines they have been communicating with, and check these 1033 addresses on next contact. It is hence important that each mapping 1034 of external IPv6 to internal IPv4 addresses is being stored by BIA, 1035 so as to always use the same internal address for a particular 1036 external address at the next communication. This implies a very wide 1037 IPv4 address range available for mapping. The authors propose a 1038 Class A range, making approximately 16Mega addresses available. 1039 Even that can get exhausted in some cases, so this range should 1040 be supplemented by a round-robin scheme where,in case of exhaustion, 1041 the mappings that remain unused for the longest time can be reused 1042 for new mappings (not the creation time, but the last time that 1043 mapping was actively used is important). It is considered that this 1044 would be sufficient in about all operational situations. As this 1045 mapping list potentially can become very large, the store/retrieval 1046 mechanism implementation should be optimized for speed or it may 1047 introduce unacceptable long delays. This is an implementation issue 1048 however, and will not be dealt with here. 1049 - It is obvious that an IPv4/IPv6 correspondence while be frequently 1050 required in the course of a communication; short time caching seems 1051 essential to avoid having to look up the correspondence again during 1052 the course of a communication. 1053 - A machine having both IPv4 and IPv6 connectivity will be using both 1054 IPv4 and IPv6 addresses. To avoid conflicts, it is essential that the 1055 internal addresses used will never be used as an external address. 1056 Original BIA proposed the use of a limited (256 addresses) range as 1057 a "pool" in an "unassigned" IPv4 address range. The limited size (256) 1058 is much too small for operational purposes, even not considering the 1059 requirement for storing the mappings as described in the previous 1060 paragraph, as a machine may have more than this number of mappings 1061 active concurrently. Taking into account the requirement for storing 1062 the mappings, a very large range of unassigned addresses is required. 1064 6.3 ICMP Message Handling 1066 When an application needs ICMP messages values (e.g., Type, Code, 1067 etc.) sent from a network layer, ICMPv4 message values MAY be 1068 translated into ICMPv6 message values based on SIIT 1069 [I-D.ietf-behave-v6v4-xlate], and vice versa. It can be implemented 1070 using raw socket. 1072 6.4 Implementation Issues 1074 This document uses the implementation issues specified in [RFC3338]. 1076 7. Limitations 1078 This mechanism supports unicast communications only. In order to support 1079 multicast functions, some other additional functionalities must be 1080 considered in the function mapper module. 1081 Since the IPv6 socket API has new advanced features, it is difficult to 1082 translate such kinds of IPv6 socket APIs into IPv4 socket APIs. Thus, 1083 IPv6 inbound communication with advanced features may be discarded. 1085 It should be noted that the original BIA assumes the hosts have 1086 compatible network connectivity. The new version of the BIA is 1087 developed to support the heterogeneity between connectivity and 1088 applications only, NOT incompatible network connectivity. 1089 Communication between hosts with incompatible connectivity 1090 (IPv4 only connectivity to IPv6 only connectivity, or the other way 1091 around) cannot be handled by BIA, and other solutions need to be 1092 applied, e.g. protocol translation mechanisms PNAT 1093 [I-D.draft-huang-behave-pnat], NAT64 1094 [I-D.ietf-behave-v6v4-xlate-stateful], or SIIT 1095 [I-D.ietf-behave-v6v4-xlate]. 1097 8. IANA Considerations 1099 This document has no IANA actions. 1101 9. Security Considerations 1103 This document uses the security considerations specified in [RFC3338]. 1105 10. References 1106 10.1 Normative References 1108 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 1109 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 1110 RFC 3338, October 2002. 1112 [RFC2460] Deering, S., and R., Hinden, "Internet Protocol, Version 6 1113 (IPv6) Specification", RFC 2460, December 1998. 1115 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1116 Address Translator (Traditional NAT)", RFC 3022, 1117 January 2001. 1119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1120 Requirement Levels", BCP 14, RFC 2119, March 1997. 1122 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1123 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1125 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 1126 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 1127 RFC 2767, February 2000. 1129 [I-D.draft-huang-behave-rfc3338bis] 1130 Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts 1131 Using "Bump-in-the-API" (BIA)", 1132 draft-huang-behave-rfc3338bis-02 (work in progress), 1133 March 2010. 1135 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1136 E. Lear, "Address Allocation for Private Internets",BCP 5, 1137 RFC 1918, February 1996. 1139 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1140 (SIIT)", RFC 2765, February 2000. 1142 [I-D.draft-ietf-behave-address-format] 1143 Huitema, C., "IPv6 Addressing of IPv4/IPv6 Translators", 1144 draft-ietf-behave-address-format-10 (work in progress), 1145 August 2010. 1147 [I-D.draft-huang-behave-pnat] 1148 Huang, B., and H., Deng, "Prefix NAT: Host based IPv6 1149 translation", draft-huang-behave-pnat-01 (work in 1150 progress), February 2010. 1152 [I-D.ietf-behave-v6v4-xlate-stateful] 1153 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1154 NAT64: Network Address and Protocol Translation from IPv6 1155 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate- 1156 stateful-12 (work in progress), July 2010. 1158 [I-D.ietf-behave-v6v4-xlate] 1159 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1160 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 1161 progress), September 2010. 1163 10.2 Informative References 1165 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1166 Stevens, "Basic Socket Interface Extensions for IPv6", 1167 RFC 3493, February 2003. 1169 Authors' Addresses 1171 Ala Hamarsheh 1172 Electronics and Informatics Department ETRO/Vrije Universiteit Brussel 1173 Pleinlaan 2, 1050 Elsene, Brussels, Belgium 1174 Tel: +32 2 629 2930 1175 Fax: +32 2 629 2883 1176 Email: ala.hamarsheh@vub.ac.be 1178 Prof. Marnix Goossens 1179 Electronics and Informatics Department ETRO/Vrije Universiteit Brussel 1180 Pleinlaan 2, 1050 Elsene, Brussels, Belgium 1181 Tel: +32 2 629 2987 1182 Fax: +32 2 629 2883 1183 Email: marnix.goossens@vub.ac.be