Network Working Group R. Bush Internet-Draft Internet Initiative Japan Intended status: Standards Track O. Maennel Expires: July 5, 2009 T-Labs/TU-Berlin J. Zorz go6.si S. Bellovin Columbia University L. Cittadini Universita' Roma Tre January 2009 The A+P Approach to the IPv4 Address Shortage draft-ymbk-aplusp-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 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 July 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 Bush, et al. Expires July 5, 2009 [Page 1] Internet-Draft A+P Addressing Extension January 2009 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 We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before we run out of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4-world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This draft discusses the possibility address sharing by treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a device, we propose to extended the address by "stealing" bits from the port number in the TCP/UDP header, leaving the applications a reduced range of ports. This means assigning the same IP to different clients (e.g., CPE's, mobile phones), each with its port- range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. This document discusses overall constraints that apply to address sharing proposals. [I-D.levis-behave-ipv4-shortage-framework] gives an overview over the solution space and questions that need to be addressed, while [I-D.durand-softwire-dual-stack-lite], [I-D.boucadair-port-range], [I-D.boucadair-dhc-port-range], [I-D.bajko-v6ops-port-restricted-ipaddr-assign], suggest various ways of overcoming the problems of shared addresses. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Bush, et al. Expires July 5, 2009 [Page 2] Internet-Draft A+P Addressing Extension January 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . ancho 1.1. Why Large-Scale-NATs are Harmful . . . . . . . . . . . ancho 2. Design Constraints and Assumptions . . . . . . . . . . . . ancho 2.1. Design constraints . . . . . . . . . . . . . . . . . . ancho 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . ancho 3. Overview of the A+P Solution . . . . . . . . . . . . . . . ancho 3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . sec:s 3.2. Address realm . . . . . . . . . . . . . . . . . . . . . ancho 3.3. Reasons for allowing multiple A+P gateways . . . . . . sec:s 4. A+P for Broadband Providers . . . . . . . . . . . . . . . . ancho 5. A+P for Mobile Providers . . . . . . . . . . . . . . . . . ancho 6. A+P from provider networks perspective . . . . . . . . . . ancho 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . IANA 8. Security Considerations . . . . . . . . . . . . . . . . . . Secur 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . Ackno 10. References . . . . . . . . . . . . . . . . . . . . . . . . ancho 10.1. Normative References . . . . . . . . . . . . . . . . . ancho 10.2. Informative References . . . . . . . . . . . . . . . . ancho Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 0 Bush, et al. Expires July 5, 2009 [Page 3] Internet-Draft A+P Addressing Extension January 2009 1. Introduction This document addresses the imminent IPv4 address space exhaustion. Very soon there will be not enough IPv4 space allocatable to customers of broadband or mobile providers, while IPv6 is not widely enough deployed to migrate to an IPv6-only world. Many large Internet Service Providers (ISPs) face the problem that their networks' customer edges are so large that it will soon not be possible anymore to provide each customer with a single IPv4 address. Therefore ISPs have to devise something more ingenious. Although undesirable, address sharing is inevitable. To allow end-to-end connectivity between IPv4 speaking applications we propose to "steal" some bits from the UDP/TCP header and use them for addressing devices. Assuming we could limit the applications' port addressing to 8 (or 4) bits, we can increase the effective size of an IPv4 address by 8 (or 12) additional bits. In this scenario, 128 (or 4096) customers could be multiplexed on the same IPv4 address, while allowing them a fixed range of 512 (or 16) ports. Customers that require larger port-ranges could dynamically request additional blocks, depending on their contract. We call this "extended addressing" or "A+P" (Address Plus Port) addressing. The main advantage of A+P is that it preserves the Internet "end-to-end" paradigm by not translating (at least some ports of) an IP address. With NAT this end-to-end connectivity is broken. As long as the customer chooses to do this on his/her premises this is a choice that he/she takes, however this is not an option anymore in face of the looming IPv4 address exhaustion, where so called Large-Scale-NATs (LSNs) might be deployed within the providers network - outside the control of the customer. 1.1. Why Large-Scale-NATs are Harmful Various forms of NATs will be installed at various levels and places in the IPv4-Internet to achieve the necessary address compression. This document argues for mechanisms that end-customers will not be locked behind a walled-garden shrine without any control over the translation and that it is therefore essential to create mechanisms to "bypass" a NAT, and keep the control at the end-user: "Carrier grade" is a euphemism for centralized. More semantics move to the core of the network. This is bad in and of itself. Net-heads call it "telco-think" because it is the telco model of smarts in the core as opposed to the Internet model of a simple, just-forward- packets core, with smart edges. It also places the provider in the position, where the user is trapped behind unchangeable application and policies. This is the opposite of the "end-to-end" model of the Internet. Bush, et al. Expires July 5, 2009 [Page 4] Internet-Draft A+P Addressing Extension January 2009 With the smarts at the edges, one can easily field new protocols between consenting end-points by "just" tweaking the NATs at the corresponding Customer Premises Equipment (CPE), even adding application layer gateways (ALGs) if they are needed. However, LSNs do not build an Internet walled garden at the edges, they build it by restricting the core. With LSNs in the core, customers wanting new application protocols which require cooperation from the NAT, have to beg help from the broadband providers' engineers and lawyers, and all other users of the large-scale-NATs. It is feared that all new application protocols have to go through the carrier-loving lawyers to be allowed to be handled by the NATs in their core. Today's NATs are typically mitigated by ALGs over which the customer has some degree of control, e.g. port forwarding or UPnP. However, this is not expected to work anymore with LSNs. LSN proposals admit that it is not expected that applications that require specific port assignment or port mapping from the NAT box will keep working [I-D.durand-softwire-dual-stack-lite]. This is the ultimate horror the NAT-haters fear, and, in this case, they are not all that wrong. We believe this is not an option and that the end-user must have the ability to control its own ALGs. So, if someone wants to deploy a new application, they can talk to the broadband providers' lawyers or run new disruptive technology over HTTP; we can pick our poison. And if the NAT is not where the customer can directly control it, i.e., it is anywhere back in the provider's network, then the provider controls what the user can control, i.e. it is not really under user control. We do not wish to deal with the case where the provider has to decide whether to allow Skype v42 when they themselves provide a competing VoIP product. And remember that as IPv6 deploys, if we want to have one Internet, i.e. IPv4 nodes talking freely with IPv6 nodes, then translation must be done somewhere. The challenge is whether someone can figure out a scheme where it is done for these large networks? We believe it should be at the customer edge, not in the core. Another issue with LSN is scalability. ISPs face a tension between the placement of LSNs within their network to aggregate as much as possible, when too much aggregation creates a massive state problem. To reduce the state, the placement ends up somewhere closer to the edge, where the benefits are somewhat limited. It is not clear how a LSN should maintain per-session state in a scalable manner. State for improperly terminated sessions could remain stale for some time. The LSN hence trades scalability for the amount of state that needs to be kept, which makes optimally placing a LSN a hard engineering problem. Bush, et al. Expires July 5, 2009 [Page 5] Internet-Draft A+P Addressing Extension January 2009 In addition, NATs frequently need to initiate translation for secondary port numbers. This may be a decision based on packet