[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 6346

Network Working Group                                       R. Bush, Ed.
Internet-Draft                                 Internet Initiative Japan
Intended status: Experimental                            January 5, 2011
Expires: July 9, 2011


             The A+P Approach to the IPv4 Address Shortage
                          draft-ymbk-aplusp-07

Abstract

   We are facing the exhaustion of the IANA IPv4 free IP address pool.
   Unfortunately, IPv6 is not yet deployed widely enough to fully
   replace IPv4, and it is unrealistic to expect that this is going to
   change before the depletion of IPv4 addresses.  Letting hosts
   seamlessly communicate in an IPv4-world without assigning a unique
   globally routable IPv4 address to each of them is a challenging
   problem.

   This draft proposes an IPv4 address sharing scheme, treating some of
   the port number bits as part of an extended IPv4 address (Address
   plus Port, or A+P).  Instead of assigning a single IPv4 address to a
   single customer device, we propose to extend the address field by
   using bits from the port number range in the TCP/UDP header as
   additional end point identifiers, thus leaving a reduced range of
   ports available to applications.  This means assigning the same IPv4
   address to multiple clients (e.g., CPE, mobile phones), each with its
   assigned port-range.  In the face of IPv4 address exhaustion, the
   need for addresses is stronger than the need to be able to address
   thousands of applications on a single host.  If address translation
   is needed, the end-user should be in control of the translation
   process - not some smart boxes in the core.

Requirements Language

   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.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute



Bush                      Expires July 9, 2011                  [Page 1]

Internet-Draft          A+P Addressing Extension            January 2011


   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 July 9, 2011.

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



























Bush                      Expires July 9, 2011                  [Page 2]

Internet-Draft          A+P Addressing Extension            January 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Problems with Carrier Grade NATs . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Design Constraints and Functions . . . . . . . . . . . . . . .  6
     3.1.  Design Constraints . . . . . . . . . . . . . . . . . . . .  6
     3.2.  A+P Functions  . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Overview of the A+P Solution . . . . . . . . . . . . . . .  8
       3.3.1.  Signaling  . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.2.  Address Realm  . . . . . . . . . . . . . . . . . . . . 11
       3.3.3.  Reasons for Allowing Multiple A+P Gateways . . . . . . 15
       3.3.4.  Overall A+P Architecture . . . . . . . . . . . . . . . 17
   4.  Stateless A+P Mapping Function . . . . . . . . . . . . . . . . 17
     4.1.  Stateless A+P Mapping gateway (SMAP) Function
           description  . . . . . . . . . . . . . . . . . . . . . . . 17
     4.2.  Implementation Mode  . . . . . . . . . . . . . . . . . . . 19
     4.3.  Towards IPv6-only Networks . . . . . . . . . . . . . . . . 22
     4.4.  PRR: On Stateless and Binding Table Modes  . . . . . . . . 22
     4.5.  General recommendations on SMAP  . . . . . . . . . . . . . 23
   5.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 23
     5.1.  A+P Deployment Models  . . . . . . . . . . . . . . . . . . 23
       5.1.1.  A+P for Broadband Providers  . . . . . . . . . . . . . 23
       5.1.2.  A+P for Mobile Providers . . . . . . . . . . . . . . . 23
       5.1.3.  A+P from the Provider Network Perspective  . . . . . . 24
     5.2.  Dynamic Allocation of Port Ranges  . . . . . . . . . . . . 27
     5.3.  Example of A+P-forwarded Packets . . . . . . . . . . . . . 28
       5.3.1.  Forwarding of Standard Packets . . . . . . . . . . . . 32
       5.3.2.  Handling ICMP  . . . . . . . . . . . . . . . . . . . . 32
       5.3.3.  Fragmentation  . . . . . . . . . . . . . . . . . . . . 33
       5.3.4.  Limitations of the A+P approach  . . . . . . . . . . . 33
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
   8.  Authors  . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 36
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 36
     10.2. Informative References . . . . . . . . . . . . . . . . . . 36
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38












Bush                      Expires July 9, 2011                  [Page 3]

Internet-Draft          A+P Addressing Extension            January 2011


1.  Introduction

   This document describes a technique to deal with the imminent IPv4
   address space exhaustion.  Many large Internet Service Providers
   (ISPs) face the problem that their networks' customer edges are so
   large that it will soon not be possible to provide each customer with
   a unique public IPv4 address.  Therefore, although undesirable,
   address sharing, in the same molds as NAT, is inevitable.

   To allow end-to-end connectivity between IPv4 speaking applications
   we propose to extend the semantics of the IPv4 address with bits from
   the UDP/TCP header.  Assuming we could limit the applications' port
   addressing to any number of bits lower than 16, we can increase the
   effective size of an IPv4 address by remaining additional bits of up
   to 16.  In this scenario, 1 to 65536 customers could be multiplexed
   on the same IPv4 address, while allowing them a fixed or dynamic
   range of 1 to 65536 ports.  Customers could for example receive
   initial fixed port range, defined by operator and dynamically request
   additional blocks, depending on their contract.  We call this
   "extended addressing" or "A+P" (Address plus Port) addressing.  The
   main advantage of A+P is that it preserves the Internet "end-to-end"
   paradigm by not requiring translation (at least for some ports) of an
   IP address.

1.1.  Problems with Carrier Grade NATs

   Various forms of NATs will be installed at various levels and places
   in the IPv4-Internet to achieve address compression.  This document
   argues for mechanisms where this happens as close to the edge of the
   network as possible, thereby minimizing damage to the End-to-End
   Principle and allowing end-customers to retain control over the
   address and port translation.  Therefore it is essential to create
   mechanisms to "bypass" NATs in the core when applicable and keep the
   control at the end-user.

   With Carrier Grade NATs in the core of the network the user is
   trapped behind unchangeable application policies, and the deployment
   of new applications is hindered by the need to implement the
   corresponding Application Level Gateways (ALGs) on the CGNs.  This is
   the opposite of the "end-to-end" model of the Internet.

   With the smarts at the edges, one can easily deploy new applications
   between consenting end-points by merely tweaking the NATs at the
   corresponding Customer Premises Equipment (CPE), or even upgrading
   them to a new version that supports a specific ALG.

   Today's NATs are typically mitigated by offering the customers
   limited control over them, e.g. port forwarding or UPnP/NAT-PMP.



Bush                      Expires July 9, 2011                  [Page 4]

Internet-Draft          A+P Addressing Extension            January 2011


   However, this is not expected to work with CGNs.  CGN proposals -
   other than DS-Lite [I-D.ietf-softwire-dual-stack-lite] with A+P or
   PCP [I-D.wing-softwire-port-control-protocol]- admit that it is not
   expected that applications that require specific port assignment or
   port mapping from the NAT box will keep working.

   Another issue with CGN is the trade-off between session state and
   network placement.  The furthest from the edge the CGN placed, the
   more session state needs to be kept due to larger subscriber
   aggregation, and more disruption in the case of a failure.  In order
   to reduce the state, CGNs would end up somewhere closer to the edge.
   The CGN hence trades scalability for the amount of state that needs
   to be kept, which makes optimally placing a CGN a hard engineering
   problem

   In some deployment scenarios, CGN can be seen as single point of
   failure and therefore the availability of delivered services are
   impacted by the ones of CGN s devices.  Means to ensure state
   synchronisation and failover would be required to allow for service
   continuity whenever a failure occurs.

   Intra-domain paths may not be optimal for communications between two
   nodes connected to the same domain deploying CGNs, hence leading to
   path stretches.


2.  Terminology

   This document makes use of the following terms:

      Public Realm: This realm contains only public routable IPv4
      addresses.  Packets in this realm are forwarded based on the
      destination IPv4 address

      A+P Realm: This realm contains both public routable IPv4 and also
      A+P addresses.

      A+P Packet: A regular IPv4 packet is forwarded based on the
      destination IPv4 address and the TCP/UDP port numbers.

      Private Realm: This realm contains IPv4 addresses that are not
      globally routed.  They may be taken from the [RFC1918] range.
      However, this draft does not make such an assumption.  We regard
      as private address space any IPv4 address, which needs to be
      translated in order to gain global connectivity, irrespective of
      whether it falls in [RFC1918] space or not.





Bush                      Expires July 9, 2011                  [Page 5]

Internet-Draft          A+P Addressing Extension            January 2011


      Port Range Router (PRR): A device that forwards A+P packets.

      Customer Premises Equipment (CPE): cable/DSL modem.

      Provider Edge Router (PE): Customer aggregation router

      Provider Border Router (BR): Providers edge to other providers

      Network Core Routers (Core): Provider routers which are not at the
      edges.


3.  Design Constraints and Functions

   The problem of address space shortage is first felt by providers with
   a very large end-user customer base, such as broadband providers and
   mobile service providers.  Though the cases and requirements are
   slightly different, they share many commonalities.  In the following
   we develop a set of overall design constraints for solutions
   addressing the IPv4 address shortage problem.

3.1.  Design Constraints

   We regard several constraints as important for our design:

   1)      End-to-End is under customer control: Customers shall have
           the ability to deploy new application protocols at will.
           IPv4 address shortage should not be a license to break the
           Internet's end-to-end paradigm.

   2)      Backward compatibility: Approaches should be transparent to
           unaware users.  Devices or existing applications should be
           able to work without modification.  Emergence of new
           applications should not be limited.

   3)      Highly-scalable and minimal state core: Minimal state should
           be kept inside the ISP's network.  If the operator is rolling
           out A+P incrementally, it is understood there may be state in
           the core in the non-A+P part of such a roll-out.

   4)      Efficiency vs. complexity: Operators should have the
           flexibility to trade off port multiplexing efficiency and
           scalability and end-to-end transparency.

   5)      "Double-NAT" should be avoided: Multiple gateway devices
           might be present in a path, and once one has done some
           translation, those packets should not be re-translated.




