Locating IEEE 802.21 Mobility Services Using DNS
updated by
- rfc-8553 — DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
Extracted elements (22)
The document proposes making the input to the DDDS First Well Known Rule dynamic (based on resolver search path) rather than fixed, because a Mobility Server will not necessarily host all three MIH services together, requiring independent discovery of each service type.
The regexp field in NAPTR records is explicitly prohibited for MIH service discovery because it is complex, error prone, and the static TARGET field provides sufficient flexibility for this use case.
If the client is already configured with information about which transport protocol is used for a mobility service in a particular domain, it can bypass NAPTR lookup and directly perform an SRV query for that specific transport (e.g., _MIHIS._tcp.example.com).
Per RFC 2782, the SRV TARGET field MUST be an FQDN with one or more address records; there MUST NOT be a CNAME or DNAME RR at this name.
The dynamic DDDS rule described in this document SHOULD NOT be used for discovering services other than MIH services, unless stated otherwise by a future specification.
The MN MUST discard any service fields that identify a resolution service whose value is not 'M2X', for values of X that indicate transport protocols supported by the client.
The NAPTR resource record MUST contain an empty regular expression and a replacement value indicating the domain name where the SRV record for that particular transport protocol can be found.
The regexp field MUST NOT be used when discovering MIH services, as its usage can be complex and error prone, and the discovery does not require the flexibility it provides over a static target in the TARGET field.
The server supporting any of the MIH services (MIHIS, MIHES, MIHCS) MUST support at least UDP and TCP as transport; SCTP and other transport protocols MAY also be supported.
When the MN does not find valid domain names using the discovery procedures, it MUST stop any attempt to discover MIH services.
When the MN needs to discover Mobility Services in a local (visited) domain, it SHOULD use DHCP as described in RFC 5678 to discover the IP address of the server hosting the desired service.
If no NAPTR records are found, the client constructs SRV queries for each transport protocol it supports using the appropriate service identifier (_MIHIS, _MIHES, or _MIHCS). The client MAY use any transport protocol supported by both sides.
NAPTR service fields use the pattern 'ID+M2X' where ID is the service identifier (MIHIS, MIHES, or MIHCS) and X is a transport letter: M2T for TCP, M2U for UDP, M2S for SCTP.
SRV query service identifiers are '_MIHIS' for the MIH Information Service, '_MIHES' for the MIH Event Service, and '_MIHCS' for the MIH Command Service.
The search path for the DDDS First Well Known Rule can be pre-configured, discovered using DHCP, or learned from a previous MIH Information Services (IS) query as described in RFC 5677.
Three MIH service types are defined: MIH Information Service (MIHIS), MIH Event Service (MIHES), and MIH Command Service (MIHCS). These may be hosted separately and each requires independent DNS discovery.
IANA is requested to register MIHIS, MIHES, and MIHCS as service names in the Protocol and Service Names registry.
IANA maintains a registry mapping NAPTR service field values to transport protocols for MIH services. Initial entries include MIHIS+M2T/M2U/M2S, MIHES+M2T/M2U/M2S, and MIHCS+M2T/M2U/M2S mapped to TCP, UDP, and SCTP respectively. New entries require Standards Action.
Known DNS threats are documented in RFC 3833; DNSSEC (RFC 4033) provides protection against most of them. Deployments of IEEE 802.21 Mobility Services SHOULD consider DNSSEC and DNSSEC Operational Practices (RFC 4641).
Where DHCP feeds inputs to the discovery procedure, DHCP vulnerabilities (such as inability to authenticate discovery results) may cause mobility service discovery results to be incorrect even if DNS was secured.
Where DNSSEC is not feasible, measures should be taken against forged DNS responses and cache poisoning as described in RFC 5452.
NAPTR records for MIH services carry Order, Pref, Flags ('s'), Service field ('MIHIS+M2T', 'MIHIS+M2U', etc.), an empty Regexp field, and a Replacement pointing to the SRV name (e.g., _MIHIS._tcp.example.com).