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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 5678

MIPSHOP WG                                                  Gabor Bajko
Internet Draft                                                    Nokia
Intended Status: Proposed Standard                            Subir Das
Expires: December 22, 2008                                    Telcordia
                                                          June 22, 2008


  Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
                    Mobility Server (MoS) discovery
                    draft-ietf-mipshop-mos-dhcp-options-03


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 October 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document defines a number of Dynamic Host Configuration
   Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) options that contain a
   list of domain names or IP addresses that can be mapped to servers
   providing IEEE 802.21 type of Mobility Services. These Mobility
   Services are used to assist an MN in handover preparation (network
   discovery) and handover decision (network selection). The services
   addressed by this document are the Media Independent Handover
   Services defined in [IEEE802.21].

Conventions used in this document

G. Bajko & S Das           Expires 12/22/08                  [Page 1]

 Mobility Services DHCP Options                          December 2008

   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

   Mobility Services: comprises of a set of different services provided
   by the network to mobile nodes to facilitate handover preparation
   and handover decision.

   Mobility Server: a network node providing Mobility Support Services.

   MIH: Media Independent Handover, as defined in [IEEE802.21].

   MIH Service: IS, ES or CS type of service, as defined in
   [IEEE802.21].

Table of Content

   1. Introduction .................................................2
   2. DHCPv4 Options for MoS Discovery..............................3
        2.1 Domain Name List........................................5
        2.2 IPv4 Address List.......................................6
   3. DHCPv4 Relay Agent MoS Option.................................6
        3.2.1. IPv4 MoS Relay Agent Sub-option......................7
   4. DHCPv6 Options for MoS Discovery..............................6
        4.1 IPv6 MoS Identifier Option..............................6
        4.2 IPv6 Relay Agent MoS Option.............................9
        4.3 IPv6 MoS Information Option............................11
   5. Option Usage.................................................13
        5.1 Usage of DHCPv4 Options for MoS Discovery..............13
        5.2 Usage of DHCPv6 Options for MoS Discovery..............14
   6. Security Considerations .....................................15
   7. IANA Considerations .........................................15
   8. Acknowledgements ............................................16
   9. Normative References ........................................16
   10. Informative References .....................................17
   11. Author's Addresses .........................................17

1. Introduction

   IEEE 802.21 [IEEE802.21] defines three distinct service types to
   facilitate link layer handovers across heterogeneous technologies:

   a) Information Services (IS)
        IS provides a unified framework to the higher layer entities
   across the heterogeneous network environment to facilitate discovery
   and selection of multiple types of networks existing within a
   geographical area, with the objective to help the higher layer
   mobility protocols to acquire a global view of the heterogeneous
   networks and perform seamless handover across these networks.

G. Bajko & S. Das          Expires 12/22/08                  [Page 2]

Mobility Services DHCP Options                           December 2008

     b) Event Services (ES)
        Events may indicate changes in state and transmission behavior
   of the physical, data link and logical link layers, or predict state
   changes of these layers. The Event Service may also be used to
   indicate management actions or command status on the part of the
   network or some management entity.

   c) Command Services (CS)
        The command service enables higher layers to control the
   physical, data link, and logical link layers. The higher layers may
   control the reconfiguration or selection of an appropriate link
   through a set of handover commands.

   In IEEE terminology these services are called Media Independent
   Handover (MIH) services. While these services may be co-located,
   the different pattern and type of information they provide does not
   necessitate the co-location.

   An MN may make use of any of these MIH service types separately or
   any combination of them. In practice a Mobility Server may not
   necessarily host all three of these MIH services together, thus there
   is a need to discover the MIH services types separately.

   This document defines a new dhcpv4 option called MoS option, which
   allows the MN to locate a Mobility Server which hosts the desired
   service type (i.e. IS, ES or CS)as defined in [IEEE802.21]. The MoS
   information type defines sub-options for different services. The
   document also defines three DHCPv6 options which allow the MN to
   discover Mobility Servers hosting MIH services in different
   deployment scenarios. Apart from manual configuration, this is one
   of the possible solutions for locating a server providing Mobility
   Services.

