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

Versions: 00 01

Network Working Group                                  M. Boucadair, Ed.
Internet-Draft                                                  P. Levis
Intended status: Standards Track                           J-L. Grimault
Expires: June 24, 2010                                    France Telecom
                                                           T. Savolainen
                                                                G. Bajko
                                                                   Nokia
                                                       December 21, 2009


   Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP
                          Addresses Solutions
            draft-boucadair-dhcpv6-shared-address-option-01

Abstract

   This memo defines Dynamic Host Configuration Protocol version 6
   (DHCPv6) Options to be used in the context of shared IP address
   solutions.  In some deployment scenarios, DHCP (IPv4) cannot be used
   to configure customer devices because only IPv6 capabilities are
   deployed (e.g., DS-lite context or IPv6 Port Range).  Therefore,
   DHCPv6 may be used to convey IPv4-related configuration information
   such as Port Range and/or Port Extended IPv4 addresses.  This
   document defines also a DHCPv6 Option aiming to convey the IPv6
   prefix to be used to build IPv4 Embedded IPv6 addresses
   [I-D.ietf-behave-address-format].

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

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




Boucadair, et al.         Expires June 24, 2010                 [Page 1]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


   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 June 24, 2010.

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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

















Boucadair, et al.         Expires June 24, 2010                 [Page 2]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  IPv4 Address Option  . . . . . . . . . . . . . . . . . . . . .  5
   3.  Port Extended IPv4 Address DHCPv6 Option . . . . . . . . . . .  5
     3.1.  Option Format  . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Port Range Sub-Option  . . . . . . . . . . . . . . . . . .  7
     3.3.  Delegated Random Port Range Sub-Option . . . . . . . . . .  8
   4.  IPv4-Embedded IPv6 Address Format Option . . . . . . . . . . .  9
   5.  Supported IPv4-Embedded IPv6 Address Formats Option  . . . . . 12
   6.  Behaviour  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Port Mask Example . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
































Boucadair, et al.         Expires June 24, 2010                 [Page 3]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


1.  Introduction

   Within the context of IPv4 address depletion, several solutions have
   been submitted to the IETF to propose viable alternatives to double
   NAT [I-D.nishitani-cgn].  Examples of these solutions are
   [I-D.ietf-softwire-dual-stack-lite] and
   [I-D.boucadair-behave-ipv6-portrange].  These solutions propose to
   share a given global IPv4 address between several customers.  These
   solutions differ in the way they behave and particularly on the
   location of the NAT function.  In
   [I-D.boucadair-behave-ipv6-portrange] the NAT function stays at the
   CPE level and none lies in the network whilst in
   [I-D.ietf-softwire-dual-stack-lite] the NAT function is located in
   the network -in the DS-lite node- while the NAT in the CPE can be
   deactivated.  Nevertheless, [I-D.ietf-softwire-dual-stack-lite]
   supports the Extended Port IP address logic mainly for the
   enforcement of port forwarding service for instance.  Therefore,
   dedicated means such as [I-D.bajko-pripaddrassign] are required for
   the provisioning of pertinent information to constrain the source
   port number.  [I-D.bajko-pripaddrassign] specifications may be used
   when IPv4-enabled DHCP servers are deployed and corresponding DHCP
   clients enabled in customer devices, such as the CPE.

   Furthermore, both [I-D.ietf-softwire-dual-stack-lite] and
   [I-D.boucadair-behave-ipv6-portrange] assume that only IPv6 transfer
   capabilities are activated on the link connecting the customer's
   device to the access network.  IPv4-in-IPv6 tunneling capabilities
   can be put in place to allow DHCP exchanges and therefore
   [I-D.bajko-pripaddrassign] can be used to provision the customer
   device.  Nevertheless, in environments where no IPv4-enabled DHCP
   servers are maintained or no tunneling means are deployed to reach
   DHCP servers, alternative means to provision the customer's device
   are required.  This memo is an effort to meet this requirement.

   Note that [I-D.dhankins-softwire-tunnel-option] can be used to
   provide the customer device with the IPv6 address of a DS-lite CGN or
   a PRR (Port Range Router) node.

   Concretely, this document defines the following new DHCPv6 Options
   [RFC3315]:

   1.  IPv4 address: This option is used to convey a "full" IPv4
       address.

   2.  Port Extended IPv4 Address: This option carries an IPv4 address
       to be used in conjunction with an allocated Port Range.  In case
       of Port Range allocation, several customers are assigned with the
       same IPv4 Address.  This option defines the allowed port values



