idnits 2.17.1 draft-ietf-ecrit-dhc-lost-discovery-02.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 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 363. 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 (July 8, 2007) is 6137 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 248, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-05 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-security-threats-04 Summary: 2 errors (**), 0 flaws (~~), 5 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: January 9, 2008 Cisco 6 H. Tschofenig 7 Nokia Siemens Networks 8 July 8, 2007 10 A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service 11 Translation Protocol (LoST) Discovery Procedure 12 draft-ietf-ecrit-dhc-lost-discovery-02.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 January 9, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 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 [RFC4848]). 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 For DHCPv4 only: If the length of the domain name exceeds the 128 maximum permissible within a single option (i.e., 254 octets), then 129 the domain name MUST be represented in the DHCP message as specified 130 in [RFC3396]. 132 4. LoST Server DHCPv4 Option 134 The LoST server DHCPv4 option carries a DNS (RFC 1035 [RFC1035]) 135 fully-qualified domain name to be used by the LoST client to locate a 136 LoST server. 138 The DHCP option for this encoding has the following format: 140 Code Len LoST Server Domain Name 141 +-----+-----+-----+-----+-----+-----+-----+---- 142 | TBD | n | s1 | s2 | s3 | s4 | s5 | ... 143 +-----+-----+-----+-----+-----+-----+-----+---- 145 Figure 1: LoST FQDN DHCPv4 Option 147 Code: OPTION_V4_LOST (TBD1) 149 Len: Length of the 'LoST Server Domain Name' field 150 in octets; variable. 152 LoST server Domain Name: The domain name of the LoST 153 server for the client to use. 155 The encoding of the domain name is described in Section 3. 157 Only a single domain name MUST be present in the DHCPv4 option. 159 5. LoST Server DHCPv6 Option 161 This document defines a DHCPv6 options to carry a domain name. 163 The DHCPv6 option has the format shown in Figure 3. 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | OPTION_V6_LOST | option-length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | LoST Server Domain Name | 171 | ... | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 3: DHCPv6 Option for LoST Server Domain Name List 176 option-code: OPTION_V6_LOST (TBD2) 178 option-length: Length of the 'LoST Server Domain Name' field 179 in octets; variable. 181 LoST server Domain Name: The domain name of the LoST 182 server for the client to use. 184 A DHCPv6 client MAY request a LoST server domain name in an Options 185 Request Option (ORO), as described in [RFC3315]. 187 A DHCPv4 client MAY request a LoST server domain name in an Parameter 188 Request List option, as described in [RFC2131]. 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 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 TBD 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 TBD 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 233 [I-D.ietf-ecrit-security-threats]. The security considerations in 234 [RFC2131], [RFC2132] and [RFC3315] are applicable to this document. 236 9. Acknowledgements 238 The authors would like to thank Andrew Newton and Leslie Daigle for 239 their draft review. We would like to particularly thank Andrew 240 Newton for the simplifications he proposed. 242 Mark Stapp did the document review of this document for the DHC 243 working group as part of the joint working group last call. 245 10. References 246 10.1. Normative References 248 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 249 STD 13, RFC 1034, November 1987. 251 [RFC1035] Mockapetris, P., "Domain names - implementation and 252 specification", STD 13, RFC 1035, November 1987. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", RFC 2119, BCP 14, March 1997. 257 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 258 RFC 2131, March 1997. 260 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 261 Extensions", RFC 2132, March 1997. 263 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 264 and M. Carney, "Dynamic Host Configuration Protocol for 265 IPv6 (DHCPv6)", RFC 3315, July 2003. 267 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 268 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 269 November 2002. 271 10.2. Informative References 273 [I-D.ietf-ecrit-lost] 274 Hardie, T., "LoST: A Location-to-Service Translation 275 Protocol", draft-ietf-ecrit-lost-05 (work in progress), 276 March 2007. 278 [I-D.ietf-ecrit-requirements] 279 Schulzrinne, H. and R. Marshall, "Requirements for 280 Emergency Context Resolution with Internet Technologies", 281 draft-ietf-ecrit-requirements-13 (work in progress), 282 March 2007. 284 [I-D.ietf-ecrit-security-threats] 285 Taylor, T., "Security Threats and Requirements for 286 Emergency Call Marking and Mapping", 287 draft-ietf-ecrit-security-threats-04 (work in progress), 288 April 2007. 290 [RFC4848] Daigle, L., "Domain-Based Application Service Location 291 Using URIs and the Dynamic Delegation Discovery Service 292 (DDDS)", RFC 4848, April 2007. 294 Authors' Addresses 296 Henning Schulzrinne 297 Columbia University 298 Department of Computer Science 299 450 Computer Science Building 300 New York, NY 10027 301 US 303 Phone: +1 212 939 7004 304 Email: hgs+ecrit@cs.columbia.edu 305 URI: http://www.cs.columbia.edu 307 James Polk 308 Cisco 309 2200 East President George Bush Turnpike 310 Richardson, Texas 75082 311 US 313 Email: jmpolk@cisco.com 315 Hannes Tschofenig 316 Nokia Siemens Networks 317 Otto-Hahn-Ring 6 318 Munich, Bavaria 81739 319 Germany 321 Phone: +49 89 636 40390 322 Email: Hannes.Tschofenig@nsn.com 323 URI: http://www.tschofenig.com 325 Full Copyright Statement 327 Copyright (C) The IETF Trust (2007). 329 This document is subject to the rights, licenses and restrictions 330 contained in BCP 78, and except as set forth therein, the authors 331 retain all their rights. 333 This document and the information contained herein are provided on an 334 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 335 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 336 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 337 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 338 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 341 Intellectual Property 343 The IETF takes no position regarding the validity or scope of any 344 Intellectual Property Rights or other rights that might be claimed to 345 pertain to the implementation or use of the technology described in 346 this document or the extent to which any license under such rights 347 might or might not be available; nor does it represent that it has 348 made any independent effort to identify any such rights. Information 349 on the procedures with respect to rights in RFC documents can be 350 found in BCP 78 and BCP 79. 352 Copies of IPR disclosures made to the IETF Secretariat and any 353 assurances of licenses to be made available, or the result of an 354 attempt made to obtain a general license or permission for the use of 355 such proprietary rights by implementers or users of this 356 specification can be obtained from the IETF on-line IPR repository at 357 http://www.ietf.org/ipr. 359 The IETF invites any interested party to bring to its attention any 360 copyrights, patents or patent applications, or other proprietary 361 rights that may cover technology that may be required to implement 362 this standard. Please address the information to the IETF at 363 ietf-ipr@ietf.org. 365 Acknowledgment 367 Funding for the RFC Editor function is provided by the IETF 368 Administrative Support Activity (IASA).