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

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

Network Working Group                                         O. Maennel
Internet-Draft                                          T-Labs/TU-Berlin
Intended status: Standards Track                                 R. Bush
Expires: August 4, 2009                        Internet Initiative Japan
                                                            L. Cittadini
                                                    Universita' Roma Tre
                                                             S. Bellovin
                                                     Columbia University
                                                        January 31, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF 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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 4, 2009.

Copyright Notice

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



Maennel, et al.          Expires August 4, 2009                 [Page 1]

Internet-Draft          A+P Addressing Extension            January 2009


   carefully, as they describe your rights and restrictions with respect
   to this document.

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 we run out 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 discusses the possibility address sharing by 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
   device, we propose to extended the address by "stealing" bits from
   the port number in the TCP/UDP header, leaving the applications a
   reduced range of ports.  This means assigning the same IP to
   different clients (e.g., CPE's, mobile phones), each with its 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.

   This document discusses overall constraints that apply to address
   sharing proposals.  [I-D.levis-behave-ipv4-shortage-framework] gives
   an overview over the solution space and questions that need to be
   addressed, while [I-D.durand-softwire-dual-stack-lite],
   [I-D.boucadair-port-range], [I-D.boucadair-dhc-port-range],
   [I-D.bajko-v6ops-port-restricted-ipaddr-assign], suggest various ways
   of overcoming the problems of shared addresses.

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
















Maennel, et al.          Expires August 4, 2009                 [Page 2]

Internet-Draft          A+P Addressing Extension            January 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Design Constraints and Assumptions . . . . . . . . . . . . . .  4
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Design constraints . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview of the A+P Solution . . . . . . . . . . . . . . . . .  6
     3.1.  Signaling  . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Address realm  . . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Reasons for allowing multiple A+P gateways . . . . . . . . 11
   4.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  A+P for Broadband Providers  . . . . . . . . . . . . . . . 13
     4.2.  A+P for Mobile Providers . . . . . . . . . . . . . . . . . 13
     4.3.  A+P from provider networks perspective . . . . . . . . . . 14
     4.4.  Example of A+P-forwarded packets . . . . . . . . . . . . . 16
     4.5.  Forwarding of standard packets . . . . . . . . . . . . . . 21
     4.6.  Handling ICMP  . . . . . . . . . . . . . . . . . . . . . . 21
     4.7.  Limitations of the A+P approach  . . . . . . . . . . . . . 22
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24


























Maennel, et al.          Expires August 4, 2009                 [Page 3]

Internet-Draft          A+P Addressing Extension            January 2009


1.  Introduction

   This document addresses the imminent IPv4 address space exhaustion.
   Very soon there will be not enough IPv4 space allocatable to
   customers of broadband or mobile providers, while IPv6 is not widely
   enough deployed to migrate to an IPv6-only world.  Many large
   Internet Service Providers (ISPs) face the problem that their
   networks' customer edges are so large that it will soon not be
   possible anymore to provide each customer with a single IPv4 address.
   Therefore ISPs have to devise something more ingenious.  Although
   undesirable, address sharing is inevitable.

   To allow end-to-end connectivity between IPv4 speaking applications
   we propose to "steal" some bits from the UDP/TCP header and use them
   for addressing devices.  Assuming we could limit the applications'
   port addressing to 8 (or 4) bits, we can increase the effective size
   of an IPv4 address by 8 (or 12) additional bits.  In this scenario,
   512 (or 4096) customers could be multiplexed on the same IPv4
   address, while allowing them a fixed range of 512 (or 16) ports.  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 translating (at least some
   ports of) an IP address.  With NAT this end-to-end connectivity is
   broken.  As long as the customer chooses to do this on his/her
   premises this is a choice that he/she takes, however this is not an
   option anymore in face of the looming IPv4 address exhaustion, where
   large-scale-NATs (LSNs) might be deployed outside of the control of
   the customer.

   It is further feared that various forms of NATs will be installed at
   various levels and places in the IPv4-Internet to achieve the
   necessary address compression.  To ensure that end-customers are not
   locked behind a walled-garden shrine without any control over the
   translation, this document defines A+P devices that can be chained
   behind each other.  The goal is to create a mechanism to "bypass" a
   NAT, and keep the control at the end-user.  By giving the customer
   control over which traffic is translated and which is unmodified it
   is possible to achieve a better address compression ratio, and at the
   same time keeping the customer in control of the translation process.
   For example certain applications, such as peer-to-peer or VoIP might
   require an in-bound port and untranslated end-to-end connectivity;
   while web-traffic could be perfectly fine behind a NAT.


2.  Design Constraints and Assumptions

   The problem of address space shortage is first felt by providers with
   a very large end-user customer base, such as broadband providers and



Maennel, et al.          Expires August 4, 2009                 [Page 4]

Internet-Draft          A+P Addressing Extension            January 2009


   mobile-service providers.  Though the cases and requirements are
   slightly different, they share many commonalities.  In the following
   we will develop a set of overall design constraints.

2.1.  Terminology

   Encaps/decaps functionality: describes the end-points of a tunnel.
   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.

   Network Address Translation (NAT) functionality: is performing any
   address or port translation, including application-level-gateways
   (ALGs).  The state that has to be kept to implement this
   functionality is the mapping for which external addresses and ports
   have been mapped to which internal addresses and ports.

   A+P address realm : a public routable IPv4 address that is port
   restricted (Address plus Port).  Forwarding of packets is done based
   on the IPv4 address and the TCP/UDP port numbers.  When this draft
   talks about "A+P packets" it is assumed that those packets pass
   untranslated.

   Private address space: IPv4 addresses that are not globally routed.
   Ideally they should be taken from [RFC1918] range.  However, this
   draft does not make such an assumption.  We regard as private address
   space any IPv4 address which needs to be NATed in order to gain
   global connectivity, irrespective of whether it falls in [RFC1918]
   space or not.

2.2.  Design constraints

   We regard several constraints as important for our design:

   1)      End-to-end is under customer control.  Customers shall have
           the possibility to send/receive packets unmodified and deploy
           new application protocols at will.  IPv4 address exhaustion
           is no clearance to break the Internet's end-to-end paradigm.

   2)      End-to-end transparency through multiple intermediate
           devices.  Multiple gateways should be able to operate in
           sequence along one data path without interfering with each
           other.




