IPv6-to-IPv6 Network Prefix Translation

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address independence benefit associated with IPv4-to-IPv4 NAT (NAT44), and in addition provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end to end reachability at the network layer.

Requirements Terminology

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction
    1.1. What is Address Independence?
    1.2. NPTv6 Applicability
2. NPTv6 Overview
    2.1. NPTv6: the simplest case
    2.2. NPTv6 between peer networks
    2.3. NPTv6 redundnacy and load-sharing
    2.4. NPTv6 multihoming
    2.5. Mapping with No Per-Flow State
    2.6. Checksum-Neutral Mapping
3. NPTv6 Algorithmic Specification
    3.1. NPTv6 configuration calculations
    3.2. NPTv6 translation, internal network to external network
    3.3. NPTv6 translation, external network to internal network
    3.4. NPTv6 with a /48 or shorter prefix
    3.5. NPTv6 with a /49 or longer prefix
    3.6. /48 Prefix Mapping Example
    3.7. Address Mapping for Longer Prefixes
4. Implications of Network Address Translator Behavioral Requirements
    4.1. Prefix configuration and generation
    4.2. Subnet numbering
    4.3. NAT Behavioral Requirements
5. Implications for Applications
6. A Note on Port Mapping
7. Security Considerations
8. IANA Considerations
9. Acknowledgements
10. Change Log
    10.1. Changes Between draft-mrw-behave-nat66-00 and -01
    10.2. Changes between *behave-nat66-01 and -02
    10.3. Changes between *nat66-00 and *nat66-01
    10.4. Changes between *nat66-01 and *nat66-02
    10.5. Changes between *nat66-02 and *nat66-03
    10.6. Changes between *nat66-03 and *nat66-04
    10.7. Changes between *nat66-04 and *nat66-05
    10.8. Changes between *nat66-05 and *nat66-06
    10.9. Changes between *nat66-06 and *nat66-07
11. References
    11.1. Normative References
    11.2. Informative References
Appendix A. Why GSE?
Appendix B. Verification code
§ Authors' Addresses

1. Introduction

1.1. What is Address Independence?

For the purposes of this document, IPv6 Address Independence consists of the following set of properties:

Thus, address independence has ramifications for the edge network, networks it directly connects with (especially its upstream networks), and for the Internet as a whole. The desire for address independence has been a primary driver for IPv4 NAT deployment in medium to large-sized enterprise networks, including NAT deployments in enterprises that have plenty of IPv4 provider-independent address space (from IPv4 "swamp space"). It has also been a driver for edge networks to become members of RIR communities, seeking to obtain BGP Autonomous System Numbers and provider-independent prefixes, and as a result has been one of the drivers of the explosion of the IPv4 route table. Service providers have stated that the lack of address independence from their customers has been a negative incentive to deployment, due to the impact of customer routing expected in their networks.

The use of IPv6 Provider Independent (PI) addresses has also been suggested as a means to fulfill the address independence requirement. However, this solution requires that an enterprise qualify to receive a PI assignment and persuade their ISP to install specific routes for the enterprise's PI addresses. There are a number of practical issues with this approach, especially if there is a desire to route to a number of geographically and topologically diverse set of sites, which can sometimes involve coordinating with several ISPs to route portions of a single PI prefix. These problems have caused numerous enterprises with plenty of IPv4 swamp space to choose to use IPv4 NAT for part, or substantially all, of their internal network instead of using their provider-independent address space.

1.2. NPTv6 Applicability

NPTv6 provides a simple and compelling solution to meet the Address Independence requirement in IPv6. The address independence benefit stems directly from the translation function of the network prefix translator. To avoid as many of the issues associated with NAT44 as possible, NPTv6 is defined to include a two-way, checksum-neutral, algorithmic translation function, and nothing else.

NPTv6 does not include a port mapping function, and the defined address mapping mechanism is checksum-neutral. This avoids the need for a NPTv6 Translator to re-write transport layer headers, making it feasible to deploy new or improved transport layer protocols without upgrading NPTv6 Translators. Because NPTv6 does not involve re-writing transport-layer headers, NPTv6 will not interfere with encryption of the full IP payload in many cases.

The default NPTv6 address mapping mechanism is purely algorithmic, so NPTv6 translators do not need to maintain per-node or per-connection state, allowing deployment of more robust and adaptive networks than can be deployed using NAT44. Since the default NPTv6 mapping can be performed in either direction, it does not interfere with inbound connection establishment, thus allowing internal nodes to participate in direct Peer-to-Peer applications without the application layer overhead one finds in many IPv4 Peer-to-Peer applications.