2. DHCPv4 Option for MoS Discovery

   This section describes the MoS option for DHCPv4.
   The MoS option begins with a option code followed by a length and
   sub-options. The value of the length octet does not include itself
   or the option code. 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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Sub-Option 1                              |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       ...                                     |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Sub-Option n                              |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
G. Bajko & S. Das           Expires 12/22/08                   [Page 3]

 Mobility Services DHCP Options                         December 2008

   Option Code

                 OPTION-IPv4-MoS (TBD) - 2 bytes

            Length

                 2 bytes
            Sub-options

               A series of DHCPv4 sub-options.

   When the total length of a MoS option exceeds 255 octets, the
   Procedure outlined in [RFC3396] MUST be employed to split the
   option into multiple, smaller options.

   A sub-option begins with a sub-option Type followed by a length(N)
   and sub-option value. The value of the length octet does not include
   itself or the option code. Sub-option value has two encodings,
   specified by the encoding byte ('enc') that follows the code byte.
   If the encoding byte has the value 0, it is followed by a list of
   domain names, as described below (Section 2.1). If the encoding byte
   has the value 1, it is followed by one or more IPv4 addresses
   (Section 2.2).

   All implementations MUST support both encodings. A DHCP server MUST
   NOT mix the two encodings in the same DHCP message, even if it sends
   two different instances of the same option. Attempts to do so would
   result in incorrect client behavior as DHCP processing rules call
   for the concatenation of multiple instances of an option into a
   single option prior to processing the option [RFC3396].

   The sub-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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sub-opt Type  |         length                |    enc        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              FQDN or IP Address                               |
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The sub-option Types are summarized below.
      +--------------+---------------+
      |  Sub-opt     | Service       |
      |   Type*      | Name          |
      +==============+===============+
      |    1         |   IS          |
      +--------------+---------------+
      |    2         |   ES          |
      +--------------+---------------+

G. Bajko & S. Das          Expires 12/22/08                    [Page 4]

Mobility Services DHCP Options                           December 2008

      +--------------+---------------+
      |    3         |  IS and ES    |
      +--------------+---------------+
      |    4         |   CS          |
      +--------------+---------------+
      |    5         |  IS and CS    |
      +--------------+---------------+
      |    6         |  ES and CS    |
      +--------------+---------------+
      |    7         | IS, CS and ES |
      +--------------+---------------+

*Note: The values ?0? '8' to '255' are reserved and MUST NOT be
used.

    2.1 Domain Name List

   If the 'enc' byte has a value of 0, the encoding byte is followed by
   a sequence of labels, encoded according to Section 3.1 of [RFC1035],
   quoted below:

        Domain names in messages are expressed in terms of a sequence
        of labels. Each label is represented as a one octet length
        field followed by that number of octets.  Since every domain
        name ends with the null label of the root, a domain name is
        terminated by a length byte of zero. The high order two bits of
        every length octet must be zero, and the remaining six bits of
        the length field limits the label to 63 octets or less. To
        simplify implementations, the total length of a domain name
        (i.e., label octets and label length octets) is restricted to
        255 octets or less.

   [RFC1035] encoding was chosen to accommodate future international-
   lized domain name mechanisms. The minimum length for this encoding
   is 3.

   The option MAY contain multiple domain names, but these SHOULD refer
   to different NAPTR records, rather than different A records. The
   client MUST try the records in the order listed, applying the
   mechanism described in [MoS-DNS] for each. The client only resolves
   the subsequent domain names if attempts to contact the first one
   failed or yielded no common transport protocols between the MN and
   the server.

   Use of multiple domain names is not meant to replace NAPTR and SRV
   records, but rather to allow a single DHCP server to indicate MIH
   servers operated by multiple providers.

   The sub-option for this encoding has the following format:




