idnits 2.17.1 draft-ietf-ngtrans-natpt-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 58 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([NAT-TERM], [SIIT], [TRANS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 137 has weird spacing: '...rotocol trans...' == Line 140 has weird spacing: '...cations to in...' == Line 304 has weird spacing: '...) from its p...' == Line 312 has weird spacing: '...sulting addre...' == Line 474 has weird spacing: '...can now initi...' == (53 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 1999) is 8958 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPv6-A' is mentioned on line 376, but not defined == Missing Reference: 'IPv4-C' is mentioned on line 365, but not defined == Unused Reference: 'DNSSEC' is defined on line 919, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2694 (ref. 'DNS-ALG') ** Obsolete normative reference: RFC 2065 (ref. 'DNSSEC') (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 1631 (ref. 'NAT') (Obsoleted by RFC 3022) ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') -- Possible downref: Non-RFC (?) normative reference: ref. 'SIIT' ** Obsolete normative reference: RFC 1933 (ref. 'TRANS') (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 2373 (ref. 'V6ADDR') (Obsoleted by RFC 3513) Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT George Tsirtsis 2 NGTRANS WG BT 3 Expires March, 2000 Pyda Srisuresh 4 Consultant 5 October 1999 7 Network Address Translation - Protocol Translation (NAT-PT) 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies an IPv4-to-IPv6 transition mechanism, in 33 addition to those already specified in [TRANS]. This solution 34 attempts to provide transparent routing, as defined in [NAT-TERM], to 35 end-nodes in V6 realm trying to communicate with end-nodes in V4 36 realm and vice versa. This is achieved using a combination of Network 37 Address Translation and Protocol Translation. The scheme described 38 does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol 39 support) or special purpose routing requirements (such as requiring 40 tunneling support) on end nodes. This scheme is based on a 41 combination of address translation theme as described in [NAT-TERM] 42 and V6/V4 protocol translation theme as described in [SIIT]. 44 Acknowledgements 46 Special thanks to Pedro Marques for reviewing an earlier version of 47 the draft. Also, many thanks to Alan O'Neill and Martin Tatham, as 48 the mechanism described in this document was initially developed 49 through discussions with them. 51 Index 53 1. Introduction 55 2. Terminology 56 2.1 Network Address Translation (NAT) 57 2.2 NAT-PT flavors 58 2.2.1 Traditional-NAT-PT 59 2.2.2 Bi-directional-NAT-PT 60 2.3 Protocol Translation (PT) 61 2.4 Application Level Gateway (ALG) 62 2.5 Requirements 64 3. Traditional-NAT-PT operation (V6 to V4) 65 3.1 NAT-PT Outgoing Sessions 66 3.2 NAPT-PT Outgoing Sessions 68 4. Use of DNS-ALG for Address assignment 69 4.1 V4 Address Assignment for Incoming Connections (V4 to V6) 70 4.2 V4 Address Assignment for Outgoing Connections (V6 to V4) 72 5. Protocol Translation Details 73 5.1 Translating IPv4 Headers to IPv6 Headers 74 5.2 Translating IPv6 Headers to IPv4 Headers 75 5.3 TCP/UDP/ICMP Checksum Update 77 6. FTP Application Level Gateway (FTP-ALG) Support 78 6.1 Payload modifications for V4 originated FTP sessions 79 6.2 Payload modifications for V6 originated FTP sessions 80 6.3 Header updates for FTP control packets 82 7. NAT-PT Limitations and Future Work 83 7.1 Topology Limitations 84 7.2 Protocol Translation Limitations 85 7.3 Impact of Address Translation 86 7.4 Lack of End-to-End Security 87 7.5 DNS Translation and DNSSEC 89 8. Applicability Statement 91 9. Security Considerations 93 10. References 95 1. Introduction 97 IPv6 is a new version of the IP protocol designed to modernize IPv4 98 which was designed in the 1970s. IPv6 has a number of advantages over 99 IPv4 that will allow for future Internet growth and will simplify IP 100 configuration and administration. IPv6 has a larger address space 101 than IPv4, an addressing model that promotes aggressive route 102 aggregation and a powerful autoconfiguration mechanism. In time, it 103 is expected that Internet growth and a need for a plug-and-play 104 solution will result in widespread adoption of IPv6. 106 There is expected to be a long transition period during which it will 107 be necessary for IPv4 and IPv6 nodes to coexist and communicate. A 108 strong, flexible set of IPv4-to-IPv6 transition and coexistence 109 mechanisms will be required during this transition period. 111 The SIIT proposal [SIIT] describes a protocol translation mechanism 112 that allows communication between IPv6-only and IPv4-only nodes via 113 protocol independent translation of IPv4 and IPv6 datagrams, 114 requiring no state information for the session. The SIIT proposal 115 assumes that V6 nodes are assigned a V4 address for communicating 116 with V4 nodes, and does not specify a mechanism for the assignment of 117 these addresses. 119 NAT-PT uses a pool of V4 addresses for assignment to V6 nodes on a 120 dynamic basis as sessions are initiated across V4-V6 boundaries. The 121 V4 addresses are assumed to be globally unique. NAT-PT with private 122 V4 addresses is outside the scope of this document and for further 123 study. NAT-PT binds addresses in V6 network with addresses in V4 124 network and vice versa to provide transparent routing [NAT-TERM] for 125 the datagrams traversing between address realms. This requires no 126 changes to end nodes and IP packet routing is completely transparent 127 [NAT-TERM] to end nodes. It does, however, require NAT-PT to track 128 the sessions it supports and mandates that inbound and outbound 129 datagrams pertaining to a session traverse the same NAT-PT router. 130 You will note that the topology restrictions on NAT-PT are the same 131 with those described for V4 NATs in [NAT-TERM]. Protocol translation 132 details specified in [SIIT] would be used to extend address 133 translation with protocol syntax/semantics translation. A detailed 134 applicability statement for NAT-PT may be found at the end of this 135 document in section 7. 137 By combining SIIT protocol translation with the dynamic address 138 translation capabilities of NAT and appropriate ALGs, NAT-PT provides 139 a complete solution that would allow a large number of commonly used 140 applications to interoperate between IPv6-only nodes and IPv4-only 141 nodes, without requiring any changes to these applications. 143 A fundamental assumption for NAT-PT is only to be use when no other 144 native IPv6 or IPv6 over IPv4 tunneled means of communication is 145 possible. In other words the aim is to only use translation between 146 IPv6 only nodes and IPv4 only nodes, while translation between IPv6 147 only nodes and the IPv4 part of a dual stack node should be avoided 148 over other alternatives. 150 2. Terminology 152 The majority of terms used in this document are borrowed almost as is 153 from [NAT-TERM]. The following lists terms specific to this document. 155 2.1 Network Address Translation (NAT) 157 The term NAT in this document is very similar to the IPv4 NAT 158 described in [NAT-TERM], but is not identical. IPv4 NAT translates 159 one IPv4 address into another IPv4 address. In this document, NAT 160 refers to translation of an IPv4 address into an IPv6 address and 161 vice versa. 163 While the V4 NAT [NAT-TERM] provides routing between private V4 164 and external V4 address realms, NAT in this document provides 165 routing between a V6 address realm and an external V4 address 166 realm. 168 2.2 NAT-PT flavors 170 Just as there are various flavors identified with V4 NAT in [NAT- 171 TERM], the following NAT-PT variations may be identified in this 172 document. 174 2.2.1 Traditional NAT-PT 176 Traditional-NAT-PT would allow hosts within a V6 network to 177 access hosts in the V4 network. In a traditional-NAT-PT, 178 sessions are uni-directional, outbound from the V6 network. 179 This is in contrast with Bi-directional-NAT-PT, which permits 180 sessions in both inbound and outbound directions. 182 Just as with V4 traditional-NAT, there are two variations to 183 traditional-NAT-PT, namely Basic-NAT-PT and NAPT-PT. 185 With Basic-NAT-PT, a block of V4 addresses are set aside for 186 translating addresses of V6 hosts as they originate sessions to 187 the V4 hosts in external domain. For packets outbound from the 188 V6 domain, the source IP address and related fields such as IP, 189 TCP, UDP and ICMP header checksums are translated. For inbound 190 packets, the destination IP address and the checksums as listed 191 above are translated. 193 NAPT-PT extends the notion of translation one step further by 194 also translating transport identifier (e.g., TCP and UDP port 195 numbers, ICMP query identifiers). This allows the transport 196 identifiers of a number of V6 hosts to be multiplexed into the 197 transport identifiers of a single assigned V4 address. NAPT-PT 198 allows a set of V6 hosts to share a single V4 address. Note 199 that NAPT-PT can be combined with Basic-NAT-PT so that a pool 200 of external addresses are used in conjunction with port 201 translation. 203 For packets outbound from the V6 network, NAPT-PT would 204 translate the source IP address, source transport identifier 205 and related fields such as IP, TCP, UDP and ICMP header 206 checksums. Transport identifier can be one of TCP/UDP port or 207 ICMP query ID. For inbound packets, the destination IP address, 208 destination transport identifier and the IP and transport 209 header checksums are translated. 211 2.2.2 Bi-Directional-NAT-PT 213 With Bi-directional-NAT-PT, sessions can be initiated from 214 hosts in V4 network as well as the V6 network. V6 network 215 addresses are bound to V4 addresses, statically or dynamically 216 as connections are established in either direction. The name 217 space (i.e., their Fully Qualified Domain Names) between hosts 218 in V4 and V6 networks is assumed to be end-to-end unique. 219 Hosts in V4 realm access V6-realm hosts by using DNS for 220 address resolution. A DNS-ALG [DNS-ALG] must be employed in 221 conjunction with Bi-Directional-NAT-PT to facilitate name to 222 address mapping. Specifically, the DNS-ALG must be capable of 223 translating V6 addresses in DNS Queries and responses into 224 their V4-address bindings, and vice versa, as DNS packets 225 traverse between V6 and V4 realms. 227 2.3 Protocol Translation (PT) 229 PT in this document refers to the translation of an IPv4 packet 230 into a semantically equivalent IPv6 packet and vice versa. 231 Protocol translation details are described in [SIIT]. 233 2.4 Application Level Gateway (ALG) 235 Application Level Gateway (ALG) [NAT-TERM] is an application 236 specific agent that allows a V6 node to communicate with a V4 node 237 and vice versa. Some applications carry network addresses in 238 payloads. NAT-PT is application unaware and does not snoop the 239 payload. ALG could work in conjunction with NAT-PT to provide 240 support for many such applications. 242 2.5 Requirements 244 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 245 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in 246 this document, are to be interpreted as described in [KEYWORDS]. 248 3. Traditional-NAT-PT Operation (V6 to V4) 250 NAT-PT offers a straight forward solution based on transparent 251 routing [NAT-TERM] and address/protocol translation, allowing a large 252 number of applications in V6 and V4 realms to inter-operate without 253 requiring any changes to these applications. 255 In the following paragraphs we describe the operation of traditional- 256 NAT-PT and the way that connections can be initiated from a host in 257 IPv6 domain to a host in IPv4 domain through a traditional-NAT-PT 259 3.1 Basic-NAT-PT Operation 261 [IPv6-B]-+ 262 | +==============+ 263 [IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C] 264 | +==============+ 265 (pool of v4 addresses) 267 Figure 1: IPv6 to IPv4 communication 268 Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210 269 Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211 270 Node IPv4-C has an IPv4 address -> 132.146.243.30 272 NAT-PT has a pool of addresses including the IPv4 subnet 273 120.130.26/24 275 The V4 addresses in the address pool could be allocated one-to-one 276 to the V6 addresses of the V6 end nodes in which case one needs as 277 many V4 addresses as V6 end points. In this document we assume 278 that the V6 network has less V4 addresses than V6 end nodes and 279 thus dynamic address allocation is required for at least some of 280 them. 282 Say the IPv6 Node A wants to communicate with the IPv4 Node C. 283 Node A creates a packet with: 285 Source Address, SA=FEDC:BA98::7654:3210 and Destination 286 Address, DA = PREFIX::132.146.243.30 288 NOTE: The prefix PREFIX::/96 is advertised in the stub domain by 289 the NAT-PT, and packets addressed to this PREFIX will be routed to 290 the NAT-PT. The pre-configured PREFIX only needs to be routable 291 within the IPv6 stub domain and as such it can be any routable 292 prefix that the network administrator chooses. 294 The packet is routed via the NAT-PT gateway, where it is 295 translated to IPv4. 297 If the outgoing packet is not a session initialisation packet, the 298 NAT-PT SHOULD already have stored some state about the related 299 session, including assigned IPv4 address and other parameters for 300 the translation. If this state does not exist, the packet SHOULD 301 be silently discarded. 303 If the packet is a session initialisation packet, the NAT-PT 304 locally allocates an address (e.g: 120.130.26.10) from its pool 305 of addresses and the packet is translated to IPv4. The translation 306 parameters are cached for the duration of the session and the IPv6 307 to IPv4 mapping is retained by NAT-PT. 309 The resulting IPv4 packet has SA=120.130.26.10 and 310 DA=132.146.243.30. Any returning traffic will be recognised as 311 belonging to the same session by NAT-PT. NAT-PT will use the state 312 information to translate the packet, and the resulting addresses 313 will be SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Note 314 that this packet can now be routed inside the IPv6-only stub 315 network as normal. 317 3.2 NAPT-PT Operation 319 NAPT-PT, which stands for "Network Address Port Translation + 320 Protocol Translation", would allow V6 nodes to communicate with 321 the V4 nodes transparently using a single V4 address. The TCP/UDP 322 ports of the V6 nodes are translated into TCP/UDP ports of the 323 registered V4 address. 325 While NAT-PT support is limited to TCP, UDP and other port 326 multiplexing type of applications, NAPT-PT solves a problem that 327 is inherent with NAT-PT. That is, NAT-PT would fall flat when the 328 pool of V4 addresses assigned for translation purposes is 329 exhausted. Once the address pool is exhausted, newer V6 nodes 330 cannot establish sessions with the outside world anymore. NAPT-PT, 331 on the other hand, will allow for a maximum of 63K TCP and 63K UDP 332 sessions per IPv4 address before having no TCP and UDP ports left 333 to assign. 335 To modify the example sited in figure 1, we could have NAPT-PT on 336 the border router (instead of NAT-PT) and all V6 addresses could 337 be mapped to a single v4 address 120.130.26.10. 339 IPv6 Node A would establish a TCP session with the IPv4 Node C as 340 follows: 342 Node A creates a packet with: 344 Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017 345 and Destination Address, DA = PREFIX::132.146.243.30, destination 346 TCP port = 23. 348 When the packet reaches the NAPT-PT box, NAPT-PT would assign one 349 of the TCP ports from the assigned V4 address to translate the 350 tuple of (Source Address, Source TCP port) as follows: 352 SA=120.130.26.10, source TCP port = 1025 and 353 DA=132.146.243.30, destination TCP port = 23. 355 The returning traffic from 132.146.243.30, TCP port 23 will be 356 recognised as belonging to the same session and will be translated 357 back to V6 as follows: 359 SA = PREFIX::132.146.243.30, source TCP port = 23; 360 DA = FEDC:BA98::7654:3210 , destination TCP port = 3017 362 Inbound NAPT-PT sessions are restricted to one server per service, 363 assigned via static TCP/UDP port mapping. For example, the Node 364 [IPv6-A] in figure 1 may be the only HTTP server (port 80) in the 365 V6 domain. Node [IPv4-C] sends a packet: 367 SA=132.146.243.30, source TCP port = 1025 and 368 DA=120.130.26.10, destination TCP port = 80 370 NAPT-PT will translate this packet to: 371 SA=PREFIX::132.146.243.30, source TCP port = 1025 372 DA=FEDC:BA98::7654:3210, destination TCP port = 80 374 In the above example, note that all sessions which reach NAPT-PT 375 with a destination port of 80 will be redirected to the same node 376 [IPv6-A]. 378 4. Use of DNS-ALG for Address Assignment 380 An IPv4 address is assigned by NAT-PT to a V6 node when NAT-PT 381 identifies the start of session, inbound or outbound. Identification 382 of the start of a new inbound session is performed differently than 383 for outbound sessions. However, the same V4 address pool is used for 384 assignment to V6 nodes, irrespective of whether a session is 385 initiated outbound from a V6 node or initiated inbound from a V4 386 node. 388 Policies determining what type of sessions are allowed and in which 389 direction and from/to which nodes is out of the scope of this 390 document. 392 IPv4 name to address mappings are held in the DNS with "A" records. 393 IPv6 name to address mappings are at the moment held in the DNS with 394 "AAAA" records. "A6" records have also been defined but at the time 395 of writing they are neither fully standardized nor deployed. 397 In any case, the DNS-ALG's principle of operation described in this 398 section is the same with either "AAAA" or "A6" records. The only 399 difference is that a name resolution using "A6" records may require 400 more than one query - reply pairs. The DNS-ALG SHOULD, in that case, 401 track all the replies in the transaction before translating an "A6" 402 record to an "A" record. 404 One of the aims of NAT-PT design is to only use translation when 405 there is no other means of communication, such as native IPv6 or some 406 form of tunneling. For the following discussion NAT-PT, in addition 407 to the IPv4 connectivity that it has it may also have a native IPv6 408 and/or a tunneled IPv6 connection. 410 4.1 V4 Address assignment for incoming connections (V4 to V6) 412 [DNS]--+ 413 | [DNS]------[DNS]-------[DNS] 414 [IPv6-B]-+ | | 415 | +==============+ | 416 [IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C] 417 | +==============+ 418 (pool of v4 addresses) 419 Figure 2: IPv4 to IPv6 communication 420 Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210 421 Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211 422 Node IPv4-C has an IPv4 address -> 132.146.243.30 424 NAT-PT has a pool of addresses including the IPv4 subnet 425 120.130.26/24 427 In figure 2 above, when Node C's name resolver sends a name look 428 up request for Node A, the lookup query is directed to the DNS 429 server on the V6 network. Considering that NAT-PT is residing on 430 the border router between V4 and V6 networks, this request 431 datagram would traverse through the NAT-PT router. The DNS-ALG on 432 the NAT-PT device would modify DNS Queries for A records going 433 into the V6 domain as follows: (Note that a TCP/UDP DNS packet is 434 recognised by the fact that its source or destination port number 435 is 53) 437 a) For Node Name to Node Address Query requests: 438 Change the Query type from "A" to "AAAA" or "A6". 439 b) For Node address to Node name query requests: 440 Replace the string "IN-ADDR.ARPA" with the string "IP6.INT". 441 Replace the V4 address octets (in reverse order) preceding 442 the string "IN-ADDR.ARPA" with the corresponding V6 address 443 (if there exists a map) octets in reverse order. 445 In the opposite direction, when a DNS response traverses from the 446 DNS server on the V6 network to the V4 node, the DNS-ALG once 447 again intercepts the DNS packet and would: 449 a) Translate DNS responses for "AAAA" or "A6" records into "A" 450 records, (only translate "A6" records when the name has 451 completely been resolved) 452 b) Replace the V6 address resolved by the V6 DNS with the V4 453 address internally assigned by the NAT-PT router. 455 If a V4 address is not previously assigned to this V6 node, NAT-PT 456 would assign one at this time. As an example say IPv4-C attempts 457 to initialise a session with node IPv6-A by making a name lookup 458 ("A" record) for Node-A . The name query goes to the local DNS and 459 from there it is propagated to the DNS server of the IPv6 network. 460 The DNS-ALG intercepts and translates the "A" query to "AAAA" or 461 "A6" query and then forwards it to the DNS server in the IPv6 462 network which replies as follows: (The example uses AAAA records 463 for convenience) 465 Node-A AAAA FEDC:BA98::7654:3210, 467 this is returned by the DNS server and gets intercepted and 468 translated by the DNS-ALG to: 470 Node-A A 120.130.26.1 472 The DNS-ALG also holds the mapping between FEDC:BA98::7654:3210 473 and 120.130.26.1 in NAT-PT. The "A" record is then returned to 474 Node-C. Node-C can now initiate a session as follows: 476 SA=132.146.243.30, source TCP port = 1025 and 477 DA=120.130.26.1, destination TCP port = 80 479 the packet will be routed to NAT-PT, which since it already holds 480 a mapping between FEDC:BA98::7654:3210 and 120.130.26.1 can 481 translate the packet to: 483 SA=PREFIX::132.146.243.30, source TCP port = 1025 484 DA=FEDC:BA98::7654:3210, destination TCP port = 80 486 the communication can now proceed as normal. 488 The TTL values on all DNS resource records (RRs) passing through 489 NAT-PT SHOULD be set to 0 so that DNS servers/clients do not cache 490 temporarily assigned RRs. Note, however, that due to some buggy 491 DNS client implementations a value of 1 might in some cases work 492 better. The TTL values should be left unchanged for statically 493 mapped addresses. 495 Address mappings for incoming sessions, as described above, are 496 subject to denial of service attacks since one can make multiple 497 queries for nodes residing in the V6 network causing the DNS-ALG 498 to map all V4 addresses in NAT-PT and thus block legitimate 499 incoming sessions. Thus, address mappings for incoming sessions 500 should time out to minimise the effect of denial of service 501 attacks. Additionally, one IPv4 address (using NAPT-PT, see 3.2) 502 could be reserved for outgoing sessions only to minimise the 503 effect of such attacks to outgoing sessions. 505 4.2 V4 Address assignment for outgoing connections (V6 to V4) 507 V6 nodes learn the address of V4 nodes from the DNS server in the 508 V4 domain or from the DNS server internal to the V6 network. We 509 recommend that DNS servers internal to V6 domains maintain a 510 mapping of names to IPv6 addresses for internal nodes and possibly 511 cache mappings for some external nodes. In the case where the DNS 512 server in the v6 domain contains the mapping for external V4 513 nodes, the DNS queries will not cross the V6 domain and that would 514 obviate the need for DNS-ALG intervention. Otherwise, the queries 515 will cross the V6 domain and are subject to DNS-ALG intervention. 516 We recommend external DNS servers in the V4 domain cache name 517 mapping for external nodes (i.e., V4 nodes) only. Zone transfers 518 across IPv4 - IPv6 boundaries are strongly discouraged. 520 In the case of NAPT-PT, a TCP/UDP source port is assigned from the 521 registered V4 address upon detection of each new outbound session. 523 We saw that a V6 node that needs to communicate with a V4 node 524 needs to use a specific prefix (PREFIX::/96) in front of the IPv4 525 address of the V4 node. The above technique allows the use of this 526 PREFIX without any configuration in the nodes. 528 To create another example from Figure 2 say Node-A wants to set up 529 a session with Node-C. For this Node-A starts by making a name 530 look-up ("AAAA" or "A6" record) for Node-C. 532 Since Node-C may also have an IPv6 address, the DNS-ALG on the 533 NAT-PT device just forwards the original AAAA/A6 query to the 534 external DNS system unchanged. If an AAAA/A6 record exists for the 535 destination, this will be returned to NAT-PT which will forward 536 it, also unchanged, to the originating host. End to end, native 537 or tunneled IPv6 communication can now commence. 539 If on the other hand there is no AAAA/A6 record for Node-C, an 540 error will be returned to NAT-PT. In this case NAT-PT re-issues 541 the query for Node C but this time looking for an A record. 542 Assuming there is an A record for Node-C the reply returns to the 543 NAT-PT The DNS-ALG translates the reply adding the appropriate 544 PREFIX. So, if the reply is 546 NodeC A 132.146.243.30, it is translated to 547 NodeC AAAA PREFIX::132.146.243.30 or to 548 NodeC A6 PREFIX::132.146.243.30 550 Now Node A can use this address like any other IPv6 address and 551 the V6 DNS server can even cache it as long as the PREFIX does not 552 change. 554 An issue here is how the V6 DNS server in the V6 stub domain talks 555 to the V4 domain outside the V6 stub domain. Remember that there 556 are no dual stack nodes here. The external V4 DNS server needs to 557 point to a V4 address, part of the V4 pool of addresses, available 558 to NAT-PT. NAT-PT keeps a one-to-one mapping between this V4 559 address and the V6 address of the internal V6 DNS server. In the 560 other direction, the V6 DNS server points to a V6 address formed 561 by the IPv4 address of the external V4 DNS servers and the prefix 562 (PREFIX::/96) that indicates non IPv6 nodes. This mechanism can 563 easily be extended to accommodate secondary DNS servers. 565 Note that the scheme described in this section impacts DNSSEC. See 566 section 7.5 of this document for details. 568 5. Protocol Translation Details 570 The IPv4 and ICMPv4 headers are similar to their V6 counterparts but 571 a number of field are either missing, have different meaning or 572 different length. NAT-PT SHOULD translate all IP/ICMP headers from v4 573 to v6 and vice versa in order to make end-to-end IPv6 to IPv4 574 communication possible. Due to the address translation function and 575 possible port multiplexing, NAT-PT SHOULD also make appropriate 576 adjustments to the upper layer protocol (TCP/UDP) headers. A separate 577 section on FTP-ALG describes the changes FTP-ALG would make to FTP 578 payload as an FTP packet traverses from V4 to V6 realm or vice versa. 580 Protocol Translation details are described in [SIIT], but there are 581 some modifications required to SIIT because of the fact that NAT-PT 582 also performs Network Address Translation. 584 5.1 Translating IPv4 headers to IPv6 headers 586 This is done exactly the same as in SIIT apart from the following 587 fields: 589 Source Address: 590 The low-order 32 bits is the IPv4 source address. The high- 591 order 96 bits is the designated PREFIX for all v4 592 communications. Addresses using this PREFIX will be routed 593 to the NAT-PT gateway (PREFIX::/96) 595 Destination Address: 596 NAT-PT retains a mapping between the IPv4 destination 597 address and the IPv6 address of the destination node. The 598 IPv4 destination address is replaced by the IPv6 address 599 retained in that mapping. 601 5.2 Translating IPv6 headers to IPv4 headers 603 This is done exactly the same as in SIIT apart from the Source 604 Address which should be determined as follows: 606 Source Address: 607 The NAT-PT retains a mapping between the IPv6 source address 608 and an IPv4 address from the pool of IPv4 addresses 609 available. The IPv6 source address is replaced by the IPv4 610 address retained in that mapping. 612 Destination Address: 614 IPv6 packets that are translated have a destination address 615 of the form PREFIX::IPv4/96. Thus the low-order 32 bits of 616 the IPv6 destination address is copied to the IPv4 617 destination address. 619 5.3 TCP/UDP/ICMP Checksum Update 621 NAT-PT retains mapping between IPv6 address and an IPv4 address 622 from the pool of IPv4 addresses available. This mapping is used in 623 the translation of packets that go through NAT-PT. 625 The following sub-sections describe TCP/UDP/ICMP checksum update 626 procedure in NAT-PT, as packets are translated from V4 to V6 and 627 vice versa. 629 5.3.1 TCP/UDP/ICMP Checksum Update from IPv4 to IPv6 631 UDP checksums, when set to a non-zero value, and TCP checksum 632 SHOULD be recalculated to reflect the address change from v4 to 633 v6. The incremental checksum adjustment algorithm may be 634 borrowed from [NAT]. In the case of NAPT-PT, TCP/UDP checksum 635 should be adjusted to account for the address and TCP/UDP port 636 changes, going from V4 to V6 address. 638 When the checksum of a V4 UDP packet is set to zero, NAT-PT 639 MUST evaluate the checksum in its entirety for the 640 V6-translated UDP packet. If a V4 UDP packet with a checksum of 641 zero arrives in fragments, NAT-PT MUST await all the fragments 642 until they can be assembled into a single non-fragmented packet 643 and evaluate the checksum prior to forwarding the translated V6 644 UDP packet. 646 ICMPv6, unlike ICMPv4, uses a pseudo-header, just like UDP and 647 TCP during checksum computation. As a result, when the ICMPv6 648 header checksum is computed [SIIT], the checksum needs to be 649 adjusted to account for the additional pseudo-header. Note, 650 there may also be adjustments required to the checksum due to 651 changes in the source and destination addresses (and changes in 652 TCP/UDP/ICMP identifiers in the case of NAPT-PT) of the payload 653 carried within ICMP. 655 5.3.2 TCP/UDP/ICMP Checksum Update from IPv6 to IPv4 657 TCP and UDP checksums SHOULD be recalculated to reflect the 658 address change from v6 to v4. The incremental checksum 659 adjustment algorithm may be borrowed from [NAT]. In the case of 660 NAPT-PT, TCP/UDP checksums should be adjusted to account for 661 the address and TCP/UDP port changes, going from V6 to V4 662 addresses. For UDP packets, optionally, the checksum may simply 663 be changed to zero. 665 The checksum calculation for a V4 ICMP header needs to be 666 derived from the V6 ICMP header by running the checksum 667 adjustment algorithm [NAT] to remove the V6 pseudo header from 668 the computation. Note, the adjustment must additionally take 669 into account changes to the checksum as a result of updates to 670 the source and destination addresses (and transport ports in 671 the case of NAPT-PT) made to the payload carried within ICMP. 673 6. FTP Application Level Gateway (FTP-ALG) Support 675 Because an FTP control session carries, in its payload, the IP 676 address and TCP port information for the data session, an FTP-ALG is 677 required to provide application level transparency for this popular 678 Internet application. 680 In the FTP application running on a legacy V4 node, arguments to the 681 FTP PORT command and arguments in PASV response(successful) include 682 an IP V4 address and a TCP port, both represented in ASCII as 683 h1,h2,h3,h4,p1,p2. However, [FTP-IPV6] suggests EPRT and EPSV command 684 extensions to FTP, with an intent to eventually retire the use of 685 PORT and PASV commands. These extensions may be used on a V4 or V6 686 node. FTP-ALG, facilitating transparent FTP between V4 and V6 nodes, 687 works as follows. 689 6.1 Payload modifications for V4 originated FTP sessions 691 A V4 host may or may not have the EPRT and EPSV command extensions 692 implemented in its FTP application. If a V4 host originates the 693 FTP session and uses PORT or PASV command, the FTP-ALG will 694 translate these commands into EPRT and EPSV commands respectively 695 prior to forwarding to the V6 node. Likewise, EPSV response from 696 V6 nodes will be translated into PASV response prior to forwarding 697 to V4 nodes. The format of EPRT and EPSV commands and EPSV 698 response may be specified as follows[FTP-IPV6]. 700 EPRT 701 EPSV 702 (or) 703 EPSVALL 705 Format of EPSV response(Positive): 229 () 708 PORT command from a V4 node is translated into EPRT command, by 709 setting the protocol field to AF #2 (IPV6) and 710 translating the V4 host Address (represented as h1,h2,h3,h4) into 711 its NAT-PT assigned V6 address in string notation, as defined in 712 [V6ADDR] in the field. TCP port represented by p1,p2 713 in PORT command must be specified as a decimal in the 714 EPRT command. Further, translation may also be required 715 in the case of NAPT-PT. PASV command from a V4 node is be 716 translated into a EPSV command with the argument set to 717 AF #2. EPSV response from a V6 node is translated into PASV 718 response prior to forwarding to the target V4 host. 720 If a V4 host originated the FTP session and was using EPRT and 721 EPSV commands, the FTP-ALG will simply translate the parameters to 722 these commands, without altering the commands themselves. The 723 protocol Number field will be translated from AF #1 to 724 AF #2. will be translated from the V4 address in ASCII 725 to its NAT-PT assigned V6 address in string notation as defined in 726 [V6ADDR]. argument in EPSV response requires 727 translation only in the case of NAPT-PT. 729 6.2 Payload modifications for V6 originated FTP sessions 731 If a V6 host originates the FTP session, however, the FTP-ALG has 732 two approaches to pursue. In the first approach, the FTP-ALG will 733 leave the command strings "EPRT" and "EPSV" unaltered and simply 734 translate the , and arguments from 735 V6 to its NAT-PT (or NAPT-PT) assigned V4 information. 736 is translated only in the case of NAPT-PT. Same goes for EPSV 737 response from V4 node. This is the approach we recommend to ensure 738 forward support for RFC 2428. However, with this approach, the V4 739 hosts are mandated to have their FTP application upgraded to 740 support EPRT and EPSV extensions to allow access to V4 and V6 741 hosts, alike. 743 In the second approach, the FTP-ALG will translate the command 744 strings "EPRT" and "EPSV" and their parameters from the V6 node 745 into their equivalent NAT-PT assigned V4 node info and attach to 746 "PORT" and "PASV" commands prior to forwarding to V4 node. 747 Likewise, PASV response from V4 nodes is translated into EPSV 748 response prior to forwarding to the target V6 nodes. However, the 749 FTP-ALG would be unable to translate the command "EPSVALL" 750 issued by V6 nodes. In such a case, the V4 host, which receives 751 the command, may return an error code indicating unsupported 752 function. This error response may cause many RFC 2428 compliant 753 FTP applications to simply fail, because EPSV support is mandated 754 by RFC 2428. The benefit of this approach, however, is that is 755 does not impose any FTP upgrade requirements on V4 hosts. 757 6.3 Header updates for FTP control packets 759 All the payload translations considered in the previous sections 760 are based on ASCII encoded data. As a result, these 761 translations may result in a change in the size of packet. 763 If the new size is the same as the previous, only the TCP 764 checksum needs adjustment as a result of the payload translation. 765 If the new size is different from the previous, TCP sequence 766 numbers should also be changed to reflect the change in the 767 length of the FTP control session payload. The IP packet length 768 field in the V4 header or the IP payload length field in the V6 769 header should also be changed to reflect the new payload size. A 770 table is used by the FTP- ALG to correct the TCP sequence and 771 acknowledgement numbers in the TCP header for control packets in 772 both directions. 774 The table entries should have the source address, source data 775 port, destination address and destination data port for V4 and V6 776 portions of the session, sequence number delta for outbound 777 control packets and sequence number delta for inbound control 778 packets. 780 The sequence number for an outbound control packet is increased 781 by the outbound sequence number delta, and the acknowledgement 782 number for the same outbound packet is decreased by the inbound 783 sequence number delta. Likewise, the sequence number for an 784 inbound packet is increased by the inbound sequence number delta 785 and the acknowledgement number for the same inbound packet is 786 decreased by the outbound sequence number delta. 788 7. NAT-PT Limitations and Future Work 790 All limitations associated to NAT [NAT-TERM] are also associated to NAT- 791 PT. Here are the most important of them in detail, as well as some 792 unique to NAT-PT. 794 7.1 Topology limitations 796 There are limitations to using the NAT-PT translation method. It 797 is mandatory that all requests and responses pertaining to a 798 session be routed via the same NAT-PT router. One way to guarantee 799 this would be to have NAT-PT based on a border router that is 800 unique to a stub domain, where all IP packets are either 801 originated from the domain or destined to the domain. This is a 802 generic problem with NAT and it is fully described in [NAT-TERM]. 804 Note, this limitation does not apply to packets originating 805 from or directed to dual-stack nodes that do not require packet 806 translation. This is because in a dual-stack set-up, IPv4 807 addresses implied in a V6 address can be identified from the 808 address format PREFIX::x.y.z.w and a dual-stack router can 809 accordingly route a packet between v4 and dual-stack nodes 810 without tracking state information. 812 This should also not affect IPv6 to IPv6 communication and in fact 813 only actually use translation when no other means of communication 814 is possible. For example NAT-PT may also have a native IPv6 815 connection and/or some kind of tunneled IPv6 connection. Both of 816 the above connections should be preferred over translation when 817 possible. The above makes sure that NAT-PT is a tool only to be 818 used to assist transition to native IPv6 to IPv6 communication. 820 7.2 Protocol Translation Limitations 822 A number of IPv4 fields have changed meaning in IPv6 and 823 translation is not straightforward. For example, the option 824 headers semantics and syntax have changed significantly in IPv6. 825 Details of IPv4 to IPv6 Protocol Translation can be found in 826 [SIIT]. 828 7.3 Impact of Address Translation 830 Since NAT-PT performs address translation, applications that 831 carry the IP address in the higher layers will not work. In 832 this case Application Layer Gateways (ALG) need to be 833 incorporated to provide support for those applications. This is a 834 generic problem with NAT and it is fully described in [NAT-TERM]. 836 7.4 Lack of end-to-end security 838 One of the most important limitations of the NAT-PT proposal is 839 the fact that end-to-end network layer security is not possible. 840 Also transport and application layer security may not be possible 841 for applications that carry IP addresses to the application 842 layer. This is an inherent limitation of the Network Address 843 Translation function. 845 Independent of NAT-PT, end-to-end IPSec security is not possible 846 across different address realms. The two end-nodes that seek IPSec 847 network level security must both support one of IPv4 or IPv6. 849 7.5 DNS Translation and DNSSEC 850 The scheme described in section 4.2 involves translation of DNS 851 messages. It is clear that this scheme can not be deployed in 852 combination with secure DNS. I.e., an authoritative DNS name 853 server in the V6 domain cannot sign replies to queries that 854 originate from the V4 world. As a result, an V4 end-node that 855 demands DNS replies to be signed will reject replies that have 856 been tampered with by NAT-PT. 858 The good news, however, is that only servers in V6 domain that 859 need to be accessible from the V4 world pay the price for the 860 above limitation, as V4 end-nodes may not access V6 servers due to 861 DNS replies not being signed. 863 Also note that zone transfers between DNS-SEC servers within the 864 same V6 network are not impacted. 866 Clearly, with DNS SEC deployment in DNS servers and end-host 867 resolvers, the scheme suggested in this document would not work. 869 8. Applicability Statement 871 NAT-PT can be a valuable transition tool at the border of a stub 872 network that has been deployed as an IPv6 only network when it is 873 connected to an Internet that is either V4-only or a combination of 874 V4 and V6. 876 NAT-PT, in its simplest form, without the support of DNS-ALG, 877 provides one way connectivity between an IPv6 stub domain and the 878 IPv4 world meaning that only sessions initialised by IPv6 nodes 879 internal to the IPv6 stub domain can be translated, while sessions 880 initiated by IPv4 nodes are dropped. This makes NAT-PT a useful 881 tool to IPv6 only stub networks that need to be able to maintain 882 connectivity with the IPv4 world without the need to deploy servers 883 visible to the IPv4 world. 885 NAT-PT combined with a DNS-ALG provides bi-directional connectivity 886 between the IPv6 stub domain and the IPv4 world allowing sessions to 887 be initialised by IPv4 nodes outside the IPv6 stub domain. This 888 makes NAT-PT useful for IPv6 only stub networks that need to deploy 889 servers visible to the IPv4 world. 891 Some applications count on a certain degree of address stability for 892 their operation. Dynamic address reuse by NAT-PT might not be 893 agreeable for these applications. For hosts running such address 894 critical applications, NAT-PT may be configured to provide static 895 address mapping between the host's V6 address and a specific V4 896 address. This will ensure that address related changes by NAT-PT do 897 not become a significant source of operational failure. 899 9. Security Considerations 901 Section 7.4 of this document states that end-to-end network and 902 transport layer security are not possible when a session is 903 intercepted by a NAT-PT. Also application layer security may not be 904 possible for applications that carry IP addresses in the 905 application layer. 907 Section 7.5 of this document states that the DNS-ALG can not be 908 deployed in combination with secure DNS. 910 Finally, all of the security considerations described in [NAT-TERM] 911 are applicable to this document as well. 913 10. REFERENCES 915 [DNS-ALG] P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan, "DNS 916 extensions to Network Address Translators (DNS_ALG)", RFC 2694, 917 September 1999. 919 [DNSSEC] D. Eastlake, "Domain Name System Security Extensions", RFC 920 2065, March 1999. 922 [FTP-IPV6] M. Allman, S. Ostermann, C. Metz, "FTP Extensions for IPv6 923 and NATs", RFC 2428, September 1998. 925 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 926 Requirement Levels", RFC 2119, March 1997. 928 [NAT] K. Egevang, P. Francis, "The IP Network Address Translator 929 (NAT)", RFC 1631, May 1994 931 [NAT-TERM] P. Srisuresh, M. Holdrege, "IP Network Address Translator 932 (NAT) Terminology and Considerations", RFC 2663, August 1999. 934 [SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)", 935 , Work in progress, January 1999. 937 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts 938 and Routers", RFC 1933, April 1996 940 [V6ADDR] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 941 RFC 2373, July 1998 942 AUTHORS 944 George Tsirtsis 945 Internet Futures 946 B29 Room 129 947 BT Adastral Park 948 IPSWICH IP5 3RE 949 England 950 Phone: +44 181 8260073 951 Fax: +44 181 8260073 952 e-mail: george.tsirtsis@bt.com 953 e-mail (alternative): gtsirt@hotmail.com 955 Pyda Srisuresh 956 849 Erie Circle 957 Milpitas, CA 95035 958 U.S.A. 959 Tel: (408) 263-7527 960 EMail: srisuresh@yahoo.com