Bush                      Expires July 9, 2011                  [Page 6]

Internet-Draft          A+P Addressing Extension            January 2011


   6)      Legal traceability: ISPs must be able to provide the identity
           of a customer from the knowledge of the IPv4 public address
           and the port.  This should have as low an impact as is
           reasonable on storage by the ISP.  We assume that NATs on
           customer premises do not pose much of a problem, while
           provider NATs need to keep additional logs.

   7)      IPv6 deployment should be encouraged.  NAT444 strongly biases
           the users to the deployment of RFC 1918 addressing.

   Constraint 5 is important: while many techniques have been deployed
   to allow applications to work through a NAT, traversing cascaded NATs
   is crucial if NATs are being deployed in the core of a provider
   network.

3.2.  A+P Functions

   The A+P architecture can be split into three distinct functions:
   encaps/decaps, NAT, and signaling.

   Encaps/decaps function: is used to forward port-restricted A+P-
   packets over intermediate legacy devices.  The encapsulation function
   takes an IPv4 packet, looks up the IP and TCP/UDP headers, and puts
   the packet into the appropriate tunnel.  The state needed to perform
   this action is comparable to a forwarding table.  The decapsulation
   device SHOULD check if the source address and port of packets coming
   out of the tunnel are legitimate (e.g., see [BCP38]).  Based on the
   result of such a check, the packet MAY be forwarded untranslated, it
   MAY be discarded or MAY be NATed.  In this document we refer to a
   device that provides this encaps/decaps functionality as Port-Range-
   Router (PRR).

   Network Address Translation (NAT) function: is used to connect legacy
   end-hosts.  Unless upgraded, end-hosts or end-systems are not aware
   of A+P restrictions and therefore assume a full IP address.  The NAT
   function performs any address or port translation, including
   Application Level Gateways (ALGs) whenever required.  The state that
   has to be kept to implement this function is the mapping for which
   external addresses and ports have been mapped to which internal
   addresses and ports, just as in CPEs embedding NAT today.  A subtle,
   but very important, difference should be noted here: the customer has
   control over the NATing process or might choose to "bypass" the NAT.
   If this is done, we call the NAT a large scale NAT (LSN).  However,
   if the NAT that does NOT allow the customer to control the
   translation process, we refer to as a CGN.

   Signaling function: is used in order to allow A+P-aware devices get
   to know which ports are assigned to be passed through untranslated



Bush                      Expires July 9, 2011                  [Page 7]

Internet-Draft          A+P Addressing Extension            January 2011


   and what will happen to packets outside the assigned port-range
   (e.g., could be NATed or discarded).  Signaling may also be used to
   learn the encapsulation method and any endpoint information needed.
   In addition, the signaling function may be used to dynamically assign
   the requested port-range.

3.3.  Overview of the A+P Solution

   As mentioned above, the core architectural elements of the A+P
   solution are three separated and independent functions: the NAT
   function, the encaps/decaps function, and the signaling function.
   The NAT function is similar to a NAT as we know it today: it performs
   a translation between two different address realms.  When the
   external realm is public IPv4 address space, we assume that the
   translation is many-to-one, in order to multiplex many customers on a
   single public IPv4 address.  The only difference with a traditional
   NAT (Figure 1) is that the translator might only be able to use a
   restricted range of ports when mapping multiple internal addresses
   onto an external one, e.g., the external address realm might be port-
   restricted.


                    "internal-side"          "external-side"
                                   +-----+
                      internal     |  N  |     external
                      address  <---|  A  |---> address
                       realm       |  T  |      realm
                                   +-----+


                              Traditional NAT

                                 Figure 1

   The encaps/decaps function, on the other hand, is the ability to
   establish a tunnel with another end-point providing the same
   function.  This implies some form of signaling to establish a tunnel.
   Such signaling can be viewed as integrated with DHCP or as a separate
   service.  Section 3.3.1 discusses the constraints of this signaling
   function.  The tunnel can be an IPv6 or IPv4 encapsulation, a layer-2
   tunnel, or some other form of softwire.  Note that the presence of a
   tunnel allows unmodified, naive, or even legacy devices between the
   two endpoints.

   Two or more devices which provide the encaps/decaps function and are
   linked by tunnels to form an A+P subsystem.  The function of each
   gateway is to encapsulate and decapsulate respectively.  Figure 2
   depicts the simplest possible A+P subsystem, that is, two devices



Bush                      Expires July 9, 2011                  [Page 8]

Internet-Draft          A+P Addressing Extension            January 2011


   providing the encaps/decaps function.


                      +------------------------------------+
           Private    | +----------+  tunnel  +----------+ |   Public
           address  --|-| gateway  |==========| gateway  |-|-- address
           realm      | +----------+          +----------+ |    realm
                      +------------------------------------+
                                   A+P subsystem


                          A simple A+P subsystem

                                 Figure 2

   Within an A+P subsystem, the public address realm is extended by
   using bits from the port number when forwarding packets.  Each device
   is assigned one address from the external realm and a range of port
   numbers.  Hence, devices which are part of an A+P subsystem can
   communicate with the public realm without the need for address
   translation (i.e., preserving end-to-end packet integrity): an A+P
   packet originated from within the A+P subsystem can be simply
   forwarded over tunnels up to the endpoint, where it gets decapsulated
   and routed in the external realm.

3.3.1.  Signaling

   The following information needs to be available on all the gateways
   in the A+P subsystem.  It is expected that there will be a signaling
   protocols such as [I-D.bajko-pripaddrassign],
   [I-D.boucadair-dhcpv6-shared-address-option],
   [I-D.boucadair-pppext-portrange-option], or
   [I-D.wing-softwire-port-control-protocol].

   The information that needs to be shared is the following:

   o  a set of public IPv4 addresses,

   o  for each IPv4 address a starting point for the allocated port-
      range,

   o  number of delegated ports,

   o  optional key that enables partial or full preservation of entropy
      in port randomization - see [I-D.bajko-pripaddrassign],

   o  lifetime for each IPv4 address and allocated port-set,




Bush                      Expires July 9, 2011                  [Page 9]

Internet-Draft          A+P Addressing Extension            January 2011


   o  the tunneling technology to be used (e.g., "IPv6-encapsulation")

   o  addresses of the tunnel endpoints (e.g., IPv6 address of tunnel
      endpoints)

   o  whether or not NAT function is provided by the gateway

   o  a device identification number and some authentication mechanisms

   o  a version number and some reserved bits for future use.

   Note that the functions of encapsulation and decapsulation have been
   separated from the NAT function.  However, to accommodate legacy
   hosts, NATing is likely to be provided at some point in the path;
   therefore the availability or absence of NATing MUST be communicated
   in signaling, as A+P is agnostic about NAT placement.

   The port-ranges can be allocated in two different ways:

   o  If applications or end-hosts behind the CPE are not UPnPv2/NAT-PMP
      aware, then the CPE SHOULD request ports via mechanisms, e.g. as
      described in [I-D.bajko-pripaddrassign] and
      [I-D.boucadair-pppext-portrange-option].  Note that different
      port-ranges can have different lifetimes, and the CPE is not
      entitled to use them after they expire - unless it refreshes those
      ranges.  It is up to the ISP to put mechanisms in place, that
      determine what percentage of already allocated port-ranges should
      be exhausted before a CPE may requests additional ranges, how
      often the CPE can request additional ranges, and so on.  (To
      prevent Denial of Service attacks.)

   o  If applications behind the CPE are UPnPv2/NAT-PMP aware additional
      ports MAY be requested through that mechanism.  In this case the
      CPE should forward those requests to the LSN and the LSN should
      reply reporting if the requested ports are available or not (and
      if they are not available some alternatives should be offered).
      Here again, to prevent potential denial of service attacks,
      mechanism should be in place to prevent UPnPv2/NAT-PMP packet
      storms and fast port allocation.  Detailed description of this
      mechanism, called PCP is described in
      [I-D.wing-softwire-port-control-protocol].

   Whatever signaling mechanism is used inside the tunnels, DHCP, IPCP,
   or PCP-based, synchronization between signaling server and PRR must
   be established in both directions.  For example, if we use DHCP as
   signaling mechanism, the PRR must communicate to DHCP server at least
   its IP range.  The DHCP server then starts to allocate IPs and port-
   ranges to CPEs and communicates back to the PRR which IP and port



