Network Working Group P. Levis, Ed.
Internet-Draft M. Boucadair
Intended status: Informational JL. Grimault
Expires: September 5, 2009 A. Villefranque
France Telecom
March 4, 2009
IPv4 Shortage: Needs and Open Issues
draft-levis-behave-ipv4-shortage-framework-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document analyses the main issues related to IPv4 Internet
Levis, et al. Expires September 5, 2009 [Page 1]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
access in the context of public IPv4 address exhaustion. It would be
valuable to assess IPv4 address shortage solutions 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Shared IPv4 Addresses . . . . . . . . . . . . . . . . . . . . 4
3. Address Space Multiplicative Factor . . . . . . . . . . . . . 5
4. Service Management . . . . . . . . . . . . . . . . . . . . . . 5
5. IPv6 Migration and IPv4-IPv6 Coexistence . . . . . . . . . . . 6
6. Solution-Level Issues . . . . . . . . . . . . . . . . . . . . 7
6.1. Network Addressing Capability . . . . . . . . . . . . . . 7
6.2. Number of Current Sessions per Customer . . . . . . . . . 7
6.3. Scarcity of Private Addressing . . . . . . . . . . . . . . 8
6.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. Impact on Information System . . . . . . . . . . . . . . . 8
6.6. Impact on Services . . . . . . . . . . . . . . . . . . . . 9
6.7. Flow Discrimination . . . . . . . . . . . . . . . . . . . 10
6.8. Impact on Intra-Domain and Inter-Domain Routing . . . . . 10
6.9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 10
6.10. Impact on CPE . . . . . . . . . . . . . . . . . . . . . . 11
6.11. QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.11.1. QoS performance . . . . . . . . . . . . . . . . . . . 11
6.11.2. QoS mechanisms . . . . . . . . . . . . . . . . . . . 11
6.11.3. Introduction of Single Point of Failure
(Robustness) . . . . . . . . . . . . . . . . . . . . 11
6.12. Port Related Entries in the ISP Equipment . . . . . . . . 12
6.13. Support of Multicast . . . . . . . . . . . . . . . . . . . 12
6.14. Mobile-IP . . . . . . . . . . . . . . . . . . . . . . . . 12
6.15. End-Users Facilities . . . . . . . . . . . . . . . . . . . 12
6.16. Management Tools . . . . . . . . . . . . . . . . . . . . . 13
6.17. Legal Obligations . . . . . . . . . . . . . . . . . . . . 13
6.17.1. Traceability . . . . . . . . . . . . . . . . . . . . 13
6.17.2. Interception . . . . . . . . . . . . . . . . . . . . 13
6.18. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.18.1. Port Randomization . . . . . . . . . . . . . . . . . 13
6.18.2. Duplicate Effects . . . . . . . . . . . . . . . . . . 14
6.18.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Levis, et al. Expires September 5, 2009 [Page 2]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Levis, et al. Expires September 5, 2009 [Page 3]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
1. Introduction
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.
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 (a full
IPv6 world requires universal adoption which is hard to achieve).
This document analyses the main issues related to IPv4 Internet
access in the context of public IPv4 address exhaustion.
2. Shared IPv4 Addresses
So far, the current practice has been to give a unique IPv4 public
address to each customer. Current designs assume the allocation of a
global IPv4 address to the Customer Premises Equipment (CPE), whereas
hosts connected to the CPE will be privately-addressed, meaning CPE
devices activate a Network Address and Port Translator (NAPT)
capability by default, sourcing IPv4 traffic based upon this sole
global IPv4 address. 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.
All IPv4 address shortage mechanisms extend the address space in
adding port information. They differ on the way they manage the port
value. 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.
So far, two categories of solutions have been identified: (1)
Levis, et al. Expires September 5, 2009 [Page 4]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
Solutions that propose the introduction of a NAPT function in the ISP
network, denoted also as Carrier Grade NAT (CGN). The CGN is
responsible for translating IP packets issued with private addresses
to ones with publicly routable IPv4 addresses. (2) Solutions that
avoid the presence of a CGN function, they allocate the same IP
public address to several customers at the same time. They also
allocate 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.
3. Address Space Multiplicative Factor
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.
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. If we do not want to see IPv4
shortage mechanisms postpone IPv6 deployment, all Internet actors
must adopt a voluntary position towards IPv6.
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 occurs for its own customers. Most likely, a one digit
factor (less than 10) should be sufficient, and it should be
pointless 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.
4. Service Management
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,
Levis, et al. Expires September 5, 2009 [Page 5]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
unique address as the privileged choice, shared address as the
privileged choice, etc. An important issue is whether shared and
unique addresses will be differently charged.
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.
o To increase the public IPv4 address pool: increase the number of
customers with shared address; increase the ratio of customers per
shared address.
o To decrease the public IPv4 address pool: decrease the number of
customers with shared address; decrease the ratio of customers per
shared address.
5. IPv6 Migration and IPv4-IPv6 Coexistence
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.
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.
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
Levis, et al. Expires September 5, 2009 [Page 6]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
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 would advocate the
strategy to systematically bound a shared IPv4 access to any IPv6
access. Furthermore, some public IPv4 addresses will be required to
connect IPv4 and IPv6 realms, through IPv4 IPv6 translators, for the
sake of global reachability.
6. Solution-Level Issues
All IPv4 address shortage solutions will be confronted to the
hereafter listed issues. It is valuable to assess solutions 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.
6.1. Network Addressing Capability
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:
o Is it possible to configure any customer's device with a shared
address, regardless his location and his history?
o Is it possible to configure any customer's device with a unique
public address, regardless his location and his history?
o Is it straightforward to switch, for any customer, from a shared
address to a unique public address, and vice versa?
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.
6.2. Number of Current Sessions per Customer
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).
Levis, et al. Expires September 5, 2009 [Page 7]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
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).
The impact of the dynamicity of the sessions should also be
considered, especially as far as performance is concerned.
6.3. Scarcity of Private Addressing
As a matter of fact, private IPv4 addresses (as defined in [RFC1918])
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 [RFC4364] to allow
reusing the same private addresses several times with no routing
overlaps. This brings a lot of complexity in network configuration
and management.
It has been suggested to make the 240/4 block available for private
addressing [I-D.wilson-class-e]. 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.
Another suggestion [I-D.shirasaki-isp-shared-addr] 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.
What needs to be considered is to what extent the IPv4 sharing
solutions make use of IPv4 private addresses.
6.4. Scalability
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.
6.5. Impact on Information System
The impact on the Information System platforms and applications
handling the administrative and technical information to control the
activation of services, and to manage the customer profiles, should
be evaluated and assessed.
Levis, et al. Expires September 5, 2009 [Page 8]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
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.
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 way the solution
tries to possibly alleviate or simplify customer profile handling,
should be evaluated and assessed.
6.6. Impact on Services
There is a potential danger for the following types of applications:
o Applications that establish inbound communications
o Applications that carry address information in their payload
o Applications that carry port information in their payload
o Applications that use fixed ports (e.g. well known)
o Applications that do not use any port (e.g. ICMP)
o Applications that assume the uniqueness of customers' addresses
(e.g. IP address as identifier)
o Applications that explicitly prohibit twice the same address to
access to a resource at the same time
Current applications already implement some mechanisms in order to
circumvent the presence of NATs (typically CPE NATs):
o ALGs
o Port Forwarding
o UPnP IGD
o NAT Traversal
It should be considered to what extent these mechanisms can still be
used with IPv4 shortage mechanisms put in place.
Levis, et al. Expires September 5, 2009 [Page 9]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
Impact on existing services:
o Will this service work as usual?
o Will this service work but with a degradation?
o What level of degradation?
o Will this service not work at all?
o What modifications are needed if any?
Impact on future services:
o What new constraints are to be taken into account to devise new
services?
6.7. Flow Discrimination
The ISP can offer walled garden services along with Internet
services. The ISP may want these flows not to traverse the IPv4
shortage facilities put in place (for instance, all the IPv4 traffic
doesn't 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.
6.8. Impact on Intra-Domain and Inter-Domain Routing
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.
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. It could also strongly
modify the current flow distribution scheme among the different links
and nodes.
6.9. Fragmentation
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
Levis, et al. Expires September 5, 2009 [Page 10]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
treatment up to the destination. Appropriate solutions should be
evaluated.
6.10. Impact on CPE
IPv4 shortage mechanisms may require specific features in the CPEs.
Some CPEs are ISP branded. CPE devices are strategic not only
because of their large number, but also because of the advanced
capabilities they support, and which include (but are not limited
to), firewalling, QoS and self-configuring abilities. The impact on
existing CPE devices should be carefully evaluated, taking into
account: features needed, required modifications, availability.
This issue is not specific to ISP branded CPEs. CPE behavior should
be particularly specified by any solution claiming to solve the IPv4
address exhaustion problem.
6.11. QoS
6.11.1. QoS performance
The possible degradation of end-to-end performances (e.g. delay)
experienced in the context of IPv4 shortage solutions should be
evaluated.
6.11.2. QoS mechanisms
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.
6.11.3. Introduction of Single Point of Failure (Robustness)
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.
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.
Levis, et al. Expires September 5, 2009 [Page 11]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
6.12. Port Related Entries in the ISP Equipment
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 amount of data to be stored, the way the entries are
instantiated and managed, should be documented.
The number of port related entries in the ISP equipment can have a
significant impact on performance, scalability, and solution cost.
6.13. Support of Multicast
It should be assessed if a customer with a shared address can receive
multicast packets and source multicast packets.
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.
6.14. Mobile-IP
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). The way proposed solutions deal with Mobile-IP
mechanisms should be identified and assessed.
6.15. End-Users Facilities
In the current deployments, end-users are used to configuring their
CPEs in order to control the traffic entering/exiting their home LAN.
Examples of these facilities are: port forwarding or firewall rules.
The availability of these facilities offer to the end-users should be
considered in the context of IPv4 address exhaustion solutions.
Degradation compared to the current practice should be assessed.
Levis, et al. Expires September 5, 2009 [Page 12]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
6.16. Management Tools
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.
6.17. Legal Obligations
ISPs can be required by governmental and/or regulation authorities to
provide customer-specific information upon request.
6.17.1. Traceability
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.
6.17.2. Interception
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.
6.18. Security
6.18.1. Port Randomization
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
[I-D.ietf-tsvwg-port-randomization] 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.
Levis, et al. Expires September 5, 2009 [Page 13]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
Any solution to solve IPv4 address shortage should specify how port
randomization is impacted and what alternative means to bypass the
issue are.
6.18.2. Duplicate Effects
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.
6.18.3. IPsec
Even if IPSec is not deployed for mass market, impacts of solutions
based on shared IP addresses should be evaluated and assessed.
[RFC3947] proposes a solution to solve issues documented in
[RFC3715]. The applicability of [RFC3947] in the context of shared
IP address should be evaluated.
7. Acknowledgements
We are grateful to Christian Jacquenet, Iain Calder, and Marcelo
Bagnulo, for their helpful comments and suggestions for improving
this document.
8. IANA Considerations
There are no IANA considerations.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Security Considerations
Security considerations are discussed in the Security section
10. Informative References
[I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization",
draft-ietf-tsvwg-port-randomization-02 (work in progress),
August 2008.
Levis, et al. Expires September 5, 2009 [Page 14]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
[I-D.shirasaki-isp-shared-addr]
Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "ISP Shared Address",
draft-shirasaki-isp-shared-addr-01 (work in progress),
October 2008.
[I-D.wilson-class-e]
Wilson, P., Michaelson, G., and G. Huston, "Redesignation
of 240/4 from "Future Use" to "Private Use"",
draft-wilson-class-e-02 (work in progress),
September 2008.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
Authors' Addresses
Pierre Levis (editor)
France Telecom
42 rue des Coutures
BP 6243
Caen Cedex 4 14066
France
Email: pierre.levis@orange-ftgroup.com
Mohamed Boucadair
France Telecom
Email: mohamed.boucadair@orange-ftgroup.com
Levis, et al. Expires September 5, 2009 [Page 15]
Internet-Draft IPv4 Shortage: Needs and Open Issues March 2009
Jean-Luc Grimault
France Telecom
Email: jeanluc.grimault@orange-ftgroup.com
Alain Villefranque
France Telecom
Email: alain.villefranque@orange-ftgroup.com
Levis, et al. Expires September 5, 2009 [Page 16]