[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

Internet Engineering Task force                            Gabor Bajko
Internet Draft                                                   Nokia
Intended Status: Proposed Standard                           Subir Das
Expires: June 25, 2009                           Telcordia Technologies
                                                     December 26, 2008


Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
                    IEEE 802.21 Mobility Services (MoS) Discovery
                    draft-ietf-mipshop-mos-dhcp-options-09

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 25, 2009.

Copyright Notice

   Copyright (c) 2008 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.


Abstract

   This document defines a number of Dynamic Host Configuration Protocol
   (DHCPv4 and DHCPv6) options that contain a list of domain names
   or IP addresses that can be mapped to servers providing IEEE 802.21

G. Bajko & S Das           Expires 06/25/09                  [Page 1]

Mobility Services DHCP Options                         December 2008

   type of Mobility Service (MoS)[MSFD]. These Mobility Services are
   used to assist an MN in handover preparation (network discovery)
   and handover decision (network selection). The services addressed
   in this document are the Media Independent Handover Services
   defined in [IEEE802.21].


 (1) 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.

 (2) Terminology and abbreviations used in this document

   Mobility Services: a set of different services provided by the
   network to mobile nodes to facilitate handover preparation
   and handover decision. In this document, Mobility Services refer to
   the services defined in IEEE 802.21 specifications [IEEE802.21]

   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 Contents

   1. Introduction .................................................2
   2. DHCPv4 Options for MoS Discovery..............................3
        2.1 Domain Name List........................................5
        2.2 IPv4 Address List.......................................6
   3. DHCPv6 Options for MoS Discovery..............................6
   4. Option Usage..................................................8
        4.1 Usage of DHCPv4 Options for MoS Discovery...............8
        4.2 Usage of DHCPv6 Options for MoS Discovery...............9
   5. Security Considerations .....................................10
   6. IANA Considerations .........................................10
   7. Acknowledgements ............................................11
   8. References ..................................................11
       8.1 Normative References ...................................11
       8.2 Informative References .................................12
   Author's Addresses .............................................12
   Intellectual Property and Copyright Statements .................13





G. Bajko & S. Das          Expires 06/25/09                   [Page 2]

Mobility Services DHCP Options                          December 2008


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 heterogeneous
   networks and perform seamless handover across these networks.

     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 [MSFD]. 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 new DHCPv4 and DHCPv6 options and sub-options
   called the MoS Discovery 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]. 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 Discovery Option for DHCPv4. Whether
   the MN receives an MoS address from local or home network will
   depend on the actual network deployment [MSFD]. The MoS Discovery

