RFC 5679

Locating IEEE 802.21 Mobility Services Using DNS

📅 published December 2009, from ietf

RFC 5679: Locating IEEE 802.21 Mobility Services Using DNS 🦋

okay bestie, this one is RFC 5679 ✨ It comes from the Network Working Group, and the author is G. Bajko from Nokia. It's on the Standards Track and dates from December 2009 📅 The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own 💅

Abstract

okay so this doc defines application service tags 🏷️ that let you find a service without depending on strict domain naming rules, plus DNS procedures for finding servers that offer the IEEE 802.21-defined Mobility Services 🌐 Those services help a Mobile Node (MN) that supports IEEE 802.21 get ready for a handover (network discovery) and pick the right network to hand over to (network selection) 🦋 The services covered here are the Media Independent Handover Services that IEEE 802.21 defines. this is the main character of the whole doc 👑

Status of This Memo

this doc specifies an Internet standards track protocol for the Internet community 🌸 it's also asking for discussion and suggestions for improvements 💬 for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📖 Distribution of this memo is unlimited 🎀

© 2009 the IETF Trust and the persons identified as the document authors. All rights reserved ✨ This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date ⚖️ read them carefully, because they explain your rights and restrictions for this doc 🫶 Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the BSD License describes 💜

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
      1.2. Terminology ................................................3
   2. Discovering a Mobility Server ...................................3
      2.1. Selecting a Mobility Service ...............................5
      2.2. Selecting the Transport Protocol ...........................5
      2.3. Determining the IP Address and Port ........................6
   3. IANA Considerations .............................................7
   4. Security Considerations .........................................8
   5. Normative References ............................................8
   6. Informative References ..........................................9

1. Introduction ✨

okay so IEEE 802.21 [IEEE802.21] defines three service types that help with link-layer handovers across different kinds of technology 🔥

  • a) MIH Information Service (MIHIS): IS gives higher-layer entities one unified framework across the mixed network environment 🗺️ It helps them find and pick between the different types of networks in a geographic area. The goal is to help higher-layer mobility protocols get the big picture of all the heterogeneous networks, so they can do a seamless handover across them 🦋
  • b) MIH Event Service (MIHES): Events can show changes in the state and transmission behaviour of the physical, data link, and logical link layers, or predict those changes 📡 Event Services can also be used to show management actions or command status from the network, or from some management entity 💅
  • c) MIH Command Service (MIHCS): this one lets higher layers control the physical, data link, and logical link layers 🎮 The higher layers may control the reconfiguration or selection of a suitable link through a set of handover commands 🫶

In IEEE terms, these are called Media Independent Handover (MIH) services 🌈 They can live on the same box, but the different patterns and types of info they give out don't force them to be co-located 🤷‍♀️

"Service Management" service messages (MIH registration, MIH capability discovery, and MIH event subscription messages) count as MIHES and MIHCS when they carry MIH messages over L3 transport 💌

A Mobile Node (MN) may use any one of these MIH service types on its own, or any combination of them 🧚

It's expected that a Mobility Server won't necessarily host all three MIH services together 😭 so there's a real need to discover each MIH service type separately 🔍

this doc defines a bunch of application service tags that let you locate a service without relying on rigid domain naming conventions 🎀

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 doc are to be read as described in [RFC2119] 📚 this is the part where the rules get their official meaning, so read it carefully 🧐

1.2. Terminology

okay the vocab 📖

  • Mobility Services: a set of different services the network gives to mobile nodes to help with handover preparation and handover decision, as described in [IEEE802.21] and [RFC5164] 🌸
  • Mobility Server: a network node that provides IEEE 802.21 Mobility Services 🖥️
  • MIH: Media Independent Handover, as defined in [IEEE802.21] 🦋
  • Application service: a generic term for some kind of application, no matter which protocol is used to offer it 💜 Each application service gets associated with an IANA-registered tag 🏷️
  • Application protocol: this is what's used to implement the application service 🛠️ These also get associated with IANA-registered tags ✨
  • Home domain: the DNS suffix of the operator the Mobile Node has a subscription service with 🏠 It's usually stored in the Mobile Node as part of the subscription 🫶

2. Discovering a Mobility Server

