path: root/doc/rfc/rfc5678.txt

Network Working Group                                           G. Bajko
Request for Comments: 5678                                         Nokia
Category: Standards Track                                         S. Das
                                             Telcordia Technologies Inc.
                                                           December 2009


  Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
             IEEE 802.21 Mobility Services (MoS) Discovery

Abstract

   This document defines new Dynamic Host Configuration Protocol (DHCPv4
   and DHCPv6) options that contain a list of IP addresses and a list of
   domain names that can be mapped to servers providing IEEE 802.21 type
   of Mobility Service (MoS) (see RFC 5677).  These Mobility Services
   are used to assist a mobile node (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 IEEE 802.21.

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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.








Bajko & Das                 Standards Track                     [Page 1]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
      1.2. Terminology ................................................3
   2. MoS IPv4 Address Option for DHCPv4 ..............................3
   3. MoS Domain Name List Option for DHCPv4 ..........................5
   4. MoS IPv6 Address Option for DHCPv6 ..............................7
   5. MoS Domain Name List Option for DHCPv6 ..........................9
   6. Option Usage ...................................................10
      6.1. Usage of MoS Options for DHCPv4 ...........................10
      6.2. Usage of MoS Options for DHCPv6 ...........................11
   7. Security Considerations ........................................12
   8. IANA Considerations ............................................12
   9. Acknowledgements ...............................................13
   10. References ....................................................13
      10.1. Normative References .....................................13
      10.2. Informative References ...................................14

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.  The objective is to help the higher-
      layer mobility protocols 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.







Bajko & Das                 Standards Track                     [Page 2]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


   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 do not
   necessitate the co-location.

   A mobile node (MN) may make use of any of these MIH service types
   separately or any combination of them [RFC5677].  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 service
   types separately.

   This document defines new DHCPv4 and DHCPv6 options and sub-options
   called the MoS IP Address and Domain Name List Options, which allow
   the MN to locate a Mobility Server that 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.

1.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 [RFC2119].

1.2.  Terminology

   Mobility Services: a set of 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 Services.

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

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

2.  MoS IPv4 Address Option for DHCPv4

   This section describes the MoS IPv4 Address Option for DHCPv4.
   Whether the MN receives a MoS address from the local or home network
   will depend on the actual network deployment [RFC5677].  The MoS IPv4
   Address Option begins with an 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:





Bajko & Das                 Standards Track                     [Page 3]
^L
RFC 5678           Mobility Services for DCHP 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 Code   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Sub-Option 1                              |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ...                                     |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Sub-Option n                              |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Code

         OPTION-IPv4_Address-MoS (139) - 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 IPv4 Address 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 code followed by a length and
   one or more IPv4 addresses.  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 Code  |    Length     |    IP Address . . . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+










Bajko & Das                 Standards Track                     [Page 4]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


   The sub-option codes are summarized below.

      +--------------+---------------+
      |  Sub-opt     | Service       |
      |   Code       | Name          |
      +==============+===============+
      |    1         |   IS          |
      +--------------+---------------+
      |    2         |   CS          |
      +--------------+---------------+
      |    3         |   ES          |
      +--------------+---------------+

   If the length is followed by a list of IPv4 addresses indicating
   appropriate MIH servers available to the MN for a requested option,
   servers MUST be listed in order of preference and the client should
   process them in decreasing order of preference.  In the case that
   there is no MIH server available, the length is set to 0; otherwise,
   it is a multiple of 4.

   The sub-option has the following format:

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

3.  MoS Domain Name List Option for DHCPv4

   This section describes the MoS Domain Name List Option for DHCPv4.
   The general format of this option 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                              |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Bajko & Das                 Standards Track                     [Page 5]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


      Option Code

         OPTION-IPv4_FQDN-MoS (140) - 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 Domain Name List 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 code followed by a length and
   one or more Fully Qualified Domain Names (FQDNs).  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 Code  |    Length     |  FQDN(s) . . . . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The sub-option codes are summarized below.

      +--------------+---------------+
      |  Sub-opt     | Service       |
      |   Code       | Name          |
      +==============+===============+
      |    1         |   IS          |
      +--------------+---------------+
      |    2         |   CS          |
      +--------------+---------------+
      |    3         |   ES          |
      +--------------+---------------+

   Thus, the sub-option for this encoding has the following format:

          Code  Len   DNS name of Mobility Server
         +-----+----+----+-----+-----+-----+-----+--
         |1..3 | n  | s1 |  s2 |  s3 |  s4 | s5  |  ...
         +-----+----+----+-----+-----+-----+-----+--



Bajko & Das                 Standards Track                     [Page 6]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


   The sub-option begins with a sub-option code followed by a length and
   a sequence of labels that are encoded according to Section 8 of
   [RFC3315].

   The sub-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 [RFC5679] 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.

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

4.  MoS IPv6 Address Option for DHCPv6

   This section describes the MoS IPv6 Address Option for DHCPv6.
   Whether the MN receives a MoS address from the local or home network
   will depend on the actual network deployment [RFC5677].  The MoS
   Discovery Option begins with an 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:















Bajko & Das                 Standards Track                     [Page 7]
^L
RFC 5678           Mobility Services for DCHP 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 Code             |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Sub-Option 1                              |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ...                                     |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Sub-Option n                              |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Code

         OPTION-IPv6_Address-MoS (54) - 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 Code and
   Length value) as described in Section 2.  The value of the Sub-opt
   Code and Length is 2 octets, and the Length does not include itself
   or the Sub-opt Code 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 Code                  |     Length                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IP Address                                  |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+












