doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc5679.txt b/doc/rfc/rfc5679.txt
new file mode 100644
index 0000000..f049c82
--- /dev/null
+++ b/doc/rfc/rfc5679.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Bajko                       Standards Track                     [Page 1]
+
+RFC 5679          Locating Mobility Services Using DNS     December 2009
+
+
+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.
+
+
+
+
+
+
+
+Bajko                       Standards Track                     [Page 2]
+
+RFC 5679          Locating Mobility Services Using DNS     December 2009
+
+
+   "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
+
+
+
+Bajko                       Standards Track                     [Page 3]
+
+RFC 5679          Locating Mobility Services Using DNS     December 2009
+
+
+   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.
+
+
+
+
+
+Bajko                       Standards Track                     [Page 4]
+
+RFC 5679          Locating Mobility Services Using DNS     December 2009
+
+
+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.
+
+
+
+
+
+Bajko                       Standards Track                     [Page 5]
+
+RFC 5679          Locating Mobility Services Using DNS     December 2009
+
+
+   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.
+
+
+
+Bajko                       Standards Track                     [Page 6]
+
+RFC 5679          Locating Mobility Services Using DNS     December 2009
+
+
+   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].
+
+
+
+Bajko                       Standards Track                     [Page 7]
+
+RFC 5679          Locating Mobility Services Using DNS     December 2009
+
+
+   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.
+
+
+
+
+Bajko                       Standards Track                     [Page 8]
+
+RFC 5679          Locating Mobility Services Using DNS     December 2009
+
+
+   [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
+
+
+
+Bajko                       Standards Track                     [Page 9]
+