Network Working Group                                       M. Wasserman
Internet-Draft                                         Painless Security
Intended status: Standards Track                                F. Baker
Expires: June 17, 2011                                     Cisco Systems
                                                       December 14, 2010


                IPv6-to-IPv6 Network Prefix Translation
                           draft-mrw-nat66-03

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 (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

   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].

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 Internet-Draft will expire on June 17, 2011.

Copyright Notice

   Copyright (c) 2010 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



Wasserman & Baker         Expires June 17, 2011                 [Page 1]


Internet-Draft                    NPTv6                    December 2010


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  What is Address Independence?  . . . . . . . . . . . . . .  4
     1.2.  NPTv6 Applicability  . . . . . . . . . . . . . . . . . . .  6
   2.  NPTv6 Overview . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.1.  NPTv6: the simplest case . . . . . . . . . . . . . . . . .  7
     2.2.  NPTv6 between peer networks  . . . . . . . . . . . . . . .  8
     2.3.  NPTv6 redundnacy and load-sharing  . . . . . . . . . . . .  9
     2.4.  NPTv6 multihoming  . . . . . . . . . . . . . . . . . . . . 10
     2.5.  Mapping with No Per-Flow State . . . . . . . . . . . . . . 10
     2.6.  Checksum-Neutral Mapping . . . . . . . . . . . . . . . . . 11
   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 . . . . . . . . . . . . 13
     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.  NAT Behavioral Requirements  . . . . . . . . . . . . . . . 15
   5.  Implications for Applications  . . . . . . . . . . . . . . . . 16
   6.  A Note on Port Mapping . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Changes Between draft-mrw-behave-nat66-00 and -01  . . . . 18
     10.2. Changes between *behave-nat66-01 and -02 . . . . . . . . . 18
     10.3. Changes between *behave-nat66-02 and *nat66-00 . . . . . . 18
     10.4. Changes between *nat66-00 and *nat66-01  . . . . . . . . . 19
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     11.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Why GSE?  . . . . . . . . . . . . . . . . . . . . . . 21



Wasserman & Baker         Expires June 17, 2011                 [Page 2]


Internet-Draft                    NPTv6                    December 2010


   Appendix B.  Verification code . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27

















































Wasserman & Baker         Expires June 17, 2011                 [Page 3]


Internet-Draft                    NPTv6                    December 2010


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 don't checksum the IP header, such as SCTP
   or DCCP, and to transports that use the TCP/UDP pseudo-header and
   checksum [RFC1071].

   This has several ramifications:

   o  Any security benefit that NAT44 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 [I-D.ietf-v6ops-cpe-simple-security].

   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.

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.



Wasserman & Baker         Expires June 17, 2011                 [Page 4]


Internet-Draft                    NPTv6                    December 2010


      *  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 therefore 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 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 Local Network Protection [RFC4864] document discusses a related
   concept called "Address Autonomy" as a benefit of NAT44.  [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, 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 their ISP to install specific routes for
   the enterprise's PI addresses.  There are a number of practical



Wasserman & Baker         Expires June 17, 2011                 [Page 5]


Internet-Draft                    NPTv6                    December 2010


   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].  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



Wasserman & Baker         Expires June 17, 2011                 [Page 6]


Internet-Draft                    NPTv6                    December 2010


   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 privacy purpose; 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
   it was allocated by.

   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
   deployment of NPTv6 to read [RFC4864], and to carefully consider the
   alternatives described in that document, some of which may cause
   fewer problems than NPTv6.


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.








Wasserman & Baker         Expires June 17, 2011                 [Page 7]


Internet-Draft                    NPTv6                    December 2010


               External Network:  Prefix = 2001:0DB8:0001:/48
                   --------------------------------------
                                     |
                                     |
                              +-------------+
                              |     NPTv6   |
                              |  Translator |
                              +-------------+
                                     |
                                     |
                   --------------------------------------
               Internal Network:  Prefix = FD01:0203:0405:/48

                       Figure 1: A simple translator

   Figure 1 shows a 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 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 prefix
   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.







Wasserman & Baker         Expires June 17, 2011                 [Page 8]


Internet-Draft                    NPTv6                    December 2010


                  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

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.  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.

               External Network:  Prefix = 2001:0DB8:0001:/48
                   --------------------------------------
                          |                      |
                          |                      |
                   +-------------+        +-------------+
                   |  NPTv6      |        |  NPTv6      |
                   |  Translator |        |  Translator |
                   |   #1        |        |   #2        |
                   +-------------+        +-------------+
                          |                      |
                          |                      |
                   --------------------------------------
               Internal Network:  Prefix = FD01:0203:0405:/48

                      Figure 3: Parallel Translators