Maennel, et al.          Expires August 4, 2009                 [Page 5]

Internet-Draft          A+P Addressing Extension            January 2009


   3)      Incremental deployability and backward compatibility.  The
           approaches shall be transparent to unaware users.  Devices or
           existing applications shall be able to work without
           modification.  Emergence of new applications shall not be
           limited.

   4)      Automatic configuration/administration.  There should be no
           need for customers to call the ISP and tell them that they
           are operating their own A+P-gateway devices.  Customers/
           mobile phone users are NOT supposed to lookup assigned ports
           manually on websites and then configure them on devices or
           applications.

   5)      "Double-NAT" shall be avoided.  Based on Constraint 2
           multiple gateway devices might be present in a path, and once
           one has done some translation, those packets should not be
           re-translated.

   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 the lowest impact
           possible on the storage and 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.

   While we acknowledge that A+P works in an IPv4-only environment
   (e.g., [I-D.boucadair-port-range]) we strongly believe that IPv6 is
   the long-term solution to the problem, and that A+P should be
   considered only as an intermediate hack towards an IPv6-only world.
   We therefore assume in constraint 7 that the ISP has migrated to a
   dual-stack core and A+P can use IPv6 as a transport inside the
   network.  This ensures that A+P will not be an hindrance to the
   introduction of IPv6.

   Constraints 2 and 5 are 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.  Overview of the A+P Solution

   The core architectural elements of the A+P solution are two separated
   and independent functionalities: the NAT functionality and the
   encaps/decaps functionality.  The NAT functionality is similar to a
   NAT as we know it today: it performs a translation between two



Maennel, et al.          Expires August 4, 2009                 [Page 6]

Internet-Draft          A+P Addressing Extension            January 2009


   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 functionality, on the other hand, consists of the
   capability of establishing a tunnel with another endpoint providing
   the same functionality.  This implies that the two endpoints are
   involved in some signaling protocol to establish the tunnel (see
   Section 3.1).  Such a tunnel can be encapsulation in IPv6, a layer-2
   tunnel, or some other form of softwire.  Note that the presence of a
   tunnel allows for intermediate legacy devices between the two
   endpoints.

   Two or more devices which provide the encaps/decaps functionality and
   are linked by tunnels 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
   providing the encaps/decaps functionality.


                  +------------------------------------+
        internal  | +----------+  tunnel  +----------+ |    external
        address --|-| gateway  |==========| gateway  |-|--  address
         realm    | +----------+          +----------+ |     realm
                  +------------------------------------+
                              A+P subsystem


                          A simple A+P subsystem

                                 Figure 2



