<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2132 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC5213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY RFC4649 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4649.xml">
<!ENTITY RFC3046 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml">
<!ENTITY RFC6225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6255.xml">
<!ENTITY RFC2939 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2939.xml">
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC3118 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml">
<!ENTITY RFC2136 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml">
<!ENTITY RFC3007 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3007.xml">
<!ENTITY RFC6422 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6422.xml">
<!ENTITY DHCPv6-IANA-Registry SYSTEM "http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml">
<!ENTITY DHCPv4-IANA-Registry SYSTEM "http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml#options">
<!ENTITY I-D.cheshire-dnsext-dns-sd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-dns-sd.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-orr-dhcp-dns-sd-options-00"
     ipr="trust200902">
  <front>
    <title abbrev="DHCP options for DNS service discovery">DNS Service
    Discovery options in DHCP</title>

    <author fullname="Stephen Orr" initials="S." surname="Orr">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>1 Paragon Drive</street>

          <street></street>

          <city>Montvale</city>

          <region>NJ</region>

          <code>07645</code>

          <country>USA</country>
        </postal>

        <email>sorr@cisco.com</email>
      </address>
    </author>

    <author fullname="Shwetha Bhandari" initials="S." surname="Bhandari">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Sarjapura Marathalli Outer Ring
          Road</street>

          <city>Bangalore</city>

          <region>KARNATAKA</region>

          <code>560 087</code>

          <country>India</country>
        </postal>

        <phone>+91 80 4426 0474</phone>

        <email>shwethab@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Prashanth Patil" initials="P." surname="Patil">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street></street>

          <street></street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>praspati@cisco.com</email>
      </address>
    </author>

    <date day="29" month="January" year="2013" />

    <abstract>
      <t>This document specifies DHCPv4 and DHCPv6 options to deliver Service
      Discovery Domains required for DNS based service registration and
      discovery.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>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 <xref target="I-D.cheshire-dnsext-dns-sd"></xref> and dynamic
      DNS updates for service registration is described in <xref
      target="RFC2136"></xref> and<xref target="RFC3007"></xref>.</t>

      <t>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.</t>
    </section>

    <section title="Motivation">
      <t>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. </t>

      <t>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. </t>

      <t><!--
TBD - homenet, enterprises where DNS domain and server for service discovery is not the same as search domain dns server.--></t>
    </section>

    <section title="Terminology">
      <t>All the DHCP related terms used in this document are to be
      interpreted as defined in the Dynamic Host Configuration Protocol v4
      (DHCPv4) <xref target="RFC2131"></xref> and Dynamic Host Configuration
      Protocol v6 (DHCPv6) <xref target="RFC3315"></xref> specifications. DHCP
      refers to both DHCPv4 and DHCPv6 messages and entities throughout this
      document.</t>

      <t>All the DNS related terms used in this document are to be interpreted
      as defined in the DNS <xref target="RFC1035"></xref> and <xref
      target="RFC2136"></xref>.</t>
    </section>

    <section title="DNS Service Discovery Domain Name Option">
      <t>DNS Service Discovery Domain Name option carries service discovery
      domain information where services can be registered and
      discovered.<figure suppress-title="true">
          <preamble>The format of the DNS SD Domain Name option is shown
          below.</preamble>

          <artwork><![CDATA[ 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.
                    
 ]]></artwork>

          <postamble></postamble>
        </figure></t>
    </section>

    <!--TBD: Insert the option/Flags whether this DNS-SD domain is unicast or multicast (IPv4 and IPv6) - assume this would be in the 8 bit code.-->

    <section title="Client Behavior">
      <t>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
      <xref target="RFC2131"></xref>. A DHCPv6 client MAY request an service
      domain name option in an Options Request Option (ORO), as described in
      <xref target="RFC3315"></xref>.</t>
    </section>

    <section title="Relay Agent Behavior">
      <t>&lt;TBD&gt; Directly connected relay agent MAY provide a hint about
      the connected service domain to influence the service domain provided to
      the client as per <xref target="RFC6422"></xref> by including this
      option in the Relay-Supplied Options option towards the server.</t>
    </section>

    <section title="Server Behavior">
      <t>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.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>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 <xref target="RFC2939"></xref>.</t>

      <t>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).</t>

      <t>IANA is requested to add TBD2 to "Options Permitted in the
      Relay-Supplied Options Option".</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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.</t>

      <t>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" <xref target="RFC3118"></xref> and
      "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" <xref
      target="RFC3315"></xref> 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.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t></t>
    </section>

    <section title="Change log">
      <t></t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      &RFC2119;

      &RFC3315;

      &RFC2131;

      &RFC2939;

      &RFC2434;

      &RFC1035;

      &RFC3118;

      &RFC2136;

      &RFC3007;

      &RFC6422;

      &I-D.cheshire-dnsext-dns-sd;
    </references>
  </back>
</rfc>
