< draft-ietf-dnsext-apl-rr-01.txt		draft-ietf-dnsext-apl-rr-02.txt >
	INTERNET-DRAFT Peter Koch		A new Request for Comments is now available in online RFC libraries.
	Expires: December 2000 Universitaet Bielefeld
	Updates: RFC 1035 June 2000
	A DNS RR Type for Lists of Address Prefixes (APL RR)
	draft-ietf-dnsext-apl-rr-01.txt
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	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."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Comments should be sent to the author or the DNSEXT WG mailing list
	<namedroppers@internic.net>.
	Abstract
	The Domain Name System is primarily used to translate domain names
	into IPv4 addresses using A RRs. Several approaches exist to describe
	networks or address ranges. This document specifies a new DNS RR type
	"APL" for address prefix lists.
	1. Conventions used in this document
	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 [RFC2119].
	Domain names herein are for explanatory purposes only and should not
	be expected to lead to useful information in real life [RFC2606].
	2. Background
	The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
	associate addresses and other Internet infrastructure elements with
	hierarchically built domain names. Various types of resource records
	have been defined, especially those for IPv4 and IPv6 [RFCxxxx]
	addresses. In [RFC1101] a method is described to publish information
	about the address space allocated to an organisation. In older BIND
	versions, a weak form of controlling access to zone data was
	implemented using TXT RRs describing address ranges.
	This document specifies a new RR type for address prefix lists.
	3. APL RR Type
	An APL record has the DNS type of "APL" [draft, IANA: not yet applied
	for] and a numeric value of [draft, IANA:to be assigned]. The APL RR
	is defined in the IN class only. APL RRs cause no additional section
	processing.
	4. APL RDATA format
	The RDATA section consists of zero or more strings (<apstring>) of
	the form
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	| ADDRESSFAMILY |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	| PREFIX | N | AFDLENGTH |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	/ AFDPART /
	| |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
	(see IANA Considerations)
	PREFIX 8 bit unsigned binary coded prefix length.
	Upper and lower bounds and interpretation of
	this value are address family specific.
	N negation flag, indicates the presence of the
	"!" character in the textual format. It has
	the value "1" if the "!" was given, "0" else.
	AFDLENGTH length in octets of the following address
	family dependent part (7 bit unsigned).
	AFDPART address family dependent part. See below.
	This document defines the AFDPARTs for address families 1 (IPv4) and
	2 (IPv6). Future revisions may deal with additional address
	families.
	4.1. AFDPART for IPv4
	The encoding of an IPv4 address (address family 1) follows the
	encoding specified for the A RR by [RFC1035], section 3.4.1.
	PREFIX specifies the number of bits of the IPv4 address starting at
	the most significant bit. Legal values range from 0 to 32.
	Trailing zero octets do not bear any information (e.g. there is no
	semantic difference between 10.0.0.0/16 and 10/16) in an address
	prefix, so the shortest possible AFDLENGTH can be used to encode it.
	However, for DNSSEC [RFC2535] a single wire encoding must be used by
	all. Therefore the sender MUST NOT include trailing zero octets in
	the AFDPART regardless of the value of PREFIX. This includes cases in
	which AFDLENGTH times 8 results in a value less than PREFIX. The
	AFDPART is padded with zero bits to match a full octet boundary.
	An IPv4 AFDPART has a variable length of 0 to 4 octets.
	4.2. AFDPART for IPv6
	The 128 bit IPv6 address (address family 2) is encoded in network
	byte order (high-order byte first).
	PREFIX specifies the number of bits of the IPv6 address starting at
	the most significant bit. Legal values range from 0 to 128.
	With the same reasoning as in 4.1 above, the sender MUST NOT include
	trailing zero octets in the AFDPART regardless of the value of
	PREFIX. This includes cases in which AFDLENGTH times 8 results in a
	value less than PREFIX. The AFDPART is padded with zero bits to
	match a full octet boundary.
	An IPv6 AFDPART has a variable length of 0 to 16 octets.
	5. Zone File Syntax
	The textual representation of an APL RR in a DNS zone file is as
	follows:
	<owner> IN <TTL> APL {[!]afi:address/prefix}*
	The data consists of zero or more strings of the address family
	indicator <afi>, immediately followed by a colon ":", an address,
	immediately followed by the "/" character, immediately followed by a
	decimal numeric value for the prefix length. Any such string may be
	preceded by a "!" character. The strings are separated by whitespace.
	The <afi> is the decimal numeric value of that particular address
	family.
	5.1. Textual Representation of IPv4 Addresses
	An IPv4 address in the <address> part of an <apstring> is in dotted
	quad notation, just as in an A RR. The <prefix> has values from the
	interval 0..32 (decimal).
	5.2. Textual Representation of IPv6 Addresses
	The representation of an IPv6 address in the <address> part of an
	<apstring> follows [RFC2373], section 2.2. Legal values for <prefix>
	are from the interval 0..128 (decimal).
	6. APL RR usage
	An APL RR with empty RDATA is valid and implements an empty list.
	Multiple occurrences of the same <apstring> in a single APL RR are
	allowed and MUST NOT be merged by a DNS server or resolver.
	<apstrings> MUST be kept in order and MUST NOT be rearranged or
	aggregated.
	A single APL RR may contain <apstrings> belonging to different
	address families. The maximum number of <apstrings> is upper bounded
	by the available RDATA space.
	RRSets consisting of more than one APL RR are legal but the
	interpretation is left to the particular application.
	7. Applicability Statement
	The APL RR defines a framework without specifying any particular
	meaning for the list of prefixes. It is expected that APL RRs will
	be used in different application scenarios which have to be
	documented separately. Those scenarios may be distinguished by
	characteristic prefixes placed in front of the DNS owner name.
	An APL application specification MUST include information on
	o the characteristic prefix, if any
	o how to interpret APL RRSets consisting of more than one RR
	o how to interpret an empty APL RR
	o which address families are expected to appear in the APL RRs for
	that application
	o how to deal with APL RR list elements which belong to other
	address families, including those not yet defined
	o the exact semantics of list elements negated by the "!" character
	Possible applications include the publication of address ranges
	similar to [RFC1101], description of zones built following [RFC2317]
	and in-band access control to limit general access or zone transfer
	(AXFR) availability for zone data held in DNS servers.
	The specification of particular application scenarios is out of the
	scope of this document.
	8. Examples
	The following examples only illustrate some of the possible usages
	outlined in the previous section. None of those applications are
	hereby specified nor is it implied that any particular APL RR based
	application does exist now or will exist in the future.
	; RFC 1101-like announcement of address ranges for foo.example
	foo.example APL 1:192.168.32.0/21 !1:192.168.38.0/28
	; CIDR blocks covered by classless delegation
	42.168.192.IN-ADDR.ARPA APL ( 1:192.168.42.0/26 1:192.168.42.64/26
	1:192.168.42.128/25 )
	; Zone transfer restriction
	_axfr.sbo.example APL 1:127.0.0.1/32 1:172.16.64.0/22
	; List of address ranges for multicast
	multicast.example APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
	Note that since trailing zeroes are ignored in the first APL RR the
	AFDLENGTH of both <apstrings> is three.
	9. Security Considerations
	Any information obtained from the DNS should be regarded as unsafe
	unless techniques specified in [RFC2535] or [RFC2845] were used. The
	definition of a new RR type does not introduce security problems into
	the DNS, but usage of information made available by APL RRs may
	compromise security. This includes disclosure of network topology
	information and in particular the use of APL RRs to construct access
	control lists.
	10. IANA Considerations
	This section is to be interpreted as following [RFC2434].
	This document does not define any new namespaces. It uses the 16 bit
	identifiers for address families maintained by IANA in
	ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers.
	IANA is asked to assign a numeric RR type value for APL.
	11. Acknowledgements
	The author would like to thank Mark Andrews for his review and
	constructive comments.
	12. References
	[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
	RFC 1034, STD 13, November 1987
	[RFC1035] Mockapetris,P., "Domain Names - Implementation and
	Specification", RFC 1035, STD 13, November 1987
	[RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other		RFC 3123
	Types", RFC 1101, April 1989
	[RFCxxxx] Crawford,M., Huitema,C., Thomson,S., "DNS Extensions to		Title: A DNS RR Type for Lists of Address Prefixes
	Support IPv6 Address Aggregation and Renumbering", work in		(APL RR)
	progress		Author(s): P. Koch
			Status: Experimental
			Date: June 2001
			Mailbox: pk@TechFak.Uni-Bielefeld.DE
			Pages: 8
			Characters: 14648
			Updates/Obsoletes/SeeAlso: None
	[RFC2119] Bradner,S., "Key words for use in RFCs to Indicate		I-D Tag: draft-ietf-dnsext-apl-rr-02.txt
	Requirement Levels", RFC 2119, BCP 14, March 1997
	[RFC2181] Elz,R., Bush,R., "Clarifications to the DNS		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3123.txt
	Specification", RFC 2181, July 1997
	[RFC2317] Eidnes,H., de Groot,G., Vixie,P., "Classless IN-ADDR.ARPA		The Domain Name System (DNS) is primarily used to translate domain
	delegation", RFC 2317, March 1998		names into IPv4 addresses using A RRs (Resource Records). Several
			approaches exist to describe networks or address ranges.
			This document specifies a new DNS RR type "APL" for address prefix
			lists.
	[RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing		This document is a product of the DNS Extensions Working Group of the
	Architecture", RFC 2373, July 1998		IETF.
	[RFC2434] Narten,T., Alvestrand,H., "Guidelines for Writing an IANA		This memo defines an Experimental Protocol for the Internet community.
	Considerations Section in RFCs", RFC 2434, BCP 26, October		It does not specify an Internet standard of any kind. Discussion and
	1998		suggestions for improvement are requested. Distribution of this memo
			is unlimited.
	[RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC		This announcement is sent to the IETF list and the RFC-DIST list.
	2535, March 1999		Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	RFC 2606, BCP 32, June 1999		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	[RFC2845] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B.,		To: rfc-info@RFC-EDITOR.ORG
	"Secret Key Transaction Authentication for DNS (TSIG)",		Subject: getting rfcs
	RFC 2845, May 2000
	13. Author's Address		help: ways_to_get_rfcs
	Peter Koch		Requests for special distribution should be addressed to either the
	Universitaet Bielefeld		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	Technische Fakultaet		specifically noted otherwise on the RFC itself, all RFCs are for
	D-33594 Bielefeld		unlimited distribution.echo
	Germany		Submissions for Requests for Comments should be sent to
	+49 521 106 2902		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
	<pk@TechFak.Uni-Bielefeld.DE>		Authors, for further information.
End of changes. 13 change blocks.
	284 lines changed or deleted		35 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/