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]