G. Bajko & S. Das          Expires 12/22/08                   [Page 5]

Mobility Services DHCP Options                           December 2008


           Type Len enc DNS name of MoS server
         +-----+---+---+-----+-----+-----+-----+-----+--
         |1..7 | n | 0 |  s1 |  s2 |  s3 |  s4 | s5  |  ...
         +-----+---+---+-----+-----+-----+-----+-----+--

   As an example, consider the case where the server wants to offer
   two MIH IS servers, "example.com" and "example.net".  These would
   be encoded as follows:
   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |1..7|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
   +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   +---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+


2.2 IPv4 Address List

   If the 'enc' byte has a value of 1, the encoding byte is followed by
   a list of IPv4 addresses indicating appropriate MIH servers
   available to the MN. Servers MUST be listed in order of preference.

   Its minimum length is 5, and the length MUST be a multiple of 4 plus
   one. The sub-option for this encoding has the following format:

           Code Len enc IPv4 Address 1 IPv4 Address 2
         +-----+---+---+-----+----+---+----+----+--
         |1..7 | n | 1 | a1  | a2 |a3 | a4 | a1 |  ...
         +-----+---+---+-----+----+---+----+----+--


3. IPv4 Relay Agent MoS Option

   This option carries the home network MoS information which was
   transferred to the NAS from AAAH by using [MoS-AAA]. The DHCP
   relay agent insert this option when forwarding client-originated
   DHCP packets to a DHCP server.


       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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Sub-options                       |
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Option-code

               OPTION-IPv4-MoS-RELAY (TBD) - 2 bytes


G. Bajko & S. Das          Expires 12/22/08                   [Page 6]

Mobility Services DHCP Options                           December 2008


            Length

               The length of sub-options

            Sub-options

               A series of IPv4 Relay Agent sub-options.

   When the total length of a Relay Agent MoS option exceeds 255
   octets, the procedure outlined in [RFC3396] MUST be employed to
   split the option into multiple, smaller options.

   A sub-option begins with a sub-option Type followed by a length(N)
   and sub-option value. The value of the length octet does not include
   itself or the option code. Sub-option value has two encodings,
   specified by the encoding byte ('enc')as described in Section 2.1
   and Section 2.2.


3.2.1. IPv4 MoS Relay Agent Sub-option

The sub-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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sub-opt Type  |         length                |    enc        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              FQDN or IP Address                               |
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The sub-option Types are summarized below.
      +--------------+---------------+
      |  Sub-opt     | Service       |
      |   Type*      | Name          |
      +==============+===============+
      |    1         |   IS          |
      +--------------+---------------+
      |    2         |   ES          |
      +--------------+---------------+
      |    3         |  IS and ES    |
      +--------------+---------------+
      |    4         |   CS          |
      +--------------+---------------+
      |    5         |  IS and CS    |
      +--------------+---------------+
      |    6         |  ES and CS    |
      +--------------+---------------+
      |    7         | IS, CS and ES |
      +--------------+---------------+

G. Bajko & S. Das          Expires 12/22/08                   [Page 7]

Mobility Services DHCP Options                           December 2008

*Note: The values ?0?, '8' to '255' are reserved and MUST NOT be
used.

 If the 'enc' byte has a value of 0, the encoding byte is followed by
 a sequence of labels, encoded according to Section 3.1 of [RFC1035]
 as described in Section 2.1.

 If the 'enc' byte has a value of 1, the encoding byte is followed by
 a list of IPv4 addresses indicating appropriate MIH servers
 available to the MN as described in Section 2.2.

