One document matched: draft-levis-behave-ipv4-shortage-framework-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocompact="no"?>
<?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-00.txt"
ipr="trust200811">
<front>
<title abbrev="">IPv4 Shortage Framework</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="January" 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. It would be
valuable to assess each IPv4 address shortage solution with all these
issues, to check to what degree they are concerned, how they handle each
issue, and to what extent they resolve the pending problems.</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 anticipated date is mid-2012. See the IPv4 Address Report
website www.potaroo.net/tools/ipv4/index.html for a thorough analysis of
this issue, and an updated prediction.</t>
<t>At the exhaustion date, ISPs will wind up with public address pools
that cannot grow. They will have to make do with what they have
currently got. They will enter an IPv4 address shortage management
phase. It will not be possible to provide each customer with a unique
public IPv4 address. On the other hand, offering only an access to the
IPv6 Internet won't be satisfactory for the customers because a lot of
services will remain IPv4-only accessible, and this is for long period
(a full IPv6 world requires universal agreement which is hard to
achieve).</t>
<t>This document analyses the main issues related to IPv4 Internet
access in the context of public IPv4 address exhaustion. The IPv4
Internet access from an IPv6 stack, and the IPv6 Internet access
whatever the means, are out of the scope of this memo.</t>
</section>
<section title="Shared IPv4 Addresses">
<t>So far, the current practice has been to give a unique IPv4 public
address to each customer. A customer, then, can possibly share her
address among several hosts behind her Customer Premises Equipment
(CPE). In this context, the 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 allocate the same IPv4 public address to several customers
at the same time.</t>
<t>All solutions claiming to solve the IPv4 address exhaustion (simply
referred to as solutions in the remaining part of this memo) are based
on shared addresses. In this new context, an 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 by the routing infrastructure in order to correctly reach
the intended destination.</t>
<t>All IPv4 address shortage mechanisms extend the address space in
adding port information. They differ on the way they manage the port
value.</t>
</section>
<section title="Address Space Multiplicative Factor">
<t>The purpose of sharing 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.</t>
<t>The intention is not to replace IPv6. However, we should be very
careful; whatever the network model deployed, applications and business
will run on top of it. The fact that the IPv4 shortage mechanisms will
not postpone IPv6 deployment, heavily relies on voluntarism.</t>
<t>It is expected that the IPv6 communications will take an increasing
part during the next years to come, at the expense of the IPv4
communications. 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 occurs for its own customers. Most likely a
one digit factor (less than 10) should be sufficient, and it should not
be relevant to go beyond. Whereas the potential is huge, -if we allow to
each customer (one IP address, 1000 ports) we multiply by 64 the total
IPv4 address space- trying to devise solutions that can increase the
IPv4 space by a significantly bigger factor might be seen as an
incentive to postpone again and again IPv6 deployment.</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 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>An important issue is whether shared and unique addresses will
differently be charged.</t>
<t>For the sake of safety and flexibility, ISPs should not drop their
public pool size under a minimum (safety number). They 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>Any IPv4 address shortage solution should make use, as much as
possible, of the IPv6 transport capabilities available, in order to
increase the IPv6 packets traffic and to move forward from an
IPv4-enabled ISP network towards an almost only IPv6-enabled ISP
network. If it is not the case, the risk is to delay IPv6 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.</t>
<t>The IPv4 in IPv6 tunnels, and/or the translation NAT464 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>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
sessions per customer is, the higher the number of customers under the
same IPv4 public address can be, 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 serve more customers. However, this effect will only occur for
customers who have both an IPv6 access and a shared IPv4 access. This
would advocate the strategy to systematically bound a shared IPv4 access
to any IPv6 access. Furthermore, a significant number of public IPv4
addresses will be needed in the interconnection between IPv4 and IPv6
realms, for the sake of global reachability.</t>
</section>
<section title="Solution-Level Issues">
<t>All IPv4 address shortage solutions will be confronted to the
hereafter listed issues. It is valuable to assess each solution with all
these issues, to check to what degree they are concerned, how they
handle each issue, and to what extent they resolve the pending
problems.</t>
<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
address, or with a shared IPv4 address. It can 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 indeed the network
capability to enforce such address management schemes.</t>
<t>Any addressing scheme should be backward compatible with the
current practices. Means to convey IP connectivity (e.g. DHCP, PPP)
should be the same as the ones implemented by service providers.
Additional facilities and tools to ease the shared IPv4 address
management should be promoted.</t>
</section>
<section title="Number of Current Sessions per Customer">
<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. The degree of fairness
-balanced distribution of sessions between customers-, should be
assessed. Means to prevent against traffic loss (due to the limitation
in number of sessions) should be evaluated and proposed. The
importance of this issue may be greatly reduced if the multiplicative
factor is very small (e.g. 4).</t>
<t>As for the current usage of ports, several hundreds per customer
seems current practice, although several thousands may be not unusual
with some P2P applications (e.g. BitTorrent).</t>
<t>The impact of the dynamicity of the sessions should also be
considered, especially as far as performance is concerned.</t>
</section>
<section title="Scarcity of Private Addressing">
<t>According to <xref target="RFC1918"></xref>, IPv4 private addresses
must be chosen in the following ranges: <list style="symbols">
<t>10/8</t>
<t>172.16/12</t>
<t>192.168/16</t>
</list>There is a potential of 2 at the power of (224 + 220 + 216)
addresses, or 17,891,328 addresses. Actually, private addresses are
not that abundant when deployments are concerned. Some ISPs already
use private addresses within their networks for specific usage such as
walled garden services, in a way they cannot reuse them for another
usage. As a consequence, the smallness of the IPv4 private address
pool available for the Internet service could force some ISPs to 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="Impact on Information System">
<t>The IPv4 address shortage solutions could add port information in
the Information System (IS) at different levels. For instance, 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 in the IS: IPv4 unique only, IPv4 shared only, IPv4 unique +
IPv6, IPv4 shared + IPv6, IPv6 only. The impact on the IS platforms
and IS applications should be evaluated and assessed.</t>
</section>
<section title="Port Related Entries in the ISP Equipment">
<t>Additional data related to port information should be stored and
maintained by the ISP equipment. As an example, a set of entries (e.g.
session states, binding entries) are to be instantiated and
maintained. The logic instantiation (behavior and not necessarily
detailed algorithms) of these entries should be standardized to avoid
interoperability problems, and ease management tasks. Optimization
means for instantiating new entries should be investigated and
deployed if required. In addition, the amount of entries to be
maintained should not be too big.</t>
</section>
<section title="Legal Duties">
<t>ISPs are legally required to give access to information related to
their users' communications on request of the authorities.</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 users, the knowledge of the
port number, along with the IP address, is mandatory to have a
chance to find the appropriate user. The ISP must be able to provide
the identity of a customer from the knowledge of the IPv4 public
address and the port number.</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. The
mechanism put in place must be completely transparent to the
customers, so that the targeted customer cannot be aware of the
interception.</t>
</section>
</section>
<section title="Flow Discrimination">
<t>The ISP can offer walled garden services along with Internet
services. Typically, walled garden services packets are exchanged
between the customers and a Service Platform or a Service Gateway. The
ISP may want these flows not to traverse the IPv4 shortage facilities
put in place (for instance TV flows should bypass a Carrier Grade
NAT). However, the best practice seems to rapidly migrate these
services from IPv4 to IPv6.</t>
<t>The activation of solutions to solve the IPv4 shortage problem
should not alter mechanisms to enforce QoS or traffic engineering
within a given domain. Examples of these mechanisms are: DiffServ,
RSVP, etc.</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 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>End-to-end performances (e.g. delay) experienced in the context of
a new addressing solution should be at least similar to the currently
experienced one. QoS should not be severely altered when new means are
activated to solve IPv4 address exhaustion.</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,
and the addressing configuration. The introduction of new nodes that
cannot be circumvent could also yield non optimized routes, especially
for communications between customers attached to the same ISP
realm.</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. Appropriate solutions should be
investigated if required by service providers.</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
payloads</t>
<t>Applications that do not use any port (e.g. ICMP)</t>
<t>Applications that assume the uniqueness of customers'
addresses</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 Traversal</t>
</list></t>
<t>It should be considered to what extent these mechanisms can still
be used with IPv4 shortage mechanisms put in place.</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></t>
</section>
<section title="Impact on CPE">
<t>IPv4 shortage mechanisms may require specific features in the CPEs.
Some CPEs are ISP branded. CPEs are particularly sensible devices by
their number and by the fact that they are often optimized for a well
defined set of treatments closely related to the ISP's services. The
impact on existing CPE devices should be carefully evaluated, taking
into account: features needed, required modifications,
availability.</t>
<t>This requirement is not specific to ISP branded CPEs. CPE behavior
should be particularly specified by any solution claiming to solve the
IPv4 address exhaustion problem.</t>
</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
issues, building multicast trees may be impacted. This impact should
be assessed and alternatives proposed.</t>
</section>
<section title="Scalability">
<t>Any claimed solution to solve the IPv4 address shortage should be
able to deliver the IP connectivity services to a large amount of
customers, this limit should be evaluated.</t>
</section>
<section title="Security">
<t></t>
<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 five-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. Intuitively, assuming the port range is known, the
smaller the port range is, the more predictable the port choice
is.</t>
<t>Any solution to solve IPv4 address shortage should specify how
port randomization is impacted and what alternative means to bypass
the issue are.</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.</t>
</section>
</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 ICMP should be
evaluated.</t>
</section>
<section title="Solution manageability">
<t>The manageability of any new solution to be activated within
service providers realms should be evaluated and complexity avoided.
Particularly, required provisioning operations should be known and not
complex to enforce. The orchestration of required functions and nodes
should be specified.</t>
</section>
<section title="End-Users Facilities">
<t>In the current deployments, end-users are used to configure their
CPEs in order to control the traffic entering/exiting to their home
LAN. Examples of these facilities are: port forwarding or firewall
rules. These facilities should be allowed in the context of IPv4
address exhaustion solutions. No major degradation compared to the
current practice should be perceived by end users. Functional richness
and quality of experience should be at the same level.</t>
</section>
<section title="Service Access Discrimination">
<t>End-users should not be discriminated based on the assigned IP
address. The IP connectivity services should be the same for all
users. Particularly, accessing the added value services should be at
large extent not based on IP address. Applications developers are
encouraged to not embed “hard” IPv4 addresses in their
software.</t>
</section>
</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="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.ietf-tsvwg-port-randomization"?>
<?rfc include="reference.RFC.1918"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:08:07 |