RFC 5678 PROPOSED STANDARD DHCP · MOBILITY · DISCOVERY
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery
DHCP options that tell a mobile device which servers offer IEEE 802.21 handover help.
RFC EDITOR
Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery", RFC 5678, DOI 10.17487/RFC5678, December 2009, <https://www.rfc-editor.org/info/rfc5678>.
BIBTEX
@misc{rfc5678,
series = {Request for Comments},
number = 5678,
howpublished = {RFC 5678},
publisher = {RFC Editor},
doi = {10.17487/RFC5678},
url = {https://www.rfc-editor.org/info/rfc5678},
author = {G. Bajko and S. Das},
title = {{Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery}},
pagetotal = 14,
year = 2009,
month = dec,
} RFC text
Contents
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.
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.
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:
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 . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | ...
+-----+----+----+-----+-----+-----+-----+--
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:
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 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
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
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
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.
[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
AI ELI5
On this page
PROBLEMA mobile node needs to find servers providing IEEE 802.21 Mobility Services (information, event and command) when it joins a network, and a server may host only some of these services.
MECHANISMFour new options, two for DHCPv4 and two for DHCPv6, carry either a list of IP addresses or a list of domain names, with sub-options that select the service type: IS, CS or ES.
WHY IT MATTERSA mobile node asks for the option in its request list and the DHCP server answers with the matching servers. The RFC is a Proposed Standard and is not obsoleted or updated.
§1Finding Mobility Services
IEEE 802.21 defines three service types to help link layer handovers across different technologies, called Media Independent Handover (MIH) services: Information Services (IS), Event Services (ES) and Command Services (CS). A mobile node (MN) may use any of them separately or together, and a Mobility Server may not host all three, so the MN needs to discover each service type separately.
RFC 5678 defines new DHCPv4 and DHCPv6 options and sub-options, the MoS IP Address and Domain Name List Options, that let the MN locate a Mobility Server hosting the service type it wants. Apart from manual configuration, this is one of the possible ways to find such a server. The framework is in RFC 5677.
Some helpers give you maps, some warn you about changes, and some tell you what to do. This document is a way for a device to ask which helper is where.
§2The Option Formats
Each option starts with an option code and a length, followed by one or more sub-options. The length does not count the option code or itself. When a DHCPv4 option would exceed 254 octets, the procedure of RFC 3396 MUST be used to split it.
There are two kinds of option per protocol version. The MoS Address Option carries IP addresses and the MoS Domain Name List Option carries fully qualified domain names (FQDNs). In DHCPv4 the code and length are 1 octet each. In DHCPv6 they are 2 octets each, and so are the sub-option code and length.
Each sub-option begins with a sub-option code and a length. Address lists are in order of preference, which the client processes in decreasing order. If no server is available the length is 0, and otherwise it is a multiple of 4 for IPv4 or 16 for IPv6.
Each option is a labelled envelope. The label says what is inside and how big it is, and inside are smaller envelopes for each kind of helper.
§3Option Codes and Service Types
The four options and their codes are OPTION-IPv4_Address-MoS (139), OPTION-IPv4_FQDN-MoS (140), OPTION-IPv6_Address-MoS (54) and OPTION-IPv6_FQDN-MoS (55).
The sub-option codes pick the service: 1 for IS, 2 for CS and 3 for ES. They are the same in all four options.
Domain names use the label encoding of RFC 3315 Section 8. A sub-option MAY hold several names, but they should refer to the NAPTR records of different providers, not to different A records within one provider. The client MUST try them in the listed order, using the mechanism of RFC 5679, and resolves later names only if the first failed or shared no transport protocol with the server.
Number 1 means maps, 2 means commands and 3 means events. If the card lists several offices, you try the first, and only go to the next if the first does not work.
- 139OPTION-IPv4_Address-MoS — DHCPv4: IPv4 addresses of Mobility Servers.
- 140OPTION-IPv4_FQDN-MoS — DHCPv4: domain names of Mobility Servers.
- 54OPTION-IPv6_Address-MoS — DHCPv6: IPv6 addresses of Mobility Servers.
- 55OPTION-IPv6_FQDN-MoS — DHCPv6: domain names of Mobility Servers.
- 1IS — Information Services.
- 2CS — Command Services.
- 3ES — Event Services.
§4How Clients and Servers Use Them
The mobile node may discover a Mobility Server when it first joins a network or when it needs the service. It may also do so if it lacks network information, or wants to change servers, for instance to recover from a single point of failure.
In DHCPv4 the client MUST include a MoS Address Option or a MoS Domain Name List Option in the Parameter Request List. In DHCPv6 it MUST include one in the Option Request Option. The client MAY name the services it wants using sub-option codes, but SHOULD be ready to receive other sub-options or not get the ones it asked for.
A server that receives such a request MUST include the option in its reply. It MAY restrict the reply to the requested sub-options. If it finds no Mobility Server for a requested sub-option, it SHOULD return that sub-option with its length set to 0.
The device says "please tell me about the helpers". The server writes the list, and if there is no helper of some type, it writes that type with an empty list.
Mobile node (DHCP client)DHCP server
- Request with MoS option in request listOptionally names the wanted sub-option codes (1, 2 or 3).
- Reply with MoS optionServers in order of preference; length 0 if none found.
§5Security Considerations
The security considerations of RFC 2131 apply. If an attacker changes or inserts a DHCP response, the mobile node could be led to a rogue Mobility Server that supplies wrong information, events or commands for handover.
The RFC recommends DHCP authentication (RFC 3118) where available, which also helps against denial-of-service attacks on DHCP servers. Where it is not available, lower-layer security may be enough. For name resolution it recommends considering DNSSEC (RFC 4033).
If someone slips a fake card into your hand, you could end up asking the wrong helper for advice. Checking that the card really came from the front desk prevents that.
§6IANA Considerations
IANA assigns option codes 139 and 140 for DHCPv4 and 54 and 55 for DHCPv6. The document also creates two registries for the sub-option field: "IEEE 802.21 Service Type" for DHCPv4 and "IEEE 802.21 IPv6 Service Type" for DHCPv6.
Values 1 to 3 are allocated to IS, CS and ES. The values 0 and 255 are reserved in the DHCPv4 registry, and 0 and 65535 in the DHCPv6 one. New values need Standards Action.
IANA keeps the official list of labels, so everyone uses the same numbers for the same things.
§7References
[RFC2131]RFC 2131Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.March 1997[RFC3118]RFC 3118Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.June 2001[RFC3315]RFC 3315Droms, R., Ed., et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.July 2003[RFC3396]RFC 3396Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.November 2002[RFC5677]RFC 5677Melia, T., Ed., et al., "IEEE 802.21 Mobility Services Framework Design (MSFD)", RFC 5677, December 2009.December 2009[RFC5679]RFC 5679Bajko, G., "Locating IEEE 802.21 Mobility Services Using DNS", RFC 5679, December 2009.December 2009