4. DHCPv6 Options for MoS discovery

   This section introduces new DHCPv6 options used for MoS discovery.

   Whether the MN receives an MoS address from local or home network
   will depend on the actual network deployment. In general, following
   rules apply to discovery rules:
   a) In a split scenario, where the network access authentication is
   independent of the home network authentication, the MN will discover
   the MoS in the local (visited) network.

   b) In an integrated scenario, where the network access
   authentication is performed by the home network, the MN will
   discover the MoS as per the home network policy, usually stored in
   the subscription profile. When the policy dictates that an MoS
   located in the home network has to be used, the address of the MoS
   from the home network may be sent to a NAS (via AAA protocols) to
   the visited network during the authentication procedure. A DHCP
   relay agent may be provisioned accordingly to forward the MOS
   address to the DHCP Server.

   The DHCPv6 options defined in this section together with the
   procedures defined in section 4 can support both scenarios.


4.1 IPv6 MoS Identifier Option

   This option is included in the Information-request message and used
   to request the address of a specific (e.g., IS, ES, CS or any
   combination) MoS-type from a DHCP server.

       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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   MoS-type    |                Reserved                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Option Code

               OPTION-IPv6-MoS (TBD) - 2 bytes

G. Bajko & S. Das          Expires 12/22/08                    [Page 8]

 Mobility Services DHCP Options                           December 2008


            Length

               2 bytes

             MoS-Type*
                 1 byte

                 The type of Mobility Services the MN is looking for,
               i.e., IS, ES or CS or a combination of these:


                    +--------------+-------------- +
                    |  MoS-type    | MoS Name      |
                    |   value      |               |
                    +==============+===============+
                    |    1         |   IS          |
                    +--------------+---------------+
                    |    2         |   ES          |
                    +--------------+---------------+
                    |    3         |  IS and ES    |
                    +--------------+---------------+
                    |    4         |   CS          |
                    +--------------+---------------+
                    |    5         |  IS and CS    |
                    +--------------+---------------+
                    |    6         |  ES and CS    |
                    +--------------+---------------+
                    |    7         | IS, CS and ES |
                    +--------------+---------------+
     *Note: The values '0', '8' to '255' are reserved and MUST NOT be
     used.


4.2 IPv6 Relay Agent MoS Option

   This option carries the home network information which was
   transferred to the NAS from AAAH by using [MoS-AAA]. The DHCP
   relay agent sends this option to the DHCP server in the
   Relay-forward Message.


       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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Sub-options                       |
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


 G. Bajko & S. Das          Expires 12/22/08                  [Page 9]

Mobility Services DHCP Options                           December 2008

         Option-code

               OPTION-IPv6-MoS-RELAY (TBD) - 2 bytes

            Length

               The length of sub-options

            Sub-options

               A series of IPv6 Relay Agent sub-options.

4.2.1. IPv6 MoS Relay Agent Sub-option

   This sub-option carries the MoS information to the DHCP server.

       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-opt Code  |      Length                   |   MoS Type    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                    MoS Information                            .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Sub-opt-code

               An 8-bit unsigned integer for the type of the following
                MoS Information field. Possible values are:

                   1    MoS IP address list

                   2    MoS FQDN list

             Length

               1 + the length of MoS Information field.

             MoS-Type*
                 1 byte

                 The type of Mobility Services the MN is looking for,
               i.e., IS, ES or CS or a combination of these:

                    +--------------+-------------- +
                    |  MoS Type    | MoS Name      |
                    |   value      |               |
                    +==============+===============+
                    |    1         |   IS          |
                    +--------------+---------------+
                    |    2         |   ES          |
                    +--------------+---------------+
                    |    3         |  IS and ES    |
                    +--------------+---------------+
  G. Bajko & S. Das          Expires 12/22/08                 [Page 10]

