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]