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