Mobility Services DHCP Options                           December 2008

                    +--------------+---------------+
                    |    4         |   CS          |
                    +--------------+---------------+
                    |    5         |  IS and CS    |
                    +--------------+---------------+
                    |    6         |  ES and CS    |
                    +--------------+---------------+
                    |    7         | IS, CS and ES |
                    +--------------+---------------+

   *Note: The values '0', '8' to '255' are reserved and MUST NOT be
     used.

            MoS Information

               An MoS IP address or MoS FQDN.

   When the sub-opt-code is set to 1, the MoS Information field MUST
   contain the 128-bit IPv6 address of the MoS.

   When the sub-opt-code is set to 2, the MoS Information field MUST
   contain the FQDN of the MoS as described in Section 8 of [RFC3315].

   Multiple sub-options may exist in a IPv6 Relay Agent option to carry
   more than one MoS Information (IPv6 address or FQDN).

4.3 IPv6 MoS Information Option

   This option is included in the Reply message and used to carry MoS
   information to the mobile node in the form of one or more of MoS IP
   address(es) or MoS FQDN(s).

       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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                          Sub-options                          .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Option Code

               OPTION-IPv6-MoSINF (TBD)- 2 bytes

            Length

               The length of sub-options

            sub-options

               A series of MoS  Information sub-options.


G. Bajko & S. Das          Expires 12/22/08                  [Page 11]

Mobility Services DHCP Options                           December 2008



4.3.1 MoS Information Sub-option

   This sub-option carries the assigned MoS information to the DHCP
   client.

       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-opt Code  |     Length                    |     MoS Type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                     MoS Information                           .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Sub-opt Code

               An 8-bit unsigned integer for the type of the following
               MoS Information field. Possible values are:

                   1    MoS IP address

                   2    MoS FQDN

            Length

               1 + length of MoS Information field.

              MoS-Type*
                 1 byte

                 The type of Mobility Services the MN is looking for,
               i.e., IS, ES or CS or a combination of these:

                    +--------------+-------------- +
                    |  MoS Type    | MoS Name      |
                    |   value      |               |
                    +==============+===============+
                    |    1         |   IS          |
                    +--------------+---------------+
                    |    2         |   ES          |
                    +--------------+---------------+
                    |    3         |  IS and ES    |
                    +--------------+---------------+
                    |    4         |   CS          |
                    +--------------+---------------+
                    |    5         |  IS and CS    |
                    +--------------+---------------+
                    |    6         |  ES and CS    |
                    +--------------+---------------+
                    |    7         | IS, CS and ES |
                    +--------------+---------------+
 G. Bajko & S. Das          Expires 12/22/08                  [Page 12]

Mobility Services DHCP Options                           December 2008


   *Note: The values '0', '8' to '255' are reserved and MUST NOT be
     used.

              MoS Information

               An MoS IP address or MoS FQDN to be provided to a mobile
               node as indicated in the sub-opt-code.

   The sub-opt-code, sub-opt-len and MoS Information fields are set in
   the same manner as those of an IPv6 MoS Relay Agent sub-option.


5. Option Usage

5.1 Usage of DHCPv4 Options for MoS Discovery

   The requesting and sending of the proposed DHCPv4 options follow the
   rules for DHCP options in [RFC2131].

5.1.1 Mobile Node behavior

   The mobile node may perform the MoS information discovery procedure
   either during initial association with a network or when the
   mobility service is required. It may also try to perform the MoS
   information discovery when it lacks the network information for MoS
   or needs to change the  MoS for some reasons, for instance, to
   recover from the single point of failure of the existing MoS.

   In order to acquire the MoS information, the mobile node MUST send
   either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or
   a unicast server address, respectively. In this message the mobile
   node (DHCP client) MUST include the sub-opt Type for the MoS
   Discovery in the sub-options field.

5.1.2 DHCP Server behavior

   When the DHCP server receives the DHCPDISCOVER or DHCPINFORM message
   with the MoS Discovery option in the options field, the DHCP server
   MUST follow the [RFC2131] logic to construct either a DHCPOFFER or
   DHCPACK message including the MoS Discovery option. The reply
   message may contain the IP address or the FQDN of the MoS Server.

   The DHCP server MUST always construct the response according to
   the Sub-opt Type requested by the DHCP client and not based upon
   the Sub-opt Type that is inserted by the relay agent.