Bush                      Expires July 9, 2011                 [Page 10]

Internet-Draft          A+P Addressing Extension            January 2011


   range have been allocated to which CPE, so the PRR knows to which
   tunnel redirect incoming traffic.  In addition, DHCP MUST also
   communicate lifetimes of port-ranges assigned to CPE via the PRR.
   DHCP server may be co-located with the PRR function to ease address
   management and also to avoid the need to introduce a communication
   protocol between the PRR and DHCP.

   If UPnPv2/NAT-PMP is used as dynamic port allocation mechanism, the
   PRR must also communicate to the DHCP (or IPCP) server to avoid those
   ports.  The PRR must somehow (DHCP or IPCP options) communicate back
   to CPE that allocation of ports was successful, so CPE adds those
   ports to existing port ranges.

   Note that operation can be even simplified if a fixed length of port
   ranges are assigned to all customers and no differentiation is
   implemented based on port range length.  In such case, the binding
   table maintained by the PRR can be dynamically built upon the receipt
   of a first packet form a port-restricted device.

3.3.2.  Address Realm

   Each gateway within the A+P subsystem manages a certain portion of
   A+P address space, that is, a portion of IPv4 space which is extended
   by borrowing bits from the port number.  This address space may be a
   single, port-restricted IPv4 address.  The gateway MAY use its
   managed A+P address space for several purposes:

   o  Allocation of a sub-portion of the A+P address space to other
      authenticated A+P gateways in the A+P subsystem (referred to as
      delegation).  We call the allocated sub-portion delegated address
      space.

   o  Exchange of (untranslated) packets with the external address
      realm.  For this to work, such packets MUST use source address and
      port belonging to the non-delegated address space.

   If the gateway is also capable of performing the NAT function, it MAY
   translate packets arriving on an internal interface which are outside
   of its managed A+P address space into non-delegated address space.

   Hence, a provider may have 'islands' of A+P as they slowly deploy
   over time.  The provider does not have to replace CPE until they want
   to provide the A+P function to an island of users or even to one
   particular user in a sea of non-A+P users.

   An A+P gateway ("A"), accepts incoming connections from other A+P
   gateways ("B").  Upon connection establishment (provided appropriate
   authentication), B would "ask" A for delegation of an A+P address.



Bush                      Expires July 9, 2011                 [Page 11]

Internet-Draft          A+P Addressing Extension            January 2011


   In turn, A will inform B about its public IPv4 address, and will
   delegate a portion of its port-range to B. In addition, A will also
   negotiate the encaps/decaps function with B (e.g., let B know the
   address of the decaps device/other-end-point of the tunnel).

   This could be implemented for example via a NAT-PMP or DHCP-like
   solution.  In general the following rule applies: A sub-portion of
   the managed A+P address space is delegated as long as devices below
   ask for it, otherwise private IPv4 is provided to support legacy
   hosts.

   In the following example, IPv4 address reserved for documentation
   blocks defined in [RFC5737] are used.


              private    +-----+          +-----+     public
              address ---|  B  |==========|  A  |---  Internet
               realm     +-----+          +-----+

                         Address space realm of A:
                         public IPv4 address = 192.0.2.1
                         port range = 0-65535

                         Address space realm of B:
                         public IPv4 address = 192.0.2.1
                         port range = 2560-3071


                           Configuration example

                                 Figure 3

   Figure 3 illustrates a sample configuration.  Note that A might
   actually consist of three different devices: one that handles
   signaling requests from B; one device that performs encapsulation and
   decapsulation; and, if provided, one device that performs NATing
   function (e.g., LSN).  Packet forwarding is assumed to be as follows:
   In the "out-bound" case, a packet arrives from the private address
   realm to B. As stated above, B has two options: it can either apply
   or not apply the NAT function.  The decision depends upon the
   specific configuration and/or the capabilities of A and B. Note that
   NAT functionality is required to support legacy hosts, however, this
   can be done at either of the two devices A or B. The term NAT refers
   to translating the packet into the managed A+P address (B has address
   192.0.2.1 and ports 2560-3071 in the example above).  We then have
   two options:





Bush                      Expires July 9, 2011                 [Page 12]

Internet-Draft          A+P Addressing Extension            January 2011


   1)  B NATs the packet.  The translated packet is then tunneled to A.
       A recognizes that the packet has already been translated, because
       the source address and port match the delegated space.  A
       decapsulates the packet and releases it in the public Internet.

   2)  B does not NAT the packet.  The untranslated packet is then
       tunneled to A. A recognizes that the packet has not been
       translated, so A forwards the packet to a co-located NATing
       device, which translates the packet and routes it in the public
       Internet.  This device, e.g. - an LSN, has to store the mapping
       between the source port used to NAT and the tunnel where the
       packet came from, in order to correctly route the reply.  Note
       that A cannot use a port number from the range that has been
       delegated to B. As a consequence A has to assign a part of its
       non-delegated address space to the NATing function.

   "Inbound" packets are handled in the following way: a packet from the
   public realm arrives at A. A analyzes the destination port number to
   understand whether the packet needs to be NATed or not.

   1)  If the destination port number belongs to the range that A
       delegated to B, then A tunnels the packet to B. B NATs the packet
       using its stored mapping and forwards the translated packet to
       the private domain.

   2)  If the destination port number is from the address space of the
       LSN, then A passes the packet on to the co-located LSN which uses
       its stored mapping to NAT the packet into the private address
       realm of B. The appropriate tunnel is stored as well in the
       mapping of the initial NAT.  The LSN then encapsulates the packet
       to B, which decapsulates it and normally routes it within its
       private realm.

   3)  Finally, if the destination port number neither falls in a
       delegated range, nor into the address range of the LSN, A
       discards the packet.  If the packet is passed to the LSN, but no
       mapping can be found, the LSN discards the packet.

   Observe that A must be able to receive all IPv4 packets destined to
   the public IPv4 address (192.0.2.1 in the example), so that it can
   make routing decisions according to the port number.  On the other
   hand, B receives IPv4 packets destined to the public IPv4 address
   only via the established tunnel with A. In other words, B uses the
   public IPv4 address just for translation purposes, but it is not used
   to make routing decisions.  This allows us to keep the routing logic
   at B as simple as described above, while enabling seamless
   communication between A+P devices sharing the same public IPv4
   address.



Bush                      Expires July 9, 2011                 [Page 13]

Internet-Draft          A+P Addressing Extension            January 2011


              private    +-----+          +-----+     public
              address ---|  B  |==========|  A  |---  Internet
              realm 1    +-----+          +-----+
                                            |
              private    +-----+            |
              address ---|  C  |============/
              realm 2    +-----+

                         Address space realm of A:
                         public IPv4 address = 192.0.2.1
                         port range = 0-65535

                         Address space realm of B:
                         public IPv4 address = 192.0.2.1
                         port range = 2560-3071

                         Address space realm of C:
                         public IPv4 address = 192.0.2.1
                         port range = 0-2559


                             Hierarchical A+P

                                 Figure 4

   Consider the example shown in Figure 4.  Here both B and C use the
   encaps/decaps function to establish a tunnel with A, and they are
   assigned the same public IPv4 address with different, non-overlapping
   port-ranges.  Assume that a host in B's private realm sends a packet
   destined to address 192.0.2.1 and port 2000, and that B has been
   instructed to NAT all packets destined to 192.0.2.1.  Under these
   assumptions, B receives the packet and NATs it using its own public
   IPv4 address (192.0.2.1) and a port selected from its configured
   port-range (e.g., 3000).  B then tunnels the translated packet to A.
   When A receives the packet via the tunnel, it looks at the
   destination address and port, recognizes C's delegated range, and
   then tunnels the packet to C. Observe that, apart from stripping the
   tunnel header, A handles the packet as if it came from the public
   Internet.  When C receives the packet, it NATs the destination
   address into one address chosen from its private address realm, while
   keeping the source address (192.0.2.1) and port (3000) untranslated.
   Return traffic is handled the same way.  Such a mechanism allows
   hosts behind A+P devices to communicate seamlessly even when they
   share the same public IPv4 address.

   Please refer to Section 4 for a discussion of an alternative A+P
   mechanism that does not incur in path stretches penalties for intra-
   domain communication.



