draft-ietf-ipngwg-icmp-name-lookups-07.txt		draft-ietf-ipngwg-icmp-name-lookups-08.txt
	IPng Working Group Matt Crawford		IPng Working Group Matt Crawford
	Internet Draft Fermilab		Internet Draft Fermilab
	August 28, 2000		July 20, 2001
	IPv6 Node Information Queries		IPv6 Node Information Queries
	<draft-ietf-ipngwg-icmp-name-lookups-07.txt>		<draft-ietf-ipngwg-icmp-name-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 RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. Internet-Drafts are
	documents of the Internet Engineering Task Force (IETF), its areas,		working documents of the Internet Engineering Task Force (IETF), its
	and its working groups. Note that other groups may also distribute		areas, and its working groups. Note that other groups may also
	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."
	To view the list Internet-Draft Shadow Directories, see		To view the list Internet-Draft Shadow Directories, see
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document describes a protocol for asking an IPv6 node to supply		This document describes a protocol for asking an IPv6 node to supply
	certain network information, such as its fully-qualified domain		certain network information, such as its hostname or fully-qualified
	name. IPv6 implementation experience has shown that direct queries		domain name. IPv6 implementation experience has shown that direct
	for a DNS name are useful, and a direct query mechanism for other		queries for a hostname are useful, and a direct query mechanism for
	information has been requested.		other information has been found useful in serverless environments
			and for debugging.
	1. Terminology		1. Introduction
			This docment specifies a mechanism for discovering information about
			names and addresses. (The mechanism is extensible to deal with
			other information). In the global internet, the Domain Name System
			[1034, 1035] is the authoritative source of such information and
			this specifcation is not intended to supplant or supersede it. And
			in fact, in a well-supported network the names and addresses dealt
			with by this mechanism will be the same ones, and with the same
			relationships, as those listed in the DNS.
			This new Node Information protocol does provide facilities which are
			not found in the DNS - for example discovering relationships between
			addresses without reference to names. And the functions that do
			overlap with the DNS may be useful in serverless environments, for
			debugging, or in regard to link-local and site-local addresses
			[2373] which often will not be listed in the DNS.
			2. Terminology
	A "Node Information (or NI) Query" message is sent by a "Querier"		A "Node Information (or NI) Query" message is sent by a "Querier"
	node to a "Responder" node in an ICMPv6 packet addressed to the		node to a "Responder" node in an ICMPv6 packet addressed to the
	"Queried Address." The Query concerns a "Subject Address" which may		"Queried Address." The Query concerns a "Subject Address" which may
	differ from the Queried Address, or a "Subject Name". The Responder		differ from the Queried Address, or a "Subject Name". The Responder
	sends a "Node Information Reply" to the Querier, containing		sends a "Node Information Reply" to the Querier, containing
	information associated with the node at the Queries address. A node		information associated with the node at the Queries address. A node
	receiving a NI Query will be termed a Responder even if it does not		receiving a NI Query will be termed a Responder even if it does not
	send a Reply.		send a Reply.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [2119].		document are to be interpreted as described in [2119].
	Packet fields marked "unused" must be zero on transmission and,		Packet fields marked "unused" must be zero on transmission and,
	aside from inclusion in checksums or message integrity checks,		aside from inclusion in checksums or message integrity checks,
	ignored on reception.		ignored on reception.
	2. Node Information Messages		3. Node Information Messages
	Two types of Node Information messages, the NI Query and the NI		Two types of Node Information messages, the NI Query and the NI
	Reply, are carried in ICMPv6 [2463] packets. They have the same		Reply, are carried in ICMPv6 [2463] packets. They have the same
	format.		format.
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 2, line 42		skipping to change at page 3, line 14
	Fields:		Fields:
	Type 139 - NI Query.		Type 139 - NI Query.
	140 - NI Reply.		140 - NI Reply.
	Code For NI Query:		Code For NI Query:
	0 Indicates that the Data field contains an IPv6		0 Indicates that the Data field contains an IPv6
	address which is the Subject of this Query.		address which is the Subject of this Query.
	1 Indicates that the Data field contains a domain name		1 Indicates that the Data field contains a name which
	which is the Subject of this Query, or is empty, as		is the Subject of this Query, or is empty, as in the
	in the case of a NOOP or Supported Qtypes query.		case of a NOOP or Supported Qtypes query.
	2 Indicates that the Data field contains an IPv4		2 Indicates that the Data field contains an IPv4
	address which is the Subject of this Query.		address which is the Subject of this Query.
	For NI Reply:		For NI Reply:
	0 Indicates a successful reply. The Reply Data field		0 Indicates a successful reply. The Reply Data field
	may or may not be empty.		may or may not be empty.
	1 Indicates that the Responder refuses to supply the		1 Indicates that the Responder refuses to supply the
	answer. The Reply Data field will be empty.		answer. The Reply Data field will be empty.
	2 Indicates that the Qtype of the Query is unknown to		2 Indicates that the Qtype of the Query is unknown to
	the Responder. The Reply Data field will be empty.		the Responder. The Reply Data field will be empty.
	Checksum The ICMPv6 checksum.		Checksum The ICMPv6 checksum.
	Qtype A 16-bit field which designates the type if information		Qtype A 16-bit field which designates the type of information
	requested in a Query or supplied in a Reply. Its value		requested in a Query or supplied in a Reply. Its value
	in a Reply is always copied from the corresponding Query		in a Reply is always copied from the corresponding Query
	by the Responder. Five values of Qtype are specified in		by the Responder. Five values of Qtype are specified in
	this document.		this document.
	Flags Qtype-specific flags which may be defined for certain		Flags Qtype-specific flags which may be defined for certain
	Query types and their Replies. Flags not defined for a		Query types and their Replies. Flags not defined for a
	given Qtype must be zero on transmission and ignored on		given Qtype must be zero on transmission and ignored on
	reception, and must not be copied from a Query to a		reception, and must not be copied from a Query to a
	Reply unless so specified in the definition of the		Reply unless so specified in the definition of the
	skipping to change at page 3, line 44		skipping to change at page 4, line 14
	Data In a Query, the Subject Address or Name. In a Reply,		Data In a Query, the Subject Address or Name. In a Reply,
	Qtype-specific data present only when the ICMPv6 Code		Qtype-specific data present only when the ICMPv6 Code
	field is zero. The length of the Data may be inferred		field is zero. The length of the Data may be inferred
	from the IPv6 header's Payload Length field [2460], the		from the IPv6 header's Payload Length field [2460], the
	length of the fixed portion of the NI packet and the		length of the fixed portion of the NI packet and the
	lengths of the ICMPv6 header and intervening extension		lengths of the ICMPv6 header and intervening extension
	headers.		headers.
	Note that the type of information present in the Data field of a		Note that the type of information present in the Data field of a
	Query is inferred from the ICMP Code, while the type of information,		Query is declared by the ICMP Code, while the type of information,
	if any, in the Data field of a Reply is inferred from the Qtype.		if any, in the Data field of a Reply is determined by the Qtype.
	When the Subject of a Query is a name, the name MUST be in DNS wire		When the Subject of a Query is a name, the name MUST be in DNS wire
	format [1035]. The name may be either a fully-qualified domain		format [1035]. The name may be either a fully-qualified domain
	name, including the terminating zero-length label, or a single DNS		name, including the terminating zero-length label, or a single DNS
	label followed by two zero-length labels. Since a Query contains at		label followed by two zero-length labels. Since a Query contains at
	most one DNS name, DNS compression will not be used.		most one name, DNS name compression MUST NOT be used.
	3. Message Processing		4. Message Processing
	The Querier constructs an ICMP NI Query and sends it to the address		The Querier constructs an ICMP NI Query and sends it to the address
	from which information is wanted. When the Subject of the Query is		from which information is wanted. When the Subject of the Query is
	an IPv6 address, that address will normally be used as the IPv6		an IPv6 address, that address will normally be used as the IPv6
	destination address of the Query, but need not be if the Querier has		destination address of the Query, but need not be if the Querier has
	useful a priori information about the addresses of the target node.		useful a priori information about the addresses of the target node.
	An NI Query may also be sent to a multicast address of link-local		An NI Query may also be sent to a multicast address of link-local
	scope [2373].		scope [2373].
	When the Subject is a domain name, either fully-qualified or		When the Subject is a name, either fully-qualified or single-
	single-component, and the Querier does not have a unicast address		component, and the Querier does not have a unicast address for the
	for the target node, the query MUST be sent to a link-scope		target node, the query MUST be sent to a link-scope multicast
	multicast address formed in the following way. The Subject Name is		address formed in the following way. The Subject Name is converted
	converted to canonical form, as defined by DNS Security [2535],		to the canonical form defined by DNS Security [2535], which is
	which is uncompressed with all alphabetic characters in lower case.		uncompressed with all alphabetic characters in lower case. (If
	(If additional DNS label types for host names are defined, the rules		additional DNS label types for host names are created, the rules for
	for canonicalizing those labels will be found in the defining		canonicalizing those labels will be found in their defining
	specification.) Compute the MD5 hash [1321] of the first label of		specification.) Compute the MD5 hash [1321] of the first label of
	the Subject Name -- the portion beginning with the first one-octet		the Subject Name -- the portion beginning with the first one-octet
	length field and up to, but excluding, any subsequent length field.		length field and up to, but excluding, any subsequent length field.
	Append the first 32 bits of that 128-bit hash to the prefix		Append the first 32 bits of that 128-bit hash to the prefix
	FF02:0:0:0:0:2::/96. The resulting multicast address will be termed		FF02:0:0:0:0:2::/96. The resulting multicast address will be termed
	the "NI Group Address" for the name.		the "NI Group Address" for the name.
	The Nonce should be a random or good pseudo-random value to foil		The Nonce should be a random or good pseudo-random value to foil
	spoofed replies. An implementation which allows multiple		spoofed replies. An implementation which allows multiple
	independent processes to send NI queries MAY use the Nonce value to		independent processes to send NI queries MAY use the Nonce value to
	skipping to change at page 5, line 15		skipping to change at page 5, line 34
	matches the Subject. All name matching is done in a case-		matches the Subject. All name matching is done in a case-
	independent manner consistent with DNSSEC name canonicalization		independent manner consistent with DNSSEC name canonicalization
	[2535].		[2535].
	Next, if Qtype is unknown to the Responder, it must return a NI		Next, if Qtype is unknown to the Responder, it must return a NI
	Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should		Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should
	rate-limit such replies as it would ICMPv6 error replies [2463,		rate-limit such replies as it would ICMPv6 error replies [2463,
	2.4(f)].		2.4(f)].
	Next, the Responder should decide whether to refuse an answer, based		Next, the Responder should decide whether to refuse an answer, based
	on local policy not addressed in this document. If an answer is		on local policy. (See "Security Considerations" for recommended
	refused, the Responder may send a NI Reply with ICMPv6 Code = 1 and		default behavior.) If an answer is refused, the Responder may send
	no Reply Data. Again, the Responder should rate-limit such replies		a NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the
	as it would ICMPv6 error replies [2463, 2.4(f)].		Responder should rate-limit such replies as it would ICMPv6 error
			replies [2463, 2.4(f)].
	Finally, if the Qtype is known and the response is allowed by local		Finally, if the Qtype is known and the response is allowed by local
	policy, the Responder must fill in the Flags and Reply Data of the		policy, the Responder must fill in the Flags and Reply Data of the
	NI Reply in accordance with the definition of the Qtype and transmit		NI Reply in accordance with the definition of the Qtype and transmit
	the NI Reply with an ICMPv6 source address equal to the Queried		the NI Reply with an ICMPv6 source address equal to the Queried
	Address, unless that address was an anycast or a multicast address.		Address, unless that address was an anycast or a multicast address.
	If the Queried Address was anycast or multicast, the source address		If the Queried Address was anycast or multicast, the source address
	for the Reply SHOULD be one belonging to the interface on which the		for the Reply SHOULD be one belonging to the interface on which the
	Query was received.		Query was received.
	If the Query was sent to an anycast or multicast address,		If the Query was sent to an anycast or multicast address,
	transmission of the Reply MUST be delayed by a random interval		transmission of the Reply MUST be delayed by a random interval
	between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor		between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor
	Discovery [2461].		Discovery [2461].
	4. Defined Qtypes		5. Defined Qtypes
	The following five Qtypes are defined. The first four (number 0 to		The following five Qtypes are defined. The first four (number 0 to
	3) MUST be supported by any implementation of this protocol. The		3) MUST be supported by any implementation of this protocol. The
	last one SHOULD be supported by any implementation on an IPv4/IPv6		last one SHOULD be supported by any implementation on an IPv4/IPv6
	dual-stack node and MAY be supported on an IPv6-only node.		dual-stack node and MAY be supported on an IPv6-only node.
	0 NOOP.		0 NOOP.
	1 Supported Qtypes.		1 Supported Qtypes.
	2 DNS Name.		2 Node Name.
	3 Node Addresses.		3 Node Addresses.
	4 IPv4 Addresses.		4 IPv4 Addresses.
	4.1. NOOP		5.1. NOOP
	This NI type has no defined flags and never has a Data field. A		This NI type has no defined flags and never has a Data field. A
	Reply to a NI NOOP Query tells the Querier that a node with the		Reply to a NI NOOP Query tells the Querier that a node with the
	Queried Address is up and reachable, implements the Node Information		Queried Address is up and reachable, implements the Node Information
	protocol, and incidentally happens to reveal whether the Queried		protocol, and incidentally happens to reveal whether the Queried
	Address was an anycast address. On transmission, the ICMPv6 Code in		Address was an anycast address. On transmission, the ICMPv6 Code in
	a NOOP Query must be set to 1 and the Code in a NOOP Reply must be		a NOOP Query must be set to 1 and the Code in a NOOP Reply must be
	0. On reception of a NOOP Query or Reply, the Code must be ignored.		0. On reception of a NOOP Query or Reply, the Code must be ignored.
	4.2. Supported Qtypes		5.2. Supported Qtypes
	This Query contains no Data field. The Reply Data is a bit-vector		This Query contains no Data field. The Reply Data is a bit-vector
	showing which Qtypes are supported by the Responder. The Reply Data		showing which Qtypes are supported by the Responder. The Reply Data
	has two variant forms: uncompressed and compressed. The		has two variant forms: uncompressed and compressed. The
	uncompressed Data format is one or more complete 32-bit words, each		uncompressed Data format is one or more complete 32-bit words, each
	word a bitmask with the low-order bit in each word corresponding to		word a bitmask with the low-order bit in each word corresponding to
	the lowest numbered Qtype in a group of 32. The first word		the lowest numbered Qtype in a group of 32. The first word
	describes the Responder's support for Qtypes 0 to 31, the second		describes the Responder's support for Qtypes 0 to 31, the second
	word 32 to 63, and so on.		word 32 to 63, and so on.
	skipping to change at page 7, line 37		skipping to change at page 8, line 9
	In a Query, a C-flag set to 1 indicates that the Querier will accept		In a Query, a C-flag set to 1 indicates that the Querier will accept
	the compressed form of the Reply Data. In a Reply, a C-flag set to		the compressed form of the Reply Data. In a Reply, a C-flag set to
	1 indicates that the Reply Data is compressed. The compressed form		1 indicates that the Reply Data is compressed. The compressed form
	MAY be used in a Reply only if the Query had the C-flag set.		MAY be used in a Reply only if the Query had the C-flag set.
	Implementations of this specification SHOULD support the compressed		Implementations of this specification SHOULD support the compressed
	form and if they do, SHOULD set the C-flag in all Supported Qtypes		form and if they do, SHOULD set the C-flag in all Supported Qtypes
	Queries and SHOULD use the compressed form in Supported Qtypes		Queries and SHOULD use the compressed form in Supported Qtypes
	Replies (when allowed by the C-flag in the query) if doing so would		Replies (when allowed by the C-flag in the query) if doing so would
	avoid fragmentation or save significant space in the Reply.		avoid fragmentation or save significant space in the Reply.
	4.3. DNS Name		5.3. Node Name
	The NI DNS Name Query requests the fully-qualified or single-		The NI Node Name Query requests the fully-qualified or single-
	component name corresponding to the Subject Address or Name. The		component name corresponding to the Subject Address or Name. The
	Reply Data has the following format.		Reply Data has the following format.
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TTL |		| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DNS Names ... |		| Node Names ... |
	+ +		+ +
	/ /		/ /
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TTL The number of seconds that the name may be cached. For		TTL The number of seconds that the name may be cached. For
	compatibility with DNS [1035], this is a 32-bit signed,		compatibility with DNS [1035], this is a 32-bit signed,
	2's-complement number, which must not be negative.		2's-complement number, which must not be negative.
	DNS Names The fully-qualified or single-component name or names of		Node Names The fully-qualified or single-component name or names of
	the Responder which correspond(s) to the Subject Address		the Responder which correspond(s) to the Subject Address
	or Name, in DNS wire format [1035]. Each name MUST be		or Name, in DNS wire format [1035]. Each name MUST be
	fully-qualified if the responder knows the domain		fully-qualified if the responder knows the domain
	suffix, and otherwise be a single DNS label followed by		suffix, and otherwise be a single DNS label followed by
	two zero-length labels.		two zero-length labels.
	When multiple DNS names are returned, DNS name		When multiple node names are returned and more than one
	compression [1035] SHOULD be used, and the offsets are		of them is fully-qualified, DNS name compression [1035]
	counted from the first octet of the Data field. An		SHOULD be used, and the offsets are counted from the
	offset of 4, for example, will point to the beginning of		first octet of the Data field. An offset of 4, for
	the first name.		example, will point to the beginning of the first name.
	The Responder must fill in the TTL field of the Reply with a		The Responder must fill in the TTL field of the Reply with a
	meaningful value if possible. That value should be one of the		meaningful value if possible. That value should be one of the
	following.		following.
	The remaining lifetime of a DHCP lease on the Subject Address;		The remaining lifetime of a DHCP lease on the Subject Address;
	The remaining Valid Lifetime of a prefix from which the Subject		The remaining Valid Lifetime of a prefix from which the Subject
	Address was derived through Stateless Autoconfiguration [2461,		Address was derived through Stateless Autoconfiguration [2461,
	2462];		2462];
	The TTL of an existing AAAA or A6 record which associates the		The TTL of an existing AAAA or A6 record which associates the
	Subject Address with the DNS Name being returned.		Subject Address with the Node Name being returned.
	If the Responder returns multiple names but considers one name to be		If the Responder returns multiple names but considers one name to be
	official or canonical, that name MUST be placed immediately after		official or canonical, that name MUST be placed immediately after
	the TTL.		the TTL.
	Only one TTL is included in the reply. If the Responder considers		Only one TTL is included in the reply. If the Responder considers
	different names to be cacheable for different times, the TTL field		different names to be cacheable for different times, the TTL field
	must be set no larger than the minimum of those times.		must be set no larger than the minimum of those times. In any case,
			the TTL returned MUST be no greater than 2^31-1, even if the
			responding node's conception of the lifetime is longer (or
			infinite).
	If the Responder does not know its name at all it MUST send a Reply		If the Responder does not know its name at all it MUST send a Reply
	with TTL=0 and no DNS Names. The Querier will be able to determine		with TTL=0 and no Node Names (or a Reply with Code=1 indicating
	from the packet length that the Data field contains only a TTL.		refusal to answer). The Querier will be able to determine from the
			packet length that the Data field contains no names.
	One Flag bit is defined, in the Reply only.		One Flag bit is defined, in the Reply only.
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Qtype=2 | unused |T|		| Qtype=2 | unused |T|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	A T-flag set to 1 in a NI DNS Name Reply indicates that the TTL		A T-flag set to 1 in a NI Node Name Reply indicates that the TTL
	field contains a meaningful value. If the T-flag is 0, the TTL		field contains a meaningful value. If the T-flag is 0, the TTL
	SHOULD be set to zero by the Responder and MUST be ignored by the		SHOULD be set to zero by the Responder and MUST be ignored by the
	Querier.		Querier.
	If a name rather than an address was the Subject of the Query, the		If a name rather than an address was the Subject of the Query, the
	T-flag MUST be zero and the TTL SHOULD be zero.		T-flag MUST be zero and the TTL SHOULD be zero.
	The information in a NI DNS Name Reply with T-flag 1 may be cached		The information in a NI Node Name Reply with T-flag 1 may be cached
	and used for the period indicated by that TTL. If a Reply has no		and used for the period indicated by that TTL. If a Reply has no
	TTL (T-flag 0), the information in that Reply must not be used more		TTL (T-flag 0), the information in that Reply must not be used more
	than once. If the Query was sent by a DNS server on behalf of a DNS		than once. If the Query was sent by a DNS server on behalf of a DNS
	client, the result may be returned to that client as a DNS response		client, the result may be returned to that client as a DNS response
	with TTL zero. However, if the server has the matching AAAA record,		with TTL zero. However, if the server has the matching AAAA record,
	either in cache or in an authoritative zone, then the TTL of that		either in cache or in an authoritative zone, then the TTL of that
	record may be used as the missing TTL of the NI DNS Name Reply and		record may be used as the missing TTL of the NI Node Name Reply and
	the information in the reply may be cached and used for that period.		the information in the reply may be cached and used for that period.
	It would be an implementation choice for a server to perform a DNS		It would be an implementation choice for a server to perform a DNS
	query for the AAAA or A6 record that matches a received NI DNS Name		query for the AAAA or A6 records that match a received NI Node Name
	Reply. This might be done to obtain a TTL to make the Reply		Reply. This might be done to obtain a TTL to make the Reply
	cacheable or in anticipation of such a AAAA query from the client		cacheable or in anticipation of such a DNS query from the client
	that caused the DNS Name Query.		that caused the Node Name Query.
	4.3.1. Discussion		5.3.1. Discussion
	Because a node can only answer a DNS Name Request when it is up and		Because a node can only answer a Node Name Request when it is up and
	reachable, it may be useful to create a proxy responder for a group		reachable, it may be useful to create a proxy responder for a group
	of nodes, for example a subnet or a site. Such a mechanism is not		of nodes, for example a subnet or a site. Such a mechanism is not
	addressed here.		addressed here.
	IPsec can be applied to NI DNS Name messages to achieve greater		IPsec can be applied to NI Node Name messages to achieve greater
	trust in the information obtained, but such a need may be obviated		trust in the information obtained, but such a need may be obviated
	by applying IPsec directly to some other communication which is		by applying IPsec directly to some other communication which is
	going on (or contemplated) between the Querier and Responder.		going on (or contemplated) between the Querier and Responder.
	4.4. Node Addresses		5.4. Node Addresses
	The NI Node Addresses Query requests some set of the Responder's		The NI Node Addresses Query requests some set of the Responder's
	IPv6 unicast addresses. The Reply Data is a sequence of 128-bit		IPv6 unicast addresses. The Reply Data is a sequence of 128-bit
	IPv6 addresses, each address preceded by separate a 32-bit TTL		IPv6 addresses, each address preceded by separate a 32-bit TTL
	value, with Preferred addresses listed before Deprecated addresses		value, with Preferred addresses listed before Deprecated addresses
	[2461], but otherwise in no special order. Five flag bits are		[2461], but otherwise in no special order. Five flag bits are
	defined in the Query, and six in the Reply.		defined in the Query, and six in the Reply.
	0 1 2 3		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		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
	skipping to change at page 10, line 47		skipping to change at page 11, line 14
	interface) which has the Subject Address, or which are		interface) which has the Subject Address, or which are
	associated with the Subject Name.		associated with the Subject Name.
	T Defined in a Reply only, indicates that the set of addresses is		T Defined in a Reply only, indicates that the set of addresses is
	incomplete for space reasons.		incomplete for space reasons.
	Flags G, S, L, C and A are copied from a Query to the corresponding		Flags G, S, L, C and A are copied from a Query to the corresponding
	Reply.		Reply.
	The TTL associated with each address are to be determined by the		The TTL associated with each address are to be determined by the
	rules in section 4.3, applied to the returned address rather than		rules in section 5.3, applied to the returned address rather than
	the Subject. If no meaningful caching time can be given for an		the Subject. If no meaningful caching time can be given for an
	address, the corresponding TTL field MUST be zero.		address, the corresponding TTL field MUST be zero.
	Each address with non-zero TTL in a NI Node Address Reply may be		Each address with non-zero TTL in a NI Node Address Reply may be
	cached and used for the period indicated by that TTL. If the TTL is		cached and used for the period indicated by that TTL. If the TTL is
	zero, the corresponding address must not be used more than once. If		zero, the corresponding address must not be used more than once. If
	the Query was sent by a DNS server on behalf of a DNS client, the		the Query was sent by a DNS server on behalf of a DNS client, the
	result may be returned to that client as a DNS response with TTL		result may be returned to that client as a DNS response with TTL
	zero.		zero.
	IPv4-mapped addresses can only be returned by a Node Information		IPv4-mapped addresses can only be returned by a Node Information
	proxy, since they represent addresses of IPv4-only nodes, which		proxy, since they represent addresses of IPv4-only nodes, which
	perforce do not implement this protocol.		perforce do not implement this protocol.
	4.5. IPv4 Addresses		5.5. IPv4 Addresses
	The NI IPv4 Addresses Query requests some set of the Responder's		The NI IPv4 Addresses Query requests some set of the Responder's
	IPv4 unicast addresses. The Reply Data is a sequence of 32-bit IPv4		IPv4 unicast addresses. The Reply Data is a sequence of 32-bit IPv4
	addresses, each address preceded by a 32-bit TTL value. One flag		addresses, each address preceded by a 32-bit TTL value. One flag
	bit is defined in the Query, and two in the Reply.		bit is defined in the Query, and two in the Reply.
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Qtype=4 | unused |A|T|		| Qtype=4 | unused |A|T|
	skipping to change at page 11, line 40		skipping to change at page 12, line 8
	requested. If 0, only those addresses are requested which		requested. If 0, only those addresses are requested which
	belong to the interface (or any one interface) which has the		belong to the interface (or any one interface) which has the
	Subject Address.		Subject Address.
	T Defined in a Reply only, indicates that the set of addresses is		T Defined in a Reply only, indicates that the set of addresses is
	incomplete for space reasons.		incomplete for space reasons.
	Flag A is copied from a Query to the corresponding Reply.		Flag A is copied from a Query to the corresponding Reply.
	The TTL associated with each address are to be determined by the		The TTL associated with each address are to be determined by the
	rules in section 4.3, applied to the returned address rather than		rules in section 5.3, applied to the returned address rather than
	the Subject, excluding the autoconfiguration Valid Lifetime. If no		the Subject, excluding the autoconfiguration Valid Lifetime. If no
	meaningful caching time can be given for an address, the		meaningful caching time can be given for an address, the
	corresponding TTL field MUST be zero.		corresponding TTL field MUST be zero.
	Each address with non-zero TTL in a NI IPv4 Address Reply may be		Each address with non-zero TTL in a NI IPv4 Address Reply may be
	cached and used for the period indicated by that TTL. If the TTL is		cached and used for the period indicated by that TTL. If the TTL is
	zero, the corresponding address must not be used more than once. If		zero, the corresponding address must not be used more than once. If
	the Query was sent by a DNS server on behalf of a DNS client, the		the Query was sent by a DNS server on behalf of a DNS client, the
	result may be returned to that client as a DNS response with TTL		result may be returned to that client as a DNS response with TTL
	zero.		zero.
	4.5.1. Discussion		5.5.1. Discussion
	It is possible that a node may treat IPv4 interfaces and IPv6		It is possible that a node may treat IPv4 interfaces and IPv6
	interfaces as distinct, even though they are associated with the		interfaces as distinct, even though they are associated with the
	same hardware. When such a node is responding to a NI Query having		same hardware. When such a node is responding to a NI Query having
	a Subject Address of one type requesting the other type, and the		a Subject Address of one type requesting the other type, and the
	Query has the A flag set to 0, it SHOULD consider IP interfaces,		Query has the A flag set to 0, it SHOULD consider IP interfaces,
	other than tunnels, associated with the same hardware as being the		other than tunnels, associated with the same hardware as being the
	same interface.		same interface.
	5. IANA Considerations		6. IANA Considerations
	ICMPv6 type values 139 and 140 have been assigned by IANA for this		ICMPv6 type values 139 and 140 have been assigned by IANA for this
	protocol. This document defines three values of the ICMPv6 Code		protocol. This document defines three values of the ICMPv6 Code
	field for each of these ICMPv6 Type values. Additional Code values		field for each of these ICMPv6 Type values. Additional Code values
	may be defined only by IETF Consensus [2434].		may be defined only by IETF Consensus [2434].
	This document defines five values of Qtype, numbers 0 through 4.		This document defines five values of Qtype, numbers 0 through 4.
	Following the policies outlined in "Guidelines for Writing an IANA		Following the policies outlined in "Guidelines for Writing an IANA
	Considerations Section in RFCs" [2434], new values, and their		Considerations Section in RFCs" [2434], new values, and their
	associated Flags and Reply Data, may be defined as follows.		associated Flags and Reply Data, may be defined as follows.
	skipping to change at page 12, line 40		skipping to change at page 13, line 8
	Qtypes 1024 through 4095, First Come First Served.		Qtypes 1024 through 4095, First Come First Served.
	Qtypes 4096 through 65535, Private Use.		Qtypes 4096 through 65535, Private Use.
	Users of Private Use values should note that values above 8000 to		Users of Private Use values should note that values above 8000 to
	9000 are likely to lead to fragmentation of "Supported Qtypes"		9000 are likely to lead to fragmentation of "Supported Qtypes"
	Replies unless the compressed form of the Reply Data is used.		Replies unless the compressed form of the Reply Data is used.
	Assignment of the multicast address prefix FF02:0:0:0:0:2::/96 used		Assignment of the multicast address prefix FF02:0:0:0:0:2::/96 used
	in section 3 as a destination for IPv6 Node Information Queries is		in section 4 as a destination for IPv6 Node Information Queries is
	requested.		requested.
	6. Security Considerations		7. Security Considerations
			This protocol has the potential of revealing information useful to a
			would-be attacker. An implementation of this protocol SHOULD have a
			default configuration which refuses to answer queries from global-
			scope [2373] adresses.
			Implementations SHOULD apply rate-limiting to NI responses to avoid
			being used in a denial of service attack.
	The anti-spoofing Nonce does not give any protection from spoofers		The anti-spoofing Nonce does not give any protection from spoofers
	who can snoop the Query or the Reply.		who can eavesdrop the Query or the Reply.
	In a large Internet with relatively frequent renumbering, the		In a large Internet with relatively frequent renumbering, the
	maintenance of of KEY and SIG records [2535] in the zones used for		maintenance of of KEY and SIG records [2535] in the zones used for
	address-to-name translations will be no easier than the maintenance		address-to-name translations will be no easier than the maintenance
	of the NS, SOA and PTR records themselves, which already appears to		of the NS, SOA and PTR records themselves, which already appears to
	be difficult in many cases. The author expects, therefore, that		be difficult in many cases. The author expects, therefore, that
	address-to-name mappings, either through the original DNS mechanism		address-to-name mappings, either through the original DNS mechanism
	or through this new mechanism, will generally be used as only a hint		or through this new mechanism, will generally be used as only a hint
	to find more trustworthy information using the returned name as an		to find more trustworthy information using the returned name as an
	index.		index.
	7. Acknowledgments		8. Acknowledgments
	Alain Durand contributed to this specification and valuable feedback		Alain Durand contributed to this specification and valuable feedback
	and implementation experience was provided by Jun-Ichiro Hagino and		and implementation experience was provided by Jun-Ichiro Hagino and
	Tatuya Jinmei. This document is not the first proposal of a direct		Tatuya Jinmei. Other useful comments were received from Robert Elz
	query mechanism for address-to-name translation. The idea had been		and Keith Moore.
	discussed briefly in the IPng working group and RFC 1788 [1788]
	describes such a mechanism for IPv4.
	8. References		This document is not the first proposal of a direct query mechanism
			for address-to-name translation. The idea had been discussed
			briefly in the IPng working group and RFC 1788 [1788] describes such
			a mechanism for IPv4.
			9. References
			[1034] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC
			1034, STD 13, November 1987.
	[1035] P. Mockapetris, "Domain Names - Implementation and		[1035] P. Mockapetris, "Domain Names - Implementation and
	Specification", RFC 1035, STD 13, November 1987.		Specification", RFC 1035, STD 13, November 1987.
	[1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,		[1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.		April 1992.
	[1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788, April		[1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788, April
	1995.		1995.
	skipping to change at page 14, line 15		skipping to change at page 15, line 6
	[2462] Thomson, S. and T. Narten, "IPv6 Stateless Address		[2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
	Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
	[2463] Conta, A. and S. Deering, "Internet Control Message Protocol		[2463] Conta, A. and S. Deering, "Internet Control Message Protocol
	(ICMPv6) for the Internet Protocol Version 6 (IPv6)		(ICMPv6) for the Internet Protocol Version 6 (IPv6)
	Specification", RFC 2463, December 1998.		Specification", RFC 2463, December 1998.
	[2535] D. Eastlake 3rd, "Domain Name System Security Extensions",		[2535] D. Eastlake 3rd, "Domain Name System Security Extensions",
	RFC 2535, March 1999.		RFC 2535, March 1999.
	9. Author's Address		10. Author's Address
	Matt Crawford		Matt Crawford
	Fermilab MS 368		Fermilab MS 368
	PO Box 500		PO Box 500
	Batavia, IL 60510		Batavia, IL 60510
	USA		USA
	Phone: +1 630 840 3461		Phone: +1 630 840 3461
	Email: crawdad@fnal.gov		Email: crawdad@fnal.gov
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/