G. Bajko & S. Das          Expires 12/22/08                 [Page 13]

 Mobility Services DHCP Options                          December 2008

    In case that the server cannot find any MoS information for a
   specific MoS sub-opt Type, it MUST return the MoS option with a
   sub-option by setting the sub-opt Type to the requested
   sub-opt Type and the length of the sub-option to 1.


5.1.3 DHCP Relay Agent behavior

   Upon receiving the DHCP-REQUEST from the mobile node, the

   DHCP relay agent MUST forward the message to the DHCP server as per
   [RFC2131]. If the relay agent determines that the AAAV/NAS has
   passed MoS information for this mobile node and has available MoS
   information for it, the relay agent MUST include the MoS information
   in the IPv4 Relay Agent MoS option, and insert this option in
   client-originated DHCP packets to a DHCP server. In case the relay
   agent does not maintain any MoS information for the requesting
   mobile node, it simply forwards the received message
   to the DHCP server according to the [RFC2131].

   Servers recognizing the IPv4 Agent MoS option may use the
   information to implement MoS IP address or other parameter
   assignment policies.  The DHCP Server echoes the
   option back verbatim to the relay agent in server-to-client replies,
   and the relay agent strips the option before forwarding the reply to
   the client according to the [RFC2131].


5.2 DHCPv6 Options for MoS discovery

   The requesting and sending of the proposed DHCPv6 options follow the
   rules for DHCP options in [RFC3315].

5.2.1 Mobile node behavior

   The mobile node may perform the MoS information discovery procedure
   either during initial association with a network or when the
   mobility service is required. It may also try to perform the MoS
   information discovery when it lacks the network information for MoS
   or needs to change the  MoS for some reasons, for instance, to
   recover from the single point of failure of the existing MoS

   In order to acquire the MoS address, the mobile node MUST send an
   Information-request message to the All_DHCP_Relay_Agents_and_Servers
   multicast address. In this message the mobile node (DHCP client)
   MUST include the Option Code for the MoS Discovery option in the
   option_code.

5.2.2 DHCP Relay Agent behavior

   Upon receiving the Information-request from the mobile node, the
   DHCP relay agent MUST forward the message to the DHCP server as per
   [RFC3315].

G. Bajko & S. Das          Expires 12/22/08                  [Page 14]

Mobility Services DHCP Options                            December 2008

   If the relay agent determines that the AAAV/NAS has passed MoS
   information for this mobile node and has available MoS information
   for it, the relay agent MUST include the MoS information in the IPv6
   Relay Agent option, and attach this option in the Relay-forward
   message.

   In case the relay agent does not maintain any MoS information for
   the requesting mobile node, it simply forwards the received message
   to the DHCP server according to the [RFC3315].


   Upon receiving a Relay-reply message from the DHCPv6 server, the
   relay agent MUST follow the guidelines defined in [RFC3315]. The
   relay agent extracts the Reply message from the Relay Message option
   in the Relay-reply message and relays it to the mobile node.

5.2.3 DHCP Server behavior

   When the DHCP Server receives the Information-request message with
   the MoS Identifier option in the Relay-forward message, it looks for
   a MIP6 Relay Agent Option containing MoS Information. The
   Information-request message may not include the MIP6 Relay Agent
   option in case there was no MoS information available at the NAS /
   DHCP Relay Agent for a mobile node.

   The DHCP server MUST follow the following logic to construct a Reply
   message with the MoS Information option, and include the Reply
   message in the payload of a Relay Message option of Relay-reply
   message.

   If the DHCP server has the requested MoS information, it MUST
   include the information in the MoS Information option. The server
   may provide the matching information either extracted from the IPv6
   MOS Relay Agent option or from the preconfigured information
   available locally.

   The DHCP server MUST always construct the response
   according to the MoS Type requested by the DHCP client and not
   based upon the MoS Type that is inserted by the relay agent.

    In case that the server cannot find any MoS information for a
   specific MoS type, it MUST return the MoS Information option with
   a sub-option by setting the MoS type to the requested MoS Type
   and the length of the sub-option is to 4.


