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]