idnits 2.17.1 draft-ietf-ecrit-dhc-lost-discovery-03.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, updated by RFC 4748 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 368. 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 IETF Trust 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 (May 29, 2008) is 5804 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: 'RFC1034' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'RFC3396' is defined on line 274, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Schulzrinne 3 Internet-Draft Columbia University 4 Intended status: Standards Track J. Polk 5 Expires: November 30, 2008 Cisco 6 H. Tschofenig 7 Nokia Siemens Networks 8 May 29, 2008 10 A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service 11 Translation Protocol (LoST) Discovery Procedure 12 draft-ietf-ecrit-dhc-lost-discovery-03.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 November 30, 2008. 39 Abstract 41 The Location-to-Service Translation Protocol (LoST) describes an XML- 42 based protocol for mapping service identifiers and geospatial or 43 civic location information to service contact Uniform Resource 44 Locators (URLs). LoST servers can be located anywhere but a 45 placement closer to the end host, e.g., in the access network, is 46 desireable. Such a LoST server placement provides benefits in 47 disaster situations with intermittent network connectivity regarding 48 the resiliency of emergency service communication. 50 This document describes how a LoST client can discover a LoST server 51 using the Dynamic Host Configuration Protocol (DHCP). 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Domain Name Encoding . . . . . . . . . . . . . . . . . . . . . 3 58 4. LoST Server DHCPv4 Option . . . . . . . . . . . . . . . . . . . 4 59 5. LoST Server DHCPv6 Option . . . . . . . . . . . . . . . . . . . 5 60 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. IANA Consideration for DHCPv4 Option . . . . . . . . . . . 6 63 7.2. IANA Consideration for DHCPv6 Option . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 Intellectual Property and Copyright Statements . . . . . . . . . . 9 72 1. Introduction 74 The Location-to-Service Translation Protocol (LoST) 75 [I-D.ietf-ecrit-lost] describes an XML-based protocol for mapping 76 service identifiers and geospatial or civic location information to 77 service contact Uniform Resource Locators (URLs). 79 In order to interact with a LoST server, the LoST client eventually 80 needs to discover the server's IP address. Several mechanisms can be 81 used to learn this address, including manual configuration. In 82 environments where the access network itself either deploys a LoST 83 server or knows a third party that operates a LoST server, DHCP can 84 provide the end host with a domain name. This domain name is then 85 used as input to the DNS-based resolution mechanism described in LoST 86 [I-D.ietf-ecrit-lost] that reuses the URI-enabled NAPTR specification 87 (see [RFC4848]). 89 This document specifies a DHCPv4 and a DHCPv6 option that allows LoST 90 clients to discover local LoST servers. 92 Section 2 provides terminology. Section 3 shows the encoding of the 93 domain name. Section 4 describes the DHCPv4 option while Section 5 94 describes the DHCPv6 option, with the same functionality. IANA and 95 Security Considerations complete the document in Section 7 and 96 Section 8. 98 2. Terminology 100 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 101 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 102 and "OPTIONAL" are to be interpreted as described in RFC 2119 103 [RFC2119]. 105 Within this document, we use terminology from [RFC5012] and 106 [I-D.ietf-ecrit-lost]. 108 3. Domain Name Encoding 110 This section describes the encoding of the domain name used in the 111 DHCPv4 option shown in Section 4 and also used in the DHCPv6 option 112 shown in Section 5. 114 The domain name is encoded according to Section 3.1 of RFC 1035 115 [RFC1035] whereby each label is represented as a one octet length 116 field followed by that number of octets. Since every domain name 117 ends with the null label of the root, a domain name is terminated by 118 a length byte of zero. The high order two bits of every length octet 119 MUST be zero, and the remaining six bits of the length field limit 120 the label to 63 octets or less. To simplify implementations, the 121 total length of a domain name (i.e., label octets and label length 122 octets) is restricted to 255 octets or less. 124 4. LoST Server DHCPv4 Option 126 The LoST server DHCPv4 option carries a DNS (RFC 1035 [RFC1035]) 127 fully-qualified domain name to be used by the LoST client to locate a 128 LoST server. 130 The DHCP option for this encoding has the following format: 132 Code Len LoST Server Domain Name 133 +-----+-----+-----+-----+-----+-----+-----+---- 134 | TBD1| n | s1 | s2 | s3 | s4 | s5 | ... 135 +-----+-----+-----+-----+-----+-----+-----+---- 137 Figure 1: LoST FQDN DHCPv4 Option 139 The values s1, s2, s3, etc. represent the domain name labels in the 140 domain name encoding. Note that the length field in the DHCPv4 141 option represents the length of the entire domain name encoding, 142 whereas the length fields in the domain name encoding (see Section 3) 143 is the length of a single domain name label. 145 Code: OPTION_V4_LOST (TBD1) 147 Len: Length of the 'LoST Server Domain Name' field 148 in octets; variable. 150 LoST server Domain Name: The domain name of the LoST 151 server for the client to use. 153 A DHCPv4 client MAY request a LoST server domain name in an Parameter 154 Request List option, as described in [RFC2131]. 156 The encoding of the domain name is described in Section 3. 158 This option contains a single doamin name, and as such MUST contain 159 precisely one root label. 161 5. LoST Server DHCPv6 Option 163 This section defines a DHCPv6 option to carry a domain name. 165 The DHCPv6 option has the format shown in Figure 2. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | OPTION_V6_LOST | option-length | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | LoST Server Domain Name | 173 | ... | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 2: DHCPv6 Option for LoST Server Domain Name List 178 option-code: OPTION_V6_LOST (TBD2) 180 option-length: Length of the 'LoST Server Domain Name' field 181 in octets; variable. 183 LoST server Domain Name: The domain name of the LoST 184 server for the client to use. 186 A DHCPv6 client MAY request a LoST server domain name in an Options 187 Request Option (ORO), as described in [RFC3315]. 189 The encoding of the domain name is described in Section 3. 191 This option contains a single doamin name, and as such MUST contain 192 precisely one root label. 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 |TBD1|13 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 203 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 205 Figure 3: Example for a LoST FQDN DHCPv4 Option 207 7. IANA Considerations 209 7.1. IANA Consideration for DHCPv4 Option 211 The following DHCPv4 option code for the Location-to-Service 212 Translation Protocol (LoST) server option must be assigned by IANA: 214 Option Name Value Described in 215 ----------------------------------------------- 216 OPTION_V4_LOST TBD1 Section 4 218 7.2. IANA Consideration for DHCPv6 Option 220 IANA is requested to assign the following DHCPv6 option codes for the 221 Location-to-Service Translation Protocol (LoST) options: 223 Option Name Value Described in 224 ------------------------------------------------ 225 OPTION_V6_LOST TBD2 Section 5 227 8. Security Considerations 229 If an adversary manages to modify the response from a DHCP server or 230 insert its own response, a LoST client could be led to contact a 231 rogue LoST server under the control of the adversary or be given an 232 invalid address. These threats are documented in [RFC5069]. The 233 security considerations in [RFC2131], [RFC2132] and [RFC3315] are 234 applicable to this document. 236 With respect to the LoST security mechanisms please refer to 237 [I-D.ietf-ecrit-lost]. 239 9. Acknowledgements 241 The authors would like to thank Andrew Newton and Leslie Daigle for 242 their draft review and Andy for the proposed simplifications. 244 Mark Stapp and David W. Hankins did the document review for the DHC 245 working group as part of the joint working group last call. 247 We would like to thank Vijay K. Gurbani for the Gen-ART review. 248 Furthermore, we would like to thank Russ Housley, Tim Polk, Jari 249 Arkko, and Christian Vogt. 251 10. References 253 10.1. Normative References 255 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 256 STD 13, RFC 1034, November 1987. 258 [RFC1035] Mockapetris, P., "Domain names - implementation and 259 specification", STD 13, RFC 1035, November 1987. 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", RFC 2119, BCP 14, March 1997. 264 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 265 RFC 2131, March 1997. 267 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 268 Extensions", RFC 2132, March 1997. 270 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 271 and M. Carney, "Dynamic Host Configuration Protocol for 272 IPv6 (DHCPv6)", RFC 3315, July 2003. 274 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 275 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 276 November 2002. 278 10.2. Informative References 280 [I-D.ietf-ecrit-lost] 281 Hardie, T., Newton, A., Schulzrinne, H., and H. 282 Tschofenig, "LoST: A Location-to-Service Translation 283 Protocol", draft-ietf-ecrit-lost-10 (work in progress), 284 May 2008. 286 [RFC4848] Daigle, L., "Domain-Based Application Service Location 287 Using URIs and the Dynamic Delegation Discovery Service 288 (DDDS)", RFC 4848, April 2007. 290 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 291 Emergency Context Resolution with Internet Technologies", 292 RFC 5012, January 2008. 294 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 295 Shanmugam, "Security Threats and Requirements for 296 Emergency Call Marking and Mapping", RFC 5069, 297 January 2008. 299 Authors' Addresses 301 Henning Schulzrinne 302 Columbia University 303 Department of Computer Science 304 450 Computer Science Building 305 New York, NY 10027 306 US 308 Phone: +1 212 939 7004 309 Email: hgs+ecrit@cs.columbia.edu 310 URI: http://www.cs.columbia.edu 312 James Polk 313 Cisco 314 2200 East President George Bush Turnpike 315 Richardson, Texas 75082 316 US 318 Email: jmpolk@cisco.com 320 Hannes Tschofenig 321 Nokia Siemens Networks 322 Linnoitustie 6 323 Espoo 02600 324 Finland 326 Phone: +358 (50) 4871445 327 Email: Hannes.Tschofenig@nsn.com 328 URI: http://www.tschofenig.priv.at 330 Full Copyright Statement 332 Copyright (C) The IETF Trust (2008). 334 This document is subject to the rights, licenses and restrictions 335 contained in BCP 78, and except as set forth therein, the authors 336 retain all their rights. 338 This document and the information contained herein are provided on an 339 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 340 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 341 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 342 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 343 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 344 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 346 Intellectual Property 348 The IETF takes no position regarding the validity or scope of any 349 Intellectual Property Rights or other rights that might be claimed to 350 pertain to the implementation or use of the technology described in 351 this document or the extent to which any license under such rights 352 might or might not be available; nor does it represent that it has 353 made any independent effort to identify any such rights. Information 354 on the procedures with respect to rights in RFC documents can be 355 found in BCP 78 and BCP 79. 357 Copies of IPR disclosures made to the IETF Secretariat and any 358 assurances of licenses to be made available, or the result of an 359 attempt made to obtain a general license or permission for the use of 360 such proprietary rights by implementers or users of this 361 specification can be obtained from the IETF on-line IPR repository at 362 http://www.ietf.org/ipr. 364 The IETF invites any interested party to bring to its attention any 365 copyrights, patents or patent applications, or other proprietary 366 rights that may cover technology that may be required to implement 367 this standard. Please address the information to the IETF at 368 ietf-ipr@ietf.org.