idnits 2.17.1 draft-bajko-mos-dns-discovery-01.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 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 389. 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 ([1]), 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 199 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 (November 18, 2007) is 5996 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 2434 (ref. '4') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP WG Gabor Bajko 3 Internet Draft Nokia 4 Intended Status: Standards Track November 18, 2007 5 Expires: May 18, 2008 7 Locating Mobility Servers 8 draft-bajko-mos-dns-discovery-01 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 February 20, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document defines application service tags that allow service 42 location without relying on rigid domain naming conventions, and DNS 43 procedures for discovering servers which provide Mobility Services. 44 Mobility Services are used to assist an MN in handover preparation 45 (network discovery) and handover decision (network selection). The 46 services addressed by this document are the Media Independent 47 Handover Services defined in [1]. 49 Conventions used in this document 50 Locating Mobility Services Servers August 2008 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 54 this document are to be interpreted as described in RFC-2119 [1]. 56 Terminology and abbreviations used in this document 58 Mobility Services: comprises of a set of different services provided 59 by the network to mobile nodes to facilitate handover preparation 60 and handover decision. 62 Mobility Server: a network node providing Mobility Services. 64 MIH: Media Independent Handover, as defined in [1]. 66 MIH Service: IS, ES or CS type of service, as defined in [1]. 68 Application service: is a generic term for some type of 69 application, independent of the protocol that may be used to offer 70 it. Each application service will be associated with an IANA- 71 registered tag. 73 Application protocol: is used to implement the application service. 74 These are also associated with IANA-registered tags. 76 Table of Content 78 1. Introduction 2 79 2. Discovering a Mobility Server 3 80 2.1 Selecting a Mobility Service 3 81 2.2 Selecting the transport protocol 4 82 2.3 Determining the IP address and port 5 83 3. IANA Considerations 6 84 4. Security Considerations 6 85 5. Normative References 6 86 6. Informative References 7 87 7. Author's Address 7 89 1. Introduction 91 IEEE 802.21 [1] defines three distinct service types to facilitate 92 link layer handovers across heterogeneous technologies: 94 a) Information Services (IS) 95 IS provides a unified framework to the higher layer entities 96 across the heterogeneous network environment to facilitate discovery 97 and selection of multiple types of networks existing within a 98 geographical area, with the objective to help the higher layer 99 mobility protocols to acquire a global view of the heterogeneous 100 networks and perform seamless handover across these networks. 102 b) Event Services (ES) 104 Locating Mobility Services Servers August 2008 106 Events may indicate changes in state and transmission behavior 107 of the physical, data link and logical link layers, or predict state 108 changes of these layers. The Event Service may also be used to 109 indicate management actions or command status on the part of the 110 network or some management entity. 112 c) Command Services (CS) 113 The command service enables higher layers to control the 114 physical, data link, and logical link layers. The higher layers may 115 control the reconfiguration or selection of an appropriate link 116 through a set of handover commands. 118 In IEEE terminology these services are called Media Independent 119 Handover (MIH) services. 120 While these services may be co-located, the different pattern and 121 type of information they provide does not necessitate the co- 122 location. 124 An MN may make use of any of these MIH service types separately or 125 any combination of them. 127 It is anticipated that a Mobility Server will not necessarily host 128 all three of these MIH Services together, thus there is a need to 129 discover the MIH Service types separately. 131 This document defines a number of application service tags that 132 allow service location without relying on rigid domain naming 133 conventions. 135 2. Discovering a Mobility Server 137 The procedures defined here assume that the MN knows the domain name 138 of the network where it wants to locate a Mobility Server. The 139 domain name of the network can either be pre-configured, discovered 140 using DHCP or learned from a previous Information Service (IS) query 141 [1] as described in [ID.melia-mipshop-mstp-solution]. 142 The procedures defined here result in an IP address, port and 143 transport protocol where the MN can contact the Mobility Server 144 which hosts the service the MN is looking for. 146 2.1 Selecting a Mobility Service 148 The MN should know the characteristics of the Mobility Services 149 defined in [1] and based on that it should be able to select the 150 service it wants to use to facilitate its handover. The services it 151 can choose from are: 152 - Information Service (IS) 153 - Event Service (ES) 154 - Command Service (CS) 156 The service identifiers for the services are "IS", "ES" and "CS" 157 respectively. 159 Locating Mobility Services Servers August 2008 161 The server supporting any of the above services MUST support UDP and 162 TCP as transport. 164 2.2 Selecting the transport protocol 166 After the desired service has been chosen, the client selects the 167 transport protocol it prefers to use. Note, that transport selection 168 may impact the handover performance. 170 The services relevant for the task of transport protocol selection 171 are those with NAPTR service fields with values "IS+M2X" for IS 172 service, "ES+M2X" for the ES service, "CS+M2X" for the CS service, 173 where X is a letter that corresponds to a transport protocol 174 supported by the domain. This specification defines M2U for UDP, M2T 175 for TCP and M2S for SCTP. We also establish an IANA registry for 176 NAPTR service name to transport protocol mappings. 178 These NAPTR [3] records provide a mapping from a domain to the SRV 179 [2] record for contacting a server with the specific transport 180 protocol in the NAPTR services field. The resource record will 181 contain an empty regular expression and a replacement value, which 182 is the SRV record for that particular transport protocol. If the 183 server supports multiple transport protocols, there will be multiple 184 NAPTR records, each with a different service value. As per RFC 2915 185 [3], the client discards any records whose services fields are not 186 applicable. 188 The MN MUST discard any service fields that identify a resolution 189 service whose value is not "M2X", for values of X that indicate 190 transport protocols supported by the client. The NAPTR processing 191 as described in RFC 2915 will result in the discovery of the most 192 preferred transport protocol of the server that is supported by the 193 client, as well as an SRV record for the server. 195 As an example, consider a client that wishes to find IS service in 196 the example.com domain. The client performs a NAPTR query for that 197 domain, and the following NAPTR records are returned: 199 order pref flags service regexp replacement 200 IN NAPTR 50 50 "s" "IS+M2T" "" _IS._tcp.example.com 201 IN NAPTR 90 50 "s" "IS+M2U" "" _IS._ucp.example.com 203 This indicates that the domain does have a server providing IS 204 services over TCP and UDP, in that order of preference. Since the 205 client supports TCP and UDP, TCP will be used, targeted to a host 206 determined by an SRV lookup of _IS._tcp.example.com. That lookup 207 would return: 209 ;; Priority Weight Port Target 210 IN SRV 0 1 XXXX server1.example.com 211 IN SRV 0 2 XXXX server2.example.com 213 Locating Mobility Services Servers August 2008 215 It is not necessary for the domain suffixes in the NAPTR replacement 216 field to match the domain of the original query (i.e., example.com 217 above). However, a domain MUST maintain SRV records for the domain 218 of the original query, even if the NAPTR record is in a different 219 domain, as the access network the MN is attached to might implement 220 policies which restrict access to certain domains. As an example, 221 even though the SRV record for TCP is _IS._tcp.school.edu, there 222 MUST also be an SRV record at _IS._tcp.example.com. 224 If no NAPTR records are found, the client constructs SRV queries for 225 those transport protocols it supports, and does a query for each. 226 Queries are done using the service identifier "_IS" for the 227 Information Service, "_ES" for the Event Service and "_CS" for 228 Command Service. A particular transport is supported if the query is 229 successful. The client MAY use any transport protocol it desires 230 which is supported by the server. 232 Note, that the regexp field in the NAPTR example above is empty. 233 This document discourages the use of this field as its usage can be 234 complex and error prone; and the discovery of the MIH services do 235 not require the flexibility provided by this field over a static 236 target present in the TARGET field. 238 If no SRV records are found, the client SHOULD use TCP to contact a 239 server which hosts an IS service and UDP to contact a server which 240 hosts an ES and/or CS service. 242 If the MN knows the IP address of the server, it may contact the 243 server using the default port number for that service. 245 2.3 Determining the IP address and port 247 Once the server providing the desired service and the transport 248 protocol has been determined, the next step is to determine the IP 249 address and port. 251 If TARGET is a numeric IP address, the MN uses that IP address and 252 the already chosen transport to contact the server providing the 253 desired service. 255 If the TARGET was not a numeric IP address, then the MN performs an 256 A or AAAA record lookup of the domain name. The result will be a 257 list of IP addresses, each of which can be contacted using the 258 transport protocol determined previously. 260 If the result of the SRV query contains a port number, then the MN 261 SHOULD contact the server at that port number. If the SRV record did 262 not contain a port number then the MN SHOULD contact the server at 263 the default port number of that particular service. 265 Locating Mobility Services Servers August 2008 267 3. IANA considerations 269 The usage of NAPTR records described here requires well known values 270 for the service fields for each transport supported by Mobility 271 Services. The table of mappings from service field values to 272 transport protocols is to be maintained by IANA. New entries in the 273 table MAY be added through the publication of standards track RFCs, 274 as described in RFC 2434 [4]. 276 The registration in the RFC MUST include the following information: 278 Service Field: The service field being registered. 280 Protocol: The specific transport protocol associated with that 281 service field. This MUST include the name and acronym for the 282 protocol, along with reference to a document that describes the 283 transport protocol. 285 Name and Contact Information: The name, address, email address 286 and telephone number for the person performing the 287 registration. 289 The following values have been placed into the registry: 291 Service Fields Protocol 292 IS+M2T TCP 293 IS+M2U UDP 294 IS+M2S SCTP 295 ES+M2T TCP 296 ES+M2U UDP 297 ES+M2S SCTP 298 CS+M2T TCP 299 CS+M2U UDP 300 CS+M2S SCTP 302 Name and contact information of the person performing the 303 registration: 304 Gabor Bajko, email: gabor.bajko@nokia.com 306 4. Security considerations 308 Fake DNS requests and responses may cause DoS. Where networks are 309 exposed to such DoS, it is recommended that DNS service providers 310 use the Domain Name System Security Extensions (DNSSEC) as described 311 in [RFC4033]. 312 Readers may also refer to [RFC4641] to consider the aspects of 313 DNSSEC Operational Practices. 315 5. Normative References 316 Locating Mobility Services Servers August 2008 318 [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 319 Specifying the Location of Services (DNS SRV)", RFC 2782, 320 February 2000. 322 [3] Mealling, M., "DDDS, The Domain Name System (DNS) Database", RFC 323 3403, October 2002. 325 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 326 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 328 [RFC4033] DNS Security Introduction and Requirements, Arends et al, 329 March 2005 331 6. Informative References 333 [1] IEEE 802.21 Standard for Local and Metropolitan Area Networks: 334 Media Independent Handover Services 336 [ID.melia-mipshop-mstp-solution] Mobility Services Transport 337 Protocol Design, Melia et al, November 2007, work in progress 339 [RFC4641] DNSSEC Operational Practices, Kolkman et al, September 340 2006 342 7. Author's Address 344 Gabor Bajko 345 Nokia 346 gabor.bajko@nokia.com 348 Locating Mobility Services Servers August 2008 350 Full Copyright Statement 352 Copyright (C) The IETF Trust (2007). 354 This document is subject to the rights, licenses and restrictions 355 contained in BCP 78, and except as set forth therein, the authors 356 retain all their rights. 358 This document and the information contained herein are provided on 359 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 360 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 361 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 362 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 363 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 364 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 365 FOR A PARTICULAR PURPOSE. 367 Intellectual Property 369 The IETF takes no position regarding the validity or scope of any 370 Intellectual Property Rights or other rights that might be claimed 371 to pertain to the implementation or use of the technology described 372 in this document or the extent to which any license under such 373 rights might or might not be available; nor does it represent that 374 it has made any independent effort to identify any such rights. 375 Information on the procedures with respect to rights in RFC 376 documents can be found in BCP 78 and BCP 79. 378 Copies of IPR disclosures made to the IETF Secretariat and any 379 assurances of licenses to be made available, or the result of an 380 attempt made to obtain a general license or permission for the use 381 of such proprietary rights by implementers or users of this 382 specification can be obtained from the IETF on-line IPR repository 383 at http://www.ietf.org/ipr. 385 The IETF invites any interested party to bring to its attention any 386 copyrights, patents or patent applications, or other proprietary 387 rights that may cover technology that may be required to implement 388 this standard. Please address the information to the IETF at ietf- 389 ipr@ietf.org. 391 Acknowledgment 393 Funding for the RFC Editor function is provided by the IETF 394 Administrative Support Activity (IASA).