Bush                      Expires July 9, 2011                 [Page 14]

Internet-Draft          A+P Addressing Extension            January 2011


3.3.3.  Reasons for Allowing Multiple A+P Gateways

   Since each device in an A+P subsystem provides the encaps/decaps
   function, new devices can establish tunnels and become in turn part
   of an A+P subsystem.  As noted above, being part of an A+P subsystem
   implies the capability of talking to the external address realm
   without any translation.  In particular, as described in the previous
   section, a device X in an A+P subsystem can be reached from the
   external domain by simply using the public IPv4 address and a port
   which has been delegated to X. Figure 5 shows an example where three
   devices are connected in a chain.  In other words, A+P signaling can
   be used to extend end-to-end connectivity to the devices which are in
   an A+P subsystem.  This allows A+P-aware applications (or OSes)
   running on end hosts to enter an A+P subsystem and exploit
   untranslated connectivity.

   There are two modes for end-hosts to gain fine-grained control of
   end-to-end connectivity.  The first is where actual end-hosts perform
   the NAT function and the encaps/decaps function which is required to
   join the A+P subsystem.  This option works in a similar way to the
   NAT-in-the-host trick employed by virtualization software such as
   VMware, where the guest operating system is connected via a NAT to
   the host operating system.  The second mode is applications which
   autonomously ask for an A+P address and use it to join the A+P
   subsystem.  This capability is necessary for some applications that
   require end-to-end connectivity (e.g., applications that need to be
   contacted from outside).


               +---------+      +---------+      +---------+
     internal  | gateway |      | gateway |      | gateway |  external
     realm   --|    1    |======|    2    |======|    3    |-- realm
               +---------+      +---------+      +---------+


                  An A+P subsystem with multiple devices

                                 Figure 5

   Whatever the reasons might be, the Internet was built on a paradigm
   that end-to-end connectivity is important.  A+P makes this still
   possible in a time where address shortage forces ISPs to use NATs at
   various levels.  In such sense, A+P can be regarded as a way to
   bypass NATs.







Bush                      Expires July 9, 2011                 [Page 15]

Internet-Draft          A+P Addressing Extension            January 2011


              +---+          (customer2)
              |A+P|-.         +---+
              +---+  \     NAT|A+P|-.
                      \       +---+ |
                       \            |       forward if in-range
              +---+     \+---+    +---+    /
              |A+P|------|A+P|----|A+P|----
              +---+     /+---+    +---+    \
                       /                    NAT if necessary
                      / (cust1)   (prov.    (e.g., provider NAT)
              +---+  /            router)
              |A+P|-'
              +---+


                          A complex A+P subsystem

                                 Figure 6

   Figure 6 depicts a complex scenario, where the A+P subsystem is
   composed by multiple devices organized in a hierarchy.  Each A+P
   gateway decapsulates the packet and then re-encapsulates it again to
   the next tunnel.

   A packet can either be NATed when it enters the A+P subsystem, or at
   intermediate devices, or when it exits the A+P subsystem.  This could
   be for example a gateway installed within the provider's network,
   together with a LSN.  Then each customer operates its own CPE.
   However, behind the CPE applications might also be A+P-aware and run
   their own A+P-gateways, which enables them to have end-to-end
   connectivity.

   One limitation applies, if "delayed translation" is used (e.g.,
   translation at the LSN instead of the CPE).  If devices using
   "delayed translation" want to talk to each other they SHOULD use A+P
   addresses or out-of-band addressing.















Bush                      Expires July 9, 2011                 [Page 16]

Internet-Draft          A+P Addressing Extension            January 2011


3.3.4.  Overall A+P Architecture


                           A+P architecture

         IPv4         Full-A+P          AFTR             CGN
          |              |               |                |
   <-- Full IPv4 ---- Port range ---- Port range  ---- Provider --->
       allocated      & dynamic         & LSN          NAT ONLY
                      allocation      (NAT on CPE      (No mechanism)
       (no NAT)      (NAT on CPE)     and on LSN)      for customer to
                                                       bypass CGN)


                    Figure 7: A+P overall architecture

   The A+P architecture defines various deployment options within an
   ISP.  Figure 7 shows the spectrum of deployment options.  On the far
   left is the common deployment method for broadband subscribers today,
   an IPv4 address unrestricted with full port-range.  Full-A+P refers
   to a port-range allocation from the ISP.  The customer must operate
   an A+P-aware CPE device and no NATing functionality is provided by
   the ISP.  AFTR, such as DS-Lite [I-D.ietf-softwire-dual-stack-lite],
   is a hybrid.  There is NAT present in the core (in this document
   referred to as LSN), but the user has the option to "bypass" that NAT
   in one form or an other, for example via A+P, NAT-PMP, etc...
   Finally, a service provider which only deploys CGN, will place a NAT
   in the providers core and does not allow the customer to "bypass" the
   translation process or modify ALGs on the NAT.  The customer is
   provider-locked.  Notice that all options (besides full IPv4) require
   some form of tunneling mechanism (e.g., 4in6) and a signaling
   mechanism (see Section 3.3.1).


4.  Stateless A+P Mapping Function

4.1.  Stateless A+P Mapping gateway (SMAP) Function description

   SMAP stands for Stateless A+P Mapping.  This function is responsible
   to encapsulate (Resp., decapsulate), in a stateless scheme, IPv4
   packets in (Resp. from) IPv6 ones.  A SMAP function may be hosted in
   a PRR, end-user device, etc.

   Stateless A+P Mapping gateway (SMAP) consists in two basic functions
   as described in Figure 8.

   1.  SMAP encapsulates an IPv4 packet, destined to a shared IPv4
   address, in IPv6 one.  The IPv6 source address is constructed using



Bush                      Expires July 9, 2011                 [Page 17]

Internet-Draft          A+P Addressing Extension            January 2011


   an IPv4-Embedded IPv6 address [I-D.ietf-behave-address-format] from
   the IPv4 source address and port number plus the IPv6 prefix which
   has been provisioned to the node performing the SMAP function.  The
   destination IPv6 address is constructed using the shared IPv4
   destination address and port number plus the IPv6 prefix which has
   been provisioned to the SMAP function and which is dedicated to IPv4
   destination addresses.

   2.  SMAP extracts IPv4 incoming packets from IPv6 incoming ones which
   have IPv6 source addresses belonging to the prefix of the node
   performing the SMAP function.  Extracted IPv4 packets are then
   forwarded to the point identified by the IPv4 destination address and
   port number.


                           +-------------------+
                           |                   |----IPv6---\
               ----IPv4---\|                   |----IPv4---\\
               -----------/|                   |-----------//
                           |                   |-----------/
                           |       SMAP        |
                           |                   | /--IPv6-----
               /---IPv4----|                   |//---IPv4----
               \-----------|                   |\\-----------
                           |                   | \-----------
                           +-------------------+



             Figure 8: Stateless A+P Mapping Gateway Function

   A SMAP-enabled node will perform the stateless 6/4 mapping function
   for all public shared IPv4 addresses for which it was designated as a
   stateless 6/4 mapping gateway.

   To perform stateless 6/4 mapping function a SMAP gateway must:

   o be provided with an IPv6 prefix (i.e., Pref6).  The SMAP gateway
   uses this prefix to construct IPv6 source addresses for all IPv4
   shared addresses for which it was designated as a SMAP gateway.  The
   IPv6 prefix may be provisioned statically or dynamically (e.g., DHCP)

   o be able to know the IPv6 prefix of the node serving as another SMAP
   gateway for IPv4 destination addresses.  This prefix may be known in
   various ways:

   * Default or Well Known Prefix (i.e., 64:ff9b::/96) which was
   provisioned statically or dynamically;



Bush                      Expires July 9, 2011                 [Page 18]