Maennel, et al.          Expires August 4, 2009                 [Page 7]

Internet-Draft          A+P Addressing Extension            January 2009


   Within an A+P subsystem, the external address realm is extended by
   "stealing" bits from the port number.  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
   external address 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.  On the other hand, packets that are originated from
   outside the A+P subsystem need to be translated, since they belong to
   different realms.  For this reason, one of the two edges of the A+P
   subsystem MUST provide the NAT functionality (or both).  It is up to
   the provider to trade-off the placement of the NAT functionality.
   Hence, the design of A+P is deliberately agnostic to where packets in
   transit will be translated, provided that the translation happens
   exactly once (Constraint 5).

3.1.  Signaling

   The following information needs to be available on all the gateways
   in the A+P subsystem.  While we certainly recommend a signaling
   protocol (e.g., [I-D.bajko-v6ops-port-restricted-ipaddr-assign]), for
   usability reasons, we acknowledge that other forms of provisioning
   may be deployed as well (e.g. signaling via documentation, manual
   provisioning, etc.):

   o  a set of public IPv4 addresses,

   o  for each IPv4 address a set of allocated port-ranges (port-set),

   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 functionality is provided by the gateway

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

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







Maennel, et al.          Expires August 4, 2009                 [Page 8]

Internet-Draft          A+P Addressing Extension            January 2009


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
   borrowing bits from the port number.  This address space may even be
   a single, port-restricted IPv4 address.  The gateway MAY use its
   managed A+P address space for several purposes:

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

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

   An A+P gateway ("A"), accepts incoming connections from other A+P
   gateways ("B").  Upon connection establishment (provided appropriate
   authentication), the encaps/decaps functionality is negotiated
   between A and B. In this sense device B would contact A and "ask" for
   delegation of an A+P address.  In particular, upon the establishment
   of the tunnel, A will inform B about its public IPv4 address, and
   will delegate a portion of its port-range to B.

   This could be implemented for example via a DHCP-similar solution.  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.

















Maennel, et al.          Expires August 4, 2009                 [Page 9]

Internet-Draft          A+P Addressing Extension            January 2009


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

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

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


                                 Figure 3

   Figure 3 illustrates a sample configuration.  Packet forwarding is
   assumed in the following way: 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 device B. Note that NAT functionality is required to
   support legacy hosts, however, this can be done at any of the two
   devices A or B. The term NAT refers to translating the packet into
   the managed A+P address (B has address 12.0.0.1 and ports 2560-3071
   in the example above).  We then have two options:

   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 allocated information.  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 the LSN, which translates
       the packet and routes it in the public Internet.  The NATing
       device co-located with A 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 functionality.

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






Maennel, et al.          Expires August 4, 2009                [Page 10]

Internet-Draft          A+P Addressing Extension            January 2009


   1)  If the destination port number belongs to the range that A
       delegated to B, then A tunnels the packet to B. B can now NAT the
       packet using its stored mapping and route the translated packet
       in 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
       the 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 does neither fall 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.

3.3.  Reasons for allowing multiple A+P gateways

   Since each device in the A+P subsystem provides the encaps/decaps
   functionality, new devices can establish tunnels and become in turn
   part of the A+P subsystem.  As noted above, being part of the 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 the 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 4 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 the A+P subsystem.  This allows A+P-aware
   applications (or OSes) running on end hosts to enter the A+P
   subsystem and exploit untranslated connectivity.

   We envision two modes for end hosts to gain end-to-end connectivity.
   The first one is having end hosts perform the NAT function (along
   with 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 who 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).






Maennel, et al.          Expires August 4, 2009                [Page 11]

Internet-Draft          A+P Addressing Extension            January 2009


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


                  An A+P subsystem with multiple devices

                                 Figure 4

   Whatever the reasons might be, the Internet was build on a paradigm
   that end-to-end connectivity is possible.  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.


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

   Figure 5 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 (a large-scale-NAT provided
   by the provider).  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



