idnits 2.17.1 draft-ietf-mipshop-mos-dns-discovery-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 431. 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 Copyright Line does not match the current year == Line 211 has weird spacing: '...f flags servi...' == Line 246 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 (October 17, 2008) is 5667 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) ** 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 (~~), 3 warnings (==), 8 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 October 17, 2008 5 Expires: April 16, 2009 7 Locating IEEE 802.21 Mobility Servers using DNS 8 draft-ietf-mipshop-mos-dns-discovery-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 16, 2009. 35 Abstract 37 This document defines application service tags that allow service 38 location without relying on rigid domain naming conventions, and DNS 39 procedures for discovering servers which provide IEEE 802.21 40 [IEEE802.21] defined Mobility Services. Such Mobility Services are 41 used to assist a Mobile Node (MN) supporting IEEE 802.21 42 [IEEE802.21], in handover preparation (network discovery) and 43 handover decision (network selection). The services addressed by 44 this document are the Media Independent Handover Services defined in 45 [IEEE802.21]. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC-2119. 53 Locating Mobility Servers using DNS October 2008 55 Terminology and abbreviations used in this document 57 Mobility Services: comprises of a set of different services provided 58 by the network to mobile nodes to facilitate handover preparation 59 and handover decision, as described in [IEEE802.21]. 61 Mobility Server: a network node providing IEEE 802.21 Mobility 62 Services. 64 MIH: Media Independent Handover, as defined in [IEEE802.21]. 66 MIH Service: IS, ES or CS type of service, as defined in 67 [IEEE802.21]. 69 Application service: is a generic term for some type of 70 application, independent of the protocol that may be used to offer 71 it. Each application service will be associated with an IANA- 72 registered tag. 74 Application protocol: is used to implement the application service. 75 These are also associated with IANA-registered tags. 77 Table of Content 79 1. Introduction....................................................2 80 2. Discovering a Mobility Server...................................3 81 2.1 Selecting a Mobility Service..............................3 82 2.2 Selecting the transport protocol..........................4 83 2.3 Determining the IP address and port.......................5 84 3. IANA Considerations.............................................6 85 4. Security Considerations.........................................6 86 5. Normative References............................................6 87 6. Informative References..........................................7 88 7. Author's Address................................................7 90 1. Introduction 92 IEEE 802.21 [IEEE802.21] defines three distinct service types to 93 facilitate link layer handovers across heterogeneous technologies: 95 a) Information Services (IS) 96 IS provides a unified framework to the higher layer entities 97 across the heterogeneous network environment to facilitate 98 discovery and selection of multiple types of networks existing 99 within a geographical area, with the objective to help the 100 higher layer mobility protocols to acquire a global view of the 101 heterogeneous networks and perform seamless handover across 102 these networks. 104 b) Event Services (ES) 105 Events may indicate changes in state and transmission behavior 106 of the physical, data link and logical link layers, or predict 108 Locating Mobility Servers using DNS October 2008 110 state changes of these layers. The Event Service may also be 111 used to indicate management actions or command status on the 112 part of the network or some management entity. 114 c) Command Services (CS) 115 The command service enables higher layers to control the 116 physical, data link, and logical link layers. The higher layers 117 may control the reconfiguration or selection of an appropriate 118 link through a set of handover commands. 120 In IEEE terminology these services are called Media Independent 121 Handover (MIH) services. 122 While these services may be co-located, the different pattern and 123 type of information they provide does not necessitate the co- 124 location. 126 "Service Management" service messages, i.e., MIH registration, MIH 127 capability discovery and MIH event subscription messages, are 128 considered as ES and CS when transporting MIH messages over L3 129 transport. 131 An MN may make use of any of these MIH service types separately or 132 any combination of them. 134 It is anticipated that a Mobility Server will not necessarily host 135 all three of these MIH Services together, thus there is a need to 136 discover the MIH Service types separately. 138 This document defines a number of application service tags that 139 allow service location without relying on rigid domain naming 140 conventions. 142 2. Discovering a Mobility Server 144 The procedures defined here assume that the MN knows the domain name 145 of the network where it wants to locate a Mobility Server. The 146 domain name of the network can either be pre-configured, discovered 147 using DHCP or learned from a previous Information Service (IS) query 148 [IEEE802.21] as described in [ID.ietf-mipshop-mstp-solution]. 149 The procedures defined here result in an IP address, port and 150 transport protocol where the MN can contact the Mobility Server 151 which hosts the service the MN is looking for. 153 2.1 Selecting a Mobility Service 155 The MN should know the characteristics of the Mobility Services 156 defined in [IEEE802.21] and based on that it should be able to 157 select the service it wants to use to facilitate its handover. The 158 services it can choose from are: 159 - Information Service (IS) 160 - Information Service over a secure connection (ISs) 161 - Event Service (ES) 163 Locating Mobility Servers using DNS October 2008 165 - Event Service over a secure connection (ESs) 166 - Command Service (CS) 167 - Command Service over a secure connection (CSs) 169 The service identifiers for the services are "IS","ISs", "ES", 170 "ESs", "CS" and "CSs" respectively. 171 The server supporting any of the above services MUST support at 172 least UDP and TCP as transport, as described in [ID.ietf-mipshop- 173 mstp-solution]. SCTP and other transport protocols MAY also be 174 supported. 176 2.2 Selecting the transport protocol 178 After the desired service has been chosen, the client selects the 179 transport protocol it prefers to use. Note, that transport selection 180 may impact the handover performance. 182 The services relevant for the task of transport protocol selection 183 are those with NAPTR service fields with values "ID+M2X", where ID 184 is the service identifier defined in the previous section and X is a 185 letter that corresponds to a transport protocol supported by the 186 domain. This specification defines M2U for UDP, M2T for TCP and M2S 187 for SCTP. This document also establishes an IANA registry for 188 NAPTR service name to transport protocol mappings. 190 These NAPTR [RFC3403] records provide a mapping from a domain to the 191 SRV [RFC2782] record for contacting a server with the specific 192 transport protocol in the NAPTR services field. The resource record 193 will contain an empty regular expression and a replacement value, 194 which indicates the domain name where the SRV record for that 195 particular transport protocol can be found. If the server supports 196 multiple transport protocols, there will be multiple NAPTR records, 197 each with a different service value. As per [RFC3403], the client 198 discards any records whose services fields are not applicable. 200 The MN MUST discard any service fields that identify a resolution 201 service whose value is not "M2X", for values of X that indicate 202 transport protocols supported by the client. The NAPTR processing 203 as described in RFC 3403 will result in the discovery of the most 204 preferred transport protocol of the server that is supported by the 205 client, as well as an SRV record for the server. 207 As an example, consider a client that wishes to find IS service in 208 the example.com domain. The client performs a NAPTR query for that 209 domain, and the following NAPTR records are returned: 211 order pref flags service regexp replacement 212 IN NAPTR 50 50 "s" "IS+M2T" "" _IS._tcp.example.com 213 IN NAPTR 90 50 "s" "IS+M2U" "" _IS._udp.example.com 215 This indicates that the domain does have a server providing IS 216 services over TCP and UDP, in that order of preference. Since the 218 Locating Mobility Servers using DNS October 2008 220 client supports TCP and UDP, TCP will be used, targeted to a host 221 determined by an SRV lookup of _IS._tcp.example.com. That lookup 222 would return: 224 ;; Priority Weight Port Target 225 IN SRV 0 1 XXXX server1.example.com 226 IN SRV 0 2 XXXX server2.example.com 228 If no NAPTR records are found, the client constructs SRV queries for 229 those transport protocols it supports, and does a query for each. 230 Queries are done using the service identifier "_IS" for the 231 Information Service, "_ES" for the Event Service and "_CS" for 232 Command Service. A particular transport is supported if the query is 233 successful. The client MAY use any transport protocol it desires 234 which is supported by the server. 236 Note, that the regexp field in the NAPTR example above is empty. 237 This document discourages the use of this field as its usage can be 238 complex and error prone; and the discovery of the MIH services do 239 not require the flexibility provided by this field over a static 240 target present in the TARGET field. 242 As another example, consider a client which wishes to find ES 243 service over a secure connection. The client performs a NAPTR query 244 for that domain, and the following NAPTR records are returned: 246 order pref flags service regexp replacement 247 IN NAPTR 50 50 "s" "ESs+M2T" "" _ESs._tcp.example.com 248 IN NAPTR 90 50 "s" "ESs+M2U" "" _ESs._udp.example.com 250 This indicates that the domain does have a server providing ES 251 services over a secure connection, in the above case TLSoverTCP and 252 DTLSoverUDP. 254 When a transport protocol is specified explicitly, the client will 255 perform an SRV query for that specific transport using the service 256 identifier of the Mobility Service. 258 2.3 Determining the IP address and port 260 Once the server providing the desired service and the transport 261 protocol has been determined, the next step is to determine the IP 262 address and port. 264 If TARGET is a numeric IP address, the MN uses that IP address and 265 the already chosen transport to contact the server providing the 266 desired service. 268 If the TARGET was not a numeric IP address, then the MN performs an 269 A and/or AAAA record lookup of the domain name, as appropriate. The 271 Locating Mobility Servers using DNS October 2008 273 result will be a list of IP addresses, each of which can be 274 contacted using the transport protocol determined previously. 276 If the result of the SRV query contains a port number, then the MN 277 SHOULD contact the server at that port number. If the SRV record did 278 not contain a port number then the MN SHOULD contact the server at 279 the default port number of that particular service. A default port 280 number for MIH services is requested from IANA in [ID.ietf-mipshop- 281 mstp-solution]. 283 3. IANA considerations 285 The usage of NAPTR records described here requires well known values 286 for the service fields for each transport supported by Mobility 287 Services. The table of mappings from service field values to 288 transport protocols is to be maintained by IANA. 290 The registration in the RFC MUST include the following information: 292 Service Field: The service field being registered. 294 Protocol: The specific transport protocol associated with that 295 service field. This MUST include the name and acronym for the 296 protocol, along with reference to a document that describes the 297 transport protocol. 299 Name and Contact Information: The name, address, email address 300 and telephone number for the person performing the 301 registration. 303 The following values have been placed into the registry: 305 Service Fields Protocol 306 IS+M2T TCP 307 ISs+M2T TLSoverTCP (RFC 5246) 308 IS+M2U UDP 309 ISs+M2U DTLSoverUDP (RFC 4347) 310 IS+M2S SCTP 311 ISs+M2S TSLoverSCTP (RFC 3436) 312 ES+M2T TCP 313 ESs+M2T TLSoverTCP (RFC 5246) 314 ES+M2U UDP 315 ESs+M2U DTLSoverUDP (RFC 4347) 316 ES+M2S SCTP 317 ESs+M2S TLSoverSCTP (RFC 3436) 318 CS+M2T TCP 319 CSs+M2T TLSoverTCP (RFC 5246) 320 CS+M2U UDP 321 CSs+M2U DTLSoverUDP (RFC 4347) 322 CS+M2S SCTP 323 CSs+M2S TLSoverSCTP (RFC 3436) 325 Locating Mobility Servers using DNS October 2008 327 New Service Fields are to be added via Standards Action as defined 328 in [RFC5226]. 329 New entries to the table that specify additional transport protocols 330 for the existing Service Fields may be registered by IANA on a First 331 Come First Served' basis [RFC5226]. 333 4. Security considerations 335 A list of known threats to services using DNS is documented in 336 [RFC3833]. For most of those identified threats, the DNS Security 337 Extensions [RFC4033] does provide protection. It is therefore 338 recommended to consider the usage of DNSSEC [RFC4033] and the 339 aspects of DNSSEC Operational Practices [RFC4641] when deploying 340 IEEE 802.21 Mobility Services. 342 In deployments where DNSSEC usage is not feasible, measures should 343 be taken to protect against forged DNS responses and cache poisoning 344 as much as possible. Efforts in this direction are documented in 345 [ID.ietf-dnsext-forgery-resilience]. 347 5. Normative References 349 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 350 specifying the location of services (DNS SRV)", RFC 2782, 351 February 2000. 353 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 354 Part Three: The Domain Name System (DNS) Database", RFC 3403, 355 October 2002. 357 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 358 Rose, "DNS Security Introduction and Requirements", RFC 4033, 359 March 2005. 361 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 362 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 363 2008. 365 6. Informative References 367 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 368 Networks: Media Independent Handover Services 370 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 371 RFC 4641, September 2006. 373 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 374 Name System (DNS)", RFC 3833, August 2004. 376 Locating Mobility Servers using DNS October 2008 378 [ID.ietf-mipshop-mstp-solution] Mobility Services Transport Protocol 379 Design, Melia et al, April 2008, work in progress 381 [ID.ietf-dnsext-forgery-resilience] Measures for making DNS more 382 resilient against forged answers, Hubert et al, August 2008, 383 work in progress 385 7. Author's Addresses 387 Gabor Bajko 388 gabor(dot)bajko(at)nokia(dot)com 390 Locating Mobility Servers using DNS October 2008 392 Full Copyright Statement 394 Copyright (C) The IETF Trust (2008). 396 This document is subject to the rights, licenses and restrictions 397 contained in BCP 78, and except as set forth therein, the authors 398 retain all their rights. 400 This document and the information contained herein are provided on 401 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 402 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 403 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 404 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 405 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 406 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 407 FOR A PARTICULAR PURPOSE. 409 Intellectual Property 411 The IETF takes no position regarding the validity or scope of any 412 Intellectual Property Rights or other rights that might be claimed 413 to pertain to the implementation or use of the technology described 414 in this document or the extent to which any license under such 415 rights might or might not be available; nor does it represent that 416 it has made any independent effort to identify any such rights. 417 Information on the procedures with respect to rights in RFC 418 documents can be found in BCP 78 and BCP 79. 420 Copies of IPR disclosures made to the IETF Secretariat and any 421 assurances of licenses to be made available, or the result of an 422 attempt made to obtain a general license or permission for the use 423 of such proprietary rights by implementers or users of this 424 specification can be obtained from the IETF on-line IPR repository 425 at http://www.ietf.org/ipr. 427 The IETF invites any interested party to bring to its attention any 428 copyrights, patents or patent applications, or other proprietary 429 rights that may cover technology that may be required to implement 430 this standard. Please address the information to the IETF at ietf- 431 ipr@ietf.org. 433 Acknowledgment 435 Funding for the RFC Editor function is provided by the IETF 436 Administrative Support Activity (IASA).