6. Security Considerations

   The security considerations in [RFC2131] apply. If an adversary
   manages to modify the response from a DHCP server or insert its own
   response, an MN could be led to contact a rogue Mobility Server,

G. Bajko & S. Das          Expires 12/22/08                   [Page 15]

Mobility Services DHCP Options                            December 2008

  possibly one that then would provide wrong information, event or
   command for handover.

   It is recommended to use either DHCP authentication option described
   in [RFC3118] where available, or rely upon link layer security.

   This will also protect the denial of service attacks to DHCP
   servers.[RFC3118] provides mechanisms for both entity authentication
   and message authentication.

7. IANA Considerations

  This document defines one new DHCPv4 option as described in section
  2.

   MoS Option for DHCPv4 (OPTION-IPv4-MoS)                 TBD
   Mos Option for DHCPv4 Relay (OPTION-IPV4-MoS-RELAY)     TBD

   This document creates a new registry for the Sub-Option field in the
   MoS DHCPv4 option called the "MoS Service Type".
      IS                       1
      ES                       2
      IS and ES                3
      CS                       4
      IS and CS                5
      ES and CS                6
      IS, CS and ES            7

  The values '0', '8' to '255' are reserved and MUST NOT be used. New
  values can be allocated by Standards Action or IESG approval.

  This document also defines three new DHCPv6 options as described in
  sections 3.1 and 3.2

     IPv6-MoSINF (IPv6 MoS Information Option)             TBD
     IPv6-MoS (IPv6 MoS Identifier Option)                 TBD
     IPv6-MoS-RELAY (IPv6 Relay Agent MoS Option)          TBD

   This document creates a new registry for the "MoS Type" field in
   the IPv6 MoS Relay Agent Sub-option (section 3.2.1) and the MoS
   Information Sub-option (section 3.3.1).
        IS                       1
        ES                       2
        IS and ES                3
        CS                       4
        IS and CS                5
        ES and CS                6
        IS, CS and ES            7

  The values '0', '8' to '255' are reserved and MUST NOT be used. New
  Values can be allocated by Standards Action or IESG approval.



G. Bajko & S. Das          Expires 12/22/08                   [Page 16]

Mobility Services DHCP Options                            December 2008


8. Acknowledgements

   Authors would like to acknowledge the following individuals for
   their valuable comments.
   Vijay Devarapalli, Telemaco Melia, and Yoshihiro Ohba

9. Normative References

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

   [RFC1035] Mockapetris, P., "Domain names - implementation and
      specification", STD 13, RFC 1035, November 1987.



  [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
      RFC3396, November 2002.

   [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001

   [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6),
      Droms et al, July 2003

10. Informative References

   [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area
      Networks: Media Independent Handover Services

   [MoS-DNS] Bajko, G., "Locating Mobility Servers",
      draft-ietf-mipshop-mos-dns-discovery-01, (Work in Progress),
      May 2008.

   [MoS-AAA] Stuper, Patrick et.al, ?Diameter extensions for MoS
      Discovery? draft-stupar-dime-mos-options-00?
      (Work in progress), February, 2008


11. Authors' Addresses

   Gabor Bajko
   Nokia
   e-mail: gabor.bajko@nokia.com

   Subir Das
   Telcordia Technologies Inc.
   e-mail: subir@research.telcordia.com




G. Bajko & S. Das          Expires 12/22/08                   [Page 17]

Mobility Services DHCP Options                            December 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).





G. Bajko & S. Das          Expires 12/22/08                 [Page 18]


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