idnits 2.17.1 draft-mrw-nat66-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1145 has weird spacing: '...d short inner...' == Line 1147 has weird spacing: '...d short outer...' == Line 1149 has weird spacing: '...d short inner...' == Line 1150 has weird spacing: '...d short packe...' == Line 1151 has weird spacing: '...ed char chec...' == (12 more instances...) -- The document date (January 28, 2011) is 4830 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 1377 -- Looks like a reference, but probably isn't: '1' on line 1377 -- Looks like a reference, but probably isn't: '0' on line 1377 -- Looks like a reference, but probably isn't: '2' on line 1377 -- Looks like a reference, but probably isn't: '4' on line 1378 -- Looks like a reference, but probably isn't: '5' on line 1378 -- Looks like a reference, but probably isn't: '6' on line 1378 -- Looks like a reference, but probably isn't: '7' on line 1378 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wasserman 3 Internet-Draft Painless Security 4 Intended status: Experimental F. Baker 5 Expires: August 1, 2011 Cisco Systems 6 January 28, 2011 8 IPv6-to-IPv6 Network Prefix Translation 9 draft-mrw-nat66-07 11 Abstract 13 This document describes a stateless, transport-agnostic IPv6-to-IPv6 14 Network Prefix Translation (NPTv6) function that provides the address 15 independence benefit associated with IPv4-to-IPv4 NAT (NAT44), and in 16 addition provides a 1:1 relationship between addresses in the 17 "inside" and "outside" prefixes, preserving end to end reachability 18 at the network layer. 20 Requirements Terminology 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 1, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. What is Address Independence? . . . . . . . . . . . . . . 4 62 1.2. NPTv6 Applicability . . . . . . . . . . . . . . . . . . . 6 63 2. NPTv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1. NPTv6: the simplest case . . . . . . . . . . . . . . . . . 7 65 2.2. NPTv6 between peer networks . . . . . . . . . . . . . . . 8 66 2.3. NPTv6 redundnacy and load-sharing . . . . . . . . . . . . 9 67 2.4. NPTv6 multihoming . . . . . . . . . . . . . . . . . . . . 10 68 2.5. Mapping with No Per-Flow State . . . . . . . . . . . . . . 10 69 2.6. Checksum-Neutral Mapping . . . . . . . . . . . . . . . . . 11 70 3. NPTv6 Algorithmic Specification . . . . . . . . . . . . . . . 11 71 3.1. NPTv6 configuration calculations . . . . . . . . . . . . . 11 72 3.2. NPTv6 translation, internal network to external network . 12 73 3.3. NPTv6 translation, external network to internal network . 12 74 3.4. NPTv6 with a /48 or shorter prefix . . . . . . . . . . . . 13 75 3.5. NPTv6 with a /49 or longer prefix . . . . . . . . . . . . 13 76 3.6. /48 Prefix Mapping Example . . . . . . . . . . . . . . . . 13 77 3.7. Address Mapping for Longer Prefixes . . . . . . . . . . . 14 78 4. Implications of Network Address Translator Behavioral 79 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.1. Prefix configuration and generation . . . . . . . . . . . 15 81 4.2. Subnet numbering . . . . . . . . . . . . . . . . . . . . . 15 82 4.3. NAT Behavioral Requirements . . . . . . . . . . . . . . . 15 83 5. Implications for Applications . . . . . . . . . . . . . . . . 16 84 6. A Note on Port Mapping . . . . . . . . . . . . . . . . . . . . 16 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 88 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 10.1. Changes Between draft-mrw-behave-nat66-00 and -01 . . . . 18 90 10.2. Changes between *behave-nat66-01 and -02 . . . . . . . . . 18 91 10.3. Changes between *nat66-00 and *nat66-01 . . . . . . . . . 19 92 10.4. Changes between *nat66-01 and *nat66-02 . . . . . . . . . 19 93 10.5. Changes between *nat66-02 and *nat66-03 . . . . . . . . . 20 94 10.6. Changes between *nat66-03 and *nat66-04 . . . . . . . . . 20 95 10.7. Changes between *nat66-04 and *nat66-05 . . . . . . . . . 20 96 10.8. Changes between *nat66-05 and *nat66-06 . . . . . . . . . 20 97 10.9. Changes between *nat66-06 and *nat66-07 . . . . . . . . . 20 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 100 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 101 Appendix A. Why GSE? . . . . . . . . . . . . . . . . . . . . . . 22 102 Appendix B. Verification code . . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 105 1. Introduction 107 This document describes a stateless IPv6-to-IPv6 Network Prefix 108 Translation (NPTv6) function, designed to provide address 109 independence to the edge network. It is transport-agnostic with 110 respect to transports that don't checksum the IP header, such as SCTP 111 or DCCP, and to transports that use the TCP/UDP pseudo-header and 112 checksum [RFC1071]. 114 This has several ramifications: 116 o Any security benefit that NAT44 might offer is not present in 117 NPTv6, necessitating the use of a firewall to obtain those 118 benefits if desired. An example of such a firewall is described 119 in [RFC6092]. 121 o End to end reachability is preserved, although the address used 122 "inside" the edge network differs from the address used "outside" 123 the edge network. This has implications for application referrals 124 and other uses of Internet layer addresses. 126 o If there are multiple identically-configured prefix translators 127 between two networks, there is no need for them to exchange 128 dynamic state, as there is no dynamic state - the algorithmic 129 translation will be identical across each of them. The network 130 can therefore asymmetrically route, load-share, and fail-over 131 among them without issue. 133 o Since translation is 1:1 at the network layer, there is no need to 134 modify port numbers or other transport parameters. 136 1.1. What is Address Independence? 138 For the purposes of this document, IPv6 Address Independence consists 139 of the following set of properties: 141 From the perspective of the edge network: 143 * The IPv6 addresses used inside the local network (for 144 interfaces, access lists, and logs) do not need to be 145 renumbered if the global prefix(es) assigned for use by the 146 edge network are changed. 148 * The IPv6 addresses used inside the edge network (for 149 interfaces, access lists, and logs) or within other upstream 150 networks (such as when multihoming) do not need to be 151 renumbered when a site adds, drops, or changes upstream 152 networks. 154 * It is not necessary for an administration to convince an 155 upstream network to route its internal IPv6 prefixes, or for it 156 to advertise prefixes derived from other upstream networks into 157 it. 159 * Unless it wants to optimize routing between multiple upstream 160 networks in the process of multihoming, there is therefore no 161 need for a BGP exchange with the upstream network. 163 From the perspective of the upstream network: 165 * IPv6 addresses used by the edge network are guaranteed to have 166 a provider-allocated prefix, eliminating the need and concern 167 for BCP 38 [RFC2827] ingress filtering and the advertisement of 168 customer-specific prefixes. 170 Thus, address independence has ramifications for the edge network, 171 networks it directly connects with (especially its upstream 172 networks), and for the Internet as a whole. The desire for address 173 independence has been a primary driver for IPv4 NAT deployment in 174 medium to large-sized enterprise networks, including NAT deployments 175 in enterprises that have plenty of IPv4 provider-independent address 176 space (from IPv4 "swamp space"). It has also been a driver for edge 177 networks to become members of RIR communities, seeking to obtain BGP 178 Autonomous System Numbers and provider-independent prefixes, and as a 179 result has been one of the drivers of the explosion of the IPv4 route 180 table. Service providers have stated that the lack of address 181 independence from their customers has been a negative incentive to 182 deployment, due to the impact of customer routing expected in their 183 networks. 185 The Local Network Protection [RFC4864] document discusses a related 186 concept called "Address Autonomy" as a benefit of NAT44. [RFC4864] 187 indicates that address autonomy can be achieved by the simultaneous 188 use of global addresses on all nodes within a site that need external 189 connectivity, and Unique Local Addresses (ULAs) [RFC4193] for all 190 internal communication. However, this solution fails to meet the 191 requirement for address independence, because if an ISP renumbering 192 event occurs, all of the hosts, routers, DHCP servers, ACLs, 193 firewalls and other internal systems that are configured with global 194 addresses from the ISP will need to be renumbered before global 195 connectivity is fully restored. 197 The use of IPv6 Provider Independent (PI) addresses has also been 198 suggested as a means to fulfill the address independence requirement. 199 However, this solution requires that an enterprise qualify to receive 200 a PI assignment and persuade their ISP to install specific routes for 201 the enterprise's PI addresses. There are a number of practical 202 issues with this approach, especially if there is a desire to route 203 to a number of geographically and topologically diverse set of sites, 204 which can sometimes involve coordinating with several ISPs to route 205 portions of a single PI prefix. These problems have caused numerous 206 enterprises with plenty of IPv4 swamp space to choose to use IPv4 NAT 207 for part, or substantially all, of their internal network instead of 208 using their provider-independent address space. 210 1.2. NPTv6 Applicability 212 NPTv6 provides a simple and compelling solution to meet the Address 213 Independence requirement in IPv6. The address independence benefit 214 stems directly from the translation function of the network prefix 215 translator. To avoid as many of the issues associated with NAT44 as 216 possible, NPTv6 is defined to include a two-way, checksum-neutral, 217 algorithmic translation function, and nothing else. 219 NPTv6 does not include a port mapping function, and the defined 220 address mapping mechanism is checksum-neutral. This avoids the need 221 for a NPTv6 Translator to re-write transport layer headers, making it 222 feasible to deploy new or improved transport layer protocols without 223 upgrading NPTv6 Translators. Because NPTv6 does not involve re- 224 writing transport-layer headers, NPTv6 will not interfere with 225 encryption of the full IP payload in many cases. 227 The default NPTv6 address mapping mechanism is purely algorithmic, so 228 NPTv6 translators do not need to maintain per-node or per-connection 229 state, allowing deployment of more robust and adaptive networks than 230 can be deployed using NAT44. Since the default NPTv6 mapping can be 231 performed in either direction, it does not interfere with inbound 232 connection establishment, thus allowing internal nodes to participate 233 in direct Peer-to-Peer applications without the application layer 234 overhead one finds in many IPv4 Peer-to-Peer applications. 236 Although NPTv6 compares favorably to NAT44 in several ways, it does 237 not eliminate all of the architectural problems associated with IPv4 238 NAT, as described in [RFC2993]. NPTv6 involves modifying IP headers 239 in transit, so it is not compatible with security mechanisms, such as 240 the IPsec Authentication Header, that provide integrity protection 241 for the IP header. NPTv6 may interfere with the use of application 242 protocols that transmit IP addresses in the application-specific 243 portion of the IP packet. These applications currently require 244 application layer gateways (ALGs) to work correctly through NAT44 245 devices, and similar ALGs may be required for these applications to 246 work through NPTv6 Translators. The use of separate internal and 247 external prefixes creates complexity for DNS deployment, due the 248 desire for internal nodes to communicate with other internal nodes 249 using internal addresses, while external nodes need to obtain 250 external addresses to communicate with the same nodes. This 251 frequently results in the deployment of "split DNS", which may add 252 complexity to network configuration. 254 The choice of address within the edge network bears consideration. 255 One could use a ULA, which maximizes address independence. That 256 could also be considered a misuse of the ULA; if the expectation is 257 that a ULA prevents access to a system from outside the range of the 258 ULA, NPTv6 overrides that. On the other hand, the administration is 259 aware that it has made that choice, and could if it desired deploy a 260 second ULA for the purpose of privacy; the only prefix that will be 261 translated is one that has a NPTv6 Translator configured to translate 262 to or from it. Also, using any other global scope address format 263 makes one either obtain a PI prefix or be at the mercy of the agency 264 from which it was allocated. 266 There are significant technical impacts associated with the 267 deployment of any prefix translation mechanism, including NPTv6, and 268 we strongly encourage anyone who is considering the implementation or 269 deployment of NPTv6 to read [RFC4864], and to carefully consider the 270 alternatives described in that document, some of which may cause 271 fewer problems than NPTv6. 273 2. NPTv6 Overview 275 NPTv6 may be implemented in an IPv6 router to map one IPv6 address 276 prefix to another IPv6 prefix as each IPv6 packet transits the 277 router. A router that implements a NPTv6 prefix translation function 278 is referred to as an NPTv6 Translator. 280 2.1. NPTv6: the simplest case 282 In its simplest form, a NPTv6 Translator interconnects two network 283 links, one of which is an "internal" network link attached to a leaf 284 network within a single administrative domain, and the other of which 285 is an "external" network with connectivity to the global Internet. 286 All of the hosts on the internal network will use addresses from a 287 single, locally-routed prefix, and those addresses will be translated 288 to/from addresses in a globally-routable prefix as IP packets transit 289 the NPTv6 Translator. The lengths of these two prefixes will be 290 functionally the same; if they differ, the longer of the two will 291 limit the ability to use subnets in the shorter. 293 External Network: Prefix = 2001:0DB8:0001:/48 294 -------------------------------------- 295 | 296 | 297 +-------------+ 298 | NPTv6 | 299 | Translator | 300 +-------------+ 301 | 302 | 303 -------------------------------------- 304 Internal Network: Prefix = FD01:0203:0405:/48 306 Figure 1: A simple translator 308 Figure 1 shows a NPTv6 Translator attached to two networks. In this 309 example, the internal network uses IPv6 Unique Local Addresses (ULAs) 310 [RFC4193] to represent the internal IPv6 nodes, and the external 311 network uses globally routable IPv6 addresses to represent the same 312 nodes. 314 When a NPTv6 Translator forwards packets in the "outbound" direction, 315 from the internal network to the external network, NPTv6 overwrites 316 the IPv6 source prefix (in the IPv6 header) with a corresponding 317 external prefix. When packets are forwarded in the "inbound" 318 direction, from the external network to the internal network, the 319 IPv6 destination prefix is overwritten with a corresponding internal 320 prefix. Using the prefixes shown in the diagram above, as an IP 321 packet passes through the NPTv6 Translator in the outbound direction, 322 the source prefix (FD01:0203:0405:/48) will be overwritten with the 323 external prefix (2001:0DB8:0001:/48). In an inbound packet, the 324 destination prefix (2001:0DB8:0001:/48) will be overwritten with the 325 internal prefix (FD01:0203:0405:/48). In both cases, it is the local 326 IPv6 prefix that is overwritten; the remote IPv6 prefix remains 327 unchanged. Nodes on the internal network are said to be "behind" the 328 NPTv6 Translator. 330 2.2. NPTv6 between peer networks 332 NPTv6 can also be used between two private networks. In these cases, 333 both networks may use ULA prefixes, with each subnet in one network 334 mapped into a corresponding subnet in the other network, and vice 335 versa. Or, each network may use ULA prefixes for internal 336 addressing, and global unicast addresses on the other network. 338 Internal Prefix = FD01:4444:5555:/48 339 -------------------------------------- 340 V | External Prefix 341 V | 2001:0DB8:6666:/48 342 V +---------+ ^ 343 V | NPTv6 | ^ 344 V | Device | ^ 345 V +---------+ ^ 346 External Prefix | ^ 347 2001:0DB8:0001:/48 | ^ 348 -------------------------------------- 349 Internal Prefix = FD01:0203:0405:/48 351 Figure 2: Flow of Information in Translation 353 2.3. NPTv6 redundnacy and load-sharing 355 In some cases, more than one NPTv6 Translator may be attached to a 356 network, as show in Figure 3. In such cases, NPTv6 Translators are 357 configured with the same internal and external prefixes. Since there 358 is only one translation, even though there are multiple translators, 359 they map only one external address (prefix and IID) to the internal 360 address. 362 External Network: Prefix = 2001:0DB8:0001:/48 363 -------------------------------------- 364 | | 365 | | 366 +-------------+ +-------------+ 367 | NPTv6 | | NPTv6 | 368 | Translator | | Translator | 369 | #1 | | #2 | 370 +-------------+ +-------------+ 371 | | 372 | | 373 -------------------------------------- 374 Internal Network: Prefix = FD01:0203:0405:/48 376 Figure 3: Parallel Translators 378 2.4. NPTv6 multihoming 380 External Network #1: External Network #2: 381 Prefix = 2001:0DB8:0001:/48 Prefix = 2001:0DB8:5555:/48 382 --------------------------- -------------------------- 383 | | 384 | | 385 +-------------+ +-------------+ 386 | NPTv6 | | NPTv6 | 387 | Translator | | Translator | 388 | #1 | | #2 | 389 +-------------+ +-------------+ 390 | | 391 | | 392 -------------------------------------- 393 Internal Network: Prefix = FD01:0203:0405:/48 395 Figure 4: Parallel Translators with different upstream networks 397 When multihoming, NPTv6 Translators are attached to an internal 398 network, as show in Figure 4, but connected to different external 399 networks. In such cases, NPTv6 Translators are configured with the 400 same internal prefix, but different external prefixes. Since there 401 are multiple translations, they map multiple external addresses 402 (prefix and IID) to the common internal address. A system within the 403 edge network is unable to determine which external address it is 404 using apart from services such as STUN. 406 Multihoming in this sense has one negative feature as compared with 407 multihoming with a provider-independent address; when routes change 408 between NPTv6 Translators, since the upstream network changes, the 409 translated prefix can change. This would case sessions and referrals 410 dependent on it to fail as well. This is not expected to be a major 411 real issue, however, in networks where routing is generally stable. 413 2.5. Mapping with No Per-Flow State 415 When NPTv6 is used as described in this document, no per-node or per- 416 flow state is maintained in the NPTv6 Translator. Both inbound and 417 outbound packets are translated algorithmically, using only 418 information found in the IPv6 header. Due to this property, NPTv6's 419 two-way, algorithmic address mapping can support both outbound and 420 inbound connection establishment without the need for state-priming 421 or rendezvous mechanisms, or the maintenance of mapping state. This 422 is a significant improvement over NAT44 devices, but it also has 423 significant security implications which are described in the Security 424 Considerations section. 426 2.6. Checksum-Neutral Mapping 428 When a change is made to one of the IP header fields in the IPv6 429 pseudo-header checksum (such as one of the IP addresses), the 430 checksum field in the transport layer header may become invalid. 431 Fortunately, an incremental change in the area covered by the 432 Internet standard checksum [RFC1071] will result in a well-defined 433 change to the checksum value [RFC1624]. So, a checksum change caused 434 by modifying part of the area covered by the checksum can be 435 corrected by making a complementary change to a different 16-bit 436 field covered by the same checksum. 438 The NPTv6 mapping mechanisms described in this document are checksum- 439 neutral, which means that they result in IP headers that will 440 generate the same IPv6 pseudo-header checksum when the checksum is 441 calculated using the standard Internet checksum algorithm [RFC1071]. 442 Any changes that are made during translation of the IPv6 prefix are 443 offset by changes to other parts of the IPv6 address. This results 444 in transport layers that use the Internet checksum (such as TCP and 445 UDP) calculating the same IPv6 pseudo header checksum for both the 446 internal and external forms of the same packet, which avoids the need 447 for the NPTv6 Translator to modify those transport layer headers to 448 correct the checksum value. 450 As noted in Section 4.2, this mapping results in an edge network 451 using a /48 external prefix to be unable to use subnet 0xFFFF. 453 3. NPTv6 Algorithmic Specification 455 The [RFC4291] IPv6 Address is reproduced for clarity in Figure 5. 457 0 15 16 31 32 47 48 63 64 79 80 95 96 111 112 127 458 +-------+-------+-------+-------+-------+-------+-------+-------+ 459 | Routing Prefix | Subnet| Interface Identifier (IID) | 460 +-------+-------+-------+-------+-------+-------+-------+-------+ 462 Figure 5: Enumeration of the IPv6 Address [RFC4291] 464 3.1. NPTv6 configuration calculations 466 When an NPTv6 Translation function is configured, it is configured 467 with 469 o one or more "internal" interfaces with their "internal" routing 470 domain prefixes, and 472 o one or more "external" interfaces with their "external" routing 473 domain prefixes. 475 In the simple case, there is one of each. If a single router 476 provides NPTv6 translation services between a multiplicity of domains 477 (as might be true when multihoming), each internal/external pair must 478 be thought of as a separate NPTv6 Translator from the perspective of 479 this specification. 481 When an NPTv6 Translator is configured, the translation function 482 first ensures that the internal and external prefixes are the same 483 length, if necessary by extending the shorter of the two with zeroes. 484 These two prefixes will be used in the prefix translation function 485 described in Section 3.2 and Section 3.3. 487 They are then zero-extended to /64, for the purposes of a 488 calculation. The translation function calculates the ones-complement 489 sum of the 16 bit words of the /64 external prefix and the /64 490 internal prefix. It then calculates the difference between these 491 values: internal minus external. This value, called the 492 "adjustment", is effectively constant for the lifetime of the NPTv6 493 Translator configuration, and used in per-packet processing. 495 3.2. NPTv6 translation, internal network to external network 497 When a datagram passes through the NPTv6 Translator from an internal 498 to an external network, its IPv6 Source Address is changed in two 499 ways: 501 o If the internal subnet number has no mapping, such as being 0xFFFF 502 or simply not mapped, discard the datagram. This SHOULD result in 503 an ICMP Destination Unreachable. 505 o The internal prefix is overwritten with the external prefix, in 506 effect subtracting the difference between the two checksums (the 507 adjustment) from the pseudo-header's checksum, and 509 o A 16-bit word of the address has the adjustment added to it using 510 one's complement arithmetic. If the result is 0xFFFF, it is 511 overwritten as zero. The choice of word is as specified in 512 Section 3.4 or Section 3.5 as appropriate. 514 3.3. NPTv6 translation, external network to internal network 516 When a datagram passes through the NPTv6 Translator from an external 517 to an internal network, its IPv6 Destination Address is changed in 518 two ways: 520 o The external prefix is overwritten with the internal prefix, in 521 effect adding the difference between the two checksums (the 522 adjustment) to the pseudoheader's checksum, and 524 o A 16-bit word of the address has the adjustment subtracted from it 525 (bitwise inverted and added to it) it using one's complement 526 arithmetic. If the result is 0xFFFF, it is overwritten as zero. 527 The choice of word is as specified in Section 3.4 or Section 3.5 528 as appropriate. 530 3.4. NPTv6 with a /48 or shorter prefix 532 When a NPTv6 Translator is configured with internal and external 533 prefixes that are 48 bits in length (a /48) or shorter, the 534 adjustment MUST be added to or subtracted from bits 48..63 of the 535 address. 537 This mapping results in no modification of the Interface Identifier 538 (IID), which is held in the lower half of the IPv6 address, so it 539 will not interfere with future protocols that may use unique IIDs for 540 node identification. 542 NPTv6 Translator implementations MUST implement the /48 mapping. 544 3.5. NPTv6 with a /49 or longer prefix 546 When a NPTv6 Translator is configured with internal and external 547 prefixes that are longer than 48 bits in length (such as a /52, /56, 548 or /60), the adjustment must be added to or subtracted from one of 549 the words in bits 64..79, 80..95, 96..111, or 112..127 of the 550 address. While the choice of word is immaterial as long as it is 551 consistent, for consistency's sake, these words MUST be inspected in 552 that sequence, and the first that is not initially 0xFFFF chosen. 554 NPTv6 Translator implementations SHOULD implement the mapping for 555 longer prefixes. 557 3.6. /48 Prefix Mapping Example 559 For the network shown in Figure 1, the Internal Prefix is FD01:0203: 560 0405:/48, and the External Prefix is 2001:0DB8:0001:/48 562 If a node with internal address FD01:0203:0405:0001::1234 sends an 563 outbound packet through the NPTv6 Translator, the resulting external 564 address will be 2001:0DB8:0001:D550::1234. The resulting address is 565 obtained by calculating the checksum of both the internal and 566 external 48-bit prefixes, subtracting the internal prefix from the 567 external prefix using one's complement arithmetic to calculate the 568 "adjustment", and adding the adjustment to the 16-bit subnet field 569 (in this case 0x0001). 571 To show the work: 573 The one's complement checksum of FD01:0203:0405 is 0xFCF5. The one's 574 complement checksum of 2001:0DB8:0001 is 0xD245. Using one's 575 complement arithmetic, 0xD245 - 0xFCF5 = 0xD54F. The subnet in the 576 original packet is 0x0001. Using one's complement arithmetic, 0x0001 577 + 0xD54F = 0xD550. Since 0xD550 != 0xFFFF, it is not changed to 578 0x0000. 580 So, the value 0xD550 is written in the 16-bit subnet area, resulting 581 in a mapped external address of 2001:0DB8:0001:D550::1234. 583 When a response packet is received, it will contain the destination 584 address 2001:0DB8:0001:D550::0001, which will be mapped using the 585 inverse mapping algorithm, back to FD01:0203:0405:0001::1234. 587 In this case, the difference between the two prefixes will be 588 calculated as follows: 590 Using one's complement arithmetic, 0xFCF5 - 0xD245 = 0x2AB0. The 591 subnet in the original packet = 0xD550. Using one's complement 592 arithmetic, 0xD550 + 0x2AB0 = 0x0001. Since 0x0001 != 0xFFFF, it is 593 not changed to 0x0000. 595 So the value 0x0001 is written into the subnet field, and the 596 internal value of the subnet field is properly restored. 598 3.7. Address Mapping for Longer Prefixes 600 If the prefix being mapped is longer than 48 bits, the algorithm is 601 slightly more complex. A common case will be that the internal and 602 external prefixes are of different length. In such a case, the 603 shorter prefix is zero-extended to the length of the longer as 604 described in Section 3.1 for the purposes of overwriting the prefix. 605 Then, they are both zero-extended to 64 bits to facilitate one's 606 complement arithmetic. The "adjustment" is calculated using those 64 607 bit prefixes. 609 For example if the internal prefix is a /48 ULA and the external 610 prefix is a /56 provider-allocated prefix, the ULA becomes a /56 with 611 zeros in bits 48..55. For purposes of one's complement arithmetic, 612 they are then both zero-extended to 64 bits. A side-effect of this 613 is that a subset of the subnets possible in the shorter prefix are 614 untranslatable. While the security value of this is debatable, the 615 administration may choose to use them for subnets that it knows need 616 no external accessibility. 618 We then find the first word in the IID that does not have the value 619 0xFFFF, trying bits 64..79, and then 80..95, 96..111, and finally 620 112..127. We perform the same calculation (with the same proof of 621 correctness) as in Section 3.6, but applying it to that word. 623 Although any 16-bit portion of an IPv6 IID could contain 0xFFFF, an 624 IID of all-ones is a reserved anycast identifier that should not be 625 used on the network [RFC2526]. If a NPTv6 Translator discovers a 626 packet with an IID of all-zeros while performing address mapping, 627 that packet MUST be dropped, and an ICMPv6 Parameter Problem error 628 SHOULD be generated [RFC4443]. 630 Note: this mechanism does involve modification of the IID; it may not 631 be compatible with future mechanisms that use unique IIDs for node 632 identification. 634 4. Implications of Network Address Translator Behavioral Requirements 636 4.1. Prefix configuration and generation 638 NPTv6 Translators MUST support manual configuration of internal and 639 external prefixes, and MUST NOT place any restrictions on those 640 prefixes except that they be valid IPv6 unicast prefixes as described 641 in [RFC4291]. They MAY also support random generation of ULA 642 addresses on command. Since the most common place anticipated for 643 the implementation of an NPTv6 Translator is a CPE router, the reader 644 is urged to consider the requirements of 645 [I-D.ietf-v6ops-ipv6-cpe-router]. 647 4.2. Subnet numbering 649 For reasons detailed in Appendix B, a network using NPTv6 Translation 650 and a /48 external prefix MUST NOT use the value 0xFFFF to designate 651 a subnet that it expects to be translated. 653 4.3. NAT Behavioral Requirements 655 NPTv6 Translators MUST support hairpinning behavior, as defined in 656 the NAT Behavioral Requirements for UDP document [RFC4787]. This 657 means that when a NPTv6 Translator receives a packet on the internal 658 interface that has a destination address that matches the site's 659 external prefix, it will translate the packet and forward it 660 internally. This allows internal nodes to reach other internal nodes 661 using their external, global addresses when necessary. 663 Conceptually, the datagram leaves the domain (is translated as 664 described in Section 3.2), and returns (is again translated as 665 described in Section 3.3). As a result, the datagram exchange will 666 be through the NPTv6 Translator in both directions for the lifetime 667 of the session. The alternative would be to require the NPTv6 668 Translator to drop the datagram, forcing the sender to use the 669 correct internal prefix for its peer. Performing only the external- 670 to-internal translation results in the datagram being sent from the 671 untranslated internal address of the source to the translated and 672 therefore internal address of its peer, which would enable the 673 session to bypass the NPTv6 Translator for future datagrams. It 674 would also mean that the original sender would be unlikely to 675 recognize the response when it arrived. 677 Because NPTv6 does not perform port mapping and uses a one-to-one, 678 reversible mapping algorithm, none of the other NAT behavioral 679 requirements apply to NPTv6. 681 5. Implications for Applications 683 The use of NPTv6 Transition technology makes a capability available 684 to Applications (and the networks that contain them) that is not 685 readily possible in a NAT44 network. This is the ability to position 686 an externally-accessible application within the "internal" network. 687 In an IPv4 network using NAT44, an externally-accessible application 688 must be positioned on systems with global addresses, forcing the edge 689 network to obtain global address allocation; if the application can 690 be in the translated routing domain, it automatically has an address 691 in each of its upstream prefixes without the edge network obtaining 692 such. However, there must be a means for the application to know 693 what addresses are usable. Reasons include at least advertisement in 694 DNS (which might be done statically if DNS is directly maintained by 695 the administration, or from the end system if Dynamic DNS is in use). 696 If referrals and other uses of network layer addressing do not use 697 names, then the application needs a means to determine what addresses 698 are relevant, whether from DNS or another means. 700 The means of address discovery is not within the scope of this 701 specification. 703 6. A Note on Port Mapping 705 In addition to overwriting IP addresses when packets are forwarded, 706 NAPT44 devices overwrite the source port number in outbound traffic, 707 and the destination port number in inbound traffic. This mechanism 708 is called "port mapping". 710 The major benefit of port mapping is that it allows multiple 711 computers to share a single IPv4 address. A large number of internal 712 IPv4 addresses (typically from one of the [RFC1918] private address 713 spaces) can be mapped into a single external, globally routable IPv4 714 address, with the local port number used to identify which internal 715 node should receive each inbound packet. This address amplification 716 feature is not generally foreseen as a necessity at this time. 718 Since port mapping requires re-writing a portion of the transport 719 layer header, it requires NAPT44 devices to be aware of all of the 720 transport protocols that they forward, thus stifling the development 721 of new and improved transport protocols and preventing the use of 722 IPsec encryption. Modifying the transport layer header is 723 incompatible with security mechanisms that encrypt the full IP 724 payload, and restricts the NAPT44 to forwarding transport layers that 725 use weak checksum algorithms that are easily recalculated in routers. 727 Since there is significant detriment caused by modifying transport 728 layer headers and very little, if any, benefit to the use of port 729 mapping in IPv6, NPTv6 Translators that comply with this 730 specification MUST NOT perform port mapping. 732 7. Security Considerations 734 When NPTv6 is deployed using either of the two-way, algorithmic 735 mappings defined in the document, it allows direct inbound 736 connections to internal nodes. While this can be viewed as a benefit 737 of NPTv6 vs. NAT44, it does open internal nodes to attacks that would 738 be more difficult in a NAT44 network. Although this situation is not 739 substantially worse, from a security standpoint, than running IPv6 740 with no NAT, some enterprises may assume that a NPTv6 Translator will 741 offer similar protection to a NAT44 device. 743 The port mapping mechanism in NAT44 implementations require that 744 state be created in both directions. This has lead to an industry- 745 wide perception that NAT functionality is the same as a stateful 746 firewall. It is not. The translation function of the NAT only 747 creates dynamic state in one direction and has no policy. For this 748 reason, it is RECOMMENDED that NPTv6 Translators also implement 749 firewall functionality such as described in [RFC6092], with 750 appropriate configuration options including turning it on or off. 752 When [RFC4864] talks about randomizing the subnet identifier, the 753 idea is to make it harder for worms to guess a valid subnet 754 identifier at an advertised network prefix. This should not be 755 interpreted as endorsing concealing the subnet identifier behind the 756 obfuscating function of a translator such as NPTv6. [RFC4864] 757 specifically talks about how to obtain the desired properties of 758 concealment without using a translator. Topology hiding when using 759 NAT is often ineffective in environments where the topology is 760 visible in application layer messaging protocols such as DNS, SIP, 761 SMTP, etc. If the information were not available through the 762 application layer, [RFC2993] would not be valid. 764 8. IANA Considerations 766 This document has no IANA considerations. 768 9. Acknowledgements 770 The checksum-neutral algorithmic address mapping described in this 771 document is based on e-mail written by Iljtsch Van Beijnum. 773 The following people provided advice or review comments that 774 substantially improved this document: Christian Huitema, Dave Thaler, 775 Ed Jankiewicz, Eric Kline, Iljtsch Van Beijnum, Jari Arkko, Mark 776 Townsley, Merike Kaeo, Ralph Droms, Remi Depres, Steve Blake, and 777 Tony Hain. 779 This document was written using the xml2rfc tool described in RFC 780 2629 [RFC2629]. 782 10. Change Log 784 10.1. Changes Between draft-mrw-behave-nat66-00 and -01 786 There were several minor changes made between the *behave-nat66-00 787 and -01 versions of this draft: 789 o Added Fred Baker as a co-author. 791 o Minor arithmetic corrections. 793 o Added AH to paragraph on NAT security issues. 795 o Added additional NAT topologies to overview (diagrams TBD). 797 10.2. Changes between *behave-nat66-01 and -02 799 There were further changes made between *behave-nat66-01 and -02: 801 o Removed topology hiding mechanism. 803 o Added diagrams. 805 o Made minor updates based on mailing list feedback. 807 o Added discussion of IPv6 SAF document. 809 o Added applicability section. 811 o Added discussion of Address Independence requirement. 813 o Added hairpinning requirement and discussion of applicability of 814 other NAT behavioral requirements. 816 10.3. Changes between *nat66-00 and *nat66-01 818 There were further changes made between nat66-01 and nat66-02: 820 o Added mapping for prefixes longer than /48. 822 o Change draft name to remove reference to the behave WG. 824 o Resolved various open issues and fixed typos. 826 10.4. Changes between *nat66-01 and *nat66-02 828 o Change the acronym "NAT66" to "NPTv6", so people don't read "NAT" 829 and MEGO. 831 o Change the term used to refer to the function from "NAT66 device" 832 to "NPTv6 Translator". It's not a "device" function, it's a 833 function that is applied between two interfaces. Consider a 834 router with two upstreams and two legs in the local network; it 835 will not translate between the local legs, but will translate to 836 and from each upstream, and be configured differently for each of 837 the two ISPs. 839 o Comment specifically on the security aspects. 841 o Comment specifically on the application issues raised on this 842 list. 844 o Comment specifically on multihoming, load-sharing, and asymmetric 845 routing. 847 o Spell out the hairpinning requirement and its implications. 849 o Spell out the service provider side of Address Independence. 851 o 00 focuses on the edge's view 853 o Detail the algorithm in a manner clearer to the implementor (I 854 think) 856 o Spell out the case for GSE-style DMZs between the edge and the 857 transit network, which is about the implications for the global 858 routing table. 860 o Refer to [RFC6092] as a CPE firewall description. 862 10.5. Changes between *nat66-02 and *nat66-03 864 o Added an appendix on Verification code 866 o Various minor markups in response to Ralph Droms 868 10.6. Changes between *nat66-03 and *nat66-04 870 o Markups in response to Christian Huitema, mostly surrounding the 871 issue of subnet 0xFFFF. 873 o Refer to [I-D.ietf-v6ops-ipv6-cpe-router] for CPE router 874 requirements. 876 10.7. Changes between *nat66-04 and *nat66-05 878 o Update statistics in appendix A per BGP report of 17 December 2010 880 o Update security considerations using text supplied by Merike Kaeo. 882 10.8. Changes between *nat66-05 and *nat66-06 884 o restore a code snippet inadvertently removed in version -05 886 10.9. Changes between *nat66-06 and *nat66-07 888 o Changed requested status to experimental 890 o Incorporated comments from Eric Kline 892 11. References 893 11.1. Normative References 895 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 896 Requirement Levels", BCP 14, RFC 2119, March 1997. 898 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 899 Addresses", RFC 2526, March 1999. 901 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 902 Addresses", RFC 4193, October 2005. 904 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 905 Architecture", RFC 4291, February 2006. 907 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 908 Message Protocol (ICMPv6) for the Internet Protocol 909 Version 6 (IPv6) Specification", RFC 4443, March 2006. 911 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 912 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 913 RFC 4787, January 2007. 915 11.2. Informative References 917 [GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture 918 for IPv6", February 1997, 919 . 921 [I-D.ietf-v6ops-ipv6-cpe-router] 922 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 923 Troan, "Basic Requirements for IPv6 Customer Edge 924 Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in 925 progress), December 2010. 927 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 928 "Computing the Internet checksum", RFC 1071, 929 September 1988. 931 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 932 Incremental Update", RFC 1624, May 1994. 934 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 935 E. Lear, "Address Allocation for Private Internets", 936 BCP 5, RFC 1918, February 1996. 938 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 939 June 1999. 941 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 942 Defeating Denial of Service Attacks which employ IP Source 943 Address Spoofing", BCP 38, RFC 2827, May 2000. 945 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 946 November 2000. 948 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 949 E. Klein, "Local Network Protection for IPv6", RFC 4864, 950 May 2007. 952 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 953 Customer Premises Equipment (CPE) for Providing 954 Residential IPv6 Internet Service", RFC 6092, 955 January 2011. 957 Appendix A. Why GSE? 959 For the purpose of this discussion, let us over-simplify the 960 Internet's structure by distinguishing between two broad classes of 961 networks: transit and edge. A "transit network", in this context, is 962 a network that provides connectivity services to other networks. Its 963 AS number may show up in a non-final position in BGP AS paths, or in 964 the case of mobile and residential broadband networks, it may offer 965 network services to smaller networks that can't justify RIR 966 membership. An "edge network", in contrast, is any network that is 967 not a transit network; it is the ultimate customer, and while it 968 provides internal connectivity for its own use, it is in other 969 respects is a consumer of transit services. In terms of routing, a 970 network in the transit domain generally needs some way to make 971 choices about how it routes to other networks; an edge network is 972 generally quite satisfied with a simple default route. 974 The [GSE] proposal, and as a result this proposal (which is similar 975 to GSE in most respects and inspired by it), responds directly to 976 current concerns in the RIR communities. Edge networks are used to 977 an environment in IPv4 in which their addressing is disjoint from 978 that of their upstream transit networks; it is either provider 979 independent, or a network prefix translator makes their external 980 address distinct from their internal address, and they like the 981 distinction. In IPv6, there is a mantra that edge network addresses 982 should be derived from their upstream, and if they have multiple 983 upstreams, edge networks are expected to design their networks to use 984 all of those prefixes equivalently. They see this as unnecessary and 985 unwanted operational complexity, and are as a result pushing very 986 hard in the RIR communities for provider independent addressing. 988 Widespread use of provider independent addressing has a natural and 989 perhaps unavoidable side-effect that is likely to be very expensive 990 in the long term. It means that the routing table will enumerate the 991 networks at the edge of the transit domain, the edge networks, rather 992 than enumerating the transit domain. Per the BGP Update Report of 17 993 December 2010, there are currently over 36,000 Autonomous Systems 994 being advertised in BGP, of which over 15,000 advertise only one 995 prefix. There are in the neighborhood of 5000 AS's that show up in a 996 non-final position in AS paths, and perhaps another 5000 networks 997 whose AS numbers are terminal in more than one AS path. In other 998 words, we have prefixes for some 36,000 transit and edge networks in 999 the route table now, many of which arguably need an Autonomous System 1000 number only for multihoming. Current estimates suggest that we could 1001 easily see that be on the order of 10,000,000 within fifteen years. 1002 Tens of thousands of entries in the 36,264 Autonomous Systems being 1003 advertised in BGP, of which 31,137 provide no visible transit service 1004 to another AS, and 23,595 of those are visible in only one AS path 1005 (have only one upstream network). In addition, of the 36,264 AS's in 1006 the world, 15,439 advertise only a single prefix. In other words, we 1007 have prefixes for some 36,000 transit and edge networks in the route 1008 table now, many of which arguably need an Autonomous System number 1009 only for multihoming. However, the vast majority of networks (2/3) 1010 having the tools necessary to multihome are not visibly doing so, and 1011 would be well served by any solution that gives them address 1012 independence without the overhead of RIR membership and BGP routing. 1014 Current growth estimates suggest that we could easily see that be on 1015 the order of 10,000,000 within fifteen years. Tens of thousands of 1016 entries in the route table is very survivable; while our protocols 1017 and computers will likely do quite well with tens of millions of 1018 routes, the heat produced and power consumed by those routers, and 1019 the inevitable impact on the cost of those routers, is not a good 1020 outcome. To avoid having a massive and unscalable route table, we 1021 need to find a way that is politically acceptable and returns us to 1022 enumerating the transit domain, not the edge. 1024 There have been a number of proposals. As described, shim6 moves the 1025 complexity to the edge, and the edge is rebelling. Geographic 1026 addressing in essence forces ISPs to "own" geographic territory from 1027 a routing perspective, as otherwise there is no clue in the address 1028 as to what network a datagram should be delivered to in order to 1029 reach it. Metropolitan Addressing can imply regulatory authority, 1030 and even if it is implemented using internet exchange consortia, 1031 visits a great deal of complexity on the transit networks that 1032 directly serve the edge. The one that is likely to be most 1033 acceptable is any proposal that enables an edge network to be 1034 operationally independent of its upstreams, with no obligation to 1035 renumber when it adds, drops, or changes ISPs, and with no additional 1036 burden placed either on the ISP or the edge network as a result. 1037 From an application perspective, an additional operational 1038 requirement in the words of US NIST's Roadmap for the Smart Grid, is 1039 that 1041 "...the Network should enable an application in a particular 1042 domain to communicate with an application in any other domain in 1043 the information network, with proper management control over who 1044 and where applications can be interconnected." 1046 In other words, the structure of the network should allow for and 1047 enable appropriate access control, but the structure of the network 1048 should not inherently limit access. 1050 The GSE model, by statelessly translating the prefix between an edge 1051 network and its upstream transit network, accomplishes that with a 1052 minimum of fuss and bother. Stated in the simplest terms, it enables 1053 the edge network to behave as if it has a provider-independent prefix 1054 from a multihoming and renumbering perspective without the overhead 1055 of RIR membership or maintaining BGP connectivity, and it enables the 1056 transit networks to aggressively aggregate what are from their 1057 perspective provider-allocated customer prefixes, to maintain a 1058 rational-sized routing table. 1060 Appendix B. Verification code 1062 This non-normative appendix is presented as a proof of concept. It 1063 is in no sense optimized; for example, one's complement arithmetic is 1064 implemented in portable subroutines, where operational 1065 implementations might use one's complement arithmetic instructions 1066 through a pragma; such implementations probably need to explicitly 1067 force 0xFFFF to 0x0000, as the instruction will not. The original 1068 purpose of the code was to verify whether or not it was necessary to 1069 suppress 0xFFFF by overwriting with zero, and whether predicted 1070 issues with subnet numbering were real. 1072 The point is to 1074 o demonstrate that if one or the other representation of zero is not 1075 used in the word the checksum is updated in, the program maps 1076 inner and outer addresses in a manner that is, mathematically, 1:1 1077 and onto (each inner address maps to a unique outer address, and 1078 that outer address maps back to exactly the same inner address), 1079 and 1081 o give guidance on the suppression of 0xFFFF checksums. 1083 In short, in one's complement arithmetic, x-x=0, but will take the 1084 negative representation of zero. If 0xFFFF results are forced to the 1085 value 0x0000, as is recommended in [RFC1071], the word the checksum 1086 is adjusted in cannot be initially 0xFFFF, as on the return it will 1087 be forced to 0. If 0xFFFF results are not forced to the value 0x0000 1088 as is recommended in [RFC1071], the word the checksum is adjusted in 1089 cannot be initially 0, as on the return it will be calculated as 1090 0+(~0) = 0xFFFF. We chose to follow [RFC1071]'s recommendations, 1091 which implies a requirement to not use 0xFFFF as a subnet number in 1092 networks with a /48 external prefix. 1094 /* 1095 * Copyright (c) 2010 IETF Trust and the persons identified as 1096 * authors of the code. All rights reserved. Redistribution 1097 * and use in source and binary forms, with or without 1098 * modification, are permitted provided that the following 1099 * conditions are met: 1100 * 1101 * o Redistributions of source code must retain the above 1102 * copyright notice, this list of conditions and the 1103 * following disclaimer. 1104 * 1105 * o Redistributions in binary form must reproduce the above 1106 * copyright notice, this list of conditions and the 1107 * following disclaimer in the documentation and/or other 1108 * materials provided with the distribution. 1109 * 1110 * o Neither the name of Internet Society, IETF or IETF Trust, 1111 * nor the names of specific contributors, may be used to 1112 * endorse or promote products derived from this software 1113 * without specific prior written permission. 1114 * 1115 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 1116 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 1117 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 1118 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 1119 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR 1120 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1121 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 1122 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 1123 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 1124 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 1125 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 1126 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 1127 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1128 */ 1129 #include "stdio.h" 1130 #include "assert.h" 1131 /* 1132 * program to verify the NPTv6 algorithm 1133 * 1134 * argument: 1135 * perform negative zero suppression: boolean 1136 * 1137 * method: 1138 * We specify an internal and an external prefix. The prefix 1139 * length is presumed to be the common length of both, and for 1140 * this is a /48. We perform the three algorithms specified. 1141 * the "packet" address is in effect the source address 1142 * internal->external and the destination address 1143 * external->internal. 1144 */ 1145 unsigned short inner_init[] = { 1146 0xFD01, 0x0203, 0x0405, 1, 2, 3, 4, 5}; 1147 unsigned short outer_init[] = { 1148 0x2001, 0x0db8, 0x0001, 1, 2, 3, 4, 5}; 1149 unsigned short inner[8]; 1150 unsigned short packet[8]; 1151 unsigned char checksum[65536] = {0}; 1152 unsigned short outer[8]; 1153 unsigned short adjustment; 1154 unsigned short suppress; 1155 /* 1156 * One's complement sum. 1157 * return number1 + number2 1158 */ 1159 unsigned short 1160 add1(number1, number2) 1161 unsigned short number1; 1162 unsigned short number2; 1163 { 1164 unsigned int result; 1166 result = number1; 1167 result += number2; 1168 if (suppress) { 1169 while (0xFFFF <= result) { 1170 result = result + 1 - 0x10000; 1171 } 1172 } else { 1173 while (0xFFFF < result) { 1174 result = result + 1 - 0x10000; 1175 } 1176 } 1177 return result; 1178 } 1179 /* 1180 * One's complement difference 1181 * return number1 - number2 1182 */ 1183 unsigned short 1184 sub1(number1, number2) 1185 unsigned short number1; 1186 unsigned short number2; 1187 { 1188 return add1(number1, ~number2); 1189 } 1191 /* 1192 * return one's complement sum of an array of numbers 1193 */ 1194 unsigned short 1195 sum1(numbers, count) 1196 unsigned short *numbers; 1197 int count; 1198 { 1199 unsigned int result; 1201 result = *numbers++; 1202 while (--count > 0) { 1203 result += *numbers++; 1204 } 1206 if (suppress) { 1207 while (0xFFFF <= result) { 1208 result = result + 1 - 0x10000; 1209 } 1210 } else { 1211 while (0xFFFF < result) { 1212 result = result + 1 - 0x10000; 1213 } 1214 } 1215 return result; 1216 } 1218 /* 1219 * NPTv6 initialization: section 3.1 assuming section 3.4 1220 * 1221 * create the /48, a source address in internal format, and a 1222 * source address in external format. calculate the adjustment 1223 * if one /48 is overwritten with the other. 1224 */ 1225 void 1226 nptv6_initialization(subnet) 1227 unsigned short subnet; 1228 { 1229 int i; 1230 unsigned short inner48; 1231 unsigned short outer48; 1233 /* initialize the internal and external prefixes. */ 1234 for (i = 0; i < 8; i++) { 1235 inner[i] = inner_init[i]; 1236 outer[i] = outer_init[i]; 1237 } 1238 inner[3] = subnet; 1239 outer[3] = subnet; 1240 /* calculate the checksum adjustment */ 1241 inner48 = sum1(inner, 3); 1242 outer48 = sum1(outer, 3); 1243 adjustment = sub1(inner48, outer48); 1244 } 1246 /* 1247 * NPTv6 packet from edge to transit: section 3.2 assuming 1248 * section 3.4 1249 * 1250 * overwrite the prefix in the source address with the outer 1251 * prefix, and adjust the checksum 1252 */ 1253 void 1254 nptv6_inner_to_outer() 1255 { 1256 int i; 1258 /* let's get the source address into the packet */ 1259 for (i = 0; i < 8; i++) { 1260 packet[i] = inner[i]; 1261 } 1263 /* overwrite the prefix with the outer prefix */ 1264 for (i = 0; i < 3; i++) { 1265 packet[i] = outer[i]; 1266 } 1268 /* adjust the checksum */ 1269 packet[3] = add1(packet[3], adjustment); 1270 } 1272 /* 1273 * NPTv6 packet from transit to edge:: section 3.3 assuming 1274 * section 3.4 1275 * 1276 * overwrite the prefix in the destination address with the 1277 * inner prefix, and adjust the checksum 1278 */ 1279 void 1280 nptv6_outer_to_inner() 1281 { 1282 int i; 1284 /* overwrite the prefix with the outer prefix */ 1285 for (i = 0; i < 3; i++) { 1286 packet[i] = inner[i]; 1287 } 1289 /* adjust the checksum */ 1290 packet[3] = sub1(packet[3], adjustment); 1291 } 1293 /* 1294 * main program 1295 */ 1296 main(argc, argv) 1297 int argc; 1298 char **argv; 1299 { 1300 unsigned subnet; 1301 int i; 1303 if (argc < 2) { 1304 fprintf(stderr, "usage: nptv6 supression\n"); 1305 assert(0); 1306 } 1307 suppress = atoi(argv[1]); 1308 assert(suppress <= 1); 1310 for (subnet = 0; subnet < 0x10000; subnet++) { 1311 /* section 3.1: initialize the system */ 1312 nptv6_initialization(subnet); 1314 /* section 3.2: take a packet from inside to outside */ 1315 nptv6_inner_to_outer(); 1317 /* the resulting checksum value should be unique */ 1318 if (checksum[subnet]) { 1319 printf("inner->outer duplicated checksum: " 1320 "inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) " 1321 "calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n", 1322 inner[0], inner[1], inner[2], inner[3], 1323 inner[4], inner[5], inner[6], inner[7], 1324 sum1(inner, 8), 1325 packet[0], packet[1], packet[2], packet[3], 1326 packet[4], packet[5], packet[6], packet[7], 1327 sum1(packet, 8)); 1328 } 1330 checksum[subnet] = 1; 1332 /* 1333 * the resulting checksum should be the same as the inner 1334 * address's checksum 1335 */ 1336 if (sum1(packet, 8) != sum1(inner, 8)) { 1337 printf("inner->outer incorrect: " 1338 "inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) " 1339 "calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n", 1340 inner[0], inner[1], inner[2], inner[3], 1341 inner[4], inner[5], inner[6], inner[7], 1342 sum1(inner, 8), 1343 packet[0], packet[1], packet[2], packet[3], 1344 packet[4], packet[5], packet[6], packet[7], 1345 sum1(packet, 8)); 1346 } 1348 /* section 3.3: take a packet from outside to inside */ 1349 nptv6_outer_to_inner(); 1351 /* 1352 * the returning packet should have the same checksum it 1353 * left with 1354 */ 1355 if (sum1(packet, 8) != sum1(inner, 8)) { 1356 printf("outer->inner checksum incorrect: " 1357 "calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x) " 1358 "inner: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n", 1359 packet[0], packet[1], packet[2], packet[3], 1360 packet[4], packet[5], packet[6], packet[7], 1361 sum1(packet, 8), inner[0], inner[1], inner[2], 1362 inner[3], inner[4], inner[5], inner[6], 1363 inner[7], sum1(inner, 8)); 1364 } 1366 /* 1367 * and every octet should calculate back to the same inner 1368 * value 1369 */ 1370 for (i = 0; i < 8; i++) { 1371 if (inner[i] != packet[i]) { 1372 printf("outer->inner different: " 1373 "calculated: %x:%x:%x:%x:%x:%x:%x:%x " 1374 "inner: %x:%x:%x:%x:%x:%x:%x:%x\n", 1375 packet[0], packet[1], packet[2], packet[3], 1376 packet[4], packet[5], packet[6], packet[7], 1377 inner[0], inner[1], inner[2], inner[3], 1378 inner[4], inner[5], inner[6], inner[7]); 1379 break; 1380 } 1381 } 1382 } 1383 } 1385 Authors' Addresses 1387 Margaret Wasserman 1388 Painless Security 1389 North Andover, MA 01845 1390 USA 1392 Phone: +1 781 405 7464 1393 Email: mrw@painless-security.com 1394 URI: http://www.painless-secuirty.com 1396 Fred Baker 1397 Cisco Systems 1398 Santa Barbara, California 93117 1399 USA 1401 Phone: +1-408-526-4257 1402 Email: fred@cisco.com