idnits 2.17.1
draft-winterbottom-geopriv-held-identity-extensions-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 15.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 562.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 573.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 580.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 586.
** 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:
----------------------------------------------------------------------------
** Too long document name: The document name (without revision number),
'draft-winterbottom-geopriv-held-identity-extensions', is 51 characters
long, but may be at most 50 characters
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- 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 (Oct 2006) is 6403 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)
== Missing Reference: '0-5' is mentioned on line 308, but not defined
== Missing Reference: '0-4' is mentioned on line 308, but not defined
== Missing Reference: '0-9' is mentioned on line 308, but not defined
== Missing Reference: '0-1' is mentioned on line 308, but not defined
== Outdated reference: A later version (-05) exists of
draft-winterbottom-http-location-delivery-03
Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Geopriv J. Winterbottom
3 Internet-Draft M. Thomson
4 Intended status: Standards Track Andrew Corporation
5 Expires: April 4, 2007 Oct 2006
7 HELD End-Point identity Extensions
8 draft-winterbottom-geopriv-held-identity-extensions-00.txt
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 months
23 and may be updated, replaced, or obsoleted by other documents at any
24 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 4, 2007.
35 Copyright Notice
37 Copyright (C) The Internet Society (2006).
39 Abstract
41 This document describes a schema for extending HELD Target
42 identification beyond source IP Address. It describes real-world
43 situations where such a mechanism can be deployed, and provides
44 examples of HELD message syntax including identity extensions.
46 Table of Contents
48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
50 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
51 4. Example Network Deployments . . . . . . . . . . . . . . . . . 6
52 4.1. Digital Subscriber Line Networks . . . . . . . . . . . . . 6
53 4.2. LLDP Enabled Network . . . . . . . . . . . . . . . . . . . 7
54 5. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 8
55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
57 7.1. URN Sub-Namespace Registration for
58 urn:ietf:params:xml:ns:geopriv:held:deviceIdentifiers . . 14
59 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14
60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
62 9.1. Normative references . . . . . . . . . . . . . . . . . . . 17
63 9.2. Informative references . . . . . . . . . . . . . . . . . . 17
64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
65 Intellectual Property and Copyright Statements . . . . . . . . . . 19
67 1. Introduction
69 The HELD protocol [I-D.winterbottom-http-location-delivery] defines
70 the way in in which location information is acquired from a Location
71 Information Server (LIS). HELD uses the IP address of the location
72 request message as the primary source of identifier for the
73 requesting device, there are however circumstances and network
74 configurations where an IP address alone is insufficient to identify
75 a Target in a network. This specification defines an identity
76 extensions schema that can be used by requesting devices to assist
77 the LIS in determining their physical location.
79 2. Terminology
81 The key conventions and terminology used in this document are defined
82 as follows:
84 This document reuses the terms Target, as defined in [RFC3693].
86 This document uses the term Location Information Server, LIS, to
87 represent a combined Location Server and Location Generator (as
88 defined in [RFC3693]) residing inside the local access domain.
90 Broadband Regional Aggregation Server (BRAS). A node in a DSL
91 network responsible for switching data streams between end-points and
92 Internet Service Providers.
94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
96 document are to be interpreted as described in [RFC2119].
98 3. Overview
100 A basic premise in HELD is that the source IP address of the location
101 request message can be used by the LIS to identify the requesting
102 Target, and that this identity can be used with other contextual
103 network information to provide a physical location for the Target.
104 In many network deployments this premise holds true, but in some
105 network deployments additional identifiers are required to identify
106 the Target at different points throughout the network, or they may
107 assist with speeding up location determination.
109 The base HELD schema was designed with extensibility in mind and the
110 assumption that IP address may not always be enought to identify a
111 Target. The HELD identity extensions schema is made up of a number
112 of discrete element blocks that can included into the HELD
113 locationRequest, createContext and updateContext messages. These
114 elements can then be used by the LIS to identify the Target closer to
115 the edge of the network, for example a MAC address or DHCP client-
116 identifier, or to identify an element that has a closer relationship
117 with the target, for example LLDP switch and port information. The
118 identity extension elements have been desgined to work across a range
119 of existing and emerging technologies. It is envisaged that while
120 this schema is not exhaustive, it will address many of the perceived
121 deployment solution. It is further envisaged that extensions to this
122 schema will be necessary as new identifiers are created or required.
124 4. Example Network Deployments
126 4.1. Digital Subscriber Line Networks
128 Digital Subscriber Line (DSL) networks represent the fastest growing
129 residentital broadband technology. DSL networks have evolved
130 consideraly since their first deployments, with core aggregation
131 architectures being covered in DSL forum documents [TR025] and
132 [TR101]. DSL depoloyments are frequently constructed through the
133 cooperation of two or more providers. These can be generalized into
134 two basic categories, infrastructure providers and Internet
135 providers. Infrastructure providers own the cables and provide layer
136 2 connectivity from a residence to the Internet provider. The
137 Internet provider assigns an IP address and provides routing and
138 access to broader network services. End users obtain their service
139 from and ISP, that in turn needs to negotiate access from an
140 Infrastructure provider. Request for location from the end user
141 therefore, are made to the Internet Service Provider (ISP) LIS. In
142 many cases the ISP LIS is unable to provide location as it is removed
143 from the physical access network, consequently it needs to request
144 location from the Infrastructure provider LIS. Depending on the
145 network configuration the ISP LIS may need to provide the
146 Infrastructure provider LIS with additional identifier information
147 that it can glean when the end-point connection is established with
148 the ISP Network Access Server (NAS).
150 Determining location in DSL environments is dependent on identifying
151 and following provisioned circuit chains. And circuit chains are
152 identified differently depending the DSL network deployment. Take
153 for example a deployment that uses a proxy-RADIUS service between the
154 BRAS, this mode of operation IP routing is used between the BRAS and
155 the ISP NAS. In this case, the Infrastructure provider LIS may
156 information about incoming port information to the BRAS that it can
157 link back to a DSLAM port, and hence a street address. Since the
158 BRAS must perform IP routing to the ISP NAS, the Infrastructure
159 provider LIS may more easily perform associations between IP address
160 and provisioned circuit chain information.
162 A large number of DSL deployments however use L2TP connections from
163 the BRAS to the ISP NAS. In this case, the Infrastructure provider
164 LIS can only link tunnel and session information to with the
165 provisioned circuit chain. Since the ISP LIS can obtain this same
166 tunnel and session information it can provide this in a HELD request
167 to the Infrastructre provider LIS, and obtain the location of the
168 end-point. A HELD location request using this meachnism may look
169 something similar to the figure below.
171
173
174 pres:user@example.isp.com
175 1800
176 false
177
178 -
180 -
181 192.168.4.10
182 10.1.0.60
183 528
184
185
186
188 4.2. LLDP Enabled Network
190 Link Layer Discovery Protocol (LLDP)[LLDP] is being increasingly
191 deployed in enterprise environments. One of the functions available
192 in these networks is for an LLDP capable switch to report information
193 about itself to attached clients, such as the switch chassis type,
194 switch chassis id, port type and port id. If a Target provides this
195 data in a location request to the LIS, it may significantly improve
196 the location determination process. This is because the LIS may
197 trust the Target implicitly and simply perform a lookup on the data
198 provided, of it can redcue the number of switches that a LIS may need
199 to search in order to verify the Target's point of attachment. A
200 HELD location request using this extension may look similar to that
201 shown in the figure below.
203
205 -
207 -
208 211
209 10.1.0.60
210 10
211 192.168.55.7
212
213
214
216 5. XML Schema Definition
218
219
226
227
228
229
230
231
233
234
235
236
237
238
240
241
242
243
246
247
249
250
251
252
253
254
255
257
258
259
260
261 An IP version 6 address, based on RFC 1884.
262
263
264
265
266
268
269
270
271
273
275
277
279
281
283
284
285
286
297
298
299
300
302
303
304
305
310
311
312
313
314
315
316
317
318
320
321
322
323
325
326
327
328
329
330
332
333
335
336
337
338
339
340
341
342
343
345
346
347
348
349
350
351
352
353
355
356
357
358
359
361
363
364
366
367
368
369
370
371
372
373
374
376
378
379
380
381
382
384
385
386
388
390
391
392
394
396
398
400
402
404
405
406
407
408
409
411
413
415
417
419
421
423
425
427
428
429
431
433
435 6. Security Considerations
437 Operators of a LIS that supports this schema extension need to take
438 to take steps to ensure that location provided to nodes requesting
439 location in this manner are entitled to the location information
440 being requested. In some circumstances support of this schema
441 extension will be inappropriate and alternative measure will need to
442 be employed.
444 7. IANA Considerations
446 According to the guidelines in [RFC3688], this document registers an
447 XML namespace and schema with IANA.
449 7.1. URN Sub-Namespace Registration for
450 urn:ietf:params:xml:ns:geopriv:held:deviceIdentifiers
452 This section registers a new XML namespace,
453 "urn:ietf:params:xml:ns:geopriv:held:deviceIdentfiers", as per the
454 guidelines in [RFC3688].
456 URI: urn:ietf:params:xml:ns:geopriv:held:deviceIdentifiers
458 Registrant Contact: IETF, GEOPRIV working group,
459 (geopriv@ietf.org), James Winterbottom
460 (james.winterbottom@andrew.com).
462 XML:
464 BEGIN
465
466
468
469
470 HELD Device Ddentity Extensions
471
472
473 Namespace for HELD Device Identity Extensions
474 urn:ietf:params:xml:ns:geopriv:held:deviceIdentifiers
475 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
476 with the RFC number for this specification.]]
477 See RFCXXXX.
478
479
480 END
482 7.2. XML Schema Registration
484 This section registers an XML schema as per the guidelines in
485 [RFC3688].
487 URI: urn:ietf:params:xml:schema:geopriv:held:deviceIdentifiers
488 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
489 James Winterbottom (james.winterbottom@andrew.com).
491 Schema: The XML for this schema can be found as the entirety of
492 Section 5 of this document.
494 8. Acknowledgements
496 The authors wish to thank the NENA VoIP location working group for
497 their assistance in the definition of the schema used in this
498 document.
500 9. References
502 9.1. Normative references
504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
505 Requirement Levels", BCP 14, RFC 2119, March 1997.
507 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
508 January 2004.
510 [I-D.winterbottom-http-location-delivery]
511 Winterbottom, J., "HTTP Enabled Location Delivery (HELD)",
512 draft-winterbottom-http-location-delivery-03 (work in
513 progress), May 2006.
515 9.2. Informative references
517 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
518 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
520 [TR025] Wang, R., "Core Network Architecture Recommendations for
521 Access to Legacy Data Networks over ADSL", September 1999.
523 [TR101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSl
524 Aggregation", April 2006.
526 [LLDP] IEEE, "802.1AB, IEEE Standard for Local and Metropolitan
527 area networks, Station and Media Access Control
528 Connectivity Discovery", June 2005.
530 Authors' Addresses
532 James Winterbottom
533 Andrew Corporation
534 PO Box U40
535 University of Wollongong, NSW 2500
536 AU
538 Email: james.winterbottom@andrew.com
540 Martin Thomson
541 Andrew Corporation
542 PO Box U40
543 University of Wollongong, NSW 2500
544 AU
546 Email: martin.thomson@andrew.com
548 Full Copyright Statement
550 Copyright (C) The Internet Society (2006).
552 This document is subject to the rights, licenses and restrictions
553 contained in BCP 78, and except as set forth therein, the authors
554 retain all their rights.
556 This document and the information contained herein are provided on an
557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
559 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
560 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
561 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
564 Intellectual Property
566 The IETF takes no position regarding the validity or scope of any
567 Intellectual Property Rights or other rights that might be claimed to
568 pertain to the implementation or use of the technology described in
569 this document or the extent to which any license under such rights
570 might or might not be available; nor does it represent that it has
571 made any independent effort to identify any such rights. Information
572 on the procedures with respect to rights in RFC documents can be
573 found in BCP 78 and BCP 79.
575 Copies of IPR disclosures made to the IETF Secretariat and any
576 assurances of licenses to be made available, or the result of an
577 attempt made to obtain a general license or permission for the use of
578 such proprietary rights by implementers or users of this
579 specification can be obtained from the IETF on-line IPR repository at
580 http://www.ietf.org/ipr.
582 The IETF invites any interested party to bring to its attention any
583 copyrights, patents or patent applications, or other proprietary
584 rights that may cover technology that may be required to implement
585 this standard. Please address the information to the IETF at
586 ietf-ipr@ietf.org.
588 Acknowledgment
590 Funding for the RFC Editor function is provided by the IETF
591 Administrative Support Activity (IASA).