< draft-ietf-ipngwg-dns-lookups-07.txt		draft-ietf-ipngwg-dns-lookups-08.txt >
	IPng Working Group Matt Crawford		IPng Working Group Matt Crawford
	Internet Draft Fermilab		Internet Draft Fermilab
	Christian Huitema		Christian Huitema
	Susan Thomson		Susan Thomson
	Telcordia		Telcordia
	March 8, 2000		May 17, 2000
	DNS Extensions to Support IPv6 Address Aggregation and Renumbering		DNS Extensions to Support IPv6 Address Aggregation and Renumbering
	<draft-ietf-ipngwg-dns-lookups-07.txt>		<draft-ietf-ipngwg-dns-lookups-08.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026. Internet-Drafts are		all provisions of Section 10 of RFC 2026. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet- Drafts as		at any time. It is inappropriate to use Internet- Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	1. Abstract		1. Abstract
	This document defines changes to the Domain Name System to support		This document defines changes to the Domain Name System to support
	renumberable and aggregatable IPv6 addressing. The changes include		renumberable and aggregatable IPv6 addressing. The changes include
	a new resource record type to store an IPv6 address in a manner		a new resource record type to store an IPv6 address in a manner
	which expedites network renumbering and updated definitions of		which expedites network renumbering and updated definitions of
	existing query types that return Internet addresses as part of		existing query types that return Internet addresses as part of
	additional section processing.		additional section processing.
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	1. Abstract ...................................................... 1		1. Abstract ...................................................... 1
	2. Introduction .................................................. 3		2. Introduction .................................................. 3
	3. Overview ...................................................... 4		3. Overview ...................................................... 4
	3.1. Name-to-Address Lookup .................................. 4		3.1. Name-to-Address Lookup .................................. 4
	3.2. Underlying Mechanisms for Reverse Lookups ............... 4		3.2. Underlying Mechanisms for Reverse Lookups ............... 4
	3.2.1. Delegation on Arbitrary Boundaries ................ 4		3.2.1. Delegation on Arbitrary Boundaries ................ 4
	3.2.2. Reusable Zones .................................... 5		3.2.2. Reusable Zones .................................... 5
	4. Specifications ................................................ 5		4. Specifications ................................................ 6
	4.1. The A6 Record Type ...................................... 5		4.1. The A6 Record Type ...................................... 6
	4.1.1. Format ............................................ 6		4.1.1. Format ............................................ 6
	4.1.2. Processing ........................................ 6		4.1.2. Processing ........................................ 6
	4.1.3. Textual Representation ............................ 7		4.1.3. Textual Representation ............................ 7
	4.1.4. Name Resolution Procedure ......................... 7		4.1.4. Name Resolution Procedure ......................... 7
	4.2. Zone Structure for Reverse Lookups ...................... 8		4.2. Zone Structure for Reverse Lookups ...................... 8
	5. Modifications to Existing Query Types ......................... 8		5. Modifications to Existing Query Types ......................... 8
	6. Usage Illustrations ........................................... 9		6. Usage Illustrations ........................................... 9
	6.1. A6 Record Chains ........................................ 9		6.1. A6 Record Chains ........................................ 9
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	renumbering we define the following extensions.		renumbering we define the following extensions.
	o A new resource record type, "A6", is defined to map a domain		o A new resource record type, "A6", is defined to map a domain
	name to an IPv6 address, with a provision for indirection for		name to an IPv6 address, with a provision for indirection for
	leading "prefix" bits.		leading "prefix" bits.
	o Existing queries that perform additional section processing to		o Existing queries that perform additional section processing to
	locate IPv4 addresses are redefined to do that processing for		locate IPv4 addresses are redefined to do that processing for
	both IPv4 and IPv6 addresses.		both IPv4 and IPv6 addresses.
	o A new domain, IP6.INT, is defined to support lookups based on		o A new domain, IP6.ARPA, is defined to support lookups based on
	IPv6 address.		IPv6 address.
	o A new prefix-delegation method is defined, relying on new DNS		o A new prefix-delegation method is defined, relying on new DNS
	features [BITLBL, DNAME].		features [BITLBL, DNAME].
	The changes are designed to be compatible with existing application		The changes are designed to be compatible with existing application
	programming interfaces. The existing support for IPv4 addresses is		programming interfaces. The existing support for IPv4 addresses is
	retained. Transition issues related to the coexistence of both IPv4		retained. Transition issues related to the coexistence of both IPv4
	and IPv6 addresses in DNS are discussed in [TRANS].		and IPv6 addresses in DNS are discussed in [TRANS].
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 33 ¶
	of IPv6 addresses which are formed.		of IPv6 addresses which are formed.
	An application looking up an IPv6 address will generally cause the		An application looking up an IPv6 address will generally cause the
	DNS resolver to access several A6 records, and multiple IPv6		DNS resolver to access several A6 records, and multiple IPv6
	addresses may be returned even if the queried name was the owner of		addresses may be returned even if the queried name was the owner of
	only one A6 record. The authenticity of the returned address(es)		only one A6 record. The authenticity of the returned address(es)
	cannot be directly verified by DNS Security [DNSSEC]. The A6		cannot be directly verified by DNS Security [DNSSEC]. The A6
	records which contributed to the address(es) may of course be		records which contributed to the address(es) may of course be
	verified if signed.		verified if signed.
			Implementers are reminded of the necessity to limit the amount of
			work a resolver will perform in response to a client request. This
			principle MUST be extended to also limit the generation of DNS
			requests in response to one name-to-address (or address-to-name)
			lookup request.
	3.2. Underlying Mechanisms for Reverse Lookups		3.2. Underlying Mechanisms for Reverse Lookups
	This section describes the new DNS features which this document		This section describes the new DNS features which this document
	exploits. This section is an overview, not a specification of those		exploits. This section is an overview, not a specification of those
	features. The reader is directed to the referenced documents for		features. The reader is directed to the referenced documents for
	more details on each.		more details on each.
	3.2.1. Delegation on Arbitrary Boundaries		3.2.1. Delegation on Arbitrary Boundaries
	This new scheme for reverse lookups relies on a new type of DNS		This new scheme for reverse lookups relies on a new type of DNS
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 27 ¶
	implicit count is equal to four times the number of hexadecimal		implicit count is equal to four times the number of hexadecimal
	digits.		digits.
	Consecutive bit-string labels are equivalent (up to the limit		Consecutive bit-string labels are equivalent (up to the limit
	imposed by the size of the bit count field) to a single bit-string		imposed by the size of the bit count field) to a single bit-string
	label containing all the bits of the consecutive labels in the		label containing all the bits of the consecutive labels in the
	proper order. As an example, either of the following domain names		proper order. As an example, either of the following domain names
	could be used in a QCLASS=IN, QTYPE=PTR query to find the name of		could be used in a QCLASS=IN, QTYPE=PTR query to find the name of
	the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.		the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
	\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.INT.		\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
	\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.INT.		\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
	3.2.2. Reusable Zones		3.2.2. Reusable Zones
	DNS address space delegation is implemented not by zone cuts and NS		DNS address space delegation is implemented not by zone cuts and NS
	records, but by a new analogue to the CNAME record, called the DNAME		records, but by a new analogue to the CNAME record, called the DNAME
	resource record [DNAME]. The DNAME record provides alternate naming		resource record [DNAME]. The DNAME record provides alternate naming
	to an entire subtree of the domain name space, rather than to a		to an entire subtree of the domain name space, rather than to a
	single node. It causes some suffix of a queried name to be		single node. It causes some suffix of a queried name to be
	substituted with a name from the DNAME record's RDATA.		substituted with a name from the DNAME record's RDATA.
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 12 ¶
	beginning at that name, discarding records which have invalid prefix		beginning at that name, discarding records which have invalid prefix
	lengths as defined in section 4.1.2.		lengths as defined in section 4.1.2.
	If some A6 queries fail and others succeed, a client might obtain a		If some A6 queries fail and others succeed, a client might obtain a
	non-empty but incomplete set of IPv6 addresses for a host. In many		non-empty but incomplete set of IPv6 addresses for a host. In many
	situations this may be acceptable. The completeness of a set of A6		situations this may be acceptable. The completeness of a set of A6
	records may always be determined by inspection.		records may always be determined by inspection.
	4.2. Zone Structure for Reverse Lookups		4.2. Zone Structure for Reverse Lookups
	Very little of the new scheme's data actually appears under IP6.INT;		Very little of the new scheme's data actually appears under
	only the first level of delegation needs to be under that domain.		IP6.ARPA; only the first level of delegation needs to be under that
	More levels of delegation could be placed under IP6.INT if some		domain. More levels of delegation could be placed under IP6.ARPA if
	top-level delegations were done via NS records instead of DNAME		some top-level delegations were done via NS records instead of DNAME
	records, but this would incur some cost in renumbering ease at the		records, but this would incur some cost in renumbering ease at the
	level of TLAs [AGGR]. Therefore, it is declared here that all		level of TLAs [AGGR]. Therefore, it is declared here that all
	address space delegations SHOULD be done by the DNAME mechanism		address space delegations SHOULD be done by the DNAME mechanism
	rather than NS.		rather than NS.
	In addition, since uniformity in deployment will simplify		In addition, since uniformity in deployment will simplify
	maintenance of address delegations, it is SUGGESTED that address and		maintenance of address delegations, it is SUGGESTED that address and
	prefix information be stored immediately below a DNS label "IP6".		prefix information be stored immediately below a DNS label "IP6".
	Stated another way, conformance with this suggestion would mean that		Stated another way, conformance with this suggestion would mean that
	"IP6" is the first label in the RDATA field of DNAME records which		"IP6" is the first label in the RDATA field of DNAME records which
	support IPv6 reverse lookups.		support IPv6 reverse lookups.
	When any "reserved" or "must be zero" bits are adjacent to a		When any "reserved" or "must be zero" bits are adjacent to a
	delegation boundary, the higher-level entity MUST retain those bits		delegation boundary, the higher-level entity MUST retain those bits
	in its own control and delegate only the bits over which the lower-		in its own control and delegate only the bits over which the lower-
	level entity has authority.		level entity has authority.
	To find the name of a node given its IPv6 address, a DNS client MUST		To find the name of a node given its IPv6 address, a DNS client MUST
	perform a query with QCLASS=IN, QTYPE=PTR on the name formed from		perform a query with QCLASS=IN, QTYPE=PTR on the name formed from
	the 128 bit address as one or more bit-string labels [BITLBL],		the 128 bit address as one or more bit-string labels [BITLBL],
	followed by the two standard labels "IP6.INT". If recursive service		followed by the two standard labels "IP6.ARPA". If recursive
	was not obtained from a server and the desired PTR record was not		service was not obtained from a server and the desired PTR record
	returned, the resolver MUST handle returned DNAME records as		was not returned, the resolver MUST handle returned DNAME records as
	specified in [DNAME], and NS records as specified in [DNSCF], and		specified in [DNAME], and NS records as specified in [DNSCF], and
	iterate.		iterate.
	5. Modifications to Existing Query Types		5. Modifications to Existing Query Types
	All existing query types that perform type A additional section		All existing query types that perform type A additional section
	processing, i.e. the name server (NS), mail exchange (MX), and		processing, i.e. the name server (NS), mail exchange (MX), and
	mailbox (MB) query types, and the experimental AFS data base (AFSDB)		mailbox (MB) query types, and the experimental AFS data base (AFSDB)
	and route through (RT) types, must be redefined to perform type A,		and route through (RT) types, must be redefined to perform type A,
	A6 and AAAA additional section processing, with type A having the		A6 and AAAA additional section processing, with type A having the
	skipping to change at page 13, line 27 ¶		skipping to change at page 13, line 29 ¶
	It is possible, but not necessarily recommended, for a zone		It is possible, but not necessarily recommended, for a zone
	maintainer to forego the renumbering support afforded by the		maintainer to forego the renumbering support afforded by the
	chaining of A6 records and to record entire IPv6 addresses within		chaining of A6 records and to record entire IPv6 addresses within
	one zone file.		one zone file.
	6.2. Reverse Mapping Zones		6.2. Reverse Mapping Zones
	Supposing that address space assignments in the TLAs with Format		Supposing that address space assignments in the TLAs with Format
	Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in		Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
	zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then		zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
	the IP6.INT zone would include		the IP6.ARPA zone would include
	$ORIGIN IP6.INT.		$ORIGIN IP6.ARPA.
	\[x234500/24] DNAME IP6.ALPHA-TLA.ORG.		\[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
	\[x267800/24] DNAME IP6.BRAVO-TLA.ORG.		\[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
	\[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.		\[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
	Eight trailing zero bits have been included in each TLA ID to		Eight trailing zero bits have been included in each TLA ID to
	reflect the eight reserved bits in the current aggregatable global		reflect the eight reserved bits in the current aggregatable global
	unicast addresses format [AGGR].		unicast addresses format [AGGR].
	6.2.1. The TLA level		6.2.1. The TLA level
	skipping to change at page 14, line 42 ¶		skipping to change at page 14, line 42 ¶
	could have been joined with the interface identifier. But if		could have been joined with the interface identifier. But if
	subnets are treated alike in both the A6 records and in the reverse		subnets are treated alike in both the A6 records and in the reverse
	zone, it will always be possible to keep the forward and reverse		zone, it will always be possible to keep the forward and reverse
	definition data for each prefix in one zone.		definition data for each prefix in one zone.
	6.3. Lookups		6.3. Lookups
	A DNS resolver looking for a hostname for the address		A DNS resolver looking for a hostname for the address
	2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the		2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
	DNAME records shown above and would form new queries. Assuming that		DNAME records shown above and would form new queries. Assuming that
	it began the process knowing servers for IP6.INT, but that no server		it began the process knowing servers for IP6.ARPA, but that no
	it consulted provided recursion and none had other useful additional		server it consulted provided recursion and none had other useful
	information cached, the sequence of queried names and responses		additional information cached, the sequence of queried names and
	would be (all with QCLASS=IN, QTYPE=PTR):		responses would be (all with QCLASS=IN, QTYPE=PTR):
	To a server for IP6.INT:		To a server for IP6.ARPA:
	QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT.		QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
	Answer:		Answer:
	\[x234500/24].IP6.INT. DNAME IP6.ALPHA-TLA.ORG.		\[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
	To a server for IP6.ALPHA-TLA.ORG:		To a server for IP6.ALPHA-TLA.ORG:
	QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.		QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
	Answer:		Answer:
	\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.		\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
	To a server for IP6.C.NET.:		To a server for IP6.C.NET.:
	QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.		QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
	skipping to change at page 18, line 9 ¶		skipping to change at page 18, line 9 ¶
	by a sequence of nibbles separated by dots with the suffix		by a sequence of nibbles separated by dots with the suffix
	".IP6.INT". The sequence of nibbles is encoded in reverse order,		".IP6.INT". The sequence of nibbles is encoded in reverse order,
	i.e. the low-order nibble is encoded first, followed by the next		i.e. the low-order nibble is encoded first, followed by the next
	low-order nibble and so on. Each nibble is represented by a		low-order nibble and so on. Each nibble is represented by a
	hexadecimal digit. For example, a name for the address		hexadecimal digit. For example, a name for the address
	2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in		2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in
	section 6.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-		section 6.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
	8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."		8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
	Implementations conforming to this specification will perform a		Implementations conforming to this specification will perform a
	lookup of a binary label in IP6.INT as specified in Section 3.2. It		lookup of a binary label in IP6.ARPA as specified in Section 3.2.
	is RECOMMENDED that for a transition period implementations first		It is RECOMMENDED that for a transition period implementations first
	lookup the binary label in IP6.INT and if this fails try to lookup		lookup the binary label in IP6.ARPA and if this fails try to lookup
	the 'nibble' label in IP6.INT.		the 'nibble' label in IP6.INT.
	8. Security Considerations		8. Security Considerations
	The signing authority [DNSSEC] for the A6 records which determine an		The signing authority [DNSSEC] for the A6 records which determine an
	IPv6 address is distributed among several entities, reflecting the		IPv6 address is distributed among several entities, reflecting the
	delegation path of the address space which that address occupies.		delegation path of the address space which that address occupies.
	DNS Security is fully applicable to bit-string labels and DNAME		DNS Security is fully applicable to bit-string labels and DNAME
	records. And just as in IPv4, verification of name-to-address		records. And just as in IPv4, verification of name-to-address
	mappings is logically independent of verification of address-to-name		mappings is logically independent of verification of address-to-name
	skipping to change at page 19, line 42 ¶		skipping to change at page 19, line 42 ¶
	1900, February 1996.		1900, February 1996.
	Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:		Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
	Why would I want it and what is it anyway?", RFC 2071, January		Why would I want it and what is it anyway?", RFC 2071, January
	1997.		1997.
	Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address		Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
	Behaviour Today", RFC 2101, February 1997.		Behaviour Today", RFC 2101, February 1997.
	[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for		[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
	IPv6 Hosts and Routers", RFC 1933, April 1996. [TSIG] Vixie,		IPv6 Hosts and Routers", RFC 1933, April 1996.
	P., Gudmundsson, O., Eastlake, D. 3rd and B. Wellington, "Secret
	Key Transaction Authentication for DNS (TSIG)", work in		[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
	progress.		Wellington, "Secret Key Transaction Authentication for DNS
			(TSIG)", work in progress.
	12. Authors' Addresses		12. Authors' Addresses
	Matt Crawford Christian Huitema Susan Thomson		Matt Crawford Christian Huitema Susan Thomson
	Fermilab Telcordia Telcordia		Fermilab Telcordia Telcordia
	MS 368 MCC 1J236B MCC 1C259B		MS 368 MCC 1J236B MCC 1C259B
	PO Box 500 445 South Street 445 South Street		PO Box 500 445 South Street 445 South Street
	Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960		Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960
	USA USA USA		USA USA USA
End of changes. 18 change blocks.
	34 lines changed or deleted		41 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/