RFC5678
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.
Contents
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.
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.
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].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | ...
+-----+---+---+----+----+----+-----+----+--
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +---+---+---+---+---+---+---+---+---+---+---+---+---+
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.
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.
Option Usage
Usage of MoS Options for DHCPv4
The requesting and sending of the proposed DHCPv4 options follow the rules for DHCP options in RFC2131.
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).
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.
Usage of MoS Options for DHCPv6
The requesting and sending of the proposed DHCPv6 options follow the rules for DHCP options in RFC3315.
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).
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.
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.
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.
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: [email protected]
Subir Das Telcordia Technologies Inc. EMail: [email protected]
