Internet Engineering Task Force T. Savolainen Internet-Draft Nokia Intended status: Standards Track February 20, 2009 Expires: August 24, 2009 A way for a host to indicate support for 240.0.0.0/4 addresses draft-savolainen-indicating-240-addresses-01 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 August 24, 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes how in certain deployment scenarios the 240.0.0.0/4 address space can be taken into use in incremental and Savolainen Expires August 24, 2009 [Page 1] Internet-Draft Indicate support for 240-addresses February 2009 backwards compatible manner. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Benefits for large organizations . . . . . . . . . . . . . . . 4 3. Usage scenarios for 240.0.0.0/4 private addresses . . . . . . 5 3.1. IPv4 point-to-point links . . . . . . . . . . . . . . . . 5 3.2. IPv4 over IPv6 tunnels . . . . . . . . . . . . . . . . . . 5 3.3. Local area network behind CPE . . . . . . . . . . . . . . 6 3.4. Modem used for dial-up . . . . . . . . . . . . . . . . . . 7 4. Indication of support for 240.0.0.0/4 addresses in specific protocols . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Internet Protocol Control Protocol . . . . . . . . . . . . 8 4.2. Dynamic Host Configuration Protocol . . . . . . . . . . . 9 4.3. Dual-Stack Mobile IPv6 . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Savolainen Expires August 24, 2009 [Page 2] Internet-Draft Indicate support for 240-addresses February 2009 1. Introduction IPv4 address space 240.0.0.0/4, formerly known as Class E address space, is currently designated for 'Future use' by IANA and is being directed by [I-D.wilson-class-e] to be designated as unicast address space for private use. A general problem of 240.0.0.0/4 address space usage is that some IP stacks may consider it invalid as a source or a destination address [I-D.fuller-240space]. Because of that, 240.0.0.0/4 address space cannot be taken into use in public or private domains before all exposed nodes have been updated and verified to support it. Furthermore, while it may be possible to upgrade all infrastructure components, it may not be possible to ensure that all attaching hosts have the required support. This is especially true for wireline and wireless operators with large subscriber base with very varying equipment populations. This document describes a generic way, with specific examples, how a host can indicate capability to support 240.0.0.0/4 addresses to an address allocating entity, thereby enabling incremental deployment of 240.0.0.0/4 addresses for certain types of networks. Contents of this document: o Chapter 2 discusses about benefits for large organizations. o Chapter 3 lists use cases where 240.0.0.0/4 address space could be taken into use in the proposed manner. o Chapter 4 shows how three different protocols could be modified to enable indication of support for 240.0.0.0/4 addresses. 1.1. 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]. 1.2. Terminology Consumer Premise Equipment (CPE): a device often provided by an Internet Service Provider, which provides Internet connectivity for a local area network in subscribers' premises (e.g. at home). Cellular router: a portable device that is providing network access for multiple hosts by sharing its cellular network connection with local area network, very much like what a CPE does. Savolainen Expires August 24, 2009 [Page 3] Internet-Draft Indicate support for 240-addresses February 2009 Host: an individual device accessing Internet. Modem: a device that is providing network access for a single host without usually having IP-stack active. PC: any kind of device that is using modem, CPE, or cellular router to get access to Internet. Point-to-Point server: the "server" end of point-to-point protocol link, but can also be the peer of any other point-to-point link. 2. Benefits for large organizations There are countless numbers of private networks using [RFC1918] addressing, but most of them are small enough to manage with the provided private address space. However, there are already networks larger than the currently designated private address space. These include at least major cellular and cable operators, many of which have close to 100 million customers or more, potentially requiring at least five times the private address space provided by RFC1918. It is easy to see that currently allocated private IPv4 address space is too small for large organizations. The organizations are left with options to request for more public IPv4 addresses, deploy multiple instances of RFC1918 address space, deploy port-restricted IPv4 addresses [I-D.bajko-pripaddrassign], and/or transition to IPv6 (and provide IPv4 connectivity to subscribers for example with help of DS-Lite [I-D.durand-softwire-dual-stack-lite]). In the longer term transition to IPv6 is inevitable as IPv4 address space is exhausting, but in the shorter term use of 240.0.0.0/4 as private address space would help large organizations to manage growth and transition (for example, by using 240.0.0.0/4 addresses on dual- stack accesses). 240.0.0.0/4 addresses could also help on scenarios where currently both operator and its customers are using RFC1918 addresses - having 240.0.0.0/4 used in the operator's network could help avoid addressing conflicts. While this document describes how a host can be dynamically allocated an address from 240.0.0.0/4 space, the organization utilizing these addresses must ensure all infrastructure nodes exposed to these addresses (both on- and off-path) have the required support as well. That includes Intranet services, accounting services, management tools etc. Savolainen Expires August 24, 2009 [Page 4] Internet-Draft Indicate support for 240-addresses February 2009 3. Usage scenarios for 240.0.0.0/4 private addresses This chapter presents how support for 240.0.0.0/4 addresses could be handled in some simple but common use cases. 3.1. IPv4 point-to-point links In the figure 1 three hosts are attached to a point-to-point server, which is acting as an address allocating entity. Behind the server, or integrated within, is a NAT facing the Internet. In this kind of setup 240.0.0.0/4 needs to be supported by the host, the server, the NAT, the network between NAT and server, and also by the administrative entities. The server can allocate addresses from 240.0.0.0/4 space to those hosts that indicate support for it, while giving, for example, RFC1918 addresses for others. +-------------------------+ | Administrative entities | +-------------------------+ +----------+ Host---point-to-point link---| | +-----+ | point- | | | Host---point-to-point link---| to-point |----| NAT |----Internet | server | | | Host---point-to-point link---| | +-----+ +----------+ Hosts using point-to-point links Figure 1 The point-to-point server can be, for example: o Dial-up networking server o A 3GPP Gateway GPRS Support Node (GGSN) 3.2. IPv4 over IPv6 tunnels Running IPv4 over IPv6 in tunnels is very much like using direct point-to-point links, as described in section 3.1. The figure 2 illustrates tunneling solution and additionally highlights a middle box, a firewall, that also needs to support 240.0.0.0/4 addresses if it is inspecting (non-encrypted) tunneled packets. Savolainen Expires August 24, 2009 [Page 5] Internet-Draft Indicate support for 240-addresses February 2009 +---------+ |Firewall | | | +----------+ Host===IPv4 tunnel over IPv6===| | | | | | +-----+ +---------+ | tunnel | | | Host===IPv4 tunnel over IPv6===| endpoint |---| NAT |---Internet | | | | Host===IPv4 tunnel over IPv6===| | +-----+ +----------+ Hosts using IPv4 tunnel over IPv6 with firewall Figure 2 The tunnel endpoint can be e.g.: o Dual-Stack Mobile IPv6 home agent providing IPv4 connectivity over IPv6 [SOL2008] o Secure Gateway for Virtual Private Networks (VPN) 3.3. Local area network behind CPE It may well be that a CPE or cellular router having point-to-point or tunneled connectivity to Internet has additional devices behind it. Figure 3 shows a CPE/cellular router type of case where number of devices in the LAN are being provided Internet connectivity. LAN/USB RFC1918 addressing +----------+ PC ---------+ | CPE | | +-----+ | PC ---------+------------| NAT | |--- point-to-point link --- | +-----+ | with 240.0.0.0/4 PC ---------+ | | addressing +----------+ CPE provides networking services for LAN Figure 3 In this scenario the CPE has 240.0.0.0/4 address for its uplink point-to-point, or tunneled, network interface. As the host is sharing its single IP address with multiple devices in LAN, it is obvious that network address translation is required. The CPE should use RFC1918 space for the LAN to ensure backwards compatibility with Savolainen Expires August 24, 2009 [Page 6] Internet-Draft Indicate support for 240-addresses February 2009 legacy devices. 3.4. Modem used for dial-up In the figure 4 there is a single PC using a modem for Internet access. Usually in this kind of use case the modem's possibly existing IP stack is not involved, but the PC interfaces directly with the point-to-point server. In that kind of case 240.0.0.0/4 addresses can be used only if the PC itself is able to indicate support for 240.0.0.0/4 addresses. +----------+ +----------+ | | | | | Modem | | point- | PC ------------------------- point-to-point link ---| to-point | | | | server | +----------+ | | +----------+ PC using modem for dial-up Figure 4 However, in some scenarios it may be desirable for the modem to interfere with the PC's request for an IP address. The modem could modify PC's IP address request by replacing the 0.0.0.0 address with 240.0.0.0 in order to indicate support for 240.0.0.0/4 addresses towards the server. If the server then provides an address from 240.0.0.0/4 address space, the modem would have to activate its IP stack and configure the address obtained from the server for itself, instantiate NAT, and allocate an IP address from RFC1918 address space for the PC. This setup is illustrated in figure 5. For the PC the whole process would be transparent. If the server provides a non-240.0.0.0/4 address even when support for 240.0.0.0/4 was indicated, the modem could pass it to the PC unmodified and work as in figure 4. Savolainen Expires August 24, 2009 [Page 7] Internet-Draft Indicate support for 240-addresses February 2009 +-------+ +----------+ | Modem | | | +---+ | | point- | PC----point-to-point---|NAT| |----point-to-point----| to-point | with RFC1918 +---+ | with 240.0.0.0/4 | server | addressing | | addressing | | +-------+ +----------+ Modem interfering with PCs IP address allocation Figure 5 4. Indication of support for 240.0.0.0/4 addresses in specific protocols This chapter illustrates how the support for 240.0.0.0/4 addresses could be implemented for three different protocols. It is expected that similar approach could be used in some other protocols as well, whether they are standardized by IETF or by some other organization. The general idea is that a host requesting an IP address allocation would indicate its support for 240.0.0.0/4 addresses, which enables address allocating entity to decide whether to provide an IP address from 240.0.0.0/4 address space or not. In a case where an address allocating entity has ran out of public and/or RFC1918 address space, the allocating entity SHOULD offer an address from 240.0.0.0/4 space even when a host has not indicated any support. That would allow legacy hosts, which support use of 240.0.0.0/4 addresses, but do not implement indication of the support, to get an IP address. Updated host implementations that support 240.0.0.0/4 addressing SHOULD always include the indication of support to help avoid situations where address allocation entity is forced to offer 240.0.0.0/4 addresses for those hosts not upgraded with required support. 4.1. Internet Protocol Control Protocol The PPP Internet Protocol Control Protocol (IPCP) [RFC1332] defines in IPCP Configuration Options an IP-Address option, which allows sender to request for a specific IP address, and a receiver to either acknowledge the requested address, or by NAKing the option to give back different IP address. This would happen also when receiver does not understand meaning of 240.0.0.0 address in the request. The required protocol modification is such that the sender would request for the 240.0.0.0 instead of the 0.0.0.0 in the IP-Address Savolainen Expires August 24, 2009 [Page 8] Internet-Draft Indicate support for 240-addresses February 2009 option. The receiver could then, by its choosing, allocate an address from 240.0.0.0/4 address space. 4.2. Dynamic Host Configuration Protocol The Dynamic Host Configuration Protocol (DHCP) [RFC2131] allows DHCP client to request for a specific IP address in DHCPDISCOVER message in 'requested IP address' option. A client supporting 240.0.0.0/4 addresses would request for 240.0.0.0 address in DHCPDISCOVER message, and a supporting server could then by its choosing allocate an IP address from 240.0.0.0/4 address space. A DHCP server not supporting this feature would ignore the requested 240.0.0.0 IP address as an invalid IP address, and would provide the client with any other IP address it chooses. 4.3. Dual-Stack Mobile IPv6 Dual-Stack Mobile IPv6 (DSMIPv6, [I-D.ietf-mext-nemo-v4traversal]), allows a mobile node to ask for an IPv4 Home Address in an IPv4 Home Address Option extension of a Binding Update message. A mobile node supporting 240.0.0.0/4 addresses would request for 240.0.0.0 instead of 0.0.0.0 address in the IPv4 Home Address Option. A supporting home agent could then provide a home address from 240.0.0.0/4 address space, while a home agent not supporting the feature would ignore the request and provide the mobile node with any IP address it chooses. 5. Acknowledgements This document was prepared using xml2rfc template and related web- tool. 6. IANA Considerations This document recommends specifying that the address 240.0.0.0 in an IP address request message indicates host support for 240.0.0.0/4 addresseses, and not a specific request for an 240.0.0.0 address. 7. Security Considerations TBD Savolainen Expires August 24, 2009 [Page 9] Internet-Draft Indicate support for 240-addresses February 2009 8. References 8.1. Normative References [I-D.fuller-240space] Fuller, V., "Reclassifying 240/4 as usable unicast address space", draft-fuller-240space-02 (work in progress), March 2008. [I-D.ietf-mext-nemo-v4traversal] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07 (work in progress), December 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. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. 8.2. Informative References [I-D.bajko-pripaddrassign] Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment", draft-bajko-pripaddrassign-00 (work in progress), February 2009. [I-D.durand-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., and J. Woodyatt, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-durand-softwire-dual-stack-lite-01 (work in progress), November 2008. Savolainen Expires August 24, 2009 [Page 10] Internet-Draft Indicate support for 240-addresses February 2009 Author's Address Teemu Savolainen Nokia Hermiankatu 12 D TAMPERE, FI-33720 FINLAND Email: teemu.savolainen@nokia.com Savolainen Expires August 24, 2009 [Page 11]