Network Working Group G. Bajko
Request for Comments: 5679 Nokia
Category: Standards Track December 2009
 Locating IEEE 802.21 Mobility Services Using DNS
Abstract
 This document defines application service tags that allow service
 location without relying on rigid domain naming conventions, and DNS
 procedures for discovering servers that provide IEEE 802.21-defined
 Mobility Services. Such Mobility Services are used to assist a
 Mobile Node (MN) supporting IEEE 802.21, in handover preparation
 (network discovery) and handover decision (network selection). The
 services addressed by 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.
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
 IEEE 802.21 [IEEE802.21] defines three distinct service types to
 facilitate link-layer handovers across heterogeneous technologies:
 a) MIH Information Service (MIHIS)
 IS provide 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) MIH Event Service (MIHES)
 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 Services may also be used to
 indicate management actions or command status on the part of the
 network or some management entity.
 c) MIH Command Service (MIHCS)
 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 do not
 necessitate the co-location.
 "Service Management" service messages, i.e., MIH registration, MIH
 capability discovery and MIH event subscription messages, are
 considered as MIHES and MIHCS when transporting MIH messages over L3
 transport.
 A Mobile Node (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 service types separately.
 This document defines a number of application service tags that allow
 service location 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
 document are to be interpreted as described in [RFC2119].
1.2. Terminology
 Mobility Services: composed of a set of different services provided
 by the network to mobile nodes to facilitate handover preparation and
 handover decision, as described in [IEEE802.21] and [RFC5164].
 Mobility Server: a network node providing IEEE 802.21 Mobility
 Services.
 MIH: Media Independent Handover, as defined in [IEEE802.21].
 Application service: is a generic term for some type of application,
 independent of the protocol that may be used to offer it. Each
 application service will be associated with an IANA-registered tag.
 Application protocol: is used to implement the application service.
 These are also associated with IANA-registered tags.
 Home domain: the DNS suffix of the operator with which the Mobile
 Node has a subscription service. The suffix is usually stored in the
 Mobile Node as part of the subscription.
2. Discovering a Mobility Server
 The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to
 implement lazy binding of strings to data, in order to support
 dynamically configured delegation systems. The DDDS functions by
 mapping some unique string to data stored within a DDDS database by
 iteratively applying string transformation rules until a terminal
 condition is reached. When DDDS uses DNS as a distributed database
 of rules, these rules are encoded using the Naming Authority Pointer
 (NAPTR) Resource Record (RR). One of these rules is the First Well
 Known Rule, which says where the process starts.
 In current specifications, the First Well Known Rule in a DDDS
 application [RFC3403] is assumed to be fixed, i.e., the domain in the
 tree where the lookups are to be routed to, is known. This document
 proposes the input to the First Well Known Rule to be dynamic, based
 on the search path the resolver discovers or is configured with.
 The search path of the resolver can either 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 contact it
 directly. In some instances, the discovery may result in a per
 protocol/application list of domain names that are then used as
 starting points for the subsequent NAPTR lookups. If neither the IP
 address or domain name can be discovered with the above procedure,
 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 have not expired, they can
 be used as input to the DDDS application.
 When the MN does not find valid domain names using the procedures
 above, it MUST stop any attempt to discover MIH services.
 The dynamic rule described above SHOULD NOT be used for discovering
 services other than MIH services described in this document, unless
 stated otherwise by a future specification.
 The procedures defined here result in an IP address, port, and
 transport protocol where the MN can contact the Mobility Server that
 hosts the service the MN is 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
 select the service it wants to use to facilitate its handover. The
 services it can choose from are:
 - Information Services (MIHIS)
 - Event Services (MIHES)
 - Command Services (MIHCS)
 The service identifiers for the 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
 After the desired service has been chosen, the client selects the
 transport protocol it prefers to use. Note that transport selection
 may impact the handover performance.
 The services relevant for the task of transport protocol selection
 are those with NAPTR service fields with values "ID+M2X", where ID is
 the service identifier defined in the previous section, and X is a
 letter that corresponds to a transport protocol supported by the
 domain. This specification defines M2U for UDP, M2T for TCP and M2S
 for SCTP. This document also establishes an IANA registry for
 mappings of NAPTR service name to transport protocol.
 These NAPTR [RFC3403] records provide a mapping from a domain to the
 SRV [RFC2782] record for contacting a server with the specific
 transport protocol in the NAPTR services field. The resource record
 MUST contain an empty regular expression and a replacement value,
 which indicates the domain name where the SRV record for that
 particular transport protocol can be found. If the server supports
 multiple transport protocols, there will be multiple NAPTR records,
 each with a different service value. As per [RFC3403], the client
 discards any records whose services fields are not 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 is supported by the
 client, as well as an SRV record for the server.
 As an example, consider a client that wishes to find MIHIS service in
 the example.com domain. The client performs a NAPTR query for that
 domain, and the following NAPTR records are returned:
 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
 This indicates that the domain does have a server providing MIHIS
 services over TCP and UDP, in that order of preference. Since the
 client supports TCP and UDP, TCP will be used, targeted to a host
 determined by 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 represents the port number at which the service is
 reachable.
 If no NAPTR records are found, the client constructs SRV queries for
 those transport protocols it supports, and does a query for each.
 Queries are done using the service identifier "_MIHIS" for the MIH
 Information Service, "_MIHES" for the MIH Event Service and "_MIHCS"
 for the MIH Command Service. A particular transport is supported if
 the query is successful. The client MAY use any transport protocol
 it desires that is supported by the server.
 Note that the regexp field in the NAPTR example above is empty. The
 regexp field MUST NOT be used when discovering MIH services, as its
 usage can be complex and error prone. Also, the discovery of the MIH
 services does not require the flexibility provided by this field over
 a static target present in the TARGET field.
 If the client is already configured with the information about which
 transport protocol is used for a mobility service in a particular
 domain, it can directly perform an SRV query for that specific
 transport using the service identifier of the Mobility Service. For
 example, if the client knows that it should be using TCP for MIHIS
 service, it can perform a SRV query directly for
 _MIHIS._tcp.example.com.
2.3. Determining the IP Address and Port
 Once the server providing the desired service and the transport
 protocol has been determined, the next step is to determine the IP
 address and port.
 The response to the SRV DNS query contains the port number in the
 Port field of the SRV RDATA.
 According to the specification of SRV RRs 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, i.e., there MUST
 NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query
 already has reported a sufficient number of these address records in
 the Additional Data section of the DNS response (as recommended by
 [RFC2782]), the MN needs to perform A and/or AAAA record lookup(s) of
 the domain name, as appropriate. The result will be a list of IP
 addresses, each of which can be contacted using the transport
 protocol determined previously.
3. IANA Considerations
 The usage of NAPTR records described here requires well-known values
 for the service fields for each transport supported by Mobility
 Services. The table of mappings from service field values to
 transport protocols is to be maintained by IANA.
 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 reference to a document that describes the
 transport protocol.
 Name and Contact Information: The name, address, email address,
 and telephone number for the person performing the registration.
 The following values have been placed into 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 are to be added via Standards Action as defined in
 [RFC5226].
 New entries to the table that specify additional transport protocols
 for the existing Service Fields may similarly be registered by IANA
 through Standards Action [RFC5226].
 IANA is also requested to register MIHIS, MIHES, MIHCS as service
 names in the Protocol and Service Names registry.
4. Security Considerations
 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 are fed via
 DHCP, DHCP vulnerabilities can also cause issues. For instance, the
 inability to authenticate DHCP discovery results may lead to the
 mobility service results also being incorrect, even if the DNS
 process was secured.
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