Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery
Extracted elements (26)
Both IP address and FQDN variants of the MoS option are defined to give deployers a choice: direct address provisioning for simple cases and DNS-based discovery (via RFC 5679 NAPTR/SRV) for more flexible deployments.
Separate sub-option codes for IS, CS, and ES are defined because Mobility Servers may not host all three MIH service types together, and the different patterns of information they provide do not require co-location.
A DHCP client SHOULD be prepared to accept a response from a server that includes sub-options other than those requested, or that omits the requested sub-options entirely.
Multiple domain names in a MoS FQDN sub-option are intended to reference NAPTR records of different providers, not multiple A records of the same provider; this mechanism complements rather than replaces NAPTR and SRV records.
If the DHCP server cannot find any Mobility Server satisfying a requested sub-option, it SHOULD return the MoS Option with that sub-option and its length set to 0.
IPv4 and IPv6 MIH server addresses in sub-options MUST be listed in order of preference; the client should process them in decreasing order of preference.
The DHCP client (mobile node) MUST try domain name records in the listed order, applying the DNS-based MIH discovery mechanism from RFC 5679 for each, and only proceeds to the next name if the previous attempt failed or yielded no common transport protocols.
To discover MoS via DHCPv4, the mobile node MUST include either a MoS IPv4 Address Option or a MoS Domain Name List Option in the Parameter Request List (PRL) in its DHCP messages per RFC 2131.
To discover MoS via DHCPv6, the mobile node MUST include either a MoS IPv6 Address Option or a MoS Domain Name List Option in the Option Request Option (ORO) per RFC 3315.
When the DHCPv4 server receives a MoS IPv4 Address or MoS Domain Name List Option in the PRL, it MUST include the option in its response message as defined in RFC 2131.
When the DHCPv6 server receives a MoS IPv6 Address or MoS Domain Name List Option in the ORO, it MUST include the option in its response message as defined in RFC 3315.
When the total length of a MoS Domain Name List Option for DHCPv4 exceeds 254 octets, the procedure in RFC 3396 MUST be used to split the option into multiple smaller options.
When the total length of a MoS IPv4 Address Option exceeds 254 octets, the procedure in RFC 3396 MUST be used to split the option into multiple smaller options.
OPTION-IPv4_Address-MoS (code 139) is a DHCPv4 option carrying a list of IPv4 addresses of IEEE 802.21 Mobility Servers, structured as an option code (1 byte), length (1 byte), and a series of sub-options keyed by MIH service type.
OPTION-IPv4_FQDN-MoS (code 140) is a DHCPv4 option carrying a list of FQDNs of IEEE 802.21 Mobility Servers, structured as option code (1 byte), length (1 byte), and sub-options containing domain names encoded per RFC 3315 Section 8.
OPTION-IPv6_Address-MoS (code 54) is a DHCPv6 option carrying IPv6 addresses of IEEE 802.21 Mobility Servers, with a 2-byte option code, 2-byte length, and sub-options whose Sub-opt Code and Length fields are each 2 octets.
OPTION-IPv6_FQDN-MoS (code 55) is a DHCPv6 option carrying FQDNs of IEEE 802.21 Mobility Servers, with a 2-byte option code and 2-byte length; its sub-option encoding is identical to the DHCPv4 FQDN option except for the wider code and length fields.
Sub-options are keyed by MIH service type: sub-option code 1 = Information Services (IS), 2 = Command Services (CS), 3 = Event Services (ES). This sub-option scheme is shared across all four MoS DHCP options.
This document registers DHCPv4 option codes 139 (OPTION-IPv4_Address-MoS) and 140 (OPTION-IPv4_FQDN-MoS), and creates the 'IEEE 802.21 Service Type' sub-option registry with IS=1, CS=2, ES=3; values 0 and 255 are reserved; new values require Standards Action.
This document registers DHCPv6 option codes 54 (OPTION-IPv6_Address-MoS) and 55 (OPTION-IPv6_FQDN-MoS), and creates the 'IEEE 802.21 IPv6 Service Type' sub-option registry with IS=1, CS=2, ES=3; values 0 and 65535 are reserved; new values require Standards Action.
An adversary that modifies or spoofs a DHCP response could direct a mobile node to a rogue Mobility Server, which could then supply incorrect handover information, events, or commands. DHCP authentication per RFC 3118 is recommended where available to prevent both message tampering and denial-of-service attacks against DHCP servers.
For domain name resolution of MoS FQDNs, use of DNSSEC (RFC 4033) and DNSSEC Operational Practices (RFC 4641) is recommended. Security considerations from RFC 5679 (DNS-based MIH discovery) also apply.
DHCPv4 MoS Domain Name sub-option: Sub-opt Code (1 byte, 1–3), Length (1 byte), followed by one or more FQDNs encoded as a sequence of DNS labels per RFC 3315 Section 8 (length-prefixed labels, zero-length terminator).
DHCPv4 MoS IPv4 Address sub-option: Sub-opt Code (1 byte, 1–3), Length (1 byte), followed by one or more 4-byte IPv4 addresses. Length is 0 if no server is available, otherwise a multiple of 4.
DHCPv6 MoS Domain Name sub-option: Sub-opt Code (2 bytes), Length (2 bytes), followed by FQDNs in the same label-encoded format as the DHCPv4 variant. Semantics and content are identical to Section 3.
DHCPv6 MoS IPv6 Address sub-option: Sub-opt Code (2 bytes), Length (2 bytes, excludes code and length fields), followed by one or more 16-byte IPv6 addresses. Length is 0 if no server is available, otherwise a multiple of 16.