idnits 2.17.1 draft-vogt-durand-virtual-ip6-connectivity-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5295 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'SIIT' is mentioned on line 582, but not defined ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Christian Vogt 3 Internet-Draft Ericsson 4 Expires: April 29, 2010 Alain Durand 5 Comcast 6 October 26, 2009 8 Virtual IPv6 Connectivity for IPv4-Only Networks 9 draft-vogt-durand-virtual-ip6-connectivity-03 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 29, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 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 in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 Although the impetus to invest in interworking between IP versions 4 58 and 6 is initially on the side of early IPv6 adopters, more 59 substantial IPv6 deployment in the future will shift this impetus 60 towards the side of the legacy IPv4 Internet. However, interworking 61 techniques for IPv4-only networks are as yet largely unexplored. 62 This document proposes Virtual IPv6 Connectivity, a technique for 63 IPv4-only networks to communicate with the IPv6 Internet. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conceptual Overview . . . . . . . . . . . . . . . . . . . . . 4 69 3. Virtual IP Addresses . . . . . . . . . . . . . . . . . . . . . 6 70 4. Discovery of Virtual IP Addresses . . . . . . . . . . . . . . 7 71 5. IP Protocol Translation . . . . . . . . . . . . . . . . . . . 13 72 6. Multi-Homing Support . . . . . . . . . . . . . . . . . . . . . 18 73 7. Side-Effects . . . . . . . . . . . . . . . . . . . . . . . . . 20 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 21 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 Appendix A. Pending Document Changes . . . . . . . . . . . . . . 22 79 Appendix B. Log of Document Changes . . . . . . . . . . . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 82 1. Introduction 84 The deployment of IP version 6 is challenging. Since it requires 85 changes to applications, host stacks, and networks end-to-end, IPv6 86 deployment involves multiple stakeholders. These stakeholders are in 87 general independent and not coordinated, so a simultaneously 88 transition to IPv6 by all stakeholders is practically impossible. It 89 is therefore necessary to enable the stakeholders to deploy IPv6 90 independently of each other. This requires interworking between 91 those stakeholders who have already adopted IPv6, and those 92 stakeholders who have not yet. 94 There are two basic approaches to enable interworking between IP 95 versions: 97 o Make IPv6 backwards compatible with IPv4 99 o Make IPv4 forward compatible with IPv6 101 Which of the approaches is feasible depends on where the impetus on 102 interworking is -- on the side of early IPv6 adopters, or on the side 103 of the legacy IPv4 Internet. This impetus will shift over time. 104 Initially, the impetus for interworking will naturally be high on the 105 side of early IPv6 adopters. Services and peers will at that point 106 almost exclusively be IPv4-only, so IPv6 adopters will have to make 107 sure they can communicate via IPv4. For the same reason, initial 108 incentives to invest in interworking will be very low on the side of 109 the legacy IPv4 Internet: Why would the legacy IPv4 Internet want to 110 communicate via IPv6 if everything they need is available also via 111 IPv4? 113 However, as IPv6 deployment progresses, more and more services and 114 peers will become IPv6-capable. The interworking impetus on the side 115 of IPv6 adopters will therefore shrink. At some point, a critical 116 mass of IPv6 deployment will have been reached to make it feasible 117 for services and peers to be IPv6-only. And as there are more and 118 more IPv6-only services and peers, the impetus for interworking will 119 grow on the side of the legacy IPv4 Internet, so that those IPv6-only 120 services and peers can be reached. 122 Consequently, interworking between IP versions will initially be 123 realized foremost through backwards compatibility of IPv6 with IPv4, 124 but over time increasinly also through forward compatibilility of 125 IPv4 with IPv6. Due to the immediate need for IPv6 backwards 126 compatibility, the Internet Engineering Task Force has made the 127 design of suitable techniques a task of high priority. However, 128 techniques for IPv4 forward compatibility are as yet largely 129 unexplored. 131 This document proposes Virtual IPv6 Connectivity, a technique to make 132 IPv4 forward compatible with IPv6. Virtual IPv6 Connectivity uses IP 133 protocol translators on the border of IPv4-only networks to enable 134 local hosts to communicate with IPv6-only peers on the Internet. It 135 makes IPv4-only hosts reachable by peers on the Internet via "virtual 136 IPv6 addresses", and it makes IPv6-only peers reachable by IPv4-only 137 hosts via "virtual IPv4 addresses". A virtual IPv6 address is 138 statically mapped to each IPv4 address, and made retrievable via the 139 DNS or DNSSEC. A virtual IPv4 address is mapped to a peer's IPv6 140 address dynamically and on demand, and made retrievable via DNS 141 proxies or DNSSEC proxies. The IP protocol translators can 142 alternatively be operated by IPv4-only networks directly, or by 143 providers on behalf of IPv4-only networks. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. Conceptual Overview 151 To enable hosts in an IPv4-only network to communicate with remote 152 IPv6 peers, Virtual IPv6 Connectivity employs four components: 154 o Virtual IPv4 and IPv6 addresses to represent, respectively, the 155 IPv6 addresses of remote peers to local IPv4-only hosts, and the 156 IPv4 addresses of local hosts to remote IPv6 peers. 158 o IP protocol translators, placed on border links of the IPv4-only 159 network, to translate packets exchanged with remote IPv6 peers. 161 o Support in authoritative DNS servers for returning virtual IPv6 162 addresses in place of the IPv4 addresses of local IPv4-only hosts 163 when responding to queries from remote IPv6-only peers. 165 o Support in recursive DNS servers for returning virtual IPv4 166 addresses in place of the IPv6 addresses of remote IPv6-only peers 167 when responding to queries from local IPv4-only hosts. 169 Figure 1 depicts an IPv4-only network that uses Virtual IPv6 170 Connectivity. The network has an IP protocol translator, denoted 171 "xlate" in the figure, on its border link to the IPv6 Internet. The 172 network also has sets of virtual IPv6 and IPv4 addresses, which, in 173 this example, are taken from the IPv6 address prefix 2001:DB8::/96 174 and from the IPv4 address prefix 10.0.0.0/8, respectively. The 175 virtual IPv6 addresses represent the regular IPv4 addresses of the 176 IPv4-only network to remote IPv6-only peers. The virtual IPv4 177 addresses represent the regular IPv6 addresses of remote IPv6-only 178 peers to hosts in the IPv4-only network. Furthermore, the IPv4-only 179 network has authoritative and recursive DNS servers that can return, 180 respectively, virtual IPv4 addresses in place of local IPv4 181 addresses, and virtual IPv4 addresses in place of remote IPv6 182 addresses. 184 virtual IPv6 addresses 185 recursive/authoritative 2001:DB8::/96 186 DNS servers | ( 187 ~~~|~~~~~~~|~~~ | ( 188 ( ['] ['] ) ### ### | ( 189 ( ) ## ## / ( 190 ( v4-only network ) ======== xlate ======== ( v6 Internet 191 ( ) / ## ## ( 192 ( ) | ### ### ( 193 ~~~~~~~~~~~~~~~ | ( 194 | ( 195 virtual IPv4 addresses 196 10.0.0.0/8 198 Figure 1: Conceptual overview of Virtual IPv6 Connectivity 200 Packets exchanged between an IPv4 host and an IPv6 peer are always 201 destined to a virtual IP address, and sourced from a regular IP 202 address, when initially dispatched by the sender. Virtual IP 203 addresses route to an IP protocol translator, which performs three 204 tasks for each received packet exchanged between an IPv4 host and an 205 IPv6 peer: 207 o It maps the IP source and destination addresses in a packet, 208 replacing the virtual IP destination address with the represented 209 regular IP address, and replacing the regular IP source address 210 with the representing virtual IP address. 212 o It uses the Stateless IP/ICMP Translation algorithm [RFC2765] to 213 translate the IP header of the packet into an IP header from the 214 respective other IP version. The new IP header uses the IP source 215 and destination addresses determined in the foregoing mapping. 217 o It forwards the packet towards the new IP destination address. 219 Translated packets are consequently always destined to a regular IP 220 address and sourced from a virtual IP address. 222 The pair of a virtual IP address and the represented regular IP 223 address is called a "mapping". Mappings are used in IP protocol 224 translators and DNS servers as a basis for translating packets 225 between IP versions, and for provisioning virtual IP addresses in the 226 DNS. Mappings between IPv4 addresses and virtual IPv6 addresses are 227 static. Each IPv4 address is mapped to a separate virtual IPv6 228 address by appending it to a 96-bit virtual IPv6 address prefix. 229 This enables stateless, algorithmic mapping in IP protocol 230 translators and authoritative DNS servers. On the other hand, 231 mappings between IPv6 addresses and virtual IPv4 addresses are 232 dynamic and on-demand to enable reuse of virtual IPv4 addresses. 233 This is inevitable because any set of virtual IPv4 addresses is 234 smaller than the global set of regular IPv6 addresses for which 235 mappings are potentially needed. As a consequence, mappings between 236 IPv6 addresses and virtual IPv4 addresses must be statefully 237 maintained by IP protocol translators and recursive DNS servers per 238 communication session. Mapping creation is triggered by a recursive 239 DNS server when receiving a query for an IPv6-only peer's DNS name 240 from an IPv4-only host. The mappings expire when no longer used by a 241 communication session. 243 3. Virtual IP Addresses 245 For the local hosts in an IPv4-only network to communicate with 246 remote IPv6 correspondent hosts, local hosts and remote correspondent 247 hosts must be able to reach their respective peer with an IP version 248 they support: The local hosts must be able to reach the remote 249 correspondent hosts via an IPv4 address, and the remote correspondent 250 hosts must be able to reach the local hosts via an IPv6 address. 251 Virtual IPv6 Connectivity achieves this reachability across IP 252 versions by means of virtual IPv4 and IPv6 addresses, which 253 respectively map onto the regular IPv6 addresses of remote 254 correspondent hosts and the regular IPv4 addresses of local hosts. 256 Virtual IPv6 addresses represent local hosts in an IPv4-only network 257 to remote IPv6 correspondent hosts. They are ordinary, global IPv6 258 addresses, which the IPv4-only network obtains either from its 259 Internet service provider or from an Internet registry. Virtual IPv6 260 addresses are announced externally in the global routing system, but 261 are not used internally within the IPv4-only network. They map one- 262 to-one onto the regular IPv4 addresses in the IPv4-only network, 263 i.e., there is one unique virtual IPv6 address for each regular IPv4 264 address. There are no restrictions as to how to realize this one-to- 265 one mapping. A simple, recommended way is to reserve a 96-bit IPv6 266 address prefix, and to map each regular IPv4 address to the virtual 267 IPv6 address that is defined by attaching the 32 bits of the regular 268 IPv4 address to the 96 bits of the reserved 96-bit IPv6 address 269 prefix. 271 Virtual IPv4 addresses represent remote IPv6 correspondent hosts to 272 local hosts in an IPv4-only network. They are ordinary IPv4 273 addresses that map onto the regular IPv6 addresses of the remote 274 correspondent hosts. Virtual IPv4 addresses are announced internally 275 in the local routing system of an IPv4-only network, but are not used 276 outside the IPv4-only network. Since virtual IPv4 addresses are used 277 only locally within an IPv4-only network, they can be non-global. 278 This makes them re-usable in different IPv4-only networks with 279 Virtual IPv6 Connectivity. As an example, virtual IPv4 addresses 280 could be taken from the private net-10 or 192.168.0.0/16 address 281 spaces [###RFC1918], or from a new IPv4 address block specifically 282 allocated for use in IPv4-only networks with Virtual IPv6 283 Connectivity. 285 Different than mappings between regular IPv4 addresses and virtual 286 IPv6 addresses, mappings between regular IPv6 addresses and virtual 287 IPv4 addresses cannot be one-to-one because the set of regular IPv6 288 addresses that potentially need to be mapped is larger than any pool 289 of virtual IPv4 addresses. Mappings between regular IPv6 addresses 290 and virtual IPv4 addresses may instead change dynamically depending 291 on the set of remote IPv6 correspondent hosts that communicate with 292 an IPv4-only network. Mappings between regular IPv6 addresses and 293 virtual IPv4 addresses are therefore created in an on-demand manner, 294 and they have a lifetime after which they may be replaced. 296 In the example of Figure 1, the IPv4-only network has obtained the 297 96-bit IPv6 address prefix 2001:DB8::/96 for virtual IPv6 addresses, 298 so any IPv4 address a.b.c.d from the IPv4-only network can be mapped 299 one-to-one to a virtual IPv6 address 2001:DB8::a.b.c.d. The IPv4- 300 only network furthermore uses the private net-10 address space, 301 10.0.0.0/8, for virtual IPv4 addresses. So for any remote IPv6 302 correspondent host that communicates with a local host in the IPv4- 303 only network, a virtual IPv4 address is allocated from the 8-bit IPv4 304 address prefix 10.0.0.0/8, and is temporarily mapped to the remote 305 correspondent host's regular IPv6 address. 307 4. Discovery of Virtual IP Addresses 309 Communications between between an IPv4-only host and an IPv6-only 310 peer require that the initiator of a new communication obtains a 311 virtual IP address for its peer: An IPv6-only peer intending to reach 312 an IPv4-only host must obtain a virtual IPv6 address for the IPv4- 313 only host; an IPv4-only host intending to reach an IPv6-only peer 314 must obtain a virtual IPv4 address for the IPv6-only peer. To 315 support the discovery of virtual IP addresses, Virtual IPv6 316 Connectivity makes virtual IPv4 and IPv6 addresses available via the 317 DNS. This section describes the extensions for recursive and 318 authoritative DNS servers in an IPv4-only network that are necessary 319 for this. 321 4.1. Discovery of Virtual IPv6 Addresses 323 For an IPv6-only peer to obtain via the DNS the virtual IPv6 324 addresses of a host in an IPv4-only network, the authoritative DNS 325 servers in the IPv4-only network must provide records of type AAAA 326 containing the host's virtual IPv6 addresses. That is, whenever the 327 DNS resolves a host's DNS name into an IPv4 address of that host, the 328 same DNS name must also resolve to the corresponding virtual IPv6 329 address. The retrieval of virtual IPv6 addresses via DNS then does 330 not differ from the retrieval of regular IPv4 addresses. 332 Furthermore, the virtual IPv6 addresses maintained by an 333 authoritative DNS server for an IPv4-only host should automatically 334 adapt when the host's regular IPv4 addresses change in order to 335 support dynamic DNS updates: Since the mapping between IPv4 addresses 336 and the corresponding virtual IPv6 addresses is static, a change in a 337 host's IPv4 address implies that also a virtual IPv6 address of the 338 host changes. The change of the corresponding type-AAAA record 339 should be pursued by the authoritative DNS server. Hosts cannot be 340 expected to update records of type AAAA because they are generally 341 unaware of their virtual IP addresses. 343 To enable accurate provisioning of virtual IPv6 addresses via the 344 DNS, Virtual IPv6 Connectivity calls for authoritative DNS servers to 345 synthesize type-AAAA records on demand whenever an IPv6 address is 346 being requested by a remote peer. This guarantees that the type-AAAA 347 records in a DNS reply contain exactly those virtual IPv6 addresses 348 that correspond to the IPv4 addresses of the host whoose DNS name is 349 being resolved. 351 IPv6 correspondent authoritative DNS server 352 host in IPv4-only network 353 | | 354 | DNS query: AAAA for host.v4.net? | 355 |-------------------------------------------> | 356 | | 357 | DNS reply: AAAA for host.v4.net | 358 | with 2001:DB8:ABC::a.b.c.d | 359 | <-------------------------------------------| 360 | | 362 Figure 2: Discovery of virtual IPv6 addresses via the DNS 364 Figure 4 shows the resolution of an IPv4-only host's DNS name into a 365 virtual IPv6 address. In this example, the DNS name is 366 "host.v4.net", and it resolves into the regular IPv4 address a.b.c.d. 367 The virtual IPv6 address prefix is 2001:DB8:ABC::/96 in this example, 368 so the host's IPv4 address maps to the virtual IPv6 address 2001:DB8: 369 ABC::a.b.c.d. The message exchange in the figure begins where a 370 remote peer queries an authoritative DNS server in the IPv4-only 371 network for a record of type AAAA associated with DNS name 372 "host.v4.net". The authoritative DNS server replies with a type-AAAA 373 record containing the virtual IPv6 address 2001:DB8:ABC::a.b.c.d. 375 4.2. Discovery of Virtual IPv4 Addresses 377 For an IPv4-only host to obtain via the DNS the virtual IPv4 378 addresses of a remote IPv6-only peer, the DNS must provide records of 379 type A containing the peer's virtual IPv4 addresses. However, 380 different than virtual IPv6 addresses, virtual IPv4 addresses 381 generally cannot be provisioned directly by the DNS server that is 382 authoritative for the corresponding regular IP addresses. A DNS 383 server handing out virtual IPv4 addresses must have an administrative 384 relationship with the IPv4-only network to which the virtual IPv4 385 addresses belong. This relationship generally does not exist for DNS 386 servers authoritative for a remote peer's regular IPv6 addresses. 388 To enable the retrieval of virtual IPv4 addresses via the DNS despite 389 the missing administrative relationship between the authoriative DNS 390 server and the IPv4-only network, Virtual IPv6 Connectivity calls for 391 recursive DNS servers in IPv4-only networks to serve as proxies for 392 the authoritative DNS servers of IPv6-only peers. Thus, when 393 requested by an IPv4-only host to resolve the DNS name of an IPv6- 394 only peer, a recursive DNS server retrieves the peer's regular IPv6 395 addresses, triggers the creation of a mapping for those regular IPv6 396 addresses, and returns the corresponding virtual IPv4 addresses on 397 behalf of the peer's authoritative DNS server. 399 Since mappings between virtual IPv4 addresses and regular IPv6 400 addresses are dynamic, they must be carefully coordinated between IP 401 protocol translators and recursive DNS servers if created during DNS 402 name resolution. Lack of coordination can lead to loss of packets 403 exchanged between IPv4-only hosts and IPv6-only peers due to 404 incorrect translation. To guarantee the coordination of mappings, 405 Virtual IPv6 Connectivity requires all mappings between virtual IPv4 406 addresses and regular IPv6 addresses to be created by IP protocol 407 translators. Accordingly, recursive DNS servers must request a 408 mapping from an IP protocol translator when needed for a peer's 409 regular IPv6 address. Given such a request, an IP protocol 410 translator first checks if a mapping already exists for the peer's 411 regular IPv6 address. If so, the IP protocol translator returns this 412 mapping to the recursive DNS server. If no mapping exists for the 413 peer's regular IPv6 address, the IP protocol translator creates a new 414 mapping, stores the mapping locally for subsequent translation of 415 packets, and returns a copy of the mapping to the requesting 416 recursive DNS server. The recursive DNS server finally generates a 417 DNS reply and removes the mapping afterwards. IP protocol 418 translators maintain pools of virtual IPv4 addresses that are 419 currently not used in a mapping. They use virtual IPv4 addresses 420 from these pools to create new mappings. 422 The reason for requiring IP protocol translators, rather than 423 recursive DNS servers, to be in control of mappings is to spare the 424 overhead of coordinating mappings that are created based on packets 425 received by an IP protocol translator. These mappings are created 426 for the first packet in communication sessions initiated by a remote 427 IPv6-only peer. Having the IP protocol translator create the mapping 428 in those cases removes the need to coordinate the mapping with a 429 recursive DNS server. Coordination between the IP protocol 430 translator and the recursive DNS server is then only necessary for 431 mappings created during DNS name resolution initiated by IPv4-only 432 hosts. 434 The overall operation of a recursive DNS server in an IPv4-only 435 network more specifically proceeds as follows: 437 o Upon receiving a DNS query from a local IPv4-only host for records 438 of type A associated with a peer's DNS name, the recursive DNS 439 server first attempts to retrieve the records of type A directly 440 from the peer's authoritative DNS server. This is the standard 441 operation of a recursive DNS server. 443 o If the recursive DNS server receives a DNS reply with one or more 444 records of type A, it returns the DNS reply unchanged to the 445 resolving IPv4-only host. The peer in this case is reachable via 446 IPv4, and it is not necessary to allocate a virtual IPv4 address 447 for the peer. 449 o If the recursive DNS server fails to receive a DNS reply with a 450 record of type A, the peer cannot be reached at a regular IPv4 451 address. The recursive DNS server in this case attempts to 452 retrieve records of type AAAA associated with the peers's DNS 453 name. 455 o If the recursive DNS server receives a DNS reply with one or more 456 records of type AAAA, the peer can be reached via IPv6. The 457 recursive DNS server in this case requests a mapping for each of 458 the regular IPv6 addresses in those records from the IP protocol 459 translator. It then synthesizes a DNS reply with a record of type 460 A for each virtual IPv4 address in a received mapping, and it 461 returns this DNS reply to the resolving IPv4-only host. The 462 recursive DNS server does not store the mappings received from the 463 IP protocol translator. 465 o If the recursive DNS server fails to receive a DNS reply with 466 records of either type A or type AAAA, it returns an error 467 notification to the resolving IPv4-only host. The peer is in this 468 case unreachable from the IPv4-only host. 470 As an optimization to reduce latency, a recursive DNS server may send 471 DNS queries for type-A and type-AAAA records simultaneously to the 472 DNS server authoritative for the peer. With this optimization, if no 473 type-A records can be retrieved, the latency related to retrieving 474 type-AAAA records can be reduced or eliminated. 476 IP protocol translators remove mappings between virtual IPv4 477 addresses and regular IPv6 addresses that appear to be no longer in 478 use. To keep track of which mappings are in use, IP protocol 479 translators should maintain an expiration timer for each mapping. 480 The expiration timer for a mapping is set at the time the mapping is 481 created. It is reset whenver a mapping for the same regular IPv6 482 address is requested, and whenever the mapping is used to translate a 483 packet. After a mapping's expiration timer has reached zero, the 484 mapping should be removed, and the virtual IPv4 address from the 485 mapping should be returned to the IP protocol translator's pool of 486 unallocated virtual IPv4 addresses. 488 IPv4-only host recursive DNS DNS server 489 | name server authoritative for 490 | | correspondent host 491 | | | 492 | DNS query: | DNS query: | 493 | A for host.v6.net? | A for host.v6.net? | 494 |--------------------> |-----------------------------> | 495 | | | 496 | | DNS reply: | 497 | | no A for host.v6.net | 498 | | <-----------------------------| 499 | | | 500 | | DNS query: | 501 | | AAAA for host.v6.net? | 502 | |-----------------------------> | 503 | | | 504 | | DNS reply: | 505 | | AAAA for host.v6.net | 506 | | is 2001:DB8:BCD::X:Y:Z | 507 | | <-----------------------------| 508 | | | 509 | +----------------------------------+ | 510 | | create mapping state | | 511 | | 2001:DB8:BCD::X:Y:Z <-> 10.u.v.w | | 512 | +----------------------------------+ | 513 | | | 514 | DNS reply: | | 515 | A for host.v6.net | | 516 | is 10.u.v.w | | 517 | <--------------------| | 518 | | | 520 Figure 3: Discovery of virtual IPv4 addresses via the DNS 522 Figure 3 illustrates the operation of a recursive DNS server in an 523 IPv4-only network with Virtual IPv6 Connectivity. The IPv4-only host 524 on the left of the figure queries a recursive DNS server in the 525 middle for records of type A associated with the DNS name of an IPv6- 526 only peer. The DNS name of the peer is "host.v6.net" in this 527 example, and this is associated with a single record of type AAAA for 528 IPv6 address 2001:DB8:BCD::X:Y:Z. Since only IPv4 addresses are of 529 use for the IPv4-only host, the host naturally does not send a DNS 530 query for records of type AAAA. The recursive DNS server first 531 processes the DNS query unchanged, so it tries to retrieve records of 532 type A from the DNS server that is authoritative for the peer, as 533 represented on the right of Figure 3. This fails because the peer 534 does not have an IPv4 address. In a second attempt, the recursive 535 DNS name server queries for records of type AAAA. This is 536 successful; the recursive DNS server receives a record with IPv6 537 address 2001:DB8:BCD::X:Y:Z. The recursive DNS server then obtains 538 from an IP protocol translator in the IPv4-only network a mapping 539 between the regular IPv6 address 2001:DB8:BCD::X:Y:Z and a virtual 540 IPv4 address that routes to this IP protocol translator. In the 541 example of Figure 3, this virtual IPv4 address is 10.u.v.w. The 542 recursive DNS server finally returns a DNS reply to the resolving 543 IPv4-only host that contains a record of type A containing the 544 virtual IPv4 address 10.u.v.w. 546 5. IP Protocol Translation 548 In addition to the mapping between regular IP addresses from one IP 549 version and virtual IP addresses from the respective other IP 550 version, packets exchanged between the local hosts in an IPv4-only 551 network and remote IPv6 correspondent hosts must be converted from 552 IPv4 to IPv6 and vice versa on the border between the IPv4-only 553 network and the IPv6 Internet. For this purpose, IPv4-only networks 554 with Virtual IPv6 Connectivity deploy IP protocol translators on each 555 border link that shall be enabled for communications with remote IPv6 556 correspondent host. An IP protocol translator is a router with the 557 extra capabilities to map between regular and virtual IP addresses, 558 and to convert packets between IPv4 and IPv6 using the appropriate 559 mapping. Figure 1 illustrates an IPv4-only network with one border 560 link, which is endowed with an IP protocol translator to achieve 561 Virtual IPv6 connectivity for the IPv4-only network. 563 Since in general not all packets traversing a border link need to be 564 translated between IPv4 and IPv6, IP protocol translators must have a 565 means to distinguish packets that require translation from packets 566 that can be forwarded without modification. IP protocol translators 567 perform this differentiation based on the packets' IP destination 568 address: Packets destined to a regular IP address do not require 569 translation, whereas packets destined to a virtual IP address do. 570 This rule is independent of whether packets originate within and 571 leave the IPv4-only network, or whether the packets originate outside 572 and enter the IPv4-only network. For packets that are destined to a 573 regular IP address, an IP protocol translator behaves as an ordinary 574 router. For packets that are destined to a virtual IP address, the 575 IP protocol translator performs three tasks: 577 o It maps the IP source and destination addresses in a packet, 578 replacing the virtual IP destination address with the represented 579 regular IP address, and replacing the regular IP source address 580 with the representing virtual IP address. 582 o It uses the Stateless IP/ICMP Translation Algorithm [SIIT] to 583 translate the IP header of the packet into an IP header from the 584 respective other IP version. The new IP header uses the IP source 585 and destination addresses determined in the foregoing mapping. 587 o It forwards the packet towards the new (regular) IP destination 588 address. 590 ### DESCRIBE WHEN TRANSLATOR CREATES MAPPING? ### 592 To ensure that packets pass through an IP protocol translator if 593 exchanged between a host in an IPv4-only network and a remote IPv6 594 correspondent host, the routes towards virtual IPv4 and IPv6 595 addresses must lead to an IP protocol translator. Routes to virtual 596 IPv4 addresses must be available within the IPv4-only network; they 597 lead to the interface of an IP protocol translator that faces the 598 IPv4-only network. Routes to virtual IPv6 addresses must be 599 available in the Internet; they lead to the Internet-facing interface 600 of an IP protocol translator. Thus, when a remote IPv6 correspondent 601 host sends a packet to the virtual IPv6 address of a local host in 602 the IPv4-only network, the packet routes to an IP protocol 603 translator, which translates the packet's virtual IPv6 destination 604 address into the mapped regular IPv4 destination address, and the 605 packet's regular IPv6 source address into a mapped virtual IPv4 606 source address. Vice versa, when the local host in the IPv4-only 607 network sends a packet to a remote IPv6 correspondent host, an IP 608 protocol translator translates the packet's regular IPv4 source 609 address into the mapped virtual IPv6 source address, and the packet's 610 virtual IPv4 destination address into the mapped regular IPv6 611 destination address. Both local host and remote correspondent host 612 therefore use only their respective IP version; the peer's regular IP 613 address from the other IP version is transparent to them. 615 There are different means to provision routes to virtual IP 616 addresses. One is through dynamic route announcements by IP protocol 617 translators. IP protocol translators then announce routes towards 618 virtual IPv6 addresses on their interfaces towards the IPv6 Internet, 619 and routes towards virtual IPv4 addresses on their interfaces towards 620 the IPv4-only network. Static configuration is an alternative for 621 part of the routes. Routes to virtual IPv4 addresses can be 622 statically configured in routers of the IPv4-only network. Routes to 623 virtual IPv6 addresses can be statically configured between the IPv4- 624 only network and its provider, if the IP protocol translators are 625 located on the side of the IP-only network. In the latter case, it 626 is the IPv4-only network's provider that dynamically announces a 627 route to virtual IPv6 addresses towards the Internet. 629 Routes to virtual IP addresses may be aggregated with routes to other 630 IP addresses. For example, the route to virtual IPv4 addresses 631 within an IPv4-only network may be a default route. 633 Figure 4 illustrates the the case where routes to virtual IP 634 addresses are dynamically announced, using the IPv4-only network from 635 Figure 1. 637 announces route to virtual 638 IPv6 address prefix 2001:DB8::/96 639 | ( 640 ~~~~~~~~~~~~~~~ | ( 641 ( ) ### ### | ( 642 ( ) ## ## -----> ( 643 ( v4-only network ) ======== xlate ======== ( v6 Internet 644 ( ) <----- ## ## ( 645 ( ) | ### ### ( 646 ~~~~~~~~~~~~~~~ | ( 647 | ( 648 announces route to virtual 649 IPv4 address prefix 10.0.0.0/8 651 Figure 4: Route announcement for virtual IP addresses 653 Since the explicit routes towards virtual IP addresses ensure that 654 packets are routed via an IP protocol translator if they require 655 translation between IPv4 and IPv6, IPv4-only networks with Virtual 656 IPv6 Connectivity may deploy IP protocol translators on only some, 657 but not all of their border links. This can reduce the expenses for 658 deployment and operation of Virtual IPv6 Connectivity. 660 Since the communication between a host in an IPv4-only network and a 661 remote IPv6 correspondent host would break if the mapping between 662 either host's regular and virtual IP addresses changed throughout the 663 course of the communication, IP protocol translators must ensure that 664 mappings are stable for the duration of the communications in which 665 they are used. This is trivial for the mappings between regular IPv4 666 addresses and virtual IPv6 addresses because these mappings are one- 667 to-one and therefore constant. However, as one-to-one mappings are 668 not possible between the large set of regular IPv6 addresses and the 669 necessarily smaller set of virtual IPv4 addresses, IP protocol 670 translators need state to ensure that these mappings remain constant 671 during the communications in which they are used. An IP protocol 672 translator establishes such state in either of two ways, depending on 673 which way a communication is established: 675 o For communications that are initiated by a local host in an IPv4- 676 only network, mapping state is created at the time the local host 677 retrieves the remote IPv6 correspondent host's virtual IPv4 678 address via the DNS. This ensures that the IP protocol translator 679 can map the virtual IPv4 address in the first packet that the 680 local host sends to the remote correspondent host. Mapping state 681 creation is in this case initiated by a recursive DNS name server 682 from the IPv4-only network. This will be explained further in 683 Section 4. 685 o For communications that are initiated by a remote IPv6 686 correspondent host, the creation of mapping state is postponed to 687 the time the IP protocol translator receives the first packet that 688 the remote correspondent host sends to the local host in the IPv4- 689 only network. It is then the IP protocol translator which 690 initiates mapping state creation. Postponing the creation of 691 mapping state is possible in this case because the remote 692 correspondent host does not use the virtual IPv4 address for which 693 mapping state is created. The postponement then has the advantage 694 that both the creation of mapping state as well as the allocation 695 of a virtual IPv4 address happens only when there is actually a 696 communication using it. 698 The involvement of both IP protocol translators and recursive DNS 699 name servers in the creation of mapping state and in the allocation 700 of virtual IPv4 addresses calls for coordination between IP protocol 701 translators and recursive DNS name servers: IP protocol translators 702 must have relevant mapping state even if the creation of the state 703 was initiated by a recursive DNS name server; and simultaneous 704 allocation of a given virtual IPv4 address by both an IP protocol 705 translator and a recursive DNS name server must be avoided. This 706 document assumes that sufficient coordination is in place between IP 707 protocol translators and recursive DNS name servers. IP protocol 708 translators and recursive DNS name servers may be co-located to 709 simplify their coordination, or they may coordinate by means of a 710 protocol specified outside of this document. It is recommended that 711 the maintenance of virtual IPv4 addresses is with the IP protocol 712 translator to which they route. This accelerates packet forwarding 713 when the creation of mapping state is inititated by an IP protocol 714 translator, and it hence accounts for the commonly stricter delay 715 constraints on packet forwarding in routers compared to those on DNS 716 lookups. 718 IPv4 host IP protocol IPv6 correspondent 719 | translator host 720 | | | 721 | | from 2001:DB8:BCD::X:Y:Z | 722 | | to 2001:DB8:ABC::a.b.c.d | 723 | | <---------------------------------| 724 | | | 725 | +----------------------------------+ | 726 | | create mapping state | | 727 | | 2001:DB8:BCD::X:Y:Z <-> 10.u.v.w | | 728 | +----------------------------------+ | 729 | | | 730 | from 10.u.v.w | | 731 | to a.b.c.d | | 732 | <----------------| | 733 | | | 734 | from a.b.c.d | from 2001:DB8:ABC::a.b.c.d | 735 | to 10.u.v.w | to 2001:DB8:BCD::X:Y:Z | 736 |----------------> |---------------------------------> | 737 | | | 738 | from 10.u.v.w | from 2001:DB8:BCD::X:Y:Z | 739 | to a.b.c.d | to 2001:DB8:ABC::a.b.c.d | 740 | <----------------| <---------------------------------| 741 | | | 743 Figure 5: Mapping state creation and packet translation for a 744 communication initiated by an IPv6 correspondent host 746 Figure 5 illustrates the mapping state creation and the translation 747 of packets between IPv4 and IPv6 for a communication that is 748 initiated by a remote IPv6 correspondent host. The packets are 749 exchanged between a local host in an IPv4-only network on the left, 750 and the remote IPv6 correspondent host on the right. The IPv4-only 751 network uses Virtual IPv6 Connectivity, so the packets traverse an IP 752 protocol translator. Continuing from previous examples, virtual IPv6 753 addresses are taken from the IPv6 address prefix 2001::DB8:ABC::/96, 754 and virtual IPv4 addresses are taken from the private net-10 address 755 space, 10.0.0.0/8. The local host's regular IPv4 address, a.b.c.d, 756 maps to the virtual IPv6 address 2001:DB8:ABC::a.b.c.d. This mapping 757 is constant. The remote correspondent host's regular IPv6 address, 758 2001:DB8:BCD::X:Y:Z, maps to the virtual IPv4 address 10.u.v.w. This 759 mapping is temporary and created in on-demand manner. The dynamic 760 state for the mapping between the regular IPv6 address 2001:DB8:BCD:: 761 X:Y:Z and the virtual IPv4 address 10.u.v.w is created when the first 762 packet in the communication reaches the IP protocol translator. Once 763 the state is created, subsequent packets from the same communication 764 can be translated from IPv6 to IPv4 and vice versa, as shown in the 765 figure. 767 6. Multi-Homing Support 769 A technique for networks to increase the performance and reliability 770 of their Internet connectivity is to establish multiple border links 771 to either the same or different providers. This technique is called 772 "multi-homing". To combine multi-homing with Virtual IPv6 773 Connectivity, an IPv4-only network must ensure that packets exchanged 774 between local IPv4 hosts and remote IPv6 correspondent hosts pass 775 through an IP protocol translator that is aware of the mappings for 776 the virtual IP addresses used in the packets. This can be achieved 777 in one of the following two ways: 779 o Shared virtual IP addresses -- A route to a virtual IPv4 or IPv6 780 address originates at all IP protocol translators, and all IP 781 protocol translators can handle the mapping for all virtual IP 782 addresses. This requires synchronization of mapping state across 783 IP protocol translators. 785 o Unshared virtual IP addresses -- A route to each virtual IPv4 or 786 IPv6 address originates at exactly one IP protocol translator, and 787 only that IP protocol translator can handle the mapping for the 788 virtual IP address. It is then sufficient to maintain mapping 789 state for a given virtual IPv4 address in only one IP protocol 790 translator. 792 Sharing virtual IP addresses across multiple IP protocol translators 793 provides a basis for automated fail-over and dynamic load balancing 794 between border links. Fail-over from a failing IP protocol 795 translator to a backup happens automatically due to the redundancy of 796 routes for a given virtual IP address. Dynamic load balancing can be 797 achieved if the routes to virtual IP addresses are dynamically 798 announced. Virtual IP addresses can then be dynamically divided 799 across available IP protocol translators. On the other hand, shared 800 virtual IP addresses require IP protocol translators to map the 801 complete set of virtual IP addresses in a consistent manner. This 802 implies two costs: First, it involves more mapping state for each IP 803 protocol translator, since mappings must be stored even when unused. 804 Second, it necessitates synchronization between IP protocol 805 translators to ensure mapping consistency. Whereas the mapping 806 consistency for virtual IPv6 addresses can be guaranteed by pre- 807 configuration due to the staticness of these mappings, mappings for 808 virtual IPv4 addresses are dynamic and must hence be synchronized 809 across IP protocol translators. 811 Synchronization of mapping state for virtual IPv4 addresses may be 812 proactive or on-demand. Proactive synchronization ensures that IP 813 protocol translators have a consistent view of all mappings at any 814 time. This requires immediate mapping updates whenever a new mapping 815 is created. On-demand synchronization enables IP protocol 816 translators to retrieve any missing mapping they may need to process 817 a packet. The mappings of virtual IPv4 addresses may then be 818 centrally maintained in a single database that IP protocol 819 translators can query when needed. 821 Unshared virtual IP addresses can be used without synchronization 822 between IP protocol translators. It is instead sufficient to ensure 823 that the virtual IPv4 and IPv6 addresses that are used in the 824 mappings for a particular communication belong to partitions from the 825 same IP protocol translator. The disjoint route announcements of the 826 IP protocol translators then ensure that packets exchanged between 827 IPv4 and IPv6 hosts always route to the IP protocol translator that 828 can map the IP addresses in the packets. A disadvantage of 829 partitioned virtual IP addresses is that active communications cannot 830 be switched to a different IP protocol translator for the purpose of 831 fail-over or load balancing because they are bound to a route via a 832 particular IP protocol translator. 834 Although active communications cannot be switched between IP protocol 835 translators, communications that are newly established should be able 836 to go via any IP protocol translator of an IPv4-only network. The 837 partitioning of virtual IPv4 addresses does not prevent this: Since 838 the mappings for virtual IPv4 addresses are dynamically created, they 839 can be created with a virtual IPv4 address that routes to a preferred 840 IP protocol translator. However, the mappings for virtual IPv6 841 addresses cannot reflect a current preference for a specific IP 842 protocol translator because those mappings are constant. So to 843 enable the establishment of a new communication via any IP protocol 844 translator, each regular IPv4 address of a host within the IPv4-only 845 network must be mapped to multiple virtual IPv6 addresses, one for 846 each IP protocol translator. 848 The decision of whether to use shared vs. partitioned virtual IP 849 addresses may have an impact on whether a multi-homed IPv4 network 850 can use virtual IPv6 addresses that have been allocated to its 851 provider: If the border links of the multi-homed IPv4 network connect 852 to different providers, virtual IPv6 addresses must be provider- 853 independent in order to be shared across IP protocol translators. 854 This may cause additional load for the global routing system because 855 routes towards the virtual IPv6 addresses could not be announced in 856 aggregated manner. It is therefore recommended that multi-homed IPv4 857 networks with border links to multiple providers use virtual IPv6 858 addresses that are provider-allocated, and hence by necessity 859 partitioned virtual IP addresses. 861 7. Side-Effects 863 The translation of IP addresses in the network without explicit 864 coordination with applications and host stacks inevitably leads to 865 side-effects. The following explains the side-effects of Virtual 866 IPv6 Connectivity, and shows why those are unavoidable given the 867 objectives for which Virtual IPv6 Connectivity was designed. 869 The side-effects of Virtual IPv6 Connectivity are three-fold: 871 o It may interfere with applications that expect addresses not to 872 change in packets en route. 874 o It may cause the establishment of new communication sessions to 875 fail due to the unavailability or staleness of a virtual IPv4 876 address. 878 o It requires the use of a recursive DNS server for name resolution 879 by IPv4-only hosts. 881 Interferences may affect applications that use address referrals 882 inside packet payloads. Since the translation between IPv4 and IPv6 883 addresses affects only the IP headers in packets, but no address 884 referrals inside packet payloads, addresses referenced in packet 885 payloads may become unreachable when a packet traverses an address 886 translator. Special support, either in the applications themselves 887 or in the address translator, can mitigate the problem. But such 888 special support cannot be guaranteed for every application. 890 Unavailability of virtual IPv4 addresses may cause the establishment 891 of new communication sessions to fail if a large number of IPv6-only 892 hosts communicate with an IPv4-only network. In such a case, the 893 pool of virtual IPv4 addresses may temporarily be exhausted. 894 Staleness of virtual IPv4 addresses can cause session establishment 895 failures if an application uses a virtual IPv4 address a long time 896 after it was mapped to the corresponding regular IPv6 address. The 897 virtual IPv4 address may at that point have been mapped to a 898 different regular IPv6 address, as mappings between regular IPv6 899 addresses and virtual IPv4 addresses are dynamic. 901 The need for recursive DNS servers in IPv4-only networks precludes 902 direct resolution of DNS names by hosts, and requires configuration 903 of hosts in IPv4-only networks with a recursive DNS server. While 904 this requirement is often negligible due to the widespread use of 905 recursive DNS servers, preventing direct DNS name resolution 906 altogether is typically difficult. 908 All of these side-effects are unavoidable, since they are a 909 consequence of the objectives for which Virtual IPv6 Connectivity was 910 designed, that is, to enable bilateral communications between IPv4- 911 only hosts and IPv6-only peers with upgrades only to IPv4-only 912 networks: 914 o The objective to upgrade only IPv4-only networks requires that 915 addresses are translated, in the network, without explicit 916 coordination with host stacks and applications. This may cause 917 interference with applications that expect addresses not to change 918 in packets en route. 920 o The objective to enable bilateral communications between IPv4-only 921 hosts and IPv6-only peers requires that IPv6-only peers must be 922 represented to IPv4-only hosts via virtual IPv4 addresses. The 923 mappings between regular IPv6 addresses and virtual IPv4 addresses 924 must be dynamic, since no set of IPv4 addresses can be large 925 enough to provide for static virtual IPv4 addresses for all 926 potential IPv6-only peers. This may cause the establishment of 927 new communication sessions to fail due to the unavailability or 928 staleness of a virtual IPv4 address. 930 o The need to translate addresses without explicit coordination with 931 host stacks and applications calls for the use of recursive DNS 932 servers by IPv4-only hosts, in order to handle the translation of 933 DNS messages from regular IPv6 addresses to virtual IPv4 934 addresses. Even though it would be possible to translate DNS 935 messages without recursive DNS server, doing so would defeat the 936 use of DNS security extensions. 938 8. Security Considerations 940 No security considerations yet; to be written down. 942 9. IANA Considerations 944 This document has no actions for IANA. 946 10. Acknowledgment 948 Many ideas in Virtual IPv6 Connectivity were originally proposed in 949 2002 by Alain Durand [draft-durand-ngtrans-nat64-nat46]. 951 The authors would like to thank Edward Jankiewicz, Dave Thaler, and 952 Brian Carpenter for their reviews of this document and their valuable 953 comments. 955 This document was generated using the xml2rfc tool. 957 11. References 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", BCP 14, RFC 2119, March 1997. 962 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 963 (SIIT)", RFC 2765, February 2000. 965 Appendix A. Pending Document Changes 967 This section identifies pending document changes, proposed by a 968 reviewer or author, that have not been addressed so far. 970 o Describe the extent to which Virtual IPv6 Connectivity supports 971 DNSSEC, and explain how DNSSEC can be put to use. (Comment from 972 Brian Carpenter.) 974 o Describe how reverse DNS lookups function for virtual IP 975 addresses. (Comment from Brian Carpenter.) 977 o Integrate support for IPv4/IPv4 address translation for 978 communication sessions with IPv4 peers? (Comment from Edward 979 Jankiewicz. Needs working group feedback.) 981 Appendix B. Log of Document Changes 983 The following is a list of technical changes that were made from 984 version 00 to version 01 of the document. Editorial revisions are 985 not explicitly mentioned. Part of the technical and editorial 986 document changes address review comments received from Dave Thaler. 988 o Revised abstract and introduction to emphasize that the impetus to 989 invest in IPv4/IPv6 interworking will shift towards the legacy 990 IPv4 Internet as IPv6 becomes more deployed. 992 o Clarified that virtual IP address prefixes used in figures and 993 examples throughout the document are not mandatory. Which 994 prefixes are used is up to the network operator/administrator 995 deploying Virtual IPv6 Connectivity. 997 o Clarified in which situations an a-priori DNS name resolution is 998 needed to initiate a new communication session. 1000 o Elaborated on how routes towards virtual IP addresses can be 1001 established. Besides announcement of these routes by IP address 1002 translators, the document now also mentiones static configuration, 1003 and aggregation of the routes within a default route. 1005 o Highlighted the importance of coordination between IP protocol 1006 translators and recursive DNS servers. Still need to specify such 1007 coordination in more detail. 1009 o Explained how dynamic DNS updates work. This required a 1010 clarification of how authoritative DNS servers generate type-AAAA 1011 records for virtual IPv6 addresses. 1013 o Elaborated on the pros and cons of the two multi-homing techniques 1014 described in section 6, "Multi-Homing". Section 6 still requires 1015 more work. 1017 The following is a list of technical changes that were made from 1018 version 01 to version 02 of the document. Editorial revisions are 1019 not explicitly mentioned. Part of the technical and editorial 1020 document changes address review comments received from Edward 1021 Jankiewicz. 1023 o Revised the conceptual overview. 1025 o Swapped the order of sections 4 and 5, "IP Protocol Translation" 1026 and "Discovery of Virtual IP Addresses", respectively. The reason 1027 for originally having the former section first was that it 1028 included information about address mappings that was useful for 1029 the latter section. However, the comment that the new order is 1030 easier to follow for the reader is a good one. 1032 o Revised sections 4 and 5, "IP Protocol Translation" and "Discovery 1033 of Virtual IP Addresses", to accommodate the change of order of 1034 these sections (see previous bullet). 1036 o Clarified that address mappings are maintained by IP protocol 1037 translators, not by recursive DNS servers. Recursive DNS servers 1038 may only trigger the creation of a new address mapping during DNS 1039 name resolution. Elaborated further on the coordination between 1040 IP protocol translators and recursive DNS servers. 1042 o Included a note that the attempts to retrieve regular IPv4 and 1043 IPv6 addresses by a recursive DNS server could be initiated 1044 simultaneously to reduce latency. 1046 o Elaborated on the mapping management for the case when two IPv4- 1047 only hosts want to communicate with the same remote IPv6-only 1048 peer. In this case, the same mapping should be used for both 1049 communication sessions to reduce the number of virtual IPv4 1050 addresses needed. 1052 o Further review comments on abstract and introduction were already 1053 addressed by the document revision from version 00 to version 01. 1055 Authors' Addresses 1057 Christian Vogt 1058 Ericsson Research, NomadicLab 1059 Hirsalantie 11 1060 02420 Jorvas 1061 Finland 1063 Email: christian.vogt@ericsson.com 1065 Alain Durand 1066 Comcast 1067 1500 Market Street 1068 Philadelphia, PA 19102 1069 USA 1071 Email: alain_durand@cable.comcast.com