Maennel, et al.          Expires August 4, 2009                [Page 12]

Internet-Draft          A+P Addressing Extension            January 2009


   "delayed translation want to talk to each other they SHOULD use A+P
   addresses or out-of-band addressing.


4.  Deployment Scenarios

4.1.  A+P for Broadband Providers

   Large broadband providers have not enough 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.

   In this document we use the following terms and assumptions:

   1.  Customer Premises Equipment (CPE), i.e. cable/DSL modem.

   2.  Provider Edge Router (PE), AKA customer aggregation router

   3.  A+P Border Router (APR), edge behind which A+P addresses are
       used.

   4.  Provider Border Router (BR), providers edge to other providers

   5.  Network Core Routers (Core), provider routers which are not at
       the edge.

   It is expected that 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 same functionality, and
   hence is able to establish an A+P subsystem with the CPE.  This
   device is referred to as A+P border router (APR), and could be
   located close to the PE router.  The core of the network MUST support
   the tunneling protocol (which SHOULD be IPv6, as per Constraint 7).
   In addition, we do not want to restrict any initiative of customers,
   who might want to run an A+P-capable network behind their CPE.  To
   satisfy both Constraints 1 and 3 unmodified legacy hosts should keep
   working seamlessly, while upgraded/new end-systems should be given
   the opportunity to exploit enhanced features.

4.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/
   PDN GW of 3GPP, or ASN GW of WiMAX).  The need to extend the address



Maennel, et al.          Expires August 4, 2009                [Page 13]

Internet-Draft          A+P Addressing Extension            January 2009


   is not within the provider network, but on the edge between the
   mobile phone devices and the base-station.  While desirable, IPv6
   connectivity may or may not be providable.

   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 many IPv4 addresses and is always in
   the data-path of the packets.  Transportation between 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
   necessarily 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 APR/LSN box in the network of the broadband provider.

4.3.  A+P from provider networks 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.
















Maennel, et al.          Expires August 4, 2009                [Page 14]

Internet-Draft          A+P Addressing Extension            January 2009


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


                      A simple A+P subsystem example

                                 Figure 6

   Consider the deployment scenario in Figure 6, where an A+P subsystem
   is formed between the CPE and an A+P border router (APR) within the
   ISP core network.  The APR is placed somewhere within the ISPs
   network, preferably close to the customer edge and forms the border
   from where on packets are forwarded based on address and port.  The
   provider MAY deploy a LSN co-located with the APR: in this case
   packets that have not been translated by the CPE will be handed to
   the LSN and NATted.  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 with the requirements stated above).

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



















Maennel, et al.          Expires August 4, 2009                [Page 15]

Internet-Draft          A+P Addressing Extension            January 2009


   +------------ IPv6-only transport ------------+
   | +---------------+ |              |          |
   | |A+P-application| |  +--------+  |  +-----+ |    dual-stacked
   | | on end-host   |=|==| CPE w/ |==|==| APR |-|--  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 7

   Figure 7 shows an example of how an upgraded application running on a
   legacy end-host can connect.  The legacy host is provisioned with a
   private IPv4 address allocated from 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.1 to
   connect to the A+P-subsystem.  Hence, the application will be
   delegated some space in the A+P address realm, and will be able to
   contact the external 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 APR provides NATing
   functionality, then it will not be possible connect legacy end-hosts.

4.4.  Example of A+P-forwarded packets

   This section provides a detailed example of A+P setup, configuration,
   and how packets flow from an end-host behind an A+P upgraded provider
   to any host in the IPv4 Internet and how the return packets flow
   back.  The following example discusses the situation of an A+P-
   unaware end-host.  Figure 8 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 via interaction via a website, or via automatic
   signaling).  In the following, we call a packet which is translated
   at the CPE an A+P-forwarded packet, in analogy with the port-



Maennel, et al.          Expires August 4, 2009                [Page 16]