Boucadair, et al.         Expires June 24, 2010                 [Page 4]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


       to be used as source port number.  This option is completely
       independent of the IPv4 address Option above.

   3.  IPv4-embedded IPv6 address Format: This option is used to provide
       the device with the prefix to be used to build an IPv4-embedded
       IPv6 address, see for intance [I-D.ietf-behave-address-format].

   4.  Supported IPv4-embedded IPv6 address Formats: This option allows
       a DHCPv6 client to indicate the type of IPv4-embedded IPv6
       address format(s) it can handle.


2.  IPv4 Address Option

   This DHCPv6 Option carries an IPv4 address.  The DHCPv6 Option has
   the format shown in Figure 1 :

       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_IPV4_A            |           option-length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    IP Address (IPv4 Address)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      preferred-lifetime                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        valid-lifetime                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 1: IPv4 Address DHCPv6 Option

      - option-code: OPTION_IPV4_A (To be assigned by IANA)

      - option-length: 12.

      - preferred-lifetime: The preferred lifetime for the IPv4 address
      in the option, expressed in units of seconds.

      - valid-lifetime: The valid lifetime for the IPv4 address in the
      option, expressed in units of seconds.


3.  Port Extended IPv4 Address DHCPv6 Option







Boucadair, et al.         Expires June 24, 2010                 [Page 5]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


3.1.  Option Format

   The Port Extended IPv4 address DHCPv6 Option is used to specify a
   shared IPv4 address together with one range of ports (contiguous or
   not).

   The format of the Port Extended IPv4 address Option is provided in
   Figure 2.


        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_PORT_EXTENDED_A        |           option-length       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         sub-option-code       |         sub-option-len        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        sub-option-content                     |
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             ...                               |
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      preferred-lifetime                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        valid-lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




            Figure 2: Port Extended IPv4 Address DHCPv6 Option

      - option-code: OPTION_PORT_EXTENDED_A (To be assigned by IANA)

      - option-length: the length of enclosed sub-option(s) + 4.

      - sub-option code: specifies the code of the included sub-options.
      Two sub-codes are defined in this document: SUB_OPTION_PORT_MASK
      and SUB_OPTION_DELG_RAND.

      - sub-option-len: length of the sub-option.

      - sub-option-content: content of the sub-option





Boucadair, et al.         Expires June 24, 2010                 [Page 6]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


      - preferred-lifetime: The preferred lifetime for the Port Extended
      IPv4 address in the option, expressed in units of seconds.

      - valid-lifetime: The valid lifetime for the Port Extended IPv4
      address in the option, expressed in units of seconds.

3.2.  Port Range Sub-Option

   Figure 3 provides an overview of the Port Range sub-option.

   This sub-option is used to notify a remote peer about an IPv4 address
   to be used in conjunction with an allocated Port Range.  The Port
   Range is allocated on the form of a Port Mask to be applied when
   selecting a port value as a source port.  The Port Range Sub Option
   is used to infer a set of allowed port values.  A Port Mask defines a
   set of ports that all have in common a subset of pre-positioned bits.
   This set of ports is also called Port Range.

   A Port Mask is composed of a Port Range Value and a Port Range Mask.

   o  The Port Range Value indicates the value of the significant bits
      of the Port Mask.  The Port Range Value is encoded as follows:

      *  The significant bits may take a value of 0 or 1.

      *  All the other bits (non significant ones) are set to 0.

   o  The Port Range Mask indicates, by the bit(s) set to 1, the
      position of the significant bits of the Port Range Value.

   This DHCPv6 Sub Option provides a way to negotiate the port range to
   be allocated to the peer.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    SUB_OPTION_PORT_MASK       |         sub-option-len        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Port Extended IP Address (IPv4 Address)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Port Range Value         |      Port Range Mask          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                      Figure 3: Port Range Sub Option