Internet-Draft          A+P Addressing Extension            January 2011


   * Retained at the reception of incoming IPv4-in-IPv6 encapsulated
   packets;

   * Discovered at the communication starting thanks to mechanisms as
   DNS resolution for example.

   When the SMAP-enabled node receives IPv4 packets with IPv4 source
   addresses for which it was not designated as a SMAP gateway, it will
   not perform stateless 6/4 mapping function for those packets.  Those
   packets will be handled in a classical way (i.e., forwarded, dropped
   or locally processed).

   When the SMAP-enabled node receives IPv6 packets with IPv6 addresses
   which do not match with its IPv6 prefix, it will not perform the
   stateless 6/4 mapping function for those packets.  Those packets will
   be handled in a classical way (i.e., forwarded, dropped or locally
   processed).

4.2.  Implementation Mode

   In this configuration, the node A performs the stateless mapping
   function on the received IPv4 traffic (encapsulated in IPv6 packets)
   before forwarding to the node B. The node B performs the stateless
   mapping function on the received IPv6 traffics (extracting IPv4
   packets) before forwarding the IPv4 traffic to the destination
   identified by the IPv4 destination address and port number.  In the
   opposite direction and as previously, the node B performs the
   stateless mapping function on the received IPv4 traffics
   (encapsulating in IPv6 packets) before forwarding to the node A. The
   node A performs the stateless mapping function on the received IPv6
   traffic (extracting IPv4 packets) before forwarding the IPv4 traffic
   to the point identified by the IPv4 destination address and port
   number.  In this case, only IPv6 traffic is managed in the network
   segment between the nodes A and B.

















Bush                      Expires July 9, 2011                 [Page 19]

Internet-Draft          A+P Addressing Extension            January 2011


                       +------+             +------+
                       |      |----IPv6---\ |      |
           ----IPv4---\|      |----IPv4---\\|      |----IPv4---\
           -----------/|      |-----------//|      |-----------/
                       |      |-----------/ |      |
                       | SMAP |             | SMAP |
                       |      | /----IPv6---|      |
           /---IPv4----|      |//---IPv4----|      |/---IPv4----
           \-----------|      |\\-----------|      |\-----------
                       |      | \-----------|      |
                       +------+             +------+
                        node A               node B


                                 Figure 9

   Several deployment scenarios of the SMAP function may be envisaged in
   the context of Port Range based solutions:

   o A SMAP function is embedded in a port-restricted device.  Other
   SMAP-enabled nodes are deployed in the boundaries between IPv6-
   enabled realms and IPv4 ones.  This scenario may be particularly
   deployed for intra-domain communications so as to interconnect
   heterogeneous realms (i.e., IPv6/IPv4) within the same AS.

   o A SMAP function is embedded in a port-restricted device.  Other
   SMAP-enabled nodes are deployed in the interconnection segment (with
   adjacent IPv4-only ones) of a given AS.  This deployment scenario is
   more suitable for service providers targeting the deployment of IPv6
   since it eases the migration to full IPv6.  Core nodes are not
   required to activate anymore both IPv4 and IPv6 transfer
   capabilities.

   Other considerations regarding the interconnection of SMAP-enabled
   domains should be elaborated.  The following provides a non
   exhaustive list of interconnection schemes.

   o The interconnection of two domains implementing the SMAP function
   may be deployed via IPv4 Internet (Figure 10): This means that IPv4
   packets encapsulated in IPv6 one are transferred using IPv6 until
   reaching the first SMAP-node.  Then these packets are de-
   encapsulated and are forwarded using IPv4 transfer capabilities.  A
   remote SMAP-enabled node will receive those packets and proceeds to
   an IPv4-in-IPv6 encapsulation.  These packets are then routed
   normally until reaching the port-restricted devices which de-
   encapsulates the packets.





Bush                      Expires July 9, 2011                 [Page 20]

Internet-Draft          A+P Addressing Extension            January 2011


   +------+          +------+   +--------+   +------+           +------+
   |      |--IPv6--\ |      |   |        |   |      |---IPv6--\ |      |
   |      |--IPv4--\\|      |---|-IPv4---|--\|      |---IPv4--\\|      |
   |      |--------//|      |---|--------|--/|      |---------//|      |
   |      |--------/ |      |   |Internet|   |      |---------/ |      |
   | SMAP |          | SMAP |   |  IPv4  |   | SMAP |           | SMAP |
   |      | /--IPv6--|      |   |        |   |      | /---IPv6--|      |
   |      |//--IPv4--|      |/--|-IPv4---|---|      |//--IPv4---|      |
   |      |\\--------|      |\--|--------|---|      |\\---------|      |
   |      | \--------|      |   |        |   |      | \---------|      |
   +------+          +------+   +--------+   +------+           +------+
    Source           node A                  node B          Destination



                   Figure 10: Interconnection Scenario 1

   o A second scheme is to interconnect two realms implementing the SMAP
   function using IPv6 (Figure 11).  An IPv6 prefix (i.e., Pref6)
   assigned by IANA is used for this service.  If appropriate routing
   configuration have been enforced, then the IPv6 encapsulated packets
   will be routed until the final destination.  In order to implement
   this model, IPv4-inferred IPv6 prefixes are required to be injected
   in the IPv6 inter-domain routing tables.


        +------+             +------------+              +------+
        |      |             |            |              |      |
        |      |----IPv6-----|----IPv6----|----IPv6----\ |      |
        |      |----IPv4-----|------------|----IPv4----\\|      |
        |      |-------------|------------|------------//|      |
        |      |-------------|------------|------------/ |      |
        | SMAP |             | Internet v6|              | SMAP |
        |      | /-----IPv6--|------------|-----IPv6-----|      |
        |      |//---IPv4----|------------|-------IPv4---|      |
        |      |\\-----------|------------|--------------|      |
        |      | \-----------|------------|--------------|      |
        |      |             |            |              |      |
        +------+             +------------+              +------+
         Source                                            Destination


                   Figure 11: Interconnection Scenario 2








Bush                      Expires July 9, 2011                 [Page 21]

Internet-Draft          A+P Addressing Extension            January 2011


4.3.  Towards IPv6-only Networks

   The deployment of SMAP function allows for smooth migration of
   networks to IPv6-only scheme while maintaining the delivery of IPv4
   connectivity services to customers.  The delivery of IPv4
   connectivity services over an IPv6-only network does not require any
   stateful function to be deployed on the core network.  Owing to this
   A+P mode, both the IPv4 service continuity and migration to an IPv6-
   only deployment model are facilitated.

4.4.  PRR: On Stateless and Binding Table Modes

   o Stateless Mode

   Complete stateless mapping implies that the IPv4 address and the
   significant bits coding the port range are reflected inside the IPv6
   prefix assigned to the port-restricted device.  Two alternatives are
   offered when such a stateless mapping is to be enabled:

   - either using the IPv6 prefix already used for native IPv6 traffic,

   - or provide two prefixes to the port-restricted device: one for the
   native IPv6 traffic and one for the IPv4 traffic.

   Note that:

   - Providing two IPv6 prefixes has the advantages of allowing a /64
   prefix for the port-restricted device along with another prefix
   (e.g., a /56 or /64) for native IPv6 traffic.  This alternative
   spares the service provider to relate the native IPv6 traffic
   addressing plan to the IPv4 addressing plan.  The drawback is the
   burden to allocate two prefixes to each port-restricted device and to
   route them.  In addition, an address selection issue may be
   encountered.

   - Providing one prefix for both needs (e.g., a /56 or a /64) spares
   the service provider to handle two types of IPv6 prefix for the port-
   restricted device and in routing tables.  But the drawback is that it
   somewhat links strongly the IPv4 addressing plan to the allocated
   IPv6 prefixes.

   o Binding Table Mode

   Another alternative is to assign a "normal" IPv6 prefix to the port-
   restricted device and to use a binding table, which can be hosted by
   a service node, to correlate the (shared IPv4 address, Port Range)
   with an IPv6 address part of the assigned IPv6 prefix.  For
   scalability reasons, this table should be instantiated within PRR-



Bush                      Expires July 9, 2011                 [Page 22]

Internet-Draft          A+P Addressing Extension            January 2011


   enabled nodes which are close to the port-restricted devices.  The
   number of required entries if hosted at interconnection segment would
   be equal to the amount of subscribed users (one per port-restricted
   device).

4.5.  General recommendations on SMAP

   If Stateless A+P Mapping (SMAP) type of implementation is deployed
   over intermediate IPv6-ONLY-capable devices, it is recommended that
   default-routes are configured and IPv4 routing table is not "leaked"
   into IPv6 routing table in terms to have reachability for the packets
   going towards the internet.


5.  Deployment Scenarios

5.1.  A+P Deployment Models

