<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
     docName="draft-levis-behave-ipv4-shortage-framework-02.txt"
     ipr="trust200811">
  <front>
    <title abbrev="IPv4 Address Shortage">IPv4 Address Shortage: Needs and
    Open Issues</title>

    <author fullname="Pierre Levis" initials="P." role="editor"
            surname="Levis">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street>42 rue des Coutures</street>

          <street>BP 6243</street>

          <city>Caen Cedex 4</city>

          <code>14066</code>

          <country>France</country>
        </postal>

        <email>pierre.levis@orange-ftgroup.com</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <email>mohamed.boucadair@orange-ftgroup.com</email>
      </address>
    </author>

    <author fullname="Jean-Luc Grimault" initials="JL." surname="Grimault">
      <organization>France Telecom</organization>

      <address>
        <email>jeanluc.grimault@orange-ftgroup.com</email>
      </address>
    </author>

    <author fullname="Alain Villefranque" initials="A." surname="Villefranque">
      <organization>France Telecom</organization>

      <address>
        <email>alain.villefranque@orange-ftgroup.com</email>
      </address>
    </author>

    <date month="June" year="2009" />

    <keyword>Internet-Draft</keyword>

    <keyword>IPv4 shortage</keyword>

    <abstract>
      <t>This document analyses the main issues related to IPv4 Internet
      access in the context of public IPv4 address exhaustion.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>Taking into consideration the IPv4 public address pool currently
      available at the Internet Assigned Numbers Authority (IANA), it is
      expected that the Regional Internet Registries (RIRs) will have no more
      public IPv4 addresses to allocate in the short term. At the time of
      writing, this foreseen date is mid-2012. See the IPv4 Address Report
      website (available at http://www.potaroo.net/tools/ipv4/index.html) for
      a thorough analysis of this issue, and an updated prediction.</t>

      <t>This exhaustion phenomenon has been anticipated for a long time by
      the IETF, with the specification of the IPv6 protocol as the IPv4
      successor. IPv6 increases the IPv4 addressing space by a power-of-four
      factor. IPv6 specifications are mature and current standardization
      effort is exclusively dedicated to operational aspects. Unfortunately,
      IPv6 was not devised as backwards compatible with IPv4; it is not
      possible to have IPv6-based applications directly exchange IP packets
      with their IPv4-based counterparts. The expected transition process was
      to assume hosts and routers will be Dual-Stack, that is, will support
      the two distinct protocol families IPv4 and IPv6, and to wait until the
      entire Internet supports Dual-Stack connectivity to deprecate IPv4. More
      than a decade later, IPv4-only communications are still the norm, and
      IPv6 is still rather marginal. ISPs will need to continue to provide
      IPv4 Internet access to their customers at the exhaustion date, if they
      do not want to see their business completely stalled or decreasing. They
      will wind up with public address pools that cannot grow. They will have
      to adapt to this situation, and enter an IPv4 address shortage
      management phase.</t>

      <t>This document analyses the main issues related to IPv4 Internet
      access in the context of public IPv4 address exhaustion. Another
      complementary study can be find in <xref
      target="I-D.ford-shared-addressing-issues"></xref>.</t>
    </section>

    <section title="Shared IPv4 Addresses">
      <t>So far, the current practice (particularly for fixed service
      offering) has been to give a unique IPv4 public address to each
      customer. A common design is to assign this global IPv4 address to the
      Customer Premises Equipment (CPE), and to assign IPv4 private addresses
      to the hosts connected behind the CPE. A private to public (and vice
      versa) translation occurs in the CPE owing to the activation of a
      Network Address and Port Translator (NAPT) function <xref
      target="RFC3022"></xref>. In this context, the public addresses that can
      be seen in any IP packets always refer to a unique customer. To cope
      with the IPv4 address exhaustion, this kind of practices is no more
      affordable. Therefore, ISPs are bound to share the same IPv4 public
      address among several customers at the same time.</t>

      <t>All IPv4 address shortage mechanisms extend the address space in
      adding port information. We call them by the generic name of IPv4
      shortage solutions, or shared address solutions. IPv4 shortage solutions
      differ on the way they manage the port value. In this new context, a
      public IPv4 address seen in an IP packet can refer to several customers.
      The port information must be considered as well, in order to be able to
      unambiguously identify the customer pointed by that shared address. In
      particular, the port information along with the address information,
      must eventually be taken into account in order to correctly reach the
      intended destination.</t>
    </section>

    <section title="Solution Space">
      <section title="CGN-based Solutions">
        <t>These solutions propose the introduction of a NAPT function in the
        ISP network, denoted also as Carrier Grade NAT (CGN), or Large Scale
        NAT (LSN) <xref target="I-D.nishitani-cgn"></xref>, or Provider NAT.
        The CGN is responsible for translating private addresses to publicly
        routable addresses. Private addresses are assigned to customers, a
        pool of public addresses is assigned to the CGN, the number of public
        addresses is much smaller than the number of customers. A public
        address of the CGN pool will therefore be shared by several customers
        at the same time.</t>

        <t>Packet processing is as follows (for port-based
        communications):<list style="symbols">
            <t>Outgoing packets from an internal host to an Internet host: the
            internal host sends a packet with a private IPv4 source address.
            This packet goes up to the CGN, possibly after a first private to
            private address translation in the CPE, the CGN dynamically
            replaces the private source address by a public source address and
            modifies the source port value. The CGN creates an entry in its
            NAT mapping (or binding) table for each new mapping. Dynamic
            mappings can only be created by outgoing packets.</t>

            <t>Incoming packets from an Internet host to an internal host: the
            remote host sends a packet with a destination address within the
            CGN public address pool. If, and only if, a mapping already exists
            for the (destination address, destination port, protocol) tuple,
            the CGN can reverse the mapping and forward the packet towards the
            internal side. However, even if this mapping exists, the CGN may
            discard the packet due to a particular filtering policy. If no
            mapping exists for the (destination address, destination port,
            protocol), the CGN discards the packet.</t>
          </list></t>

        <t>CGN-based solutions can be deployed in different network
        configurations. One outstanding flavor is the DS-lite CGN <xref
        target="I-D.ietf-softwire-dual-stack-lite"></xref>: there is no NAT in
        the CPEs, IPv6 addresses (or prefixes) are assigned to CPEs, no IPv4
        addresses are assigned to CPEs, traffic is tunnelled between CPEs and
        the DS-lite CGN into IPv6.</t>
      </section>

      <section title="A+P Solutions">
        <t>These solutions avoid the presence of a CGN function. They assign
        the same IP public address to several customers at the same time
        (shared address). They also assign a restricted port range to each
        customer so that two customers with the same IP address have two
        different port ranges that do not overlap. These solutions are called
        A+P (Address+Port) <xref target="I-D.ymbk-aplusp"></xref>, or Port
        Range <xref target="I-D.boucadair-port-range"></xref>, or SAM
        (Stateless Address Mapping) <xref target="I-D.despres-sam"></xref>.
        These solutions introduce a new function in the ISP network called
        Port Range Router (PRR).</t>

        <t>Packet processing is as follows (for port-based
        communications):<list style="symbols">
            <t>Outgoing packets from an internal host to an Internet host: the
            internal host sends a packet with its public shared address as the
            source address and a source port within his dedicated port range
            (the internal host may also send a packet with a private address,
            and then a NAPT in the CPE forces the source port to be within the
            port range and translates the private source address into the
            shared public address allocated). No specific handling is
            necessary in the ISP network, apart from the traditional IP
            routing process. In order to allow internal communications (within
            the same ISP realm), the outgoing packets have however to go up to
            the device that embeds the PRR function, but the packet will be
            processed by this PRR, if and only if, the PRR handles the
            destination subnet.</t>

            <t>Incoming packets from an Internet host to an internal host: the
            remote host sends a packet with a shared destination public
            address. Owing to routing protocol advertisements, this packet is
            routed up to the PRR that handles this address subnet. The PRR is
            in charge to find a route towards the actual internal
            correspondent -for instance, CPEs have setup PPP sessions with the
            PRR, the PRR maintains a binding table between (IPv4 address, Port
            Range) couples and PPP session IDs-. The PRR that handles the
            shared address of a user must be in the data path of any packet
            intended to that user.</t>
          </list>Port range solutions are sometimes described as a CGN
        function that would have been distributed among the CPEs. This is not
        false, but may be a rather misleading view, in the sense that it would
        assume CGN has not disappeared but simply melt into the CPEs, and
        that, to some extent, it is still CGN. Actually, the very purpose of
        A+P solutions is to completely get rid of any CGN function. One main
        interest of A+P solutions is that PRR devices are simple equipment
        which, unlike CGN devices, have no per-user session processing, and do
        not modify packet headers. Thus, PRR performance should not be an
        issue.</t>
      </section>

      <section title="Common Architecture">
        <t>To provide a common architecture, we introduce the SHared Ip
        Processor (SHIP) function embedded in a SHIP device. A SHIP device can
        host either a CGN function or a PRR function, or both. In the latter
        case, some traffic is CGN-processed (outgoing and incoming packets),
        some is PRR-processed (incoming packets). There can be several SHIP
        devices in the same ISP network.</t>

        <figure align="center" title="Shared Address Architecture">
          <artwork><![CDATA[                             (3)
    (1)                 +----------+
+---------+             |          |
|         |    (2)      |          |              +-----------------+
|Host/CPE |-------------|   SHIP   |--------------|THE IPv4 INTERNET|
|         |             |          |              +-----------------+
+---------+             |          |
                        +----------+]]></artwork>
        </figure>

        <t>This architecture is composed of the following elements:</t>

        <t>(1) The hosts are directly connected (e.g. mobile terminal), or
        connected through a CPE. For PRR-based solutions, packets are sent
        with source ports within their allocated Port Ranges. A Host/CPE must
        know a SHIP device to which it can send its traffic.</t>

        <t>(2) The network infrastructure between CPEs and PRR:<list
            style="symbols">
            <t>Ensures outgoing packets are routed up to the SHIP device;</t>

            <t>Ensures incoming packets are routed up to the intended
            Host/CPE.</t>
          </list></t>

        <t>(3) The SHIP device may:<list style="symbols">
            <t>Translate (NAPT) outgoing and incoming packets for
            CGN-processed traffic (CGN function only);</t>

            <t>Find a route to incoming packets for PRR-processed traffic (PRR
            function only).</t>
          </list>Many architectural issues are common to all IPv4 shortage
        solutions, whether they rely on the presence of a CGN or a PRR.
        Including, for instance, means to ensure proper routing between
        customers and SHIP devices, and SHIP devices location. Therefore, it
        does make sense to describe and specify all solutions on a concerted
        basis, and not in completely separate ways.</t>
      </section>
    </section>

    <section title="Address Space Multiplicative Factor">
      <t>The purpose of sharing public IPv4 addresses is to potentially
      increase the addressing space. A key parameter is the factor by which
      ISPs want or need to multiply their IPv4 public address space; and the
      consequence is the number of customers sharing the same public IPv4
      address. This parameter is called the address space multiplicative
      factor, the inverse is called the compression ratio.</t>

      <t>It is expected that IPv6 traffic will take an increasing part during
      the next years to come, at the expense of IPv4 traffic. We should reach
      a safety point in the future, where the number of IPv4 public addresses,
      in use at the same time, begins decreasing. From an ISP point of view,
      the multiplicative factor must be enough to survive until this event
      occurs for its own customers.</t>

      <t>The multiplicative factor can only be applied to the part of
      customers that is eligible to shared address. The reasons a customer
      cannot have a shared address can be:<list style="symbols">
          <t>It would not be compatible with the service he has currently
          subscribed to (for example: business customer).</t>

          <t>His CPE does not allow the solution selected by the ISP (for
          example it does not handle port restriction for PRR-based solutions
          or it does not allow IPv4 in IPv6 encapsulation for DS-lite
          solution), and its replacement is not easy.</t>
        </list></t>

      <t>Different ISPs may have very different needs. A long-lived ISP, whose
      number of customers is rather stable, will have an existing address pool
      that will only need a small extension to cope with the next years to
      come (small multiplicative factor, less than 10). A new comer will need
      a much bigger multiplicative factor (e.g. 1000). A mobile operator may
      see its address need explode if the IP mobile handset market
      dramatically grows, with Internet 3G access and Internet wireless
      (Wi-Fi/WiMAX) hotspot access.</t>

      <t>The multiplicative factor is an important criterion in order to
      select a solution. When the multiplicative factor is large, the average
      number of ports per customer is small; in that case, it is essential to
      manage port attribution the closest to the need as possible, and to
      avoid to dedicate ports to people who do not use them, when other people
      are running out of ports. Then, the larger the multiplicative factor is,
      the more dynamic the port assignment has to be.</t>

      <t>CGN solutions provide the most dynamic port assignment scheme, hence
      the best possible ratio. However, CGNs can also be produced with
      functionalities that reduce their dynamicity; for instance, a port range
      can be attributed to each user, the CGN mapping is constrained into this
      range, in order, for example, to ease legal storage. As for A+P
      solutions, their dynamicity can vary a lot, depending on the Port Range
      assignment policy. Port Ranges can be assigned in a complete static way;
      one Port Range is assigned once and for all to each customer, no port
      can be added in, or removed from, the attributed Range. On the opposite,
      Port Range assignment can be fully dynamic; small Port Ranges (possibly
      up to one port) are dynamically assigned and removed.</t>

      <t>Whatever the multiplicative factor selected, one must keep in mind
      that trying to deploy solutions that increase the IPv4 space by a big
      factor, might be seen as an incentive to postpone again and again IPv6
      deployment.</t>
    </section>

    <section anchor="Section_5" title="Number of Current Sessions">
      <t>In any kind of solutions, the number of current sessions per customer
      has, de facto, to be limited in some way. Therefore, the number of
      current sessions per customer is a limit to take into account in any
      architectural dimensioning. According to <xref target="RFC2663"> </xref>
      terminology: "A session is defined as the set of traffic that is managed
      as a unit for translation. TCP/UDP sessions are uniquely identified by
      the tuple of (source IP address, source TCP/UDP port, target IP address,
      target TCP/UDP port)".</t>

      <t>A CGN must sustain the traffic that will occur in its location point
      at the most loaded time, in terms of number of current sessions, and
      number of new sessions per second (i.e. when these parameter values are
      the highest). A Port Range solution should be less sensitive than a CGN
      to session rate and number, because a PRR is a per-user, and not a
      per-session, process.</t>

      <t>UDP sessions and TCP sessions are separately handled in a CGN (a CGN
      mapping incorporates the protocol value); it is as if the same public
      IPv4 address pool was allocated twice: once for the TCP communications
      and once for the UDP communications (of course other Transport protocols
      may be taken into account such as SCTP or DCCP). Therefore, the number
      of public addresses needed in a CGN will be driven by the type of
      communications -TCP or UDP- which consumes the highest number of public
      addresses. This consumption depends on the number of current sessions.
      Actually, for a Full Cone CGN (Endpoint-Independent Mapping and End
      point-Independent Filtering <xref target="RFC4787"></xref>), the address
      consumption should directly depend on the number of current couples
      (customer source address, customer source port) rather than on the
      number of current sessions.</t>

      <t>For the same traffic conditions, a Port Range solution should need
      more addresses than a CGN. Let's assume, for the sake of simplicity,
      that port range allocation is a static one-size fits all. The range size
      should not only cover the average number of current sessions per user at
      peak time, but should also take into account the distribution of
      sessions, and should be significantly larger than the average if the
      standard deviation is large. So, where a CGN consumes no more ports than
      the number of current sessions, a Port Range solution, due to the
      attribution of ports by blocks, consumes more ports, and thus more
      addresses.</t>

      <t>The IPv6 increasing deployment should have a decreasing effect on the
      number of current IPv4 sessions per customer. If the percentage of
      end-to-end IPv6 traffic significantly increases, so that the volume of
      IPv4 traffic begins decreasing, then the number of IPv4 sessions will be
      decreasing. The smaller the number of current IPv4 sessions per customer
      is, the higher the number of customers under the same IPv4 public
      address can be (better compression ratio), and consequently, the lower
      the number of IPv4 public addresses is needed. Hence, the pressure on
      IPv4 address shortage would be relaxed, because one IPv4 public address
      would be able to potentially serve more customers. However, this effect
      will only occur for customers who have both an IPv6 access and a shared
      IPv4 access. This advocates the strategy to systematically bound a
      shared IPv4 access to any IPv6 access. It is difficult to foresee to
      what extent the IPv6 traffic will decrease the number of current IPv4
      sessions, but in any case, IPv6 activation should increase the potential
      IPv4 multiplicative factor. If it does not, that means IPv6 does not
      take over IPv4.</t>

      <t>As for the current usage of ports, several hundreds as peak numbers
      per customer, seems current practice, although several thousands may be
      not unusual with some P2P applications (e.g. BitTorrent). The degree of
      fairness -balanced distribution of sessions between customers-, traffic
      loss due to the limitation in number of sessions, may vary according to
      the traffic conditions, and the policy enforced. The knowledge of the
      distribution of sessions among a set of users, makes it possible to know
      how many users might be adversely affected if/when system limits are
      reached. However, it is surely not that straightforward to really assess
      the degradation the customers should experience, from the knowledge of
      their session number limitations.</t>
    </section>

    <section title="Service Management">
      <t>At the time of IPv4 address exhaustion in the RIRs, ISPs will have to
      manage public address pools that cannot grow (at least from the RIRs).
      Concretely, they will have to decide to whom they allocate shared
      addresses and to whom they allocate unique public addresses, to the
      extent of the availability of addresses. Many policies can be envisaged,
      taking into account parameters such as: old vs. new customers, user
      profile, access type, geographic considerations, unique address as the
      privileged choice, shared address as the privileged choice, etc.</t>

      <t>Care must be taken when considering the ratio that reflects the
      number of customers who will share a given global IPv4 address, not only
      to preserve some flexibility on the global address space that is left,
      but also to make sure that the ISP can adequately serve customer's
      requirements, without degrading the services they have subscribed to.
      ISPs can adjust the volume of IPv4 public addresses available playing on
      the balance between shared and unique allocations. <list style="symbols">
          <t>To increase the public IPv4 address pool: increase the number of
          customers with shared address; increase the ratio of customers per
          shared address.</t>

          <t>To decrease the public IPv4 address pool: decrease the number of
          customers with shared address; decrease the ratio of customers per
          shared address.</t>
        </list></t>
    </section>

    <section title="IPv6 Migration and IPv4-IPv6 Coexistence">
      <t>IPv6 is the only solution to solve the IPv4 public address
      exhaustion, that is, to actually get rid of the limitation on the number
      of IP addresses. IPv4 shared addresses are not candidate to IPv6
      replacement. However, we should be very careful; whatever the network
      model deployed, applications and business will run on top of it. If we
      do not want to see IPv4 address shortage mechanisms postpone IPv6
      deployment, all Internet actors must adopt a voluntary position towards
      IPv6.</t>

      <t>Any IPv4 address shortage solution should make use, as much as
      possible, of the IPv6 transport capabilities available, in order to
      increase the IPv6 traffic and to move forward from an IPv4-enabled ISP
      network towards an almost IPv6-only ISP network. If it is not the case,
      the risk is to delay IPv6 operational deployments, in staying on a pure
      Dual-Stack attitude for ever, similar to the ships in the night routing
      approach, where the protocols independently live their own lives. IPv4
      in IPv6 tunnels, and/or NAT64 and NAT46 translations should be favored.
      However, increasing the number of IPv6 packets does not automatically
      mean IPv6 is being generalized, if the main purpose of these packets is
      to carry IPv4 information. This is very similar to what occurred with
      ATM, especially in European countries, where ATM cells have heavily been
      used to convey IPv4 packets in the backhaul networks, but have never
      been used for end-to-end communications!</t>

      <t>Some public IPv4 addresses will be required to connect IPv4 and IPv6
      realms, through IPv4-IPv6 translators, for the sake of global
      reachability.</t>

      <t>IPv4 shortage solutions may interfere with exiting IPv4 to IPv6
      transition mechanisms, which were not designed with IPv4 shortage
      considerations. With A+P for instance, incoming 6to4 packets should be
      able to find their way from a 6to4 Relay up to the appropriate 6to4 CPE
      router, despite the lack of direct port range information (UDP/TCP
      initial source port did not pass through the CPE Port Range NAT
      translation process). One solution would be that a 6to4 IPv6 address
      embeds not only an IPv4 address but also a Port Range value.</t>
    </section>

    <section title="Network Addressing Capability">
      <t>The network addressing capability is the level of flexibility the
      network has to configure customers' devices, either with a unique public
      IPv4 address, or with a shared public IPv4 address. It may be assessed
      through the following considerations:<list style="symbols">
          <t>Is it possible to configure any customer's device with a shared
          address, regardless his location and his history?</t>

          <t>Is it possible to configure any customer's device with a unique
          public address, regardless his location and his history?</t>

          <t>Is it straightforward to switch, for any customer, from a shared
          address to a unique public address, and vice versa?</t>
        </list>What is considered here is not the policy decision to allocate
      a unique or a shared address, but the network capability to enforce such
      address management schemes.</t>
    </section>

    <section title="Scarcity of Private Addressing">
      <t>In several IPv4 shortage scenarios, private addresses, (as defined in
      <xref target="RFC1918"></xref>), can be assigned to CPEs, and to SHIP
      devices. This can be applied, for instance, to CGN double NAT
      architecture. In this case, if there are intermediate routers between
      CPEs and CGN, the outgoing packets are encapsulated into IPv4 packets
      addressed to a CGN private address (tunneling), and the incoming packets
      are natively routed towards the CPEs -the routing infrastructure must be
      able to route the CPEs' private addresses-. If there are no intermediate
      routers, no tunnel is necessary. However, private addresses are already
      in use in many ISPs' networks, they belong to a finite space which may
      rapidly raise overlapping issues as both the number of customers and the
      number of services that can be subscribed by these customers increase.
      As a consequence, some ISPs use Virtual Private Networks (VPNs) such as
      <xref target="RFC4364"></xref> to allow reusing the same private
      addresses several times with no routing overlaps. This brings a lot of
      complexity in network configuration and management.</t>

      <t>It has been suggested to make the 240/4 block available for private
      addressing <xref target="I-D.wilson-class-e"></xref>. This address
      block, formerly designated as "Class E", is still noted as being
      reserved in the IANA IPv4 address registry. If it were reassigned for
      private addressing that would yield around 268 millions extra private
      addresses. However, many current implementations of the TCP/IP protocol
      stack do not allow the use of the 240/4 block. This is a severe blocking
      point for a lot of existing devices: CPE, NAT or routers. This issue
      will only be solved when the vendors' implementations accept the (240/4)
      addresses.</t>

      <t>Another suggestion <xref
      target="I-D.shirasaki-isp-shared-addr"></xref> is to reserve some public
      blocks (typically three or four /8) only for internal usage. So far,
      there has been no consensus upon this proposal.</t>
    </section>

    <section title="Scalability">
      <t>The number of state entries in the ISP equipment (mainly the SHIP
      devices) can have a significant impact on performance, scalability, and
      solution cost. CGNs need to store many highly dynamic user session
      states. Basically, PRRs will keep information about Port Range
      attribution; they will not need to store a lot of states, the states
      dynamicity will depend on the assignment policy enforced by ISPs.</t>

      <t>IPv4 shortage solutions must be able to adapt to the different ISP
      needs and be flexible enough to cover their evolutions. Customers under
      shared addresses can be geographically disseminated in very different
      ways: scattered vs. localised, sparse vs. dense. In term of architecture
      two types of responses are possible for the placement of the SHIP
      devices: close to the users (many devices that federate few customers)
      vs. close to the core (few devices that federate many customers).</t>

      <t>A+P solutions should be rather flexible and scalable. A PRR treatment
      is a light process and should be straightforward to implement, a PRR
      function could then be implemented in almost any router devices. From
      this viewpoint, it will be rather comfortable for a network manager to
      activate the PRR functions he wants, when he needs and where he needs,
      with no big extra CAPEX (CAPital EXpenditure) increase. For the same
      number of customers federated, a CGN device should be more expensive
      than a PRR device. That could make CGN solutions less flexible and
      scalable than A+P solutions.</t>

      <t>Another important scalability parameter is the impact on the CPEs.
      Some IPv4 shortage mechanisms require specific features in the CPEs. In
      that case, IPv4 shared addresses will not be able to spread to current
      CPEs that lack these appropriate features. Some CPEs are ISP branded
      which makes them, on the one hand, easier to control and to enhance, but
      which can be, on the other hand, very expensive for ISPs if a lot of
      legacy CPEs need to be replaced (if a software update is not
      enough).</t>

      <t>A+P solutions require that CPEs receive specific Port Ranges (e.g.
      through DHCP), and that they control and restrict the source port of
      outgoing packets, according to the assigned Port Ranges. Supplementary
      CPE resources (hardware and software) to run these two features should
      be tiny (if not null) because, for example, in Linux OS the port range
      restriction is already part of the OS (Netfilter/Iptables) and the DHCP
      process is already in the CPE, and would only need to be complemented
      with port range negotiation as proposed in <xref
      target="I-D.bajko-pripaddrassign"></xref> for DHCPv4, and in <xref
      target="I-D.boucadair-dhcpv6-shared-address-option"></xref> for
      DHCPv6.</t>

      <t>Some CGN solutions can be used with no specific features in the CPEs,
      just adding a second NAT level in the ISP network, to the extent that
      routing is correctly achieved between CPEs and CGN. The DS-lite CGN
      flavor requires CPEs to be NATless and to have a tunnel interface IPv4
      into IPv6 (with several possible encapsulation types) to communicate
      with the DS-lite CGN device. A+P IPv6 variant also requires the same
      kind of IPv4 into IPv6 encapsulation.</t>
    </section>

    <section title="Impact on Information System">
      <t>IPv4 shortage solutions will have an impact on the Information System
      platforms and applications handling the administrative and technical
      information to control the activation of services (service ordering and
      service handling functions), and to manage the customer profiles. The
      possibility to give either a unique or a shared address, coupled or not
      with an IPv6 address, could yield several types of customers to deal
      with: IPv4 unique only, IPv4 shared only, IPv4 unique + IPv6, IPv4
      shared + IPv6, IPv6 only.</t>

      <t>Common practice used to rely upon the global IPv4 address assigned to
      a CPE device for customer identification purposes. The forthcoming
      address depletion therefore encourages ISPs to revisit their customer
      identification schemes since global IPv4 addresses will be shared
      amongst several customers. This clearly advocates for an IPv6-based
      customer identification scheme and thus impacts the way
      customer-specific management policies are enforced.</t>

      <t>Additionally, &ldquo;Service and Network Assurance&rdquo; functions
      may be impacted by the introduction of SHIP function. Impacts should be
      assessed. Moreover, dedicated interface to access the CPE when no IPv4
      address is assigned (e.g. DS-lite) should be defined and implemented
      (preferably such access should migrate towards IPv6).</t>
    </section>

    <section title="Impact on Services">
      <t>There is a potential danger for the following types of
      applications:<list style="symbols">
          <t>Applications that establish inbound communications;</t>

          <t>Applications that carry address information in their payload;</t>

          <t>Applications that carry port information in their payload;</t>

          <t>Applications that use fixed ports (e.g. well known);</t>

          <t>Applications that do not use any port (e.g. ICMP);</t>

          <t>Applications that assume the uniqueness of customers' addresses
          (e.g. IP address as identifier);</t>

          <t>Applications that explicitly prohibit twice the same address to
          access to a resource at the same time.</t>
        </list></t>

      <t>Current applications already implement some mechanisms in order to
      circumvent the presence of NATs (typically CPE NATs):<list
          style="symbols">
          <t>ALGs;</t>

          <t>Port Forwarding;</t>

          <t>UPnP IGD;</t>

          <t>NAT-PMP;</t>

          <t>NAT Traversal techniques: ICE, STUN, TURN, etc.</t>
        </list></t>

      <t>It should be considered to what extent these mechanisms can still be
      used with IPv4 shortage mechanisms.</t>

      <t>Impact on existing services:<list style="symbols">
          <t>Will this service work as usual?</t>

          <t>Will this service work but with a degradation?</t>

          <t>What level of degradation?</t>

          <t>Will this service not work at all?</t>

          <t>What modifications are needed if any?</t>
        </list>Impact on future services:<list style="symbols">
          <t>What new constraints are to be taken into account to devise new
          services?</t>
        </list>CGN solutions should have more impact on applications than A+P
      solutions. Basically, from an end-to-end perspective, A+P solutions
      should not be perceived by applications, to the extent of the port range
      limitation, whereas a CGN should be perceived as a supplementary
      blocking mechanism that must be circumvent by specific techniques and
      protocols. This is particular sensitive for P2P applications, even if
      Full Cone CGN behavior should alleviate some problems.</t>
    </section>

    <section title="Port Space Boundaries">
      <t>Most of the time the source port issued by a client application will
      be translated, apart from a direct knowledge of a Port Range restriction
      by the client's stack (A+P), either by a NAT in the user's device (A+P),
      or by a CPE NAT (A+P), or by a CPE NAT and/or a CGN NAT (CGN).</t>

      <t>IANA has classified the whole port space in three categories (as
      defined in http://www.iana.org/assignments/port-numbers):<list
          style="symbols">
          <t>The Well Known Ports are those from 0 through 1023.</t>

          <t>The Registered Ports are those from 1024 through 49151.</t>

          <t>The Dynamic and/or Private Ports are those from 49152 through
          65535.</t>
        </list></t>

      <t><xref target="RFC4787"></xref> notices that current NATs have
      different policies with regard to this classification; some NATs
      restrict their translations to the use of dynamic ports, some also
      include registered ports, some preserve the port range if it is in the
      well-known range. <xref target="RFC4787"></xref> makes it clear that the
      use of port space [1024, 65535] is safe: "mapping a source port to a
      source port that is already registered is unlikely to have any bad
      effects". Therefore, for both A+P and CGN solutions, there is no reason
      to only consider a subset of the port space [1024, 65535] for outgoing
      source ports. In any case, limiting the number of ports available will
      limit the compression ratio.</t>

      <t>The problem is trickier for Well Known Ports. For outgoing source
      ports, <xref target="RFC4787"></xref> points out that "certain
      applications expect the source UDP port to be in the well-known range",
      hence, it can be safe to keep the source port in the Well Known Ports in
      that case. This is possible for a CGN, to the extent that this port is
      still available; this is not possible for A+P if the well known port
      value is not in the attributed Port Range. Apart from port preservation,
      the use of Well Known Ports should be prohibited for outgoing source
      ports, because some applications will not work (for instance MSN
      messenger cannot sign in).</t>

      <t>For inbound communications, it is interesting to be able to use a
      destination port within the Well Known Ports, in order to reach a server
      hosted by a customer (however, this constraint can be alleviated with
      the use of SRV records <xref target="RFC2782"></xref>). This possibility
      is limited. It is unlikely, for example, to satisfy all customers who
      may request port 80. For a CGN, a given customer will get port 80 if
      there is still one address of the CGN public pool where port 80 is
      currently not used, with the restriction that if this customer already
      uses an external public address, it can be harmful to give him a second
      current external public address (this is referenced in behave WG
      documents as "IP address pooling behavior" of "arbitrary" vs. "paired").
      For A+P, a given customer will only get port 80 if port 80 is within his
      Port Range.</t>
    </section>

    <section title="Flow Discrimination">
      <t>ISPs can offer walled garden services along with Internet services.
      ISPs may want these flows not to traverse the IPv4 shortage facilities
      put in place. For instance, all the IPv4 traffic does not have to be
      processed by a CGN facility, for various reasons that are mostly ISP
      policy-specific and which include -but are not necessarily limited to-
      performance considerations, service-specific forwarding policies. It
      should be clear how these IPv4 flows can bypass the IPv4 shortage
      facilities and how they can be handled by the corresponding service
      platform/gateway. However, the best practice seems to rapidly migrate
      these services from IPv4 to IPv6.</t>
    </section>

    <section title="Impact on Intra-Domain and Inter-Domain Routing">
      <t>The introduction of port consideration to route packets to their
      final destinations may have an impact on the current routing
      infrastructure: on the architecture, the IGP and EGP configuration, the
      addressing configuration, and on routers performances.</t>

      <t>The introduction of new nodes that cannot be circumvent could also
      yield non optimized paths, especially for communications between
      customers attached to the same ISP realm.</t>

      <t>Centralized SHIP devices could also strongly modify the current flow
      distribution scheme among the different links and nodes, and then lead
      to non optimal paths.</t>
    </section>

    <section title="Fragmentation">
      <t>When a packet is fragmented, the port information (either UDP or TCP)
      will only be present in the first fragment. The other fragments will not
      bear the port information which is necessary to a correct treatment up
      to the destination. Dedicated means to ease fragmented packets routing
      should be activated.</t>
    </section>

    <section title="QoS">
      <section title="QoS performance">
        <t>The possible degradation of end-to-end performances (e.g. delay)
        experienced in the context of IPv4 shortage solutions should be
        evaluated.</t>
      </section>

      <section title="QoS mechanisms">
        <t>The impact on QoS mechanisms should be investigated. In particular
        the ability to classify traffic in order to apply differentiated
        treatments could be hindered by the fact that an IPv4 address is
        shared among several users, possibly in a dynamic way. In particular,
        transparent DSCP handling should be supported by SHIP devices.</t>
      </section>

      <section title="Introduction of Single Point of Failure (Robustness)">
        <t>The introduction of new nodes/functions, specifically where the
        port information is managed, can create single points of failure. Any
        IPv4 shortage solution should consider the opportunity to add
        redundancy features in order to alleviate the impact on the robustness
        of the offered IP connectivity service.</t>

        <t>Additionally, load balancing and load sharing means should be
        evaluated. The ability of the solution to allow hot swapping from a
        machine to another, in minimizing the perturbations, should be
        considered.</t>

        <t>For CGN solutions, the ability to switch from a CGN node to another
        one without losing active sessions, might be rather complex to achieve
        due to the need to keep the two devices synchronized with the same
        active session states. For the A+P solutions such hot swapping is
        clearly achievable because an A+P node in the network does not
        maintain any session-based states; thus, fail-over means would be
        lightweight.</t>
      </section>
    </section>

    <section title="Support of Multicast">
      <t>It should be assessed if a customer with a shared address can receive
      multicast packets and source multicast packets.</t>

      <t>Particularly, impact on IGMP should be identified and solutions
      proposed. Because of the presence of several end-user devices with the
      same IP address, membership to multicast groups should be evaluated and
      enhancement should be proposed if required. Besides the membership
      issue, building multicast trees may be impacted. This impact should be
      assessed and alternatives proposed.</t>
    </section>

    <section title="Mobile-IP">
      <t>Owing to the deployment of a Mobile-IP architecture, a mobile
      terminal continues to access its connectivity service when visiting a
      Foreign Network. In order to avoid traffic loss, it is recommended to
      use the home address (HoA), and not the care-of address (CoA), to reach
      that mobile terminal. A dedicated entity called HA (Home Agent) is
      responsible for routing the traffic according to the binding table it
      maintains. This table includes in particular the association between the
      HoA and CoA. A Foreign Agent (FA) can optionally be deployed in the
      visited network. If an IP address is shared (in the home network or/and
      in the visited network), HA or FA must be updated so as to take into
      account the port information to achieve its operations (i.e. relay
      traffic destined to HoA to the current CoA).</t>
    </section>

    <section title="End-Users Facilities">
      <t>In the current deployments, end-users are used to configuring their
      CPEs in order to control the traffic entering/exiting their home
      LAN.</t>

      <t>One important and very used feature is the ability to open ports
      (port forwarding) either manually, or with a protocol such as UPnP IGD.
      If a CGN is present, the port must also be open in the CGN. However,
      ISPs may not be very incline to see their customers configure some
      specific parameters in a device inside their networks. Furthermore, any
      supplementary treatment in the NAPT process is also prone to decrease
      the overall CGN performances. The situation may be alleviated if the CGN
      architecture is composed of only one NAT level (no NAT in the CPE) as
      for DS-lite. If all NATs are Full Cone the need for port forwarding may
      be less critical, especially to allow P2P communications. For A+P the
      port forwarding capability may still be used at CPE level, with the
      limitation that the port open must be within the Port Range (for
      instance no possibility to open port 80, if port 80 is not in the
      allocated Port Range). UPnP IGD version 2 should, on this matter,
      facilitate the Port Range working, in allowing CPEs to allocate another
      port number than the one first requested by the terminals.</t>

      <t>The use of the DNS SRV records <xref target="RFC2782"></xref> could
      be the solution to host servers in customers' premises under shared
      addresses. SRV records give the possibility to specify a port value
      related to a service, and then allow services to be accessible on ports
      which are not Well Known ports (e.g. a web server accessible on a port
      different from 80).</t>

      <t>Another widely used feature is the ability to store specific ALGs on
      the CPE to allow applications to correctly behave despite the presence
      of the NAT CPE (even if it is harmful and should be avoided, to the
      extent possible, according to behave WG recommendations). When the CPE
      belongs to the customer, the customer has all flexibility to tailor the
      device to his needs, if the CPE belongs to the ISP, the customer depends
      on the ISP good will to satisfy his request. For CGNs, it would be
      difficult to customize the CGN with specific ALGs coming from specific
      customers' requirements, the customers should wind up with only a
      limited set of possibilities if any. For A+P, ALGs should work as usual,
      and have the same possibilities as today, possibly taking into account
      the limited port choice. Like current deployment, and in the context of
      A+P, the resources required to run ALGs concern the CPE and no network
      nodes.</t>
    </section>

    <section title="Management Tools">
      <t>ISPs deploy a set of tools and applications for the management of
      their infrastructure, especially for supervision purposes. Impact on
      these tools should be evaluated and solutions proposed when required.
      Particularly, means to assign IP connectivity information, means to
      monitor the overall network, to assess the reachability of devices
      should be specified. In this context, impact on tools (e.g. ICMP-based)
      to check the reachability of network nodes should be evaluated.</t>
    </section>

    <section title="Legal Obligations">
      <t>ISPs can be required by governmental and/or regulation authorities to
      provide customer-specific information upon request.</t>

      <section title="Traceability">
        <t>Legal obligations require an ISP to provide the identity of a
        customer upon request of the authorities. Because one public IPv4
        address may be shared between several customers, the knowledge of the
        IP address is not enough to have a chance to find the appropriate
        customer. The legal request should include the information: [IP
        address - Port - Protocol- Begin_Timestamp - End_Timestamp].</t>

        <t>A CGN must record and store all mappings (typically during 6 months
        to one year, depending on the legislation) that it creates. The piece
        of information to store by mapping is two-part: Index, and
        Customer_Discriminator.<list style="symbols">
            <t>Index: is the information that will match legal request input.
            It is composed of: [Public IP address - Public port - Protocol -
            Date of mapping creation - Date of mapping deletion].</t>

            <t>Customer_Discriminator: is the Information that will identify
            the customer for a given index value. The customer discriminator
            depends on the kind of CGN solution put in place. For a DS-lite
            CGN the customer discriminator is his IPv6 prefix, for other CGN
            architectures it can be, for instance and among other
            possibilities, an IPv4 private address, a PPP session ID.</t>
          </list></t>

        <t>The complete DS-lite storage tuple is: [IPv6 prefix - Public IP
        address - Public port - Protocol - Date of mapping creation - Date of
        mapping deletion] per mapping. It should not be necessary to store the
        private address and private port. The ISP should be responsible for
        resolving the customer identity: who the ISP has an agreement with,
        but not the identity of who in the customer's house was actually
        connected (which is of the customer responsibility).</t>

        <t>If we consider one mapping per session (in fact it should be less
        for a Full Cone, one mapping per couple as seen in <xref
        target="Section_5"></xref>) an ISP should record and retain traces of
        all sessions created by all customers during one year (if the legal
        storage duration is one year). This can be a problem not only as a big
        volume of data to store, but also as a big volume of data to
        constantly transfer from the CGN to the storage place.</t>

        <t>A PRR has only to keep one entry [Public IP address - Port Range
        -Date of beginning of Port Range assignment-Date of end of Port Range
        assignment] per customer. Legal storage should not be a main issue for
        A+P solutions, especially if Port Range assignment remains rather
        static.</t>
      </section>

      <section title="Interception">
        <t>This process is proactive, a given group of communications is
        replicated in real time towards a law enforcement agency. Typically,
        the point of replication is the first IP hop in the ISP network.
        Wiretapping techniques need to be transparent to the customer, so that
        the targeted customer cannot be aware of the interception, owing to
        tools such as traceroute that would make appear modification on the
        path. They even need to be transparent to network administration team,
        and need special login with special privileges only accessible to
        authorized members.</t>
      </section>
    </section>

    <section title="Security">
      <section title="Port Randomization">
        <t>A kind of blind attacks that can be performed against TCP relies on
        the attacker's ability to guess the 5-tuple (Protocol, Source Address,
        Destination Address, Source Port, Destination Port) that identifies
        the transport protocol instance to be attacked. Document <xref
        target="I-D.ietf-tsvwg-port-randomization"></xref> describes a number
        of methods for the random selection of the client port number, such
        that the possibility of an attacker guessing the exact value is
        reduced. With shared IPv4 addresses, the port selection space is
        reduced. This issue seems more severe for A+P solutions than for CGN;
        Intuitively, assuming the port range is known, the smaller the port
        range is, the more predictable the port choice is.</t>

        <t>It should be noted that to guess the port information may not be
        sufficient to carry out a successful blind attack. The exact TCP
        Sequence Number (SN) should also be known, a TCP segment is processed
        only if all previous segments have been received, except for some
        Reset Segment implementations which immediately process the Reset as
        long as it is within the Window. If SN is randomly chosen it will be
        difficult to guess it (SN is 32 bits long); port randomization is one
        protection among others against blind attacks.</t>
      </section>

      <section title="Duplicate Effects">
        <t>Some types of attacks that have an impact on a targeted IPv4 public
        address, could see their effects increased by the number of customers
        who share this address. For example, if a given address that has,
        deliberately or not misbehaved, is consequently forbidden to access
        some resources, the whole set of customers who share this address will
        be impacted. Application developers should find alternative
        information to uniquely identify connected users.</t>
      </section>

      <section title="IPsec">
        <t>Even if IPSec is not deployed for mass market (e.g. residential),
        impacts of solutions based on shared IP addresses should be evaluated
        and assessed. <xref target="RFC3947"></xref> proposes a solution to
        solve issues documented in <xref target="RFC3715"></xref>. The
        applicability of <xref target="RFC3947"></xref> in the context of
        shared IP address should be evaluated.</t>
      </section>
    </section>

    <section title="Acknowledgements">
      <t>We are grateful to Christian Jacquenet, Iain Calder, and Marcelo
      Bagnulo, for their helpful comments and suggestions for improving this
      document.</t>

      <t>This document has also been deeply improved by the fruitful exchanges
      with all people who have actively participated in the proposal of IPv4
      shortage solutions.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>There are no IANA considerations.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Security considerations are discussed in the Security section</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include="reference.RFC.4364"?>

      <?rfc include="reference.I-D.wilson-class-e"?>

      <?rfc include="reference.I-D.shirasaki-isp-shared-addr"?>

      <?rfc include="reference.I-D.nishitani-cgn"?>

      <?rfc include="reference.I-D.ymbk-aplusp"?>

      <?rfc include="reference.I-D.boucadair-port-range"?>

      <?rfc include="reference.I-D.despres-sam"?>

      <?rfc include="reference.I-D.ford-shared-addressing-issues"?>

      <?rfc include="reference.I-D.boucadair-dhcpv6-shared-address-option"?>

      <?rfc include="reference.I-D.bajko-pripaddrassign"?>

      <?rfc include="reference.I-D.ietf-softwire-dual-stack-lite"?>

      <?rfc include="reference.I-D.ietf-tsvwg-port-randomization"?>

      <?rfc include="reference.RFC.1918"?>

      <?rfc include="reference.RFC.3947"?>

      <?rfc include="reference.RFC.2782"?>

      <?rfc include="reference.RFC.3715"?>

      <?rfc include="reference.RFC.4787"?>

      <?rfc include="reference.RFC.3022"?>

      <?rfc include="reference.RFC.2663"?>
    </references>
  </back>
</rfc>
