One document matched: draft-bajko-mos-dhcp-options-00.txt
MIPSHOP WG Gabor Bajko
Internet Draft Nokia
Intended Status: Standards Track August 2007
Expires: February 20, 2007
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
Mobility Servers (MoS)
draft-bajko-mos-dhcp-options-00
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 February 20, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines a number of Dynamic Host Configuration
Protocol (DHCP-for-IPv4) options that contain a list of domain names
or IPv4 addresses that can be mapped to servers providing Mobility
Services. Mobility Services are used to assist an MN in handover
preparation (network discovery) and handover decision (network
selection). The services addressed by this document are the Media
Independent Handover Services defined in [1].
Conventions used in this document
G. Bajko Expires 02/20/08 [Page 1]
Mobility Services DHCP Options August 2007
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 [1].
Terminology and abbreviations used in this document
Mobility Support 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 [1].
MIH Service: IS, ES or CS type of service, as defined in [1].
Table of Content
1. Introduction ...................................................2
2. Mobility Server DHCPv4 Options..................................3
2.1 Domain Name List .........................................3
2.2 IPv4 Address List ........................................5
3. Mobility Server DHCPv6 Options..................................5
3.1 Domain Name List .........................................6
3.2 IPv6 Address List ........................................6
4. Security Considerations ........................................6
5. IANA Considerations ............................................7
6. Acknowledgements ...............................................7
7. Normative References ...........................................7
8. Informative References .........................................7
9. Author's Addresses .............................................8
1. Introduction
IEEE 802.21 [1] 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 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.
G. Bajko Expires 02/20/08 [Page 2]
Mobility Services DHCP Options August 2007
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.
It is anticipated that a Mobility Server will 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 three dhcp options [4,5] for DHCPv4 and
DHCPv6, one for each of the services defined in [1], namely IS, ES
and CS. The options would allow an MN to locate a Mobility Server
which hosts the desired MIH service type (IS, ES or CS) the MN is
looking for. This is one of the possible solutions for locating a
server providing Mobility Services; manual configuration is an
example of another.
2. Mobility Server DHCPv4 Options
This section describes three options for DHCPv4.
The Mobility Server DHCPv4 options carry either a 32-bit (binary)
IPv4 address or, preferably, a DNS (RFC 1035 [6]) fully-qualified
domain name to be used by the MN to locate a server hosting either
an IS, an ES or a CS service.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MoS code | Length | enc | MoS Server ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... domain name or IP address list ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MoS code: option codes assigned by IANA (tbd)
Length: indicates the total number of octets in the option following
the 'Length' field, including the encoding byte
enc: one byte indicating the encoding type of the next field
The options have two 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
G. Bajko Expires 02/20/08 [Page 3]
Mobility Services DHCP Options August 2007
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. The 'Length' field
indicates the total number of octets in the option following the
'Length' field, including the encoding byte.
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 [7].
The code for the MIH IS option is XXX. The code for the MIH ES
option is YYY. The code for the MIH CS option is ZZZ.
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 3.1 of RFC 1035
[6], quoted below:
Domain names in messages are expressed in terms of a sequence
of labels. Each label is represented as a one octet length
field followed by that number of octets. Since every domain
name ends with the null label of the root, a domain name is
terminated by a length byte of zero. The high order two bits of
every length octet must be zero, and the remaining six bits of
the length field limit the label to 63 octets or less. To
simplify implementations, the total length of a domain name
(i.e., label octets and label length octets) is restricted to
255 octets or less.
RFC 1035 encoding was chosen to accommodate future internationalized
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 [8] 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.
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.
Clients MUST support compression according to the encoding in
Section 4.1.4 of "Domain Names - Implementation And Specification"
[6].
G. Bajko Expires 02/20/08 [Page 4]
Mobility Services DHCP Options August 2007
Since the domain names are supposed to be different domains,
compression will likely have little effect, however.
If the length of the domain list exceeds the maximum permissible
within a single option (254 octets), then the domain list MUST be
represented in the DHCP message as specified in [7].
The DHCP option for this encoding has the following format:
Code Len enc DNS name of MoS server
+-----+-----+-----+-----+-----+-----+-----+-----+--
| XXX | 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:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|XXX|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 DHCP option for this encoding has the following format:
Code Len enc IPv4 Address 1 IPv4 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| XXX | n | 1 | a1 | a2 | a3 | a4 | a1 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
3. Mobility Server DHCPv6 Options
This section defines a DHCP for IPv6 (DHCPv6) option for the
discovery of a list of domain names or IPv6 addresses of Mobility
Servers.
The Mobility Server DHCPv6 options carry either a 128-bit (binary)
IPv6 address or, preferably, a DNS (RFC 1035 [6]) fully-qualified
domain name to be used by the MN to locate a server hosting either
an IS, an ES or a CS service.
G. Bajko Expires 02/20/08 [Page 5]
Mobility Services DHCP Options August 2007
The DHCPv6 option for this parameter is similarly formatted to the
DHCPv4 option.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MoS code | Length | enc | MoS Server ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| domain name or IP address list ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MoS code: option codes assigned by IANA (tbd)
Length: indicates the total number of octets in the option following
the 'Length' field, including the encoding byte
enc: one byte indicating the encoding type of the next field
The options have two 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. The 'Length' field
indicates the total number of octets in the option following the
'Length' field, including the encoding byte.
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 [7].
The code for the MIH IS dhcpv6 option is XXX. The code for the MIH
ES dhcpv6 option is YYY. The code for the MIH CS dhcpv6 option is
ZZZ.
3.1 Domain Name List
If the 'enc' byte has a value of 0, the encoding byte is followed by
a sequence of labels, as described in section 2.1
3.2 IPv6 address list
If the 'enc' byte has a value of 1, the encoding byte is followed by
a list of IPv6 addresses indicating appropriate MoS servers
available to the MN. Servers MUST be listed in order of preference.
4. Security Considerations
The security considerations in RFC 2131 [5]. 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,
G. Bajko Expires 02/20/08 [Page 6]
Mobility Services DHCP Options August 2007
possibly one that then would provide wrong information, event or
command for handover.
5. IANA Considerations
This document registers the following dhcpv4 options with IANA:
MIH IS dhcpv4 option
MIH ES dhcpv4 option
MIH CS dhcpv4 option
This document also registers the following dhcpv6 options with IANA:
MIH IS dhcpv6 option
MIH ES dhcpv6 option
MIH CS dhcpv6 option
5. Acknowledgements
Acknowledgements to the DT members.
6. Normative References
[1] IEEE 802.21 Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services
[4] Alexander, S. and R. Droms, "DHCP options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[6] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[7] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
RFC3396, November 2002.
[8] Bajko, G. " Locating Mobility Servers", draft-bajko-mos-dns-
discovery-00.txt
7. Informative References
8. Author's Addresses
Gabor Bajko
Nokia
gabor.bajko@nokia.com
G. Bajko Expires 02/20/08 [Page 7]
Mobility Services DHCP Options August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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).
G. Bajko Expires 02/20/08 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 06:00:00 |