5.1.1.  A+P for Broadband Providers

   Some large broadband providers will not have enough public IPv4
   address space to provide every customer with a single IP.  The
   natural solution is sharing a single IP address among many customers.
   Multiplexing customers is usually accomplished by allocating
   different port numbers to different customers somewhere within the
   network of the provider.

   It is expected that, when the provider wishes to enable A+P for a
   customer or a range of customers, the CPE can be upgraded or replaced
   to support A+P encaps/decaps functionality.  Ideally the CPE also
   provides NATing functionality.  Further, it is expected that at least
   another component in the ISP network provides the corresponding A+P
   functionality, and hence is able to establish an A+P subsystem with
   the CPE.  This device is referred to as A+P router or port-range
   router (PRR), and could be located close to PE routers.  The core of
   the network MUST support the tunneling protocol (which SHOULD be
   IPv6, as per Constraint 7) but MAY be another tunneling technology
   when necessary.  In addition, we do not wish to restrict any
   initiative of customers who might want to run an A+P-capable network
   on or behind their CPE.  To satisfy both Constraints 1 and 2
   unmodified legacy hosts should keep working seamlessly, while
   upgraded/new end-systems should be given the opportunity to exploit
   enhanced features.

5.1.2.  A+P for Mobile Providers

   In the case of mobile service provider the situation is slightly
   different.  The A+P border is assumed to be the gateway (e.g., GGSN/



Bush                      Expires July 9, 2011                 [Page 23]

Internet-Draft          A+P Addressing Extension            January 2011


   PDN GW of 3GPP, or ASN GW of WiMAX).  The need to extend the address
   is not within the provider network, but on the edge between the
   mobile phone devices and the gateway.  While desirable, IPv6
   connectivity may or may not be provided.

   For mobile providers we use the following terms and assumptions:

   1.  Provider Network (PN)

   2.  Gateway (GW)

   3.  Mobile Phone device (phone)

   4.  Devices behind phone, e.g., laptop computer connecting via phone
       to Internet.

   We expect that the gateway has a pool of IPv4 addresses and is always
   in the data-path of the packets.  Transport between the gateway and
   phone devices is assumed to be an end-to-end layer-2 tunnel.  We
   assume that phone as well as gateway can be upgraded to support A+P.
   However, some applications running on the phone or devices behind the
   phone (such as laptop computers connecting via the phone), are not
   expected to be upgraded.  Again, while we do not expect that devices
   behind the phone will be A+P aware/upgraded we also do not want to
   hinder their evolution.  In this sense the mobile phone would be
   comparable to the CPE in the broadband provider case; the gateway to
   the PRR/LSN box in the network of the broadband provider.

5.1.3.  A+P from the Provider Network Perspective

   ISPs suffering from IPv4 address space exhaustion are interested in
   achieving a high address space compression ratio.  In this respect,
   an A+P subsystem allows much more flexibility than traditional NATs:
   the NAT can be placed at the customer, and/or in the provider
   network.  In addition hosts or applications can request ports and
   thus have untranslated end-to-end connectivity.















Bush                      Expires July 9, 2011                 [Page 24]

Internet-Draft          A+P Addressing Extension            January 2011


                   +---------------------------+
        private    | +------+  A+P-in  +-----+ |   dual-stacked
       (RFC1918) --|-| CPE  |==-IPv6-==| PRR |-|-- network
         space     | +------+  tunnel  +-----+ |   (public addresses)
                   |    ^              +-----+ |
                   |    |  IPv6-only   | LSN | |
                   |    |   network    +-----+ |
                   +----+----------------- ^ --+
                        |                  |
                   on customer        within provider
              premises and control      network


                      A simple A+P subsystem example

                                 Figure 12

   Consider the deployment scenario in Figure 12, where an A+P subsystem
   is formed by the CPE and a PRR within the ISP core network,
   preferably close to the customer edge, and represents the border from
   where on packets are forwarded based on address and port.  The
   provider MAY deploy a LSN co-located with the PRR to handle packets
   that have not been translated by the CPE.  In such a configuration,
   the ISP allows the customer to freely decide whether the translation
   is done at the CPE or at the LSN.  In order to establish the A+P
   subsystem, the CPE will be configured automatically (e.g. via a
   signaling protocol, that conforms to the requirements stated above).

   Note that the CPE in the example above is only provisioned with an
   IPv6 address on the external interface.





















Bush                      Expires July 9, 2011                 [Page 25]

Internet-Draft          A+P Addressing Extension            January 2011


    +------------ IPv6-only transport ------------+
    | +---------------+ |              |          |
    | |A+P-application| |  +--------+  |  +-----+ |   dual-stacked
    | | on end-host   |=|==| CPE w/ |==|==| PRR |-|-- network
    | +---------------+ |  +--------+  |  +-----+ |   (public addresses)
    +---------------+   |  +--------+  |  +-----+ |
      private IPv4 <-*--+->| NAT    |  |  | LSN | |
      address space   \ |  +--------+  |  +-----+ |
      for legacy       +|--------------|----------+
        hosts           |              |
                        |              |
      end-host with     |  CPE device  |  provider
        upgraded        |  on customer |  network
       application      |   premises   |


         An extended A+P subsystem with end-host running A+P-aware
                               applications

                                 Figure 13

   Figure 13 shows an example of how an upgraded application running on
   a legacy end-host can connect to another host in the public realm.
   The legacy host is provisioned with a private IPv4 address allocated
   by the CPE.  Any packet sent from the legacy host will be NATed
   either at the CPE (if configured to do so), or at the LSN (if
   available).

   An A+P-aware application running on the end-host MAY use the
   signaling described in Section 3.3.1 to connect to the A+P-subsystem.
   In this case, the application will be delegated some space in the A+P
   address realm, and will be able to contact the public realm (i.e.,
   the public Internet) without the need for translation.

   Note that part of A+P signaling is that the NATs are optional.
   However, if neither the CPE nor the PRR provides NATing
   functionality, then it will not be possible to connect legacy end-
   hosts.

   To enable packet forwarding with A+P, the ISP MUST install at its A+P
   border a PRR which encaps/decaps packets.  However, to achieve a
   higher address space compression ratio and/or to support CPEs without
   NATing functionality, the ISP MAY decide to provide an LSN as well.
   If no LSN is installed in some part of the ISP's topology, all CPE in
   that part of the topology MUST support NAT functionality.  For
   reasons of scalability, it is assumed that the PRR is located within
   the access-portion of the network.  The CPE would be configured
   automatically (e.g. via an extended DHCP or NAT-PMP, which has the



Bush                      Expires July 9, 2011                 [Page 26]

Internet-Draft          A+P Addressing Extension            January 2011


   signaling requirements stated above) with the address of the PRR, and
   if a LSN is being provided or not.  Figure 12 illustrates a possible
   deployment scenario.

5.2.  Dynamic Allocation of Port Ranges

   Allocating a fixed number of ports to all CPEs may lead to exhaustion
   of ports for high usage customers.  This is a perfect recipe for
   upsetting more demanding customers.  On the other hand, allocating to
   all customers ports sufficient to match the needs of peak users will
   not be very efficient.  A mechanism for dynamic allocation of port
   ranges allows the ISP to achieve two goals; a more efficient
   compression ratio of number of customers on one IPv4 address and, on
   the other hand, not limiting the more demanding customers'
   communication.

   Additional allocation of ports, or port ranges may be made after an
   initial static allocation of ports.

   The mechanism would prefer allocations of port ranges from the same
   IP address as the initial allocation.  If it is not possible to
   allocate an additional port range from the same IP, then mechanism
   can allocate a port range from another IP within the same subnet.
   With every additional port range allocation, the PRR updates its
   routing table.  The mechanism for allocating additional port ranges
   may be part of normal signaling that is used to authenticate CPE to
   ISP.

   The ISP controls the dynamic allocation of port ranges by the PRR by
   setting the initial allocation size and maximum number of allocations
   per CPE, or the maximum allocations per subscription, depending on
   subscription level.  There is a general observation that the more
   demanding customer uses around 1024 ports when heavily communicating.
   So, for example, a first suggestion might be 128 ports initially and
   then dynamic allocations of ranges of 128 ports up to 511 more
   allocations maximum.  A configured maximum number of allocations
   could be used to prevent one customer acting in destructive manner
   should they become infected.  The maximum number of allocations might
   also be more finely grained, with parameters of how many allocations
   a user may request per some time frame.  If this is used, evasive
   applications may need to be limited in their bad behavior, for
   example one additional allocation per minute would considerably slow
   a port request storm.

   There is likely no minimum request size.  This is because A+P-aware
   applications running on end-hosts MAY request a single port (or a few
   ports) for the CPE to be contacted on (e.g., VoIP clients register a
   public IP and a single delegated port from the CPE, and accept



Bush                      Expires July 9, 2011                 [Page 27]

Internet-Draft          A+P Addressing Extension            January 2011


   incoming calls on that port).  The implementation on the CPE or PRR
   will dictate how to handle such requests for smaller blocks: For
   example, half of available blocks might be used for "block-
   allocations", 1/6 for single port requests, and the rest for NATing.

   Another possible mechanism to allocate additional ports is UPnP/
   NAT-PMP (as defined in Section 3.3.1), if applications behind CPE
   support it.  In case of the LSN implementation (DS-Lite), as
   described in the A+P overall architecture section, signaling packets
   are simply forwarded by the CPE to the LSN and back to the host
   running the application which requested the ports, and PRR allocates
   requested port to appropriate CPE.  The same behavior may be chosen
   with AFTR, if requested ports are outside of static initial port
   allocation.  If a full A+P implementation is selected, than UPnPv2/
   NAT-PMP packets are accepted by the CPE, processed, and the requested
   port number is communicated through normal signaling mechanism
   between CPE and PRR tunnel endpoints (PCP).