Although NPTv6 compares favorably to NAT44 in several ways, it does not eliminate all of the architectural problems associated with IPv4 NAT, as described in [RFC2993] (Hain, T., “Architectural Implications of NAT,” November 2000.). NPTv6 involves modifying IP headers in transit, so it is not compatible with security mechanisms, such as the IPsec Authentication Header, that provide integrity protection for the IP header. NPTv6 may interfere with the use of application protocols that transmit IP addresses in the application-specific portion of the IP packet. These applications currently require application layer gateways (ALGs) to work correctly through NAT44 devices, and similar ALGs may be required for these applications to work through NPTv6 Translators. The use of separate internal and external prefixes creates complexity for DNS deployment, due the desire for internal nodes to communicate with other internal nodes using internal addresses, while external nodes need to obtain external addresses to communicate with the same nodes. This frequently results in the deployment of "split DNS", which may add complexity to network configuration.

The choice of address within the edge network bears consideration. One could use a ULA, which maximizes address independence. That could also be considered a misuse of the ULA; if the expectation is that a ULA prevents access to a system from outside the range of the ULA, NPTv6 overrides that. On the other hand, the administration is aware that it has made that choice, and could if it desired deploy a second ULA for the purpose of privacy; the only prefix that will be translated is one that has a NPTv6 Translator configured to translate to or from it. Also, using any other global scope address format makes one either obtain a PI prefix or be at the mercy of the agency from which it was allocated.

2. NPTv6 Overview

NPTv6 may be implemented in an IPv6 router to map one IPv6 address prefix to another IPv6 prefix as each IPv6 packet transits the router. A router that implements a NPTv6 prefix translation function is referred to as an NPTv6 Translator.

2.1. NPTv6: the simplest case

In its simplest form, a NPTv6 Translator interconnects two network links, one of which is an "internal" network link attached to a leaf network within a single administrative domain, and the other of which is an "external" network with connectivity to the global Internet. All of the hosts on the internal network will use addresses from a single, locally-routed prefix, and those addresses will be translated to/from addresses in a globally-routable prefix as IP packets transit the NPTv6 Translator. The lengths of these two prefixes will be functionally the same; if they differ, the longer of the two will limit the ability to use subnets in the shorter.

When a NPTv6 Translator forwards packets in the "outbound" direction, from the internal network to the external network, NPTv6 overwrites the IPv6 source prefix (in the IPv6 header) with a corresponding external prefix. When packets are forwarded in the "inbound" direction, from the external network to the internal network, the IPv6 destination prefix is overwritten with a corresponding internal prefix. Using the prefixes shown in the diagram above, as an IP packet passes through the NPTv6 Translator in the outbound direction, the source prefix (FD01:0203:0405:/48) will be overwritten with the external prefix (2001:0DB8:0001:/48). In an inbound packet, the destination prefix (2001:0DB8:0001:/48) will be overwritten with the internal prefix (FD01:0203:0405:/48). In both cases, it is the local IPv6 prefix that is overwritten; the remote IPv6 prefix remains unchanged. Nodes on the internal network are said to be "behind" the NPTv6 Translator.

2.2. NPTv6 between peer networks

NPTv6 can also be used between two private networks. In these cases, both networks may use ULA prefixes, with each subnet in one network mapped into a corresponding subnet in the other network, and vice versa. Or, each network may use ULA prefixes for internal addressing, and global unicast addresses on the other network.

2.3. NPTv6 redundnacy and load-sharing

In some cases, more than one NPTv6 Translator may be attached to a network, as show in Figure 3 (Parallel Translators). In such cases, NPTv6 Translators are configured with the same internal and external prefixes. Since there is only one translation, even though there are multiple translators, they map only one external address (prefix and IID) to the internal address.

2.4. NPTv6 multihoming

When multihoming, NPTv6 Translators are attached to an internal network, as show in Figure 4 (Parallel Translators with different upstream networks), but connected to different external networks. In such cases, NPTv6 Translators are configured with the same internal prefix, but different external prefixes. Since there are multiple translations, they map multiple external addresses (prefix and IID) to the common internal address. A system within the edge network is unable to determine which external address it is using apart from services such as STUN.

