Network Working Group S. Orr Internet-Draft S. Bhandari Intended status: Standards Track T. Reddy Expires: August 2, 2013 P. Patil Cisco January 29, 2013 DNS Service Discovery options in DHCP draft-orr-dhcp-dns-sd-options-00 Abstract This document specifies DHCPv4 and DHCPv6 options to deliver Service Discovery Domains required for DNS based service registration and discovery. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 2, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Orr, et al. Expires August 2, 2013 [Page 1] Internet-Draft DHCP options for DNS service discovery January 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. DNS Service Discovery Domain Name Option . . . . . . . . . . . 4 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 11. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Orr, et al. Expires August 2, 2013 [Page 2] Internet-Draft DHCP options for DNS service discovery January 2013 1. Introduction Domain Name System (DNS) allows for dynamic registration and discovery of service through the use of Resource Records (RR) to allow hosts to connect to network resources without knowing apriori what services currently reside in the network. DNS based service discovery is defined in [I-D.cheshire-dnsext-dns-sd] and dynamic DNS updates for service registration is described in [RFC2136] and[RFC3007]. For a host to dynamically register and browse services it has to know the domain in which it is allowed to register/browse these services. If the server for such a service domain cannot be dynamically looked up in the DNS search domain then the server's address has to be learnt by the host where it can register and browse services. This document specifies options for DHCPv4 and DHCPv6 to inform the host or a network device service discovery domain it can use and advertise. 2. Motivation Service registration and browsing is a critical part of client operations. Without service registration and browsing, a user must know in advance the IP address or hostname where the specific service they require is located. By using dynamic service registration and browsing, clients can search their domain for serivces of interest (printers, video devices, storage etc) or these services can advertise themselves on the network. Practical applications range from homenets to enterprise and service provide architectures. Typical DNS deployment models using DHCP option allow hosts to receive their DNS Domain as well as their primary/secondary DNS servers. These DNS servers typically are used for Fully Qualified Domain Name to IP address translation where the service is included as part of the name such as www.xyz123.com or ftp.xyz123.com to designate the Web and FTP Services for the xyz123.com domain. This document introduces DHCP options to provide multiple domains in addition to the FQDN to register and browse for services. Direct application for this can be seen in home/residential networking where the FQDN and DNS servers delivered to the host does not permit them to register or browse for services on their local home network where it would be more applicable to provide a "home" domain for these users in addition to Service Provider assigned domain. In enterprise networks when heirarchical sub-domains have to be carved out network device that is at the root of such sub-domains can learn and provide these options to clients that are part of such sub- domains. Orr, et al. Expires August 2, 2013 [Page 3] Internet-Draft DHCP options for DNS service discovery January 2013 3. Terminology All the DHCP related terms used in this document are to be interpreted as defined in the Dynamic Host Configuration Protocol v4 (DHCPv4) [RFC2131] and Dynamic Host Configuration Protocol v6 (DHCPv6) [RFC3315] specifications. DHCP refers to both DHCPv4 and DHCPv6 messages and entities throughout this document. All the DNS related terms used in this document are to be interpreted as defined in the DNS [RFC1035] and [RFC2136]. 4. DNS Service Discovery Domain Name Option DNS Service Discovery Domain Name option carries service discovery domain information where services can be registered and discovered. Orr, et al. Expires August 2, 2013 [Page 4] Internet-Draft DHCP options for DNS service discovery January 2013 The format of the DNS SD Domain Name option is shown below. DHCPv4 Option Code Len DNS-SD-domain-name Value +------+------+------+------+------+-- --+-----+ | TBD1 | len | DNS-SD-domain-name ... | +------+------+------+------+------+-- --+-----+ TBD1: 8-bit code carrying TBD1 len: 8 bit indicating total length of the included DNS-SD-domain-name value. DNS-SD-domain-name: Contains the domain name encoded according to Section 3.1 of[RFC 1035] This option contains a single domain name and, as such,MUST contain precisely one root label. DHCPv6 Option 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code (TBD2) | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . DNS-SD-domain-name . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: 16-bit code TBD2 option-length: 16-bit unsigned integer indicating length in octets of this option DNS-SD-domain-name: Contains the domain name encoded according to Section 3.1 of[RFC 1035] This option contains a single domain name and, as such,MUST contain precisely one root label. 5. Client Behavior All hosts or clients MAY request for Service Domain Name option in all the upstream DHCP messages. A DHCPv4 client MAY request a service domain name option in a Parameter Request List option, as described in [RFC2131]. A DHCPv6 client MAY request an service domain name option in an Options Request Option (ORO), as described in [RFC3315]. Orr, et al. Expires August 2, 2013 [Page 5] Internet-Draft DHCP options for DNS service discovery January 2013 6. Relay Agent Behavior Directly connected relay agent MAY provide a hint about the connected service domain to influence the service domain provided to the client as per [RFC6422] by including this option in the Relay- Supplied Options option towards the server. 7. Server Behavior If a DHCP Server is configured with these options and receives a client request for these options, it MUST return these options and associated data in a downstream DHCP message. Additionaly, if a DHCP server is configured with these options, it SHOULD deliver them to the client whether or not it is explicitly requested. 8. IANA Considerations This document defines DHCPv4 Service Domain Name option which requires assignment of DHCPv4 option code TBD1 assigned from "Bootp and DHCP options" registry (http://www.iana.org/assignments/ bootp-dhcp-parameters/bootp-dhcp-parameters.xml), as specified in [RFC2939]. IANA is requested to assign option code TBD2 for DHCPv6 option from the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/ assignments/dhcpv6-parameters/dhcpv6-parameters.xml). IANA is requested to add TBD2 to "Options Permitted in the Relay- Supplied Options Option". 9. Security Considerations The options defined in this document may be used by an intruder DHCP server to assign invalid parameters, resulting in clients unable to register and discover services. To minimize these attacks, this option SHOULD be included by DHCP entities only when it is configured. Where critical decisions might be based on the value of this option, DHCP authentication as defined in "Authentication for DHCP Messages" [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] SHOULD be used to protect the integrity of the DHCP options. Link-layer confidentiality and integrity protection may also be employed to reduce the risk of disclosure and tampering. Orr, et al. Expires August 2, 2013 [Page 6] Internet-Draft DHCP options for DNS service discovery January 2013 10. Acknowledgements 11. Change log 12. Normative References [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-11 (work in progress), December 2011. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, December 2011. Orr, et al. Expires August 2, 2013 [Page 7] Internet-Draft DHCP options for DNS service discovery January 2013 Authors' Addresses Stephen Orr Cisco Systems, Inc. 1 Paragon Drive Montvale, NJ 07645 USA Email: sorr@cisco.com Shwetha Bhandari Cisco Systems, Inc. Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India Phone: +91 80 4426 0474 Email: shwethab@cisco.com Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com Prashanth Patil Cisco Systems, Inc. Bangalore, Karnataka 560103 India Email: praspati@cisco.com Orr, et al. Expires August 2, 2013 [Page 8]