5.3.  Example of A+P-forwarded Packets

   This section provides a detailed example of A+P setup, configuration,
   and packet flow from an end-host connected to A+P Service Provider to
   any host in the IPv4 Internet, and how the return packets flow back.
   The following example discusses an A+P-unaware end-host, where the
   NATing is done at the CPE.  Figure 14 illustrates how the CPE
   receives an IPv4 packet from the end-user device.  We first describe
   the case where the CPE has been configured to provide the NAT
   functionality (e.g., by the customer through interaction with a
   website, or automatic signaling).  In the following, we call a packet
   which is translated at the CPE an A+P-forwarded packet, an analogy
   with the port-forwarding function employed in today's CPEs.  Upon
   receiving a packet from the internal interface, the CPE translates,
   encapsulates and forwards it to the PRR.  The NAT on the CPE is
   assumed to have a default route to the public realm through its
   tunnel interface.

   When the PRR receives the A+P-forwarded packet, it de-capsulates the
   inner IPv4 packet and checks the source address.  If the source
   address does match the range assigned to A+P enabled CPEs, then the
   PRR simply forwards the decapsulated packet onward.  This is always
   the case for A+P-forwarded packets.  Otherwise, the PRR assumes that
   the packet is not A+P-forwarded, and passes it to the LSN function,
   which in-turn translates and forward the packet based on the
   destination address.  Figure 14 shows the packet flow for an outgoing
   A+P-forwarded packet.






Bush                      Expires July 9, 2011                 [Page 28]

Internet-Draft          A+P Addressing Extension            January 2011


                   +-----------+
                   |    Host   |
                   +-----+-----+
                      |  |  198.51.100.2
      IPv4 datagram 1 |  |
                      |  |
                      v  |  198.51.100.1
               +---------|---------+
               |CPE      |         |
               +--------|||--------+
                      | |||     2001:db8::2
                      | ||| 192.0.2.3 (100-200)
       IPv6 datagram 2| |||
                      | |||<-IPv4-in-IPv6
                      | |||
                 -----|-|||-------
               /      | |||        \
              |  ISP access network |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      v |||     2001:db8::1
               +--------|||--------+
               |PRR     |||        |
               +---------|---------+
                      |  |  192.0.2.1
      IPv4 datagram 3 |  |
                 -----|--|--------
               /      |  |         \
              |   ISP network /     |
               \      Internet     /
                 -----|--|--------
                      |  |
                      v  | 203.0.113.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+


          Figure 14: Forwarding of Outgoing A+P-forwarded Packets











Bush                      Expires July 9, 2011                 [Page 29]

Internet-Draft          A+P Addressing Extension            January 2011


     +-----------------+--------------+-----------------------------+
     |        Datagram | Header field | Contents                    |
     +-----------------+--------------+-----------------------------+
     | IPv4 datagram 1 |     IPv4 Dst | 203.0.113.1                 |
     |                 |     IPv4 Src | 198.51.100.2                |
     |                 |      TCP Dst | 80                          |
     |                 |      TCP Src | 8000                        |
     | --------------- | ------------ | --------------------------- |
     | IPv6 Datagram 2 |     IPv6 Dst | 2001:db8::1                 |
     |                 |     IPv6 Src | 2001:db8::2                 |
     |                 |     IPv4 Dst | 203.0.113.1                 |
     |                 |     IPv4 Src | 192.0.2.3                   |
     |                 |      TCP Dst | 80                          |
     |                 |      TCP Src | 100                         |
     | --------------- | ------------ | --------------------------- |
     | IPv4 datagram 3 |     IPv4 Dst | 203.0.113.1                 |
     |                 |     IPv4 Src | 192.0.2.3                   |
     |                 |      TCP Dst | 80                          |
     |                 |      TCP Src | 100                         |
     +-----------------+--------------+-----------------------------+

                         Datagram header contents

   An incoming packet undergoes the reverse process.  When the PRR
   receives an IPv4 packet on an external interface, it first checks
   whether the destination address falls within the A+P CPE delegated
   range or not.  If the address space was delegated, then PRR
   encapsulates the incoming packet and forwards it through the
   appropriate tunnel for that IP/port range.  If the address space was
   not-delegated the packet would be handed to the LSN to check if a
   mapping is available.

   Figure 15 shows how an incoming packet is forwarded, under the
   assumption that the port number matches the port range which was
   delegated to the CPE.
















Bush                      Expires July 9, 2011                 [Page 30]

Internet-Draft          A+P Addressing Extension            January 2011


                   +-----------+
                   |    Host   |
                   +-----+-----+
                      ^  |  198.51.100.2
      IPv4 datagram 3 |  |
                      |  |
                      |  |  198.51.100.1
               +---------|---------+
               |CPE      |         |
               +--------|||--------+
                      ^ |||     2001:db8::2
                      | ||| 192.0.2.3 (100-200)
       IPv6 datagram 2| |||
                      | |||<-IPv4-in-IPv6
                      | |||
                 -----|-|||-------
               /      | |||        \
              | ISP access network  |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      | |||     2001:db8::1
               +--------|||--------+
               |PRR     |||        |
               +---------|---------+
                      ^  |  192.0.2.1
      IPv4 datagram 1 |  |
                 -----|--|--------
               /      |  |         \
              |  ISP network /      |
               \      Internet     /
                 -----|--|--------
                      |  |
                      |  | 203.0.113.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

          Figure 15: Forwarding of Incoming A+P-forwarded Packets












Bush                      Expires July 9, 2011                 [Page 31]

Internet-Draft          A+P Addressing Extension            January 2011


     +-----------------+--------------+-----------------------------+
     |        Datagram | Header field | Contents                    |
     +-----------------+--------------+-----------------------------+
     | IPv4 datagram 1 |     IPv4 Dst | 198.51.100.3                |
     |                 |     IPv4 Src | 203.0.113.1                 |
     |                 |      TCP Dst | 100                         |
     |                 |      TCP Src | 80                          |
     | --------------- | ------------ | --------------------------- |
     | IPv6 Datagram 2 |     IPv6 Dst | 2001:db8::2                 |
     |                 |     IPv6 Src | 2001:db8::1                 |
     |                 |     IPv4 Dst | 198.51.100.3                |
     |                 |       IP Src | 203.0.113.1                 |
     |                 |      TCP Dst | 100                         |
     |                 |      TCP Src | 80                          |
     | --------------- | ------------ | --------------------------- |
     | IPv4 datagram 3 |     IPv4 Dst | 198.51.100.2                |
     |                 |     IPv4 Src | 203.0.113.1                 |
     |                 |      TCP Dst | 8000                        |
     |                 |      TCP Src | 80                          |
     +-----------------+--------------+-----------------------------+

                         Datagram header contents

   Note that datagram 1 travels untranslated up to the CPE, thus the
   customer has the same control over the translation as it has today
   where s/he has an home gateway with customizable port-forwarding.

5.3.1.  Forwarding of Standard Packets

   Packets for which the CPE does not have a corresponding port
   forwarding rule are tunneled to the PRR which provides the LSN
   function.  We underline that the LSN MUST NOT use the delegated space
   for NATting.  See [I-D.ietf-softwire-dual-stack-lite] for network
   diagrams which illustrate the packet flow in this case.

5.3.2.  Handling ICMP

   ICMP is problematic for all NATs, because it lacks port numbers.  A+P
   routing exacerbates the problem.

   Most ICMP messages fall into one of two categories: error reports, or
   ECHO/ECHO reply (commonly known as "ping").  For error reports, the
   offending packet header is embedded within the ICMP packet; NAT
   devices can then rewrite that portion and route the packet to the
   actual destination host.  This functionality will remain the same
   with A+P; however, the PRR will need to examine the embedded header
   to extract the port number, while the A+P gateway will do the
   necessary rewriting.