Bajko & Das                 Standards Track                     [Page 8]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


   The sub-option codes are summarized below.

      +----------------+---------------+
      |  Sub-opt Code  | Service Name  |
      +================+===============+
      |    1           |   IS          |
      +----------------+---------------+
      |    2           |   CS          |
      +----------------+---------------+
      |    3           |   ES          |
      +----------------+---------------+

   If the length is followed by a list of IPv6 addresses indicating
   appropriate MIH servers available to the MN for a requested option,
   servers MUST be listed in order of preference and the client should

   process them in decreasing order of preference.  In the case where
   there is no MIH server available, the length is set to 0; otherwise,
   it is a multiple of 16.

5.  MoS Domain Name List Option for DHCPv6

   This section describes the MoS Domain List Option for DHCPv6.  The
   general format of this option 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_FQDN-MoS (55) - 2 bytes

      Length

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




Bajko & Das                 Standards Track                     [Page 9]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


      Sub-options

         A series of DHCPv6 sub-options

   The sub-options follow the same format (except the Sub-opt Code and
   Length value) as described in Section 3.  The value of the Sub-opt
   Code and Length is 2 octets, and the Length does not include itself
   or the Sub-opt Code 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 Code                  |     Length                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   FQDN(s)                                     |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The sub-option codes are summarized below.

      +----------------+---------------+
      |  Sub-opt Code  | Service Name  |
      +================+===============+
      |    1           |   IS          |
      +----------------+---------------+
      |    2           |   CS          |
      +----------------+---------------+
      |    3           |   ES          |
      +----------------+---------------+

   The semantics and content of the DHCPv6 encoding of this option are
   exactly the same as the encoding described in Section 3, except the
   Option Code and Length value.

6.  Option Usage

6.1.  Usage of MoS Options for DHCPv4

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

6.1.1.  Mobile Node Behavior

   The mobile node may perform a MoS discovery either during initial
   association with a network or when the mobility service is required.
   It may also try to perform the MoS 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.



Bajko & Das                 Standards Track                    [Page 10]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


   In order to discover the IP address or FQDN of a MoS, the mobile node
   (DHCP client) MUST include either a MoS IPv4 Address Option or a MoS
   Domain Name List Option in the Parameter Request List (PRL) in the
   respective DHCP messages as defined in [RFC2131].

   The client MAY include a MoS IPv4 Address Option or a MoS Domain Name
   List Option that includes one or more sub-option(s) with the Sub-opt
   Code or Codes that represent the service(s) the mobile node is
   interested in.  However, a client SHOULD be prepared to accept a
   response from a server that includes other sub-option(s) or does not
   include the requested sub-option(s).

6.1.2.  DHCP Server Behavior

   When the DHCP server receives either a MoS IPv4 Address Option or a
   MoS Domain Name List Option in the PRL, the DHCP server MUST include
   the option in its response message as defined in [RFC2131].

   A server MAY use the sub-options in the received MoS IPv4 Address
   Option or MoS Domain Name List Option from the client's message to
   restrict its response to the client requested sub-options.  In the
   case when the server cannot find any Mobility Server satisfying a
   requested sub-option, the server SHOULD return the MoS Option with
   that sub-option and the length of the sub-option set to 0.

6.2.  Usage of MoS Options for DHCPv6

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

6.2.1.  Mobile Node Behavior

   The mobile node may perform the MoS discovery either during initial
   association with a network or when the mobility service is required.
   It may also try to perform the MoS 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 discover the IP address or FQDN of a MoS, the mobile node
   (DHCP client) MUST include either a MoS IPv6 Address Option or a MoS
   Domain Name List Option in the Option Request Option (ORO) in the
   respective DHCP messages as defined in [RFC3315].

   The client MAY include a MoS IPv6 Address Option or a MoS Domain Name
   List Option that includes one or more sub-option(s) with the Sub-opt
   Code or Codes that represent the service(s) the mobile node is