Boucadair, et al.         Expires June 24, 2010                 [Page 7]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


      - sub-option-code: SUB_OPTION_PORT_MASK (To be assigned by IANA)

      - sub-option-len: 8.

      - Port Extended IP Address: specifies the shared IPv4 address

      - Port Range Value (PRV) (16 bits): PRV indicates the value of the
      significant bits of the Port Mask.

      - Port Range Mask (PRM) (16 bits): The Port Range Mask indicates,
      by the bit(s) set to 1, the position of the significant bits of
      the Port Range Value.

   An example of Port Range Mask is provided in Appendix A.

3.3.  Delegated Random Port Range Sub-Option

   Figure 4 provides an overview of the delegated random Port Range:


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    SUB_OPTION_DELG_RAND       |         sub-option-len        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Port Extended IP Address (IPv4 Address)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         function                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         starting point        |    number of delegated ports  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           key K (128 bits)                    |
       |                                                               |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 4: Delegated Random Port Option

      - sub-option-code: SUB_OPTION_DELG_RAND (To be assigned by IANA)

      - sub-option-len: 28.

      - Port Extended IP Address: specifies the shared IPv4 address

      - Function: A 32 bit field whose value is associated with
      predefined encryption functions.  For more information about this
      function, refer to [I-D.bajko-pripaddrassign].



Boucadair, et al.         Expires June 24, 2010                 [Page 8]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


      - starting point: A 16 bit value used as an input to the specified
      function.

      - Number of delegated ports: A 16bit value specifying the number
      of ports delegated to the client for use as source port values.

      - Key K: A 128 bit key used as input to the predefined function
      for delegated port calculation.


4.  IPv4-Embedded IPv6 Address Format Option

   [I-D.boucadair-behave-ipv6-portrange] defines a Port Range solution
   which assumes IPv6-only network for the delivery of both IPv4 and
   IPv6 connectivity services.  The solution is based on IPv4-in-IPv6
   encapsulation for the transport of IPv4 datagrams inside an IPv6-only
   network.  For these reasons, an IPv6 prefix is required to build
   destination IPv4-embedded IPv6 addresses of IPv4-in-IPv6 encapsulated
   datagrams issued by a port-restricted device.
   [I-D.ietf-behave-address-format] specifies the format of IPv4
   Embedded IPv6 address.

   Figure 5 provides an example of a structure of an IPv4-embedded IPv6
   address where "Pref6" is a well-known IPv6 prefix:

+----------------------------------------------------------------------...+
|       Pref6              |Dest. IPv4    |Dest.  |          0:0:0:0      |
|                          |address       |port   |                       |
+----------------------------------------------------------------------...+


              Figure 5: Example of IPv4-Embedded IPv6 Address

   The IPv4-embedded IPv6 address format used by a device depends on
   several parameters such as the ability of the device to use a port
   number or not when building an IPv4-embedded IPv6 address.  Hence
   there is a need to identify several formats.  This need is covered by
   the IPv4-embedded IPv6 address Format Option.

   The IPv4-embedded IPv6 address Format Option is structured as shown
   in Figure 6.










Boucadair, et al.         Expires June 24, 2010                 [Page 9]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


        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_INFER_V4V6             |           option-length       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      format-type              |     IPv6 Prefix length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                                                               |
       |                 IPv6 Prefix  (Variable)                       |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      preferred-lifetime                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        valid-lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



           Figure 6: IPv4-inferred IPv6 addresses Format Option

      - option-code: OPTION_INFER_V4V6 (To be assigned by IANA)

      - option-length: Variable.

      - format-type: Indicates the format type of the IPv4-embedded IPv6
      address.  The values so far defined are the following ones:

         - "1": When the format-type value is set to 1, the destination
         addresses of IPv4-in-IPv6 datagrams issued by the device have
         the following structure:


