Diff: draft-andrews-dnsop-pd-reverse-01.txt - draft-andrews-dnsop-pd-reverse-02.txt

	< draft-andrews-dnsop-pd-reverse-01.txt	draft-andrews-dnsop-pd-reverse-02.txt >

	Network Working Group M. Andrews	Network Working Group M. Andrews
	Internet-Draft ISC	Internet-Draft ISC

	Expires: May 8, 2014 November 4, 2013	Expires: May 9, 2014 November 5, 2013

	Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation	Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation

	draft-andrews-dnsop-pd-reverse-01	draft-andrews-dnsop-pd-reverse-02

	Abstract	Abstract

	This document describes a method to automate the delegation of	This document describes a method to automate the delegation of
	IP6.ARPA reverse zones when performing Prefix Delegations.	IP6.ARPA reverse zones when performing Prefix Delegations.

	Status of this Memo	Status of this Memo

	This Internet-Draft is submitted in full conformance with the	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.	provisions of BCP 78 and BCP 79.

	skipping to change at page 1, line 30 ¶	skipping to change at page 1, line 30 ¶
	Internet-Drafts are working documents of the Internet Engineering	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.	Drafts is at http://datatracker.ietf.org/drafts/current/.

	Internet-Drafts are draft documents valid for a maximum of six months	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."	material or to cite them other than as "work in progress."


	This Internet-Draft will expire on May 8, 2014.	This Internet-Draft will expire on May 9, 2014.

	Copyright Notice	Copyright Notice

	Copyright (c) 2013 IETF Trust and the persons identified as the	Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents	Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of	(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as	the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.	described in the Simplified BSD License.

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3	2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3	3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	5. Normative References . . . . . . . . . . . . . . . . . . . . . 4	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4	6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5

	1. Introduction	1. Introduction

	This document describes a method to automate the delegation of	This document describes a method to automate the delegation of
	IP6.ARPA reverse zones when performing Prefix Delegations.	IP6.ARPA reverse zones when performing Prefix Delegations.

	This will allow home users and small businesses to have IP6.ARPA	This will allow home users and small businesses to have IP6.ARPA
	zones without manual intervention on the part of the ISP.	zones without manual intervention on the part of the ISP.

	2. Method	2. Method


	CPE generates a RSA key pair and stores this in non-volatile memory.	1) CPE device generates a RSA key pair and stores this in non-
		volatile memory.


	CPE generates DHCPv6 Prefix Delegation [RFC3633] request which	2) CPE device generates a DHCPv6 Prefix Delegation [RFC3633] request
	includes a KEY-RDATA option (code point TBA) which contains a the	which includes a KEY-RDATA option (code point TBA), which contains a
	rdata of a DNS KEY record containing a RSASHA256 key using the public	the rdata of a DNS KEY record containing a RSASHA256 key using the
	components of the previously generated RSA key pair.	public components of the previously generated RSA key pair.


	DHCP server updates DNS server based on the prefix it is delegating	3) DHCP server updates DNS server based on the prefix it is
	and the KEY-RDATA using TSIG [RFC2845] for authentication and	delegating and the KEY-RDATA, using TSIG [RFC2845] for
	responds with prefix. If this is a new prefix delegation it will	authentication, and responds with prefix. If this is a new prefix
	clear out all the old DNS records as part of the delegation processs.	delegation, it will clear out all the old DNS records as part of the
	If there are multiple prefixes being delegated the ISP's DNS server	delegation process. If there are multiple prefixes being delegated
	will be updated for all of them.	the ISP's DNS server will be updated for all of them. If the
		delegated prefix is not nibble aligned then the server will update
		all the reverse apex names that cover the address space, i.e. 1, 2, 4
		or 8 KEY records will be added all with the same rdata contents.


	The CPE device configures the nameserver built in to it to server the	4) CPE device configures the nameserver built into it to serve the
	reverse of the delegated prefixes. Alternatively it may configure	reverse of the delegated prefixes. Alternatively it may configure

	other nameservers to server these zones however the method to do that	other nameservers to serve these zones, however the method to do that
	is out of scope for this document.	is out of scope for this document.


	CPE device generates DNS UPDATE [RFC2136] which delegates the reverse	5) CPE device generates a DNS UPDATE [RFC2136] which delegates the
	name space to itself and others if they have been configured. The	reverse name space to itself and others if they have been configured.
	CPE uses SIG(0) [RFC2931] to sign the request with owner name	It uses SIG(0) [RFC2931] to sign the request, with owner name
	matching the reverse of the delegated prefix.	matching the reverse of the delegated prefix.


	The ISP's DNS server is configured to accept self signed requests	6) 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	(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	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	KEY record added by the DHCPv6 server, and decides whether the
	valid.	request is valid.


	3. IANA Considerations	3. Example

		If 2001:DB8:1:4::/62 is delegated then KEY records for

		4.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA KEY ...
		5.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA KEY ...
		6.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA KEY ...
		7.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA KEY ...

		will be added. The CPE device will configure the nameservers to
		serve all of the following zones

		4.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
		5.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
		6.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
		7.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA

		then will send individual UPDATE messages to delegate each of the
		reverse zones.

		% nsupdate -k K4.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
		update add 4.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA NS ...
		send
		% nsupdate -k K5.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
		update add 5.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA NS ...
		send
		% nsupdate -k K6.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
		update add 6.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA NS ...
		send
		% nsupdate -k K7.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
		update add 7.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA NS ...
		send

		4. IANA Considerations

	Allocate a DHCPv6 code point for KEY-RDATA.	Allocate a DHCPv6 code point for KEY-RDATA.


	4. Security Considerations	5. Security Considerations

	The UPDATE requests are all signed. This is a proven method for	The UPDATE requests are all signed. This is a proven method for
	securing UPDATE requests in the DNS.	securing UPDATE requests in the DNS.


	As a RSA key is being used there is no issue with the key material	As a RSA key is being used there is no issue with key material being
	being in the clear.	sent in the clear.

	Only the CPE device and the ISP itself is capable of creating,	Only the CPE device and the ISP itself is capable of creating,
	updating or destroying the delegation.	updating or destroying the delegation.


	5. Normative References	6. Normative References

	[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,	[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
	"Dynamic Updates in the Domain Name System (DNS UPDATE)",	"Dynamic Updates in the Domain Name System (DNS UPDATE)",
	RFC 2136, April 1997.	RFC 2136, April 1997.

	[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.	[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
	Wellington, "Secret Key Transaction Authentication for DNS	Wellington, "Secret Key Transaction Authentication for DNS
	(TSIG)", RFC 2845, May 2000.	(TSIG)", RFC 2845, May 2000.

	[RFC2931] Eastlake, D., "Secret Key Transaction Authentication for	[RFC2931] Eastlake, D., "Secret Key Transaction Authentication for

End of changes. 16 change blocks.
	32 lines changed or deleted	70 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/