Multihoming in this sense has one negative feature as compared with multihoming with a provider-independent address; when routes change between NPTv6 Translators, since the upstream network changes, the translated prefix can change. This would case sessions and referrals dependent on it to fail as well. This is not expected to be a major real issue, however, in networks where routing is generally stable.

2.5. Mapping with No Per-Flow State

When NPTv6 is used as described in this document, no per-node or per-flow state is maintained in the NPTv6 Translator. Both inbound and outbound packets are translated algorithmically, using only information found in the IPv6 header. Due to this property, NPTv6's two-way, algorithmic address mapping can support both outbound and inbound connection establishment without the need for state-priming or rendezvous mechanisms, or the maintenance of mapping state. This is a significant improvement over NAT44 devices, but it also has significant security implications which are described in the Security Considerations section.

2.6. Checksum-Neutral Mapping

The NPTv6 mapping mechanisms described in this document are checksum-neutral, which means that they result in IP headers that will generate the same IPv6 pseudo-header checksum when the checksum is calculated using the standard Internet checksum algorithm [RFC1071] (Braden, R., Borman, D., Partridge, C., and W. Plummer, “Computing the Internet checksum,” September 1988.). Any changes that are made during translation of the IPv6 prefix are offset by changes to other parts of the IPv6 address. This results in transport layers that use the Internet checksum (such as TCP and UDP) calculating the same IPv6 pseudo header checksum for both the internal and external forms of the same packet, which avoids the need for the NPTv6 Translator to modify those transport layer headers to correct the checksum value.

As noted in Section 4.2 (Subnet numbering), this mapping results in an edge network using a /48 external prefix to be unable to use subnet 0xFFFF.

3. NPTv6 Algorithmic Specification

3.1. NPTv6 configuration calculations

In the simple case, there is one of each. If a single router provides NPTv6 translation services between a multiplicity of domains (as might be true when multihoming), each internal/external pair must be thought of as a separate NPTv6 Translator from the perspective of this specification.

They are then zero-extended to /64, for the purposes of a calculation. The translation function calculates the ones-complement sum of the 16 bit words of the /64 external prefix and the /64 internal prefix. It then calculates the difference between these values: internal minus external. This value, called the "adjustment", is effectively constant for the lifetime of the NPTv6 Translator configuration, and used in per-packet processing.

3.2. NPTv6 translation, internal network to external network

When a datagram passes through the NPTv6 Translator from an internal to an external network, its IPv6 Source Address is changed in two ways:

3.3. NPTv6 translation, external network to internal network

When a datagram passes through the NPTv6 Translator from an external to an internal network, its IPv6 Destination Address is changed in two ways:

3.4. NPTv6 with a /48 or shorter prefix

When a NPTv6 Translator is configured with internal and external prefixes that are 48 bits in length (a /48) or shorter, the adjustment MUST be added to or subtracted from bits 48..63 of the address.

This mapping results in no modification of the Interface Identifier (IID), which is held in the lower half of the IPv6 address, so it will not interfere with future protocols that may use unique IIDs for node identification.

3.5. NPTv6 with a /49 or longer prefix

When a NPTv6 Translator is configured with internal and external prefixes that are longer than 48 bits in length (such as a /52, /56, or /60), the adjustment must be added to or subtracted from one of the words in bits 64..79, 80..95, 96..111, or 112..127 of the address. While the choice of word is immaterial as long as it is consistent, for consistency's sake, these words MUST be inspected in that sequence, and the first that is not initially 0xFFFF chosen.

NPTv6 Translator implementations SHOULD implement the mapping for longer prefixes.

3.6. /48 Prefix Mapping Example

For the network shown in Figure 1 (A simple translator), the Internal Prefix is FD01:0203:0405:/48, and the External Prefix is 2001:0DB8:0001:/48

If a node with internal address FD01:0203:0405:0001::1234 sends an outbound packet through the NPTv6 Translator, the resulting external address will be 2001:0DB8:0001:D550::1234. The resulting address is obtained by calculating the checksum of both the internal and external 48-bit prefixes, subtracting the internal prefix from the external prefix using one's complement arithmetic to calculate the "adjustment", and adding the adjustment to the 16-bit subnet field (in this case 0x0001).

