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).