idnits 2.17.1 draft-jennings-behave-nat6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 680. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (November 3, 2008) is 5653 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) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-16 ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track November 3, 2008 5 Expires: May 7, 2009 7 NAT for IPv6-Only Hosts 8 draft-jennings-behave-nat6-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 7, 2009. 35 Abstract 37 This specification defines a NAT that allows IPv6-only hosts that are 38 inside the NAT to operate with IPv4 hosts that are outside the NAT. 39 It requires no modifications to the v4 hosts or applications, or to 40 the operating system of v6 hosts, but it does require some changes to 41 v6 applications. Typically this specification would be used to allow 42 the hosts inside a NAT to connect to hosts outside it; but under some 43 limitations, it can also allow hosts outside to connect to hosts 44 inside. 46 The goal of this draft is to consider what is the minimal feasible 47 approach to this problem. The current intention is to merge this 48 with the nat64 draft. This draft is being discussed on the 49 behave@ietf.org list. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. NAT from 6 to 4 . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. NAT from 4 to 6 . . . . . . . . . . . . . . . . . . . . . 5 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . 7 60 5.1. UDP and TCP 6 to 4 . . . . . . . . . . . . . . . . . . . . 7 61 5.2. UDP and TCP 4 to 6 . . . . . . . . . . . . . . . . . . . . 7 62 5.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . 8 63 5.4. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.5. DSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.6. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.6.1. Option Yes ICMP . . . . . . . . . . . . . . . . . . . 9 67 5.6.2. Option No ICMP . . . . . . . . . . . . . . . . . . . . 9 68 5.7. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.8. DCCP, SCTP, etc . . . . . . . . . . . . . . . . . . . . . 10 70 6. ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1. FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6.2. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6.3. Others . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. Helper Services . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.2. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.4. V6 Routing / Tunnel . . . . . . . . . . . . . . . . . . . 11 79 8. Requirement Conformance . . . . . . . . . . . . . . . . . . . 11 80 8.1. RFC 4787 Requirements . . . . . . . . . . . . . . . . . . 11 81 8.2. draft-ietf-behave-tcp Requirements . . . . . . . . . . . . 12 82 8.3. draft-bagnulo-v6ops-6man-nat64-pb-statement 83 Requirements . . . . . . . . . . . . . . . . . . . . . . . 12 84 8.4. draft-nishitani-cgn Requirements . . . . . . . . . . . . . 12 85 8.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 Intellectual Property and Copyright Statements . . . . . . . . . . 16 95 1. Introduction 97 A lot of thought has gone into the question of how to connect v6-only 98 and v4-only hosts. This draft tries to identify the simplest 99 approach to what would just "barely work," since what barely works is 100 what is most likely to get deployed. The basic approach is to ask 101 what works for v4 to v4 NATs and to pick a design that requires as 102 few changes as possible from that. The assumption is that it is hard 103 to deploy changes in existing v4 applications and in both v4 and v6 104 operating systems. Of course, this specification relies on 105 subjective judgements about the relative complexity of deploying 106 changes into various parts of the network. 108 This specification therefore amounts to a rough straw man meant to 109 encourage discussion of what is the minimum that can be done. 111 2. Architecture 113 2.1. NAT from 6 to 4 115 The deployment topology that this work addresses has many v6-only 116 hosts behind some large, carrier-grade NAT, and these hosts wish to 117 be able to form connections to the v4 internet. This is the classic 118 NAT64 case. The harder NAT46 case is discussed later. As shown in 119 Figure 1, when a new connection is initiated by the host inside the 120 NAT using internal address X1 and port x1, the NAT creates a mapping 121 from the inside address port combination X1:x1 to some unused address 122 and port on the outside. The external v4 address that X1:x1 was 123 mapped to is referred to as X1':x1, and any packets that are sent to 124 this port on the NAT are forwarded to X1:x1. 126 +-------------------------------+ 127 | +----------+ External v4 | 128 | |Server App| | 129 | +----------+ | 130 | |Host OS | | 131 | +----------+ | 132 | Y1:y1 | 133 | | 134 | | 135 | X1':x1' | 136 | +--------+ +-------+ | 137 +----+--------+-----------------+ 138 | NAT64 | | DNS64 | 139 +----+--------+-----------------+ 140 | +--------+ +-------+ | 141 | Internal v6 | 142 | | 143 | X1:x1 | 144 | +--------+ | 145 | | Client | | 146 | +--------+ | 147 | | Host OS| | 148 | +--------+ | 149 +-------------------------------+ 151 Figure 1 153 The client application needs to know how to create a v6 destination 154 address that will be routed to the v4 server. First the client 155 application finds the v4 address of the server. One way to find the 156 server is using a DNS query. The DNS query will go through a device 157 that both synthesizes a DNS AAAA record for the A record and returns 158 the A record. If the end application knows how to look at the A 159 record directly and synthesize the v6 address to use, it can do that 160 and continue to support features such as DNSSEC. If the application 161 is unaware of the fact it is behind a NAT, it can use the AAAA record 162 as a normal v6 only application would. The v6 address is formed by 163 putting a ::FFFE:0:0/96 prefix before the v4 address. This prefix 164 range is routed to the NAT, which can extract the v4 destination 165 address. 167 The mapping from X1:x1/X1':x1' is maintained by the NAT as long as it 168 sees periodic traffic being sent from X1:x1. This specification only 169 defines the NAT for UDP and TCP but could be extended for other 170 protocols that have a port multiplexing scheme. When a mapping is 171 created for a particular port, that mapping exists for all protocols, 172 not just the protocol that created the mapping. This greatly 173 simplifies generating the keep alive traffic that is necessary to 174 maintain the mapping. 176 2.2. NAT from 4 to 6 178 Making it possible for a v4 host to connect to a server on the v6 179 side requires more complex changes to the v6 applications than the 180 trivial changes that were required in the 6 to 4 direction. However, 181 many applications that usefully have a server running behind a NAT 182 have already changed to work behind v4 to v4 NATs. The approach here 183 is the same. 185 +-------------------------------+ 186 | +----------+ External v4 | 187 | |Client App| | 188 | +----------+ | 189 | |Host OS | | 190 | +----------+ | 191 | Y1:y1 | 192 | | 193 | +----+ | 194 | X1':x1' |STUN| | 195 | +--------+ +----+ | 196 +----+--------+-----------------+ 197 | NAT | 198 +----+--------+-----------------+ 199 | +--------+ Internal v6 | 200 | | 201 | | 202 | X1:x1 | 203 | +--------+ | 204 | | Server | | 205 | +--------+ | 206 | | Host OS| | 207 | +--------+ | 208 +-------------------------------+ 210 Figure 2 212 The server starts by creating a mapping in the NAT to a v4 address 213 that it can use. The server does this by creating a connection to 214 some server in the outside v4 space and having that server tell it 215 what address and port the request came from, which reveals the 216 external X1':x1' address port that has been mapped to the port the 217 server is using. Typically a STUN server would be used. Note that a 218 UDP transaction to a STUN server will allocate a mapping that can be 219 used for incoming TCP connections. The NAT is required to run a STUN 220 server on the external side at the address ::FFFE:127.0.0.1 on the 221 default STUN port so the server will always be able to find a STUN 222 server if it is behind a NAT. [[ Note - I have no idea if this 223 address hack would work - but we can skin the cat with some other 224 potato peeler if it does not ]]. The server needs to send periodic 225 keep alive traffic to make sure the NAT does not remove the mapping. 226 This can also be done with STUN. 228 Next the server lets the client know that it can be reached at the 229 address port of X1':x1'. This might be done simply, such as by 230 creating a URL that points to that location and providing it by 231 whatever means the URL is found (email, IM, bathroom walls, 232 whatever); or through a complex approach, such as by using a 233 rendezvous server such as a SIP registrar or by using DNS SRV records 234 as rendezvous servers that point at the correct address and port. At 235 this point, a client in the v4 space can initiate a connection to the 236 X1':x1', and this will form a connection to the server. 238 The applications that tend to be popular to run behind NATs are 239 mostly P2P applications, such as file sharing and VoIP. Many of 240 these types of applications have already undergone the changes that 241 would be necessary to enable them to work behind a NAT such as the 242 one described here, because these changes let them work behind v4 to 243 v4 NATs. HTTP servers may also turn out to be valuable to run behind 244 NATs. The use cases would likely not involve direct web page serving 245 so much as places where a web application, such as Facebook, could 246 make an RPC call to an application that was running on the v6 server 247 behind the NAT. The URL that Facebook uses for the RPC calls can 248 easily be updated by the application. This type of architecture is 249 already becoming more common as people use virtual servers in elastic 250 computing environments. These environments are often behind NATs to 251 facilitate migration of virtual servers. It is worth noting, 252 particularly for future protocol development, that if HTTP did a DNS 253 SRV lookup, it would be possible to use DNS as the rendezvous server 254 for a generic web browser on the v4 internet to reach a v6-only 255 server behind the NAT. 257 3. Terminology 259 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 260 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 261 document are to be interpreted as described in RFC 2119 [RFC2119]. 263 4. Mapping 265 When the NAT receives a packet with a source of X1:x1 from a host on 266 the inside, the NAT first checks to see if it already has a mapping 267 for it. If so, it resets the timer for the mapping; otherwise, it 268 creates a new mapping. If the NAT already has any mapping from X1 to 269 an external address X1', the external address used for this new 270 mapping MUST be the same as the external address used for previous 271 mappings of X1. The external address/port combination (X1':x1') 272 allocated for the new mapping MUST NOT be in use by any other 273 mapping. When choosing a port number for the mapping, well known 274 port numbers MUST NOT be used. 276 The mappings timer MUST keep mappings for at least 10 minutes after 277 any packet is sent from the internal host through that mapping. Note 278 that applications should not assume that the mapping will be promptly 279 removed after 10 minutes of inactivity, since NAT implementations 280 often do not use a timer per mapping but instead use a periodic sweep 281 approach to deleting mapping. 283 5. Packet Forwarding 285 5.1. UDP and TCP 6 to 4 287 When the NAT receives a UDP or TCP packet from the inside, it updates 288 the mapping as described in Section 4, and then it extracts the 289 external v4 address from the v6 address by striping the ::FFFE:0:0/96 290 prefix. Next it takes the payload section of the UDP or TCP packet 291 and constructs a v4 UDP or TCP payload using this destination and 292 source from the associated mapping. Then it sends the packet 293 following the procedures defined for a host to send a UDP or TCP 294 packet. Note that any IP options (other than fragmentation) are lost 295 in this process; also, as defined in UDP and TCP, new checksums will 296 be updated. 298 It is worth noting that the v4 destination address of the packet may 299 be one of the external addresses of this NAT, in which case the 300 packet is forwarded to that address and processed just like any other 301 packet arriving at this address. Packets can therefore "hairpin" 302 though the NAT. There is no good way to avoid this without some 303 modifications to the applications to allow them to be aware of this 304 and optimize around it. ICE is an example of a way applications can 305 optimize around this hairpinning. 307 5.2. UDP and TCP 4 to 6 309 When the NAT receives a UDP or TCP packet from the outside, it checks 310 to see if it has a mapping for the address port that the packet was 311 received on. If it does, it uses the internal address and port 312 associated with the mapping as the destination. It constructs a v6 313 UDP or TCP packet from the payload of the received packet and 314 forwards that to the internal address. Note that checksums are 315 updated when this new packet is created and sent. 317 If the NAT receives a TCP SYN packet for which there is no mapping it 318 SHOULD silently discard it; otherwise TCP hole punching techniques 319 using simultaneous opens will not work. 321 5.3. IP Fragmentation 323 The interaction of v4 and v6 fragmentation has some thorny issues. 325 The NAT MUST support reassembly of fragmented packets when the 326 packets are received in order, but support for out of order fragments 327 is OPTIONAL. 329 If the NAT receives a v4 packet with the do not fragment bit set, it 330 MUST NOT forward it if the MTU of the v6 link would require the 331 packet to be fragmented, and the NAT MUST NOT include a fragment 332 header in the v6 packet. If the NAT receives a v4 packet that does 333 not have the do not fragment bit set, then the packet, when 334 forwarded, MUST include a fragment header; and if the packet is 335 larger than the MTU, the packet MUST be appropriately fragmented. 336 When the NAT receives a v6 packet without a fragment header, it MUST 337 set the do not fragment bit in any v4 packets, and if the resulting 338 v4 packet is larger than the MTU on the v4 link that will be used, 339 the NAT MUST NOT forward the packet. When the NAT receives a v6 340 packet with a fragment header, it can send the v4 packet without the 341 do not fragment bit set and can fragment the packet appropriately. 343 The problem with this approach is that the v6 host is likely to send 344 packets less than 1280 octets with no fragmentation header. The v4 345 side will interpret these packets as being unable to be fragmented, 346 and if they are destined for a host in which some element of the path 347 has a shorter MTU, the packet will be discarded. The only practical 348 way to mitigate this situation is to have the application send most 349 of it packets with a fragmentation header, even if they are smaller 350 than 1280 octets. 352 Application that support this specification, when sending to a v6 353 address that starts with the prefix ::FFFE:0:0/96 SHOULD include a 354 fragment header regardless of the size of the packet. 356 5.4. TTL 358 When a packet is forwarded, the TTL is decremented by one. If it is 359 zero, the packet is not forwarded. 361 5.5. DSCP 363 When packets pass from one side to the other, the DSCP needs to be 364 copied. If the NAT also includes diffserv classifier and marker 365 functionality it MAY change the DSCP values. See RFC 2983[RFC2983] 366 for more information. 368 5.6. ICMP 370 [[ Note - this is going to be controversial. I suspect it actually 371 goes too far but I'm deliberately presenting a pretty far out there 372 side of the argument, in the hope that it will drive a discussion 373 about what we really need, in practice, if we ignore IETF dogma. ]] 375 5.6.1. Option Yes ICMP 377 ICMP packets are translated as described in [RFC2765]. 379 5.6.2. Option No ICMP 381 ICMP can be split into two parts, the part that reports errors for 382 other transports and the part that supports exactly two applications, 383 ping and traceroute. The problem with ICMP for reporting transport 384 errors is that on today's internet ICMP is so often blocked that no 385 application can rely on ICMP working. Applications tend to be 386 designed to work without ICMP. NAT processing of ICMP packets is 387 complicated because ICMP packets may contain embedded IP packets or 388 fragments thereof. The security is further complicated by the fact 389 that a UDP or TCP packet may cause an ICMP error to be generated by a 390 host other than the host for which the original packet was destined. 391 This possibility makes it difficult to determine which ICMP packets 392 are valid and which are not. Furthermore, the way the APIs for UDP 393 are typically used makes it hard for operating systems to notify 394 applications of ICMP errors. 396 NAT processing of ICMP errors is complicated and of very limited 397 value; for that reason forwarding ICMP error messages is OPTIONAL. 398 Processing to allow ping and traceroute through the NAT is also 399 OPTIONAL 401 5.7. IPsec 403 IPsec over UDP will work, but other forms of IPsec will generally not 404 work in a reliable way. 406 5.8. DCCP, SCTP, etc 408 This specification can be extended by future specifications to 409 support other transports but, given the immediate needs, this 410 specification only requires support for UDP and TCP. This allows 411 vendors that have not implemented other protocols to be compliant 412 with this specification. No significant problems are see with using 413 the same basic approach for DCCP. 415 SCTP may be more complicated. Often one of the reasons for using 416 SCTP is to take advantage multi-homing for reliability reasons but 417 this may require that the two SCTP sessions try and use different 418 NATs. The requirements and deployments topologies are not clear. 420 6. ALGs 422 6.1. FTP 424 The deployment of personal firewalls and the misconfiguration of 425 other firewalls has resulted in widespread breakage of active mode 426 FTP. The general guess is that an FTP ALG will be needed to take 427 PASV responses and turn them into EPAS responses. However, more 428 experimentation is needed with what happens today with existing FTP 429 clients running on v6 only hosts behind NATs to determine what is the 430 best approach to this problem. 432 6.2. SIP 434 Many widely deployed SIP implementations work fine through NATs 435 without requiring any ALGs. SIP was not designed to work with ALGs. 436 More importantly, ALGs are not considered when designing new 437 extensions to SIP and the combination of the extensions and the ALG 438 often break badly. It is NOT RECOMMENDED for the NAT to have SIP 439 ALGs, but if SIP ALGs are insisted upon, the best approach is to 440 implement a dual homed proxy in the NAT that does v6 on one side and 441 v4 on the other. This approach will be compatible with future SIP 442 extensions and is significantly easier to correctly implement as SIP 443 was designed so this would work. 445 6.3. Others 447 All other ALGs are NOT RECOMMENDED. 449 7. Helper Services 451 There are several services that, while not actually part of NATs, 452 greatly facilitate being able to build applications that reliably 453 work through NATs and should be logically, if not physically, 454 associated with the NAT. 456 7.1. STUN 458 The NAT must run a Basic Standalone STUN server as defined in section 459 13 of [I-D.ietf-behave-rfc3489bis], with the exception that it is NOT 460 REQUIRED that it support TCP and it is not necessary to provide a DNS 461 entry for this server. The server MUST run on the address ::FFFE: 462 127.0.0.1 with default port of 3478. [[Note, if this address hack is 463 inappropriate, this could be resolved by just defining a well known 464 v4 anycast address for STUN and using that]] 466 7.2. DNS 468 The NAT MUST provide a recursive DNS resolver that is capable of 469 taking a DNS request received from the inside and resolving it on the 470 outside. 472 The resolver SHOULD try to take DNS A records results from the 473 outside and synthesize synthetic AAAA records that would be routed to 474 the using the v6 prefix. This SHOULD NOT be done if a record exists 475 that does not use the NAT prefix address. 477 7.3. DHCP 479 DHCP is very useful for the automated configuration of many things 480 beyond IP addresses. [[ TODO should any particular DHCP things be 481 required]] 483 7.4. V6 Routing / Tunnel 485 If a packet arrives from the inside with a v6 destination that is not 486 in the ::FFFE:0:0/96 range, the NAT could/(should/may) forward this 487 to the v6 internet. This could be via a direct v6 connection or some 488 646 tunnel. [[ Note not sure what to require / recommend here ]] 490 8. Requirement Conformance 492 8.1. RFC 4787 Requirements 494 NATs meeting this specification are compliant with the specification 495 defined for UDP NAT behavior in RFC 4787 [RFC4787], with the 496 exception that RFC 4787 requires reassembly of out of order packets 497 while this does not. 499 8.2. draft-ietf-behave-tcp Requirements 501 NATs meeting this specification are compliant with the specification 502 defined for [I-D.ietf-behave-tcp], with the exception of Req-9, which 503 requires ICMP, and Req-5, which requires that mapping of established 504 TCP connections with no traffic to stay valid for 2 hours and 4 505 minutes, while this requires only 10 minutes. 507 8.3. draft-bagnulo-v6ops-6man-nat64-pb-statement Requirements 509 Meets all the MUST support items in 510 [I-D.bagnulo-v6ops-6man-nat64-pb-statement] except the requirement in 511 R7 for ICMP support. 513 Meets all the SHOULD support items except: 515 I4 requires support for out of order fragmented packets. See 516 security consideration section in this document for more 517 discussion on this. 519 I6 - not clear whether or not all of MIPv6 works with this. 521 I7 & I8 require support for DCCP and SCTP which could be done as 522 an extension to this. 524 I9 - not clear when this does and does not work with multicast. 526 8.4. draft-nishitani-cgn Requirements 528 Meets all the requirements of [I-D.nishitani-cgn] except the 529 following: 531 R4 & R9 - require support of ICMP. 533 R5 & R6 are additional constraints on reserving ports which are 534 not mandated by this specification; but a device that was fully 535 compliant with this specification could still support these. 537 R7 & R8 are analyzed in Section 8.1 and Section 8.2. 539 8.5. Multicast 541 More analysis is needed - your mileage may vary. Some important 542 multicast applications such as an IP TV-like system that used an SSM 543 sender in the v4 space with clients in the v6 space could probably be 544 made to work fine, with little modification for v6-only clients. 545 Some other multicast scenarios with senders in both the v4 and v6 546 space probably would not work. 548 9. IANA Considerations 550 This document makes no request of IANA. 552 Open Issues: What prefix to use. We will want to allocate a 553 different prefix than the ::FFFE:0:0/96. This draft makes no 554 argument about which prefix would be best, it just requires that the 555 specification define some fixed prefix to use. 557 Note to RFC Editor: this section may be removed on publication as an 558 RFC. 560 10. Security Considerations 562 Often NATs are combined with firewalls that perform address-dependent 563 filtering (as defined in [RFC4787]) to improve security. The type of 564 NAT envisioned here is a large, carrier-grade NAT with many clients 565 behind it. Performing firewall operations at this location in the 566 topology is not particularly effective because the attacker may well 567 be on the "inside". The firewall capabilities should be provided 568 much closer to the host being protected. The benefit of having 569 mappings with address-independent filtering is that it make it 570 possible to easily run servers inside the NAT with no modification of 571 the clients outside the NAT. For this reason, this specification 572 adopts a NAT design with address-independent filtering. 574 One of the concerns about a large scale NAT that a single host inside 575 the NAT might be able to perform a DOS attack by using up a large 576 portion of the available external ports simply by creating many 577 mappings. To mitigate this, the NAT SHOULD allow a configurable 578 limit to the number of mappings that can be created by a single host 579 inside the NAT. 581 TODO - reassembly of out of order packets 583 11. Acknowledgements 585 Thanks to Dave Ward who pointed out that I and others were spending 586 too much time making this complicated and should stop talking and get 587 on with writing some drafts. Thanks for helpful comments from Mangus 588 Westerlud, Iljitsch van Beijnum, and . 590 12. References 591 12.1. Normative References 593 [I-D.ietf-behave-rfc3489bis] 594 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 595 "Session Traversal Utilities for (NAT) (STUN)", 596 draft-ietf-behave-rfc3489bis-16 (work in progress), 597 July 2008. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 603 (SIIT)", RFC 2765, February 2000. 605 12.2. Informative References 607 [I-D.bagnulo-v6ops-6man-nat64-pb-statement] 608 Bagnulo, M. and F. Baker, "IPv4/IPv6 Coexistence and 609 Transition: Requirements for solutions", 610 draft-bagnulo-v6ops-6man-nat64-pb-statement-01 (work in 611 progress), February 2008. 613 [I-D.ietf-behave-tcp] 614 Guha, S., "NAT Behavioral Requirements for TCP", 615 draft-ietf-behave-tcp-07 (work in progress), April 2007. 617 [I-D.nishitani-cgn] 618 Nishitani, T. and S. Miyakawa, "Carrier Grade Network 619 Address Translator (NAT) Behavioral Requirements for 620 Unicast UDP, TCP and ICMP", draft-nishitani-cgn-00 (work 621 in progress), July 2008. 623 [RFC2983] Black, D., "Differentiated Services and Tunnels", 624 RFC 2983, October 2000. 626 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 627 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 628 RFC 4787, January 2007. 630 Author's Address 632 Cullen Jennings 633 Cisco Systems 634 170 West Tasman Drive 635 Mailstop SJC-21/2 636 San Jose, CA 95134 637 USA 639 Phone: +1 408 902-3341 640 Email: fluffy@cisco.com 642 Full Copyright Statement 644 Copyright (C) The IETF Trust (2008). 646 This document is subject to the rights, licenses and restrictions 647 contained in BCP 78, and except as set forth therein, the authors 648 retain all their rights. 650 This document and the information contained herein are provided on an 651 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 652 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 653 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 654 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 655 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 656 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 658 Intellectual Property 660 The IETF takes no position regarding the validity or scope of any 661 Intellectual Property Rights or other rights that might be claimed to 662 pertain to the implementation or use of the technology described in 663 this document or the extent to which any license under such rights 664 might or might not be available; nor does it represent that it has 665 made any independent effort to identify any such rights. Information 666 on the procedures with respect to rights in RFC documents can be 667 found in BCP 78 and BCP 79. 669 Copies of IPR disclosures made to the IETF Secretariat and any 670 assurances of licenses to be made available, or the result of an 671 attempt made to obtain a general license or permission for the use of 672 such proprietary rights by implementers or users of this 673 specification can be obtained from the IETF on-line IPR repository at 674 http://www.ietf.org/ipr. 676 The IETF invites any interested party to bring to its attention any 677 copyrights, patents or patent applications, or other proprietary 678 rights that may cover technology that may be required to implement 679 this standard. Please address the information to the IETF at 680 ietf-ipr@ietf.org.