One document matched: draft-ietf-mipshop-mos-dhcp-options-06.txt
Differences from draft-ietf-mipshop-mos-dhcp-options-05.txt
MIPSHOP WG Gabor Bajko
Internet Draft Nokia
Intended Status: Proposed Standard Subir Das
Expires: April 17, 2009 Telcordia
October 17, 2008
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
Mobility Server (MoS) discovery
draft-ietf-mipshop-mos-dhcp-options-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 October 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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
type of Mobility Services [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].
G. Bajko & S Das Expires 04/17/09 [Page 1]
Mobility Services DHCP Options October 2008
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.
Terminology and abbreviations used in this document
Mobility Services: comprises of a set of different services provided
by the network to mobile nodes to facilitate handover preparation
and handover decision.
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 Content
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 .............................................11
Intellectual Property and Copyright Statements .................12
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
G. Bajko & S. Das Expires 03/07/09 [Page 2]
Mobility Services DHCP Options September 2008
mobility protocols to acquire a global view of the 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 a new dhcpv4 option called MoS 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]. The MoS
information type defines sub-options for different services. The
document also defines DHCPv6 options that allow the MN to
discover Mobility Servers hosting MIH services in different
deployment scenarios. 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 option for DHCPv4.
The MoS 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 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
G. Bajko & S. Das Expires 04/17/09 [Page 3]
Mobility Services DHCP Options October 2008
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv4-MoS (TBD) - 1 byte
Length
1 byte
Sub-options
A series of DHCPv4 sub-options.
When the total length of a MoS option exceeds 254 octets, the
Procedure outlined in [RFC3396] MUST be employed to split the
option into multiple, smaller options.
A sub-option begins with a sub-option Type followed by a length
and a `enc` field. The value of the length octet does not include
itself or the option code. 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
for the concatenation of multiple instances of an option into a
single option prior to processing the option [RFC3396].
The sub-option layout is depicted below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-opt Type | length | enc | FQDN or .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
G. Bajko & S. Das Expires 04/17/09 [Page 4]
Mobility Services DHCP Options October 2008
+---------------------------------------------------------------+
. IP Address .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-option Types are summarized below.
+--------------+---------------+
| Sub-opt | Service |
| Type* | Name |
+==============+===============+
| 1 | IS |
+--------------+---------------+
| 2 | ES |
+--------------+---------------+
| 3 | IS and ES |
+--------------+---------------+
| 4 | CS |
+--------------+---------------+
| 5 | IS and CS |
+--------------+---------------+
| 6 | ES and CS |
+--------------+---------------+
| 7 | IS, CS and ES |
+--------------+---------------+
*Note: The values `0` '8' to '255' are reserved and MUST NOT be used.
Future sub-options may or may not use the above format.
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 different NAPTR records, rather than different A records. The
client MUST try the records in the order listed, applying the
mechanism described in [MoS-DNS] for each. The client only resolves
G. Bajko & S. Das Expires 04/17/09 [Page 5]
Mobility Services DHCP Options October 2008
the subsequent domain names if attempts to contact the first one
failed or yielded no common transport protocols between the MN and
the server.
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 sub-option for this encoding has the following format:
Type Len enc DNS name of MoS server
+-----+---+---+-----+-----+-----+-----+-----+--
|1..7 | n | 0 | s1 | s2 | s3 | s4 | s5 | ...
+-----+---+---+-----+-----+-----+-----+-----+--
As an example, consider the case where the server wants to offer
two MIH IS servers, "example.com" and "example.net". These would
be encoded as follows:
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|1..7|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+
2.2 IPv4 Address List
If the 'enc' byte has a value of 1, the encoding byte is followed by
a list of IPv4 addresses indicating appropriate MIH servers
available to the MN. Servers MUST be listed in order of preference.
Its minimum length is 5, and the length MUST be a multiple of 4 plus
one. The sub-option for this encoding has the following format:
Code Len enc IPv4 Address 1 IPv4 Address 2
+-----+---+---+-----+----+---+----+----+--
|1..7 | n | 1 | a1 | a2 |a3 | a4 | a1 | ...
+-----+---+---+-----+----+---+----+----+--
3. DHCPv6 Option for MoS discovery
This section introduces new DHCPv6 option used for MoS discovery.
Whether the MN receives an MoS address from local or home network
will depend on the actual network deployment [MSFD].
G. Bajko & S. Das Expires 04/17/09 [Page 6]
Mobility Services DHCP Options October 2008
The MoS 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 (TBD) - 2 bytes
Length
2 bytes
Sub-options
A series of DHCPv6 sub-options.
The sub-options follow the same format (except the length value) and
'enc' rules as described in Section 2. The sub-option layout is
Depicted below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-opt Type | Length | enc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. FQDN or IP Address .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
G. Bajko & S. Das Expires 04/17/09 [Page 7]
Mobility Services DHCP Options October 2008
The sub-option Types are summarized below.
+--------------+---------------+
| Sub-opt | Service |
| Type* | Name |
+==============+===============+
| 1 | IS |
+--------------+---------------+
| 2 | ES |
+--------------+---------------+
| 3 | IS and ES |
+--------------+---------------+
| 4 | CS |
+--------------+---------------+
| 5 | IS and CS |
+--------------+---------------+
| 6 | ES and CS |
+--------------+---------------+
| 7 | IS, CS and ES |
+--------------+---------------+
*Note: The values `0` '8' to '255' are reserved and MUST NOT be used.
Future sub-options may or may not use the above format.
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 acquire the MoS information, the mobile node MUST send
either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or
a unicast server address, respectively. In this message the mobile
node (DHCP client) MUST include the sub-opt Type for the MoS
Discovery in the sub-options field.
G. Bajko & S. Das Expires 04/17/09 [Page 8]
Mobility Services DHCP Options October 2009
4.1.2 DHCP Server behavior
When the DHCP server receives the DHCPDISCOVER or DHCPINFORM message
with the MoS Discovery option in the options field, the DHCP server
MUST follow the [RFC2131] logic to construct either a DHCPOFFER or
DHCPACK message including the MoS Discovery option. The reply
message may contain the IP address or the FQDN of the MoS Server.
The DHCP server MUST always construct the response according to
the Sub-opt Type requested by the DHCP client.
In case that the server cannot find any MoS information for a
specific MoS sub-opt Type, it MUST return the MoS option with a
sub-option by setting the sub-opt Type to the requested
sub-opt Type and the length of the sub-option to 1.
4.2 DHCPv6 Options for MoS discovery
The requesting and sending of the proposed DHCPv6 options follow the
rules for DHCP options in [RFC3315].
4.2.1 Mobile node behavior
The mobile node may perform the MoS information discovery procedure
either during initial association with a network or when the
mobility service is required. It may also try to perform the MoS
information discovery when it lacks the network information for MoS
or needs to change the MoS for some reasons, for instance, to
recover from the single point of failure of the existing MoS
In order to acquire the MoS address, the mobile node MUST send either
a REQUEST or INFORMATION_REQUEST message to the All_DHCP_Servers
multicast address. In this message the mobile node (DHCP client)
MUST include the Option Code for the MoS Discovery option in the
option_code.
4.2.2 DHCP Server behavior
When the DHCP Server receives either REQUEST or INFORMATION-REQUEST
message the DHCP server MUST follow the following logic to construct
a REPLY message with the MoS Information option.
If the DHCP server has the requested MoS information, it MUST
include the information in the MoS Information option. The server
may provide the matching information from the preconfigured
information available locally.
G. Bajko & S. Das Expires 04/17/09 [Page 9]
Mobility Services DHCP Options September 2008
The DHCP server MUST always construct the response
according to the Sub-Opt Type requested by the DHCP client.
In case that the server cannot find any MoS information for a
specific MoS type, it MUST return the MoS option with
a sub-option by setting the Sub-opt Type to the requested Sub-opt
Type and the length of the sub-option to 1.
5. Security Considerations
The security considerations in [RFC2131] apply. If an adversary
manages to modify the response from a DHCP server or insert its own
response, an MN could be led to contact a rogue Mobility Server,
possibly one that then would provide wrong information, event or
command for handover.
It is recommended to use either DHCP authentication option described
in [RFC3118] where available, or rely upon link layer security.
This will also protect the denial of service attacks to DHCP
servers. [RFC3118] provides mechanisms for both entity authentication
and message authentication.
6. IANA Considerations
This document defines one new DHCPv4 option as described in section
2.
MoS Option for DHCPv4 (OPTION-IPv4-MoS) TBD
This document creates a new registry for the Sub-Option field in the
MoS DHCPv4 option called the "MoS Service Type" (Section 2).
IS 1
ES 2
IS and ES 3
CS 4
IS and CS 5
ES and CS 6
IS, CS and ES 7
The values '0', '8' to '255' are reserved and MUST NOT be used. New
values can be allocated by Standards Action or IESG approval.
This document also defines new DHCPv6 options as described in
section 3
G. Bajko & S. Das Expires 04/17/09 [Page 10]
Mobility Services DHCP Options October 2008
MoS Option for DHCPv6 (OPTION-IPv6-MoS) TBD
This document creates a new registry for the sub-option field in
the MoS DHCPv6 option called the ?MoS Service Type?(section 3).
IS 1
ES 2
IS and ES 3
CS 4
IS and CS 5
ES and CS 6
IS, CS and ES 7
The values '0', '8' to '255' are reserved and MUST NOT be used. New
Values can be allocated by Standards Action or IESG approval.
7. Acknowledgements
Authors would like to acknowledge the following individuals for
their valuable comments.
Vijay Devarapalli, Telemaco Melia, and Yoshihiro Ohba
8. References
8.1 Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
RFC3396, November 2002.
[RFC3118] Authentication for DHCP Messages, Droms et al, June 2001
[RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6),
Droms et al, July 2003
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 04/17/09 [Page 11]
Mobility Services DHCP Options October 2008
[MoS-DNS] Bajko, G., "Locating Mobility Servers",
draft-ietf-mipshop-mos-dns-discovery, (Work in Progress),
May 2008.
[MSFD] T Melia, Ed., " Mobility Services Framework Design (MSFD)",
draft-ietf-mipshop-mstp-solution, (Work in Progress)
Authors' Addresses
Gabor Bajko
Nokia
e-mail: gabor.bajko@nokia.com
Subir Das
Telcordia Technologies Inc.
e-mail: subir@research.telcordia.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
G. Bajko & S. Das Expires 04/17/09 [Page 12]
Mobility Services DHCP Options October 2008
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
| PAFTECH AB 2003-2026 | 2026-04-24 04:50:09 |