+-----------------------------------------------------------------------------+
|       IPv6 Prefix         (128 bits)                                        |
|                                                                             |
+-----------------------------------------------------------------------------+

                            Figure 7: Format Type (1)

         As a matter of fact, the IPv6 Prefix (128 bits long) is an IPv6
         address here.  The IPv4-in-IPv6 encapsulation scheme is the
         simple IPv4-in-IPv6 encapsulation.



         - "2": When the format-type value is equal to 2, the
         destination IPv6 addresses of IPv4-in-IPv6 datagrams issued by
         the device follow the following structure.  This format type is



Boucadair, et al.         Expires June 24, 2010                [Page 10]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


         defined in [I-D.boucadair-behave-ipv6-portrange].


+------------------------------------------------------------------------------+
|IPv6 Prefix (32 bits)| Dest. IPv4       |               0::0                  |
|                     | address (32 bits)|                                     |
+------------------------------------------------------------------------------+

                            Figure 8: Format Type (2)

         The IPv4-in-IPv6 encapsulation scheme is the simple IPv4-in-
         IPv6 encapsulation.

         - "3": When the format-type value is set to 3,

         a.  if the IPv4 packet to be sent encapsulated bears a protocol
             with port information (case of TCP and UDP, for example),
             the destination IPv6 address of the IPv4-in-IPv6 datagram
             transmitted by the device follows the following structure :
+------------------------------------------------------------------------------+
|IPv6 Prefix (32 bits)| Dest. IPv4       |Dest. Port|      0::0                |
|                     | address (32 bits)|(16 bits) |                          |
+------------------------------------------------------------------------------+

                              Figure 9: Format Type (3)

         b.  if the IPv4 datagram to be encapsulated bears a protocol
             without port number (e.g.  ICMP), the destination IPv6
             address of the IPv4-in-IPv6 datagram issued by the device
             SHOULD be sent to another IPv6 destination address than the
             destination address depicted in Figure 9.  For example,
             such packet without port number MAY be transmitted to a DS-
             lite CGN node.  Another alternative is to send such packet
             following the Format Type (2) even if Format Type (3) has
             been mandated by the DHCPv6 server to the client, but this
             behavior is NOT RECOMMENDED.

         The IPv4-in-IPv6 encapsulation scheme is the simple IPv4-in-
         IPv6 encapsulation.

         - Other format-type values can be defined later.  The format-
         type values from the value 32768 are not reserved.  They can be
         used in a ISP scope to encode a proprietary format-type.

      - IPv6 Prefix: Encloses the IPv6 prefix to be used to build IPv4-
      embedded IPv6 addresses.  When format-type 1 is used, this prefix
      is an IPv6 address.




Boucadair, et al.         Expires June 24, 2010                [Page 11]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


      - preferred-lifetime: The preferred lifetime for the IPv6 Prefix
      in the option, expressed in units of seconds.

      - valid-lifetime: The valid lifetime for the IPv6 Prefix in the
      option, expressed in units of seconds.


5.  Supported IPv4-Embedded IPv6 Address Formats Option

   A client MAY indicate the format-type values it can support (related
   to IPv4- embedded IPv6 address Formats Option) by including the
   Supported IPv4-embedded IPv6 address Formats Option in a DHCPv6
   Solicit, Request, Renew, Rebind, Confirm or Information-request
   message.

   The order in the list MAY indicate preference in format-types, the
   first value being the preferred one.

   The Supported IPv4-embedded IPv6 address Format Option is structured
   as shown in Figure 10.
        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_SUPPORT_INFER_V4V6    |           option-length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      format-type-1              |     ...                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      ...                        |     format-type-n           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 10: Supported IPv4-inferred IPv6 Address Formats Option

      - option-code: OPTION_SUPPORT_INFER_V4V6 (To be assigned by IANA)

      - option-length: permits to numerate the supported format-type
      values.

      option-length = 2 * number of format-type values.  In case of an
      odd number of format-type values, a padding of two "x00" octets is
      to be placed in the ending 16 bits.

      - format-type-i: the values of the format-type supported by the
      client.


