doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc6296.txt b/doc/rfc/rfc6296.txt
new file mode 100644
index 0000000..fa1bfb5
--- /dev/null
+++ b/doc/rfc/rfc6296.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Wasserman
+Request for Comments: 6296                             Painless Security
+Category: Experimental                                          F. Baker
+ISSN: 2070-1721                                            Cisco Systems
+                                                               June 2011
+
+
+                IPv6-to-IPv6 Network Prefix Translation
+
+Abstract
+
+   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
+   (NAPT44) and provides a 1:1 relationship between addresses in the
+   "inside" and "outside" prefixes, preserving end-to-end reachability
+   at the network layer.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6296.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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
+
+
+
+
+Wasserman & Baker             Experimental                      [Page 1]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   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.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  What is Address Independence?  . . . . . . . . . . . . . .  4
+     1.2.  NPTv6 Applicability  . . . . . . . . . . . . . . . . . . .  5
+     1.3.  Requirements Terminology . . . . . . . . . . . . . . . . .  7
+   2.  NPTv6 Overview . . . . . . . . . . . . . . . . . . . . . . . .  7
+     2.1.  NPTv6: The Simplest Case . . . . . . . . . . . . . . . . .  7
+     2.2.  NPTv6 between Peer Networks  . . . . . . . . . . . . . . .  8
+     2.3.  NPTv6 Redundancy and Load Sharing  . . . . . . . . . . . .  9
+     2.4.  NPTv6 Multihoming  . . . . . . . . . . . . . . . . . . . .  9
+     2.5.  Mapping with No Per-Flow State . . . . . . . . . . . . . . 10
+     2.6.  Checksum-Neutral Mapping . . . . . . . . . . . . . . . . . 10
+   3.  NPTv6 Algorithmic Specification  . . . . . . . . . . . . . . . 11
+     3.1.  NPTv6 Configuration Calculations . . . . . . . . . . . . . 11
+     3.2.  NPTv6 Translation, Internal Network to External Network  . 12
+     3.3.  NPTv6 Translation, External Network to Internal Network  . 12
+     3.4.  NPTv6 with a /48 or Shorter Prefix . . . . . . . . . . . . 12
+     3.5.  NPTv6 with a /49 or Longer Prefix  . . . . . . . . . . . . 13
+     3.6.  /48 Prefix Mapping Example . . . . . . . . . . . . . . . . 13
+     3.7.  Address Mapping for Longer Prefixes  . . . . . . . . . . . 14
+   4.  Implications of Network Address Translator Behavioral
+       Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     4.1.  Prefix Configuration and Generation  . . . . . . . . . . . 15
+     4.2.  Subnet Numbering . . . . . . . . . . . . . . . . . . . . . 15
+     4.3.  NAT Behavioral Requirements  . . . . . . . . . . . . . . . 15
+   5.  Implications for Applications  . . . . . . . . . . . . . . . . 16
+     5.1.  Recommendation for Network Planners Considering Use of
+           NPTv6 Translation  . . . . . . . . . . . . . . . . . . . . 17
+     5.2.  Recommendations for Application Writers  . . . . . . . . . 18
+     5.3.  Recommendation for Future Work . . . . . . . . . . . . . . 18
+   6.  A Note on Port Mapping . . . . . . . . . . . . . . . . . . . . 18
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 20
+   Appendix A.  Why GSE?  . . . . . . . . . . . . . . . . . . . . . . 23
+   Appendix B.  Verification Code . . . . . . . . . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+Wasserman & Baker             Experimental                      [Page 2]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+1.  Introduction
+
+   This document describes a stateless IPv6-to-IPv6 Network Prefix
+   Translation (NPTv6) function, designed to provide address
+   independence to the edge network.  It is transport-agnostic with
+   respect to transports that do not checksum the IP header, such as
+   SCTP, and to transports that use the TCP/UDP/DCCP (Datagram
+   Congestion Control Protocol) pseudo-header and checksum [RFC1071].
+
+   For reasons discussed in [RFC2993] and Section 5, the IETF does not
+   recommend the use of Network Address Translation technology for IPv6.
+   Where translation is implemented, however, this specification
+   provides a mechanism that has fewer architectural problems than
+   merely implementing a traditional stateful Network Address Translator
+   in an IPv6 environment.  It also provides a useful alternative to the
+   complexities and costs imposed by multihoming using provider-
+   independent addressing and the routing and network management issues
+   of overlaid ISP address space.  Some problems remain, however.  The
+   reader should consider the alternatives suggested in [RFC4864] and
+   the considerations of [RFC5902] for improved approaches.
+
+   The stateless approach described in this document has several
+   ramifications:
+
+   o  Any security benefit that NAPT44 might offer is not present in
+      NPTv6, necessitating the use of a firewall to obtain those
+      benefits if desired.  An example of such a firewall is described
+      in [RFC6092].
+
+   o  End-to-end reachability is preserved, although the address used
+      "inside" the edge network differs from the address used "outside"
+      the edge network.  This has implications for application referrals
+      and other uses of Internet layer addresses.
+
+   o  If there are multiple identically configured prefix translators
+      between two networks, there is no need for them to exchange
+      dynamic state, as there is no dynamic state -- the algorithmic
+      translation will be identical across each of them.  The network
+      can therefore asymmetrically route, load share, and fail-over
+      among them without issue.
+
+   o  Since translation is 1:1 at the network layer, there is no need to
+      modify port numbers or other transport parameters.
+
+   o  TCP sessions that authenticate peers using the TCP Authentication
+      Option [RFC5925] cannot have their addresses translated, as the
+      addresses are used in the calculation of the Message
+      Authentication Code.  This consideration applies in general to any
+
+
+
+Wasserman & Baker             Experimental                      [Page 3]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+      UNilateral Self-Address Fixing (UNSAF) [RFC3424] Protocol, which
+      the IAB recommends against the deployment of in an environment
+      that changes Internet addresses.
+
+   o  Applications using the Internet Key Exchange Protocol Version 2
+      (IKEv2) [RFC5996] should, at least in theory, detect the presence
+      of the translator; while no NAT traversal solution is required,
+      [RFC5996] would require such sessions to use UDP.
+
+1.1.  What is Address Independence?
+
+   For the purposes of this document, IPv6 address independence consists
+   of the following set of properties:
+
+   From the perspective of the edge network:
+
+      *  The IPv6 addresses used inside the local network (for
+         interfaces, access lists, and logs) do not need to be
+         renumbered if the global prefix(es) assigned for use by the
+         edge network are changed.
+
+      *  The IPv6 addresses used inside the edge network (for
+         interfaces, access lists, and logs) or within other upstream
+         networks (such as when multihoming) do not need to be
+         renumbered when a site adds, drops, or changes upstream
+         networks.
+
+      *  It is not necessary for an administration to convince an
+         upstream network to route its internal IPv6 prefixes or for it
+         to advertise prefixes derived from other upstream networks into
+         it.
+
+      *  Unless it wants to optimize routing between multiple upstream
+         networks in the process of multihoming, there is no need for a
+         BGP exchange with the upstream network.
+
+   From the perspective of the upstream network:
+
+      *  IPv6 addresses used by the edge network are guaranteed to have
+         a provider-allocated prefix, eliminating the need and concern
+         for BCP 38 [RFC2827] ingress filtering and the advertisement of
+         customer-specific prefixes.
+
+   Thus, address independence has ramifications for the edge network,
+   networks it directly connects with (especially its upstream
+   networks), and 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
+
+
+
+Wasserman & Baker             Experimental                      [Page 4]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   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 Regional Internet Registry (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 Local Network Protection [RFC4864] document discusses a related
+   concept called "Address Autonomy" as a benefit of NAPT44.  [RFC4864]
+   indicates that address autonomy can be achieved by the simultaneous
+   use of global addresses on all nodes within a site that need external
+   connectivity and Unique Local Addresses (ULAs) [RFC4193] for all
+   internal communication.  However, this solution fails to meet the
+   requirement for address independence, because if an ISP renumbering
+   event occurs, all of the hosts, routers, DHCP servers, Access Control
+   Lists (ACLs), firewalls, and other internal systems that are
+   configured with global addresses from the ISP will need to be
+   renumbered before global connectivity is fully restored.
+
+   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 its 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 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 NAPT44 as
+   possible, NPTv6 is defined to include a two-way, checksum-neutral,
+   algorithmic translation function, and nothing else.
+
+   The fact that NPTv6 does not map ports and is checksum-neutral avoids
+   the need for an NPTv6 Translator to rewrite transport layer headers.
+   This makes it feasible to deploy new or improved transport layer
+
+
+
+
+Wasserman & Baker             Experimental                      [Page 5]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   protocols without upgrading NPTv6 Translators.  Similarly, since
+   NPTv6 does not rewrite 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 NAPT44.  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 NAPT44 in several ways, it does
+   not eliminate all of the architectural problems associated with IPv4
+   NAT, as described in [RFC2993].  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 datagram.  These applications currently require
+   Application Layer Gateways (ALGs) to work correctly through NAPT44
+   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 to 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 deploy a second ULA for
+   the purpose of privacy if it desired; the only prefix that will be
+   translated is one that has an 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.
+
+   There are significant technical impacts associated with the
+   deployment of any prefix translation mechanism, including NPTv6, and
+   we strongly encourage anyone who is considering the implementation or
+
+
+
+
+
+Wasserman & Baker             Experimental                      [Page 6]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   deployment of NPTv6 to read [RFC4864] and [RFC5902], and to carefully
+   consider the alternatives described in that document, some of which
+   may cause fewer problems than NPTv6.
+
+1.3.  Requirements Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  NPTv6 Overview
+
+   NPTv6 may be implemented in an IPv6 router to map one IPv6 address
+   prefix to another IPv6 prefix as each IPv6 datagram transits the
+   router.  A router that implements an NPTv6 prefix translation
+   function is referred to as an NPTv6 Translator.
+
+2.1.  NPTv6: The Simplest Case
+
+   In its simplest form, an 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 datagrams
+   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.
+
+               External Network:  Prefix = 2001:0DB8:0001:/48
+                   --------------------------------------
+                                     |
+                                     |
+                              +-------------+
+                              |     NPTv6   |
+                              |  Translator |
+                              +-------------+
+                                     |
+                                     |
+                   --------------------------------------
+               Internal Network:  Prefix = FD01:0203:0405:/48
+
+                       Figure 1: A Simple Translator
+
+
+
+
+
+
+
+Wasserman & Baker             Experimental                      [Page 7]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   Figure 1 shows an NPTv6 Translator attached to two networks.  In this
+   example, the internal network uses IPv6 Unique Local Addresses (ULAs)
+   [RFC4193] to represent the internal IPv6 nodes, and the external
+   network uses globally routable IPv6 addresses to represent the same
+   nodes.
+
+   When an NPTv6 Translator forwards datagrams 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 datagrams 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 datagram 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 datagram, 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.
+
+                  Internal Prefix = FD01:4444:5555:/48
+                  --------------------------------------
+                       V            |      External Prefix
+                       V            |      2001:0DB8:6666:/48
+                       V        +---------+      ^
+                       V        |  NPTv6  |      ^
+                       V        |  Device |      ^
+                       V        +---------+      ^
+              External Prefix       |            ^
+              2001:0DB8:0001:/48    |            ^
+                  --------------------------------------
+                  Internal Prefix = FD01:0203:0405:/48
+
+               Figure 2: Flow of Information in Translation
+
+
+
+
+
+
+
+Wasserman & Baker             Experimental                      [Page 8]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+2.3.  NPTv6 Redundancy and Load Sharing
+
+   In some cases, more than one NPTv6 Translator may be attached to a
+   network, as shown in Figure 3.  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 Interface Identifier
+   (IID)) to the internal address.
+
+               External Network:  Prefix = 2001:0DB8:0001:/48
+                   --------------------------------------
+                          |                      |
+                          |                      |
+                   +-------------+        +-------------+
+                   |  NPTv6      |        |  NPTv6      |
+                   |  Translator |        |  Translator |
+                   |   #1        |        |   #2        |
+                   +-------------+        +-------------+
+                          |                      |
+                          |                      |
+                   --------------------------------------
+               Internal Network:  Prefix = FD01:0203:0405:/48
+
+                      Figure 3: Parallel Translators
+
+2.4.  NPTv6 Multihoming
+
+            External Network #1:          External Network #2:
+         Prefix = 2001:0DB8:0001:/48    Prefix = 2001:0DB8:5555:/48
+         ---------------------------    --------------------------
+                         |                      |
+                         |                      |
+                  +-------------+        +-------------+
+                  |  NPTv6      |        |  NPTv6      |
+                  |  Translator |        |  Translator |
+                  |   #1        |        |   #2        |
+                  +-------------+        +-------------+
+                         |                      |
+                         |                      |
+                  --------------------------------------
+              Internal Network:  Prefix = FD01:0203:0405:/48
+
+      Figure 4: Parallel Translators with Different Upstream Networks
+
+   When multihoming, NPTv6 Translators are attached to an internal
+   network, as shown in Figure 4, but are connected to different
+   external networks.  In such cases, NPTv6 Translators are configured
+   with the same internal prefix but different external prefixes.  Since
+
+
+
+Wasserman & Baker             Experimental                      [Page 9]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   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 Session Traversal Utilities for NAT
+   (STUN) [RFC5389].
+
+   Multihoming in this sense has one negative feature as compared with
+   multihoming with a provider-independent address: when routes change
+   between NPTv6 Translators, the translated prefix can change since the
+   upstream network changes.  This causes sessions and referrals
+   dependent on it to fail as well.  This is not expected to be a major
+   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 datagrams 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 maintenance of
+   mapping state or for state-priming or rendezvous mechanisms.  This is
+   a significant improvement over NAPT44 devices, but it also has
+   significant security implications, which are described in Section 7.
+
+2.6.  Checksum-Neutral Mapping
+
+   When a change is made to one of the IP header fields in the IPv6
+   pseudo-header checksum (such as one of the IP addresses), the
+   checksum field in the transport layer header may become invalid.
+   Fortunately, an incremental change in the area covered by the
+   Internet standard checksum [RFC1071] will result in a well-defined
+   change to the checksum value [RFC1624].  So, a checksum change caused
+   by modifying part of the area covered by the checksum can be
+   corrected by making a complementary change to a different 16-bit
+   field covered by the same checksum.
+
+   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].
+   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 datagram, which avoids the
+   need for the NPTv6 Translator to modify those transport layer headers
+   to correct the checksum value.
+
+
+
+Wasserman & Baker             Experimental                     [Page 10]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   The outgoing checksum correction is achieved by making a change to a
+   16-bit section of the source address that is not used for routing in
+   the external network.  Due to the nature of checksum arithmetic, when
+   the corresponding correction is applied to the same bits of
+   destination address of the inbound packet, the Destination Address
+   (DA) is returned to the correct internal value.
+
+   As noted in Section 4.2, this mapping results in an edge network
+   using a /48 external prefix to be unable to use subnet 0xFFFF.
+
+3.  NPTv6 Algorithmic Specification
+
+   The [RFC4291] IPv6 Address is reproduced for clarity in Figure 5.
+
+      0    15 16   31 32   47 48   63 64   79 80   95 96  111 112  127
+     +-------+-------+-------+-------+-------+-------+-------+-------+
+     |     Routing Prefix    | Subnet|   Interface Identifier (IID)  |
+     +-------+-------+-------+-------+-------+-------+-------+-------+
+
+            Figure 5: Enumeration of the IPv6 Address [RFC4291]
+
+3.1.  NPTv6 Configuration Calculations
+
+   When an NPTv6 Translation function is configured, it is configured
+   with
+
+   o  one or more "internal" interfaces with their "internal" routing
+      domain prefixes, and
+
+   o  one or more "external" interfaces with their "external" routing
+      domain prefixes.
+
+   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.
+
+   When an NPTv6 Translator is configured, the translation function
+   first ensures that the internal and external prefixes are the same
+   length, extending the shorter of the two with zeroes if necessary.
+   These two prefixes will be used in the prefix translation function
+   described in Sections 3.2 and 3.3.
+
+   They are then zero-extended to /64 for the purposes of a calculation.
+   The translation function calculates the one's 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
+
+
+
+Wasserman & Baker             Experimental                     [Page 11]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   minus external.  This value, called the "adjustment", is effectively
+   constant for the lifetime of the NPTv6 Translator configuration and
+   is used in per-datagram 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 either changed in
+   two ways or results in the datagram being discarded:
+
+   o  If the internal subnet number has no mapping, such as being 0xFFFF
+      or simply not mapped, discard the datagram.  This SHOULD result in
+      an ICMP Destination Unreachable.
+
+   o  The internal prefix is overwritten with the external prefix, in
+      effect subtracting the difference between the two checksums (the
+      adjustment) from the pseudo-header's checksum, and
+
+   o  A 16-bit word of the address has the adjustment added to it using
+      one's complement arithmetic.  If the result is 0xFFFF, it is
+      overwritten as zero.  The choice of word is as specified in
+      Sections 3.4 or 3.5 as appropriate.
+
+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:
+
+   o  The external prefix is overwritten with the internal prefix, in
+      effect adding the difference between the two checksums (the
+      adjustment) to the pseudo-header's checksum, and
+
+   o  A 16-bit word of the address has the adjustment subtracted from it
+      (bitwise inverted and added to it) using one's complement
+      arithmetic.  If the result is 0xFFFF, it is overwritten as zero.
+      The choice of word is as specified in Section 3.4 or Section 3.5
+      as appropriate.
+
+3.4.  NPTv6 with a /48 or Shorter Prefix
+
+   When an 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.
+
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 12]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   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.
+
+   NPTv6 Translator implementations MUST implement the /48 mapping.
+
+3.5.  NPTv6 with a /49 or Longer Prefix
+
+   When an 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, these words MUST be inspected in that sequence and the
+   first that is not initially 0xFFFF chosen, for consistency's sake.
+
+   NPTv6 Translator implementations SHOULD implement the mapping for
+   longer prefixes.
+
+3.6.  /48 Prefix Mapping Example
+
+   For the network shown in Figure 1, 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 datagram 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).
+
+   To show the work:
+
+   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 datagram 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.
+
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 13]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   When a response datagram is received, it will contain the destination
+   address 2001:0DB8:0001:D550::0001, which will be mapped back to FD01:
+   0203:0405:0001::1234 using the inverse mapping algorithm.
+
+   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 datagram = 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 lengths.  In such a case, the
+   shorter prefix is zero-extended to the length of the longer as
+   described in Section 3.1 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 is
+   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 but apply it to that word.
+
+   Although any 16-bit portion of an IPv6 IID could contain 0xFFFF, an
+   IID of all-ones is a reserved anycast identifier that should not be
+   used on the network [RFC2526].  If an NPTv6 Translator discovers a
+   datagram with an IID of all-zeros while performing address mapping,
+   that datagram MUST be dropped, and an ICMPv6 Parameter Problem error
+   SHOULD be generated [RFC4443].
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 14]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   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
+
+   NPTv6 Translators MUST support manual configuration of internal and
+   external prefixes and MUST NOT place any restrictions on those
+   prefixes except that they be valid IPv6 unicast prefixes as described
+   in [RFC4291].  They MAY also support random generation of ULA
+   addresses on command.  Since the most common place anticipated for
+   the implementation of an NPTv6 Translator is a Customer Premises
+   Equipment (CPE) router, the reader is urged to consider the
+   requirements of [RFC6204].
+
+4.2.  Subnet Numbering
+
+   For reasons detailed in Appendix B, 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].  This
+   means that when an NPTv6 Translator receives a datagram on the
+   internal interface that has a destination address that matches the
+   site's external prefix, it will translate the datagram 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) and returns (is again translated as
+   described in Section 3.3).  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.
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 15]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   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
+
+   NPTv6 Translation does not create several of the problems known to
+   exist with other kinds of NATs as discussed in [RFC2993].  In
+   particular, NPTv6 Translation is stateless, so a "reset" or brief
+   outage of an NPTv6 Translator does not break connections that
+   traverse the translation function, and if multiple NPTv6 Translators
+   exist between the same two networks, the load can shift or be
+   dynamically load shared among them.  Also, an NPTv6 Translator does
+   not aggregate traffic for several hosts/interfaces behind a fewer
+   number of external addresses, so there is no inherent expectation for
+   an NPTv6 Translator to block new inbound flows from external hosts
+   and no issue with a filter or blacklist associated with one prefix
+   within the domain affecting another.  A firewall can, of course, be
+   used in conjunction with an NPTv6 Translator; this would allow the
+   network administrator more flexibility to specify security policy
+   than would be possible with a traditional NAT.
+
+   However, NPTv6 Translation does create difficulties for some kinds of
+   applications.  Some examples include:
+
+   o  An application instance "behind" an NPTv6 Translator will see a
+      different address for its connections than its peers "outside" the
+      NPTv6 Translator.
+
+   o  An application instance "outside" an NPTv6 Translator will see a
+      different address for its connections than any peer "inside" an
+      NPTv6 Translator.
+
+   o  An application instance wishing to establish communication with a
+      peer "behind" an NPTv6 Translator may need to use a different
+      address to reach that peer depending on whether the instance is
+      behind the same NPTv6 Translator or external to it.  Since an
+      NPTv6 Translator implements hairpinning (Section 4.3), it suffices
+      for applications to always use their external addresses.  However,
+      this creates inefficiencies in the local network and may also
+      complicate implementation of the NPTv6 Translator.  [RFC3484] also
+      would prefer the private address in such a case in order to reduce
+      those inefficiencies.
+
+   o  An application instance that moves from a realm "behind" an NPTv6
+      Translator to a realm that is "outside" the network, or vice
+      versa, may find that it is no longer able to reach its peers at
+      the same addresses it was previously able to use.
+
+
+
+Wasserman & Baker             Experimental                     [Page 16]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   o  An application instance that is intermittently communicating with
+      a peer that moves from behind an NPTv6 Translator to "outside" of
+      it, or vice versa, may find that it is no longer able to reach
+      that peer at the same address that it had previously used.
+
+   Many, but not all, of the applications that are adversely affected by
+   NPTv6 Translation are those that do "referrals" -- where an
+   application instance passes its own addresses, and/or addresses of
+   its peers, to other peers.  (Some believe referrals are inherently
+   undesirable; others believe that they are necessary in some
+   circumstances.  A discussion of the merits of referrals, or lack
+   thereof, is beyond the scope of this document.)
+
+   To some extent, the incidence of these difficulties can be reduced by
+   DNS hacks that attempt to expose addresses "behind" an NPTv6
+   Translator only to hosts that are also behind the same NPTv6
+   Translator and perhaps to also expose only the "internal" addresses
+   of hosts behind the NPTv6 Translator to other hosts behind the same
+   NPTv6 Translator.  However, this cannot be a complete solution.  A
+   full discussion of these issues is out of scope for this document,
+   but briefly: (a) reliance on DNS to solve this problem depends on
+   hosts always making queries from DNS servers in the same realm as
+   they are (or on DNS interception proxies, which create their own
+   problems) and on mobile hosts/applications not caching those results;
+   (b) reliance on DNS to solve this problem depends on network
+   administrators on all networks using such applications to reliably
+   and accurately maintain current DNS entries for every host using
+   those applications; and (c) reliance on DNS to solve this problem
+   depends on applications always using DNS names, even though they
+   often must run in environments where DNS names are not reliably
+   maintained for every host.  Other issues are that there is often no
+   single distinguished name for a host and no reliable way for a host
+   to determine what DNS names are associated with it and which names
+   are appropriate to use in which contexts.
+
+5.1.  Recommendation for Network Planners Considering Use of NPTv6
+      Translation
+
+   In light of the above, network planners considering the use of NPTv6
+   translation should carefully consider the kinds of applications that
+   they will need to run in the future and determine whether the
+   address-stability and provider-independence benefits are consistent
+   with their application requirements.
+
+
+
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 17]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+5.2.  Recommendations for Application Writers
+
+   Several mechanisms (e.g., STUN [RFC5389], Traversal Using Relays
+   around NAT (TURN) [RFC5766], and Interactive Connectivity
+   Establishment (ICE) [RFC5245]) have been used with traditional IPv4
+   NAT to circumvent some of the limitations of such devices.  Similar
+   mechanisms could also be applied to circumvent some of the issues
+   with an NPTv6 Translator.  However, all of these require the
+   assistance of an external server or a function co-located with the
+   translator that can tell an "internal" host what its "external"
+   addresses are.
+
+5.3.  Recommendation for Future Work
+
+   It might be desirable to define a general mechanism that would allow
+   hosts within a translation domain to determine their external
+   addresses and/or request that inbound traffic be permitted.  If such
+   a mechanism were to be defined, it would ideally be general enough to
+   also accommodate other types of NAT likely to be encountered by IPV6
+   applications, in particular IPv4/IPv6 Translation [RFC6144] [RFC6147]
+   [RFC6145] [RFC6146] [RFC6052].  For this and other reasons, such a
+   mechanism is beyond the scope of this document.
+
+6.  A Note on Port Mapping
+
+   In addition to overwriting IP addresses when datagrams 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] 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 datagram.  This address-
+   amplification feature is not generally foreseen as a necessity at
+   this time.
+
+   Since port mapping requires rewriting 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.
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 18]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   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 this document, it allows direct inbound
+   connections to internal nodes.  While this can be viewed as a benefit
+   of NPTv6 versus NAPT44, it does open internal nodes to attacks that
+   would be more difficult in a NAPT44 network.  From a security
+   standpoint, although this situation is not substantially worse than
+   running IPv6 with no NAT, some enterprises may assume that an NPTv6
+   Translator will offer similar protection to a NAPT44 device.
+
+   The port mapping mechanism in NAPT44 implementations requires that
+   state be created in both directions.  This has lead to an industry-
+   wide perception that NAT functionality is the same as a stateful
+   firewall.  It is not.  The translation function of the NAT only
+   creates dynamic state in one direction and has no policy.  For this
+   reason, it is RECOMMENDED that NPTv6 Translators also implement
+   firewall functionality such as described in [RFC6092], with
+   appropriate configuration options including turning it on or off.
+
+   When [RFC4864] talks about randomizing the subnet identifier, the
+   idea is to make it harder for worms to guess a valid subnet
+   identifier at an advertised network prefix.  This should not be
+   interpreted as endorsing concealment of the subnet identifier behind
+   the obfuscating function of a translator such as NPTv6.  [RFC4864]
+   specifically talks about how to obtain the desired properties of
+   concealment without using a translator.  Topology hiding when using
+   NAT is often ineffective in environments where the topology is
+   visible in application layer messaging protocols such as DNS, SIP,
+   SMTP, etc.  If the information were not available through the
+   application layer, [RFC2993] would not be valid.
+
+   Due to the potential interactions with IKEv2/IPsec NAT traversal, it
+   would be valuable to test interactions of NPTv6 with various aspects
+   of current-day IKEv2/IPsec NAT traversal.
+
+8.  Acknowledgements
+
+   The checksum-neutral algorithmic address mapping described in this
+   document is based on email written by Iljtsch van Beijnum.
+
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 19]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   The following people provided advice or review comments that
+   substantially improved this document: Allison Mankin, Christian
+   Huitema, Dave Thaler, Ed Jankiewicz, Eric Kline, Iljtsch van Beijnum,
+   Jari Arkko, Keith Moore, Mark Townsley, Merike Kaeo, Ralph Droms,
+   Remi Despres, Steve Blake, and Tony Hain.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2526]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
+              Addresses", RFC 2526, March 1999.
+
+   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", RFC 4193, October 2005.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+   [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.
+
+   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
+              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+              RFC 4787, January 2007.
+
+9.2.  Informative References
+
+   [GSE]      O'Dell, M., "GSE - An Alternate Addressing Architecture
+              for IPv6", Work in Progress, February 1997.
+
+   [NIST]     NIST, "Draft NIST Framework and Roadmap for Smart Grid
+              Interoperability Standards, Release 1.0", September 2009.
+
+   [RFC1071]  Braden, R., Borman, D., Partridge, C., and W. Plummer,
+              "Computing the Internet checksum", RFC 1071,
+              September 1988.
+
+   [RFC1624]  Rijsinghani, A., "Computation of the Internet Checksum via
+              Incremental Update", RFC 1624, May 1994.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+
+
+Wasserman & Baker             Experimental                     [Page 20]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   [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.
+
+   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
+              November 2000.
+
+   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
+              Self-Address Fixing (UNSAF) Across Network Address
+              Translation", RFC 3424, November 2002.
+
+   [RFC3484]  Draves, R., "Default Address Selection for Internet
+              Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
+              E. Klein, "Local Network Protection for IPv6", RFC 4864,
+              May 2007.
+
+   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", RFC 5245,
+              April 2010.
+
+   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+              October 2008.
+
+   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
+              Relays around NAT (TURN): Relay Extensions to Session
+              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
+
+   [RFC5902]  Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
+              IPv6 Network Address Translation", RFC 5902, July 2010.
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, June 2010.
+
+   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+              "Internet Key Exchange Protocol Version 2 (IKEv2)",
+              RFC 5996, September 2010.
+
+   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+              October 2010.
+
+
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 21]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in
+              Customer Premises Equipment (CPE) for Providing
+              Residential IPv6 Internet Service", RFC 6092,
+              January 2011.
+
+   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation", RFC 6144, April 2011.
+
+   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+              Algorithm", RFC 6145, April 2011.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011.
+
+   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
+              Beijnum, "DNS64: DNS Extensions for Network Address
+              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
+              April 2011.
+
+   [RFC6204]  Singh, H., Beebee, W., Donley, C., Stark, B., and O.
+              Troan, "Basic Requirements for IPv6 Customer Edge
+              Routers", RFC 6204, April 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 22]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+Appendix A.  Why GSE?
+
+   For the purpose of this discussion, let us oversimplify 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
+   Autonomous System (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
+   cannot 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 a consumer of transit services in other respects.  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] 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, as a result, are 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.  With widespread PI addressing, the routing table
+   will enumerate the networks at the edge of the transit domain, the
+   edge networks, rather than enumerate 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 ASs
+   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.  The vast majority of
+   networks (2/3) having the tools necessary to multihome are not
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 23]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   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 are 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 the Roadmap for the Smart Grid [NIST] is
+   that
+
+      "...the network should provide the capability to enable an
+      application in a particular domain to communicate with an
+      application in any other domain over the information network, with
+      proper management control as to who and where applications can be
+      inter-connected."
+
+   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 maintenance of BGP connectivity, and it enables
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 24]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   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.
+
+   The point is to
+
+   o  demonstrate that if one or the other representation of zero is not
+      used in the word in which the checksum is updated, the program
+      maps inner and outer addresses in a manner that is,
+      mathematically, 1:1 and onto (each inner address maps to a unique
+      outer address, and that outer address maps back to exactly the
+      same inner address), and
+
+   o  give guidance on the suppression of 0xFFFF checksums.
+
+   In short, in one's complement arithmetic, x-x=0 but will take the
+   negative representation of zero.  If 0xFFFF results are forced to the
+   value 0x0000, as is recommended in [RFC1071], the word the checksum
+   is adjusted in cannot be initially 0xFFFF, as on the return it will
+   be forced to 0.  If 0xFFFF results are not forced to the value 0x0000
+   as is recommended in [RFC1071], the word the checksum is adjusted in
+   cannot be initially 0, as on the return it will be calculated as
+   0+(~0) = 0xFFFF.  We chose to follow [RFC1071]'s recommendations,
+   which implies a requirement to not use 0xFFFF as a subnet number in
+   networks with a /48 external prefix.
+
+  /*
+   * Copyright (c) 2011 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:
+   *
+   * - Redistributions of source code must retain the above copyright
+   *   notice, this list of conditions and the following disclaimer.
+
+
+
+Wasserman & Baker             Experimental                     [Page 25]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   *
+   * - 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.
+   *
+   * - 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 "datagram" 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  datagram[8];
+  unsigned char   checksum[65536] = {0};
+
+
+
+Wasserman & Baker             Experimental                     [Page 26]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+  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;
+  {
+
+
+
+Wasserman & Baker             Experimental                     [Page 27]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+      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);
+  }
+
+  /*
+
+
+
+Wasserman & Baker             Experimental                     [Page 28]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   * NPTv6 datagram 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 datagram. */
+      for (i = 0; i < 8; i++) {
+          datagram[i] = inner[i];
+      }
+
+      /* Overwrite the prefix with the outer prefix. */
+      for (i = 0; i < 3; i++) {
+          datagram[i] = outer[i];
+      }
+
+      /* Adjust the checksum. */
+      datagram[3] = add1(datagram[3], adjustment);
+  }
+
+  /*
+   * NPTv6 datagram 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++) {
+          datagram[i] = inner[i];
+      }
+
+      /* Adjust the checksum. */
+      datagram[3] = sub1(datagram[3], adjustment);
+  }
+
+  /*
+   * Main program
+
+
+
+Wasserman & Baker             Experimental                     [Page 29]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+   */
+  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 datagram 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), datagram[0], datagram[1],
+                         datagram[2], datagram[3], datagram[4],
+                         datagram[5], datagram[6], datagram[7],
+                         sum1(datagram, 8));
+          }
+
+          checksum[subnet] = 1;
+
+          /*
+           * The resulting checksum should be the same as the inner
+           * address's checksum.
+           */
+          if (sum1(datagram, 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),
+
+
+
+Wasserman & Baker             Experimental                     [Page 30]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+                     datagram[0], datagram[1], datagram[2], datagram[3],
+                     datagram[4], datagram[5], datagram[6], datagram[7],
+                     sum1(datagram, 8));
+          }
+
+          /* Section 3.3: take a datagram from outside to inside */
+          nptv6_outer_to_inner();
+
+          /*
+           * The returning datagram should have the same checksum it
+           * left with.
+           */
+          if (sum1(datagram, 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",
+                     datagram[0], datagram[1], datagram[2], datagram[3],
+                     datagram[4], datagram[5], datagram[6], datagram[7],
+                     sum1(datagram, 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] != datagram[i]) {
+                  printf("outer->inner different: "
+                         "calculated: %x:%x:%x:%x:%x:%x:%x:%x "
+                         "inner: %x:%x:%x:%x:%x:%x:%x:%x\n",
+                         datagram[0], datagram[1], datagram[2],
+                         datagram[3], datagram[4], datagram[5],
+                         datagram[6], datagram[7], inner[0], inner[1],
+                         inner[2], inner[3], inner[4], inner[5],
+                         inner[6], inner[7]);
+                  break;
+              }
+          }
+      }
+  }
+
+
+
+
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 31]
+
+RFC 6296                          NPTv6                        June 2011
+
+
+Authors' Addresses
+
+   Margaret Wasserman
+   Painless Security
+   North Andover, MA  01845
+   USA
+
+   Phone: +1 781 405 7464
+   EMail: mrw@painless-security.com
+   URI:   http://www.painless-security.com
+
+
+   Fred Baker
+   Cisco Systems
+   Santa Barbara, California  93117
+   USA
+
+   Phone: +1-408-526-4257
+   EMail: fred@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wasserman & Baker             Experimental                     [Page 32]
+