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