6.  Behaviour

   A client MAY request IPv4 Address and/or Port Extended IPv4 Address
   and/or IPv4-embedded IPv6 address Format Option(s) by including the



Boucadair, et al.         Expires June 24, 2010                [Page 12]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


   corresponding Option codes into an Option Request Option (as per
   [RFC3315]).  This latter being itself included into a Solicit,
   Request, Renew, Rebind, Confirm or Information-request message.
   Doing so, the client can inform the server about options the client
   wishes to receive.

   The client MAY include IPv4 Address and/or Port Extended IPv4 Address
   and/or IPv4-embedded IPv6 address Format in Solicit, Request, Renew,
   Rebind, Confirm or Information request message as hints to the server
   about parameter values the client would like to be returned.  In such
   case, the Option Request Option MUST be sent in the message and
   includes the corresponding Option codes.  If the client sends the
   IPv4-embedded IPv6 address Formats as a hint to the server, the value
   of the format-type in the Option is the value of the format-type
   preferred by the client.

   A client MAY indicate the format-type values it can support (related
   to IPv4-embedded IPv6 address Format Option) by including the
   Supported IPv4-embedded IPv6 address Formats Option in a Solicit,
   Request, Renew, Rebind, Confirm or Information-request message.  If
   in the same message the client has also included the IPv4-embedded
   IPv6 address Format Option as a hint to the server, then the format-
   type values listed in the Supported IPv4-embedded IPv6 address
   Formats Option has to be taken by the server as complementary
   information.  In that case, for consistency reasons, the first
   format-type value indicated in the Supported IPv4-embedded IPv6
   address Formats Option MUST be the same value (i.e. the preferred
   one) as the one in the IPv4-embedded IPv6 address Format Option.

   If a client receives the IPv4 Address Option in conjunction with an
   IPv4-embedded IPv6 address Format Option, all IPv4 datagrams MUST be
   encapsulated in IPv6 according to the features indicated in this
   latter Option, meaning that the destination IPv6 addresses MUST be
   IPv4-embedded addresses as specified in the Option.

   If a client receives the Port Extended IPv4 Address Option, the
   client MUST constrain the source port number of included Port
   Extended IPv4 Address to be within the provisioned Port Range.  If a
   client receives the IPv4 Address Port Extended IPv4 Address Option in
   conjunction with the IPv4-embedded IPv6 address Format Option, all
   IPv4 datagrams MUST be encapsulated in IPv6 according to the features
   indicated in this latter Option, meaning that the destination IPv6
   addresses MUST be IPv4-embedded address as specified in the Option.

   If a client receives a Port Extended IPv4 Address Option but no Port
   Range Sub-Option included, it MUST use the conveyed IPv4 address as
   non restricted one.  If in addition, it has received an IPv4-embedded
   IPv6 address Format Option, all IPv4 datagrams MUST be encapsulated



Boucadair, et al.         Expires June 24, 2010                [Page 13]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


   in IPv6 according to the features indicated in this latter Option,
   meaning that the destination IPv6 addresses MUST be IPv4-embedded
   addresses as specified in the Option.

   If a client receives a Port Extended IPv4 Address Option with the
   Port Range Sub-Option enclosed but with the IPv4 address set to
   "0.0.0.0", the client MUST constrain all IPv4 communications to be
   within the allocated Port Range.  In such case, the IPv4 address the
   client will use is allocated by other means than by DHCPv6 Port
   Extended IPv4 Address Option (e.g. through DHCP (IPv4), IPv4 address
   derived from an IPv6 address, ... ).  It is NOT RECOMMENDED that the
   client or the server use the IPv4 Address Option in conjunction with
   a Port Extended IPv4 Address option with Port Range Sub-Option
   present and IPv4 address set to "0.0.0.0", because the use of the
   Port Extended IPv4 Address Option with a correct IPv4 address is more
   efficient.

   When a peer issues a request enclosing one or more options (defined
   in this document), if the server does not support this (ese)
   option(s), the DHCPv6 server ignores the corresponding option.


