Internet Engineering Task force Gabor Bajko
Internet Draft Nokia
Intended Status: Proposed Standard Subir Das
Expires: July 08, 2009 Telcordia Technologies
January 08, 2009
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
IEEE 802.21 Mobility Services (MoS) Discovery
draft-ietf-mipshop-mos-dhcp-options-10
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 July 08, 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 07/08/09 [Page 1]
Mobility Services DHCP Options January 2009
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 .................................11
Author's Addresses .............................................12
G. Bajko & S. Das Expires 07/08/09 [Page 2]
Mobility Services DHCP Options January 2009
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 07/08/09 [Page 3]
Mobility Services DHCP Options January 2009
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 Code followed by a length
and a `enc` field. The value of the length octet does not include
itself or the Sub-opt Code 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 07/08/09 [Page 4]
Mobility Services DHCP Options January 2009
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 Code | length | enc | FQDN or .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. IP Address .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-option Codes are summarized below.
+--------------+---------------+
| Sub-opt | Service |
| Code* | Name |
+==============+===============+
| 1 | IS |
+--------------+---------------+
| 2 | CS |
+--------------+---------------+
| 3 | ES |
+--------------+---------------+
*Note: The values `0` '4' 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].
[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
G. Bajko & S. Das Expires 07/08/09 [Page 5]
Mobility Services DHCP Options January 2009
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:
Code Len enc DNS name of MoS server
+-----+---+---+-----+-----+-----+-----+-----+--
|1..3 | 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..3|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+
2.2 IPv4 Address List
If the 'enc' byte has a value of 1, the encoding byte is followed by
a list of IPv4 addresses indicating appropriate MIH servers
available to the MN. Servers MUST be listed in order of preference.
Its minimum length is 5, and the length MUST be a multiple of 4 plus
one. The sub-option for this encoding has the following format:
Code Len enc IPv4 Address 1 IPv4 Address 2
+-----+---+---+-----+----+---+----+----+--
|1..3 | n | 1 | a1 | a2 |a3 | a4 | a1 | ...
+-----+---+---+-----+----+---+----+----+--
3. DHCPv6 Option for MoS discovery
This section introduces new DHCPv6 option used for MoS discovery.
G. Bajko & S. Das Expires 07/08/09 [Page 6]
Mobility Services DHCP Options January 2009
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 Code and
Length value) and 'enc' rules as described in Section 2. The value of
the Sub-opt Code and Length are 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
G. Bajko & S. Das Expires 07/08/09 [Page 7]
Mobility Services DHCP Options January 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enc | FQDN or IP Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-option Codes are summarized below.
+--------------+---------------+
| Sub-opt | Service |
| Code* | Name |
+==============+===============+
| 1 | IS |
+--------------+---------------+
| 2 | CS |
+--------------+---------------+
| 3 | ES |
+--------------+---------------+
*Note: The values `0` '4' 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
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 one or more sub-option(s) with the Sub-opt
Code(s) that represents the service(s) 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
G. Bajko & S. Das Expires 07/08/09 [Page 8]
Mobility Services DHCP Options January 2009
construct the response according to the sub-option code(s)
representing the service(s) 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 Code, the server MUST return
the MoS Discovery Option with a sub-option by setting the
Sub-opt Code to the requested Sub-opt Code 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 one or more sub-option(s) with the
Sub-opt Code(s) that represents the service(s) 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(s)
representing the service 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 Code, the server MUST return
the MoS Discovery Option with a sub-option by setting the
Sub-opt Code to the requested Sub-opt Code and the length of
the sub-option to 1.
G. Bajko & S. Das Expires 07/08/09 [Page 9]
Mobility Services DHCP Options January 2009
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
CS 2
ES 3
The values '0', '4' 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
CS 2
ES 3
The values '0', '4' to '65535' are reserved and MUST NOT be used.
New Values can be allocated via Standards Action as defined
in [RFC5226].
G. Bajko & S. Das Expires 07/08/09 [Page 10]
Mobility Services DHCP Options January 2009
7. Acknowledgements
Authors would like to acknowledge the following individuals for
their valuable comments.
Bernie Volz, Vijay Devarapalli, David W. Hankins, Alfred Hoenes,
Telemaco Melia, Ralph Droms 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
[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
G. Bajko & S. Das Expires 07/08/09 [Page 11]
Mobility Services DHCP Options January 2009
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 07/08/09 [Page 12]
