idnits 2.17.1 draft-ietf-ngtrans-natpt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 10) being 122 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 240 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 10 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([NAT], [SIIT], [TRANS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There is 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 220: '... NAT-PT SHOULD already have s...' RFC 2119 keyword, line 222: '...state does not exist the packet SHOULD...' RFC 2119 keyword, line 421: '...t length. NAT-PT SHOULD translate all ...' RFC 2119 keyword, line 424: '... plexing, NAT-PT MUST also make the ap...' RFC 2119 keyword, line 435: '... bytes the IPv4 packet SHOULD be frag-...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 32 has weird spacing: '...ddition to t...' == Line 33 has weird spacing: '...already spec...' == Line 34 has weird spacing: '...y hosts to ...' == Line 35 has weird spacing: '...v4-only host...' == Line 36 has weird spacing: '...require du-...' == (235 more instances...) -- 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 (August 1998) is 9386 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IPv6-A' is mentioned on line 301, but not defined == Missing Reference: 'IPv4-C' is mentioned on line 289, but not defined == Missing Reference: 'DNS-ALG' is mentioned on line 415, but not defined == Missing Reference: 'PMTUv4' is mentioned on line 580, but not defined ** Obsolete normative reference: RFC 1933 (ref. 'TRANS') (Obsoleted by RFC 2893) Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT George Tsirtsis 2 NGTRANS WG BT Laboratories 3 Expires February, 1999 Pyda Srishuresh 4 Category: Informational Lucent Technologies 5 August 1998 7 Network Address Translation - Protocol Translation (NAT-PT) 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Abstract 32 This document specifies a transition mechanism in addition to those 33 already specified in [TRANS]. The new mechanism provides an 34 end-to-end solution to allow IPv6-only hosts to communicate with 35 IPv4-only hosts and vice versa using Network Address Translation 36 and Protocol Translation. The scheme described does not require du- 37 al-stack hosts; nor does it mandate any routing related changes on 38 the hosts. The scheme is based on a combination of address transla- 40 tion theme as described in [NAT] and V6/V4 protocol translation 41 theme as described in [SIIT]. 43 Acknowledgements 45 The authors would like to thank Erik Nordmark whose Protocol 46 Translation details in [SIIT] formed the bases of the corresponding 47 section 5 in this document. 49 Special thanks to Pedro Marques for reviewing the draft. Finally, 50 many thanks to Alan O'Neill and Martin Tatham since the initial 51 idea described in this document was developed after discussions with 52 them. 54 Index 56 1. Introduction 58 2. Terminology 60 3. Network Address Translation operation 61 3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4) 62 3.2 NAPT-PT Outgoing Sessions (IPv6 to IPv4) 64 4. IP v4 Address Assignment 65 4.1 V4 Address assignment for outgoing connections 66 4.2 V4 Address assignment for incoming connections 67 4.2.1 DNS Application Layer Gateway (ALG) support 69 5. Protocol Translation Details 70 5.1 Translating IPv4 headers to IPv6 headers 71 5.2 Translating ICMPv4 headers to ICMPv6 headers 72 5.3 Translating IPv6 headers to IPv4 headers 73 5.4 Translating ICMPv6 headers to ICMPv4 headers 74 5.5 TCP/UDP Checksum Update 75 5.6 FTP Control session payload 77 6. NAT-PT Limitations and Future Work 78 6.1 Topology limitations 79 6.2 Protocol Translation Limitations 80 6.3 Impact of Address Translation 81 6.4 Lack of end-to-end security 82 6.5 DNS Translation and DNSSEC 84 7. Applicability Statement 86 8. Security Considerations 88 9. References 90 1. Introduction 92 IPv6 is the upcoming IP protocol that was designed in order to 93 modernise IPv4, which was designed in the 1970s. IPv6 has a number of 94 advantages over IPv4 including the fact that it provides a much 95 larger address space than IPv4, which for many, is the number one 96 reason to move to IPv6. A basic requirement, however, for a large 97 number of people is to be able to communicate with IPv4 hosts during 98 the transition period. Keeping in mind that the chances are that 99 IPv4 and IPv6 will have to coexist for a very long time, 100 interoperability becomes a very important issue. 102 The SIIT proposal [SIIT] describes a protocol translation mechanism 103 that allows communication between IPv6-only and IPv4-only machines. 104 This proposal assumes that V6 hosts are somehow assigned a V4 address 105 for communicating with v4 hosts. Further, it assumes that the V6 106 hosts would use a V6 address based on their v4 address (v4 mapped or 107 v4 compatible) as their source V6 address and V4-mapped address of 108 the target V4 machine as the destination V6 address. With these as- 109 sumptions, SIIT purports to do protocol independent translation of 110 V4/V6 datagrams, requiring no state details on the sessions. 112 Unlike SIIT, NAT-PT provides a transparent end-to-end solution re- 113 quiring no changes to end nodes. NAT-PT uses a pool of V4 addresses 114 for assignment to V6 hosts on a dynamic basis as sessions are initi- 115 ated across V4-V6 boundaries. These assigned addresses in turn are 116 used to transparently replace the original addresses used by V6 end 117 nodes and vice versa. This requires NAT-PT to track the sessions it 118 supports and mandates that inbound and outbound datagrams pertaining 119 to a session traverse through the same NAT-PT router. You will note 120 that the topology restriction on NAT-PT are very similar to those de- 121 scribed for V4 NATs in [NAT]. Protocol translation details specified 122 in [SIIT] would be used to extend address translation with protocol 123 syntax/semantics translation. 125 2. Terminology 127 Session initiation packet 128 This is the first packet of an IP session. Only the first 129 packet of a TCP session can be identified in a deterministic 130 way, with the presence of SYN bit and absence of ACK bit in TCP 131 header. There is no deterministic way to recognise the start of 132 a UDP or any non-TCP session. [NAT]. 134 Network Address Translation (NAT) 135 NAT in this document is very similar, but not the same, with 136 IPv4 NAT as described in [NAT]. IPv4 NAT translates one 137 IPv4 address into another IPv4 address . In this document, NAT 138 refers to translation of an IPv4 address into an IPv6 ad- 139 dress and vice versa. 141 Protocol Translation (PT) 142 PT in this document refers to translation of an IPv4 packet 143 into a semantically equivalent IPv6 packet and vice versa. 145 Application Layer Gateway (ALG) 146 Application Level Gateway (ALG) is an application specific 147 agent that allows a V6 host to communicate with a V4 host and 148 vice versa. Some applications carry network addresses in pay- 149 load. NAT-PT is application independent (with the notable ex- 150 ception of FTP) and does not snoop the payload to fix IP ad- 151 dresses in payload. ALG is an alternative to NAT-PT for such 152 applications. 154 3. Network Address Translation operation 156 NAT-PT offers a straight forward end-to-end solution with 157 transparent routing and address/protocol translation. Operation of 158 NAT-PT is described in the following sub-sections. There are 159 limitations to using the translation method. Is it mandatory that all 160 requests and responses pertaining to a session be routed via the same 161 NAT router. One way to ascertain this would be to have NAT based on a 162 border router that is unique to a stub domain, where all IP packets are 163 either originated from the domain or destined to the domain. There are 164 other ways to ensure this with multiple NAT devices. For example, a 165 private domain could have two distinct exit points to different 167 providers and the session flow from the hosts in a private network 168 could traverse through whichever NAT device has the best metric for an 169 external host. 171 NAT-PT is application independent. Applications such as "FTP" that 172 include IP addresses in payload will need to be supported by 173 application specific ALGs in conjunction with NAT-PT. This document 174 describes the functioning of FTP and DNS ALGs in conjunction with 175 NAT-PT. Specifications of ALGs for other applications is outside the 176 scope of this document. 178 NAT-PT is also limited by the fact that it can translate only the 179 shared semantics between the V4 and V6 protocols. Features specific 180 only to V6 or features not supported in V6 will not be supported by 181 NAT-PT. 183 In the following paragraphs we describe the operation of NAT-PT and 184 the way that connections can be initiated from both sides, when an 186 IPv6 domain is connected to an IPv4 domain through a NAT-PT 188 3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4) 190 ^ 191 | 192 [IPv6-B]-+ 193 | +==============+ 194 [IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C] 195 | +==============+ 196 (pool of v4 addresses) 198 Figure 1: IPv6 to IPv4 communication 199 Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210 200 Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211 201 Host IPv4-C has an IPv4 address -> 132.146.243.30 203 NAT-PT has a pool of addresses including the IPv4 subnet 204 120.130.26/24 205 Say the IPv6 Host A wants to communicate with the IPv4 Host C. 206 Host A creates a packet with: 208 Source Address, SA=FEDC:BA98::7654:3210 and 209 Destination Address, DA = prefix::132.146.243.30 211 NOTE: The prefix PREFIX::/96 is advertised in the stub domain by 212 the NAT-PT and it points to it. The pre-configured prefix has to 213 be routable only inside the stub domain representing the IPv4 214 world. 216 The packet is routed to the NAT-PT gateway, where it has to be 217 translated to IPv4. 219 If the outgoing packet is not a session initialisation packet, the 220 NAT-PT SHOULD already have stored some state about the related 221 session, including assigned IPv4 address and cached parameters for 222 the translation. If this state does not exist the packet SHOULD 223 be silently discarded. 225 If the packet is a session initialisation packet the NAT-PT 226 locally allocates an address (e.g: 120.130.26.10) from its 227 pool of addresses and the packet is translated to IPv4, while 228 translation parameters are cached for the duration of the session 229 and the IPv6 to IPv4 mapping is retained by NAT-PT. 231 The resulting IPv4 packet has SA=120.130.26.10 and 232 DA=132.146.243.30. The returning traffic will be recognised as 234 belonging to the same session and the packet will use the cached 235 information in order to be translated, while the addresses after 236 the translation will be as follows. 237 SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Note that 238 this packet can now be routed inside the IPv6-only network as nor- 239 mal. 241 3.2 NAPT-PT Outgoing Sessions (IPv6 to IPv4) with a single V4 address 243 NAPT-PT, which stands for "Network Address Port Translation + Pro- 244 tocol Translation", would allow V6 hosts to communicate with the 245 V4 world transparently using a single V4 address. The TCP/UDP 246 ports of the V6 hosts are translated into TCP/UDP ports of the 247 registered V4 address. The port translation and ICMP query iden- 248 tifier translation works very similar to the way NAPT is described 249 in [NAT]. 251 NAPT-PT also solves a problem that is inherent with NAT-PT. That 252 is, NAT-PT would fall flat when the pool of V4 addresses assigned 253 for translation purposes is exhausted. Once the address pool is 254 exhausted, newer V6 hosts cannot establish sessions with the out- 255 side world anymore. NAPT-PT, on the other hand, will allow for a 256 maximum of 63K TCP and 63K UDP sessions before falling flat with 257 no TCP and UDP ports left to assign. 259 In the example sited in figure 1, say, we have NAPT-PT on the bor- 260 der router (instead of NAT-PT) and all V6 addresses are mapped in- 261 to a single v4 address 120.130.26.10. 263 Say the IPv6 Host A wanted to set up a TCP session with the IPv4 264 Host C. 266 Host A creates a packet with: 268 Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017 269 and Destination Address, DA = PREFIX::132.146.243.30, destination 270 TCP port = 23. 272 When the packet reaches the NAPT-PT box, NAPT-PT would assign one 273 of the TCP ports from the assigned V4 address to translate the tu- 274 ple of (source Address, Source TCP port) as follows. 276 SA=120.130.26.10, source TCP port = 1025 and 277 DA=132.146.243.30, destination TCP port = 23. 279 The returning traffic from 132.146.243.30, TCP port 23 will be 280 recognised as belonging to the same session and will be translated 281 back to V6 as follows: 283 SA = PREFIX::132.146.243.30, source TCP port = 23; 284 DA = FEDC:BA98::7654:3210 , destination TCP port = 3017 286 As for inbound sessions, they are restricted to one server per 287 service made possible by static TCP/UDP port mapping. For example, 288 say the Host [IPv6-A] in figure 1 is the only HTTP server in the 289 V6 domain. Host [IPv4-C] sends a packet: 291 SA=132.146.243.30, source TCP port = 1025 and 292 DA=120.130.26.10, destination TCP port = 80 (http port) 294 NAPT-PT will translate this packet to: 296 SA=PREFIX::132.146.243.30, source TCP port = 1025 297 DA=FEDC:BA98::7654:3210, destination TCP port = 80 (http port) 299 In the above example, note that all sessions to NAPT registered 300 address with service port of 80 will be redirected to the same 301 host [IPv6-A]. 303 4. IPv4 Address Assignment 305 IPv4 addresses are assigned by NAT-PT to a V6 host, when NAT-PT iden- 306 tifies the start of session, inbound or outbound. Identification of 307 session start on the inbound is done differently from that on the 308 outbound. However, the same V4 address pool is used for assigning to 309 V6 hosts, irrespective of whether a session is initiated outbound 310 from a V6 host or initiated inbound from a V4 host. 312 Policies determining what type of sessions are allowed and in which 313 direction and from/to which hosts is out of the scope of this docu- 314 ment. 316 4.1 V4 Address assignment for outgoing connections 318 Outbound session start is based on identifying the first packet of 319 a session. For ex: SYN, !ACK for TCP sessions. 321 V6 hosts learn the address of V4 hosts from the DNS server in the 322 V4 domain or the DNS server internal to the V6 network. We recom- 323 mend that DNS servers internal to V6 maintain mapping of names to 324 IP V6 addresses for internal hosts and possibly some external 325 hosts. External DNS servers in the V4 domain maintain name map- 326 ping for external hosts (i.e., V4 hosts) alone. 328 In case of NAPT-PT, a TCP/UDP source port is assigned from the 329 registered V4 address upon detection of each new outbound session. 331 4.2 V4 Address assignment for incoming connections 333 In order to initiate incoming sessions, a V4 host obtains the V4 334 address of the V6 host it is trying to connect to by making a DNS 335 request. This request constitutes the start of a potential new 336 session. 337 ^ 338 [DNS]--+ 339 | [DNS]------[DNS]-------[DNS] 340 [IPv6-B]-+ \ | | 341 | +==============+ | 342 [IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C] 343 | +==============+ 344 (pool of v4 addresses) 346 Figure 2: IPv4 to IPv6 communication 348 Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210 349 Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211 350 Host IPv4-C has an IPv4 address -> 132.146.243.30 352 NAT-PT has a pool of addresses including the IPv4 subnet 353 120.130.26/24 354 4.2.1 DNS Application Layer Gateway (ALG) support 356 In figure 2 above, when Host C name resolver makes a name look 357 up request for Host A, the lookup query is redirected to the 358 DNS server on the V6 network. Considering that NAT-PT is 359 residing on the border router between V4 and V6 networks, this 360 request datagram would traverse through the NAT-PT router. The 361 DNS ALG on NAT-PT would modify the DNS Queries going into V6 362 domain as follows: 364 a) For Host Name to Host Address Query requests: 365 Change the Query type from "A" to "AAAA". 366 b) For Host address to Host name query requests: 367 Replace the V4 address octets (in reverse order) preceding 368 the string "IN-ADDR.ARPA" with the corresponding V6 address 369 (if there exists a map) octets in reverse order. 371 In the opposite direction, When DNS response traverse from the 372 DNS server on V6 network to V4 host, the DNS-ALG once again 373 traps the DNS packet and would: 375 a) Translate DNS responses for "AAAA" records into 'A' records, 376 b) Replace the V6 address sent by the V6 DNS server with the V4 377 address internally assigned by the NAT-PT router. 379 If a V4 address is not previously assigned to this V6 host, 380 NAT-PT would assign it this time. The TTL values on all DNS re- 381 source records (RRs) passing through NAT-PT would be set to 0. 383 This technique is also useful for outgoing communication as 384 well. We saw that a v6host that needs to communicate with a v4 385 hosts needs to use a specific prefix (PREFIX::) in front of the 386 IPv4 address of the v4host. The above technique allows the use 387 of this prefix without any configuration in the hosts. E.g.: In 388 Figure 2, Host-A makes a name look-up on the Host-C. The DNS 389 query goes to the v6 DNS server and from there to the v4 DNS 390 server outside the v6 stub domain after it has been translated 391 by the NAT-PT. The reply follows the same route but now the 392 NAT-PT translates the reply adding the appropriate prefix. So, 393 if the reply is: 395 HostC A 132.146.243.30, it is translated to 396 HostC AAAA PREFIX::132.146.243.30 398 Now Host A can use this address as any other IPv6 address and 399 the v6 DNS server can even cache it as long as the prefix does 400 not change. 402 An additional problem is how the v6 DNS server in the v6 stub 403 domain talks to the v4 domain outside the v6 stub domain. Re- 404 member that there are no dual stack hosts here. The v4 DNS 405 server needs to point to a v4 address, part of the v4 pool of 406 addresses, available to the NAT-PT. The NAT-PT keeps a one-to- 407 one mapping between this v4 address and the IPv6 address of the 408 v6 DNS server. In the other direction, the v6 DNS server points 410 to the IPv4 address of the v4 DNS servers with the prefix (PRE- 411 FIX::) which indicates non IPv6 address. This mechanism can 412 easily be extended to accommodate secondary DNS servers. 414 Note that the scheme described above impacts DNSSEC and look at 415 section 6.5 of this document as well as [DNS-ALG] for details. 417 5. Protocol Translation Details 419 The IPv4 and ICMPv4 headers are similar to their V6 counterparts but 420 a number of field are either missing, have different meaning or dif- 421 ferent length. NAT-PT SHOULD translate all IP/ICMP headers from and 422 to IPv6 in order to make end-to-end IPv6 to IPv4 communication possi- 423 ble. Due to the address translation function and possible port multi- 424 plexing, NAT-PT MUST also make the appropriate adjustments to the up- 425 per layer protocol (TCP/UDP) as well as to the FTP control session 426 payload. 428 In the following paragraphs we are borrowing the translation mecha- 429 nism from the SIIT specification and we make the changes imposed by 430 the address translation. 432 5.1 Translating IPv4 headers to IPv6 headers 434 If the DF flag is not set and the IPv4 packet will result in an 435 IPv6 packet larger than 1280 bytes the IPv4 packet SHOULD be frag- 436 mented prior to translating it. Since IPv4 packets with DF not 437 set will always result in a fragment header being added to the 438 packet, the IPv4 packets must be fragmented so that their length, 439 excluding the IPv4 header, is at most 1232 bytes (1280 minus 40 440 for the IPv6 header and 8 for the Fragment header). The resulting 441 fragments are then translated independently using the logic de- 442 scribed below. 444 If the DF bit is set and the packet is not a fragment (i.e., the 445 MF flag is not set and the Fragment Offset is zero) then there is 446 no need to add a fragment header to the packet. The IPv6 header 447 fields are set as follows: 449 Version: 450 6 452 Flow ID: 453 0 (all zero bits) 455 Payload Length: 456 Total length value from IPv4 header, minus the size of 457 the IPv4 header and IPv4 options, if present. 459 Tsirtsis & Srisuresh [Page 9] 460 Payload Type: 461 Protocol field copied from IPv4 header 463 Hop Limit: 464 TTL value copied from IPv4 header, decremented by one. 466 Source Address: 467 The low-order 32 bits is the IPv4 source address. The 468 high-order 96 bits is the designated prefix for all v4 469 communications and points to the NAT-PT gateway (PRE- 470 FIX::/96) 472 Destination Address: 473 The NAT-PT retains a mapping between the IPv4 DA and 474 the IPv6 address of the destination host. The IPv4 DA 475 is replaced by the IPv6 address retained in that map- 476 ping. 478 If IPv4 options are present in the IPv4 packet, they 479 are ignored i.e., there is no attempt to translate 480 them. 482 If there is need to add a fragment header (the DF bit 483 is not set or the packet is a fragment) the header 484 fields are set as above with the following exceptions: 486 IPv6 fields: 487 Payload Length: 488 Total length value from IPv4 header, plus 8 for the 489 fragment header, minus the size of the IPv4 header and 490 IPv4 options, if present. 492 Payload Type: 493 Fragment Header (44). 495 Fragment header fields: 496 Next Header: 497 Protocol field copied from IPv4 header. 499 Fragment Offset: 500 Fragment Offset copied from the IPv4 header. 502 M flag: 503 More Fragments bit copied from the IPv4 header. 505 Identification: 506 The low-order 16 bits copied from the Identification 507 field in the IPv4 header. The high-order 16 bits set 508 to zero. 510 5.2 Translating ICMPv4 headers to ICMPv6 headers 512 All ICMP messages that are to be translated require that the ICMP 513 checksum field be updated as part of the translation since ICMPv6, 514 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 516 The NAT-PT retains a mapping between the IPv4 DA and the IPv6 ad- 517 dress of the destination host. The checksum update needs to in- 518 clude this IPv6 address in the calculation. 520 In addition all ICMP packets needs to have the Type value trans- 521 lated and for ICMP error messages the included IP header also 522 needs translation. 524 The actions needed to translate various ICMPv4 messages are: 526 ICMPv4 query messages: 527 Echo and Echo Reply (Type 8 and Type 0) 528 Adjust the type to 128 and 129, respectively, and ad- 529 just the ICMP checksum both take the type change into 530 account and to include the ICMPv6 pseudo-header. 532 Information Request/Reply (Type 15 and Type 16) 533 Obsoleted in ICMPv4. Silently drop. 535 Timestamp and Timestamp Reply (Type 13 and Type 14) 536 Obsoleted in ICMPv6. Silently drop. 538 Address Mask Request/Reply (Type 17 and Type 18) 539 Obsoleted in ICMPv6. Silently drop. 541 ICMP Router Advertisement (Type 9) 542 Single hop message. Silently drop. 544 ICMP Router Solicitation (Type 10) 545 Single hop message. Silently drop. 547 Unknown ICMPv4 types 548 Silently drop. 550 IGMP messages: 551 While there are ICMPv6 counterparts for the IGMP messages all 552 the "normal" IGMP messages are single-hop messages and should 553 be silently dropped by the translator. Other IGMP messages 555 might be used by multicast routing protocols and, since it 556 would be a configuration error to try to have router adjacen- 557 cies across IPv4/IPv6 translators those packets should also be 558 silently dropped. 560 ICMPv4 error messages: 561 Destination Unreachable (Type 3) 562 For all that are not explicitly listed below set the Type 563 to 1. 565 Translate the code field as follows: 566 Code 0, 1: Set Code to 0 (no route to destination). 568 Code 2: Translate to an ICMPv6 Parameter Problem (Type 569 4, Code 1) and make the Pointer point to the IPv6 Pay- 570 load Type field. 572 Code 3: Set Code to 4 (port unreachable). 574 Code 4: Translate to an ICMPv6 Packet Too Big message 575 (Type 2) with code 0. The MTU field needs to be ad- 576 justed for the difference between the IPv4 and IPv6 577 header sizes. Note that if the IPv4 router did not 578 set the MTU field i.e. the router does not implement 579 [PMTUv4], then the translator must use the plateau 580 values specified in [PMTUv4] to determine a likely 581 path MTU and include that path MTU in the ICMPv6 pack- 582 et. (Use the greatest plateau value that is less than 583 the returned Total Length field.) 585 Code 5: Set Code to 2 (not a neighbor). 587 Code 6,7: Set Code to 0 (no route to destination). 589 Code 8: Set Code to 0 (no route to destination). 591 Code 9, 10: Set Code to 1 (communication with destina- 592 tion administratively prohibited) 594 Code 11, 12: Set Code to 0 (no route to destination). 596 Redirect (Type 5) 597 Single hop message. Silently drop. 599 Source Quench (Type 4) 600 Obsoleted in ICMPv6. Silently drop. 602 Time Exceeded (Type 11) 603 Set the Type field to 3. The Code field is unchanged. 605 Parameter Problem (Type 12) 606 Set the Type field to 4. The Pointer needs to be updated 607 to point to the corresponding field in the translated in- 608 clude IP header. 610 There are some differences between the IPv4 and the IPv6 ICMP er- 611 ror message formats as detailed above. In addition, the ICMP er- 612 ror messages contain the IP header for the packet in error which 613 needs to be translated just like a normal IP header. The transla- 614 tion will change the length of the datagram thus the Payload 615 Length field in the outer IPv6 header will need to be updated. 617 TCP/UDP/ICMP query headers within the ICMP error messages will 618 need to be translated to account for checksum changes. In the case 619 of NAPT-PT, even the TCP/UDP port numbers and ICMP Query ID will 621 need to be translated. 623 5.3 Translating IPv6 headers to IPv4 headers 625 If there is no IPv6 Fragment header the IPv4 header fields are set 626 as follows: 628 Version: 629 4 631 Internet Header Length: 632 5 (no IPv4 options) 634 Type of Service: 635 All zero. 637 Total Length: 638 Payload length value from IPv6 header, plus the size 639 of the IPv4 header. 641 Identification: 642 All zero. 644 Flags: 645 The More Fragments flag is set to zero. The Don't 646 Fragments flag is set to one. 648 Fragment Offset: 649 All zero. 651 Time to Live: 652 Hop Limit value copied from IPv6 header, decremented 653 by one. 655 Protocol: 656 Payload Type field copied from IPv6 header. 658 Header Checksum: 659 Computed once the IPv4 header has been created. 661 Source Address: 662 The NAT-PT retains a mapping between the IPv6 SA and 663 an IPv4 address from the pool of IPv4 addresses avail- 664 able. The IPv6 SA is replaced by the above IPv4 ad- 665 dress. 667 Destination Address: 668 IPv6 packets that are translated have a destination 669 address that includes an IPv4 address in the lower 32 670 bits of the address. Thus, the low-order 32 bits of 671 the IPv6 destination address is copied to the IPv4 672 source address. 674 If any of an IPv6 hop-by-hop options header, destination options 675 header, or routing header are present in the IPv6 packet, they are 676 ignored i.e., there is no attempt to translate them. However, the 677 Total Length field and the Protocol field would have to be adjust- 678 ed to "skip" these extension headers. 680 If the IPv6 packet contains a Fragment header the header fields 681 are set as above with the following exceptions: 683 Total Length: 684 Payload length value from IPv6 header, minus 8 for the 685 Fragment header, plus the size of the IPv4 header. 687 Identification: 688 Copied from the low-order 16-bits in the Identifica- 689 tion field in the Fragment header. 691 Flags: 692 The More Fragments flag is copied from the M flag in 693 the Fragment header. The Don't Fragments flag is set 694 to zero allowing this packet to be fragmented by IPv4 695 routers. 697 Fragment Offset: 698 Copied from the Fragment Offset field in the Fragment 699 Header. 701 Protocol: 702 Next Header value copied from Fragment header. 704 5.4 Translating ICMPv6 headers to ICMPv4 headers 706 All ICMP messages that are to be translated require that the ICMP 707 checksum field be updated as part of the translation since ICMPv6, 708 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 710 The NAT-PT retains a mapping between the IPv6 SA and an IPv4 ad- 711 dress from the pool of IPv4 addresses. The checksum update needs 712 to include this IPv4 address in the calculation. 714 In addition all ICMP packets needs to have the Type value trans- 715 lated and for ICMP error messages the included IP header also 716 needs translation. 718 The actions needed to translate various ICMPv6 messages are: 720 ICMPv6 informational messages: 721 Echo Request and Echo Reply (Type 128 and 129) 722 Adjust the type to 0 and 8, respectively, and adjust 723 the ICMP checksum both take the type change into ac- 724 count and to exclude the ICMPv6 pseudo-header. 726 Group Membership Query/Report/Reduction (Type 130, 131, 132) 727 Single hop message. Silently drop. 729 Neighbor Discover messages (Type 133 through 137) 730 Single hop message. Silently drop. 732 Unknown informational messages 733 Silently drop. 735 ICMPv6 error messages: 736 Destination Unreachable (Type 1) 737 Set the Type field to 3. Translate the code field as fol- 738 lows: 739 Code 0: Set Code to 1 (host unreachable). 740 Code 1: Set Code to 10 (communication with destination 741 host administratively prohibited). 742 Code 2: Set Code to 5 (source route failed). 743 Code 3: Set Code to 1 (host unreachable). 744 Code 4: Set Code to 3 (port unreachable). 746 Packet Too Big (Type 2) 747 Translate to an ICMPv4 Destination Unreachable with 748 code 4. The MTU field needs to be adjusted for the 749 difference between the IPv4 and IPv6 header sizes tak- 750 ing into account whether or not the packet in error 751 includes a Fragment header. 753 Time Exceeded (Type 3) 754 Set the Type to 11. The Code field is unchanged. 756 Parameter Problem (Type 4) 757 If the Code is 1 translate this to an ICMPv4 protocol 758 unreachable (Type 3, Code 2). Otherwise set the Type 759 to 12 and the Code to zero. The Pointer needs to be 760 updated to point to the corresponding field in the 761 translated include IP header. 763 Unknown error messages 764 Silently drop. 766 There are some differences between the IPv4 and the IPv6 ICMP er- 767 ror message formats as detailed above. In addition, the ICMP er- 769 ror messages contain the IP header for the packet in error which 770 needs to be translated just like a normal IP header. The transla- 771 tion will change the length of the datagram thus the Payload 772 Length field in the outer IPv6 header might need to be updated. 774 TCP/UDP/ICMP query headers within the ICMP error messages will 775 need to be translated to account for checksum changes. In the case 776 of NAPT-PT, even the TCP/UDP port numbers and ICMP Query ID will 777 need to be translated. 779 5.5 TCP/UDP Checksum Update 781 The NAT-PT retains a mapping between an IPv6 address and an IPv4 782 address from the pool of IPv4 addresses available. The above map- 783 ping is used in the translation process of every packet that goes 784 through the NAT-PT. 786 TCP/UDP checksum MUST be recalculated according to the address 787 change: Source Address for v6 to v4 translation; Destination Ad- 788 dress for v4 to v6 translation 790 The incremental checksum adjustment algorithm may be borrowed from 791 [NAT] draft. 793 In the case of NAPT-PT, TCP/UDP checksum must be recalculated on 794 the outbound to account for V6 source address and V6 TCP/UDP port 795 changes. Likewise, TCP/UDP checksum on the inbound packets must 796 be recalculated to account for destination v4 address and destina- 797 tion TCP/UDP port changes. 799 5.6 FTP Control session payload 801 FTP control session carries in its payload the IP address and TCP 802 port information pertaining to the data session it supports, an 803 FTP ALG on NAT-PT is needed to provide support for the popular 804 Internet application. 806 The arguments to the File Transfer Protocol (FTP) PORT command and 807 PASV response include an IP address (V4 or V6 address) and a TCP 808 port in ASCII. If the IP address in PORT command or PASV response 809 is a V6 address, then NAT-PT must substitute this with the NAT-PT 810 assigned V4 address. In case of NAPT-PT, even the TCP port follow- 811 ing the IP address must be translated. The reverse (translation 812 from v4 address to V6 address) is true in the inbound packets. 814 Note, all translations are ASCII encoded translations. As a re- 815 sult, these translations may result in a change in the size of 816 packet. 818 If the new size is same as the previous, only the TCP checksum 819 needs adjustment as a result of payload translation. If the new 820 size is different from the previous, TCP sequence numbers must al- 821 so be changed to reflect the change in length of FTP control ses- 822 sion payload. The IP packet length field in V4 header or the IP 823 payload length in V6 field must also be changed by the same delta 824 change in payload size. A special table is used to correct the TCP 825 sequence and acknowledge numbers in the TCP header for control 826 packets in both directions. 828 The table entries should have the source address, source data 829 port, destination address and destination data port for V4 and V6 830 portions of the session, sequence number delta for outbound pack- 831 ets and sequence number delta for inbound packets. The sequence 832 number deltas are negative (i.e., payload size decreases) on the 833 outbound and positive (i.e., payload increases) on the inbound. 834 Sequence number for an outbound packet is increased by the out- 835 bound sequence number delta and acknowledgement number for the 836 same outbound packet is decreased by the inbound sequence number 837 delta. Likewise, sequence number for an inbound packet is in- 838 creased by the inbound sequence number delta and acknowledgement 839 number for the same inbound packet is decreased by the outbound 840 sequence number delta. 842 6. NAT-PT Limitations and Future Work 844 6.1 Topology limitations 846 There are limitations to using the translation method. It is 847 mandatory that all requests and responses pertaining to a session 848 be routed via the same NAT router. One way to ascertain this would 849 be to have NAT based on a border router that is unique to a stub 850 domain, where all IP packets are either originated from the domain 851 or destined to the domain. 853 Note that the same limitation does not apply to IPv6 routing, since 854 IPv4 routing cn be recognised from its form PREFIX::x.y.z.w 855 (PREFIX::/96) and be treated differently. 857 6.2 Protocol Translation Limitations 859 A number of IPv4 fields have changed meaning in IPv6 and transla- 860 tion is not straightforward. For example the TOS field in IPv4 be- 861 came 'class' field in IPv6. When the IPv6 class field be standard- 862 ised meaningful mapping may be possible. As another example, the 863 option headers semantics and syntax have changed significantly in 864 IPv6, some meaningful translation may also be possible in the fu- 865 ture using NAT-PT. 867 6.3 Impact of Address Translation 869 Since NAT-PT performs address translation, applications that 870 carry the IP address in the higher layers will not work. In this 871 case Application Layer Gateways (ALG) need to be incorporated to 872 provide services to that kind of applications. 874 6.4 Lack of end-to-end security 876 One of the most important limitations of the NAT-PT proposal is 877 the fact that end-to-end network and transport layer security is 878 not possible. Also Application layer security is not possible for 879 applications that carry IP addresses to the application layer. 880 This is an inherent limitation from the Network Address Transla- 881 tion function. 883 6.5 DNS Translation and DNSSEC 885 The scheme described in section 4.2 involves translation of DNS 886 messages. It is clear that this scheme can not be deployed in 887 combination with secure DNS. I.e., an authoritative DNS name 888 server in the V6 domain cannot sign replies to queries that 889 originate from the V4 world. As a result, an V4 end-node that 890 demands DNS replies to be signed will reject replies that have 891 been tampered with by NAT-PT. 893 The good news, however, is that only servers in V6 domain that 894 need to be accessable from the V4 world pay the price for the 895 above limitation, as V4 end-nodes may not access V6 servers due to 896 DNS replies not being signed. 898 Also note that zone transfers between DNS-SEC servers within the 899 same V6 network are not impacted. 901 Clearly, if DNS-SEC were to become the norm in both V4 and V6 902 DNS servers and end-host resolvers, the scheme suggested in this 903 document will not work. 905 7. Applicability Statement 907 NAT-PT can be a valuable transition tool at the border of a stub 908 network that has been deployed as an IPv6 only network and it is 909 connected to an Internet that is either V4-only or a combination of 910 V4 and V6. 912 NAT-PT by default provides one way connectivity between an IPv6 stub 913 domain and the IPv4 world meaning that only sessions initialised by 914 IPv6 nodes internal to the IPv6 stub domain can be translated, while 915 sessions initiated by IPv4 nodes are droped. This makes NAT-PT a useful 916 tool to IPv6 only stub networks that need to be able to maintain 917 connectivity with the IPv4 world without the need to deploy servers 918 visible to the IPv4 world. 920 NAT-PT combined with a DNS ALG as described in 4.2.1 provides two way 921 connectivity between the IPv6 stub domain and the IPv4 world allowing 922 sessions to be initialised by IPv4 nodes outside the IPv6 stub domain. 923 This makes NAT-PT useful for IPv6 only stub networks that need to 924 deploy servers visible to the IPv4 world. 926 8. Security Considerations 928 All security considerations associated with NAT routers, described 929 in [NAT] as well as those described in [SIIT] are applicable 930 to NAT-PT. 932 9. REFERENCES 934 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and 935 Routers, RFC 1933, April 1996 937 [NAT] P. Srisuresh, M. Holdrege, "The IP Network Address Translator 938 (NAT) terminology and considerations", , 939 Work in progress, July 1998 941 [SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)", 942 , Work in progress, November 1997 944 [DNS-ALG} P. Srisuresh, G.Tsirtsis, P. Akkiraju, A. Heffernan, 945 "DNS extensions to Network Address Translators (DNS_ALG)", 946 , Work in progress, July 1998 948 AUTHORS 950 George Tsirtsis 951 Internet Transport Group 952 B29 Room 129 953 BT Laboratoties 954 IPSWICH IP5 3RE 955 England 956 Phone: +44 1473 640756 957 Fax: +44 1473 640709 958 e-mail: george@gideon.bt.co.uk 960 Pyda Srisuresh 961 Lucent Technologies 962 4464 Willow Road 963 Pleasanton, CA 94588-8519 964 U.S.A. 965 Voice: (925) 737-2153 966 Fax: (925) 737-2110 967 EMail: suresh@ra.lucent.com