7.  IANA Considerations

   This document requests IANA to assign numbers for these DHCPv6
   options:

      - OPTION_IPV4_A

      - OPTION_PORT_EXTENDED_A

      - OPTION_INFER_V4V6

      - OPTION_SUPPORT_INFER_V4V6



   And the following sub-options:

      - SUB_OPTION_PORT_MASK

      - SUB_OPTION_DELG_RAND


8.  Security Considerations

   All security considerations described in [RFC3315] apply for this
   specification.



Boucadair, et al.         Expires June 24, 2010                [Page 14]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


9.  Acknowledgements

   The authors would like to thank Christian JACQUENET for his review.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

10.2.  Informative References

   [I-D.bajko-pripaddrassign]
              Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
              "Port Restricted IP Address Assignment",
              draft-bajko-pripaddrassign-02 (work in progress),
              October 2009.

   [I-D.boucadair-behave-ipv6-portrange]
              Boucadair, M., Levis, P., Grimault, J., Villefranque, A.,
              Kassi-Lahlou, M., Bajko, G., Lee, Y., Melia, T., and O.
              Vautrin, "Flexible IPv6 Migration Scenarios in the Context
              of IPv4 Address Shortage",
              draft-boucadair-behave-ipv6-portrange-04 (work in
              progress), October 2009.

   [I-D.dhankins-softwire-tunnel-option]
              Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol (DHCPv6) Option for Dual-Stack Lite",
              draft-dhankins-softwire-tunnel-option-05 (work in
              progress), November 2009.

   [I-D.ietf-behave-address-format]
              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
              draft-ietf-behave-address-format-03 (work in progress),
              December 2009.

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
              Y., and R. Bush, "Dual-stack lite broadband deployments
              post IPv4 exhaustion",



Boucadair, et al.         Expires June 24, 2010                [Page 15]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


              draft-ietf-softwire-dual-stack-lite-02 (work in progress),
              October 2009.

   [I-D.nishitani-cgn]
              Nishitani, T., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common Functions of Large Scale NAT
              (LSN)", draft-nishitani-cgn-03 (work in progress),
              November 2009.


Appendix A.  Port Mask Example

   The following figure (Figure 11) provides an example of the resulting
   Port Range when:

   - Port Range Mask is set to 0001010000000000 (5120) and

   - Port Range Value is set to 0000010000000000 (1024).

   Ports belonging to this port range must have the 4th bit (resp. the
   sixth one), from the left, set to 0 (resp. 1).  Only these ports will
   be used by the peer when enforcing the configuration conveyed by
   DHCPv6.


       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0|  Port Range Mask
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |   |
             |   | (two significant bits)
             v   v
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0|  Port Range Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x x x 0 x 1 x x x x x x x x x x|  Usable ports (x may take a value of 0 or 1).
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 11: Example of Port Range Mask and Port Range Value








Boucadair, et al.         Expires June 24, 2010                [Page 16]

Internet-Draft     Shared IP addresses DHCPv6 Options      December 2009


Authors' Addresses

   Mohamed Boucadair (editor)
   France Telecom
   3, Av Francois Chateaux
   Rennes  35000
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Pierre Levis
   France Telecom

   Email: pierre.levis@orange-ftgroup.com


   Jean-Luc Grimault
   France Telecom

   Email: jeanluc.grimault@orange-ftgroup.com


   Teemu Savolainen
   Nokia


   Email: teemu.savolainen@nokia.com


   Gabor Bajko
   Nokia


   Email: Gabor.Bajko@nokia.com
















Boucadair, et al.         Expires June 24, 2010                [Page 17]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/