Wasserman & Baker         Expires June 17, 2011                 [Page 9]


Internet-Draft                    NPTv6                    December 2010


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 show in Figure 4, 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.

   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
   prefix used in shifting sessions changes.  This obviously causes them
   to fail.  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.




Wasserman & Baker         Expires June 17, 2011                [Page 10]


Internet-Draft                    NPTv6                    December 2010


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 packet, which avoids the need
   for the NPTv6 Translator to modify those transport layer headers to
   correct the checksum value.


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



Wasserman & Baker         Expires June 17, 2011                [Page 11]


Internet-Draft                    NPTv6                    December 2010


   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, if necessary by extending the shorter of the two with zeroes.
   These two prefixes will be used in the prefix translation function
   described in Section 3.2 and Section 3.3.

   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:

   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
      Section 3.4 or Section 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 pseudoheader's checksum, and

   o  A 16-bit word of the address has the adjustment subtracted from it
      (bitwise inverted and added to it) 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



Wasserman & Baker         Expires June 17, 2011                [Page 12]


Internet-Draft                    NPTv6                    December 2010


      as appropriate.

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.

   NPTv6 Translator implementations MUST implement the /48 mapping.

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, 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).

   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



Wasserman & Baker         Expires June 17, 2011                [Page 13]


Internet-Draft                    NPTv6                    December 2010


   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 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, but applying it to that word.

   Although any 16-bit portion of an IPv6 IID could contain 0xFFFF, an



Wasserman & Baker         Expires June 17, 2011                [Page 14]


Internet-Draft                    NPTv6                    December 2010


   IID of all-ones is a reserved anycast identifier that should not be
   used on the network [RFC2526].  If a NPTv6 Translator discovers a
   packet with an IID of all-zeros while performing address mapping,
   that packet MUST be dropped, and an ICMPv6 Parameter Problem error
   SHOULD be generated [RFC4443].

   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].

   NPTv6 Translators that do not have a manually configured internal
   prefix SHOULD randomly generate a ULA prefix for the internal network
   and advertise that prefix in router advertisements.  NPTv6
   Translators with more than one internal interface SHOULD assign a
   (non-0xFFFF) subnet number to each link, and include the subnet
   number in router advertisements on the corresponding link.  NPTv6
   Translators that generate a ULA prefix MUST generate the prefix using
   a random number as described in RFC4291 [RFC4193], and SHOULD store
   the randomly generated prefix in non-volatile storage for continued
   use.

4.2.  NAT Behavioral Requirements

   NPTv6 Translators MUST support hairpinning behavior, as defined in
   the NAT Behavioral Requirements for UDP document [RFC4787].  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), 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-



Wasserman & Baker         Expires June 17, 2011                [Page 15]


Internet-Draft                    NPTv6                    December 2010


   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, 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.

   The means of address discovery is not within the scope of this
   specification.


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 RFC 1918 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



Wasserman & Baker         Expires June 17, 2011                [Page 16]


Internet-Draft                    NPTv6                    December 2010


   feature should not be needed in IPv6.

   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.  For this reason, it is
   RECOMMENDED that NPTv6 Translators also implement firewall
   functionality such as described in
   [I-D.ietf-v6ops-cpe-simple-security], with appropriate configuration
   options including turning it on or off.


8.  IANA Considerations

   This document has no 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: Jari Arrko, Iljtsch Van
   Beijnum, Ralph Droms, Remi Depres, Tony Hain, Ed Jankiewicz, Dave
   Thaler, Mark Townsley, and Steve Blake.




Wasserman & Baker         Expires June 17, 2011                [Page 17]


Internet-Draft                    NPTv6                    December 2010


   This document was written using the xml2rfc tool described in RFC
   2629 [RFC2629].


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:

   o  Added Fred Baker as a co-author.

   o  Minor arithmetic corrections.

   o  Added AH to paragraph on NAT security issues.

   o  Added additional NAT topologies to overview (diagrams TBD).

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

   There were further changes made between *behave-nat66-01 and -02:

   o  Removed topology hiding mechanism.

   o  Added diagrams.

   o  Made minor updates based on mailing list feedback.

   o  Added discussion of IPv6 SAF document.

   o  Added applicability section.

   o  Added discussion of Address Independence requirement.

   o  Added hairpinning requirement and discussion of applicability of
      other NAT behavioral requirements.

