Network Working Group                                  M. Boucadair, Ed.
Internet-Draft                                             J-L. Grimault
Intended status: Informational                                  P. Levis
Expires: April 26, 2009                                  A. Villefranque
                                                          France Telecom
                                                        October 23, 2008


  Provider-Provisioned CPE: IPv4 Connectivity Access in the context of
                        IPv4 address exhaustion
                   draft-boucadair-port-range-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 April 26, 2009.

Abstract

   This memo proposes a solution, based on fractional addresses, to face
   the IPv4 public address exhaustion.  It details the solution and
   presents a mock-up implementation, with the results of tests that
   validate the concept.  Finally, it makes a comparison with the
   alternative Carrier-Grade NAT (CG-NAT) solutions.







Boucadair, et al.        Expires April 26, 2009                 [Page 1]


Internet-Draft          Provider-Provisioned CPE            October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Context  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Tentative Solutions: Overview and Limitations  . . . . . .  4
     1.3.  Contribution of this draft . . . . . . . . . . . . . . . .  6

   2.  Conventions used in this document  . . . . . . . . . . . . . .  6

   3.  Provider Provisioned CPE: Overall Procedure  . . . . . . . . .  6
     3.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Basic Principles . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Illustration Examples  . . . . . . . . . . . . . . . . . .  8
       3.3.1.  Outbound communications  . . . . . . . . . . . . . . .  9
       3.3.2.  Inbound communications . . . . . . . . . . . . . . . . 10
     3.4.  Retrieving IP Configuration Data . . . . . . . . . . . . . 11
       3.4.1.  Assumption . . . . . . . . . . . . . . . . . . . . . . 11
       3.4.2.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 12
     3.5.  Required Modifications . . . . . . . . . . . . . . . . . . 13
       3.5.1.  CPE  . . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.5.2.  Service Provider Infrastructure  . . . . . . . . . . . 13
       3.5.3.  DHCP Server Implementations  . . . . . . . . . . . . . 13
     3.6.  Port Range Router  . . . . . . . . . . . . . . . . . . . . 14
       3.6.1.  Main function  . . . . . . . . . . . . . . . . . . . . 14
       3.6.2.  Routing Considerations: Focus on IGP . . . . . . . . . 15
       3.6.3.  Binding Table  . . . . . . . . . . . . . . . . . . . . 15
       3.6.4.  Provisioning . . . . . . . . . . . . . . . . . . . . . 16
       3.6.5.  Localization inside a Service Provider's domain  . . . 17
     3.7.  An alternative to avoid DHCP Server's modification . . . . 17

   4.  Experimentation Results  . . . . . . . . . . . . . . . . . . . 20
     4.1.  Configuration  . . . . . . . . . . . . . . . . . . . . . . 20
     4.2.  On the CPE . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.3.  On the PRR . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.4.  Main Results . . . . . . . . . . . . . . . . . . . . . . . 23
     4.5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 25

   5.  Comparison with CG-NAT . . . . . . . . . . . . . . . . . . . . 25
     5.1.  Generic Hurdles  and Focus on Transparency to
           applications which enclose IPv4 address in their
           protocol messages  . . . . . . . . . . . . . . . . . . . . 25
     5.2.  Focus on Legal Storage . . . . . . . . . . . . . . . . . . 26
     5.3.  Sessions Handling in CG-NAT  . . . . . . . . . . . . . . . 29
     5.4.  Peer-to-Peer applications  . . . . . . . . . . . . . . . . 30
     5.5.  Position in a context of future IPv6 deployments . . . . . 30

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30




Boucadair, et al.        Expires April 26, 2009                 [Page 2]


Internet-Draft          Provider-Provisioned CPE            October 2008


   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 31
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 31

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 33









































Boucadair, et al.        Expires April 26, 2009                 [Page 3]


Internet-Draft          Provider-Provisioned CPE            October 2008


1.  Introduction

