idnits 2.17.1 draft-ietf-ecrit-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. ** 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 : ---------------------------------------------------------------------------- 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 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 (December 10, 2006) is 6340 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) == Unused Reference: 'RFC3319' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC3361' is defined on line 290, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-02 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-02) exists of draft-daigle-unaptr-01 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-12 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-security-threats-03 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Schulzrinne 3 Internet-Draft Columbia U. 4 Intended status: Standards Track J. Polk 5 Expires: June 13, 2007 Cisco 6 H. Tschofenig 7 Siemens Networks GmbH & Co KG 8 December 10, 2006 10 A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service 11 Translation Protocol (LoST) Discovery Procedure 12 draft-ietf-ecrit-dhc-lost-discovery-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 13, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 The Location-to-Service Translation Protocol (LoST) describes an XML- 46 based protocol for mapping service identifiers and geospatial or 47 civic location information to service contact Uniform Resource 48 Locators (URLs). LoST servers can be located anywhere but a 49 placement closer to the end host, e.g., in the access network, is 50 desireable. Such a LoST server placement provides benefits in 51 disaster situations with intermittent network connectivity regarding 52 the resiliency of emergency service communication. 54 This document describes how a LoST client can discover a LoST server 55 using the Dynamic Host Configuration Protocol (DHCP). 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Domain Name Encoding . . . . . . . . . . . . . . . . . . . . . 3 62 4. LoST Server DHCPv4 Option . . . . . . . . . . . . . . . . . . . 4 63 5. LoST Server DHCPv6 Option . . . . . . . . . . . . . . . . . . . 4 64 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 7.1. IANA Consideration for DHCPv4 Option . . . . . . . . . . . 6 67 7.2. IANA Consideration for DHCPv6 Option . . . . . . . . . . . 6 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 Intellectual Property and Copyright Statements . . . . . . . . . . 9 76 1. Introduction 78 The Location-to-Service Translation Protocol (LoST) 79 [I-D.ietf-ecrit-lost] describes an XML-based protocol for mapping 80 service identifiers and geospatial or civic location information to 81 service contact Uniform Resource Locators (URLs). 83 In order to interact with a LoST server, the LoST client finally 84 needs to know its IP address. Several mechanisms can be used to 85 learn this address, including manual configuration. In environments 86 where the access network itself either deploys a LoST server or knows 87 a third party that operates a LoST server DHCP can provide the end 88 host with a domain name. This domain name is then used as input to 89 the DNS-based resolution mechanism described in LoST 90 [I-D.ietf-ecrit-lost] that reuses the URI-enabled NAPTR specification 91 (see [I-D.daigle-unaptr]). 93 This document specifies a DHCPv4 and a DHCPv6 option that allows LoST 94 clients to discover local LoST servers. 96 Section 2 provides terminology. Section 4 describes the DHCPv4 97 option while Section 5 describes the DHCPv6 option, with the same 98 functionality. IANA and Security Considerations complete the 99 document in Section 7 and Section 8. 101 2. Terminology 103 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 104 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 105 and "OPTIONAL" are to be interpreted as described in RFC 2119 106 [RFC2119]. 108 Within this document, we use terminology from 109 [I-D.ietf-ecrit-requirements] and [I-D.ietf-ecrit-lost]. 111 3. Domain Name Encoding 113 This section describes the encoding of the domain name used in the 114 DHCPv4 option shown in Section 4 and also used in the DHCPv6 option 115 shown in Section 5. 117 The domain name is encoded according to Section 3.1 of RFC 1035 118 [RFC1035] whereby each label is represented as a one octet length 119 field followed by that number of octets. The domain name ends with 120 the null label of the root, a domain name is terminated by a length 121 byte of zero. The high order two bits of every length octet must be 122 zero, and the remaining six bits of the length field limit the label 123 to 63 octets or less. To simplify implementations, the total length 124 of a domain name (i.e., label octets and label length octets) is 125 restricted to 255 octets or less. 127 RFC 1035 [RFC1035] encoding was chosen to accommodate future 128 internationalized domain name mechanisms. 130 For DHCPv4 only: If the length of the domain name exceeds the 131 maximum permissible within a single option (i.e., 254 octets), then 132 the domain name MUST be represented in the DHCP message as specified 133 in [RFC3396]. 135 4. LoST Server DHCPv4 Option 137 The LoST server DHCPv4 option carries a DNS (RFC 1035 [RFC1035]) 138 fully-qualified domain name to be used by the LoST client to locate a 139 LoST server. 141 The DHCP option for this encoding has the following format: 143 Code Len LoST Server Domain Name 144 +-----+-----+-----+-----+-----+-----+-----+---- 145 | TBD | n | s1 | s2 | s3 | s4 | s5 | ... 146 +-----+-----+-----+-----+-----+-----+-----+---- 148 Figure 1: LoST FQDN DHCPv4 Option 150 Code: OPTION_LOST (TBD1) 152 Len: Length of the 'LoST Server Domain Name' field 153 in octets; variable. 155 LoST server Domain Name: The domain name of the LoST 156 server for the client to use. 158 The encoding of the domain name is described in Section 3. 160 Only a single domain name MUST be present in the DHCPv4 option. 162 5. LoST Server DHCPv6 Option 164 This document defines a DHCPv6 options to carry a domain name. 166 The DHCPv6 option has the format shown in Figure 3. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | OPTION_LOST | option-length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | LoST Server Domain Name | 174 | ... | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 3: DHCPv6 Option for LoST Server Domain Name List 179 option-code: OPTION_LOST (TBD2) 181 option-length: Length of the 'LoST Server Domain Name' field 182 in octets; variable. 184 LoST server Domain Name: The domain name of the LoST 185 server for the client to use. 187 A DHCPv6 client may request a LoST server domain name in an Options 188 Request Option (ORO) as described in [RFC3315]. 190 The encoding of the domain name is described in Section 3. 192 Only a single domain name MUST be present in the DHCPv6 option. 194 6. Example 196 This section shows an example of a DHCPv4 option where the DHCP 197 server wants to offer the "example.com" domain name to the client as 198 input to the U-NAPTR LoST discovery procedure. This domain name 199 would be encoded as follows: 201 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 202 |TBD|13 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 203 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 205 Figure 5: Example for a LoST FQDN DHCPv4 Option 207 7. IANA Considerations 208 7.1. IANA Consideration for DHCPv4 Option 210 The following DHCPv4 option code for the Location-to-Service 211 Translation Protocol (LoST) server option must be assigned by IANA: 213 Option Name Value Described in 214 ----------------------------------------------- 215 OPTION_LOST TBD Section 4 217 7.2. IANA Consideration for DHCPv6 Option 219 IANA is requested to assign the following DHCPv6 option codes for the 220 Location-to-Service Translation Protocol (LoST) options: 222 Option Name Value Described in 223 ------------------------------------------------ 224 OPTION_LOST TBD Section 5 226 8. Security Considerations 228 If an adversary manages to modify the response from a DHCP server or 229 insert its own response, a LoST client could be led to contact a 230 rogue LoST server under the control of the adversary or be given an 231 invalid address. These threats are documented in 232 [I-D.ietf-ecrit-security-threats]. The security considerations in 233 [RFC2131], [RFC2132] and [RFC3315] are applicable to this document. 235 9. Acknowledgements 237 The authors would like to thank Andrew Newton and Leslie Daigle for 238 their draft review. We would like to particularly thank Andrew 239 Newton for the simplifications he proposed. 241 10. References 243 10.1. Normative References 245 [I-D.ietf-ecrit-lost] 246 Hardie, T., "LoST: A Location-to-Service Translation 247 Protocol", draft-ietf-ecrit-lost-02 (work in progress), 248 October 2006. 250 [RFC1035] Mockapetris, P., "Domain names - implementation and 251 specification", STD 13, RFC 1035, November 1987. 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", RFC 2119, BCP 14, March 1997. 256 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 257 RFC 2131, March 1997. 259 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 260 Extensions", RFC 2132, March 1997. 262 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 263 and M. Carney, "Dynamic Host Configuration Protocol for 264 IPv6 (DHCPv6)", RFC 3315, July 2003. 266 10.2. Informative References 268 [I-D.daigle-unaptr] 269 Daigle, L., "Domain-based Application Service Location 270 Using URIs and the Dynamic Delegation Discovery Service 271 (DDDS)", draft-daigle-unaptr-01 (work in progress), 272 October 2006. 274 [I-D.ietf-ecrit-requirements] 275 Schulzrinne, H. and R. Marshall, "Requirements for 276 Emergency Context Resolution with Internet Technologies", 277 draft-ietf-ecrit-requirements-12 (work in progress), 278 August 2006. 280 [I-D.ietf-ecrit-security-threats] 281 Taylor, T., "Security Threats and Requirements for 282 Emergency Call Marking and Mapping", 283 draft-ietf-ecrit-security-threats-03 (work in progress), 284 July 2006. 286 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 287 Protocol (DHCPv6) Options for Session Initiation Protocol 288 (SIP) Servers", RFC 3319, July 2003. 290 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 291 (DHCP-for-IPv4) Option for Session Initiation Protocol 292 (SIP) Servers", RFC 3361, August 2002. 294 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 295 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 296 November 2002. 298 Authors' Addresses 300 Henning Schulzrinne 301 Columbia University 302 Department of Computer Science 303 450 Computer Science Building 304 New York, NY 10027 305 US 307 Phone: +1 212 939 7004 308 Email: hgs+ecrit@cs.columbia.edu 309 URI: http://www.cs.columbia.edu 311 James Polk 312 Cisco 313 2200 East President George Bush Turnpike 314 Richardson, Texas 75082 315 US 317 Email: jmpolk@cisco.com 319 Hannes Tschofenig 320 Siemens Networks GmbH & Co KG 321 Otto-Hahn-Ring 6 322 Munich, Bavaria 81739 323 Germany 325 Phone: +49 89 636 40390 326 Email: Hannes.Tschofenig@siemens.com 327 URI: http://www.tschofenig.com 329 Full Copyright Statement 331 Copyright (C) The Internet Society (2006). 333 This document is subject to the rights, licenses and restrictions 334 contained in BCP 78, and except as set forth therein, the authors 335 retain all their rights. 337 This document and the information contained herein are provided on an 338 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 339 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 340 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 341 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 342 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 343 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 345 Intellectual Property 347 The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; nor does it represent that it has 352 made any independent effort to identify any such rights. Information 353 on the procedures with respect to rights in RFC documents can be 354 found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use of 359 such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository at 361 http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at 367 ietf-ipr@ietf.org. 369 Acknowledgment 371 Funding for the RFC Editor function is provided by the IETF 372 Administrative Support Activity (IASA).