| TOC |
|
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 August 1, 2009.
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.
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.
1.
Introduction
2.
Shared IPv4 Addresses
3.
Address Space Multiplicative Factor
4.
Service Management
5.
IPv6 Migration and IPv4-IPv6 Coexistence
6.
Solution-Level Issues
6.1.
Network Addressing Capability
6.2.
Number of Current Sessions per Customer
6.3.
Scarcity of Private Addressing
6.4.
Impact on Information System
6.5.
Port Related Entries in the ISP Equipment
6.6.
Legal Duties
6.6.1.
Traceability
6.6.2.
Interception
6.7.
Flow Discrimination
6.8.
Introduction of Single Point of Failure (Robustness)
6.9.
Impact on Intra-Domain and Inter-Domain Routing
6.10.
Fragmentation
6.11.
Impact on Services
6.12.
Impact on CPE
6.13.
Support of Multicast
6.14.
Scalability
6.15.
Security
6.15.1.
Port Randomization
6.15.2.
Duplicate Effects
6.16.
Management Tools
6.17.
Solution manageability
6.18.
End-Users Facilities
6.19.
Service Access Discrimination
7.
IANA Considerations
8.
Security Considerations
9.
References
§
Authors' Addresses
| TOC |
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, and this is for long period (a full IPv6 world requires universal agreement which is hard to achieve).
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.
| TOC |
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.
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.
All IPv4 address shortage mechanisms extend the address space in adding port information. They differ on the way they manage the port value.
| TOC |
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. The fact that the IPv4 shortage mechanisms will not postpone IPv6 deployment, heavily relies on voluntarism.
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.
| TOC |
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.
An important issue is whether shared and unique addresses will differently be charged.
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.
| TOC |
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 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.
| TOC |
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.
| TOC |
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:
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.
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.
| TOC |
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).
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.
| TOC |
According to [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.), IPv4 private addresses must be chosen in the following ranges:
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 [RFC4364] (Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006.) 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] (Wilson, P., Michaelson, G., and G. Huston, “Redesignation of 240/4 from "Future Use" to "Private Use",” September 2008.). 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] (Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, “ISP Shared Address,” March 2010.) 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.
| TOC |
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.
| TOC |
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.
| TOC |
ISPs are legally required to give access to information related to their users' communications on request of the authorities.
| TOC |
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.
| TOC |
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.
| TOC |
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.
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.
| TOC |
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.
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.
| TOC |
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.
| TOC |
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.
| TOC |
There is a potential danger for the following types of applications:
Current applications already implement some mechanisms in order to circumvent the presence of NATs (typically CPE NATs):
It should be considered to what extent these mechanisms can still be used with IPv4 shortage mechanisms put in place.
Impact on existing services:
Impact on future services:
| TOC |
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.
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.
| TOC |
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 issues, building multicast trees may be impacted. This impact should be assessed and alternatives proposed.
| TOC |
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.
| TOC |
| TOC |
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] (Larsen, M. and F. Gont, “Transport Protocol Port Randomization Recommendations,” April 2010.) 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.
Any solution to solve IPv4 address shortage should specify how port randomization is impacted and what alternative means to bypass the issue are.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
There are no IANA considerations.
Note to RFC Editor: this section may be removed on publication as an RFC.
| TOC |
Security considerations are discussed in the Security section
| TOC |
| [I-D.ietf-tsvwg-port-randomization] | Larsen, M. and F. Gont, “Transport Protocol Port Randomization Recommendations,” draft-ietf-tsvwg-port-randomization-07 (work in progress), April 2010 (TXT). |
| [I-D.shirasaki-isp-shared-addr] | Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, “ISP Shared Address,” draft-shirasaki-isp-shared-addr-04 (work in progress), March 2010 (TXT). |
| [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 (TXT). |
| [RFC1918] | Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” BCP 5, RFC 1918, February 1996 (TXT). |
| [RFC4364] | Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” RFC 4364, February 2006 (TXT). |
| TOC |
| 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 |
| Jean-Luc Grimault | |
| France Telecom | |
| Email: | jeanluc.grimault@orange-ftgroup.com |
| Alain Villefranque | |
| France Telecom | |
| Email: | alain.villefranque@orange-ftgroup.com |