idnits 2.17.1 draft-orr-dhcp-dns-sd-options-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 29, 2013) is 4098 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: 'RFC 1035' is mentioned on line 167, but not defined == Unused Reference: 'RFC2434' is defined on line 249, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Orr 3 Internet-Draft S. Bhandari 4 Intended status: Standards Track T. Reddy 5 Expires: August 2, 2013 P. Patil 6 Cisco 7 January 29, 2013 9 DNS Service Discovery options in DHCP 10 draft-orr-dhcp-dns-sd-options-00 12 Abstract 14 This document specifies DHCPv4 and DHCPv6 options to deliver Service 15 Discovery Domains required for DNS based service registration and 16 discovery. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 2, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. DNS Service Discovery Domain Name Option . . . . . . . . . . . 4 62 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6 64 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 11. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 12. Normative References . . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Domain Name System (DNS) allows for dynamic registration and 75 discovery of service through the use of Resource Records (RR) to 76 allow hosts to connect to network resources without knowing apriori 77 what services currently reside in the network. DNS based service 78 discovery is defined in [I-D.cheshire-dnsext-dns-sd] and dynamic DNS 79 updates for service registration is described in [RFC2136] 80 and[RFC3007]. 82 For a host to dynamically register and browse services it has to know 83 the domain in which it is allowed to register/browse these services. 84 If the server for such a service domain cannot be dynamically looked 85 up in the DNS search domain then the server's address has to be 86 learnt by the host where it can register and browse services. This 87 document specifies options for DHCPv4 and DHCPv6 to inform the host 88 or a network device service discovery domain it can use and 89 advertise. 91 2. Motivation 93 Service registration and browsing is a critical part of client 94 operations. Without service registration and browsing, a user must 95 know in advance the IP address or hostname where the specific service 96 they require is located. By using dynamic service registration and 97 browsing, clients can search their domain for serivces of interest 98 (printers, video devices, storage etc) or these services can 99 advertise themselves on the network. Practical applications range 100 from homenets to enterprise and service provide architectures. 101 Typical DNS deployment models using DHCP option allow hosts to 102 receive their DNS Domain as well as their primary/secondary DNS 103 servers. These DNS servers typically are used for Fully Qualified 104 Domain Name to IP address translation where the service is included 105 as part of the name such as www.xyz123.com or ftp.xyz123.com to 106 designate the Web and FTP Services for the xyz123.com domain. This 107 document introduces DHCP options to provide multiple domains in 108 addition to the FQDN to register and browse for services. Direct 109 application for this can be seen in home/residential networking where 110 the FQDN and DNS servers delivered to the host does not permit them 111 to register or browse for services on their local home network where 112 it would be more applicable to provide a "home" domain for these 113 users in addition to Service Provider assigned domain. 115 In enterprise networks when heirarchical sub-domains have to be 116 carved out network device that is at the root of such sub-domains can 117 learn and provide these options to clients that are part of such sub- 118 domains. 120 3. Terminology 122 All the DHCP related terms used in this document are to be 123 interpreted as defined in the Dynamic Host Configuration Protocol v4 124 (DHCPv4) [RFC2131] and Dynamic Host Configuration Protocol v6 125 (DHCPv6) [RFC3315] specifications. DHCP refers to both DHCPv4 and 126 DHCPv6 messages and entities throughout this document. 128 All the DNS related terms used in this document are to be interpreted 129 as defined in the DNS [RFC1035] and [RFC2136]. 131 4. DNS Service Discovery Domain Name Option 133 DNS Service Discovery Domain Name option carries service discovery 134 domain information where services can be registered and discovered. 136 The format of the DNS SD Domain Name option is shown below. 137 DHCPv4 Option 139 Code Len DNS-SD-domain-name Value 140 +------+------+------+------+------+-- --+-----+ 141 | TBD1 | len | DNS-SD-domain-name ... | 142 +------+------+------+------+------+-- --+-----+ 144 TBD1: 8-bit code carrying TBD1 146 len: 8 bit indicating total length of the included 147 DNS-SD-domain-name value. 148 DNS-SD-domain-name: Contains the domain name encoded according to 149 Section 3.1 of[RFC 1035] 150 This option contains a single domain name and, 151 as such,MUST contain precisely one root label. 153 DHCPv6 Option 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | option-code (TBD2) | option-length | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 . DNS-SD-domain-name . 160 . ... . 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 option-code: 16-bit code TBD2 164 option-length: 16-bit unsigned integer indicating length 165 in octets of this option 166 DNS-SD-domain-name: Contains the domain name encoded according to 167 Section 3.1 of[RFC 1035] 168 This option contains a single domain name and, 169 as such,MUST contain precisely one root label. 171 5. Client Behavior 173 All hosts or clients MAY request for Service Domain Name option in 174 all the upstream DHCP messages. A DHCPv4 client MAY request a 175 service domain name option in a Parameter Request List option, as 176 described in [RFC2131]. A DHCPv6 client MAY request an service 177 domain name option in an Options Request Option (ORO), as described 178 in [RFC3315]. 180 6. Relay Agent Behavior 182 Directly connected relay agent MAY provide a hint about the 183 connected service domain to influence the service domain provided to 184 the client as per [RFC6422] by including this option in the Relay- 185 Supplied Options option towards the server. 187 7. Server Behavior 189 If a DHCP Server is configured with these options and receives a 190 client request for these options, it MUST return these options and 191 associated data in a downstream DHCP message. Additionaly, if a DHCP 192 server is configured with these options, it SHOULD deliver them to 193 the client whether or not it is explicitly requested. 195 8. IANA Considerations 197 This document defines DHCPv4 Service Domain Name option which 198 requires assignment of DHCPv4 option code TBD1 assigned from "Bootp 199 and DHCP options" registry (http://www.iana.org/assignments/ 200 bootp-dhcp-parameters/bootp-dhcp-parameters.xml), as specified in 201 [RFC2939]. 203 IANA is requested to assign option code TBD2 for DHCPv6 option from 204 the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/ 205 assignments/dhcpv6-parameters/dhcpv6-parameters.xml). 207 IANA is requested to add TBD2 to "Options Permitted in the Relay- 208 Supplied Options Option". 210 9. Security Considerations 212 The options defined in this document may be used by an intruder DHCP 213 server to assign invalid parameters, resulting in clients unable to 214 register and discover services. 216 To minimize these attacks, this option SHOULD be included by DHCP 217 entities only when it is configured. Where critical decisions might 218 be based on the value of this option, DHCP authentication as defined 219 in "Authentication for DHCP Messages" [RFC3118] and "Dynamic Host 220 Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] SHOULD be used to 221 protect the integrity of the DHCP options. Link-layer 222 confidentiality and integrity protection may also be employed to 223 reduce the risk of disclosure and tampering. 225 10. Acknowledgements 227 11. Change log 229 12. Normative References 231 [I-D.cheshire-dnsext-dns-sd] 232 Cheshire, S. and M. Krochmal, "DNS-Based Service 233 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 234 progress), December 2011. 236 [RFC1035] Mockapetris, P., "Domain names - implementation and 237 specification", STD 13, RFC 1035, November 1987. 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 243 RFC 2131, March 1997. 245 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 246 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 247 RFC 2136, April 1997. 249 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 250 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 251 October 1998. 253 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 254 of New DHCP Options and Message Types", BCP 43, RFC 2939, 255 September 2000. 257 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 258 Update", RFC 3007, November 2000. 260 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 261 Messages", RFC 3118, June 2001. 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 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 268 RFC 6422, December 2011. 270 Authors' Addresses 272 Stephen Orr 273 Cisco Systems, Inc. 274 1 Paragon Drive 275 Montvale, NJ 07645 276 USA 278 Email: sorr@cisco.com 280 Shwetha Bhandari 281 Cisco Systems, Inc. 282 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 283 Bangalore, KARNATAKA 560 087 284 India 286 Phone: +91 80 4426 0474 287 Email: shwethab@cisco.com 289 Tirumaleswar Reddy 290 Cisco Systems, Inc. 291 Cessna Business Park, Varthur Hobli 292 Sarjapur Marathalli Outer Ring Road 293 Bangalore, Karnataka 560103 294 India 296 Email: tireddy@cisco.com 298 Prashanth Patil 299 Cisco Systems, Inc. 300 Bangalore, Karnataka 560103 301 India 303 Email: praspati@cisco.com