1.1.  Context

   It is commonly agreed by the Internet community that the exhaustion
   of public IPv4 addresses is an ineluctable fact.  In this context,
   the community was mobilized in the past to adopt a promising solution
   (in particular with the definition of IPv6).  Nevertheless, this
   solution is not globally activated by Service Providers for both
   financial and strategic reasons.  In the meantime, these Service
   Providers are not indifferent to the alarms recently emitted by the
   IETF (particularly by the reports presented within the GROW working
   group (Global Routing Operations Working Group) meetings.

   G. Huston introduced an extrapolation model to forecast the
   exhaustion date of IPv4 addresses managed by IANA.  This effort
   indicates that if the current tendency of consumption continues at
   the same pace, IPv4 addresses exhaustion of IANA's pool would occur
   in 2011, while RIRs'pool would be exhausted in late 2012.  The state
   of the current consumption of public IPv4 addresses is daily updated
   and is available at this URL:
   http://www.potaroo.net/tools/ipv4/index.html.

1.2.  Tentative Solutions: Overview and Limitations

   In order to solve this depletion problem, Service Providers need to
   investigate and enable means to ensure the deployment of their
   service offerings and their delivery to end users.  Two strands may
   be followed:

      (1) Migrate to IPv6:

   IPv6 has been introduced for several years as the next version of the
   IP protocol.  This new version offers an abundance of IP addresses as
   well as several enhancements compared to IPv4 especially with the
   adoption of a hierarchical routing (and therefore allows reducing the
   routing tables size).  IPv6 specifications are mature and current
   work within the IETF is related to operational aspects.
   Nevertheless, Service Providers have not largely activated IPv6 in
   their networks yet.

   However, even if a Service Provider activates IPv6, it will be
   confronted with the problem to ensure a global connectivity towards
   nowadays Internet v4.  Mechanisms such as NAT-PT (Network Address
   Translation Protocol Translation) were introduced to ensure the
   interconnection between two heterogeneous realms (i.e.  IPv4/IPv6)
   and to ensure a continuity of IP communications (i.e. end-to-end).
   It is out of scope of this document to analyze the hurdles of these



Boucadair, et al.        Expires April 26, 2009                 [Page 4]


Internet-Draft          Provider-Provisioned CPE            October 2008


   solutions.

   Despite current IPv6 deployment situation, IPv6 is a long term and
   viable alternative to offer IP connectivity services to a large
   number of customers.  From this perspective, Service Providers should
   avoid introducing new functions and nodes which may be problematic
   when envisaging migrating to IPv6.  This critical requirement should
   not be taken into account only during the technical engineering
   phase, but also when elaborating required CAPEX (Capital
   Expenditure)/OPEX (Operational Expenditure) estimation of activating
   alternative schemes to solve or to reduce the impact of the IPv4
   address exhaustion phenomenon.

   Note that this requires deploying interconnection mechanisms with the
   already existent IPv4 realms.  This cost overhead should be
   considered in transition scenarios.

      (2) Enhance current IPv4 architectures and optimize the assignment
      of IPv4 addresses:

   A first example of the implementation of this option is the
   introduction of a second level of NAT, called Provider-NAT or Carrier
   Grade NAT (CG-NAT).  This node is located in the Service Provider
   domain.  In such option, only private addresses are assigned to end-
   user home gateways, which still perform their own NAT.  The CG-NAT is
   responsible for translating IP packets issued with private addresses
   to ones with publicly routable IPv4 addresses (especially when
   exiting the domain of the Service Provider).

   The introduction of the CG-NAT will have an important impact on the
   applications.  Some services will only work in a degraded mode, some
   will even not work at all (refer to Section 5.1 for more details
   about encountered hurdles.)

   Another example of this second option is the proposal that has been
   made to release IPv4 class E addresses [ID.240space]: concretely to
   reclassify 240/4 as usable unicast address space.  The rationale of
   this proposal is that since the community has not concluded whether
   the E block should be considered public or private, and given the
   current consumption rate, it is clear that the block should not be
   left unused.  This proposal requires updating IP-enabled equipment so
   as to treat correctly IPv4 addresses belonging to 240/4 blocks.
   These addresses should be routable and announced for instance between
   adjacent Autonomous Systems (ASes) through BGP (Border Gateway
   Protocol) for instance.  An exhaustive study should be undertaken to
   evaluate the economic and technical impact of such new policy.





Boucadair, et al.        Expires April 26, 2009                 [Page 5]


Internet-Draft          Provider-Provisioned CPE            October 2008


1.3.  Contribution of this draft

   This memo specifies an alternative solution to the Double NAT
   architecture which aims at solving the depletion problem as
   encountered by current ISPs.  The proposed solution, called Provider-
   Provisioned CPE is stateless and does not alter the various offered
   services.  The solution presented in this document does not require
   severe modifications to current engineering practices as adopted by
   major Service Providers.  Furthermore, the solution is scalable and
   can be deployed in several variants, especially to prepare the
   migration towards IPv6.

   This draft describes a lightweight architecture that may be deployed
   by Service Providers to offer IP connectivity services to their
   already subscribed customers or to new ones.  This document provides
   an implementation scenario.  Service Providers are free to enforce
   their own engineering rules based on their internal policies and
   available technological means as activated in their IP
   infrastructure.  The solution is flexible enough to be accommodated
   in various contexts.

   The scalability of this solution is similar to current deployed IP
   architectures.  No session-related states are maintained in core
   nodes operated by a given Service Provider.

   This draft is a contribution to the required specification effort
   mandated in [ID.arkko], especially scenario c.


2.  Conventions used in this document

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


3.  Provider Provisioned CPE: Overall Procedure

3.1.  Introduction

   As an alternative to the Double NAT solution, which suffers from
   several drawbacks, a second alternative is proposed within this
   document.  The motivations for introducing this second alternative
   are as follows:

      - Not to alter current (IPv4-based) services delivery and to not
      impact the introduction of future services;




Boucadair, et al.        Expires April 26, 2009                 [Page 6]


Internet-Draft          Provider-Provisioned CPE            October 2008


      - Avoid maintaining sessions states at the core network and
      privilege stateless solutions;

      - Ease management functions (including provisioning, configuration
      operations, etc.);

      - Optimise CAPEX and OPEX: As shown latter in this draft, the
      functional requirements to implement the proposed procedure are
      lightweight.  Only slight modifications are required to be
      brought.  Furthermore, the offered services are not impacted.
      Management practices would remain as today.  For example, because
      the solution described in this memo does not handle dynamic NAT
      mappings (contrary to the CG-NAT), the planned maintenance
      operations (replacement of involved network equipment) would not
      impact the delivered services as a CG-NAT-based solution would do;

      - Minor impact on routing and addressing architectures;

      - Transparent to end-users: The same practices as today's ones
      will remain (e.g.  Port forwarding on CPE);

      - Usability easiness;

      - Facilitate functional separation (Service and Network): For
      instance, and unlike CG-NAT, the problem to run SIP-based services
      above a third party IP infrastructure would not be encountered
      with the proposed solution;

      - Ease implementing legal requirements (optimize storage of legal
      data);

      - Ease migration to a long term solution such as IPv6;

   This section focuses only on the IPv4 variant of the solution.  Other
   variants have been defined to integrate IPv6 and offer a global IP
   connectivity services including towards IPv6 realms in a stateless
   manner.  Companion Internet Drafts will be submitted latter.

3.2.  Basic Principles

   The major idea is to assign the same IP address to several end-
   users' devices (e.g.  Home Gateways (HGW) embedding NAT) and to
   constraint the (source) port numbers to be used by each HGW.  In
   addition to the assigned IP address to access IP connectivity
   services, an additional parameter, called Port Mask, is also assigned
   to the customer's device.  This mask indicates which Port Range is to
   be used by the customers' devices.




Boucadair, et al.        Expires April 26, 2009                 [Page 7]


Internet-Draft          Provider-Provisioned CPE            October 2008


   In the remaining part of this draft, the above mentioned public
   address is denoted as Primary IP Address.

   For outbound communications, a given HGW proceeds to its classical
   operations except the constraint to control the source port number
   assignment so as to be within the Port Range assigned by its IP
   connectivity Service Provider.  The traffic is then routed inside the
   Service Provider's domain and delivered to its final destination
   (within the service domain or to external domains).

   For inbound communications (i.e.  Towards customers attached to the
   Service Provider which has activated the procedure detailed in this
   memo), the traffic is trapped by a dedicated function called: Port
   Range Router (PRR).  This function may be embedded in current routers
   or hosted by new nodes to be integrated in the IP infrastructure of
   these Service Providers.  Appropriate routing tuning policies are
   enforced so as to drive the inbound traffic to cross a PRR (see
   Section 3.6.2 for more details).  Particularly, each PRR correlate
   the Primary IP Address and information about the allowed port values
   with a specific identifier called: routing identifier.  This routing
   identifier is used to route the packets to the suitable device among
   all those owning the same IP address.

   Note that for some reasons (e.g.  Ease implementation of port-driven
   RPF (Reverse Path Forwarding) checking, anti-spoofing techniques,
   etc.), outbound traffic may be constrained to invoke the PRR
   function.  This feature for outbound packets is considered as an
   engineering option.  Service Providers are free to enforce it or not.

3.3.  Illustration Examples

   In order to illustrate the procedure detailed above, let's consider
   the example illustrated Figure 1.

   As shown in Figure 1, the same IP address 5.5.5.5 is assigned to the
   Home NAT of Phone-1, the one of Phone-2 and the one of Phone-3.
   Three port masks are also assigned to the three users.  In this
   example, we assume that distinct Port Ranges are assigned to each
   HGW.  For example, the Home NAT of Phone-1 can use a range of port
   numbers up to 10000, the Home NAT of Phone-2 a range of port numbers
   from 10100 to 20000 and the one of Phone-3 is from 20100 to 30000.










Boucadair, et al.        Expires April 26, 2009                 [Page 8]


Internet-Draft          Provider-Provisioned CPE            October 2008


   +-------+    +---+    +--------------+    +------------+
   |       |    |   |    |              |    |            |
   |Phone-1|----|HGW|----|              |    |            |
   |       |    |   |    |              |    |            |
   +-------+    +---+    |              |    |            |
   10.0.0.1   5.5.5.5    |              |    |            |
                         |              |    |            |
   +-------+    +---+    | Service      +----+ Internet   |
   |       |    |   |    |              |    |            |
   |Phone-2|----|HGW|----| Provider     |    |            |
   |       |    |   |    |              |    |            |
   +-------+    +---+    | Domain       |    |            |    +-------+
   192.168.1.1 5.5.5.5   |              |    |            |----|Phone-4|
                         |              |    |            |    +       |
   +-------+    +---+    |              |    |            |    +-------+
   |       |    |   |    |      +-----+ |    |            | 25.25.25.28
   |Phone-3+----+HGW+----+      | PRR | |    |            |
   |       |    |   |    |      +-----+ |    |            |
   +-------+    +---+    +--------------+    +------------+
   10.0.45.25  5.5.5.5

                     Figure 1: Reference Architecture

3.3.1.  Outbound communications

   When Phone-1 issues an IP packet to Phone-4, the source IP address is
   equal to 10.0.0.1 and the source port number is 1234 (i.e.  Packet
   Po1 represented in Figure 2).

   Once received by the Home NAT, this latter proceeds to its NAT
   operations and assigns a port number in its provisioned range.  In
   this example, a source port number 9123 is assigned.  The packet
   (i.e.  Po2 represented in Figure 2) is then routed until its final
   destination (i.e.  Phone-4).

















Boucadair, et al.        Expires April 26, 2009                 [Page 9]


Internet-Draft          Provider-Provisioned CPE            October 2008


   +-------+Po1 +---+Po2 +--------------+    +------------+
   |       |===>|   |=======            |    |            |
   |Phone-1+----+HGW+----+  \           |    |            |
   |       |    |   |    |   \          |    |            |
   +-------+    +---+    |    \         |    |            |
   10.0.0.1   5.5.5.5    |     \        |    |            |
                         |      ====\   |    |            |
   +-------+    +---+    | Service   \  +----+ Internet   |
   |       |    |   |    |            \ |    |            |
   |Phone-2+----+HGW+----+ Provider    \|    |            |
   |       |    |   |    |              \    |            |    +-------+
   +-------+    +---+    | Domain       |\====================>|       |
   192.168.1.1 5.5.5.5   |              |    |            +----+Phone-4|
                         |              |    |            |    |       |
   +-------+    +---+    |              |    |            |    +-------+
   |       |    |   |    |      +-----+ |    |            | 25.25.25.28
   |Phone-3+----+HGW+----+      | PRR | |    |            |
   |       |    |   |    |      +-----+ |    |            |
   +-------+    +---+    +--------------+    +------------+
   10.0.45.25  5.5.5.5

               Figure 2: Example of an Inbound Communication

3.3.2.  Inbound communications

   Phone-4 can send traffic to 5.5.5.5:9123 (i.e.  Ultimately to Phone-
   1)(see Pi1 traffic of Figure 3).  This traffic crosses the Port Range
   Router which proceeds to a port-driven routing.

   Concretely, the PRR retrieves both destination IP address and
   destination port number from the received packet.  Then, it checks
   its binding table and retrieves the suitable information (i.e.
   routing identifier) to route the packet towards the appropriate HGW.
   The initial packet is then routed (e.g. encapsulated) and sent to
   that HGW using the retrieved routing identifier.

   Packets are routed up to Home NAT of Phone-1 (see Pi2 traffic of
   Figure 3) which proceeds to a de-encapsulation operation.  At this
   phase, it retrieves a packet destined to 5.5.5.5:9123.  As a final
   step, it checks its mapping table in order to find which local IP
   address and port numbers are to be used.  In this example, an entry
   exists: 10.0.0.1 and 1234 are returned and the packet is translated
   and routed to Phone-1.

   All these operations are similar to classical NAT operations except
   the operations undertaken by the PRR and the conditioned port numbers
   assignment process in the HGW.  This simple example does not take
   into account IP addresses which may be involved inside the payload,



Boucadair, et al.        Expires April 26, 2009                [Page 10]


Internet-Draft          Provider-Provisioned CPE            October 2008


   i.e. those requiring ALG invocation.


   +-------+Pi3 +---+    +--------------+    +------------+
   |       |<===|   |<=\ |              |    |            |
   |Phone-1+----+HGW+--|-+              |    |            |
   |       |    |   |  | |              |    |            |
   +-------+    +---+  | |              |    |            |
   10.0.0.1   5.5.5.5  | |              |    |            |
                       | |              |    |            |
   +-------+    +---+  | | Service      +----+ Internet   |
   |       |    |   |  | |              |    |            |
   |Phone-2+----+HGW+--|-+ Provider     |    |            |
   |       |    |   |  | |              |    |    Pi1     |    +-------+
   +-------+    +---+  | | Domain       |/=====================|       |
   192.168.1.1 5.5.5.5  \|              /    |            +----+Phone-4|
                         \             /|    |            |    |       |
   +-------+    +---+    |\           / |    |            |    +-------+
   |       |    |   |    | \Pi2 +-----+ |    |            | 25.25.25.28
   |Phone-3+----+HGW+----+  \===|PRR  | |    |            |
   |       |    |   |    |      +-----+ |    |            |
   +-------+    +---+    +--------------+    +------------+
   10.0.45.25  5.5.5.5

              Figure 3: Example of an Outbound Communication

   Note that the paths shown in the figures above (i.e.  Figure 2 and
   Figure 3) represent a functional invocation path of the PRR function
   and not real IP routes.  Indeed, based on adopted PRR deployment
   strategy (e.g.  PRR embedded in a DSLAM (Digital Subscriber Line
   Access Multiplexer), PRR embedded in an access router, a centralized
   PRR per access PoP (Point of Presence), etc.), IP routes may be
   symmetric or asymmetric at least at access segment.

   Moreover, the PRR function may be embedded in an existing router or
   be hosted by a dedicated node.

   See Section 3.6.5 for additional considerations.

3.4.  Retrieving IP Configuration Data

3.4.1.  Assumption

   In the context of this section, it is assumed that DHCP (Dynamic Host
   Configuration Protocol, [RFC2131]) is used to convey IP connectivity
   information.  Other alternatives, such as PPP (Point-to-Point
   Protocol, [RFC1661]), may be used.  The procedure described in this
   section is only an illustration example.  It may be adapted so as to



Boucadair, et al.        Expires April 26, 2009                [Page 11]


Internet-Draft          Provider-Provisioned CPE            October 2008


   be able to apply in other technological contexts.

3.4.2.  Procedure

3.4.2.1.  Overview

   At bootstrapping phase, a given HGW issues a DHCP_DISCOVER message.
   This message is sent in broadcast.  This message can be relayed by a
   DHCP Client Relay or be received directly by a DHCP Server.  Once
   this message is received by a DHCP Server, this latter answers the
   requestor by a dedicated DHCP_OFFER message containing a
   configuration offer.

   The exchange which intervenes is illustrated in the following figure:

   +-----+                     +-------------+
   | HGW |                     | DHCP Server |
   +-----+                     +-------------+
      |                               |
      |      (1) DHCP DISCOVER        |
      |------------------------------>|
      |                               |
      |                               |
      |       (2) DHCP OFFER          |
      |<------------------------------|
      |                               |

                         Figure 4: DHCP Call Flow

   DHCP OFFER message encloses a set of IP-related information so as to
   access IP connectivity service.  Particularly, it includes an IP
   address together with a new option denoted as Port Mask, see:
   [ID.boucadair] (note that this new DHCP option is not the same as the
   one defined in [ID.bajko]).

   Additional information may be included in the DHCP offer .

   The use of Port Mask (similar to subnet mask) makes it possible to
   extend the notion of Port Range with non-continues values, for the
   sake of flexibility.

   A Port Range is then a set of ports that all have in common a subset
   of pre-positioned bits.

   Once a Port Mask information is received by a HGW, it constraints its
   NAT operations to the provisioned range.  The number of customers to
   which an ISP can assign the same IP address depends on the number of
   allowed port numbers per user.  Thus, if N bits are used to build the



Boucadair, et al.        Expires April 26, 2009                [Page 12]


Internet-Draft          Provider-Provisioned CPE            October 2008


   Port Mask, 2^N customers can be provided with the same IP address.
   For example: If N == 3, then the Service Provider multiplies by 8 its
   capacity in term of number of customers to which the connectivity
   service may be delivered.

3.5.  Required Modifications

3.5.1.  CPE

   Above, we have quoted the case of Home Gateway but the solution can
   fit to any kind of Customer Premises Equipment (CPE).

   In order to activate the aforementioned solution, slight
   modifications are required to be supported by CPEs.  Concretely, CPEs
   MUST be able to constraint their NAT operations and to use only
   source port numbers within the allocated Port Range.  If an IP packet
   is received by a given Port Range-enabled CPE, with a destination
   port number outside the assigned Port Range, the packet MUST be
   discarded.

   Moreover, Port Range-enabled CPEs MUST be able to enforce
   configuration data received from the Service Providers so as to
   constraint its Port Range.  More particularly, if DHCP is used to
   convey configuration data, a particular DHCP option (to be assigned
   by IANA) is to be supported by that CPE.

3.5.2.  Service Provider Infrastructure

   The IP infrastructure of a given IP Service Provider is maintained
   slightly unchanged when deploying the Provider-Provisioned CPE
   solution.  Only, a new function is introduced.  This new function is
   denoted as PRR.  This function is responsible for routing packets to
   the appropriate CPE among a set of CPEs to which the same IP address
   is assigned by the Service Provider.  This operation is denoted as
   Port-Driven Routing operation since the destination IP address is not
   anymore sufficient to handle routing operations and the information
   related to destination port is also required.

   Except the PRR, all classical operations and practices remain as
   today's ones.

3.5.3.  DHCP Server Implementations

   In case DHCP is used to convey IP connectivity information to
   customers' devices (CPE), DHCP server implementations may be modified
   accordingly.  Indeed, DHCP server implementation should be modified
   so as to be able to support additional options such as Port Mask DHCP
   option.  The DHCP server assignment policy can be tuned by the



Boucadair, et al.        Expires April 26, 2009                [Page 13]


Internet-Draft          Provider-Provisioned CPE            October 2008


   Service Provider.  A given Service Provider can provision its DHCP
   server with the Port Range to be allocated to end users' devices.

   A second alternative to assign Port Ranges is described in Section
   3.7.  This alternative does not require any modification of the DHCP
   Server.  Nevertheless, new changes are required to be supported by
   DHCP Relay Clients.

3.6.  Port Range Router

3.6.1.  Main function

   As stated above, the main function implemented by a PRR is a port-
   driven routing.  In order to implement the port-driven routing, the
   following operations are achieved by a given PRR:

   In order to implement the port-driven routing, the following
   operations are achieved by a given PRR:

   1.  It retrieves both destination IP address and destination port
       number.

   2.  Based on this couple, the PRR consults its binding table and
       retrieves the routing identifier.

   Several modes may be envisaged to assign a routing identifier to be
   used as a deterministic discriminator to unambiguously identify a
   device among all those having the same IP address.

   Hereafter are provided some implementation alternatives:

   1.  If a Secondary-IP address is used as the routing identifier: the
       PRR consults its binding table and retrieves the corresponding
       Secondary-IP address associated with a (Destination IP, Port
       Mask).  Once retrieved, the PRR encapsulates the original packets
       in an IPv4 one with a destination IP address equal to
       Secondary-IP.  This packet is then routed according to
       instantiated IGP (Interior Gateway Protocol) routes.  Once
       received by the CPE, a de-encapsulation operation is achieved.
       The original packets is then treated and handled locally.  If
       destination port of that packet is within the Port Range of that
       CPE, and depending on the local NAT implementation, the packet
       may be accepted and then proceed to classical NAT operation.
       Otherwise, the packet is dropped.

   2.  Instead of encapsulation, and if source routing is supported, an
       explicit route is forced.  A loose route is indicated in the
       packets.  This loose route contains at least Secondary-IP.  The



Boucadair, et al.        Expires April 26, 2009                [Page 14]


Internet-Draft          Provider-Provisioned CPE            October 2008


       routing of the resulting packet will be based on that address and
       not the destination one.  The packet will be then received by the
       CPE with that Secondary-IP address.  Then, the CPE will route the
       packet based on the final destination IP address.  Since that
       address is also an IP address of that CPE, the packet is handled
       locally.  The remaining operations are similar to the ones
       implemented by current CPEs.

   3.  If disjoint routes have been pre-installed so as to unambiguously
       identify the targeted device among all those having the same IP
       address, the PRR consults its binding tables and retrieves the
       index of the route corresponding to that (Destination IP, Port
       Mask) pair.  The original packet is then sent over that route.
       Since the routes are disjoint, the packet will be received by the
       targeted CPE.

   As for inbound, a new operation is introduced in the path, this
   operation is a port-driven operation with no modification of the
   original packet.  Further evaluation should be undertaken so as to
   assess the impact of this operation.

   The performance experienced by outbound packets is not impacted since
   no alteration of the issued packets is to be enforced in the path.
   The experienced QoS (Quality of Service) is then the same as the
   currently deployed one.

3.6.2.  Routing Considerations: Focus on IGP

   A PRR is inserted in the inbound path in order to execute a port-
   driven routing.  This constraint is translated into an IGP one.
   Indeed, a given PRR MUST advertise in IGP the primary IP addresses it
   handles.  Doing so, all inbound packets will cross that PRR.

   In case Secondary-IP addresses are used to uniquely identify a CPE
   among all those having the same Primary-IP address, Secondary-IP
   addresses MUST NOT be routable addresses inside core network.  These
   addresses MUST NOT be reachable from the Internet.  An example of the
   scope of those addresses is up to the frontier of an IP access POP
   (Point of Presence).

3.6.3.  Binding Table

   In order to implement port-driven routing operations, a PRR maintains
   a binding table which is a collection of entries correlating (IP
   address, Port Mask) with a routing identifier.

   This table should not be confused with the NAT table as maintained by
   a CG-NAT.



Boucadair, et al.        Expires April 26, 2009                [Page 15]


Internet-Draft          Provider-Provisioned CPE            October 2008


3.6.4.  Provisioning

3.6.4.1.  Needs

   In order to be able to treat received packets and then to proceed to
   port-driven routing, a PRR MUST be provisioned appropriately.
   Concretely, and as stated above, a given PRR needs to maintain a
   binding table which correlates a destination IP address and a Port
   Mask with a routing identifier (such as a secondary IPv4 address,
   IPv6 address, routing index, MAC address, PPP session identifier,
   etc.).  This binding table can be provisioned either by the Service
   Provider (owing to an internal interface) or by the CPE itself once
   IP connectivity information has been received from the service
   platform.

   These two options are described hereafter.  Service Providers are
   free to implement the option which meets its internal engineering
   policies.

3.6.4.2.  Option 1: CPE-Provisioned PRR

   Once its IP connectivity configuration is retrieved owing to a
   dedicated means such as DHCP, a given CPE enforces this new
   configuration.  Particularly, the new received information may
   contain the following information:

   {Primary-IP, Port Mask, Default_PRR, Routing Identifier}

   In case the adopted method for the routing identifier (mentioned in
   Section 3.6.1) is a Secondary-IP address, a message is issued by the
   CPE towards its Default PRR.  This message notifies that PRR about
   the new association: i.e.  (Primary-IP, Port Mask) with Secondary-IP.
   This notification is achieved owing to a new message denoted as
   BIND().  Once received by the PRR, an ACK() message must be sent as
   response.  If no ACK() message is received, the CPE re-transmits its
   BIND() message.

   The procedure is sketched in the following figure:













Boucadair, et al.        Expires April 26, 2009                [Page 16]


Internet-Draft          Provider-Provisioned CPE            October 2008


   +-----+                         +-----+
   | HGW |                         | PRR |
   +-----+                         +-----+
      |                               |
      |         (1) BIND()            |
      |------------------------------>|
      |                               |
      |                               |
      |           (2) ACK             |
      |<------------------------------|
      |                               |

                 Figure 5: Example of CPE-provisioned PRR

3.6.4.3.   Option 2: Provider-Provisioned PRR

   Here, the provisioning of PRR binding table is undertaken by the
   Service Provider owing to the activation of appropriate management
   interfaces.  These interfaces are internal to Service Provider's
   domain and are not visible to end-users.  Exchanges between the PRR
   and the management realms are operated by the Service Provider.  An
   implementation scenario of this option, is that once the DHCP server
   has assigned an IP address together with a Port Range a dedicated
   message is issued towards a PRR so as to instantiate a new entry in
   the binding table of that PRR.  The entry can be refreshed or dropped
   once required.

   In both options, the structure of the binding tables and the state
   machine of the PRR are identical.

3.6.5.  Localization inside a Service Provider's domain

   Each service Provider is free to adopt its internal policies for the
   deployment of PRRs.  Nevertheless, we recommend deploying those nodes
   at access segment in order not to significantly impact end-to-end
   routing optimization.  A PRR function can be embedded in an access
   router, a DSLAM, etc.

3.7.  An alternative to avoid DHCP Server's modification

   To avoid alteration of already in place DHCP server, this section
   presents an alternative to implement Port Range assignment procedure.
   This alternative relies on DHCP Relay Clients and not on DHCP
   servers.  These latter are kept unchanged.  Their main function is to
   assign an available IP address.  This address is assumed to be routed
   inside the Service Provider domain.

   DHCP Relay Clients, in cooperation with the PRR, maintains a set of



Boucadair, et al.        Expires April 26, 2009                [Page 17]


Internet-Draft          Provider-Provisioned CPE            October 2008


   pre-assignments based on a pre-provisioned Service Provider policy
   regarding how to build Port Ranges.  As an example, if the
   implemented policy is to assign the same IP address to 4 customers,
   then 4 Port Ranges per IP address are statically built and then
   assigned to customers upon request.

   In this context, DHCP Relay Clients do not relay any IP assignment
   request until all available Port Ranges are allocated.

   Figure 6 and Figure 7 provide an example of this option.  In this
   example, CPE-1 and CPE-2 are two CPE of two distinct customers.

   CPE-1 sends first its DHCP DISCOVER message.  This message is
   received by the DHCP Relay.  Upon receipt, a lookup on available IP
   address and Port Range is achieved by the DHCP Relay.

   Since no IP address is available, DHCP DISCOVER message is forwarded
   to the DHCP Server.  A DHCP OFFER is then sent back.  This offer is
   trapped by the DHCP Relay.

   The assigned IP address is retrieved and a pre-allocation of a Port
   Range is achieved.  The offer is then updated with the Port Range
   Information and then relayed to CPE-1.

   The remaining operations are the same operations as current DHCP
   exchanges.

























Boucadair, et al.        Expires April 26, 2009                [Page 18]


Internet-Draft          Provider-Provisioned CPE            October 2008


   +-----+              +-----+           +--------+            +------+
   |CPE-1|              |DHCP |           |Binding |            |DHCP  |
   |     |              |Relay|           |Table   |            |Server|
   +-----+              +-----+           +--------+            +------+
      |  (1)DHCP DISCOVER  |                  |                    |
      |------------------->|                  |                    |
      |                    |(2) Check if there|                    |
      |                    |  is an available |                    |
      |                    |    IP @ and a    |                    |
      |                    |    Port Range    |                    |
      |                    |----------------->|                    |
      |                    |                  |                    |
      |                    |(3) No Available @|                    |
      |                    |                  |                    |
      |                    |<-----------------|                    |
      |                    |                  |                    |
      |                    | (4) DHCP DISCOVER|                    |
      |                    |-------------------------------------->|
      |                    |              (5) DHCP OFFER(IP-Pub-1) |
      |                    |<--------------------------------------|
      |                    | (6) DHCP REQUEST (IP-Pub-1)           |
      |                    |-------------------------------------->|
      |                    |              (7) DHCP ACK(IP-Pub-1)   |
      |                    |<--------------------------------------|
      |                    |                  |                    |
      |                    |(8)Add IP-Pub-1   |                    |
      |                    |  to Ports Range  |                    |
      |                    |    allocation,   |                    |
      |                    |and pre-assign a                       |
      |                    | Port Range to CPE1                    |
      |                    |----------------->|                    |
      |(9)DHCP OFFER(IP-Pub-1, PR1)           |                    |
      |<-------------------|                  |                    |
      |                    |                  |                    |
      |(10)DHCP REQUEST(IP-Pub-1, PR1)        |                    |
      |------------------->|                  |                    |
      |                    |(11) Assign PR1 to|                    |
      |                    |       CPE1       |                    |
      |                    |----------------->|                    |
      |(10)DHCP ACK(IP-Pub-1, PR1)            |                    |
      |------------------->|                  |                    |
      |                    |                  |                    |

                          Figure 6: First Example

   If CPE-2 requests an IP address, it issues a DHCP DISCOVER message.
   This message is not relayed to the DHCP Server.  A lookup request is
   executed by the DHCP Relay to check if an IP address and a Port Range



Boucadair, et al.        Expires April 26, 2009                [Page 19]


Internet-Draft          Provider-Provisioned CPE            October 2008


   are available to be assigned.  In this example, a positive answer is
   sent to the DHCP Relay.  An Offer is then sent to CPE-2 as
   illustrated in Figure 7.

   +-----+              +-----+           +--------+            +------+
   |CPE-2|              |DHCP |           |Binding |            |DHCP  |
   |     |              |Relay|           |Table   |            |Server|
   +-----+              +-----+           +--------+            +------+
      |  (1)DHCP DISCOVER  |                  |                    |
      |------------------->|                  |                    |
      |                    |(2) Check if there|                    |
      |                    |  is an available |                    |
      |                    |    IP @ and a    |                    |
      |                    |    Port Range    |                    |
      |                    |----------------->|                    |
      |                    |                  |                    |
      |                    |(3) OK (IP1)      |                    |
      |                    |                  |                    |
      |                    |<-----------------|                    |
      |                    |                  |                    |
      |                    |                  |                    |
      |                    |(4) Allocate IP1  |                    |
      |                    |and Pre-assign a  |                    |
      |                    |Port Range to CPE2                     |
      |                    |----------------->|                    |
      |(9)DHCP OFFER(IP-Pub-1, PR2)           |                    |
      |<-------------------|                  |                    |
      |                    |                  |                    |
      |(10)DHCP REQUEST(IP-Pub-1, PR2)        |                    |
      |------------------->|                  |                    |
      |                    |(11) Assign PR2 to|                    |
      |                    |       CPE2       |                    |
      |                    |----------------->|                    |
      |(10)DHCP ACK(IP-Pub-1, PR2)            |                    |
      |------------------->|                  |                    |
      |                    |                  |                    |

                         Figure 7: Second Example


4.  Experimentation Results

4.1.  Configuration

   The main functionalities of the Provider-Provisioned CPE solution
   have been validated in a proof-of-concept testbed.  The goal of this
   testbed is to assess the validity of the proposed solution and its
   ability to meet its objectives.  Concretely, hereafter are listed two



Boucadair, et al.        Expires April 26, 2009                [Page 20]


Internet-Draft          Provider-Provisioned CPE            October 2008


   key functionalities which have been implemented:

   1.  The CPE restricts its source ports to be within its assigned Port
       Range.  By the way, direct communications between two CPEs with
       the same IP address (but of course with distinct Port Ranges)
       must be effective and for that purpose the packets must pass
       through the PRR.

   2.  A PRR is positioned to be in the path of all inbound packets
       destined to a shared IP address.  This PRR implements a port-
       driven routing as described in Section 3.6.

   The features relative to the proposed new DHCP options (mentioned in
   Section 3.4 and defined in [ID.boucadair]) have not been part of the
   validation activities which aimed only at validating the fractional
   address concept and checking its transparency to well-known
   applications on Internet.

   For both the CPEs and the PRR, Linux-based PCs have been used.

   As shown in Figure 8, CPEs and the PRR are directly connected via
   Ethernet.  As indicated in Section 3.6.1, other network
   configurations are possible.  This choice is motivated by its
   simplicity in the scope of a proof-of-concept testbed.

   +--------+           +--------+
   |        |           |PC Linux|
   |  user  |           |        |
   |terminal+----Eth-INT|  CPE x |Eth-EXTx----+
   |        |           |        |            |
   +--------+           +--------+            |
                                              | +--------+    +--------+
                                              | |PC Linux|    |Internet|
                        IPv4_public addr      | |        |    |        |
                        set in NAPTs          | |        |    |        |
                         of CPEs              +-|  PRR   +----+        |
                                              | |        |    |        |
                                              | +--------+    +--------+
   +--------+           +--------+            |
   |        |           |PC Linux|            |
   |  user  |           |        |            |
   |terminal+----Eth-INT|  CPE y |Eth-EXTy----+
   |        |           |        |
   +--------+           +--------+

                      Figure 8: Testbed Configuration





Boucadair, et al.        Expires April 26, 2009                [Page 21]


Internet-Draft          Provider-Provisioned CPE            October 2008


4.2.  On the CPE

   As shown in Figure 8, each CPE has two Ethernet interfaces, each one
   being set-up with a private IPv4 address:

   o  Eth INT: interface towards the LAN the CPE serves (where the user
      terminal(s) and possibility server(s) lay).  The private address
      [private addr INT CPE] is assigned to this interface.

   o  Eth EXT: interface towards the PRR; on this interface is set up
      the private address [private addr EXT CPE].

   In the remaining parts of this section, [private addr EXT CPE-x] is
   used to refer to the private address [private addr EXT CPE] of CPE x.

   To force each CPE to send all its outbound IP packets within the
   assigned Port Range, Netfilter features have been configured.  This
   has consisted to configure through iptables commands the NAT already
   embedded in the Linux OS of each CPE, as follows (for CPE x):

   /sbin/iptables -t nat -A POSTROUTING -p tcp -o [Eth_EXT] -j SNAT
   --to-source [IPv4-pub1]:[ports-range-x]

   -- the same line for UDP --

   With:

   o  IPv4-pub1: the public address shared between the CPEs

   o  ports-range-x: the Port Range assigned to CPE x

   Within this testbed, the CPE has none of its two interfaces set-up
   with the shared IP public address.  This latter is ONLY present at
   the NAPT settings level.

4.3.  On the PRR

   To enforce a port-driven routing on PRR, Linux Netfilter capabilities
   have been used.  The inbound packets are marked depending of their
   destination address and destination port.  For example for CPE x, the
   following command is executed:

   /sbin/iptables -t mangle -A PREROUTING -p tcp --destination [IPv4-
   pub1] --dport [ports-range-x] -j MARK --set-mark [x]

   -- the same line for UDP --

   In the Linux Netfilter configuration, this [x] marking is associated



Boucadair, et al.        Expires April 26, 2009                [Page 22]


Internet-Draft          Provider-Provisioned CPE            October 2008


   with a routing table dedicated for the [x] marked packets.  This
   table contains only one entry: the one pointing to the private
   address of the CPE x (private addr EXT CPE-x).

   Of course in the PRR, there is a mark setting line (as shown above)
   along with the corresponding routing table for each of the CPEs the
   PRR serves.

   This kind of marking is purely at Netfilter level and stays within
   the Linux OS of PRR.  It does not entail any marking of IP packets
   over Ethernet.

   Therefore the operations at the PRR are quite simple.  Upon an
   inbound packet coming at the outside interface of the PRR (e.g.
   Coming from Internet):

   o  At pre-routing level in the PRR, the packet is marked as shown
      above.  The marking depends on the destination address and on the
      Port Range in which the destination port falls;

   o  Owing to this mark (i.e. [x] for CPE x), the packet passes through
      a routing table which points to the private address of the CPE x
      (private addr EXT CPE-x).  This private address is seen by the PRR
      as the first hop of the route towards CPE x.  The PRR proceeds to
      an ARP (Address Resolution Protocol) resolution (if not already
      achieved previously) and matches the [private addr EXT CPE-x] with
      the MAC (Media Access Control) address of EXT CPE x;

   o  Then, the packet is encapsulated into an Ethernet frame and
      transmitted to EXT CPEx.

   Inbound packets have not been at all tempered by the PRR.
   Particularly, the destination IP address is always the shared public
   IP address of CPE x.

4.4.  Main Results

   This testbed has been used to conduct various tests.  The objectives
   of those tests were to validate the concept of the Provider-
   Provisioned CPE solution, in particular its transparency to well-
   known applications.  Indeed, the following applications have been
   selected and their behaviour evaluated: Web browsing (HTTP), FTP,
   Email, Instant messaging (two well-known applications have been
   used), Peer-to-Peer (again two well-known applications) and Voice
   over IP (an application which does not require an ALG on the CPE has
   been tested).

   Obtained results confirmed the validity of the Provider-Provisioned



Boucadair, et al.        Expires April 26, 2009                [Page 23]


Internet-Draft          Provider-Provisioned CPE            October 2008


   CPE solution: Web browsing (HTTP), Email and Instant messaging work
   normally and no degradation have been experienced.

   For Peer-to-Peer applications to be fully operational when launched
   inside terminals behind CPEs, we needed to manually set up a port
   forwarding at the CPE NAT.  This is generally already the case today
   for users whose machines do not harness UPnP or whose CPE is not UPnP
   IGD (Internet Gateway Device) enabled.  With "Provider-Provisioned
   CPE" solution the CPE implementation would need to take care that
   manual port forwarding be only possible in the allocated Port Range
   (e.g. through Web settings menus slightly amended).  As for UPnP,
   further considerations are needed to assess whether the current
   version of UPnP IGD can allow the CPE to allocate a port different
   from the one the terminal has requested.

   For one P2P (Peer-to-Peer) application tested, we found that two
   peers each behind a CPE sharing the same public address cannot
   download a SAME file from a source peer.  The reason is certainly
   that the source peer relies on the IPv4 address and therefore
   considers the two downloading peers as a unique peer and does not
   accept parts of a file to be sent to the same peer over two different
   ports.  Such limitation comes from the very principle of sharing an
   IP address (and not from the "Provider-Provisioned CPE" concept).  We
   may think that other applications on Internet react in such way.

   As for FTP, the passive mode works also well.  Active mode does not
   but this is not because of the Provider-Provisioned CPE concept but
   only because the FTP active mode does not pass naturally well the
   NAPT (even a plain NAPT without Port Range restriction).

   An FTP server has also been installed and launched on a PC behind a
   CPE.  We set up manually ports forwarding at the CPE NAT so that to
   allow inbound connections.  A FTP client (on another machine)
   succeeded to connect normally to the FTP server provided the client
   specifies the address AND port of the server when launching the
   connection.  This proves that the solution allows servers behind Port
   Range restricted CPEs.  Further investigation may be undertaken such
   as using DynDNS and SRV records to retrieve the port number to be
   used for FTP service.

   Tests were also made when the client and the server are each behind a
   CPE sharing the same address.  Again that worked also (the
   communication passes through the PRR).  That shows that there is no
   restriction for communications between two CPE sharing the same IP
   address.






Boucadair, et al.        Expires April 26, 2009                [Page 24]


Internet-Draft          Provider-Provisioned CPE            October 2008


4.5.  Conclusion

   The conclusion of this implementation is that the two key features of
   the "Provider-Provisioned CPE" solution (namely: Port Range
   restriction at CPE and port-driven routing at PRR) are already
   provided in Linux OS.  It is expected that the necessary enhancements
   on other types of CPE plus the mechanism described in Section 3.5
   should be rather simple modifications in the CPE.  This is the same
   thing for the PRR: deriving a PRR from existing routing equipments
   should be rather simple.  It may be even that, on some existing
   routers, policies based settings already implemented could perform
   the port-driven routing.

   In addition, the various functional tests we have performed on the
   testbed have assessed completely the validity of the solution.


5.  Comparison with CG-NAT

5.1.  Generic Hurdles  and Focus on Transparency to applications which
      enclose IPv4 address in their protocol messages

   When deploying a Double NAT scenario, several hurdles will be
   encountered by Service Providers.  Examples of these hurdles are as
   follows:

   o  End-users won't be able to configure their own port forwarding
      policies anymore;

   o  Need to activate a second ALG (Application Level Gateway) at the
      core network for some applications (e.g.  SIP (Session Initiation
      Protocol, [RFC3261]);

   o  Problems to run servers behind middleboxes with private addresses;

   o  Complication to enable inbound access;

   o  Performance issues;

   o  Interference between the service and network layers: The delivery
      of some services (e.g.  SIP, DNS (Domain Name Service, [RFC1034]),
      and FTP (File Transfer Protocol, [RFC3659])) will require the
      knowledge of the underlying network engineering characteristics
      (i.e.  Presence of intermediate CG-NAT boxes).  If distinct
      administrative entities are managing the high-level services and
      the underlying IP infrastructure, critical problems for the
      current Internet business model will be raised.




Boucadair, et al.        Expires April 26, 2009                [Page 25]


Internet-Draft          Provider-Provisioned CPE            October 2008


   Beside these generic hurdles, let's consider the ones that may arise
   when delivering SIP-based calls in the presence of CG-NAT boxes.
   Concretely, the following constraints should be followed:

   o  The SIP-based Service Provider should be aware about the
      underlying IP infrastructure so as to implement appropriate ALGs
      (Application Level Gateway).  At least two modifications of SIP
      messages should be applied: The first one at the Home NAT and the
      second one at the CG-NAT.  If no such ALG is enabled, no
      communication may be established.  This constraint is heavy since
      it assumes that the same administrative entity administers both
      service and network infrastructures.

   o  NAT mapping entries at the CG-NAT should be maintained by keep-
      alive packets so as to be able to deliver incoming messages to
      customers' devices located behind the CG-NAT.

   o  Media flows may encounter some problems to be delivered since RTP
      (Real Time Transport Protocol, [RFC1889]) ports may not be opened.

   The introduction of CG-NAT nodes may impact heavily the delivery of
   SIP-based services.

   With Port Range approach, nothing is changed with regard to the
   behavior of a today CPE with NAT: a SIP ALG can be quite easily
   implemented to take care of swapping the embedded IP address and port
   number in the messages to reflect the outbound IPv4 address and port
   of the CPE.  On the contrary, running a SIP ALG instance inside the
   Carrier-Grade NAT for each SIP client may turn out to be very
   complex.  Therefore, with the Port Range approach, SIP-based services
   are not altered compared to current practices when a CG-NAT is
   present in the path.  The same mechanisms as today have to be
   deployed without any additional constraint nor impact.

   Consequently, SIP-based services are not altered and complexity not
   increased.

5.2.  Focus on Legal Storage

   Most of National Regulatory Authorities (NRA) requires that ISPs
   provide the identity of a customer upon request of the authorities.
   This requirement is usually denoted as Legal Storage.  In order to
   implement this requirement, Service Providers have deployed
   appropriate infrastructures including memory storage and interface to
   their Information Systems.  Due to the continuous increase of traffic
   exchanged between end users, the amount of data stored by Service
   Providers would be also impacted if data relevant to all the sessions
   were to be stored.  This is considered as a critical issue by Service



Boucadair, et al.        Expires April 26, 2009                [Page 26]


Internet-Draft          Provider-Provisioned CPE            October 2008


   Providers.

   When deploying a new IP architecture or when modifying the currently
   deployed ones, Service Providers should be able to assess its impact
   on their Legal Storage infrastructures.  Concretely, and because of
   the presence of NAPT function the knowledge of the source port number
   (simply referred to as port number), along with the source public IP
   address (simply referred to as public IP address), is mandatory to be
   able to retrieve the appropriate customer (or user) which is
   concerned by a given flow.  This implies that all NAT mapping
   information is to be stored by a given ISP during the whole legal
   duration (one year in many countries).

   Concretely, and because of the presence of NAPT function (in the CG-
   NAT), the knowledge of the source port number (simply referred to as
   port number), along with the source public IP address (simply
   referred to as public IP address), is mandatory to be able to
   retrieve the appropriate customer (or user) which is concerned by a
   given flow.  This implies that all NAT mapping information is to be
   stored by a given ISP during the whole legal duration (one year in
   many countries).

   When a CG-NAT is deployed, a given Service Provider must store legal
   information of the mapped addresses in form of the following tuple:

   {Public IP address - Public Port - Private IP address - Private port
   - protocol - date and hour of the beginning of address/port
   allocation - duration of this allocation (or date and hour of the
   allocation end)}.

   Note that to actually find the identity of the appropriate customer
   which is concerned by a given IP flow, a given ISP must also store
   the mapping between the private IP address and the customer
   identification.

   As for the Provider-Provisioned CPE approach, the required
   information to be stored is the following tuple (called in the
   remaining part tuple with Port Range):

   {Public IP address - Port Range - protocol - customer identification
   - date and hour of the beginning of the Public IP address and Port
   Range allocation - duration of this allocation (or date and hour of
   the allocation end)}.

   The length of this tuple with Port Range is about:

   4 + 3 (2 for the Port Range pattern + 1 for the length) + 20
   (customer identification) + 8 (date/time begin) + 8 (date/time end) =



Boucadair, et al.        Expires April 26, 2009                [Page 27]


Internet-Draft          Provider-Provisioned CPE            October 2008


   43 bytes.

   The Port Range is expected to be allocated for the same duration as
   the IP address, namely for a reasonable term (e.g. more than 24 hours
   conforming to current practices of IP address assignment).  Thus,
   with regard to the nowadays situation, the additive information to be
   stored is only the Port Range.

   The allocation of Public IP address and Port Range is expected to be
   made for a reasonable term (e.g. more than 24 hours) as the current
   practices for the assignment of IP addresses.

   In order to illustrate the volume of required data to be stored by
   Service Providers,let's consider the following figures:

   o  1000 CPEs

   o  100 new sessions per 10 minutes per CPE (optimistic, it may be
      more)

   o  each CPE traffics during 6 hour a day

   o  the public address and Ports Range change each day (changing these
      parameters may be even less frequent)

   The amount of data to be stored per month when the Provider-
   Provisioned CPE approach is enabled (i.e. use of a Port Range) is
   around 1,3 Mbytes.  The one for CG-NAT is around 3,1 Gbytes (Gbytes
   and not Mbytes) per month.

   - Provider-Provisioned CPE:

   Amount for 1000 CPEs per month = 1000 (CPEs) * 43 (bytes for the
   tuple with Port Range) * 30 (days in a month) = 1,3 Mbytes

   -CG-NAT:

   {Public IP address - Public Port - Private IP address - Private port
   - protocol - date and hour of the beginning of address/port
   allocation - duration of this allocation (or date and hour of the
   allocation end)}

   = 4 + 2 + + 4 + 2 + 1 + 8 + 8

   = 29 bytes.

   Note : Storing the customer identification attached to the private
   address is considered negligible in the calculation.



Boucadair, et al.        Expires April 26, 2009                [Page 28]


Internet-Draft          Provider-Provisioned CPE            October 2008


   Amount for 1000 CPEs per month

   = 1000 (CPEs) * 100 (number of new sessions in 10 mn) * 36 (number of
   10 mn durations in 6 h) * 29 (number of bytes per session) * 30 (days
   in a month)

   = 3,1 Gbytes

   Based on this data, a factor of more than 1000 is to be observed
   between the two solutions (in favor of the Port Range approach).

   This factor (i.e. ratio of 1000) is important to be taken into
   account since CAPEX and OPEX would be impacted drastically for the
   implementation of this legal requirement.  Indeed, a large investment
   must be forecast(ed) for deploying a suitable infrastructure (e.g.
   physical nodes and storage capacity).  Service Providers should
   carefully consider this impact on their legal storage
   infrastructures.

   Moreover, as the deployment of the FTTH (Fiber To The Home) will
   progress it is expected that the number of sessions per user will be
   growing which will further increase the amount of data to be stored
   in CG-NAT but not in the Port Range approach.

5.3.  Sessions Handling in CG-NAT

   The complexity of the real-time processing is related to the number
   of operations to handle the TCP and UDP sessions and associated
   complexity.

   CG-NAT is a NAT and therefore has to monitor dynamically all the
   sessions in order to identify if a public port number is still in-use
   or can be released.  For this purpose, a CG-NAT needs in particular
   to handle timeouts and to scrutinize all TCP sessions states.  In
   addition the entries enclosed in the NAT table maintained by a given
   CG-NAT is of a much greater complexity than the table in the PRR.
   The CG-NAT needs to keep all the mappings [Public IP address - Public
   Port - protocol - Private IP address - Private Port] for each session
   (UDP or TCP) whilst the PRR has to keep only one entry [Public IP
   address - Port Range - route to the CPE] per CPE.

   For example, if the CPE handles 100 active sessions, the factor is
   100 between a CG-NAT and a PRR.  For a CPE with 1000 active sessions
   (which may not be so rare for clients making high use of peer to peer
   applications) the factor raises to 1000.  Again, this is not simply a
   matter of factor; with CG-NAT, handling a session is complex as
   already indicated (e.g. timeouts, scrutinizing of sessions states,
   NAT entries real time maintenance, etc.).



Boucadair, et al.        Expires April 26, 2009                [Page 29]


Internet-Draft          Provider-Provisioned CPE            October 2008


   As for the PRR, it does not handle sessions but simply routes packets
   (routing based on both IP address and Port Range).

   CG-NAT can either be used in a context where the CPE keeps its NAT
   (yielding a double NAT configuration) or in a configuration where the
   CPE is a mere router (or bridge) without any NAT.  In the first case
   (i.e.  CPE without NAT) there is only one level of NAT in the path
   (at the CG-NAT level).  All the complexity, today distributed among
   the CPEs, becomes concentrated into CG-NAT equipment.  The cost of
   the CG-NAT is not balanced by a relative simplification of the CPEs
   (no NAT embedded).  In a double NAT configuration the relative
   simplification of the CPE (no NAT embedded) is not even attained.

5.4.  Peer-to-Peer applications

   P2P applications can not work at full capabilities when a CG-NAT is
   in the path.  This is because the peers cannot place entering
   connections toward a peer behind a CG-NAT.  Consequently the
   communications must pass through a server which greatly reduces the
   throughput capabilities of the system.  A palliative could be for P2P
   applications to use a STUN server so that they can know the public
   address and port allocated by the CG-NAT and to keep alive the port
   (by periodical short messages).

   There is not such problem with the Port Range approach where the user
   can still as today set manually the port forwarding policies onto his
   CPE (e.g.  Through WEB page, provided the choice of the port were
   restricted to the allocated Port Range, etc.).

5.5.   Position in a context of future IPv6 deployments

   TBC


6.  IANA Considerations

   TBC.


7.  Security Considerations

   This section will be completed in the next version of this draft.


8.  Acknowledgements

   The authors would like to thank Yoann NOISETTE, for his extensive
   review and technical input, and Mohammed Kassi Lahlou for his



Boucadair, et al.        Expires April 26, 2009                [Page 30]


Internet-Draft          Provider-Provisioned CPE            October 2008


   suggestion regarding the involvement of the DHCP client relay.  We
   would also like to thank Pierrick MORAND and Mohammed ACHEMLAL for
   their support and suggestions.


9.  References

9.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC1889]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", RFC 1889, January 1996.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3659]  Hethmon, P., "Extensions to FTP", RFC 3659, March 2007.

9.2.  Informative References

   [ID.240space]
               Fuller , V.,  Lear , E., and D.  Meyer , "Reclassifying
              240/4 as usable unicast address space", March 2008.

   [ID.arkko]
              Arkko, A. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-
              Existence Scenarios", Work in progress: Internet
              Drafts draft-arkko-townsley-coexistence-00.txt, September
               2008.

   [ID.bajko]



Boucadair, et al.        Expires April 26, 2009                [Page 31]


Internet-Draft          Provider-Provisioned CPE            October 2008


              Bajko, G. and T. Savolainen , "Dynamic Host Configuration
              Protocol (DHCP) Options for Port Restricted IP Address
              Assignment", September 2008.

   [ID.boucadair]
              Boucadair, M., "DHCP Options for conveying Port Mask and
              Port Range Router IP Address".


Authors' Addresses

   Mohamed Boucadair (editor)
   France Telecom
   42 rue des Coutures
   BP 6243
   Caen Cedex 4  14066
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Jean-Luc Grimault
   France Telecom

   Email: jean-luc.grimault@orange-ftgroup.com


   Pierre Levis
   France Telecom

   Email: pierre.levis@orange-ftgroup.com


   Alain Villefranque
   France Telecom

   Email: alain.villefranque@orange-ftgroup.com














Boucadair, et al.        Expires April 26, 2009                [Page 32]


Internet-Draft          Provider-Provisioned CPE            October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Boucadair, et al.        Expires April 26, 2009                [Page 33]