Bush                      Expires July 9, 2011                 [Page 32]

Internet-Draft          A+P Addressing Extension            January 2011


   ECHO and ECHO reply are more problematic.  For ECHO, the A+P gateway
   device must rewrite the "Identifier" and perhaps "Sequence Number"
   fields in the ICMP request, treating them as if they were port
   numbers.  This way, the PRR can build the correct A+P address for the
   returning ECHO replies, so they can be correctly routed back to the
   appropriate host in the same way as TCP/UDP packets.  Pings
   originated from the Public Realm (Internet) towards an A+P device are
   not supported.

5.3.3.  Fragmentation

   In order to deliver a fragmented IP packet to its final destination
   (among those having the same IP address), the PRR should activate a
   dedicated procedure similar to the one used by
   [I-D.ietf-behave-v6v4-xlate-stateful], section 3.5 in a sense that it
   should reassemble the fragments in order to look at the destination
   port number.

   Note that it is recommended to use a PMTUD path discovery mechanism
   (e.g., [RFC1191]).

   Security issues related to fragmentation are out of scope of this
   document.  For more details, refer to [RFC1858].

5.3.4.  Limitations of the A+P approach

   One limitation that A+P shares with any other IP address-sharing
   mechanism is the availability of well-known ports.  In fact, services
   run by customers that share the same IP address will be distinguished
   by the port number.  As a consequence, it will be impossible for two
   customers who share the same IP address to run services on the same
   port (e.g., port 80).  Unfortunately, working around this limitation
   usually implies application-specific hacks (e.g., HTTP and HTTPS
   redirection), discussion of which is out of the scope of this
   document.  Of course, a provider might charge more for giving a
   customer the well-known port range, 0..1024, thus allowing the
   customer to provide externally available services.  Many applications
   require the availability of well known ports.  However, those
   applications are not expected to work in A+P environment unless they
   can adapt to work with different ports.  However, such application do
   not work behind today's NATs either.

   Another problem which is common to all NATs is coexistence with
   IPsec.  In fact, a NAT which also translates port numbers prevents AH
   and ESP from functioning properly, both in tunnel and in transport
   mode.  In this respect, we stress that, since an A+P subsystem
   exhibits the same external behavior as a NAT, well-known workarounds
   (such as [RFC3715]) can be employed.



Bush                      Expires July 9, 2011                 [Page 33]

Internet-Draft          A+P Addressing Extension            January 2011


6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


7.  Security Considerations

   With CGN/LSNs, tracing hackers, spammers and other criminals will be
   difficult, requiring logging, recording, and storing of all
   connection based mapping information.  The need for storage implies a
   tradeoff.  On one hand, the LSNs can manage addresses and ports as
   dynamically as possible in order to maximize aggregation.  On the
   other hand, the more quickly the mapping between private and public
   space changes, the more information needs to be recorded.  This would
   not only cause concern for law enforcement services, but also for
   privacy advocates.

   A+P offers a better set of tradeoffs.  All that needs to be logged is
   the allocation of a range of port numbers to a customer.  By design,
   this will be done rarely, improving scalability.  If the NAT
   functionality is moved further up the tree, the logging requirement
   will be as well, increasing the load on one node, but giving it more
   resources to allocate to a busy customer, perhaps decreasing the
   frequency of allocation requests.

   The other extreme is A+P NAT on the customer premises.  Such a node
   would be no different than today's NAT boxes, which do no such
   logging.  We thus conclude that A+P is no worse than today's
   situation, while being considerably better than CGNs.


8.  Authors

   This document has 9 primary authors, which is not allowed in the
   header of Internet-Drafts.  This is the list of actual authors of
   this document.

      Gabor Bajko
      Nokia
      Email: gabor(dot)bajko(at)nokia(dot)com

      Mohamed Boucadair
      France Telecom
      3, Av Francois Chateaux
      Rennes  35000



Bush                      Expires July 9, 2011                 [Page 34]

Internet-Draft          A+P Addressing Extension            January 2011


      France
      Email: mohamed.boucadair@orange-ftgroup.com

      Steven M. Bellovin
      Columbia University
      1214 Amsterdam Avenue
      MC 0401
      New York, NY  10027
      US
      Phone: +1 212 939 7149
      Email: bellovin@acm.org

      Randy Bush
      Internet Initiative Japan
      5147 Crystal Springs
      Bainbridge Island, Washington  98110
      US
      Phone: +1 206 780 0431 x1
      Email: randy@psg.com

      Luca Cittadini
      Universita' Roma Tre
      via della Vasca Navale, 79
      Rome,   00146
      Italy
      Phone: +39 06 5733 3215
      Email: luca.cittadini@gmail.com

      Alain Durand
      Juniper Networks
      1194 North Mathilda Avenue
      Sunnyvale, CA  94089-1206
      USA
      Email: adurand@juniper.net

      Olaf Maennel
      Loughborough University
      Department of Computer Science - N.2.03
      Loughborough
      United Kindom
      Phone: +44 115 714 0042
      Email: o@maennel.net

      Reinaldo Penno
      Juniper Networks
      1194 North Mathilda Avenue
      Sunnyvale, California  94089
      USA



Bush                      Expires July 9, 2011                 [Page 35]

Internet-Draft          A+P Addressing Extension            January 2011


      Email: rpenno@juniper.net

      Teemu Savolainen
      Nokia
      Hermiankatu 12 D
      TAMPERE, FI-33720
      Finland
      Email: teemu.savolainen@nokia.com

      Jan Zorz
      go6.si
      Frankovo naselje 165
      Skofja Loka,  4220
      Slovenia
      Phone: +38659042000
      Email: jan@go6.si



9.  Acknowledgments

   The authors wish to especially thank Remi Despres, and Pierre Levis
   for their help on the development of the A+P approach.  We also thank
   David Ward for review, constructive criticism, and interminable
   questions, and Dave Thaler for useful criticism on "stackable" A+P
   gateways.  We would also like to thank the following persons for
   their feedback on earlier versions of this work: Rob Austein, Gert
   Doering, Dino Farinacci, Russ Housley, and Ruediger Volk.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [BCP38]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, May 2000.

   [I-D.bajko-pripaddrassign]
              Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
              "Port Restricted IP Address Assignment",
              draft-bajko-pripaddrassign-01 (work in progress),
              March 2009.



Bush                      Expires July 9, 2011                 [Page 36]

Internet-Draft          A+P Addressing Extension            January 2011


   [I-D.boucadair-dhcpv6-shared-address-option]
              Boucadair, M., Levis, P., Grimault, J., Savolainen, T.,
              and G. Bajko, "Dynamic Host Configuration Protocol
              (DHCPv6) Options for Shared IP Addresses  Solutions",
              draft-boucadair-dhcpv6-shared-address-option-00 (work in
              progress), May 2009.

   [I-D.boucadair-pppext-portrange-option]
              Boucadair, M., Levis, P., Grimault, J., and A.
              Villefranque, "Port Range Configuration Options for PPP
              IPCP", draft-boucadair-pppext-portrange-option-01 (work in
              progress), July 2009.

   [I-D.ietf-behave-address-format]
              Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
              draft-ietf-behave-address-format-09 (work in progress),
              July 2010.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers",
              draft-ietf-behave-v6v4-xlate-stateful-12 (work in
              progress), July 2010.

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
              Y., and R. Bush, "Dual-stack lite broadband deployments
              post IPv4 exhaustion",
              draft-ietf-softwire-dual-stack-lite-01 (work in progress),
              July 2009.

   [I-D.wing-softwire-port-control-protocol]
              Wing, D., Penno, R., and M. Boucadair, "Port Control
              Protocol (PCP)",
              draft-wing-softwire-port-control-protocol-01 (work in
              progress), March 2010.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1858]  Ziemba, G., Reed, D., and P. Traina, "Security
              Considerations for IP Fragment Filtering", RFC 1858,
              October 1995.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",



Bush                      Expires July 9, 2011                 [Page 37]

Internet-Draft          A+P Addressing Extension            January 2011


              BCP 5, RFC 1918, February 1996.

   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
              (NAT) Compatibility Requirements", RFC 3715, March 2004.


Author's Address

   Randy Bush (editor)
   Internet Initiative Japan
   5147 Crystal Springs
   Bainbridge Island, Washington  98110
   US

   Phone: +1 206 780 0431 x1
   Email: randy@psg.com



































Bush                      Expires July 9, 2011                 [Page 38]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/