idnits 2.17.1 draft-jennings-behave-nat6-00.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 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 683. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 696. 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 (July 4, 2008) is 5765 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 July 4, 2008 5 Expires: January 5, 2009 7 NAT for IPv6-Only Hosts 8 draft-jennings-behave-nat6-00 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 January 5, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This specification defines a NAT that allows IPv6-only hosts that are 42 inside the NAT to operate with IPv4 hosts that are outside the NAT. 43 It requires no modifications to the v4 hosts or applications, or to 44 the operating system of v6 hosts, but it does require some changes to 45 v6 applications. Typically this specification would be used to allow 46 the hosts inside a NAT to connect to hosts outside it; but under some 47 limitations, it can also allow hosts outside to connect to hosts 48 inside. 50 The goal of this draft is to consider what is the minimal feasible 51 approach to this problem. The draft is being discussed on the 52 behave@ietf.org list. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. NAT from 6 to 4 . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. NAT from 4 to 6 . . . . . . . . . . . . . . . . . . . . . 5 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. UDP and TCP 6 to 4 . . . . . . . . . . . . . . . . . . . . 8 64 5.2. UDP and TCP 4 to 6 . . . . . . . . . . . . . . . . . . . . 8 65 5.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . 8 66 5.3.1. Option Frag-A . . . . . . . . . . . . . . . . . . . . 9 67 5.3.2. Option Frag-B . . . . . . . . . . . . . . . . . . . . 9 68 5.4. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.5. DSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.6. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.6.1. Option Yes ICMP . . . . . . . . . . . . . . . . . . . 10 72 5.6.2. Option No ICMP . . . . . . . . . . . . . . . . . . . . 10 73 5.7. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.8. DCCP, SCTP, etc . . . . . . . . . . . . . . . . . . . . . 11 75 6. ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 6.2. FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.3. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.4. Others . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Helper Services . . . . . . . . . . . . . . . . . . . . . . . 12 81 7.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 7.2. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 7.4. V6 Routing / Tunnel . . . . . . . . . . . . . . . . . . . 12 85 8. Requirement Conformance . . . . . . . . . . . . . . . . . . . 13 86 8.1. RFC 4787 Requirements . . . . . . . . . . . . . . . . . . 13 87 8.2. draft-ietf-behave-tcp Requirements . . . . . . . . . . . . 13 88 8.3. draft-bagnulo-v6ops-6man-nat64-pb-statement 89 Requirements . . . . . . . . . . . . . . . . . . . . . . . 13 90 8.4. draft-nishitani-cgn Requirements . . . . . . . . . . . . . 13 91 8.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 Intellectual Property and Copyright Statements . . . . . . . . . . 17 101 1. Introduction 103 A lot of thought has gone into the question of how to connect v6-only 104 and v4-only hosts. This draft tries to identify the simplest 105 approach to what would just "barely work," since what barely works is 106 what is most likely to get deployed. The basic approach is to ask 107 what works for v4 to v4 NATs and to pick a design that requires as 108 few changes as possible from that. The assumption is that it is hard 109 to deploy changes in existing v4 applications and in both v4 and v6 110 operating systems. Of course, this specification relies on 111 subjective judgements about the relative complexity of deploying 112 changes into various parts of the network. 114 This specification therefore amounts to a rough straw man meant to 115 encourage discussion of what is the minimum that can be done. 117 2. Architecture 119 2.1. NAT from 6 to 4 121 The deployment topology that this work addresses has many v6-only 122 hosts behind some large, carrier-grade NAT, and these hosts wish to 123 be able to form connections to the v4 internet. This is the classic 124 NAT64 case. The harder NAT46 case is discussed later. As shown in 125 Figure 1, when a new connection is initiated by the host inside the 126 NAT using internal address X1 and port x1, the NAT creates a mapping 127 from the inside address port combination X1:x1 to some unused address 128 and port on the outside. The external v4 address that X1:x1 was 129 mapped to is referred to as X1':x1, and any packets that are sent to 130 this port on the NAT are forwarded to X1:x1. 132 +-------------------------------+ 133 | +----------+ External v4 | 134 | |Server App| | 135 | +----------+ | 136 | |Host OS | | 137 | +----------+ | 138 | Y1:y1 | 139 | | 140 | | 141 | X1':x1' | 142 | +--------+ | 143 +----+--------+-----------------+ 144 | NAT | 145 +----+--------+-----------------+ 146 | +--------+ Internal v6 | 147 | | 148 | | 149 | X1:x1 | 150 | +--------+ | 151 | | Client | | 152 | +--------+ | 153 | | Host OS| | 154 | +--------+ | 155 +-------------------------------+ 157 Figure 1 159 The client application needs to know how to create a v6 destination 160 address that will be routed to the v4 server. First the client 161 application finds the v4 address of the server, often by using a DNS 162 A record query, and then it composes a v6 address formed by putting a 163 ::FFFF/96 prefix before the v4 address. This prefix range is routed 164 to the NAT, which can extract the v4 destination address. 166 The mapping from X1:x1/X1':x1' is maintained by the NAT as long as it 167 sees periodic traffic being sent from X1:x1. This specification only 168 defines the NAT for UDP and TCP but could be extended for other 169 protocols that have a port multiplexing scheme. When a mapping is 170 created for a particular port, that mapping exists for all protocols, 171 not just the protocol that created the mapping. This greatly 172 simplifies generating the keep alive traffic that is necessary to 173 maintain the mapping. 175 2.2. NAT from 4 to 6 177 Making it possible for a v4 host to connect to a server on the v6 178 side requires more complex changes to the v6 applications than the 179 trivial changes that were required in the 6 to 4 direction. However, 180 many applications that usefully have a server running behind a NAT 181 have already changed to work behind v4 to v4 NATs. The approach here 182 is the same. 184 +-------------------------------+ 185 | +----------+ External v4 | 186 | |Client App| | 187 | +----------+ | 188 | |Host OS | | 189 | +----------+ | 190 | Y1:y1 | 191 | | 192 | +----+ | 193 | X1':x1' |STUN| | 194 | +--------+ +----+ | 195 +----+--------+-----------------+ 196 | NAT | 197 +----+--------+-----------------+ 198 | +--------+ Internal v6 | 199 | | 200 | | 201 | X1:x1 | 202 | +--------+ | 203 | | Server | | 204 | +--------+ | 205 | | Host OS| | 206 | +--------+ | 207 +-------------------------------+ 209 Figure 2 211 The server starts by creating a mapping in the NAT to a v4 address 212 that it can use. The server does this by creating a connection to 213 some server in the outside v4 space and having that server tell it 214 what address and port the request came from, which reveals the 215 external X1':x1' address port that has been mapped to the port the 216 server is using. Typically a STUN server would be used. Note that a 217 UDP transaction to a STUN server will allocate a mapping that can be 218 used for incoming TCP connections. The NAT is required to run a STUN 219 server on the external side at the address ::FFFF:127.0.0.1 on the 220 default STUN port so the server will always be able to find a STUN 221 server if it is behind a NAT. [[ Note - I have no idea if this 222 address hack would work - but we can skin the cat with some other 223 potato peeler if it does not ]]. The server needs to send periodic 224 keep alive traffic to make sure the NAT does not remove the mapping. 225 This can also be done with STUN. 227 Next the server lets the client know that it can be reached at the 228 address port of X1':x1'. This might be done simply, such as by 229 creating a URL that points to that location and providing it by 230 whatever means the URL is found (email, IM, bathroom walls, 231 whatever); or through a complex approach, such as by using a 232 rendezvous server such as a SIP registrar or by using DNS SRV records 233 as rendezvous servers that point at the correct address and port. At 234 this point, a client in the v4 space can initiate a connection to the 235 X1':x1', and this will form a connection to the server. 237 The servers that tend to be popular to run behind NATs are mostly P2P 238 applications, such as file sharing and VoIP. Many of these types of 239 applications have already undergone the changes that would be 240 necessary to enable them to work behind a NAT such as the one 241 described here, because these changes let them work behind v4 to v4 242 NATs. HTTP servers may also turn out to be valuable to run behind 243 NATs. The use cases would likely not involve direct web page serving 244 so much as places where a web application, such as Facebook, could 245 make an RPC call to an application that was running on the v6 server 246 behind the NAT. The URL that Facebook uses for the RPC calls can 247 easily be updated by the application. This type of architecture is 248 already becoming more common as people use virtual servers in elastic 249 computing environments. These environments are often behind NATs to 250 facilitate migration of virtual servers. It is worth noting, 251 particularly for future protocol development, that if HTTP did a DNS 252 SRV lookup, it would be possible to use DNS as the rendezvous server 253 for a generic web browser on the v4 internet to reach a v6-only 254 server behind the NAT. 256 3. Terminology 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in RFC 2119 [RFC2119]. 262 4. Mapping 264 When the NAT receives a packet with a source of X1:x1 from a host on 265 the inside, the NAT first checks to see if it already has a mapping 266 for it. If so, it resets the timer for the mapping; otherwise, it 267 creates a new mapping. If the NAT already has any mapping from X1 to 268 an external address X1', the external address used for this new 269 mapping MUST be the same as the external address used for previous 270 mappings of X1. The external address/port combination (X1':x1') 271 allocated for the new mapping MUST NOT be in use by any other 272 mapping. When choosing a port number for the mapping, well known 273 port numbers MUST NOT be used. 275 The mappings timer MUST keep mappings for at least 10 minutes after 276 any packet is sent from the internal host through that mapping. Note 277 that applications should not assume that the mapping will be promptly 278 removed after 10 minutes of inactivity, since NAT implementations 279 often do not use a timer per mapping but instead use a periodic sweep 280 approach to deleting mapping. 282 5. Packet Forwarding 284 5.1. UDP and TCP 6 to 4 286 When the NAT receives a UDP or TCP packet from the inside, it updates 287 the mapping as described in Section 4, and then it extracts the 288 external v4 address from the v6 address by striping the ::FFFF/96 289 prefix. Next it takes the payload section of the UDP or TCP packet 290 and constructs a v4 UDP or TCP payload using this destination and 291 source from the associated mapping. Then it sends the packet 292 following the procedures defined for a host to send a UDP or TCP 293 packet. Note that any IP options are lost in this process; also, as 294 defined in UDP and TCP, new checksums will be computed. 296 It is worth noting that the v4 destination address of the packet may 297 be one of the external addresses of this NAT, in which case the 298 packet is forwarded to that address and processed just like any other 299 packet arriving at this address. Packets can therefore "hairpin" 300 though the NAT. 302 5.2. UDP and TCP 4 to 6 304 When the NAT receives a UDP or TCP packet from the outside, it checks 305 to see if it has a mapping for the address port that the packet was 306 received on. If it does, it uses the internal address and port 307 associated with the mapping as the destination. It constructs a v6 308 UDP or TCP packet from the payload of the received packet and 309 forwards that to the internal address. Note that checksums are 310 updated when this new packet is created and sent. 312 If the NAT receives a TCP SYN packet for which there is no mapping it 313 SHOULD silently discard it; otherwise TCP hole punching techniques 314 using simultaneous opens will not work. 316 5.3. IP Fragmentation 318 The interaction of v4 and v6 fragmentation has some thorny issues. 319 Two possible approaches to fragmentation are proposed below to 320 facilitate discussion on the topic generally. 322 5.3.1. Option Frag-A 324 The NAT MUST support reassembly of fragmented packets when the 325 packets are received in order, but support for out of order fragments 326 is OPTIONAL. 328 If the NAT receives a v4 packet with the do not fragment bit set, it 329 MUST NOT forward it if the MTU of the v6 link would require the 330 packet to be fragmented, and the NAT MUST NOT include a fragment 331 header in the v6 packet. If the NAT receives a v4 packet that does 332 not have the do not fragment bit set, then the packet, when 333 forwarded, MUST include a fragment header; and if the packet is 334 larger than the MTU, the packet MUST be appropriately fragmented. 335 When the NAT receives a v6 packet without a fragment header, it MUST 336 set the do not fragment bit in any v4 packets, and if the resulting 337 v4 packet is larger than the MTU on the v4 link that will be used, 338 the NAT MUST NOT forward the packet. When the NAT receives a v6 339 packet with a fragment header, it can send the v4 packet without the 340 do not fragment bit set and can fragment the packet appropriately. 342 The problem with this approach is that the v6 host is likely to send 343 packets less than 1280 octets with no fragmentation header. The v4 344 side will interpret these packets as being unable to be fragmented, 345 and if they are destined for a host in which some element of the path 346 has a shorter MTU, the packet will be discarded. Regardless of any 347 ICMP errors returned, it is unlikely the application will start 348 sending packets that can be fragmented. The only practical way to 349 mitigate this situation is to have the application send most of it 350 packets with a fragmentation header, even if they are smaller than 351 1280 octets. 353 5.3.2. Option Frag-B 355 The NAT MUST support reassembly of fragmented packets when the 356 packets are received in order, but support for out of order fragments 357 is OPTIONAL. 359 When a packet is sent on a link, it must be fragmented appropriately 360 for the MTU of the link. Whether a packet received has a 361 fragmentation header in v6 or a do not fragment bit set in v4 has no 362 impact on the packets sent. 364 The problem with this approach is that it disregards the instruction 365 not to fragment, which breaks path MTU discovery mechanisms. 367 5.4. TTL 369 When a packet is forwarded, the TTL is decremented by one. If it is 370 zero, the packet is not forwarded. 372 5.5. DSCP 374 When packets pass from one side to the other, the DSCP needs to be 375 copied. If the NAT also includes diffserv classifier and marker 376 functionality it MAY change the DSCP values. See RFC 2983[RFC2983] 377 for more information. 379 5.6. ICMP 381 [[ Note - this is going to be controversial. I suspect it actually 382 goes too far but I'm deliberately presenting a pretty far out there 383 side of the argument, in the hope that it will drive a discussion 384 about what we really need, in practice, if we ignore IETF dogma. ]] 386 5.6.1. Option Yes ICMP 388 ICMP packets are translated as described in [RFC2765]. 390 5.6.2. Option No ICMP 392 ICMP can be split into two parts, the part that reports errors for 393 other transports and the part that supports exactly two applications, 394 ping and traceroute. The problem with ICMP for reporting transport 395 errors is that on today's internet ICMP is so often blocked that no 396 application can rely on ICMP working. Applications tend to be 397 designed to work without ICMP. NAT processing of ICMP packets is 398 complicated because ICMP packets may contain embedded IP packets or 399 fragments thereof. The security is further complicated by the fact 400 that a UDP or TCP packet may cause an ICMP error to be generated by a 401 host other than the host for which the original packet was destined. 402 This possibility makes it difficult to determine which ICMP packets 403 are valid and which are not. Furthermore, the way the APIs for UDP 404 are typically used makes it hard for operating systems to notify 405 applications of ICMP errors. 407 NAT processing of ICMP errors is complicated and of very limited 408 value; for that reason forwarding ICMP error messages is OPTIONAL. 409 Processing to allow ping and traceroute through the NAT is also 410 OPTIONAL 412 5.7. IPsec 414 UDP is the new thin waist of the internet. IPsec over UDP will work, 415 but other forms of IPsec will generally not work in a reliable way. 417 5.8. DCCP, SCTP, etc 419 The strong temptation is to extend this specification to support 420 these protocols. However, that path is probably doomed and would 421 just add needless complexity. The issue is, if there were ever any 422 applications to use these protocols, the applications would probably 423 want to work through the existing deployed v4 to v4 NATs, which do 424 not support these transports. As a result the new transports are not 425 useful to applications unless they are adapted to work over existing 426 NATs - most commonly by running them over UDP. 428 6. ALGs 430 6.1. DNS 432 This approach does not require any DNS ALG. The downside is that the 433 servers in the 4 to 6 case need to discover and advertise their v4 434 addresses, rather than letting the NAT and DNS automatically 435 coordinate them. One of the upsides of this design is that DNSSEC 436 can work. It is debatable whether DNSSEC will ever be widely 437 deployed, but people do seem to agree that if it was, it would be 438 very valuable for building secure internet applications. Choosing an 439 architecture that would require devices to perform man in the middle 440 attacks on the basic naming service of the internet seems like a path 441 that should be avoided if possible. 443 6.2. FTP 445 The deployment of personal firewalls and the misconfiguration of 446 other firewalls has resulted in widespread breakage of active mode 447 FTP. There is no need for an FTP ALG; use EPSV. 449 6.3. SIP 451 Many widely deployed SIP implementations work fine through NATs 452 without requiring any ALGs. SIP was not designed to work with ALGs. 453 More importantly, ALGs are not considered when designing new 454 extensions to SIP and the combination of the extensions and the ALG 455 often break badly. It is NOT RECOMMENDED for the NAT to have SIP 456 ALGs, but if SIP ALGs are insisted upon, the best approach is to 457 implement a dual homed proxy in the NAT that does v6 on one side and 458 v4 on the other. This approach will be compatible with future SIP 459 extensions and is significantly easier to correctly implement as SIP 460 was designed so this would work. 462 6.4. Others 464 Resist the temptation. They are probably not needed. 466 7. Helper Services 468 There are several services that, while not actually part of NATs, 469 greatly facilitate being able to build applications that reliably 470 work through NATs and should be logically, if not physically, 471 associated with the NAT. 473 7.1. STUN 475 The NAT must run a Basic Standalone STUN server as defined in section 476 13 of [I-D.ietf-behave-rfc3489bis], with the exception that it is NOT 477 REQUIRED that it support TCP and it is not necessary to provide a DNS 478 entry for this server. The server MUST run on the address ::FFFF: 479 127.0.0.1 with default port of 3478. [[Note, if this address hack is 480 inappropriate, this could be resolved by just defining a well known 481 v4 anycast address for STUN and using that]] 483 7.2. DNS 485 The NAT MUST provide a recursive DNS resolver that is capable of 486 taking a DNS request received from the inside and resolving it on the 487 outside. 489 [[ next point is fairly controversial - could go either way of 490 RECOMMENDING or NOT RECOMMENDING this ]] It is NOT RECOMMENDED that 491 the resolver try to take DNS A records results from the outside and 492 synthesize synthetic AAAA records that would be routed to the NAT, 493 because the application would then become unable to determine that it 494 is actually contacting a v4 host via a NAT. 496 7.3. DHCP 498 DHCP is very useful for the automated configuration of many things 499 beyond IP addresses. [[ TODO should any particular DHCP things be 500 required]] 502 7.4. V6 Routing / Tunnel 504 If a packet arrives from the inside with a v6 destination that is not 505 in the ::FFFF/96 range, the NAT could/(should/may) forward this to 506 the v6 internet. This could be via a direct v6 connection or some 507 646 tunnel. [[ Note not sure what to require / recommend here ]] 509 8. Requirement Conformance 511 8.1. RFC 4787 Requirements 513 NATs meeting this specification are compliant with the specification 514 defined for UDP NAT behavior in RFC 4787 [RFC4787], with the 515 exception that RFC 4787 requires reassembly of out of order packets 516 while this does not. 518 8.2. draft-ietf-behave-tcp Requirements 520 NATs meeting this specification are compliant with the specification 521 defined for [I-D.ietf-behave-tcp], with the exception of Req-9, which 522 requires ICMP, and Req-5, which requires that mapping of established 523 TCP connections with no traffic to stay valid for 2 hours and 4 524 minutes, while this requires only 10 minutes. 526 8.3. draft-bagnulo-v6ops-6man-nat64-pb-statement Requirements 528 Meets all the MUST support items in 529 [I-D.bagnulo-v6ops-6man-nat64-pb-statement] except the requirement in 530 R7 for ICMP support. 532 Meets all the SHOULD support items except: 534 I4 requires support for out of order fragmented packets. See 535 security consideration section in this document for more 536 discussion on this. 538 I6 - not clear whether or not all of MIPv6 works with this. 540 I7 & I8 require support for DCCP and SCTP which could be done as 541 an extension to this. 543 I9 - not clear when this does and does not work with multicast. 545 8.4. draft-nishitani-cgn Requirements 547 Meets all the requirements of [I-D.nishitani-cgn] except the 548 following: 550 R4 & R9 - require support of ICMP. 552 R5 & R6 are additional constraints on reserving ports which are 553 not mandated by this specification; but a device that was fully 554 compliant with this specification could still support these. 556 R7 & R8 are analyzed in Section 8.1 and Section 8.2. 558 8.5. Multicast 560 More analysis is needed - your mileage may vary. Some important 561 multicast applications such as an IP TV-like system that used an SSM 562 sender in the v4 space with clients in the v6 space could probably be 563 made to work fine, with little modification for v6-only clients. 564 Some other multicast scenarios with senders in both the v4 and v6 565 space probably would not work. 567 9. IANA Considerations 569 This document makes no request of IANA. 571 Note - may want to allocate a different prefix than the ::FFFF/96. 573 Note to RFC Editor: this section may be removed on publication as an 574 RFC. 576 10. Security Considerations 578 Often NATs are combined with firewalls that perform address-dependent 579 filtering (as defined in [RFC4787]) to improve security. The type of 580 NAT envisioned here is a large, carrier-grade NAT with many clients 581 behind it. Performing firewall operations at this location in the 582 topology is not particularly effective because the attacker may well 583 be on the "inside". The firewall capabilities should be provided 584 much closer to the host being protected. The benefit of having 585 mappings with address-independent filtering is that it make it 586 possible to easily run servers inside the NAT with no modification of 587 the clients outside the NAT. For this reason, this specification 588 adopts a NAT design with address-independent filtering. 590 One of the concerns about a large scale NAT that a single host inside 591 the NAT might be able to perform a DOS attack by using up a large 592 portion of the available external ports simply by creating many 593 mappings. To mitigate this, the NAT SHOULD allow a configurable 594 limit to the number of mappings that can be created by a single host 595 inside the NAT. 597 TODO - reassembly of out of order packets 599 11. Acknowledgements 601 Thanks to Dave Ward who pointed out that I and others were spending 602 too much time making this complicated and should stop talking and get 603 on with writing some drafts. 605 12. References 607 12.1. Normative References 609 [I-D.ietf-behave-rfc3489bis] 610 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 611 "Session Traversal Utilities for (NAT) (STUN)", 612 draft-ietf-behave-rfc3489bis-16 (work in progress), 613 July 2008. 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 619 (SIIT)", RFC 2765, February 2000. 621 12.2. Informative References 623 [I-D.bagnulo-v6ops-6man-nat64-pb-statement] 624 Bagnulo, M. and F. Baker, "IPv4/IPv6 Coexistence and 625 Transition: Requirements for solutions", 626 draft-bagnulo-v6ops-6man-nat64-pb-statement-01 (work in 627 progress), February 2008. 629 [I-D.ietf-behave-tcp] 630 Guha, S., "NAT Behavioral Requirements for TCP", 631 draft-ietf-behave-tcp-07 (work in progress), April 2007. 633 [I-D.nishitani-cgn] 634 Nishitani, T. and S. Miyakawa, "Carrier Grade Network 635 Address Translator (NAT) Behavioral Requirements for 636 Unicast UDP, TCP and ICMP", draft-nishitani-cgn-00 (work 637 in progress), July 2008. 639 [RFC2983] Black, D., "Differentiated Services and Tunnels", 640 RFC 2983, October 2000. 642 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 643 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 644 RFC 4787, January 2007. 646 Author's Address 648 Cullen Jennings 649 Cisco Systems 650 170 West Tasman Drive 651 Mailstop SJC-21/2 652 San Jose, CA 95134 653 USA 655 Phone: +1 408 902-3341 656 Email: fluffy@cisco.com 658 Full Copyright Statement 660 Copyright (C) The IETF Trust (2008). 662 This document is subject to the rights, licenses and restrictions 663 contained in BCP 78, and except as set forth therein, the authors 664 retain all their rights. 666 This document and the information contained herein are provided on an 667 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 668 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 669 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 670 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 671 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 672 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 674 Intellectual Property 676 The IETF takes no position regarding the validity or scope of any 677 Intellectual Property Rights or other rights that might be claimed to 678 pertain to the implementation or use of the technology described in 679 this document or the extent to which any license under such rights 680 might or might not be available; nor does it represent that it has 681 made any independent effort to identify any such rights. Information 682 on the procedures with respect to rights in RFC documents can be 683 found in BCP 78 and BCP 79. 685 Copies of IPR disclosures made to the IETF Secretariat and any 686 assurances of licenses to be made available, or the result of an 687 attempt made to obtain a general license or permission for the use of 688 such proprietary rights by implementers or users of this 689 specification can be obtained from the IETF on-line IPR repository at 690 http://www.ietf.org/ipr. 692 The IETF invites any interested party to bring to its attention any 693 copyrights, patents or patent applications, or other proprietary 694 rights that may cover technology that may be required to implement 695 this standard. Please address the information to the IETF at 696 ietf-ipr@ietf.org. 698 Acknowledgment 700 Funding for the RFC Editor function is provided by the IETF 701 Administrative Support Activity (IASA).