Individual Submission T. Savolainen Internet Draft Nokia Intended status: Standards Track July 7, 2008 Expires: January 2009 A way for a host to indicate support for 240.0.0.0/4 addresses draft-savolainen-indicating-240-addresses-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 January 7, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Savolainen Expires January 7, 2009 [Page 1] Internet-Draft Indicate support for 240-addresses July 2008 Abstract This document describes how the 240.0.0.0/4 address space can be taken into use in incremental and backwards compatible manner in certain networks, and how reclassification of 240.0.0.0/4 address space as private would help Internet growth and transition to IPv6. Table of Contents 1. Introduction...................................................2 2. Conventions & Terminology......................................3 2.1. Conventions used in this document.........................3 2.2. Terminology...............................................3 3. Benefits for large internet service providers..................4 4. Benefits for IPv6 transition...................................4 5. Usage scenarios for 240.0.0.0/4 private addresses..............5 5.1. IPv4 point-to-point links.................................5 5.2. IPv4 over IPv6 tunnels....................................6 5.3. Local area network behind CPE.............................7 5.4. Modem used for dial-up....................................7 6. Indication of support for 240.0.0.0/4 addresses in specific protocols.........................................................8 6.1. Internet Protocol Control Protocol........................9 6.2. Dynamic Host Configuration Protocol.......................9 6.3. Dual-Stack Mobile IPv6...................................10 7. Security Considerations.......................................10 8. IANA Considerations...........................................10 9. Conclusions...................................................10 10. Acknowledgments..............................................10 11. References...................................................11 11.1. Normative References....................................11 11.2. Informative References..................................11 Author's Addresses...............................................11 Intellectual Property Statement..................................12 Disclaimer of Validity...........................................12 1. Introduction IPv4 address space 240.0.0.0/4 is currently reserved [RFC3330]. [FUL2008] describes different possible uses for that block and as a preparation for all cases recommends various IP-stack implementations to be updated to allow use of 240.0.0.0/4 addresses. One of listed uses is reclassification as private, as is recommended by [WIL2007]. A generic problem of 240.0.0.0/4 address space is that some IP stacks may consider it invalid [FUL2008]. Thus 240.0.0.0/4 cannot be taken into use in public or private domains before all networked hosts have Savolainen Expires January 7, 2009 [Page 2] Internet-Draft Indicate support for 240-addresses July 2008 been updated and verified. 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 using multitude of equipment of different ages. This document describes both generic and specific ways for a host to indicate support for 240.0.0.0/4 addresses to an address allocating entity, thereby enabling incremental deployment in certain networks. This document also recommends reclassification of 240.0.0.0/4 address space as private, as stated in [WIL2007], to allow deployment of larger private IPv4 networks and to ease transition to IPv6. Contents of this document: o Chapter 2 clarifies conventions and terminology o Chapter 3 illustrates benefits for large internet service providers o Chapter 4 describes how IPv6 transition is helped o Chapter 5 lists use cases that would benefit of having 240.0.0.0/4 as private address space and where it can be easily taken into use o Chapter 6 shows how three different protocols could be modified to enable indication of support for 240.0.0.0/4 addresses 2. Conventions & Terminology 2.1. Conventions used in this document 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]. 2.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 Host: an individual device accessing Internet Savolainen Expires January 7, 2009 [Page 3] Internet-Draft Indicate support for 240-addresses July 2008 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 3. Benefits for large internet service providers There are countless numbers of private networks using [RFC1918] address spaces, but most of them are small enough to manage with the address space provided by [RFC1918]. However, there are networks potentially far larger than the address space supported by [RFC1918]. These include at least major cellular operators, many of which have close to 100 million customers, potentially requiring more than five times the private address space provided by [RFC1918]. Until now cellular devices have rarely been always-on, but have been online only on-demand. Currently always-on IP-based services such as Voice over IP, Instant Messaging, IP Multimedia Subsystem (IMS), and email are gaining popularity, thus increasing number of IP addresses that are needed at any given moment of time. It is easy to see that private IPv4 address space, as defined in [RFC1918], is insignificant for these large operators, and they are left with options to ask for more public IPv4 addresses, cascade Network Address Translators (NAT), or transition to IPv6. In longer term transition to IPv6 is inevitable as public IPv4 address space is exhausting and as the 240.0.0.0/4 address space has its size limitation also, but in shorter term use of 240.0.0.0/4 address space private would help operators of large private IPv4 networks to manage growth with less need to use public IPv4 address space or manage increased complexity of cascaded NATs. 4. Benefits for IPv6 transition While reclassification of 240.0.0.0/4 address space as private would help to manage large private IPv4 networks currently using [RFC1918] spaces, thus somewhat decreasing urgency to move to IPv6, it would also help in IPv6 transition by allowing constant allocation of an IPv4 address for larger number of devices than what is possible with [RFC1918] address space. Savolainen Expires January 7, 2009 [Page 4] Internet-Draft Indicate support for 240-addresses July 2008 The transition scenarios helped by 240.0.0.0/4 private address space include: o Dual IP Layer operation [RFC4213]: in networks where there are more hosts than [RFC1918] address space supports, use of dual IP layer is problematic and requires cascading NATs, allocating IPv4 on-demand, sharing addresses and so forth. Larger private address space would be of great help o Configured tunnels [RFC4213]: in simple configured tunnels use case the tunnel server would benefit if the clients could be allocated with unique IPv4 addresses, as otherwise the tunnel endpoint would need to be modified to identify clients by their IPv6 addresses (multiple clients would be sharing same IPv4 private address), or the tunnel endpoint would need to support IPv4 on-demand or IPv4 address sharing. o Dynamic tunnels: there are various solutions for dynamic tunneling, including DSMIPv6 [SOL2008], which suffers practically from the same problems as configured tunnels and dual IP layer operations, and thus would obtain similar benefits: simpler implementation if it would be possible to allocate a constant and locally unique private IPv4 address for the clients 5. 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. 5.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, with separate point- to-point links. 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 NAT, network between NAT and server, and the server itself. The server can allocate addresses from 240.0.0.0/4 space to those hosts that indicate support for it, while giving e.g. [RFC1918] addresses for those hosts that are not indicating support. Savolainen Expires January 7, 2009 [Page 5] Internet-Draft Indicate support for 240-addresses July 2008 +----------+ Host -- point-to-point link -- | | +-----+ | point- | | | Host -- point-to-point link -- | to-point | -- | NAT | -- Internet | server | | | Host -- point-to-point link -- | | +-----+ +----------+ Figure 1 Hosts using point-to-point links The point-to-point server can be e.g.: o Dial-up networking server o A 3GPP Gateway GPRS Support Node (GGSN) 5.2. IPv4 over IPv6 tunnels Running IPv4 over IPv6 in tunnels is very much like using direct point-to-point links, as described in chapter 4.1. The main difference highlighted in this scenario is existence of possible middle boxes, such as firewalls, which are doing deep packet inspection in between the hosts and the tunnel endpoint. Those middle boxes also need to be able to manage 240.0.0.0/4 addresses. +---------+ |Firewall | | | +----------+ Host -- IPv4 tunnel over IPv6 -- | | | | | | +-----+ +---------+ | tunnel | | | Host -- IPv4 tunnel over IPv6 -- | endpoint | -- | NAT | -- Internet | | | | Host -- IPv4 tunnel over IPv6 -- | | +-----+ +----------+ Figure 2 Hosts using IPv4 tunnel over IPv6 with firewall 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) o A generic tunnel endpoint Savolainen Expires January 7, 2009 [Page 6] Internet-Draft Indicate support for 240-addresses July 2008 The obvious benefit of this is that operators of tunnel endpoints can have large number of IPv4 subscribers simultaneously online without having to deploy multiple instances of [RFC1918] - i.e. cascade NATs. 5.3. Local area network behind CPE It may 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 numbers of devices in the LAN are being offered Internet connectivity. LAN/USB RFC1918 domain +----------+ PC -------------+ | | | | CPE | PC -------------+----------- | | -- point-to-point link -- | +----------+ 240.0.0.0/4 PC -------------+ | NAT | addressing +----------+ Figure 3 CPE provides networking services for LAN In this scenario the CPE has 240.0.0.0/4 address for its uplink point-to-point, or tunneled, 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 legacy devices. 5.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 at all, but the PC interfaces directly with the point-to-point server of the point-to-point link. 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. Savolainen Expires January 7, 2009 [Page 7] Internet-Draft Indicate support for 240-addresses July 2008 +----------+ +----------+ | | | | | Modem | | point- | PC ------------------------- point-to-point link -- | to-point | | | | server | +----------+ | | +----------+ Figure 4 PC using modem for dial-up 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 server. If the server then provides an address from 240.0.0.0/4 address space, the modem would need to initiate its IP stack and configure the address obtained from server for itself, instantiate NAT, and allocate an IP address from [RFC1918] 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. +-------+ +----------+ | | | | | Modem | | point- | PC -- point-to-point --| | -- point-to-point -- | to-point | [RFC1918] +-------+ 240.0.0.0/4 | server | addressing | NAT | addressing | | +-------+ +----------+ Figure 5 Modem interfering with PCs IP address allocation 6. Indication of support for 240.0.0.0/4 addresses in specific protocols This chapter shows how the support for 240.0.0.0/4 addresses could be implemented for three different IETF defined 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 standards defining organization such as 3GPP. The general idea is that the hosts requesting for an IP address allocation would indicate support for 240.0.0.0/4 addresses, which enables address allocating entity to decide whether to provide an IP address from [RFC1918] address space or from 240.0.0.0/4 address space. This approach was chosen instead of address allocating entities simply offering 240.0.0.0/4 address without any knowledge of Savolainen Expires January 7, 2009 [Page 8] Internet-Draft Indicate support for 240-addresses July 2008 host side support, as the host software, or the used protocol, might not allow properly rejecting the offered IP address and re-request of address from different address space. In a case where 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. This solution would allow legacy hosts that support use of 240.0.0.0/4 addresses, but do not implement indication of the support, to get allocated an IP address. Updated host implementations that support 240.0.0.0/4 addressing MUST include the indication of support to help avoid situations where address allocation entity is forced to offer 240.0.0.0/4 addresses for hosts not indicating required support. 6.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 IP address in the request. The 240.0.0.0/4 modification would be such that sender would request 240.0.0.0 instead of 0.0.0.0 in the IP-Address option thus indicating support for the 240.0.0.0/4 addresses. The receiver could then, by its choosing, allocate an address also from 240.0.0.0/4 address space for the sender. 6.2. Dynamic Host Configuration Protocol The Dynamic Host Configuration Protocol (DHCP) [RFC2131] allows DHCP client to request for 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 allocate an IP address also from 240.0.0.0/4 address space for the client, if the server so chooses. 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 IP address the DHCP server chooses. Savolainen Expires January 7, 2009 [Page 9] Internet-Draft Indicate support for 240-addresses July 2008 6.3. Dual-Stack Mobile IPv6 Dual-Stack Mobile IPv6 (DSMIPv6) [SOL2008] 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 IPv4 Home Address Option. A supporting home agent could then provide home address also 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. 7. Security Considerations Security considerations are TBD. 8. 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 addresses, and not a request for 240.0.0.0 address as such. 9. Conclusions TBD 10. Acknowledgments Acknowledgements TBD. This document was prepared using 2-Word-v2.0.template.dot. Savolainen Expires January 7, 2009 [Page 10] Internet-Draft Indicate support for 240-addresses July 2008 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002 [FUL2008] Fuller, V., Lear, E., Meyer, D., "Reclassifying 240/4 as usable unicast address space", March 2008, draft-fuller-240space-02 [WIL2007] Wilson, P., Michaelson, G., Huston, G., "Redesignation of 240/4 from "Future Use" to "Limited Use for Large" Private Internets", August 2007, draft-wilson-class-e-01 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC1332, May 1992 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997 [SOL2008] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", June 2008, draft-ietf-mext-nemo-v4traversal-04 [RFC4213] Nordmark, E., Gilligan, R., "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005 11.2. Informative References TBD Author's Addresses Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 TAMPERE FINLAND Email: teemu.savolainen@nokia.com Savolainen Expires January 7, 2009 [Page 11] Internet-Draft Indicate support for 240-addresses July 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Savolainen Expires January 7, 2009 [Page 12] Internet-Draft Indicate support for 240-addresses July 2008 Savolainen Expires January 7, 2009 [Page 13]