10.3.  Changes between *behave-nat66-02 and *nat66-00

   There were further changes made between behave-nat66-02 and nat66-02:

   o  Added mapping for prefixes longer than /48.

   o  Change draft name to remove reference to the behave WG.

   o  Resolved various open issues and fixed typos.




Wasserman & Baker         Expires June 17, 2011                [Page 18]


Internet-Draft                    NPTv6                    December 2010


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

   o  Change the acronym "NAT66" to "NPTv6", so people don't read "NAT"
      and MEGO.

   o  Change the term used to refer to the function from "NAT66 device"
      to "NPTv6 Translator".  It's not a "device" function, it's a
      function that is applied between two interfaces.  Consider a
      router with two upstreams and two legs in the local network; it
      will not translate between the local legs, but will translate to
      and from each upstream, and be configured differently for each of
      the two ISPs.

   o  Comment specifically on the security aspects.

   o  Comment specifically on the application issues raised on this
      list.

   o  Comment specifically on multihoming, load-sharing, and asymmetric
      routing.

   o  Spell out the hairpinning requirement and its implications.

   o  Spell out the service provider side of Address Independence.

   o  00 focuses on the edge's view

   o  Detail the algorithm in a manner clearer to the implementor (I
      think)

   o  Spell out the case for GSE-style DMZs between the edge and the
      transit network, which is about the implications for the global
      routing table.

   o  Refer to xref target="I-D.ietf-v6ops-cpe-simple-security"/>.


11.  References

11.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



Wasserman & Baker         Expires June 17, 2011                [Page 19]


Internet-Draft                    NPTv6                    December 2010


              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.

11.2.  Informative References

   [GSE]      O'Dell, M., "GSE - An Alternate Addressing Architecture
              for IPv6", February 1997,
              <http://tools.ietf.org/id/draft-ietf-ipngwg-gseaddr>.

   [I-D.ietf-v6ops-cpe-simple-security]
              Woodyatt, J., "Recommended Simple Security Capabilities in
              Customer Premises Equipment for Providing Residential IPv6
              Internet Service", draft-ietf-v6ops-cpe-simple-security-16
              (work in progress), October 2010.

   [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.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [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.

   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
              E. Klein, "Local Network Protection for IPv6", RFC 4864,
              May 2007.






Wasserman & Baker         Expires June 17, 2011                [Page 20]


Internet-Draft                    NPTv6                    December 2010


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] 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 CIDR Report, there are
   currently more than 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 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



Wasserman & Baker         Expires June 17, 2011                [Page 21]


Internet-Draft                    NPTv6                    December 2010


   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

      "...the Network should enable an application in a particular
      domain to communicate with an application in any other domain in
      the information network, with proper management control over who
      and where applications can be interconnected."

   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

   Note to RFC Editor: please #include the standard IETF-BSD license for
   code snippets.

#include "stdio.h"



Wasserman & Baker         Expires June 17, 2011                [Page 22]


Internet-Draft                    NPTv6                    December 2010


#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 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) {



Wasserman & Baker         Expires June 17, 2011                [Page 23]


Internet-Draft                    NPTv6                    December 2010


            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



Wasserman & Baker         Expires June 17, 2011                [Page 24]


Internet-Draft                    NPTv6                    December 2010


 *
 * create
 *  - a source address in internal format,
 *  - 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
 * 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++) {



Wasserman & Baker         Expires June 17, 2011                [Page 25]


Internet-Draft                    NPTv6                    December 2010


        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 then 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);



Wasserman & Baker         Expires June 17, 2011                [Page 26]


Internet-Draft                    NPTv6                    December 2010


        /* section 3.2: take a packet from inside to outside */
        nptv6_inner_to_outer();
        if (sum1(packet, 8) != sum1(inner, 8)) {
            printf("inner->outer incorrect: "
                   "%x:%x:%x:%x:%x:%x:%x:%x(%x) "
                   "-> %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();
        if (sum1(packet, 8) != sum1(inner, 8)) {
            printf("outer->inner checksum incorrect: "
                   "%x:%x:%x:%x:%x:%x:%x:%x(%x) "
                   "-> %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));
        }
        for (i = 0; i < 8; i++) {
            if (inner[i] != packet[i]) {
                printf("outer->inner different: "
                       "%x:%x:%x:%x:%x:%x:%x:%x vs "
                       "%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;
            }
        }
    }
}













Wasserman & Baker         Expires June 17, 2011                [Page 27]


Internet-Draft                    NPTv6                    December 2010


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-secuirty.com


   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Phone: +1-408-526-4257
   Email: fred@cisco.com
































Wasserman & Baker         Expires June 17, 2011                [Page 28]