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