Internet DRAFT - draft-orr-dhcp-dns-sd-options
draft-orr-dhcp-dns-sd-options
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
<TBD> 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]