okay this part is my favourite 😭🔥 The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to do lazy binding of strings to data, so it can support dynamically configured delegation systems 🧩 It works by mapping some unique string to data stored in a DDDS database, applying string transformation rules over and over until it hits a terminal condition 🔁 When DDDS uses DNS as its distributed database of rules, those rules get encoded in the Naming Authority Pointer (NAPTR) Resource Record (RR) 📜 One of those rules is the First Well Known Rule, and it says where the process starts 🚦

In current specs, the First Well Known Rule in a DDDS application [RFC3403] is assumed to be fixed, meaning the domain in the tree where the lookups get routed to is already known 🌳 this doc proposes that the input to the First Well Known Rule be dynamic instead, based on the search path the resolver discovers or is configured with 🦋

The resolver's search path can be pre-configured, discovered using DHCP, or learned from a previous MIH Information Services (IS) query [IEEE802.21], as described in [RFC5677] 🗺️

When the MN needs to discover Mobility Services in its home domain, the input to the First Well Known Rule MUST be the MN's home domain 🏠 which is assumed to be pre-configured in the MN 💅

When the MN needs to discover Mobility Services in a local (visited) domain, it SHOULD use DHCP as described in [RFC5678] to discover the IP address of the server hosting the desired service, and then contact it directly 📡 In some cases, discovery may return a per protocol/application list of domain names, which then get used as starting points for the later NAPTR lookups 🔍 If neither the IP address nor the domain name can be discovered with the procedure above, the MN MAY request a domain search list, as described in [RFC3397] and [RFC3646], and use it as input to the DDDS application 🎀

The MN may also have a list of cached domain names of Service Providers, learned from a previous MIH Information Services (IS) query [IEEE802.21] 💾 If the cache entries haven't expired, they can be used as input to the DDDS application ✨

When the MN can't find valid domain names using the procedures above, it MUST stop any attempt to discover MIH services 🛑 no cap, that's a hard stop 😭

The dynamic rule described above SHOULD NOT be used for discovering services other than the MIH services described in this doc, unless a future specification says otherwise 🚫

The procedures defined here end with an IP address, a port, and a transport protocol that the MN can use to contact the Mobility Server hosting the service it's looking for 🎉💖

2.1. Selecting a Mobility Service

the MN should know the characteristics of the Mobility Services defined in [IEEE802.21], and based on that, it should be able to pick the service it wants to use to facilitate its handover 🧠 The options it can choose from are:

  • Information Services (MIHIS) 📚
  • Event Services (MIHES) 📡
  • Command Services (MIHCS) 🎮

The service identifiers for those services are "MIHIS", "MIHES", and "MIHCS", respectively 🏷️ The server supporting any of the above services MUST support at least UDP and TCP as transport, as described in [RFC5677] 🚚 SCTP and other transport protocols MAY also be supported 🌈

2.2. Selecting the Transport Protocol ✨

Okay so once the client has picked the service it wants, it picks the transport protocol it'd prefer to use 🦋 and ngl, transport choice can totally impact handover performance, so it's not a small decision 👀

The services that matter for transport selection are the ones with NAPTR service fields that look like ID+M2X. Here ID is the service identifier from the last section, and X is a letter for a transport protocol the domain supports. This spec defines M2U for UDP, M2T for TCP, and M2S for SCTP. It also sets up an IANA registry for mapping NAPTR service names to transport protocols 💅

These NAPTR [RFC3403] records give you a mapping from a domain to the SRV [RFC2782] record for reaching a server over a specific transport, which is whatever's in the NAPTR services field. The resource record MUST contain an empty regular expression and a replacement value. That replacement is the domain name where the SRV record for that transport lives. If the server supports multiple transports, there will be multiple NAPTR records, each with a different service value. As per [RFC3403], the client discards any records whose services fields aren't applicable 🙅‍♀️

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 processing as described in RFC 3403 will result in the discovery of the most preferred transport protocol of the server that's supported by the client, plus an SRV record for the server. Main character energy 👑

Here's an example. Say a client wants to find MIHIS service in the example.com domain. It does a NAPTR query for that domain and gets these NAPTR records back:

        Order Pref Flags  Service     Regexp       Replacement
IN NAPTR  50   50   "s"  "MIHIS+M2T"    ""  _MIHIS._tcp.example.com
IN NAPTR  90   50   "s"  "MIHIS+M2U"    ""  _MIHIS._udp.example.com

So the domain has a server providing MIHIS services over TCP and UDP, in that order of preference. The client supports both TCP and UDP, so TCP gets used, targeted at a host found through an SRV lookup of _MIHIS._tcp.example.com. That lookup would return:

