idnits 2.17.1 draft-baker-behave-ivi-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 849. 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 draft header indicates that this document updates RFC2765, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2766, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC2765, updated by this document, for RFC5378 checks: 2000-02-01) (Using the creation date from RFC2766, updated by this document, for RFC5378 checks: 1997-12-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 16, 2008) is 5699 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) == Outdated reference: A later version (-03) exists of draft-bagnulo-behave-nat64-00 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave X. Li 3 Internet-Draft C. Bao 4 Updates: 2765, 2766 CERNET Center/Tsinghua University 5 (if approved) F. Baker 6 Intended status: Standards Track K. Yin 7 Expires: March 20, 2009 Cisco Systems 8 September 16, 2008 10 IVI Update to SIIT and NAT-PT 11 draft-baker-behave-ivi-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 20, 2009. 38 Abstract 40 This note proposes an address and service architecture designed to 41 facilitate transition from an IPv4 Internet to an IPv6 Internet. 42 This service contains three parts: A DNS Application Layer Gateway, a 43 stateful Network Address Translator that enables IPv6 clients to 44 initiate connections to IPv4 servers and peers, and a stateless 45 Network Address Translator that enables IPv4 and IPv6 systems to 46 interoperate freely. 48 It is couched as an update to RFCs 2765 and 2766. This is because 49 the stateless service is essentially the SIIT with a different 50 address format, and because the DNS Application Layer Gateway and the 51 stateful translator have significant similarities to NAT-PT. There 52 are, however, important differences from NAT-PT, responsive to the 53 issues raised in RFC 4966. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The IVI model . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. IVI Network Model and communication objectives . . . . . . 4 60 2.2. IVI Address Format . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Routing in IVI networks . . . . . . . . . . . . . . . . . 6 62 2.4. DNS service in IVI networks . . . . . . . . . . . . . . . 8 63 2.5. Host operation in IVI networks . . . . . . . . . . . . . . 9 64 2.5.1. Interaction of IVI Addresses with RFC3484 Address 65 Selection . . . . . . . . . . . . . . . . . . . . . . 9 66 2.5.2. Interaction of IPv4 and IVI addresses on the same 67 host . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 2.6. Operation of the IVI Gateway . . . . . . . . . . . . . . . 11 69 2.6.1. Stateless (1:1) Operation . . . . . . . . . . . . . . 12 70 2.6.2. Stateful (1:n) Operation . . . . . . . . . . . . . . . 12 71 3. Transition plan . . . . . . . . . . . . . . . . . . . . . . . 12 72 3.1. IPv4-only Network . . . . . . . . . . . . . . . . . . . . 13 73 3.2. IPv4+IPv6 Dual Stack Network . . . . . . . . . . . . . . . 13 74 3.3. IPv6+IPv4-accessible Network . . . . . . . . . . . . . . . 13 75 3.4. IPv6 Network . . . . . . . . . . . . . . . . . . . . . . . 14 76 4. Future extensions of the IVI Model . . . . . . . . . . . . . . 14 77 5. Reflections on RFC 4966 . . . . . . . . . . . . . . . . . . . 14 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 Intellectual Property and Copyright Statements . . . . . . . . . . 19 87 1. Introduction 89 This note documents the prototype being used for translation between 90 the IPv4 CERNET and the IPv6 CNGI-CERNET2 networks. This uses the 91 algorithms of SIIT [RFC2765] with a modified address format, and a 92 modified version of NAT-PT [RFC2766]. In general, we recommend the 93 use of native communication and dual stack deployment. However, in 94 several scenarios, the temporary use of translation can simplify 95 service deployment. Hence, we describe a translation function. 97 It should be understood that protocol translation in any form is not 98 a viable long term solution for IPv6 deployment; it has value during 99 a certain part of the adoption curve, but will become less relevant 100 at later points in the adoption curve. The objective of any 101 transition strategy, of which IVI is an example, is to facilitate 102 transition, not to enter a phase of heightened operational and 103 capital expenditure running two networks in parallel only to stay 104 there. When IPv6 is widely deployed and economic conditions support 105 the move, we expect service providers to withdraw IPv4 service. 107 The objectives of the translation function are to enable systems that 108 are unable to communicate with each other due to routing, 109 implementation, or parameter differences to communicate. Almost any 110 translation function will connect IPv6 systems with IPv4 systems or 111 systems in an IPv4 network. The difficulty is that this gives no 112 incentive to administrations to move their servers and peers from the 113 IPv4 domain to the IPv6 domain. Noting that dual stack 114 implementations such as recommended in [RFC4213] are not being widely 115 deployed by operators, the IVI model is designed to facilitate 116 placing servers and peers in the IPv6 domain, achieving native IPv6 117 connectivity without giving up IPv4 accessibility. 119 More specifically, the objectives are several: 121 o As with any network, IPv4 systems connected by an IPv4 network can 122 talk among themselves and IPv6 systems connected by an IPv6 123 network can talk among themselves. The first objective is to 124 preserve this and its scaling characteristics. 126 o If one or both domains are IPv4+IPv6 but there exist systems with 127 only one architecture, we presume that IPv4 and IPv6 routing 128 crosses the gateway or a parallel router, and the systems are able 129 to communicate directly. 131 o We want to enable systems that have no IPv6 address to access 132 servers and peers with IPv4-derived IPv6 addresses (IVI addresses) 133 in the IPv6 domain. This requires translation similar to that 134 described in SIIT [RFC2765]. This operation is stateless. 136 o We want to enable systems that have no IPv4 address to access 137 servers and peers in the IPv4 domain. For systems with IPv4- 138 derived IPv6 addresses (IVI addresses), this is solved by the SIIT 139 extension described in this document, given the appropriate AAAA 140 record by IVI DNS ALG. This operation is also stateless. Other 141 systems with non-IVI IPv6 addresses require some form of stateful 142 translation. This has similarities to the mechanisms described in 143 NAT-PT [RFC2766]. We wish to do this with a minimum of maintained 144 state. 146 Some have questioned the need for IPv4 access to IPv6-only servers 147 and peers, noting that in the Internet of 2008 there is no market 148 requirement for such access and any server or peer will require 149 accessibility from an IPv4 network. The issue is that this presumes 150 a certain point in the adoption curve; at another point in the 151 adoption curve, one hopes that there will be few takers for IPv4-only 152 service. In between, before IPv6 service for a server or peer 153 becomes a requirement, IPv6-only service for a server or peer must be 154 feasible (it must be conceivable that a server or peer with an IPv6 155 address will be useful). We argue that it is easier for IPv6 service 156 for a server or peer to become feasible if it is possible to 157 configure it with an IPv4-derived IPv6 address than if it must also 158 have IPv4 service. In the long term, we believe that translation is 159 not a service that service providers will normally use, but is a 160 helpful and perhaps necessary step in transitioning to an IPv6 world. 162 2. The IVI model 164 The Name "IVI" contracts "IV<->VI"; we are describing a translation 165 connection between systems using IPv4 or IPv6 that cannot communicate 166 using either IPv4 or IPv6. In any normal case where native 167 communication is possible between two systems, we argue that it is 168 preferable. 170 2.1. IVI Network Model and communication objectives 172 An IVI Network, as shown in Figure 1, consists of two or more network 173 domains connected by one or more IVI gateways. One of those networks 174 either routes IPv4 but not IPv6, or contains some hosts that only 175 implement IPv4. The other network either routes IPv6 but not IPv4, 176 or contains some hosts that only implement IPv6. Both networks 177 contain clients, servers, and peers. It would be advisable and 178 preferable to implement a dual stack architecture in both domains, 179 but either due to address scarcity or the process involved in IPv6 180 turn-up, that is not practical at the moment. 182 ----------- ----------- 183 /// IPv4 \\\ /// IPv6 \\\ 184 // Network \\ // Network \\ 185 / \ / +-----+\ 186 | | | |IPv6 | | 187 | +---------+ +-----+ | 188 | | IVI | | 189 | | Gateway | +-----+ | 190 | +-----+ +---------+ |IPv6/| | 191 | |IPv4 | | | | IVI | | 192 \ +-----+ / \ +-----+/ 193 \\ // \\ // 194 \\\ /// \\\ /// 195 ----------- ----------- 197 Figure 1: IVI Network Model 199 Clearly, there are issues in IP addressing, and routing, DNS, and the 200 specifics of translation. 202 2.2. IVI Address Format 204 The IVI Address is an IPv4 address embedded in an IPv6 address and 205 predictable by the gateway and systems on either side. The selection 206 of the LIR prefix, including its length and absolute value, is at the 207 option of the network administration; it is not fixed. Figure 2 208 shows one possible model. It enables the IPv6 domain to assign the 209 equivalent of IPv4 /24 prefixes to IPv6 LANs (/64). 211 IPv4 /24 routes in IPv6 domain 212 0 8 16 24 32 40 48 56 64 127 213 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 214 | LIR Prefix | IPv4 addr | entirely 0 | 215 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 216 |<-----prefix part ---->|<--- host part --->| 218 Figure 2: Example IVI Address Format 220 In the IPv4 domain, this represents a prefix no longer than /24. In 221 the IPv6 domain, the "default route" advertising the entire IPv4 222 address space is the LIR /40 prefix. More specific prefixes up to 223 /64 may be advertised as needed, or host (/128) routes. 225 The objective here is to enable the network administration to be in 226 control of the impact of the tradeoff on its routing. 228 The need to change the address format used by SIIT bears repetition, 229 although it has come up in other discussions. [RFC4291] deprecated 230 the address format with the brusque comment that "current IPv6 231 transition mechanisms no longer use these addresses." The reason 232 that they were not widely deployed was that they gave network 233 operators little control in routing, or ways to ensure that route 234 redistribution worked correctly. A prefix that lets the LIR specify 235 the upper bits gives the operator the flexibility to identify the IVI 236 gateway advertising the prefix and better control the distribution of 237 routes. 239 2.3. Routing in IVI networks 241 The IVI Gateway may be a general purpose router; in that mode, it 242 operates like any other router. However, it also advertises one or 243 more prefixes into both the IPv4 and the IPv6 domain, and when a 244 datagram is directed to an address within the translation prefix(es), 245 it translates the datagram. 247 As a Network Address Translator, the IVI Gateway offers one or both 248 of two services: stateless translation of addresses conforming to 249 Figure 2 to and from IPv4 addresses, and stateful translation between 250 IPv6 addressing and a combination of an IPv4 address and transport 251 source port as is done in normal NATs. 253 In IPv4, the IVI gateway advertises the IPv4 prefix being used for 254 stateless IVI address translation; for example, if an IPv4 /20 is 255 being used as a set of /24 prefixes in the IPv6 domain, it would 256 advertise a /20 into the IPv4 domain. If the IVI gateway is offering 257 stateful translation, it may also advertise the addresses or prefix 258 being used for that service unless another router handles this. 260 In IPv6, the IVI gateway advertises a "default route for global IPv4" 261 - in the example given in Figure 2, it would normally advertise the 262 /40 LIR prefix. If that is inappropriate - there are multiple non- 263 overlapping IPv4 domains or other concerns apply - it would advertise 264 "more-specific" prefixes as appropriate. 266 In the IPv6 domain, the routers or hosts that have been assigned IVI 267 prefixes or addresses subsidiary to the IVI prefix for a service 268 advertise the IVI /64s corresponding to those IPv4 /24s. 270 Clearly, there may be multiple non-overlapping IPv4 domains, multiple 271 non-overlapping IPv6 domains, and there may be multiple IVI gateways. 272 These are handled in a manner consistent with normal routing practice 273 in the Internet. 275 As shown in Figure 3, routing is slightly more complex in an IVI 276 service, but follows simple routing concepts. In this example, 277 o IPv4 interfaces can open a session to any IVI address (e.g. 4Host1 278 -> IVI1), 280 o IPv4 interfaces cannot open sessions to non-IVI IPv6 addresses 281 (e.g. 4Host1 X-> 6Host1), 283 o IPv6 IVI interfaces can open a session to any IPv4 interface, 284 statelessly (e.g. IVI1 -> 4Host1), 286 o Non-IVI IPv6 hosts can open sessions to IPv4 interfaces, 287 statefully (e.g. 6Host1 -> 4Host1), 289 o Any two IPv4 hosts can open a session to either each other using 290 native routing (e.g. 4Host1 -> 4Host2, 4Host2 -> 4Host1), 292 o Any two IPv6 hosts can open a session to either each other using 293 native routing, even using the IVI addresses (e.g. 6Host1 -> IVI1, 294 IVI1 -> 6Host1, 6Host1 -> 6Host2, IVI1 -> IVI2). 296 ------------- ------------ 297 / IPv4 Domain \ / IPv6 Domain \ 298 / \ / \ 299 / | \ / | +----+ \ 300 /+------+ | \ / |-|IVI1| \ 301 / |4Host1|-| +--+ | \ / | +--+ | +----+ \ 302 / +------+ |-|R1|-| V |-|R3|-| +------+ \ 303 | | +--+ | | | +--+ |-|6Host1| | 304 | | +-----+ | | +------+ | 305 | |-|XLATE|-| | 306 | | +-----+ | | 307 | | +--+ | | | +--+ | +------+ | 308 | +------+ |-|R2|-| | |-|R4|-|-|6Host2| | 309 \ |4Host2|-| +--+ | A | +--+ | +------+ / 310 \ +------+ | / \ | +----+ / 311 \ | / \ |-|IVI2| / 312 \ / \ | +----+ / 313 \ / \ / 314 --------------- --------------- 315 Route Advertisements: 316 R1: its IPv4 LAN R3: its IPv6 LAN 317 R2: its IPv4 LAN R3: its IVI /64 318 XLATE: IPv4 IVI prefix R4: its IPv6 LAN 319 possible IPv4 overlay R4: its IVI /64 320 prefix XLATE: IVI /40 322 Figure 3: IVI Reachability example 324 2.4. DNS service in IVI networks 326 Rather than using the DNS Application Layer Gateway described in 327 [RFC2766] as specified, the IVI DNS ALG is a one-way translation of A 328 and MX records to AAAA records with a predictable address. The DNS 329 server may be in the gateway or in a separate system related to it. 331 As illustrated in Figure 4, in the IPv4 domain, the DNS server holds 332 and advertises A records for systems with IPv4 addresses and for 333 systems (servers or peers) that have IVI addresses. These are 334 generally pre-populated, if only via Dynamic DNS. The IPv4 network 335 cannot distinguish them from other A records or from other IPv4 336 addresses, so this works without host changes. 337 IPv4 Domain IPv6 Domain 338 | | 339 A/MX Request\ | | / AAAA Request 340 \ | DNS ALG | / 341 \| as |/ 342 /| Standard |\ 343 / | DNS | \ 344 A/MX Response/ | Service | \ AAAA Response 345 | | 346 | | 348 Figure 4: Normal DNS Service 350 Also as illustrated in Figure 4, in the IPv6 domain, the DNS server 351 holds and advertises AAAA records in the usual fashion for systems 352 with general IPv6 addresses. 354 As illustrated in Figure 5, in the IPv6 domain, when the DNS ALG 355 receives a request for a AAAA record for which it has nothing to 356 reply, or for which normal DNS processing receives a failure, it 357 obtains an A or MX record from its own database or another server, 358 manufactures a corresponding AAAA record using an IVI address, and 359 returns that. The IPv6 network cannot distinguish between these and 360 other AAAA records, or between these and any other address. Routing 361 takes traffic through the gateway without host changes. 363 IPv4 Domain IPv6 Domain 364 | | 365 | | AAAA Request 366 | |<--------- 367 | | 368 A/MX Request | | 369 <-------------| DNS ALG | 370 | as IPv4 | 371 | to IPv6 | 372 ------------->| translator | 373 A/MX Response | | 374 | | 375 | |---------> 376 | | AAAA Response 377 | | 378 | | 380 Figure 5: DNS Record Translation Service 382 To avoid conflicts, the DNS server should have access to all AAAA 383 records advertised in the IPv6 domain. Otherwise, it may not know 384 when to create AAAA records from A or MX records. 386 An issue arises with Dynamic DNS, in that the IVI host will only know 387 to post its IPv6 addresses. The DNS service should store the AAAA 388 records as generated by the host, and also generate an A record for 389 each IVI address posted. Whether the IVI address itself is stored as 390 a AAAA record as well as in an A record is at the implementer's 391 option; if it is not stored it will be created from the A record if 392 needed. 394 2.5. Host operation in IVI networks 396 Host behavior is unchanged by this specification. However, the local 397 administration might want to configure host [RFC3484] address 398 selection tables to optimize session behavior. 400 2.5.1. Interaction of IVI Addresses with RFC3484 Address Selection 402 [RFC3484] could be summarized as saying that IPv6 systems should 403 select source and destination addresses that are as similar as 404 possible. "Similarity" is defined in terms of prefix length. Each 405 remote address is compared to each local address, and the remote 406 address is considered to be most similar to the local address with 407 the longest string of equivalent prefix bits. The specification 408 recommends that sessions between the two systems should prefer the 409 address pair with the longest "similar" prefix. 411 For example, if Alice has the addresses 413 o 2001:db8:1234:1::A and 415 o 2001:db8:5678::A, 417 and Bob has the following addresses 419 o 2001:db8:1234:2::B and 421 o 2001:db8:5ABC:B, 423 2001:db8:1234:1::A is more similar to 2001:db8:1234:2::B (the first 424 48 bits are the same as opposed to only the first 33) and 2001:db8: 425 5678::A is more similar to 2001:db8:5ABC:B (the first 36 bits are the 426 same as opposed to the first 33). When Alice and Bob communicate, 427 the default address policy selects the address pair in 2001:db8: 428 1234::/48 over 2001:db8:5000::/36 because it has a longer "similar" 429 prefix. 431 IPv4-only systems connect to IPv6 systems having IVI addresses 432 through the gateway, and lack a means to initiate a connection to 433 other IPv6 systems. Since IPv4 addresses appear in the IPv6 domain 434 as IVI addresses, [RFC3484] will guide IPv6-only systems with IVI 435 addresses to connect from their IVI address when communicating with 436 IPv4-only systems, as they are the "most similar" addresses to those 437 of their IPv4 counterparts. This is important, because it promotes 438 stateless translation operation. 440 IVI systems may also find the IVI address pair "most similar" when 441 communicating with other systems with IVI addresses. This is 442 acceptable, as to the IPv6 domain they are simply IPv6 addresses and 443 will communicate directly. 445 In general, a system with both an IPv4 address and an IPv6 address 446 can connect to a similar system using either technology. There need 447 be no preference order, and if one is chosen that is a local matter. 449 2.5.2. Interaction of IPv4 and IVI addresses on the same host 451 Systems that have both native IPv4 and translated IVI addresses 452 require attention to the configuration of the address choice 453 mechanism described in [RFC3484]. In such a case, the redundancy 454 suggests different uses for those addresses and the possibility that 455 IPv4 reachability has been fragmented. 457 For example, consider a host with a private IPv4 address and an IVI 458 address attempting to open a session with an IPv4 system with a 459 public address. Apart from actually successfully opening a session, 460 the addresses give no clue to actual reachability; the remote host 461 might be reachable via IPv4, or that might be a private network 462 disconnected from the Internet. If the remote host is reachable, 463 there is likely to be a NAT between the host and that system, making 464 the point moot. Similarly, the remote host might be reachable via 465 IVI, but it might not. It might be reachable via both 466 simultaneously, and it might not be reachable at all. 468 In general, native operation should be preferred to translated 469 operation, but the specifics of the environment may guide this choice 470 otherwise. As such, if an application is unable to open a session 471 using one address, it should try another, and the local 472 administration may consider configuring the [RFC3484] tables to 473 manage the case. 475 2.6. Operation of the IVI Gateway 477 The IVI Gateway has two modes, depending on the address of the IPv6 478 system using its services. These are the Stateless Mode, used to 479 connect between IPv6-only systems with IVI addresses and IPv4 480 systems, and the Stateful Mode, used to connect other (non-IVI) IPv6- 481 only systems with IPv4 systems. IPv6 routing should not take traffic 482 between IPv6 systems in the same IPv6 domain through the gateway, as 483 it will follow more specific routes. 485 In either mode, the gateway is subject to the usual ills of Network 486 Address Translation. Protocols that exchange IP addresses should in 487 general not be exchanged across an IVI gateway, as the addresses are 488 not necessarily translatable or meaningful after translation. Also, 489 IPsec AH is compromised, so end-to-end privacy and authentication 490 issues should be dealt with in another way such as IPsec ESP. 492 In general, native (IPv6<->IPv6 or IPv4<->IPv4) communications are 493 preferable to any form of translation, and stateless translation is 494 preferable to stateful translation. In the first case, this derives 495 from the End-to-End principle discussed in [Saltzer] - the utility of 496 the network to the applications that use it is generally maximized by 497 staying out of their way. In the latter case, this is due to the 498 Simplicity Principle discussed in [RFC3439]; given an easy and a hard 499 way to do something, and given equivalence of outcome, the easy way 500 is generally better for all concerned. Stateful and Stateless 501 operation both enable communication at the cost of a header exchange. 502 Stateful operation requires supporting dynamically-created per-flow 503 tables in the gateway while stateless operation transforms datagrams 504 algorithmically without per-flow state. 506 2.6.1. Stateless (1:1) Operation 508 In the stateless mode, the IVI gateway translates datagrams exchanged 509 between IPv4 systems and IPv6 systems that have an IVI address. The 510 translation is as described in SIIT [RFC2765], with the exception 511 that the address format is as described in Section 2.2 rather than 512 the IPv4 Compatible Address described in section 2.1 of that document 513 and deprecated in [RFC4291]. This includes the necessary correction 514 of transport layer checksums. 516 This is referred to as 'stateless', because the transformation 517 between IPv4 and IPv6 communication is entirely algorithmic and 518 requires no long-term state in either the hosts or the gateway. 520 2.6.2. Stateful (1:n) Operation 522 In the stateful mode, the IVI gateway operates as a standard Network 523 Address Translator, but between IPv4 and IPv6 domains. This is 524 similar in many respects to the translation carried out in NAT-PT 525 [RFC2766]. This includes the necessary correction of transport layer 526 checksums. 528 IPv4 addresses and port numbers are mapped to IPv6 addresses in a 529 stateful manner, much as is done in IPv4-IPv4 network address 530 translation. The difference is that it is unidirectional; while the 531 source port in an IPv6-> IPv4 translation may have to be changed to 532 provide adequate flow identification, there is no necessity to change 533 the source port in the IPv4->IPv6 direction. 535 3. Transition plan 537 Merriam-Webster defines a "transition" as "passage from one state, 538 stage, subject, or place to another". Any transition plan that it 539 doesn't describe how one can expect to transition from an IPv4 to an 540 IPv6 network using it is incomplete. Coexistence is a necessary 541 part, and is likely to last for a period of time measured in the 542 durations of contracts. But if the increased operations and capital 543 expenditures implied in a state of IPv4+IPv6 coexistence doesn't 544 ultimately lead to the reduced expenditure state of a single network, 545 it has not solved the problem it was intended to address. 547 In the IVI model, the network is presumed to traverse four relatively 548 stable states. These are: 550 o IPv4-only Network 551 o IPv4+IPv6 Dual Stack Network 553 o IPv6+IPv4-accessible Network 555 o IPv6 Network 557 3.1. IPv4-only Network 559 The Internet, by and large, runs on IPv4 today. There are 560 experimental uses of IPv6 and infrastructure uses of supporting 561 internetwork protocols like MPLS and ATM, but end-to-end the protocol 562 is IPv4. 564 3.2. IPv4+IPv6 Dual Stack Network 566 [RFC4213] recommends the deployment of a dual stack architecture. 567 The reason is straightforward: if while we can map IPv4 and IPv6 568 addresses 1:1 we aggressively deploy IPv6, we have two opportunities. 569 First, should there be a problem (and there are always problems), 570 user connectivity can be supported using IPv4 while the IPv6 issues 571 are sorted out. Second, at the point where the availability of IPv4 572 addresses becomes a serious issue, IPv6 connectivity will be 573 widespread, meaning that one can progress to the next phase rather 574 than scrambling for business continuity. 576 We presume that service providers and enterprise networks can deploy 577 IPv6 in parallel with IPv4, enabling current hosts (which are mostly 578 if not all IPv4+IPv6 capable) to communicate with either 579 architecture. 581 3.3. IPv6+IPv4-accessible Network 583 The problem with Section 3.2 is that, although people have had 584 warning, they have chosen to not make use of it. Hence, we are 585 likely to see an interval in the near future during which large 586 numbers of IPv4 addresses are not available to extend services and 587 IPv6 is not readily available as a deployed and purchasable service. 589 In such a case, a service provider has two main choices: obtain what 590 IPv4 addresses can be obtained at whatever cost they may be available 591 and extend his IPv4 service lifetime for a limited time period, or 592 obtain those addresses and use them in a strategic manner to 593 encourage movement to IPv6. 595 The IVI model suggests that remaining available IPv4 addresses could 596 be mapped to IPv6 addresses in such a manner than both IPv4 and IPv6 597 systems can access servers and peers using them. A subscriber might 598 be given an IPv6 /56 or /48 prefix for native use and a smaller IPv4 599 /30 or /24 prefix for translated use for servers and peers, giving 600 him an IPv6-only network whose servers and peers are available using 601 IPv4 via translation. Since the vast majority of systems operate as 602 clients or as peer-to-peer application peers, this would in fact 603 work. 605 3.4. IPv6 Network 607 At some point, enough systems have IPv6 addresses that it no longer 608 makes economic sense to support the two networks in parallel. At 609 this point, one can expect customers to no longer purchase IPv4 or 610 IVI connectivity, IPv4 and IVI services to become economically 611 uninteresting, and a global IPv6-only network to emerge. 613 4. Future extensions of the IVI Model 615 If the IPv6 hosts can be modified, the IVI model can have a stateless 616 (1:n)operation, which can support both IPv6 initiated communication 617 as well as IPv4 initiated communication. 619 For the operation and management concerns, the IVI model has ICMP 620 extension, which can be used in the traceroute or similar cases. 622 The IVI model can also support the use of multicast between IPv4 and 623 IPv6. 625 These extensions will be addressed in other documents. 627 5. Reflections on RFC 4966 629 RFCs [RFC4291] and [RFC4966] commented on the SIIT and NAT-PT 630 proposals, and called for an improved proposal. This note is in 631 response to that request. It would be of value to summarize the 632 responses to the issues. 634 The DNS Application layer Gateway used by IVI, described in 635 Section 2.4, is essentially that of DNS64 [I-D.bagnulo-behave-nat64] 636 apart from the exact format of the address. NAT-PT has a problem 637 with its DNS Application Layer gateway in that the overlay 638 relationship between IPv4 addresses and ports and IPv6 addresses is 639 dynamic, created when the RR is requested. There are complexities, 640 scoping, and timing issues with that approach. The DNS Application 641 Layer Gateway used by IVI could be configured as a completely static 642 mapping, although that would not scale. The form of the relationship 643 between A/MX and AAAA records is algorithmic and fixed, and the 644 translation is done on the fly without saved state. So the DNS 645 Application Layer Gateway is simpler and more predictable. 647 The stateless data plane translation algorithm, described in 648 Section 2.6.1, is essentially that of SIIT [RFC2765] apart from the 649 address format. As noted, [RFC4291] deprecated the address format 650 with the brusque comment that "current IPv6 transition mechanisms no 651 longer use these addresses." The reason that they were not widely 652 deployed was that they gave network operators little control in 653 routing, or ways to ensure that route redistribution worked 654 correctly. A prefix that lets the LIR specify the upper bits gives 655 the operator the flexibility to identify the IVI gateway advertising 656 the prefix and better control the distribution of routes. In 657 addition, moving the IPv4-mapped portion of the IVI address into the 658 upper 64 bits of the address enables and encourages the network 659 operator to permit IPv4-capable systems to be in various places 660 topologically while retaining an address format familiar from other 661 IPv6 addresses. The stateless mode applies to every session 662 initiated from the IPv4 side of the gateway, as IVI does not provide 663 DNS reachability to non-IVI addresses. It also applies to sessions 664 initiated from IVI addresses on the IPv6 side of the gateway. 666 The stateful data plane algorithm, described in Section 2.6.2, is 667 similar to that performed in normal IPv4/IPv4 NATs. Traffic from a 668 non-IVI IPv6 address is overlaid on an IPv4 address and disambiguated 669 by the source port number, and traffic to that IPv4 address using 670 that port number as its destination is mapped back to the IPv6 671 address and port. This is essentially the "Address+Port" model 672 proposed in [APNAT]. 674 These three algorithms have two years of operational experience 675 behind them in the CERNET/CNGI-CERNET2 network. In a world of "rough 676 consensus and running code", these are running code. 678 Many of the issues raised in [RFC4966] are in fact not specific to 679 NAT-PT, but are true of NATs in general and in particular NATs that 680 translate between Internet Protocols with different address formats. 681 In that sense, the document is not so much a complaint about NAT-PT 682 as it is a complaint about translation. IVI's stateful mode suffers 683 many of the same limitations, as would any translator. IVI's 684 stateless mode suffers from less of them due to its stateless nature, 685 but is nonetheless a translation and therefore breaks some of the 686 end-to-end semantics of the Internet. 688 6. IANA Considerations 690 This memo adds no new IANA considerations. 692 Note to RFC Editor: This section will have served its purpose if it 693 correctly tells IANA that no new assignments or registries are 694 required, or if those assignments or registries are created during 695 the RFC publication process. From the author's perspective, it may 696 therefore be removed upon publication as an RFC at the RFC Editor's 697 discretion. 699 7. Security Considerations 701 Three error cases are apparent: DNS errors, IPsec issues, and 702 application address errors. 704 As noted in Figure 4, the errors that happen in NAT-PT 705 implementations can happen in an IVI network as well. These mostly 706 relate to the propagation of DNS records outside their domain of 707 applicability. 709 As noted in Section 2.6, the side-effects of Network Address 710 Translation between IPv4 and IPv4 apply when translating between IPv4 711 and IPv6. IPsec AH, whose checksum covers the IP header, fails when 712 the header is changed. IPsec ESP, either directly on IP or over UDP 713 are usable across NATs and presumably across translators as long as 714 the IPv4 address is not in the certificate. 716 Protocols that exchange IP addresses should not normally be used 717 across a translator, as the addresses are generally not applicable on 718 the far side. Such protocols should be filtered, or permitted but 719 used with care. 721 [APNAT] raises a variety of issues with Carrier Grade Network Address 722 Translators; those issues apply to the stateful mode of IVI, and in 723 fact to any NAT. The stateless mode mitigates most of the issues 724 raised there, however. If anything, this is the reason that we 725 recommend dual stack deployment of IPv4 and IPv6 where possible in 726 the near term, and target general IPv6 deployment in the medium term, 727 as opposed to remaining in a dual address space environment forever. 729 8. Acknowledgements 731 Dan Wing and Tony Hain helped with the review of the document. 733 9. References 734 9.1. Normative References 736 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 737 (SIIT)", RFC 2765, February 2000. 739 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 740 Translation - Protocol Translation (NAT-PT)", RFC 2766, 741 February 2000. 743 9.2. Informative References 745 [APNAT] Maennel, O., Bush, R., Cittadini, L., and S. Bellovin, "A 746 Better Approach than Carrier-Grade-NAT", Aug 2008. 748 [I-D.bagnulo-behave-nat64] 749 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64/DNS64: 750 Network Address and Protocol Translation from IPv6 Clients 751 to IPv4 Servers", draft-bagnulo-behave-nat64-00 (work in 752 progress), June 2008. 754 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 755 Guidelines and Philosophy", RFC 3439, December 2002. 757 [RFC3484] Draves, R., "Default Address Selection for Internet 758 Protocol version 6 (IPv6)", RFC 3484, February 2003. 760 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 761 for IPv6 Hosts and Routers", RFC 4213, October 2005. 763 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 764 Architecture", RFC 4291, February 2006. 766 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 767 Address Translator - Protocol Translator (NAT-PT) to 768 Historic Status", RFC 4966, July 2007. 770 [Saltzer] Saltzer, JH., Reed, DP., and DD. Clark, "End-to-end 771 arguments in system design", ACM Transactions on Computer 772 Systems (TOCS) v.2 n.4, p277-288, Nov 1984. 774 Authors' Addresses 776 Xing Li 777 CERNET Center/Tsinghua University 778 Room 225, Main Building, Tsinghua University 779 Beijing, 100084 780 China 782 Phone: +86 62785983 783 Email: xing@cernet.edu.cn 785 Congxiao Bao 786 CERNET Center/Tsinghua University 787 Room 225, Main Building, Tsinghua University 788 Beijing, 100084 789 China 791 Phone: +86 62785983 792 Email: congxiao@cernet.edu.cn 794 Fred Baker 795 Cisco Systems 796 Santa Barbara, California 93117 797 USA 799 Phone: +1 408 526 4257 800 Email: fred@cisco.com 802 Kevin Yin 803 Cisco Systems 804 No. 2 Jianguomenwai Ave, Chaoyang District 805 Beijing, 100022 806 China 808 Phone: +86 10 8515 5094 809 Email: kyin@cisco.com 811 Full Copyright Statement 813 Copyright (C) The IETF Trust (2008). 815 This document is subject to the rights, licenses and restrictions 816 contained in BCP 78, and except as set forth therein, the authors 817 retain all their rights. 819 This document and the information contained herein are provided on an 820 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 821 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 822 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 823 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 824 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 825 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 827 Intellectual Property 829 The IETF takes no position regarding the validity or scope of any 830 Intellectual Property Rights or other rights that might be claimed to 831 pertain to the implementation or use of the technology described in 832 this document or the extent to which any license under such rights 833 might or might not be available; nor does it represent that it has 834 made any independent effort to identify any such rights. Information 835 on the procedures with respect to rights in RFC documents can be 836 found in BCP 78 and BCP 79. 838 Copies of IPR disclosures made to the IETF Secretariat and any 839 assurances of licenses to be made available, or the result of an 840 attempt made to obtain a general license or permission for the use of 841 such proprietary rights by implementers or users of this 842 specification can be obtained from the IETF on-line IPR repository at 843 http://www.ietf.org/ipr. 845 The IETF invites any interested party to bring to its attention any 846 copyrights, patents or patent applications, or other proprietary 847 rights that may cover technology that may be required to implement 848 this standard. Please address the information to the IETF at 849 ietf-ipr@ietf.org.