idnits 2.17.1 draft-mrw-behave-nat66-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 617. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 5645 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) ** Downref: Normative reference to an Informational RFC: RFC 1071 ** Downref: Normative reference to an Informational RFC: RFC 1624 ** Downref: Normative reference to an Informational RFC: RFC 3587 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE WG M. Wasserman 3 Internet-Draft Sandstorm Enterprises 4 Expires: May 7, 2009 F. Baker 5 Cisco Systems 6 November 3, 2008 8 IPv6-to-IPv6 Network Address Translation (NAT66) 9 draft-mrw-behave-nat66-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Abstract 38 This document describes a stateless, transport-agnostic IPv6-to-IPv6 39 Network Address Translation (NAT66) function that provides the 40 address independence benefit associated with IPv4-to-IPv4 NAT (NAT44) 41 while minimizing, but not completely eliminating, the problems 42 associated with NAT44. 44 This document also describes an address mapping option for NAT66 that 45 offers the topology hiding benefit associated with NAT44 at the cost 46 of additional state in the NAT66 device. 48 Table of Contents 50 1. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. NAT66 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. NAT66 Address Mapping Mechanisms . . . . . . . . . . . . . . . 6 55 5.1. Checksum-Neutral Mapping . . . . . . . . . . . . . . . . . 6 56 5.1.1. Two-Way Algorithmic Address Mapping . . . . . . . . . 7 57 5.1.2. Topology Hiding Option . . . . . . . . . . . . . . . . 9 58 6. Prefixes for Internal Addressing . . . . . . . . . . . . . . . 10 59 7. A Note on Port Mapping . . . . . . . . . . . . . . . . . . . . 11 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 63 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 11.1. Changes Between -00 and -01 . . . . . . . . . . . . . . . 12 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . . . 14 71 1. Requirements Terminology 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 2. Introduction 79 This document describes a stateless, transport-agnostic IPv6-to-IPv6 80 Network Address Translation (NAT66) function that provides the 81 address independence benefit associated with IPv4-to-IPv4 NAT (NAT44) 82 while minimizing, but not completely eliminating, the problems 83 associated with NAT44. 85 NAT66 does not include a port mapping function, and both of the 86 defined address mapping mechanisms use checksum-neutral algorithms. 87 This avoids the need for a NAT66 device to re-write transport layer 88 headers, making it feasible to deploy new or improved transport layer 89 protocols without upgrading NAT66 devices. Because NAT66 does not 90 involve re-writing transport-layer headers, NAT66 will not interfere 91 with encrypting the full IP payload in many cases. 93 The default NAT66 address mapping mechanism is purely algorithmic, so 94 NAT66 devices do not need to maintain per-node or per-connection 95 state, allowing deployment of more robust and adaptive networks than 96 can be deployed using NAT44. Since the default NAT66 mapping can be 97 performed in either direction, it does not interfere with inbound 98 connection establishment, thus allowing internal nodes to participate 99 in direct peer-to-peer applications. 101 This document also defines an address mapping option for NAT66 that 102 offers the topology hiding benefit associated with NAT44. This 103 mechanism involves the configuration or dynamic maintenance of some 104 per-node state in the NAT66 device. So, when used with this optional 105 address mapping mechanisms, NAT66 will have greater negative impact 106 on direct peer-to-peer applications, and on the robustness and 107 reliability of the network. These trade-offs are discussed later in 108 the document. 110 Although NAT66 compares favorably to NAT44 in several ways, it does 111 not eliminate all of the architectural problems associated with IPv4 112 NAT. [RFC2993]. NAT66 involves modifying IP headers in transit, so 113 it is not compatible with security mechanisms that involve end-to-end 114 encryption of the IP header or mechanisms, such as AH, that provide 115 integrity protection for the IP header. NAT66 may interfere with the 116 use of application protocols that transmit IP addresses in the 117 application-specific portion of the IP packet. These applications 118 currently require application layer gateways (ALGs) to work correctly 119 through NAT44 devices, and similar ALGs may be required for these 120 applications to work through NAT66 devices. The use of separate 121 internal and external address prefixes creates complexity for DNS 122 deployment, due the desire for internal nodes to communicate with 123 other internal nodes using internal addresses, while external nodes 124 need to obtain external addresses to communicate with the same nodes. 125 Typically, this results in the deployment of "split DNS", which has 126 it's own set of architectural implications [Ref Needed]. 128 3. Motivations 130 In defining the NAT66 mechanism, it is not our goal to encourage the 131 implementation or use of NAT66. There are significant technical 132 problems associated with the deployment of any type of NAT, and the 133 IETF does not recommend the use of NAT. We strongly encourage anyone 134 who is considering the implementation or deployment of NAT66 to read 135 RFC 4864 [RFC4864], and to carefully consider the alternatives 136 described in that document, many of which will cause fewer problems 137 than NAT66. 139 We are documenting NAT66 because we believe that some people will 140 choose to implement and deploy IPv6 NAT, in spite of our 141 recommendation not to do so. Some enterprises may choose to deploy 142 IPv6 NAT to gain provider independent internal addressing or to 143 simplify site multihoming. Others may consider the trade-offs and 144 choose IPv6 NAT as a topology hiding mechanism. In other cases, 145 administrators may choose to deploy IPv6 NAT to parallel their IPv4 146 NAT-based network architecture. Our goal is to define an IPv6-to- 147 IPv6 NAT mechanism, NAT66, that will minimize the negative impacts of 148 IPv6 NAT, in the event that some implementers do choose to implement 149 an IPv6 NAT mechanism, and some network administrators do choose to 150 deploy it. 152 4. NAT66 Overview 154 NAT66 may be implemented in an IPv6 router to map one IPv6 address 155 prefix to another IPv6 address prefix as each IPv6 packet transits 156 the router. A router that implements a NAT66 function is referred to 157 as a NAT66 device. 159 In its simplest form, a NAT66 device will be attached to two network 160 links, one of which is an "internal" network link attached to a leaf 161 network within a single administrative domain, and the other of which 162 is an "external" network with connectivity to the global Internet. 163 All of the hosts on the internal network will use addresses from a 164 single, locally-routed prefix, and those addresses will be translated 165 to/from addresses in a globally-routable prefix as IP packets transit 166 the NAT66 device. 168 The following picture shows a NAT66 device attached to two networks. 169 In this example, the internal network uses IPv6 Unique Local 170 Addresses (ULAs) [RFC4193] to represent the internal IPv6 nodes, and 171 the external network uses globally routable IPv6 addresses to 172 represent the same nodes. 174 External Network: Prefix = 2001:0DB8:0001:/48 175 -------------------------------------- 176 | 177 | 178 +---------+ 179 | NAT66 | 180 | Device | 181 +---------+ 182 | 183 | 184 -------------------------------------- 185 Internal Netowrk: Prefix = FD01:0203:0405:/48 187 When a NAT66 device forwards packets in the "outbound" direction, 188 from the internal network to the external network, NAT66 overwrites 189 the IPv6 source address (in the IPv6 header) with a corresponding 190 address from the external prefix. When packets are forwarded in the 191 "inbound" direction, from the external network to the internal 192 network, the IPv6 destination address is overwritten with a 193 corresponding address in the internal prefix. Using the prefixes 194 shown in the diagram above, as an IP packet passes through the NAT66 195 device in the outbound direction, the source address prefix (FD01: 196 0203:0405:/48) will be overwritten with the external address prefix 197 (2001:0DB8:0001:/48). In an inbound packet, the destination prefix 198 (2001:0DB8:0001:/48) will be overwritten with the internal network 199 prefix (FD01:0203:0405:/48). In both cases, it is the local IPv6 200 address that is overwritten; the remote IPv6 address remains 201 unchanged. Nodes on the internal network are said to be "behind" the 202 NAT66 device. 204 NAT66 can also be used between two private networks. In these cases, 205 both networks may use ULA prefixes, with each subnet in one network 206 mapped into a corresponding subnet in the other network, and vice 207 versa. Or, each network may use ULA prefixes for internal addressing 208 and global unicast addresses on the other network. [TBD, add 209 pictures of these examples]. 211 In some cases, more than one NAT66 device may be attached to a 212 network. In this case, they two NAT66 devices may be configured with 213 the same internal and external prefixes, or they may be configured 214 with the same internal prefix and different external prefixes. [TBD, 215 add pictures of these examples.] 217 5. NAT66 Address Mapping Mechanisms 219 This document defines two address mapping functions that can be used 220 in NAT66 devices. To comply with this specification, NAT66 devices 221 MUST implement the Two-Way Algorithmic Address Mapping. NAT66 222 devices SHOULD implement the Topology Hiding Option. 224 The Two-Way Algorithmic Address Mapping mechanism and the Topology 225 Hiding Option both use 1:1 (one-to-one) mappings, meaning that a 226 given internal address is always mapped to the same external address. 228 When the Two-Way Algorithmic mapping is used, no per-node or per-flow 229 state is maintained in the NAT66 box. Both inbound and outbound 230 packets are translated algorithmically, using only information found 231 in the IPv6 header. Due to this property, the Two-Way Algorithmic 232 Address Mapping can support both outbound and inbound connection 233 establishment without the need for state-priming or rendevous 234 mechanisms. This is a significant improvement over NAT44 devices, 235 but it also has significant security implications which are described 236 in the Security Considerations section. 238 The Topology Hiding Option is intended to obscure the subnet 239 information found in the internal IPv6 address prefix from external 240 view, so that an external node cannot determine the structure of the 241 internal network by looking at traffic outside of the NAT66 device. 242 This features is called "topology hiding", and it is one of the 243 benefits associated with NAT44. Because it is not possible to derive 244 the full internal address simply by looking at the external address, 245 the NAT66 device needs to maintain state in order to copy the correct 246 internal address into inbound packets. This also means that inbound 247 connection establishment will not work properly unless special 248 provisions are made to enable inbound connectivity, such as 249 configuring static state in the NAT66 device. 251 5.1. Checksum-Neutral Mapping 253 The NAT66 address mapping mechanisms described in this document are 254 checksum-neutral, which means that they result in IP headers that 255 will generate the same pseudo-header checksum when the checksum is 256 calculated using the standard Internet checksum [RFC1071]. Any 257 changes that are made during translation of the IPv6 prefix are 258 offset by changes to other parts of the IPv6 address. This results 259 in the transport layers (such as TCP and UDP) calculating the same 260 IPv6 pseudo header checksum for both the internal and external forms 261 of the same packet, which avoids the need for the NAT66 device to 262 modify the transport layer headers. 264 The NAT66 address mapping mechanisms both use the same technique to 265 ensure that they produce checksum-neutral transformations. When a 266 changes is made to one of the fields in the IPv6 pseudo-header 267 checksum, the checksum field in the transport layer header may become 268 invalid. Fortunately, an incremental change in the area covered by 269 the Internet standard checksum [RFC1071] will result in a well- 270 defined change to the checksum value [RFC1624]. So, a checksum 271 change caused by modifying one part of the area covered by the 272 checksum can be eliminated by making a complementary change to a 273 different 16-bit field covered by the same checksum. 275 To produce a checksum neutral transformation, the NAT66 device 276 calculates the 16-bit one's complement sum of the internal and 277 external IPv6 prefixes. The difference between the original and 278 mapped prefix checksums is calculated using 16-bit one's complement 279 arithmetic, and the difference is added to a 16-bit value in another 280 area of the local IPv6 address, thus resulting in an IPv6 header that 281 will have the same pseudo-header checksum as the original header. 282 Although the same mechanism is used to ensure that both of the NAT66 283 mappings are checksum-neutral, there are differences in which parts 284 of the IPv6 header are mapped and where the complementary change is 285 made. 287 5.1.1. Two-Way Algorithmic Address Mapping 289 The Two-Way Algorithmic Address Mapping MUST be implemented on all 290 NAT66 devices. This mapping consists of mapping an internal IPv6 291 prefix, typically a ULA, to/from an external prefix, typically a 292 globally-routable unicast address, and making a complementary 293 modification to 16 subnet bits in bits 49 through 64 of the local 294 IPv6 addresss. The same transformation is performed in both the 295 inbound and outbound directions, so the only state that is needed on 296 the NAT66 box to peform this transformation is knowledge of the 297 internal and external address prefixes in use. 299 For the network shown in the example diagram in the NAT66 Overview 300 section above, we might have the following example: 302 Internal Prefix: FD01:0203:0405:/48 External Prefix: 2001:0DB8: 304 0001:/48 306 If a node with internal address FD01:0203:0405:0001::1234 sends an 307 outbound packet through the NAT66 device, the resulting external 308 address will be 2001:0DB8:0001:D550::1234. The resulting address is 309 obtained by calculating the checksum of both the internal and 310 external 48-bit prefixes, sutracting the internal prefix from the 311 external prefix using one's complement arithmetic and adding the 312 result to the 16-bit subnet field (in this case 0x0001). 314 To show the work: 316 The one's complement checksum of FD01:0203:0405 is 0xFCF5. The one's 317 complement checksum of 2001:0DB8:0001 is 0xD245. Using one's 318 complement math, 0xD245 - 0xFCF5 = 0xD54F. The subnet mask in the 319 original packet is 0x0001. Using one's complement math, 0x0001 + 320 0xD54F = 0xD550. 322 So, the value 0xD550 is written in the 16-bit subnet mask area, 323 resulting in a mapped external address of 2001:0DB8:0001:D550::1234. 325 When a response packet is received, it will contain the destination 326 address 2001:0DB8:0001:D550::0001, which will be mapped using the 327 same mapping algorithm, back to FD01:0203:0405:0001::1234. 329 In this case, the difference between the two prefixes will be 330 calculated as follows: 332 Using one's complement math, 0xFCF5 - 0xD245 = 0x2AB0. The subnet 333 mask in the original packet = 0xD550. Using one's complement math, 334 0xD550 + 0x2AB0 = 0x0001. 336 So the value 0x0001 is written into the subnet field, and the 337 internal value of the subnet field is properly restored. 339 This mapping results in no modification of the Interface Identifier 340 (IID), which is held in the lower half of the IPv6 address, so it 341 will not interfere with future protocols that may use unique IIDs for 342 node identification. 344 Use of this mapping is restricted to cases where both the internal 345 and external prefixes are 48 bits long (a /48) or shorter, leaving at 346 least 16 subnet bits that can be modified to ensure checksum 347 neutrality. This may not be a significant limitation in practice, 348 because it is expected that most NAT66 devices will be used to map 349 between a provider-allocated external prefix of /48 or shorter and a 350 ULA that uses the same prefix length as the external prefix. In 351 cases where one or both prefixes are longer than a /48, the Topology 352 Hiding Option can be used. 354 5.1.2. Topology Hiding Option 356 The topology hiding option SHOULD be implemented on all NAT66 357 devices. It is very similar to the Two-Way Algorithmic Address 358 mapping, except that the subnet bits in the destination address are 359 mapped to zero in the outbound direction and are restored to their 360 original value in the inbound direction. To remove the restriction 361 on prefixes that have at least 16 bits of subnet space available, the 362 checksum adjustment is made in the last 16 bits of the IP header, 363 thus modifying the IPv6 Interface Identifier. Because the Interface 364 Identifier may no longer be unique, the "u" bit [RFC4291] is cleared 365 in the IID. This changes is also taken into account in the checksum 366 adjustment. 368 For the network shown in the example diagram in the NAT66 Overview 369 section above, we might have the following example: 371 Internal Prefix: FD01:0203:0405:/48 External Prefix: 2001:0DB8: 372 0001:/48 374 If a node with internal address FD01:0203:0405:0001::1234 sends an 375 outbound packet through the NAT66 device, the resulting external 376 address will be 2001:0DB8:0001:0000:0002::E782. The resulting 377 address is obtained by calculating the checksum of both the internal 378 and external 48-bit prefixes and subtracting the internal prefix 379 checsum from the external prefix checksum. If the "u" bit is cleared 380 in the original address (the IID has universal scope), set the bit in 381 the mapped address and add 0xFFFD to the checksum difference 382 calculated above. Then, add the checksum difference to the value o 383 the last 16 bits of the IPv6 address. 385 To show the work: 387 The one's complement checksum of FD01:0203:0405:0001 is 0xFCF4. The 388 one's complement checksum of 2001:0DB8:0001:0000 is 0xD245. Using 389 one's complement math, 0xD245 - 0xFCF4 = 0xD550. The original 390 address has the "u" bit clear, so 0xD550 + 0xFFFD = 0xD54E. The last 391 16 bits of the original address are 0x1234. Using one's complement 392 math, 0x1234 + 0xD54E = 0xE782. 394 So, when the prefix is mapped, the "u" bit is set in the IID, and the 395 value 0xE782 is written into the last 16 bits of the address, this 396 results in a mapped external address of 2001:0DB8:0001:0000:0002:: 397 E782. 399 When a response packet is received, it will contain the destination 400 address 2001:0DB8:0001:0000:0002::E782. Unfortunately that address 401 does not contain enough information to do an algorithmic reverse 402 transformation, as the subnet bits were zeroed out when the external 403 address was selected. Therefore, the NAT66 will need to consult its 404 internal state to perform the reverse address mapping. 406 The internal state used for this mapping could consist of dynamic 407 per-node mapping state, as is maintained in most NAT44 devices today, 408 or it could consist of a static mapping of external addresses to 409 internal addresses. If dynamic state is used, inbound connections to 410 nodes that have not yet communicated externally will fail, because 411 there will be no state to perform the inbound mapping. NAT66 412 implementations SHOULD provide a means for network administrators to 413 configure static mapping state to allow inbound mapping when the 414 Topology Hiding Option is in use. 416 Note: We could place the checksum adjustment in the 16-bit subnet 417 field, if the prefixes are /48 or less, thus avoiding the need to 418 modify the IID in those cases. Is that worth doing? We can't 419 blindly overwrite the 16-bit following prefix no matter where they 420 are, because of the need to maintain the "u" and "g" bits in the 7th 421 and 8th bits of the IID. 423 6. Prefixes for Internal Addressing 425 IPv6 includes a form of local addressing called Unique Local 426 Addresses (ULAs) [RFC4193], and it is RECOMMENDED that ULAs be used 427 to address network nodes that are located on an internal network 428 serviced by a NAT66 device. 430 NAT66 devices MUST support manual configuration of internal and 431 external address prefixes, and MUST NOT place any restrictions on 432 those prefixes except that they be valid IPv6 unicast address 433 prefixes, as described in [RFC4291], and that they meet the 434 requirements outlined in this document. 436 NAT66 devices that do not have a manually configured internal prefix 437 SHOULD randomly generate a ULA prefix for the internal network and 438 advertise that prefix in router advertisements. NAT66 boxes with 439 more than one internal interface SHOULD assign a subnet number to 440 each link, and include the subnet number in router advertisements on 441 the corresponding link. NAT66 devices that generate a ULA prefix 442 MUST generate the prefix using a random number as described in 443 RFC4291 [RFC4193], and SHOULD store the randomly generated prefix is 444 non-volatile storage for continued use. 446 7. A Note on Port Mapping 448 In addition to overwriting IP addresses when packets are forwarded, 449 NAT44 devices often overwrite the source port number in outbound 450 traffic, and the destination port number in inbound traffic. This 451 mechanism is called "port mapping". 453 The major benefit of port mapping, and perhaps its only significant 454 benefit, is that it allows multiple computers to share a single IPv4 455 address. A large number of internal IPv4 addresses (typically from 456 the 10.0.0.0/8 prefix) can be mapped into a single external, globally 457 routable IPv4 address, with the local port number used to identify 458 which internal node should receive each inbound packet. This address 459 amplification feature should not be needed in IPv6, where every 460 attached network should be assigned at least a /48 prefix, leaving 461 room for 16 subnet bits and a 64 bit Interface Identifier [RFC3587]. 463 Since port mapping requires re-writing a portion of the transport 464 layer header, it requires NAT66 devices to be aware of all of the 465 transport protocols that they forward, thus stifling the development 466 of new and improved transport protocols. Modifying the transport 467 layer header is incompatible with security mechanisms that encrypt 468 the full IP payload, and restricts the NAT66 device to forwarding 469 trasnport layers that use weak checksum algorithms that are easily 470 recalculated in routers. Since there is significant detriment caused 471 by modifying transport layer headers and very little, if any, benefit 472 to the use of port mapping in IPv6, NAT66 devices that comply with 473 this specification MUST NOT perform port mapping. 475 8. Security Considerations 477 When NAT66 is deployed using the two-way, algorithmic address 478 mapping, it allows direct inbound connections to internal nodes. 479 While this can be viewed as a benefit of NAT66 vs. NAT44, it does 480 open internal nodes to attacks that would not be possible in a NAT44 481 network. Although this situation is no worse, from a security 482 standpoint, than running IPv6 with no NAT, some enterprises may 483 assume that a NAT66 device will offer similar protection to a NAT44 484 device. For this reason, it is RECOMMENDED that NAT66 devices 485 include an IPv6 firewall function, and the firewall function SHOULD 486 be configured by default to block all incoming connections. 487 Administrators could then enable inbound connectivity for specific 488 ports by reconfiguring the firewall. 490 9. IANA Considerations 492 This document has no IANA considerations. 494 10. Acknowledgements 496 The checksum-neutral algorithmic address mapping described in this 497 document is based on e-mail written by Iljtsch Van Beijnum. A 498 similar mapping mechanism to the one described in this document was 499 previously described in a document that can be found here: http:// 500 users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf. 501 [TBD, move to an informative reference]. 503 The following people provided advice or review comments that 504 substantially improved this document: Ed Jankiewicz, . 506 This document was written using the xml2rfc tool described in RFC 507 2629 [RFC2629]. 509 11. Change Log 511 11.1. Changes Between -00 and -01 513 There were several minor changes made between the -00 and -01 514 versions of this draft: 516 o Added Fred Baker as a co-author. 518 o Minor mathematical corrections. 520 o Added AH to paragraph on NAT security issues. 522 o Added additional NAT topologies to overview (diagrams TBD). 524 12. References 526 12.1. Normative References 528 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 529 "Computing the Internet checksum", RFC 1071, 530 September 1988. 532 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 533 Incremental Update", RFC 1624, May 1994. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 539 Unicast Address Format", RFC 3587, August 2003. 541 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 542 Addresses", RFC 4193, October 2005. 544 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 545 Architecture", RFC 4291, February 2006. 547 12.2. Informative References 549 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 550 June 1999. 552 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 553 November 2000. 555 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 556 E. Klein, "Local Network Protection for IPv6", RFC 4864, 557 May 2007. 559 Authors' Addresses 561 Margaret Wasserman 562 Sandstorm Enterprises 563 14 Summer Street 564 Malden, MA 02148 565 USA 567 Phone: +1 781 333 3200 568 Email: mrw@lilacglade.org 569 URI: http://www.sandstorm.net 571 Fred Baker 572 Cisco Systems 573 Santa Barbara, California 93117 574 USA 576 Phone: +1-408-526-4257 577 Email: fred@cisco.com 579 Full Copyright Statement 581 Copyright (C) The IETF Trust (2008). 583 This document is subject to the rights, licenses and restrictions 584 contained in BCP 78, and except as set forth therein, the authors 585 retain all their rights. 587 This document and the information contained herein are provided on an 588 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 589 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 590 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 591 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 592 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Intellectual Property 597 The IETF takes no position regarding the validity or scope of any 598 Intellectual Property Rights or other rights that might be claimed to 599 pertain to the implementation or use of the technology described in 600 this document or the extent to which any license under such rights 601 might or might not be available; nor does it represent that it has 602 made any independent effort to identify any such rights. Information 603 on the procedures with respect to rights in RFC documents can be 604 found in BCP 78 and BCP 79. 606 Copies of IPR disclosures made to the IETF Secretariat and any 607 assurances of licenses to be made available, or the result of an 608 attempt made to obtain a general license or permission for the use of 609 such proprietary rights by implementers or users of this 610 specification can be obtained from the IETF on-line IPR repository at 611 http://www.ietf.org/ipr. 613 The IETF invites any interested party to bring to its attention any 614 copyrights, patents or patent applications, or other proprietary 615 rights that may cover technology that may be required to implement 616 this standard. Please address the information to the IETF at 617 ietf-ipr@ietf.org.