One document matched: draft-andrews-dnsop-pd-reverse-00.xml

<?xml version="1.0"?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-andrews-dnsop-pd-reverse-00">
  <front>
    <title abbrev="customer reverse zones">Automatic Delegation of IP6.ARPA reverse zones with PD</title>
    <author initials="M." surname="Andrews" fullname="M. Andrews">
      <organization abbrev="ISC">Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94063</code>
          <country>US</country>
        </postal>
        <email>marka@isc.org</email>
      </address>
    </author>
    <date month="October" year="2013"/>
    <abstract>
      <t>
      This document describes a method to automate the delegation of
      IPv6.ARPA reverse zones when performing Prefix Delegations.
      </t>
    </abstract>
  </front>
  <middle>
    <section toc="yes" anchor="intro" title="Introduction">
      <t>
	This document describes a method to automate the delegation
	of IPv6.ARPA reverse zones when performing Prefix Delegations.
      </t> <t>
	This will allow home users and small businesses to have
	IPv6.ARPA zones without manual intervention on the part of
	the ISP.
      </t>
    </section>
    <section toc="yes" anchor="method" title="Method">
      <t>
	CPE generates a RSA key pair and stores this in non-volatile
	memory.
      </t> <t>
	CPE generates DHCPv6 Prefix Delegation <xref target="RFC3633"/>
	request which includes a KEY-RDATA option (code point TBA) which
	contains a the rdata of a DNS KEY record containing a RSASHA256
	key using the public components of the previously generated RSA
	key pair.
      </t> <t>
	DHCP server updates DNS server based on the prefix it is
	delegating and the KEY-RDATA using TSIG <xref target="RFC2845"/>
	for authentication and responds with prefix.  If this is a
	new prefix delegation it will clear out all the old DNS
	records as part of the delegation processs.  If there are
	multiple prefixes being delegated the ISP's DNS server will be
	updated for all of them.
      </t> <t>
	The CPE device configures the nameserver built in to it to
	server the reverse of the delegated prefixes.   Alternatively
	it may configure other nameservers to server these zones
	however the method to do that is out of scope for this
	document.
      </t> <t>
	CPE device generates DNS UPDATE <xref target="RFC2136"/> which
	delegates the reverse name space to itself and others if they
	have been configured. The CPE uses SIG(0) <xref target="RFC2931"/>
        to sign the request with owner name matching the reverse of the
        delegated prefix.
      </t> <t>
	The ISP's DNS server is configured to accept self signed
	requests (the owner name used in the SIG(0) signature matches
	the owner name of the data to be updated).  It examines the
	request. Looks at the KEY record added by the DHCPv6 server
	and decides the request is valid.
      </t>
    </section>
    <section toc="yes" anchor="iana" title="IANA Considerations">
       <t>
	 Allocate a DHCPv6 code point for KEY-RDATA.
       </t>
    </section>
    <section toc="yes" anchor="security" title="Security Considerations">
      <t>
	The UPDATE requests are all signed.  This is a proven method
	for securing UPDATE requests in the DNS.
      </t>
      <t>
	As a RSA key is being used there is no issue with the key material
	being in the clear.
      </t>
      <t>
	Only the CPE device and the ISP itself is capable of creating, 
	updating or destroying the delegation.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC2136">
	<front>
	  <title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
          <author initials="P." surname="Vixie" fullname="P. Vixie"/>
          <author initials="S." surname="Thomson" fullname="S. Thomson"/>
          <author initials="Y." surname="Rekhter" fullname="Y. Rekhter"/>
          <author initials="J." surname="Bound" fullname="J. Bound"/>
          <date month="April" year="1997" />
        </front>
        <seriesInfo name="RFC" value="2136" />
      </reference>
      <reference anchor="RFC2845">
	<front>
	  <title>Secret Key Transaction Authentication for DNS (TSIG)</title>
          <author initials="P." surname="Vixie" fullname="P. Vixie"/>
          <author initials="O." surname="Gudmundsson" fullname="O. Gudmundsson"/>
          <author initials="D." surname="Eastlake" fullname="D. Eastlake 3rd"/>
          <author initials="B." surname="Wellington" fullname="B. Wellington"/>
          <date month="May" year="2000" />
        </front>
        <seriesInfo name="RFC" value="2845" />
      </reference>
      <reference anchor="RFC2931">
	<front>
	  <title>Secret Key Transaction Authentication for DNS (TSIG)</title>
          <author initials="D." surname="Eastlake" fullname="D. Eastlake 3rd"/>
          <date month="September" year="2000" />
        </front>
        <seriesInfo name="RFC" value="2931" />
      </reference>
      <reference anchor="RFC3633">
	<front>
	  <title>IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6</title>
          <author initials="O." surname="Troan" fullname="O. Troan"/>
          <author initials="R." surname="Droms" fullname="R. Droms"/>
          <date month="December" year="2003" />
        </front>
        <seriesInfo name="RFC" value="3633" />
      </reference>
    </references>
  </back>
</rfc>