idnits 2.17.1 draft-ietf-mipshop-mos-dns-discovery-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IEEE802.21]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 242 has weird spacing: '...f flags servi...' == Line 275 has weird spacing: '...f flags servi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 27, 2009) is 5448 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ID.ietf-mipshop-mos-dhcp-options' is defined on line 410, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP WG G. Bajko 3 Internet Draft Nokia 4 Intended Status: Proposed Standard May 27, 2009 5 Expires: November 26, 2009 7 Locating IEEE 802.21 Mobility Servers using DNS 8 draft-ietf-mipshop-mos-dns-discovery-05 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 26, 2009. 33 Copyright and License Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your 42 rights and restrictions with respect to this document. 44 Abstract 46 This document defines application service tags that allow service 47 location without relying on rigid domain naming conventions, and DNS 48 procedures for discovering servers which provide IEEE 802.21 49 [IEEE802.21] defined Mobility Services. Such Mobility Services are 50 used to assist a Mobile Node (MN) supporting IEEE 802.21 51 [IEEE802.21], in handover preparation (network discovery) and 52 handover decision (network selection). The services addressed by 53 this document are the Media Independent Handover Services defined in 54 [IEEE802.21]. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 60 this document are to be interpreted as described in RFC-2119. 62 Terminology and abbreviations used in this document 64 Mobility Services: comprises of a set of different services provided 65 by the network to mobile nodes to facilitate handover preparation 66 and handover decision, as described in [IEEE802.21]. 68 Mobility Server: a network node providing IEEE 802.21 Mobility 69 Services. 71 MIH: Media Independent Handover, as defined in [IEEE802.21]. 73 MIH Service: IS, ES or CS type of service, as defined in 74 [IEEE802.21]. 76 Application service: is a generic term for some type of 77 application, independent of the protocol that may be used to offer 78 it. Each application service will be associated with an IANA- 79 registered tag. 81 Application protocol: is used to implement the application service. 82 These are also associated with IANA-registered tags. 84 Table of Content 86 1. Introduction....................................................2 87 2. Discovering a Mobility Server...................................3 88 2.1 Selecting a Mobility Service..............................4 89 2.2 Selecting the transport protocol..........................4 90 2.3 Determining the IP address and port.......................6 91 3. IANA Considerations.............................................6 92 4. Security Considerations.........................................7 93 5. Normative References............................................8 94 6. Informative References..........................................8 95 7. Author's Address................................................9 97 1. Introduction 99 IEEE 802.21 [IEEE802.21] defines three distinct service types to 100 facilitate link layer handovers across heterogeneous technologies: 102 a) Information Services (IS) 103 IS provides a unified framework to the higher layer entities 104 across the heterogeneous network environment to facilitate 105 discovery and selection of multiple types of networks existing 106 within a geographical area, with the objective to help the 107 higher layer mobility protocols to acquire a global view of the 108 heterogeneous networks and perform seamless handover across 109 these networks. 111 b) Event Services (ES) 112 Events may indicate changes in state and transmission behavior 113 of the physical, data link and logical link layers, or predict 114 state changes of these layers. The Event Service may also be 115 used to indicate management actions or command status on the 116 part of the network or some management entity. 118 c) Command Services (CS) 119 The command service enables higher layers to control the 120 physical, data link, and logical link layers. The higher layers 121 may control the reconfiguration or selection of an appropriate 122 link through a set of handover commands. 124 In IEEE terminology these services are called Media Independent 125 Handover (MIH) services. 126 While these services may be co-located, the different pattern and 127 type of information they provide does not necessitate the co- 128 location. 130 "Service Management" service messages, i.e., MIH registration, MIH 131 capability discovery and MIH event subscription messages, are 132 considered as ES and CS when transporting MIH messages over L3 133 transport. 135 An MN may make use of any of these MIH service types separately or 136 any combination of them. 138 It is anticipated that a Mobility Server will not necessarily host 139 all three of these MIH Services together, thus there is a need to 140 discover the MIH Service types separately. 142 This document defines a number of application service tags that 143 allow service location without relying on rigid domain naming 144 conventions. 146 2. Discovering a Mobility Server 148 In current specifications, the First Well Known Rule in a DDDS 149 application [RFC3402] is assumed to be fixed, ie the domain in the 150 tree where the lookups are to be routed to, is known. This document 151 proposes the input to the First Well Known Rule to be dynamic, based 152 on the search path the resolver discovers or is configured with. 154 The search path of the resolver can either be pre-configured, 155 discovered using DHCP or learned from a previous MIH Information 156 Service (IS) query [IEEE802.21] as described in 157 [ID.ietf-mipshop-mstp-solution]. 159 When the MN needs to discover Mobility Services in its home domain, 160 the input to the First Well Known Rule MUST be the MN's home domain, 161 which is assumed to be pre-configured in the MN. 163 When the MN needs to discover Mobility Services in a local (visited) 164 domain, it SHOULD use DHCP as described in [ID.ietf-mipshop-mos- 165 dhcp-options] to discover a per protocol/application list of domain 166 names which are to be used as starting points for the subsequent 167 NAPTR lookups. If the above procedure produces no result, the MN MAY 168 request for a domain search list, as described in [RFC3397] and 169 [RFC3646], and use it as input to the DDDS application. 171 The MN may also have a list of cached domain names of Service 172 Providers, learned from a previous MIH Information Service (IS) 173 query [IEEE802.21]. If the cache entries have not expired, they can 174 be used as input to the DDDS application. 176 When the MN does not find valid domain names using the procedures 177 above, it MUST stop any attempt to discover MIH Services. 179 The dynamic rule described above SHOULD NOT be used for discovering 180 services other than MIH Services described in this document, unless 181 stated otherwise by a future specification. 183 The procedures defined here result in an IP address, port and 184 transport protocol where the MN can contact the Mobility Server 185 which hosts the service the MN is looking for. 187 2.1 Selecting a Mobility Service 189 The MN should know the characteristics of the Mobility Services 190 defined in [IEEE802.21] and based on that it should be able to 191 select the service it wants to use to facilitate its handover. The 192 services it can choose from are: 193 - Information Service (IS) 194 - Information Service over a secure connection (ISs) 195 - Event Service (ES) 196 - Event Service over a secure connection (ESs) 197 - Command Service (CS) 198 - Command Service over a secure connection (CSs) 200 The service identifiers for the services are "MIHIS","MIHISs", 201 "MIHES", "MIHESs", "MIHCS" and "MIHCSs" respectively. 202 The server supporting any of the above services MUST support at 203 least UDP and TCP as transport, as described in [ID.ietf-mipshop- 204 mstp-solution]. SCTP and other transport protocols MAY also be 205 supported. 207 2.2 Selecting the transport protocol 209 After the desired service has been chosen, the client selects the 210 transport protocol it prefers to use. Note, that transport selection 211 may impact the handover performance. 213 The services relevant for the task of transport protocol selection 214 are those with NAPTR service fields with values "ID+M2X", where ID 215 is the service identifier defined in the previous section and X is a 216 letter that corresponds to a transport protocol supported by the 217 domain. This specification defines M2U for UDP, M2T for TCP and M2S 218 for SCTP. This document also establishes an IANA registry for 219 NAPTR service name to transport protocol mappings. 221 These NAPTR [RFC3403] records provide a mapping from a domain to the 222 SRV [RFC2782] record for contacting a server with the specific 223 transport protocol in the NAPTR services field. The resource record 224 will contain an empty regular expression and a replacement value, 225 which indicates the domain name where the SRV record for that 226 particular transport protocol can be found. If the server supports 227 multiple transport protocols, there will be multiple NAPTR records, 228 each with a different service value. As per [RFC3403], the client 229 discards any records whose services fields are not applicable. 231 The MN MUST discard any service fields that identify a resolution 232 service whose value is not "M2X", for values of X that indicate 233 transport protocols supported by the client. The NAPTR processing 234 as described in RFC 3403 will result in the discovery of the most 235 preferred transport protocol of the server that is supported by the 236 client, as well as an SRV record for the server. 238 As an example, consider a client that wishes to find MIHIS service 239 in the example.com domain. The client performs a NAPTR query for 240 that domain, and the following NAPTR records are returned: 242 order pref flags service regexp replacement 243 IN NAPTR 50 50 "s" "MIHIS+M2T" "" _MIHIS._tcp.example.com 244 IN NAPTR 90 50 "s" "MIHIS+M2U" "" _MIHIS._udp.example.com 246 This indicates that the domain does have a server providing MIHIS 247 services over TCP and UDP, in that order of preference. Since the 248 client supports TCP and UDP, TCP will be used, targeted to a host 249 determined by an SRV lookup of _MIHIS._tcp.example.com. That lookup 250 would return: 252 ;; Priority Weight Port Target 253 IN SRV 0 1 XXXX server1.example.com 254 IN SRV 0 2 XXXX server2.example.com 256 If no NAPTR records are found, the client constructs SRV queries for 257 those transport protocols it supports, and does a query for each. 259 Queries are done using the service identifier "_MIHIS" for the MIH 260 Information Service, "_MIHES" for the MIH Event Service and "_MIHCS" 261 for the MIH Command Service. A particular transport is supported if 262 the query is successful. The client MAY use any transport protocol 263 it desires which is supported by the server. 265 Note, that the regexp field in the NAPTR example above is empty. 266 This document discourages the use of this field as its usage can be 267 complex and error prone; and the discovery of the MIH services do 268 not require the flexibility provided by this field over a static 269 target present in the TARGET field. 271 As another example, consider a client which wishes to find an MIHES 272 service over a secure connection. The client performs a NAPTR query 273 for that domain, and the following NAPTR records are returned: 275 order pref flags service regexp replacement 276 IN NAPTR 50 50 "s" "MIHESs+M2T" "" _MIHESs._tcp.example.com 277 IN NAPTR 90 50 "s" "ESs+M2U" "" _MIHESs._udp.example.com 279 This indicates that the domain does have a server providing MIHES 280 services over a secure connection, in the above case TLSoverTCP and 281 DTLSoverUDP. 283 When a transport protocol is specified explicitly, the client will 284 perform an SRV query for that specific transport using the service 285 identifier of the Mobility Service. 287 2.3 Determining the IP address and port 289 Once the server providing the desired service and the transport 290 protocol has been determined, the next step is to determine the IP 291 address and port. 293 If TARGET is a numeric IP address, the MN uses that IP address and 294 the already chosen transport to contact the server providing the 295 desired service. 297 If the TARGET was not a numeric IP address, then the MN performs an 298 A and/or AAAA record lookup of the domain name, as appropriate. The 299 result will be a list of IP addresses, each of which can be 300 contacted using the transport protocol determined previously. 302 If the result of the SRV query contains a port number, then the MN 303 SHOULD contact the server at that port number. If the SRV record did 304 not contain a port number then the MN SHOULD contact the server at 305 the default port number of that particular service. A default port 306 number for MIH services is requested from IANA in [ID.ietf-mipshop- 307 mstp-solution]. 309 3. IANA considerations 310 The usage of NAPTR records described here requires well known values 311 for the service fields for each transport supported by Mobility 312 Services. The table of mappings from service field values to 313 transport protocols is to be maintained by IANA. 315 The registration in the RFC MUST include the following information: 317 Service Field: The service field being registered. 319 Protocol: The specific transport protocol associated with that 320 service field. This MUST include the name and acronym for the 321 protocol, along with reference to a document that describes the 322 transport protocol. 324 Name and Contact Information: The name, address, email address 325 and telephone number for the person performing the 326 registration. 328 The following values have been placed into the registry: 330 Service Fields Protocol 331 MIHIS+M2T TCP 332 MIHISs+M2T TLSoverTCP (RFC 5246) 333 MIHIS+M2U UDP 334 MIHISs+M2U DTLSoverUDP (RFC 4347) 335 MIHIS+M2S SCTP 336 MIHISs+M2S TSLoverSCTP (RFC 3436) 337 MIHES+M2T TCP 338 MIHESs+M2T TLSoverTCP (RFC 5246) 339 MIHES+M2U UDP 340 MIHESs+M2U DTLSoverUDP (RFC 4347) 341 MIHES+M2S SCTP 342 MIHESs+M2S TLSoverSCTP (RFC 3436) 343 MIHCS+M2T TCP 344 MIHCSs+M2T TLSoverTCP (RFC 5246) 345 MIHCS+M2U UDP 346 MIHCSs+M2U DTLSoverUDP (RFC 4347) 347 MIHCS+M2S SCTP 348 MIHCSs+M2S TLSoverSCTP (RFC 3436) 350 New Service Fields are to be added via Standards Action as defined 351 in [RFC5226]. 352 New entries to the table that specify additional transport protocols 353 for the existing Service Fields may be registered by IANA on a First 354 Come First Served' basis [RFC5226]. 356 4. Security considerations 358 A list of known threats to services using DNS is documented in 359 [RFC3833]. For most of those identified threats, the DNS Security 360 Extensions [RFC4033] does provide protection. It is therefore 361 recommended to consider the usage of DNSSEC [RFC4033] and the 362 aspects of DNSSEC Operational Practices [RFC4641] when deploying 363 IEEE 802.21 Mobility Services. 365 In deployments where DNSSEC usage is not feasible, measures should 366 be taken to protect against forged DNS responses and cache poisoning 367 as much as possible. Efforts in this direction are documented in 368 [ID.ietf-dnsext-forgery-resilience]. 370 5. Normative References 372 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 373 specifying the location of services (DNS SRV)", RFC 2782, 374 February 2000. 376 [RFC3402] M. Mealling, "Dynamic Delegation Discovery System (DDDS) 377 Part Two: The Algorithm", RFC 3402, October 2002. 379 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 380 Part Three: The Domain Name System (DNS) Database", RFC 3403, 381 October 2002. 383 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 384 Rose, "DNS Security Introduction and Requirements", RFC 4033, 385 March 2005. 387 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 388 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 389 2008. 390 [RFC3397] B. Aboba and S. Cheshire, "DHCP Domain Search Option", RFC 391 3397, November 2002. 393 [RFC3646] R. Droms, "DNS Configuration options for DHCPv6", RFC 394 3646, December 2003. 396 6. Informative References 398 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 399 Networks: Media Independent Handover Services 401 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 402 RFC 4641, September 2006. 404 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 405 Name System (DNS)", RFC 3833, August 2004. 407 [ID.ietf-mipshop-mstp-solution] Mobility Services Transport Protocol 408 Design, Melia et al, April 2008, work in progress 410 [ID.ietf-mipshop-mos-dhcp-options] DHCP Options for IEEE 802.21 411 Mobility Services (MoS) Discovery, Bajko et al, May 2009, work 412 in progress 414 [ID.ietf-dnsext-forgery-resilience] Measures for making DNS more 415 resilient against forged answers, Hubert et al, August 2008, 416 work in progress 418 7. Author's Addresses 420 Gabor Bajko 421 gabor(dot)bajko(at)nokia(dot)com