[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                                G. Bajko
Internet Draft                                            T. Savolainen
Intended Status: Proposed Standard                                Nokia
Expires: May 2, 2009                                   November 2, 2008



                 Port Restricted IP Address Assignment
           draft-bajko-v6ops-port-restricted-ipaddr-assign-02


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.

   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 May 2, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   With the foreseen scarcity of public IPv4 addresses and the
   hesitation and technical difficulties to deploy IPv6, the transition
   scenarios which assumed that migration to IPv6 happens before the
   run-out of IPv4 addresses, need to be revisited.
   This document defines a method to allocate the same IPv4 address to
   multiple hosts, thus prolonging the availability of public IPv4
   addresses for as long as it takes for IPv6 to take over the demand
   for IPv4. The document also describes the deployment scenarios where
   this method is applicable.



Bajko & Savolainen        Expires May 2, 2009                 [Page 1]


Port restricted IP address assignment                   November 2008

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.

Terminology and abbreviations used in this document

   Port restricted IPv4 address: an IP address which can only be used
   in conjunction with the specified ports. Port restriction refers to
   all transport addresses.

   ASN GW       Access Service Network Gateway
   CGN          Carrier Grade Network Address Translator
   CPE          Consumer Premises Equipment, a device that resides
                between internet service provider's network and
                consumers' home network.
   GGSN         Gateway GPRS Support Node
   GPRS         General Packet Radio Service
   OPR          Offered Port Restricted IP Address
   PDN GW       Packet Data Network Gateway
   PDSN         Packet Data Serving Node
   RPR          Requested Port Restricted IP Address


Table of Content

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .3
   2. Usage of port-restricted IPv4 addresses in various scenarios . .3
      2.1 Point-to-point links with L2 IPv4 support . . . . . . . . . 4
      2.2 Point-to-point tunneled links . . . . . . . . . . . . . . . 4
      2.3 NAT in a host . . . . . . . . . . . . . . . . . . . . . . . 5
      2.4 Distributed Network Address Translation function . . . . . .6
      2.5 Relationship to other proposals . . . . . . . . . . . . . . 7
          2.5.1 Dual-Stack Lite . . . . . . . . . . . . . . . . . . . 7
          2.5.2 Address and Port Borrowing Protocol . . . . . . . . . 7
      2.6 Efficiency issues in dynamic and static port allocation
          methods . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   3. DHCPv4 Option for allocating port restricted public IPv4 addr. .8
      3.1 Option for offering port restricted IPv4 address . . . . . .8
      3.2 Option for requesting port restricted IPv4 address . . . . .9
   4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . .9
      4.1 Client Behaviour . . . . . . . . . . . . . . . . . . . . . .9
      4.2 Server Behaviour . . . . . . . . . . . . . . . . . . . . . 10
   5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .11
   6. IANA considerations . . . . . . . . . . . . . . . . . . . . . .11
   7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . .12
   8. Security considerations . . . . . . . . . . . . . . . . . . . .12
   9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
   10. Informative References . . . . . . . . . . . . . . . . . . . .12
   11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . .14


Bajko & Savolainen        Expires May 2, 2009                 [Page 2]


Port restricted IP address assignment                   November 2008

1. Introduction

   There are a number of possible solutions to deal with the problem of
   transitioning from IPv4 to IPv6; however none of them is a one fits
   all solution. Different solutions fit different deployment scenarios
   (see also [ARKK2008]). See [WING2008] for comparison.

   As a possible alternative solution for the IPv4-IPv6 coexistence
   period, this document describes a method, using newly defined DHCPv4
   [RFC2131] options, that allows servers to assign port restricted
   IPv4 addresses to clients. By assigning the same IPv4 address to
   multiple clients, the availability of IPv4 addresses can be
   prolonged for as long as it takes for IPv6 to take over the demand
   for IPv4.

   The solution described in this document is intended to be used by
   large ISPs, who as of the date of writing this document, have a
   large enough IPv4 address pool to be able to allocate one public
   IPv4 address for each and every client. They expect though that the
   situation is unsustainable and they will soon not be able to provide
   every client with a public IPv4 address. Such ISPs have two
   possibilities to choose from:
   - deploy Network Address Translators (NAT), which can be a
   significant investment for ISPs not having NATs yet. The address
   space limitations of [RFC1918] may even force these large ISPs to
   deploy double NATs, which come with all the harmful behaviour of
   Carrier Grade NATs (CGN), as described in [MAEN2008]; or
   - allocate fragments of the same public IPv4 address directly to
   multiple clients (which can be CPEs or end hosts), thus avoid the
   cost of deploying multiple layers of, or carrier grade NATs. It is
   however assumed, that the demand for IPv4 addresses will decrease in
   the not so distant future, being taken over by IPv6, as the proposal
   in this draft is not by any means a permanent solution for the IPv4
   address exhaustion problem. In fact, some presented deployment
   scenarios require existence of IPv6 access network.

   For ISPs not having NATs yet, a solution not requiring NATs would
   probably be preferred. For some other ISPs, who already have NATs in
   place, increasing the capacity of their NATs might be the preferred
   solution.

2. Usage of port-restricted IPv4 addresses in various scenarios

   This chapter depicts the scenarios where port restricted IPv4
   addresses can be used, and what kind of assumptions have to be made.
   Relationships to various IPv4-IPv6 transition proposals being
   currently discussed in IETF are also considered.






Bajko & Savolainen        Expires May 2, 2009                 [Page 3]


Port restricted IP address assignment                   November 2008

2.1 Point-to-point links with L2 IPv4 support

   In point-to-point links it can be assumed that there are only two
   communicating parties on the link, and thus IP address collisions
   are easy to avoid.

   In wireless cellular networks host attaches to an access router,
   such as 3GPP PDN GW [3GP23401] or WiMAX ASN GW [WMFS21.2], over a
   point-to-point link providing layer 2 IPv4 transport capability.

   In order to be able to allocate a port-restricted IP addresses to a
   host, the access router needs to implement DHCPv4 server [3GP23401]
   or at least act as a DHCPv4 relay or DHCPv4 proxy [WMFS31.2], while
   a DHCPv4 server exists in the backend. These setups are illustrated
   in figure 1.

                                    +--------+      |
      3GPP  ---Point to Point link--| 3GPP   |------|
      host     <-IPv4 EPS bearer--> | PDN GW |      |
                                    +--------+      |
                                                    | IPv4 Internet
                                    +--------+      |
      WiMAX ---Point to Point link--| WiMAX  |------|
      host     <-----IPv4 CS------> | ASN GW |      |
                                    +--------+      |

                Figure 1 Point-to-point physical links

   As each host is attaching to the access router with an individual
   link, both modified and unmodified hosts can be supported
   simultaneously. This enables incremental deployment of modified
   hosts that are supporting public IPv4 address conservation by using
   DHCP port restricted IPv4 address assignment, while continuing to
   support the legacy hosts using DHCP as currently specified.

   In this scenario IPv6 addresses can be used in parallel with any
   IPv4 address, therefore no tunneling is necessary.

2.2 Point-to-point tunneled links

   From DHCPv4 point of view tunneled link scenario does not differ
   very much from L2 point-to-point links as described in 2.1, although
   there are general concerns regarding tunnels (e.g. decreased MTU).

   It is expected by authors that the tunneling would be done over
   IPv6, but other mechanisms can also be thought of.

   Tunnel is established between a host (or a CPE) and a tunnel
   endpoint in the host operator's network. In different scenarios the
   tunnel endpoint may be placed at different locations. The tunnel
   endpoint can be at the first hop router such as 3GPP2 PDSN
   [3G2X0011] or 3GPP PDN-GW, or farther off in the network such as at

Bajko & Savolainen        Expires May 2, 2009                 [Page 4]


Port restricted IP address assignment                   November 2008

   Dual-Stack Lite Carrier Grade NAT (see 2.5.1). These example setups
   are illustrated in figure 2.

   Having the tunnel endpoint at the first hop router can be beneficial
   in setups where arrangement of native dual-stack transport for the
   last mile is not feasible or cost-effective approach. This can be
   the case e.g. in current 3GPP networks where a PDP context
   [3GP23060] is capable of transporting only IPv4 or IPv6 packets, and
   for dual-stack access two parallel PDP contexts are required.


                                Tunnel endpoints,
                                implementing DHCPv4
                                server/relay/proxy

                                  +-------------+
      Host ====IPv4 over IPv6==== | 3GPP2       |      |
           <---PPP & IPv6CP ----> | PDSN        |------|
               (point-to-point)   +-------------+      |
                                                       |
                                  +-------------+      |
      Host ====IPv4 over IPv6==== | 3GPP        |------| IPv4 Internet
           <--IPv6 PDP context--> | GGSN        |      |
              (point-to-point)    +-------------+      |
                                                       |
                                  +-------------+      |
      Host ====IPv4 over IPv6==== | IETF        |------|
           <---- IPv6-only -----> | DS-Lite CGN |      |
                 network          +-------------+

                Figure 2 Point-to-point links as IPv4 over
                         IPv6 tunnels over three different accesses

   For networks which use IP(v6)CP to configure an IPv4 and IPv6
   address to the host, allocating a port-restricted IPv4 address to
   the host to prevent running out of available IPv4 addresses, can
   also be a feasible solution. In these deployment scenarios IPv6CP
   would be used to configure an IPv6 address to the host. The host
   would then set up the tunnel and use the DHCPv4 extensions defined
   in this document to request a port-restricted IPv4 address. Examples
   of such networks include 3GPP2 and BRAS.

2.3 NAT in a host

   When a host which is capable of handling a port-restricted IP
   address, but some of the applications on the host may have trouble
   using those addresses (e.g. they require a specific port to
   operate), as an implementation choice, the host may hide the port
   restricted nature of the allocated address by implementing an
   internal NAT as illustrated in figure 3 below:



Bajko & Savolainen        Expires May 2, 2009                 [Page 5]


Port restricted IP address assignment                   November 2008


   Host
     +---------------------+
     +  Applic             +
     +    |                +
     +    | IPv4p +-----+  +  Port Restricted IPv4 address
     +    |-------| NAT |  +---------------------------------
     +            +-----+  +
     +                     +
     +---------------------+

                Figure 3 Internal NAT in a host


2.4 Distributed Network Address Translation function

   One deployment model for port restricted IPv4 addresses is the
   distributed Network Address Translation, as shown in figure 4. This
   deployment scenario is preferred for the cases when:
      1 the port-restricted IPv4 address is not supported by all hosts
        connected to the CPE
      2 Applications may have trouble understanding port restricted
        public IPv4 addresses, but are familiar with RFC1918 addresses
      3 Centralized NAT (Carrier Grade NAT) function may be expensive
        to deploy


                          IPv6-only network
                    +----+                 +------+
                    |home|                 + AR+  +  +-------------+
   IPv4 host--------+CPE +=====tunnel======+DHCP  +--+IPv4 Internet|
                    +----+                 +Server+  +-------------+
                                           +------+

   <---private v4--->    <--- v4 over v6 -->      <---public v4---->

                Figure 4 Distributed NAT scenario illustrated

   With distributed NAT model, the home CPE is assigned a port
   restricted public IPv4 address and it provides NATed addresses to
   the legacy devices attached to it. This setup allows avoidance of
   Carrier Grade NAT and enables customers' control on NAT with e.g.
   protocols such as UPnP and NAT-PMP, and also makes it easier to
   optimize sending of keep-alive messages.

   The distributed NAT model can be used in both physical and tunneled
   point-to-links.

   Alternatively, a CPE may choose to subdivide the port-restricted
   IPv4 address, in cases when all hosts connected to the CPE support
   port-restricted IPv4 address assignment.


Bajko & Savolainen        Expires May 2, 2009                 [Page 6]


Port restricted IP address assignment                   November 2008

2.5 Relationship to other proposals

   This chapter describes how the new DHCPv4 options for port
   restricted IPv4 address assignment can be seen to relate to some
   recent IETF proposals on this subject.

2.5.1 Dual-Stack Lite

   Dual-Stack Lite [DURA2008] describes a setup where a Dual-Stack Lite
   enabled device tunnels IPv4 over IPv6 to a Carrier Grade NAT. For
   the address mapping purposes, the CGN uses Dual-Stack Lite device's
   unique IPv6 address as an identifier in addition to any private IPv4
   address device may be using. Dual-Stack Lite client side
   functionality can be implemented into a home router or a host.

   The DHCPv4 port-restricted addresses can be used in combination with
   Dual-Stack Lite environment, as defined in [DURA2008], by simply
   incorporating the port-restricted IPv4 address allocation mechanism
   into the CGN entity. The benefit of doing so is to both enable
   distribution of the NAT function and to allow updated devices and
   applications to make good use of public, but port-restricted, IPv4
   addresses. The setup is illustrated in figure 5.

   Alternatively, the Carrier Grade NAT can just act as a tunnel
   endpoint and DHCP relay, while the DHCPv4 server is a separate
   entity. Collocating DHCPv4 server and tunnel endpoint is preferred
   approach to avoid introduction of control interfaces between DHCPv4
   server and tunnel endpoint.


   +------------------+                   +---------------+
   |Dual-Stack Lite   |                   +---+    +------+
   |host              |==IPv4 over IPv6===|NAT|----|      |
   +------------------+                   +---+    |      |
                                          |+----+  |Multi |
                                          ||IPv4|  |plexer|--- IPv4
                                          ||pool|  |      |    Internet
                                          |+----+  +------+
   +------------------+                   +------+    |   |
   |  Host with port  |==IPv4 over IPv6===|DHCPv4|----+   |
   |restricted IP addr|                   +------+        |
   | (&internal NAT)  |                   +---------------|
   +------------------+                   Carrier Grade NAT

                Figure 5 Using port-restricted IPv4 addresses in
                         Dual-Stack Lite environment

2.5.2 Address and Port Borrowing Protocol

   The architecture of address and port borrowing protocol (APBP) is
   described in [DESP2008]. The new DHCPv4 options can be used by APBP
   enabled CPE, or host, to request public IPv4 address with port range

Bajko & Savolainen        Expires May 2, 2009                 [Page 7]


Port restricted IP address assignment                   November 2008

   from APBP server. The APBP server can also act as a IPv4-over-IPv6
   tunnel endpoint. This is illustrated in figure 1 of [DESP2008].

   Again the DHCPv4 client can be either CPE implementing the
   distributed NAT, or a host having internal NAT.

2.6 Efficiency issues in dynamic and static port allocation methods

   With the port-restricted IPv4 address allocation method, ports are
   allocated statically providing benefits as described, while carrier
   grade NAT based proposals, such as DS-Lite [DURA2008], have a
   dynamic port mapping, but require NATs. The obvious result is that
   DS-Lite is more efficient in sharing single public IPv4 address for
   multiple hosts, but with related downsides. Thus there is a trade-
   off that has to be taken into account when making deployment
   decisions.

   The seriousness of efficiency difference is decreased when more
   services become available in IPv6 and thus will cease to consume
   IPv4 address and port space. In this regard it is important to have
   very port consuming services directly IPv6-accessible.

3. DHCPv4 Options for allocating port restricted public IPv4 address

   This section defines new dhcpv4 options, which would allow
   allocation of port restricted IPv4 addresses.

3.1 Option for offering port restricted IPv4 address

   The option layout is depicted below:

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Option Code  |  length        | IPv4 address                ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ... IPv4 address                |     beginning port range      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ending port range         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Code

          OPTION-IPv4-OPR (TBD) - 1     byte

   Length

          1 byte, value=8

   IP address

          Public IPv4 address


Bajko & Savolainen        Expires May 2, 2009                 [Page 8]


Port restricted IP address assignment                   November 2008

   Beginning port range

          beginning source port number, which can be used in
          conjunction with the IP address

   Ending port range

          last source port number, which can be used in conjunction
          with the IP address


3.2 Option for requesting port restricted IPv4 address

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Option Code  |  length        | IPv4 address                ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ... IPv4 address                |     beginning port range      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ending port range         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Code

          OPTION-IPv4-RPR (TBD) - 1     byte

   Length

          1 byte, value=8

   IP address

          Public IPv4 address

   Beginning port range

          beginning source port number, which can be used in
          conjunction with the IP address

   Ending port range

          last source port number, which can be used in conjunction
          with the IP address


4. Option Usage

4.1 Client Behaviour

   A client which supports the extensions defined in this document,
   SHOULD insert the option OPTION-IPv4-RPR, by setting the IPv4
   address field to 0.0.0.0, the beginning and ending port numbers to

Bajko & Savolainen        Expires May 2, 2009                 [Page 9]


Port restricted IP address assignment                   November 2008

   zero, into a DHCPDISCOVER message, to explicitly let the server know
   that it supports port restricted IPv4 addresses.

   When a client, which supports the options defined in this document,
   receives a DHCPOFFER with the 'yiaddr' (client IP address) field set
   to 0.0.0.0, it SHOULD check for the presence of OPTION-IPv4-OPR
   option field. If such an option is present, the client MAY send a
   DHCPREQUEST message and insert the option OPTION-IPv4-RPR with the
   IP address and port ranges received in the OPTION-IPv4-OPR option of
   the previous DHCPOFFER. The client MUST NOT include a 'Requested IP
   Address' DHCP option (code 50) into this DHCPOFFER.

   The client MUST NOT insert the IP address received in OPTION-IPv4-
   OPR into the 'Requested IP Address' DHCP option (code 50).

   When the client receives a DHCPACK message with an OPTION-IPv4-OPR
   option, it MAY start using the specified IP address in conjunction
   with the source ports specified. The client MUST NOT use the IP
   address with different source port numbers, as that may result in a
   conflict, since the same IP address with a different source port
   range may be assigned to a different client. Furthermore, the client
   MUST notice the situation where an outgoing IP packet has the same
   IP address as destination address than the client itself has, but
   the port number is not belonging to the allocated range. In this
   case the client MUST detect that the packet is not destined for
   itself, and it MUST send it forward.

   In case the initial port range received by the client from the
   server is exhausted and the client needs additional ports, it MAY
   request so by sending a new DHCPDISCOVER message.

   A client MUST NOT include an OPTION-IPv4-OPR option field into any
   DHCP message it generates.

4.2 Server Behaviour

   When a server, which supports the options defined in this document,
   receives a DHCPDISCOVER message, it SHOULD check the presence of the
   OPTION-IPv4-RPR option. If that option is present, the server SHOULD
   allocate port restricted IPv4 address to the client, and save the
   unrestricted addresses for clients which do not support the
   extensions defined in this document. If OPTION-IPv4-RPR is not
   present in DHCPDISCOVER, the server SHOULD allocate full
   unrestricted public or private [RFC1918] IPv4 address to the client,
   whenever available, by generating a DHCPOFFER as described in
   [RFC2131].

   When a server, which supports the options defined in this document,
   receives a DHCPDISCOVER message and can only offer port restricted
   IP address to the client, it MUST set the 'yiaddr' (client IP
   address) field of the DHCPOFFER message to 0.0.0.0 and SHOULD insert


Bajko & Savolainen        Expires May 2, 2009                [Page 10]


Port restricted IP address assignment                   November 2008

   the OPTION-IPv4-OPR option field by specifying the IP address and
   allowed port range.

   When a server, which supports the options defined in this document,
   receives a DHCPDISCOVER message from a client without the OPTION-
   IPv4-RRP, and knows by means outside the scope of this document,
   that the client supports the usage of port-restricted IPv4 addresses
   (or it is only entitled to be provisioned with such addresses), MUST
   set the 'yiaddr' (client IP address) field of the DHCPOFFER message
   to 0.0.0.0 and SHOULD insert the OPTION-IPv4-OPR option field by
   specifying the IP address and allowed port range.

   When the server receives a DHCPREQUEST message from the client with
   an OPTION-IPv4-RPR option field containing the IP address and port
   range it has previously offered to the client, the server MUST send
   a DHCPACK, where the 'yiaddr' (client IP address) field is set to
   0.0.0.0 and the server MUST include the OPTION-IPv4-OPR option
   including the IP address and port range the client requested.

   When the server receives a DHCPREQUEST message from the client with
   an OPTION-IPv4-RPR option field containing an IP address and port
   range it has previously not offered to the client, the server MUST
   send a DHCPNAK to the client.

   When the server detects that a client with a specific hardware
   address, having already been allocated with a port restricted IP
   address, sent another DHCPDISCOVER, it MAY, based on local policy,
   offer the client with additional port restricted IP address.

   A server MUST NOT include an OPTION-IPv4-RPR option field into any
   DHCP message it generates. A server MUST ignore any OPTION-IPv4-OPR
   options in DHCP messages generated by clients.

   A server SHOULD ensure the client is residing on an access link
   where usage of port-restricted addresses are not causing problems,
   before allocating it a port restricted IPv4 address.

5. Applicability

   The immediate applicability of such a solution is in 3GPP [3GP23401]
   or WiMAX [WMFS21.2] compliant mobile networks, where cellular hosts
   can directly utilize the option without separate gateway or consumer
   premises gateway being present. The new options can be utilized both
   in point-to-point links and/or IPv4-over-IPv6 tunnels.

   This document does not address the issue of how clients configured
   with port restricted IP addresses would handle protocols that run
   directly over IP (e.g. ICMP). That problem needs further
   consideration.

   The server leasing the port restricted IP address, or a gateway in
   the network, (e.g. the first hop router of a point-to-point link)

Bajko & Savolainen        Expires May 2, 2009                [Page 11]


Port restricted IP address assignment                   November 2008

   MUST enforce the restricted port range policy by filtering out
   packets sent using out of range source ports.

6. IANA considerations

   This document defines two new DHCPv4 options as described in section
   2.

   Offered Port Restricted IP Address Option for DHCPv4 (OPTION-IPv4-
   OPR) TBD

   Requested Port Restricted IP Address Option for DHCPv4 (OPTION-IPv4-
   RPR) TBD

7. Open issues

   Handling ICMP and other protocols running natively on top of IP is a
   challenge when multiple hosts share the same IP address.

   As the new DHCP options are designed only for point-to-point links,
   usage of these options on shared mediums such as Ethernet is not
   recommended, as there would be possible problems with ARP. If port-
   restricted IP addresses are going to be taken into use, it MUST be
   ensured that they are only used in environments where their usage
   does not interfere with standard IP communication.

8. Security considerations

   The solution is vulnerable to DoS when used in shared medium or when
   access network authentication is not a prerequisite to IP address
   assignment. The solution SHOULD only be used on point-to-point
   links, tunnels, and/or in environments where authentication at link
   layer is performed before IP address assignment, and not shared
   medium.

9. Normative References

   [RFC2131]    Droms, R., "Dynamic Host Configuration Protocol",
                RFC2131, March 1997

10. Informative References

   [RFC1918]    Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de
                Groot, G., Lear, E., "Address Allocation for Private
                Internets", RFC1918, February 1996

   [WING2008]   Wing, D., Ward, D., Durand, A. "A Comparison of
                Proposals to Replace NAT-PT", September 2008, draft-
                wing-nat-pt-replacement-comparison-00

   [DESP2008]   Despres, R., "A Scalable IPv4-IPv6 Transition
                Architecture Need for an address-port-borrowing-

Bajko & Savolainen        Expires May 2, 2009                [Page 12]


Port restricted IP address assignment                   November 2008

                protocol (APBP) ", July 2008, draft-despres-v6ops-apbp-
                01

   [ARKK2008]   Arkko, J., Townsley, M., "IPv4 Run-Out and IPv4-IPv6
                Co-Existence Scenarios", September 2008, draft-arkko-
                townsley-coexistence-00

   [DURA2008]   Durand, A., Droms, R., Haberman, B., Woodyatt, J.
                "Dual-stack lite broadband deployments post IPv4
                exhaustion", September 2008, draft-durand-softwire-
                dual-stack-lite-00

   [MAEN2008]   Maennel, O., Bush, R., Cittadini, L., Bellovin, S., "A
                Better Approach than Carrier-Grade-NAT", 2008,
                Technical Report CUCS-041-08

   [WMFS21.2]   WiMAX Forum, "WiMAX Forum Network Architecture, (Stage
                2: Architecture Tenets, Reference Model and Reference
                Points)", January 2008, Release 1, Version 1.2

   [WMFS31.2]   WiMAX Forum, "WiMAX Forum Network Architecture, (Stage
                3: Detailed Protocols and Procedures)", January 2008,
                Release 1, Version 1.2

   [3GP23401]   3rd Generation Partnership Project (3GPP), Technical
                Specification Group Services and System Aspects,
                "General Packet Radio Service (GPRS) enhancements for
                Evolved Universal Terrestrial Radio Access Network (E-
                UTRAN) access (Release 8)", September 2008, 3GPP TS
                23.401 V8.3.0

   [3GP23060]   3rd Generation Partnership Project (3GPP), Technical
                Specification Group Services and System Aspects,
                "General Packet Radio Service (GPRS); Service
                description; Stage 2 (Release 8)", September 2008, 3GPP
                TS 23.060 V8.2

   [3G2X0011]   3rd Generation Partnership Project 2 (3GPP2), "cdma2000
                Wireless IP Network Standard: Introduction", August
                2003, 3GPP2 X.S0011-001-C version 1.0.0


11. Author's Addresses

   Gabor Bajko
   Email: gabor(dot)bajko(at)nokia(dot)com

   Teemu Savolainen
   Hermiankatu 12 D
   FI-33720 TAMPERE
   FINLAND


Bajko & Savolainen        Expires May 2, 2009                [Page 13]


Port restricted IP address assignment                   November 2008

   Email: teemu.savolainen@nokia.com




















































Bajko & Savolainen        Expires May 2, 2009                [Page 14]


Port restricted IP address assignment                   November 2008

   Full 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.

   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.


   Intellectual Property

   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.


   Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).






Bajko & Savolainen        Expires May 2, 2009                [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/