;;          Priority  Weight    Port        Target
     IN  SRV    0        1      XXXX   server1.example.com
     IN  SRV    0        2      XXXX   server2.example.com

where XXXX stands for the port number the service is reachable on 🎀

If no NAPTR records are found, the client builds SRV queries for the transport protocols it supports and does a query for each one. The service identifier is "_MIHIS" for the MIH Information Service, "_MIHES" for the MIH Event Service, and "_MIHCS" for the MIH Command Service. A particular transport counts as supported if its query succeeds. The client MAY use any transport protocol it desires that the server supports 🧚

Quick note: the regexp field in the NAPTR example above is empty. The regexp field MUST NOT be used when discovering MIH services, because its usage can be complex and error prone 💀 Discovering MIH services also doesn't need the flexibility that this field gives you over a static target in the TARGET field, so nothing's lost.

Last bit: if the client is already configured with which transport protocol is used for a mobility service in a particular domain, it can skip the NAPTR stuff and do an SRV query for that transport directly, using the service identifier of the Mobility Service. For example, if the client knows it should be using TCP for MIHIS service, it can do an SRV query straight for _MIHIS._tcp.example.com. Efficient and iconic 🫶

2.3. Determining the IP Address and Port 🌈

Once you've figured out the server providing the desired service and the transport protocol, the next step is working out the IP address and port.

The response to the SRV DNS query contains the port number in the Port field of the SRV RDATA.

Per the SRV RR spec in [RFC2782], the TARGET field is a fully qualified domain name (FQDN) that MUST have one or more address records. The FQDN must not be an alias, meaning there MUST NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query already reported enough of these address records in the Additional Data section of the DNS response (as recommended by [RFC2782]), the MN needs to do A and/or AAAA record lookup(s) for the domain name, as appropriate. The result is a list of IP addresses, and each one can be contacted using the transport protocol picked earlier 🦋

3. IANA Considerations 🌸

Using NAPTR records the way described here needs well-known values for the service fields for each transport supported by Mobility Services. IANA maintains the table that maps service field values to transport protocols.

The registration in the RFC MUST include the following information:

  • Service Field: The service field being registered.
  • Protocol: The specific transport protocol associated with that service field. This MUST include the name and acronym for the protocol, along with a reference to a document that describes the transport protocol.
  • Name and Contact Information: The name, address, email address, and telephone number for the person doing the registration.

These values are already in the registry:

   Service Fields                    Protocol
      MIHIS+M2T                        TCP
      MIHIS+M2U                        UDP
      MIHIS+M2S                       SCTP
      MIHES+M2T                        TCP
      MIHES+M2U                        UDP
      MIHES+M2S                       SCTP
      MIHCS+M2T                        TCP
      MIHCS+M2U                        UDP
      MIHCS+M2S                       SCTP

New Service Fields get added via Standards Action as defined in [RFC5226] 📋

New entries that add more transport protocols for the existing Service Fields can also be registered by IANA through Standards Action [RFC5226] 💜

IANA is also asked to register MIHIS, MIHES, and MIHCS as service names in the Protocol and Service Names registry ✨

4. Security Considerations 💀

Okay, this section is serious business, bestie. Read it all 🚨

A list of known threats to services using DNS is documented in [RFC3833]. For most of those identified threats, the DNS Security Extensions [RFC4033] does provide protection. It is therefore recommended to consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational Practices [RFC4641] when deploying IEEE 802.21 Mobility Services.

In deployments where DNSSEC usage is not feasible, measures should be taken to protect against forged DNS responses and cache poisoning as much as possible. Efforts in this direction are documented in [RFC5452].

Where inputs to the procedure described in this document come in via DHCP, DHCP vulnerabilities can also cause issues. For instance, if DHCP discovery results can't be authenticated, the mobility service results may also be incorrect, even if the DNS process was secured. Even a perfect DNS setup isn't enough on its own 😭

5. Normative References 📚

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
  • [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
  • [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
  • [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
  • [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.
  • [RFC5678] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery", RFC 5678, December 2009.

6. Informative References 🧠

  • [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).
  • [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
  • [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
  • [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006.
  • [RFC5164] Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008.
  • [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009.

Author's Address 🎀

Gabor Bajko
Nokia
EMail: gabor.bajko@nokia.com
📦 where this page comes from