Internet-Draft          A+P Addressing Extension            January 2009


   forwarding function employed in today's CPEs.  Upon receiving a
   packet from the internal interface, the CPE NATs it and forwards it
   to the APR.  The NAT on the CPE is assumed to store the 5-tuple
   (source_IPv4, source_port, destination_IPv4, destination_port,
   tunnel-interface).

   When the APR receives the A+P-forwarded packet, it de-capsulates the
   inner IPv4 packet and it checks the source address and port.  If the
   source address and port match the CPE's A+P address, then the APR
   simply routes the encapsulated packet.  This is always the case for
   A+P-forwarded packets.  Otherwise, the APR assumes that the packet is
   not A+P-forwarded, and then passes it to the LSN function, which in-
   turn NATs the packet and then releases it into the Internet.
   Figure 8 shows the packet flow for an outgoing A+P-forwarded packet.





































Maennel, et al.          Expires August 4, 2009                [Page 17]

Internet-Draft          A+P Addressing Extension            January 2009


                   +-----------+
                   |    Host   |
                   +-----+-----+
                      |  |  10.0.0.2
      IPv4 datagram 1 |  |
                      |  |
                      v  |  10.0.0.1
               +---------|---------+
               |CPE      |         |
               +--------|||--------+
                      | |||     a::2
       IPv6 datagram 2| |||
                      | |||<-IPv4-in-IPv6
                      | |||
                 -----|-|||-------
               /      | |||        \
              |  ISP access network |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      v |||     a::1
               +--------|||--------+
               |APR     |||        |
               +---------|---------+
                      |  |  12.0.0.1
      IPv4 datagram 3 |  |
                 -----|--|--------
               /      |  |         \
              |   ISP network /     |
               \      Internet     /
                 -----|--|--------
                      |  |
                      v  | 128.0.0.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+


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












Maennel, et al.          Expires August 4, 2009                [Page 18]

Internet-Draft          A+P Addressing Extension            January 2009


     +-----------------+--------------+-----------------------------+
     |        Datagram | Header field | Contents                    |
     +-----------------+--------------+-----------------------------+
     | IPv4 datagram 1 |     IPv4 Dst | 128.0.0.1                   |
     |                 |     IPv4 Src | 10.0.0.2                    |
     |                 |      TCP Dst | 80                          |
     |                 |      TCP Src | 8000                        |
     | --------------- | ------------ | --------------------------- |
     | IPv6 Datagram 2 |     IPv6 Dst | a::1                        |
     |                 |     IPv6 Src | a::2                        |
     |                 |     IPv4 Dst | 128.0.0.1                   |
     |                 |     IPv4 Src | 12.0.0.1                    |
     |                 |      TCP Dst | 80                          |
     |                 |      TCP Src | 100                         |
     | --------------- | ------------ | --------------------------- |
     | IPv4 datagram 3 |     IPv4 Dst | 128.0.0.1                   |
     |                 |     IPv4 Src | 12.0.0.1                    |
     |                 |      TCP Dst | 80                          |
     |                 |      TCP Src | 100                         |
     +-----------------+--------------+-----------------------------+

                         Datagram header contents

   An incoming packet undergoes the reverse process.  When the APR
   receives an IPv4 packet on an external interface, it first checks
   whether the destination port number falls in a delegated range or
   not.  If the address space was delegated, then APR tunnels the
   packets unmodified.  If the address space was not-delegated the
   packet will be handed to the LSN to check if a mapping is available.

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


















Maennel, et al.          Expires August 4, 2009                [Page 19]

Internet-Draft          A+P Addressing Extension            January 2009


                   +-----------+
                   |    Host   |
                   +-----+-----+
                      ^  |  10.0.0.2
      IPv4 datagram 3 |  |
                      |  |
                      |  |  10.0.0.1
               +---------|---------+
               |CPE      |         |
               +--------|||--------+
                      ^ |||     a::2
       IPv6 datagram 2| |||
                      | |||<-IPv4-in-IPv6
                      | |||
                 -----|-|||-------
               /      | |||        \
              | ISP access network  |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      | |||     a::1
               +--------|||--------+
               |APR     |||        |
               +---------|---------+
                      ^  |  12.0.0.1
      IPv4 datagram 1 |  |
                 -----|--|--------
               /      |  |         \
              |  ISP network /      |
               \      Internet     /
                 -----|--|--------
                      |  |
                      |  | 128.0.0.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

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













Maennel, et al.          Expires August 4, 2009                [Page 20]

