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]