The one's complement checksum of FD01:0203:0405 is 0xFCF5. The one's complement checksum of 2001:0DB8:0001 is 0xD245. Using one's complement arithmetic, 0xD245 - 0xFCF5 = 0xD54F. The subnet in the original packet is 0x0001. Using one's complement arithmetic, 0x0001 + 0xD54F = 0xD550. Since 0xD550 != 0xFFFF, it is not changed to 0x0000.

So, the value 0xD550 is written in the 16-bit subnet area, resulting in a mapped external address of 2001:0DB8:0001:D550::1234.

When a response packet is received, it will contain the destination address 2001:0DB8:0001:D550::0001, which will be mapped using the inverse mapping algorithm, back to FD01:0203:0405:0001::1234.

In this case, the difference between the two prefixes will be calculated as follows:

Using one's complement arithmetic, 0xFCF5 - 0xD245 = 0x2AB0. The subnet in the original packet = 0xD550. Using one's complement arithmetic, 0xD550 + 0x2AB0 = 0x0001. Since 0x0001 != 0xFFFF, it is not changed to 0x0000.

So the value 0x0001 is written into the subnet field, and the internal value of the subnet field is properly restored.

3.7. Address Mapping for Longer Prefixes

If the prefix being mapped is longer than 48 bits, the algorithm is slightly more complex. A common case will be that the internal and external prefixes are of different length. In such a case, the shorter prefix is zero-extended to the length of the longer as described in Section 3.1 (NPTv6 configuration calculations) for the purposes of overwriting the prefix. Then, they are both zero-extended to 64 bits to facilitate one's complement arithmetic. The "adjustment" is calculated using those 64 bit prefixes.

For example if the internal prefix is a /48 ULA and the external prefix is a /56 provider-allocated prefix, the ULA becomes a /56 with zeros in bits 48..55. For purposes of one's complement arithmetic, they are then both zero-extended to 64 bits. A side-effect of this is that a subset of the subnets possible in the shorter prefix are untranslatable. While the security value of this is debatable, the administration may choose to use them for subnets that it knows need no external accessibility.

We then find the first word in the IID that does not have the value 0xFFFF, trying bits 64..79, and then 80..95, 96..111, and finally 112..127. We perform the same calculation (with the same proof of correctness) as in Section 3.6 (/48 Prefix Mapping Example), but applying it to that word.

Note: this mechanism does involve modification of the IID; it may not be compatible with future mechanisms that use unique IIDs for node identification.

4. Implications of Network Address Translator Behavioral Requirements

4.1. Prefix configuration and generation

4.2. Subnet numbering

For reasons detailed in Appendix B (Verification code), a network using NPTv6 Translation and a /48 external prefix MUST NOT use the value 0xFFFF to designate a subnet that it expects to be translated.

4.3. NAT Behavioral Requirements

NPTv6 Translators MUST support hairpinning behavior, as defined in the NAT Behavioral Requirements for UDP document [RFC4787] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.). This means that when a NPTv6 Translator receives a packet on the internal interface that has a destination address that matches the site's external prefix, it will translate the packet and forward it internally. This allows internal nodes to reach other internal nodes using their external, global addresses when necessary.

Conceptually, the datagram leaves the domain (is translated as described in Section 3.2 (NPTv6 translation, internal network to external network)), and returns (is again translated as described in Section 3.3 (NPTv6 translation, external network to internal network)). As a result, the datagram exchange will be through the NPTv6 Translator in both directions for the lifetime of the session. The alternative would be to require the NPTv6 Translator to drop the datagram, forcing the sender to use the correct internal prefix for its peer. Performing only the external-to-internal translation results in the datagram being sent from the untranslated internal address of the source to the translated and therefore internal address of its peer, which would enable the session to bypass the NPTv6 Translator for future datagrams. It would also mean that the original sender would be unlikely to recognize the response when it arrived.

Because NPTv6 does not perform port mapping and uses a one-to-one, reversible mapping algorithm, none of the other NAT behavioral requirements apply to NPTv6.

5. Implications for Applications

The use of NPTv6 Transition technology makes a capability available to Applications (and the networks that contain them) that is not readily possible in a NAT44 network. This is the ability to position an externally-accessible application within the "internal" network. In an IPv4 network using NAT44, an externally-accessible application must be positioned on systems with global addresses, forcing the edge network to obtain global address allocation; if the application can be in the translated routing domain, it automatically has an address in each of its upstream prefixes without the edge network obtaining such. However, there must be a means for the application to know what addresses are usable. Reasons include at least advertisement in DNS (which might be done statically if DNS is directly maintained by the administration, or from the end system if Dynamic DNS is in use). If referrals and other uses of network layer addressing do not use names, then the application needs a means to determine what addresses are relevant, whether from DNS or another means.