G. Bajko & S. Das           Expires 06/25/09                 [Page 3]

 Mobility Services DHCP Options                          December 2008

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


         Option Code

                OPTION-IPv4-MoS (To Be Assigned) - 1 byte

         Length

                An 8-bit field indicating the length of the option
                excluding the 'Option Code' and the 'Length' fields

         Sub-options

                A series of DHCPv4 sub-options.

   When the total length of a MoS Discovery Option exceeds 254
   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
   and a `enc` field. The value of the length octet does not include
   itself or the Sub-opt Type field. There are two types of 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

 G. Bajko & S. Das           Expires 06/25/09                   [Page 4]

   Mobility Services DHCP Options                         December 2008


   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          |
      +--------------+---------------+
      |    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 8 of [RFC3315],
   quoted below:

       So that domain names may be encoded uniformly, a domain name
       or a list of domain names is encoded using the technique
       described in section 3.1 of [RFC1035]. A domain name, or list
       of domain names, in DHCP MUST NOT be stored in compressed form,
       as described in section 4.1.4 of [RFC1035].

 G. Bajko & S. Das           Expires 06/25/09                 [Page 5]

  Mobility Services DHCP Options                         December 2008

   [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 the NAPTR records of different providers, rather than different A
   records within the same provider. That is, the 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 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.


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


           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:





G. Bajko & S. Das           Expires 06/25/09                   [Page 6]

Mobility Services DHCP Options                           December 2008

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


3.  DHCPv6 Option for MoS discovery

   This section introduces new DHCPv6 option used for MoS discovery.

   Whether the MN receives an MoS address from local or home network
   will depend on the actual network deployment [MSFD].



   The MoS Discovery 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                              |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


       Option Code

             OPTION-IPv6-MoS (To Be Assigned) - 2 bytes

       Length

             A 16-bit field indicating the length of the option
             excluding the 'Option Code' and the 'Length' fields.

       Sub-options

             A series of DHCPv6 sub-options.


   The sub-options follow the same format (except the Sub-opt Type and

G. Bajko & S. Das           Expires 06/25/09                   [Page 7]

Mobility Services DHCP Options                          December 2008

   Length value) and 'enc' rules as described in Section 2. The value of
   the Sub-opt Type and Length are 2-octets and the Length does not
   include itself or the Sub-opt Type field. 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 |
      +--------------+---------------+

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

4. Option Usage

4.1 Usage of DHCPv4 Options for MoS Discovery

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

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

G. Bajko & S. Das           Expires 06/25/09                  [Page 8]

Mobility Services DHCP Options                          December 2008

   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 request an address of a MoS Server, the mobile node
   (DHCP client) MUST include a MoS Discovery Option into either a
   DHCPDISCOVER or DHCPINFORM message. The inserted MoS Discovery
   Option MUST include only one sub-option, with the Sub-opt Type
   that represents either the service or the union of the services
   the mobile host is interested in.

4.1.2 DHCP Server behavior

   When the DHCP server receives either a DHCPDISCOVER or DHCPINFORM
   message with a MOS Discovery Option, the DHCP server MUST always
   construct the response according to the sub-option code representing
   either the service or the union of services desired by the mobile
   node in the sub-option code field. The response message may contain
   the IP address or the FQDN of the MoS Server. If set of FQDNs in
   the response message turns out to be more than 256 bytes, the DHCP
   server should send a reduced list of FQDNs so that they fit into
   one sub option.

   In case that the server cannot find any Mobility Server
   satisfying the requested Sub-opt Type, the server MUST return
   the MoS Discovery 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.

4.2 DHCPv6 Options for MoS discovery

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

4.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 request an address of a Mobility Server, the mobile
   node(DHCP client) MUST include a MoS Discovery Option into either
   a REQUEST or an  INFORMATION-REQUEST message. The inserted MoS
   Discovery Option MUST include only one sub-option, with the


 G. Bajko & S. Das           Expires 06/25/09                [Page 9]

Mobility Services DHCP Options                        December 2008

   Sub-opt Type that represents either the service or the union of
   the services the mobile host is interested in.

4.2.2 DHCP Server behavior

   When the DHCP Server receives either a REQUEST or an INFORMATION-
   REQUEST message with a MoS Discovery Option, the DHCP server MUST
   always construct the response according to the sub-option code
   representing either the service or the union of services desired
   by the mobile node in the sub-option code field. The response
   message may contain the IP address or the FQDN of the desired
   MoS server.

   In case that the server cannot find any Mobility Server
   satisfying the requested Sub-opt Type, the server MUST return
   the MoS Discovery 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. 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,
   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.


6. IANA Considerations

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

   MoS Discovery Option for DHCPv4 (OPTION-IPv4-MoS)    To Be Assigned

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

G. Bajko & S. Das           Expires 06/25/09                 [Page 10]

Mobility Services DHCP Options                         December 2008

      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 one  DHCPv6 option as described in
  section 3.

   MoS Discovery Option for DHCPv6 (OPTION-IPv6-MoS)  To Be Assigned

   This document creates a new registry for the sub-option field in
   the MoS DHCPv6 option called the "IEEE 802.21 Service Type"
   (section 3).

        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 '65535' are reserved and MUST NOT be used.
  New Values can be allocated via Standards Action as defined
  in [RFC5226].


7. Acknowledgements

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


8. References

    8.1 Normative References

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

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

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

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

  G. Bajko & S. Das           Expires 06/25/09                [Page 11]

Mobility Services DHCP Options                         December 2008


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

[RFC5226] T. Narten and H. Alvestrand, ?Guidelines for Writing an
    IANA  Considerations Section in RFCs? , May 2008.

 [MSFD] T Melia, Ed., " Mobility Services Framework Design (MSFD)",
      draft-ietf-mipshop-mstp-solution-09.txt (Work in Progress).

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



8.2 Informative References

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




 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 06/25/09               [Page 12]


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