Internet-Draft          A+P Addressing Extension            January 2009


     +-----------------+--------------+-----------------------------+
     |        Datagram | Header field | Contents                    |
     +-----------------+--------------+-----------------------------+
     | IPv4 datagram 1 |     IPv4 Dst | 12.0.0.1                    |
     |                 |     IPv4 Src | 128.0.0.1                   |
     |                 |      TCP Dst | 100                         |
     |                 |      TCP Src | 80                          |
     | --------------- | ------------ | --------------------------- |
     | IPv6 Datagram 2 |     IPv6 Dst | a::2                        |
     |                 |     IPv6 Src | a::1                        |
     |                 |     IPv4 Dst | 12.0.0.1                    |
     |                 |       IP Src | 128.0.0.1                   |
     |                 |      TCP Dst | 100                         |
     |                 |      TCP Src | 80                          |
     | --------------- | ------------ | --------------------------- |
     | IPv4 datagram 3 |     IPv4 Dst | 10.0.0.2                    |
     |                 |     IPv4 Src | 128.0.0.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 he/she has an home gateway with customizable port-forwarding.

4.5.  Forwarding of standard packets

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

4.6.  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 APR will need to examine the embedded header
   to extract the port number, while the A+P gateway will do the
   necessary rewriting.



Maennel, et al.          Expires August 4, 2009                [Page 21]

Internet-Draft          A+P Addressing Extension            January 2009


   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 BR 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 an external domain/legacy Internet towards an A+P
   device are not supported.)

4.7.  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
   virtual hosting), 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 kind of NATs is the
   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.


5.  IANA Considerations

   This document makes no request of IANA.

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


6.  Security Considerations







Maennel, et al.          Expires August 4, 2009                [Page 22]

Internet-Draft          A+P Addressing Extension            January 2009


7.  Acknowledgments

   The authors wish to thank especially (in alphabetical order) Gabor
   Bajko, Remi Despres, Alain Durand, Pierre Levis, Teemu Savolainen and
   Jan Zorz for their close collaboration on the development of the A+P
   approach.  David Ward for review, constructive criticism, and
   interminable questions.  Cullen Jennings for discussion and review of
   fragmentation, 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: Bernhard Ager, Rob
   Austein, Gert Doering, Dino Farinacci, Russ Housley, and Ruediger
   Volk.


8.  References

8.1.  Normative References

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

8.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-v6ops-port-restricted-ipaddr-assign]
              Bajko, G. and T. Savolainen, "Port Restricted IP Address
              Assignment",
              draft-bajko-v6ops-port-restricted-ipaddr-assign-02 (work
              in progress), November 2008.

   [I-D.boucadair-dhc-port-range]
              Boucadair, M., Grimault, J., Levis, P., and A.
              Villefranque, "DHCP Options for Conveying Port Mask and
              Port Range Router IP Address",
              draft-boucadair-dhc-port-range-01 (work in progress),
              October 2008.

   [I-D.boucadair-port-range]
              Boucadair, M., Grimault, J., Levis, P., and A.
              Villefranque, "Provider-Provisioned CPE: IPv4 Connectivity
              Access in the context of IPv4  address exhaustion",
              draft-boucadair-port-range-00 (work in progress),
              October 2008.

   [I-D.durand-softwire-dual-stack-lite]



Maennel, et al.          Expires August 4, 2009                [Page 23]

Internet-Draft          A+P Addressing Extension            January 2009


              Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
              "Dual-stack lite broadband deployments post IPv4
              exhaustion", draft-durand-softwire-dual-stack-lite-01
              (work in progress), November 2008.

   [I-D.levis-behave-ipv4-shortage-framework]
              Levis, P., Boucadair, M., Grimault, J., and A.
              Villefranque, "IPv4 Shortage Framework",
              draft-levis-behave-ipv4-shortage-framework-00 (work in
              progress), January 2009.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

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


Authors' Addresses

   Olaf Maennel
   T-Labs/TU-Berlin
   Ernst-Reuter-Platz 7
   Berlin  10587
   Germany

   Phone: +491607199931
   Email: olaf@maennel.net


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

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












Maennel, et al.          Expires August 4, 2009                [Page 24]

Internet-Draft          A+P Addressing Extension            January 2009


   Luca Cittadini
   Universita' Roma Tre
   via della Vasca Navale, 79
   Rome,   00146
   Italy

   Phone: +39 06 5733 3215
   Email: luca.cittadini@gmail.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
































Maennel, et al.          Expires August 4, 2009                [Page 25]


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