6. A Note on Port Mapping

In addition to overwriting IP addresses when packets are forwarded, NAPT44 devices overwrite the source port number in outbound traffic, and the destination port number in inbound traffic. This mechanism is called "port mapping".

The major benefit of port mapping is that it allows multiple computers to share a single IPv4 address. A large number of internal IPv4 addresses (typically from one of the [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) private address spaces) can be mapped into a single external, globally routable IPv4 address, with the local port number used to identify which internal node should receive each inbound packet. This address amplification feature is not generally foreseen as a necessity at this time.

Since port mapping requires re-writing a portion of the transport layer header, it requires NAPT44 devices to be aware of all of the transport protocols that they forward, thus stifling the development of new and improved transport protocols and preventing the use of IPsec encryption. Modifying the transport layer header is incompatible with security mechanisms that encrypt the full IP payload, and restricts the NAPT44 to forwarding transport layers that use weak checksum algorithms that are easily recalculated in routers.

Since there is significant detriment caused by modifying transport layer headers and very little, if any, benefit to the use of port mapping in IPv6, NPTv6 Translators that comply with this specification MUST NOT perform port mapping.

7. Security Considerations

When NPTv6 is deployed using either of the two-way, algorithmic mappings defined in the document, it allows direct inbound connections to internal nodes. While this can be viewed as a benefit of NPTv6 vs. NAT44, it does open internal nodes to attacks that would be more difficult in a NAT44 network. Although this situation is not substantially worse, from a security standpoint, than running IPv6 with no NAT, some enterprises may assume that a NPTv6 Translator will offer similar protection to a NAT44 device.

8. IANA Considerations

9. Acknowledgements

The checksum-neutral algorithmic address mapping described in this document is based on e-mail written by Iljtsch Van Beijnum.

The following people provided advice or review comments that substantially improved this document: Christian Huitema, Dave Thaler, Ed Jankiewicz, Eric Kline, Iljtsch Van Beijnum, Jari Arkko, Mark Townsley, Merike Kaeo, Ralph Droms, Remi Depres, Steve Blake, and Tony Hain.

10. Change Log

10.1. Changes Between draft-mrw-behave-nat66-00 and -01

There were several minor changes made between the *behave-nat66-00 and -01 versions of this draft:

10.2. Changes between *behave-nat66-01 and -02

10.3. Changes between *nat66-00 and *nat66-01

10.4. Changes between *nat66-01 and *nat66-02

10.5. Changes between *nat66-02 and *nat66-03

10.6. Changes between *nat66-03 and *nat66-04

10.7. Changes between *nat66-04 and *nat66-05

10.8. Changes between *nat66-05 and *nat66-06

10.9. Changes between *nat66-06 and *nat66-07

11. References

11.1. Normative References

11.2. Informative References

Appendix A. Why GSE?

For the purpose of this discussion, let us over-simplify the Internet's structure by distinguishing between two broad classes of networks: transit and edge. A "transit network", in this context, is a network that provides connectivity services to other networks. Its AS number may show up in a non-final position in BGP AS paths, or in the case of mobile and residential broadband networks, it may offer network services to smaller networks that can't justify RIR membership. An "edge network", in contrast, is any network that is not a transit network; it is the ultimate customer, and while it provides internal connectivity for its own use, it is in other respects is a consumer of transit services. In terms of routing, a network in the transit domain generally needs some way to make choices about how it routes to other networks; an edge network is generally quite satisfied with a simple default route.

