diff options
Diffstat (limited to 'doc/rfc/rfc5678.txt')
| -rw-r--r-- | doc/rfc/rfc5678.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc5678.txt b/doc/rfc/rfc5678.txt new file mode 100644 index 0000000..e4a2039 --- /dev/null +++ b/doc/rfc/rfc5678.txt @@ -0,0 +1,787 @@ + + + + + + +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. + + + + + + + + +Bajko & Das Standards Track [Page 1] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + +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. + + + + + + + +Bajko & Das Standards Track [Page 2] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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: + + + + + +Bajko & Das Standards Track [Page 3] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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 . . . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + +Bajko & Das Standards Track [Page 4] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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 | + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Bajko & Das Standards Track [Page 5] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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 | ... + +-----+----+----+-----+-----+-----+-----+-- + + + +Bajko & Das Standards Track [Page 6] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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: + + + + + + + + + + + + + + + +Bajko & Das Standards Track [Page 7] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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 | + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + +Bajko & Das Standards Track [Page 8] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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 + + + + +Bajko & Das Standards Track [Page 9] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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. + + + +Bajko & Das Standards Track [Page 10] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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 + + + + +Bajko & Das Standards Track [Page 11] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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 + + + + + +Bajko & Das Standards Track [Page 12] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + 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. + + + + +Bajko & Das Standards Track [Page 13] + +RFC 5678 Mobility Services for DCHP Options December 2009 + + + [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 + + + +Bajko & Das Standards Track [Page 14] + |