idnits 2.17.00 (12 Aug 2021) /tmp/idnits32772/draft-tschofenig-dhc-lost-discovery-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 430. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 22, 2006) is 5744 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) == Outdated reference: draft-ietf-ecrit-lost has been published as RFC 5222 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-ecrit-requirements has been published as RFC 5012 == Outdated reference: draft-ietf-ecrit-security-threats has been published as RFC 5069 == Outdated reference: draft-ietf-ecrit-service-urn has been published as RFC 5031 == Outdated reference: draft-ietf-geopriv-dhcp-civil has been published as RFC 4676 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-03 -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Siemens 4 Intended status: Standards Track August 22, 2006 5 Expires: February 23, 2007 7 A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service 8 Translation Protocol (LoST) Discovery Procedure 9 draft-tschofenig-dhc-lost-discovery-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 23, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The Location-to-Service Translation Protocol (LoST) describes an XML- 43 based protocol for mapping service identifiers and geospatial or 44 civic location information to service contact Uniform Resource 45 Locators (URIs). LoST servers can be located anywhere but a 46 placement closer to the end host, i.e., in the access network, is 47 desireable. Such a LoST server placement provides benefits in 48 disaster situations with intermittent network connectivity regarding 49 the resiliency of emergency service communication. 51 This document describes such a LoST discovery procedure based on 52 DHCP. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Location-to-Service Translation Protocol (LoST) DHCPv4 59 Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Location-to-Service Translation Protocol (LoST) DHCPv6 61 Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . . . 15 71 1. Introduction 73 The Location-to-Service Translation Protocol (LoST) describes an XML- 74 based protocol for mapping service identifiers and geospatial or 75 civic location information to service contact Uniform Resource 76 Locators (URIs). The typical procedure for running LoST at an end 77 host can be described via the following example. Note that the 78 details of the LoST protocol mechanisms are not relevant for this 79 protocol. The example aims to motive the scenario behind this 80 document. More information about LoST can be found at 81 [I-D.ietf-ecrit-lost]. 83 After performing link layer attachment an end host performs stateful 84 address autoconfiguration using DHCP. Then, DHCP provides the end 85 host with civic location (as described in 86 [I-D.ietf-geopriv-dhcp-civil]) or with geospatial location 87 information (as described in [RFC3825]). The following example below 88 shows civic location information returned to the end host via DHCP. 89 Note that other protocols may be used to provide the end host with 90 location information. Furthermore, manual configuration or GPS might 91 be used. 93 The following example shown in Figure 1 indicates a location in the 94 US, state=New York, city=New York, group of streets=Broadway, 95 additional location information=Suite 75, and zip code=10027-0401. 97 +--------+---------------+ 98 | CAtype | CAvalue | 99 +--------+---------------+ 100 | 0 | US | 101 | 1 | New York | 102 | 3 | New York | 103 | 6 | Broadway | 104 | 22 | Suite 75 | 105 | 24 | 10027-0401 | 106 +--------+---------------+ 108 Figure 1: DHCP Civic Information Example 110 Additionally, DHCP may provide information about the LoST server that 111 can be contacted. This document describes such an extension to allow 112 the DHCP server to also provide the IP address of the LoST server. 114 The end host can trigger the LoST protocol at any time: at 115 attachment time, at call time or some time in between. When the end 116 host initiates a LoST request, it includes its civic location and the 117 desired service URN in the message. Examples of service URNs can be 118 found in [I-D.ietf-ecrit-service-urn]. The request in Figure 2 shows 119 the location information received with DHCP (as shown in Figure 1) 120 together with a request for an emergency service, namely 121 'urn:service:sos.police'. 123 124 129 130 US 131 New York 132 New York 133 Broadway 134 Suite 75 135 10027-0401 136 137 urn:service:sos.police 138 140 Figure 2: Mapping Request 142 In our example we assume that the LoST server has the requested 143 information available and returns a successful response. The 144 response indicates, as a human readable display string that the 'New 145 York City Police Department' is responsible for the given 146 geographical area. The indicated URI allows the user to start 147 communication using SIP or XMPP. The 'validated' element indicates 148 which parts of the civic address were matched successfully against a 149 database and represent a known address. Other parts of the address, 150 in this example, the suite number, were ignored and not validated. 151 The returned service boundary indicates that all of New York City 152 would result in the same response. The service-number element 153 indicates that the service can be reached via the dial string 9-1-1. 155 156 161 New York City Police Department 162 163 164 US 165 New York 166 New York 167 168 169 sip:nypd@example.com 170 xmpp:nypd@example.com 171 911 172 174 Figure 3: Mapping Response 176 The received URIs then serve, for example, as input to SIP as 177 described in [I-D.rosen-ecrit-framework] whereby the SIP message 178 might carry location information as shown in 179 [I-D.ietf-sip-location-conveyance]. 181 This document describes only a LoST discovery procedure based on 182 information returned by the DHCP server. Other documents listed in 183 the example above provide further building blocks in order to obtain 184 location information via DHCP (see [I-D.ietf-geopriv-dhcp-civil] and 185 [RFC3825]), to map location and a service identifier to a service URI 186 (using LoST [I-D.ietf-ecrit-lost]), and a mechanism to convey the 187 received information in SIP using [I-D.ietf-sip-location-conveyance]. 189 2. Terminology 191 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 192 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 193 and "OPTIONAL" are to be interpreted as described in RFC 2119 194 [RFC2119]. 196 Within this document we use terminology from 197 [I-D.ietf-ecrit-requirements]. 199 3. Location-to-Service Translation Protocol (LoST) DHCPv4 Option 201 This section defines a LoST option that carries a list of 32-bit 202 (binary) IPv4 addresses indicating one or more Location-to-Service 203 Translation Protocol (LoST) servers available to the end host. 205 The DHCPv4 option for the LoST server has the format shown in 206 Figure 4. 208 0 1 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | option-code | option-length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 + LoST IPv4 Address + 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | ... | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 4: Location-to-Service Translation Protocol (LoST) DHCPv4 221 Option 223 option-code: OPTION_LOST (TBD) 225 option-length: Length of the 'options' field in octets; 226 MUST be a multiple of four (4) 228 LOST IPv4 Address: IPv4 address of a LoST server for the client to use. 229 The LoST servers are listed in the order of preference 230 for use by the client. 232 A DHCPv4 client requests the LOST DHCPv4 Option in a Parameter 233 Request List as described in [RFC2131] and [RFC2132]. 235 The DHCPv4 client MUST try the records in the order listed in the 236 LOST DHCPv4 option. 238 4. Location-to-Service Translation Protocol (LoST) DHCPv6 Option 240 This section defines a DHCPv6 option that carries a list of 128-bit 241 (binary) IPv6 addresses indicating one or more Location-to-Service 242 Translation Protocol (LoST) servers available to the end host. 244 The DHCPv6 option for Location-to-Service Translation Protocol (LoST) 245 server has the format shown in Figure 6. 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | option-code | option-length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 + + 254 | | 255 + LoST IPv6 Address + 256 | | 257 + + 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | .... | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 6: Location-to-Service Translation Protocol (LoST) DHCPv6 264 Option 266 option-code: OPTION_LOST (TBD) 268 option-length: Length of the 'options' field in octets; 269 MUST be a multiple of sixteen (16) 271 LOST IPv6 Address: IPv6 address of a LoST server for the client to use. 272 The LoST servers are listed in the order of preference 273 for use by the client. 275 A DHCPv6 client requests the LOST DHCPv6 option in an Options Request 276 Option (ORO) as described in the DHCPv6 specification [RFC3315]. 278 The DHCPv6 client MUST try the records in the order listed in the 279 LOST DHCPv6 option. 281 5. IANA Considerations 283 The following DHCPv4 option code for the Location-to-Service 284 Translation Protocol (LoST) server option must be assigned by IANA: 286 Option Name Value Described in 287 ----------------------------------------------- 288 OPTION_LOST TBD Section 5 290 The following DHCPv6 option codes for the Location-to-Service 291 Translation Protocol (LoST) options must be assigned by IANA: 293 Option Name Value Described in 294 ------------------------------------------------ 295 OPTION_LOST TBD Section 6 297 6. Security Considerations 299 If an adversary manages to modify the response from a DHCP server or 300 insert its own response, a LoST client could be led to contact a 301 rogue LoST server. As a consequence the address of a non-existent 302 LoST server could be returned to the end host. Alternatively, the 303 adversary returns an IP address of a LoST server under the control of 304 the adversary. These threats are documented in 305 [I-D.ietf-ecrit-security-threats]. The security considerations in 306 [RFC2131], [RFC2132] and [RFC3315] are applicable to this document. 308 7. Acknowledgements 310 The author of this document used draft-ietf-dhc-paa-option as a 311 template. Hence, acknowledgements go to the draft authors of 312 draft-ietf-dhc-paa-option. 314 The author would like to thank Christian Dickmann and Mayutan 315 Arumaithurai for their draft review. 317 8. References 319 8.1. Normative References 321 [I-D.ietf-ecrit-lost] 322 Hardie, T., "LoST: A Location-to-Service Translation 323 Protocol", draft-ietf-ecrit-lost-00 (work in progress), 324 June 2006. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", RFC 2119, BCP 14, March 1997. 329 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 330 RFC 2131, March 1997. 332 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 333 Extensions", RFC 2132, March 1997. 335 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 336 and M. Carney, "Dynamic Host Configuration Protocol for 337 IPv6 (DHCPv6)", RFC 3315, July 2003. 339 8.2. Informative References 341 [I-D.ietf-ecrit-requirements] 342 Schulzrinne, H. and R. Marshall, "Requirements for 343 Emergency Context Resolution with Internet Technologies", 344 draft-ietf-ecrit-requirements-11 (work in progress), 345 August 2006. 347 [I-D.ietf-ecrit-security-threats] 348 Taylor, T., "Security Threats and Requirements for 349 Emergency Call Marking and Mapping", 350 draft-ietf-ecrit-security-threats-03 (work in progress), 351 July 2006. 353 [I-D.ietf-ecrit-service-urn] 354 Schulzrinne, H., "A Uniform Resource Name (URN) for 355 Services", draft-ietf-ecrit-service-urn-04 (work in 356 progress), August 2006. 358 [I-D.ietf-geopriv-dhcp-civil] 359 Schulzrinne, H., "Dynamic Host Configuration Protocol 360 (DHCPv4 and DHCPv6) Option for Civic Addresses 361 Configuration Information", 362 draft-ietf-geopriv-dhcp-civil-09 (work in progress), 363 January 2006. 365 [I-D.ietf-sip-location-conveyance] 366 Polk, J. and B. Rosen, "Session Initiation Protocol 367 Location Conveyance", 368 draft-ietf-sip-location-conveyance-03 (work in progress), 369 June 2006. 371 [I-D.rosen-ecrit-framework] 372 Rosen, B., "Framework for Emergency Calling in Internet 373 Multimedia", draft-rosen-ecrit-framework-00 (work in 374 progress), June 2006. 376 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 377 Configuration Protocol Option for Coordinate-based 378 Location Configuration Information", RFC 3825, July 2004. 380 Author's Address 382 Hannes Tschofenig 383 Siemens 384 Otto-Hahn-Ring 6 385 Munich, Bavaria 81739 386 Germany 388 Phone: +49 89 636 40390 389 Email: Hannes.Tschofenig@siemens.com 390 URI: http://www.tschofenig.com 392 Full Copyright Statement 394 Copyright (C) The Internet Society (2006). 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 an 401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 403 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 404 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 405 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 408 Intellectual Property 410 The IETF takes no position regarding the validity or scope of any 411 Intellectual Property Rights or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; nor does it represent that it has 415 made any independent effort to identify any such rights. Information 416 on the procedures with respect to rights in RFC documents can be 417 found in BCP 78 and BCP 79. 419 Copies of IPR disclosures made to the IETF Secretariat and any 420 assurances of licenses to be made available, or the result of an 421 attempt made to obtain a general license or permission for the use of 422 such proprietary rights by implementers or users of this 423 specification can be obtained from the IETF on-line IPR repository at 424 http://www.ietf.org/ipr. 426 The IETF invites any interested party to bring to its attention any 427 copyrights, patents or patent applications, or other proprietary 428 rights that may cover technology that may be required to implement 429 this standard. Please address the information to the IETF at 430 ietf-ipr@ietf.org. 432 Acknowledgment 434 Funding for the RFC Editor function is provided by the IETF 435 Administrative Support Activity (IASA).