The [GSE] (O'Dell, M., “GSE - An Alternate Addressing Architecture for IPv6,” February 1997.) proposal, and as a result this proposal (which is similar to GSE in most respects and inspired by it), responds directly to current concerns in the RIR communities. Edge networks are used to an environment in IPv4 in which their addressing is disjoint from that of their upstream transit networks; it is either provider independent, or a network prefix translator makes their external address distinct from their internal address, and they like the distinction. In IPv6, there is a mantra that edge network addresses should be derived from their upstream, and if they have multiple upstreams, edge networks are expected to design their networks to use all of those prefixes equivalently. They see this as unnecessary and unwanted operational complexity, and are as a result pushing very hard in the RIR communities for provider independent addressing.

Widespread use of provider independent addressing has a natural and perhaps unavoidable side-effect that is likely to be very expensive in the long term. It means that the routing table will enumerate the networks at the edge of the transit domain, the edge networks, rather than enumerating the transit domain. Per the BGP Update Report of 17 December 2010, there are currently over 36,000 Autonomous Systems being advertised in BGP, of which over 15,000 advertise only one prefix. There are in the neighborhood of 5000 AS's that show up in a non-final position in AS paths, and perhaps another 5000 networks whose AS numbers are terminal in more than one AS path. In other words, we have prefixes for some 36,000 transit and edge networks in the route table now, many of which arguably need an Autonomous System number only for multihoming. Current estimates suggest that we could easily see that be on the order of 10,000,000 within fifteen years. Tens of thousands of entries in the 36,264 Autonomous Systems being advertised in BGP, of which 31,137 provide no visible transit service to another AS, and 23,595 of those are visible in only one AS path (have only one upstream network). In addition, of the 36,264 AS's in the world, 15,439 advertise only a single prefix. In other words, we have prefixes for some 36,000 transit and edge networks in the route table now, many of which arguably need an Autonomous System number only for multihoming. However, the vast majority of networks (2/3) having the tools necessary to multihome are not visibly doing so, and would be well served by any solution that gives them address independence without the overhead of RIR membership and BGP routing.

Current growth estimates suggest that we could easily see that be on the order of 10,000,000 within fifteen years. Tens of thousands of entries in the route table is very survivable; while our protocols and computers will likely do quite well with tens of millions of routes, the heat produced and power consumed by those routers, and the inevitable impact on the cost of those routers, is not a good outcome. To avoid having a massive and unscalable route table, we need to find a way that is politically acceptable and returns us to enumerating the transit domain, not the edge.

There have been a number of proposals. As described, shim6 moves the complexity to the edge, and the edge is rebelling. Geographic addressing in essence forces ISPs to "own" geographic territory from a routing perspective, as otherwise there is no clue in the address as to what network a datagram should be delivered to in order to reach it. Metropolitan Addressing can imply regulatory authority, and even if it is implemented using internet exchange consortia, visits a great deal of complexity on the transit networks that directly serve the edge. The one that is likely to be most acceptable is any proposal that enables an edge network to be operationally independent of its upstreams, with no obligation to renumber when it adds, drops, or changes ISPs, and with no additional burden placed either on the ISP or the edge network as a result. From an application perspective, an additional operational requirement in the words of US NIST's Roadmap for the Smart Grid, is that

In other words, the structure of the network should allow for and enable appropriate access control, but the structure of the network should not inherently limit access.

The GSE model, by statelessly translating the prefix between an edge network and its upstream transit network, accomplishes that with a minimum of fuss and bother. Stated in the simplest terms, it enables the edge network to behave as if it has a provider-independent prefix from a multihoming and renumbering perspective without the overhead of RIR membership or maintaining BGP connectivity, and it enables the transit networks to aggressively aggregate what are from their perspective provider-allocated customer prefixes, to maintain a rational-sized routing table.

Appendix B. Verification code

This non-normative appendix is presented as a proof of concept. It is in no sense optimized; for example, one's complement arithmetic is implemented in portable subroutines, where operational implementations might use one's complement arithmetic instructions through a pragma; such implementations probably need to explicitly force 0xFFFF to 0x0000, as the instruction will not. The original purpose of the code was to verify whether or not it was necessary to suppress 0xFFFF by overwriting with zero, and whether predicted issues with subnet numbering were real.

/*
 * Copyright (c) 2010 IETF Trust and the persons identified as
 * authors of the code.  All rights reserved.  Redistribution
 * and use in source and binary forms, with or without
 * modification, are permitted provided that the following
 * conditions are met:
 *
 * o  Redistributions of source code must retain the above
 *    copyright notice, this list of conditions and the
 *    following disclaimer.
 *
 * o  Redistributions in binary form must reproduce the above
 *    copyright notice, this list of conditions and the
 *    following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 *
 * o  Neither the name of Internet Society, IETF or IETF Trust,
 *    nor the names of specific contributors, may be used to
 *    endorse or promote products derived from this software
 *    without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
#include "stdio.h"
#include "assert.h"
/*
 * program to verify the NPTv6 algorithm
 *
 * argument:
 *     perform negative zero suppression: boolean
 *
 * method:
 *    We specify an internal and an external prefix. The prefix
 *    length is presumed to be the common length of both, and for
 *    this is a /48. We perform the three algorithms specified.
 *    the "packet" address is in effect the source address
 *    internal->external and the destination address
 *    external->internal.
 */
unsigned short  inner_init[] = {
    0xFD01, 0x0203, 0x0405, 1, 2, 3, 4, 5};
unsigned short  outer_init[] = {
    0x2001, 0x0db8, 0x0001, 1, 2, 3, 4, 5};
unsigned short  inner[8];
unsigned short  packet[8];
unsigned char   checksum[65536] = {0};
unsigned short  outer[8];
unsigned short  adjustment;
unsigned short  suppress;
/*
 * One's complement sum.
 * return number1 + number2
 */
unsigned short
add1(number1, number2)
    unsigned short  number1;
    unsigned short  number2;
{
    unsigned int    result;

    result = number1;
    result += number2;
    if (suppress) {
        while (0xFFFF <= result) {
            result = result + 1 - 0x10000;
        }
    } else {
        while (0xFFFF < result) {
            result = result + 1 - 0x10000;
        }
    }
    return result;
}

/*
 * One's complement difference
 * return number1 - number2
 */
unsigned short
sub1(number1, number2)
    unsigned short  number1;
    unsigned short  number2;
{
    return add1(number1, ~number2);
}

/*
 * return one's complement sum of an array of numbers
 */
unsigned short
sum1(numbers, count)
    unsigned short *numbers;
    int             count;
{
    unsigned int    result;

    result = *numbers++;
    while (--count > 0) {
        result += *numbers++;
    }

    if (suppress) {
        while (0xFFFF <= result) {
            result = result + 1 - 0x10000;
        }
    } else {
        while (0xFFFF < result) {
            result = result + 1 - 0x10000;
        }
    }
    return result;
}

/*
 * NPTv6 initialization: section 3.1 assuming section 3.4
 *
 * create the /48, a source address in internal format, and a
 * source address in external format. calculate the adjustment
 * if one /48 is overwritten with the other.
 */
void
nptv6_initialization(subnet)
    unsigned short  subnet;
{
    int             i;
    unsigned short  inner48;
    unsigned short  outer48;

    /* initialize the internal and external prefixes. */
    for (i = 0; i < 8; i++) {
        inner[i] = inner_init[i];
        outer[i] = outer_init[i];
    }
    inner[3] = subnet;
    outer[3] = subnet;
    /* calculate the checksum adjustment */
    inner48 = sum1(inner, 3);
    outer48 = sum1(outer, 3);
    adjustment = sub1(inner48, outer48);
}

/*
 * NPTv6 packet from edge to transit: section 3.2 assuming
 * section 3.4
 *
 * overwrite the prefix in the source address with the outer
 * prefix, and adjust the checksum
 */
void
nptv6_inner_to_outer()
{
    int             i;

    /* let's get the source address into the packet */
    for (i = 0; i < 8; i++) {
        packet[i] = inner[i];
    }

    /* overwrite the prefix with the outer prefix */
    for (i = 0; i < 3; i++) {
        packet[i] = outer[i];
    }

    /* adjust the checksum */
    packet[3] = add1(packet[3], adjustment);
}

/*
 * NPTv6 packet from transit to edge:: section 3.3 assuming
 * section 3.4
 *
 * overwrite the prefix in the destination address with the
 * inner prefix, and adjust the checksum
 */
void
nptv6_outer_to_inner()
{
    int             i;

    /* overwrite the prefix with the outer prefix */
    for (i = 0; i < 3; i++) {
        packet[i] = inner[i];
    }

    /* adjust the checksum */
    packet[3] = sub1(packet[3], adjustment);
}

/*
 * main program
 */
main(argc, argv)
    int             argc;
    char          **argv;
{
    unsigned        subnet;
    int             i;

    if (argc < 2) {
           fprintf(stderr, "usage: nptv6 supression\n");
           assert(0);
       }
       suppress = atoi(argv[1]);
       assert(suppress <= 1);

       for (subnet = 0; subnet < 0x10000; subnet++) {
           /* section 3.1: initialize the system */
           nptv6_initialization(subnet);

           /* section 3.2: take a packet from inside to outside */
           nptv6_inner_to_outer();

           /* the resulting checksum value should be unique */
           if (checksum[subnet]) {
                printf("inner->outer duplicated checksum: "
                       "inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
                       "calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
                       inner[0], inner[1], inner[2], inner[3],
                       inner[4], inner[5], inner[6], inner[7],
                       sum1(inner, 8),
                       packet[0], packet[1], packet[2], packet[3],
                       packet[4], packet[5], packet[6], packet[7],
                       sum1(packet, 8));
        }

        checksum[subnet] = 1;

        /*
         * the resulting checksum should be the same as the inner
         * address's checksum
         */
        if (sum1(packet, 8) != sum1(inner, 8)) {
            printf("inner->outer incorrect: "
                   "inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
                   "calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
                   inner[0], inner[1], inner[2], inner[3],
                   inner[4], inner[5], inner[6], inner[7],
                   sum1(inner, 8),
                   packet[0], packet[1], packet[2], packet[3],
                   packet[4], packet[5], packet[6], packet[7],
                   sum1(packet, 8));
        }

        /* section 3.3: take a packet from outside to inside */
        nptv6_outer_to_inner();

        /*
         * the returning packet should have the same checksum it
         * left with
         */
        if (sum1(packet, 8) != sum1(inner, 8)) {
            printf("outer->inner checksum incorrect: "
                   "calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
                   "inner: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
                   packet[0], packet[1], packet[2], packet[3],
                   packet[4], packet[5], packet[6], packet[7],
                sum1(packet, 8), inner[0], inner[1], inner[2],
                   inner[3], inner[4], inner[5], inner[6],
                   inner[7], sum1(inner, 8));
        }

        /*
         * and every octet should calculate back to the same inner
         * value
         */
        for (i = 0; i < 8; i++) {
            if (inner[i] != packet[i]) {
                printf("outer->inner different: "
                       "calculated: %x:%x:%x:%x:%x:%x:%x:%x "
                       "inner: %x:%x:%x:%x:%x:%x:%x:%x\n",
                   packet[0], packet[1], packet[2], packet[3],
                   packet[4], packet[5], packet[6], packet[7],
                       inner[0], inner[1], inner[2], inner[3],
                       inner[4], inner[5], inner[6], inner[7]);
                break;
            }
        }
    }
}

[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2526]	Johnson, D. and S. Deering, “Reserved IPv6 Subnet Anycast Addresses,” RFC 2526, March 1999 (TXT).
[RFC4193]	Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” RFC 4193, October 2005 (TXT).
[RFC4291]	Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” RFC 4291, February 2006 (TXT).
[RFC4443]	Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” RFC 4443, March 2006 (TXT).
[RFC4787]	Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” BCP 127, RFC 4787, January 2007 (TXT).

[GSE]	O'Dell, M., “GSE - An Alternate Addressing Architecture for IPv6,” February 1997 (TXT).
[I-D.ietf-v6ops-ipv6-cpe-router]	Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, “Basic Requirements for IPv6 Customer Edge Routers,” draft-ietf-v6ops-ipv6-cpe-router-09 (work in progress), December 2010 (TXT).
[RFC1071]	Braden, R., Borman, D., Partridge, C., and W. Plummer, “Computing the Internet checksum,” RFC 1071, September 1988 (TXT).
[RFC1624]	Rijsinghani, A., “Computation of the Internet Checksum via Incremental Update,” RFC 1624, May 1994 (TXT).
[RFC1918]	Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” BCP 5, RFC 1918, February 1996 (TXT).
[RFC2629]	Rose, M., “Writing I-Ds and RFCs using XML,” RFC 2629, June 1999 (TXT, HTML, XML).
[RFC2827]	Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” BCP 38, RFC 2827, May 2000 (TXT).
[RFC2993]	Hain, T., “Architectural Implications of NAT,” RFC 2993, November 2000 (TXT).
[RFC4864]	Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, “Local Network Protection for IPv6,” RFC 4864, May 2007 (TXT).
[RFC6092]	Woodyatt, J., “Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service,” RFC 6092, January 2011 (TXT).

	Margaret Wasserman
	Painless Security
	North Andover, MA 01845
	USA
Phone:	+1 781 405 7464
Email:	mrw@painless-security.com
URI:	http://www.painless-secuirty.com

	Fred Baker
	Cisco Systems
	Santa Barbara, California 93117
	USA
Phone:	+1-408-526-4257
Email:	fred@cisco.com

IPv6-to-IPv6 Network Prefix Translationdraft-mrw-nat66-07

Abstract