Bajko & Das                 Standards Track                    [Page 11]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


   interested in.  However, a client SHOULD be prepared to accept a
   response from a server that includes other sub-option(s) or does not
   include the requested sub-option(s).

6.2.2.  DHCP Server Behavior

   When the DHCP server receives either a MoS IPv6 Address Option or a
   MoS Domain Name List Option in the ORO, the DHCP server MUST include
   the option in its response message as defined in [RFC3315].

   A server MAY use the sub-options in the received MoS IPv6 Address
   Option or MoS Domain Name List Option from the client's message to
   restrict its response to the client-requested sub-options.  In the
   case when the server cannot find any Mobility Server satisfying a
   requested sub-option, the server SHOULD return the MoS Option with
   that sub-option and the length of the sub-option set to 0.

7.  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.  This will also protect the denial-of-
   service attacks to DHCP servers.  [RFC3118] provides mechanisms for
   both entity authentication and message authentication.

   In deployments where DHCP authentication is not available, lower-
   layer security services may be sufficient to protect DHCP messages.

   Regarding domain name resolution, it is recommended to consider the
   usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational
   Practices [RFC4641].  Security considerations described in [RFC5679]
   also apply.

8.  IANA Considerations

   This document defines two new DHCPv4 options as described in Sections
   2 and 3.

   MoS IPv4 Address Option for DHCPv4 (OPTION-IPv4_Address-MoS)    139

   MoS Domain Name List option for DHCPv4 (OPTION-IPv4_FQDN-MoS)   140





Bajko & Das                 Standards Track                    [Page 12]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


   This document creates a new registry for the Sub-Option fields in the
   MoS DHCPv4 Address and FQDN options called the "IEEE 802.21 Service
   Type" (Section 2 and 3).

       IS                       1
       CS                       2
       ES                       3

   The values '0' and '255' are reserved.  Values '1' through '3' are
   allocated as above, and the rest are available for allocation.  New
   values can be allocated via Standards Action as defined in [RFC5226].

   This document also defines two DHCPv6 options as described in
   Sections 4 and 5.

   MoS IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-MoS)   54

   MoS Domain Name List option for DHCPv6 (OPTION-IPv6_FQDN-MoS)  55

   This document creates a new registry for the sub-option field in the
   MoS DHCPv6 Address and FQDN options called the "IEEE 802.21 IPv6
   Service Type" (Sections 4 and 5).

        IS                       1
        CS                       2
        ES                       3

   The values '0' and '65535' are reserved.  Values '1' through '3' are
   allocated as above, and the rest are available for allocation.  New
   values can be allocated via Standards Action as defined in [RFC5226].

9.  Acknowledgements

   The authors would like to acknowledge the following individuals for
   their valuable comments: Alfred Hoenes, Bernie Volz, David W.
   Hankins, Jari Arkko, Telemaco Melia, Ralph Droms, Ted Lemon, Vijay
   Devarapalli, and Yoshihiro Ohba.

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.

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




Bajko & Das                 Standards Track                    [Page 13]
^L
RFC 5678           Mobility Services for DCHP Options      December 2009


   [RFC3118]    Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for
                DHCP Messages", RFC 3118, June 2001.

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

   [RFC3396]    Lemon, T. and S. Cheshire, "Encoding Long Options in the
                Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
                November 2002.

   [RFC4033]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "DNS Security Introduction and Requirements", RFC
                4033, March 2005.

   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.

   [RFC5677]    Melia, T., Ed., Bajko, G., Das, S., Golmie, N., and JC.
                Zuniga, "IEEE 802.21 Mobility Services Framework Design
                (MSFD)", RFC 5677, December 2009.

   [RFC5679]    Bajko, G., "Locating IEEE 802.21 Mobility Services Using
                DNS", RFC 5679, December 2009.

10.2.  Informative References

   [RFC4641]    Kolkman, O. and R. Gieben, "DNSSEC Operational
                Practices", RFC 4641, September 2006.

   [IEEE802.21] "IEEE Standard for Local and Metropolitan Area Networks
                - Part 21: Media Independent Handover Services", IEEE
                LAN/MAN Std 802.21-2008, January 2009,
                http://www.ieee802.org/21/private/Published%20Spec/
                802.21-2008.pdf (access to the document requires
                membership).

Authors' Addresses

   Gabor Bajko
   Nokia
   EMail: gabor.bajko@nokia.com


   Subir Das
   Telcordia Technologies Inc.
   EMail: subir@research.telcordia.com



Bajko & Das                 Standards Track                    [Page 14]
^L