draft-ietf-ipngwg-icmp-name-lookups-11.txt		draft-ietf-ipngwg-icmp-name-lookups-12.txt
	IPv6 WG M. Crawford		IPv6 WG M. Crawford
	Internet-Draft Fermilab		Internet-Draft Fermilab
	Expires: November 6, 2005 B. Haberman, Ed.		Expires: January 13, 2006 B. Haberman, Ed.
	JHU APL		JHU APL
	May 5, 2005		July 12, 2005
	IPv6 Node Information Queries		IPv6 Node Information Queries
	draft-ietf-ipngwg-icmp-name-lookups-11		draft-ietf-ipngwg-icmp-name-lookups-12
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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."
	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.
	This Internet-Draft will expire on November 6, 2005.		This Internet-Draft will expire on January 13, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	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 hostname or fully-qualified		certain network information, such as its hostname or fully-qualified
	domain name. IPv6 implementation experience has shown that direct		domain name. IPv6 implementation experience has shown that direct
	skipping to change at page 3, line 9		skipping to change at page 3, line 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1 Normative References . . . . . . . . . . . . . . . . . . . 12		10.1 Normative References . . . . . . . . . . . . . . . . . . . 12
	10.2 Informative References . . . . . . . . . . . . . . . . . . 12		10.2 Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . 14
	1. Introduction		1. Introduction
	This document specifies a mechanism for discovering information about		This document specifies a mechanism for discovering information about
	names and addresses. The applicability of these mechanics is		names and addresses. The applicability of these mechanics is
	currently limited to diagnostic and debugging tools. In the global		currently limited to diagnostic and debugging tools and network
	internet, the Domain Name System[1][2] is the authoritative source of		management (e.g. node discovery). In the global internet, the Domain
	such information and this specification is not intended to supplant		Name System[1][2] is the authoritative source of such information and
	or supersede it. And in fact, in a well-supported network the names		this specification is not intended to supplant or supersede it. And
	and addresses dealt with by this mechanism will be the same ones, and		in fact, in a well-supported network, the names and addresses dealt
	with the same relationships, as those listed in the DNS.		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		This new Node Information protocol does provide facilities which are
	not found in the DNS - for example discovering relationships between		not found in the DNS - for example discovering relationships between
	addresses without reference to names. And the functions that do		addresses without reference to names. And the functions that do
	overlap with the DNS may be useful in serverless environments, for		overlap with the DNS may be useful in serverless environments, for
	debugging, or in regard to link-local and unique-local addresses [3]		debugging, or in regard to link-local and unique-local addresses [3]
	which often will not be listed in the DNS.		which often will not be listed in the DNS.
	2. Applicability Statement		2. Applicability Statement
	IPv6 Node Information Queries include the capability to provide		IPv6 Node Information Queries include the capability to provide
	forward and reverse name lookups independent of the DNS by sending		forward and reverse name lookups independent of the DNS by sending
	packets directly to IPv6 nodes or groups of nodes.		packets directly to IPv6 nodes or groups of nodes.
	The applicability of these mechanics is currently limited to		The applicability of these mechanics is currently limited to
	diagnostic and debugging tools. These mechanisms can be used to		diagnostic and debugging tools and network management (e.g. node
	learn the addresses and names for nodes on the other end of a point-		discovery). These mechanisms can be used to learn the addresses and
	to-point link or nodes on a shared-medium link such as an Ethernet.		names for nodes on the other end of a point-to-point link or nodes on
	This is very useful when debugging problems or when bringing up IPv6		a shared-medium link such as an Ethernet. This is very useful when
	service where there isn't global routing or DNS name services		debugging problems or when bringing up IPv6 service where there isn't
	available. IPv6's large auto-configured addresses make debugging		global routing or DNS name services available. IPv6's large auto-
	network problems and bringing up IPv6 service difficult without these		configured addresses make debugging network problems and bringing up
	mechanisms. An example of a IPv6 debugging tool using IPv6 Node		IPv6 service difficult without these mechanisms. An example of an
	Information Queries is the ping6 program in the KAME, USAGI, and		IPv6 debugging tool using IPv6 Node Information Queries is the ping6
	other IPv6 implementations <http://www.kame.net>.		program in the KAME (<http://www.kame.net>), USAGI, and other IPv6
			implementations.
	The mechanisms defined in this document may have wider applicability		The mechanisms defined in this document may have wider applicability
	in the future (for example, name lookups in zero configuration		in the future (for example, name lookups in zero configuration
	networks, global reverse name lookups, etc.), but any use beyond		networks, global reverse name lookups, etc.), but any use beyond
	debugging and diagnostic tools is left for further study and is		debugging and diagnostic tools is left for further study and is
	beyond the scope of this document.		beyond the scope of this document.
	3. Terminology		3. 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 and may be an IPv6 or IPv4 address)
	sends a "Node Information Reply" to the Querier, containing		or a "Subject Name". The Responder sends a "Node Information Reply"
	information associated with the node at the Queried Address. A node		to the Querier, containing information associated with the node at
	receiving a NI Query will be termed a Responder even if it does not		the Queried Address. A node receiving an NI Query will be termed a
	send a reply.		Responder even if it does not send a reply.
	The word "name" in this document refers to a hostname with or without		The word "name" in this document refers to a hostname with or without
	the domain. Where necessary, the cases of fully-qalified and single-		the domain. Where necessary, the cases of fully-qalified and single-
	label names will be distinguished.		label names will be distinguished.
	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 [4].		document are to be interpreted as described in [4].
	Packet fields marked "unused" must be zero on transmission and, aside		Packet fields marked "unused" must be zero on transmission and, aside
	skipping to change at page 6, line 34		skipping to change at page 6, line 34
	scope [3].		scope [3].
	When the Subject is a name, either fully-qualified or single-		When the Subject is a name, either fully-qualified or single-
	component, and the Querier does not have a unicast address for the		component, and the Querier does not have a unicast address for the
	target node, the query MUST be sent to a link-scope multicast address		target node, the query MUST be sent to a link-scope multicast address
	formed in the following way. The Subject Name is converted to the		formed in the following way. The Subject Name is converted to the
	canonical form defined by DNS Security [6], which is uncompressed		canonical form defined by DNS Security [6], which is uncompressed
	with all alphabetic characters in lower case. (If additional DNS		with all alphabetic characters in lower case. (If additional DNS
	label types or character sets for host names are defined, the rules		label types or character sets for host names are defined, the rules
	for canonicalizing those labels will be found in their defining		for canonicalizing those labels will be found in their defining
	specification.) Compute the MD5 hash [10] of the first label of the		specification.) Compute the MD5 hash [11] of the first label of the
	Subject Name -- the portion beginning with the first one-octet length		Subject Name -- the portion beginning with the first one-octet length
	field and up to, but excluding, any subsequent length field. Append		field and up to, but excluding, any subsequent length field. Append
	the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0:		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 the "NI Group		2::/96. The resulting multicast address will be termed the "NI Group
	Address" for the name. A node will support an "NI Group Address" for		Address" for the name. A node will support an "NI Group Address" for
	each associated Subject Name.		each associated Subject 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 independent		spoofed replies. An implementation which allows multiple independent
	processes to send NI queries MAY use the Nonce value to deliver		processes to send NI queries MAY use the Nonce value to deliver
	Replies to the correct process. Nonetheless, such processes MUST		Replies to the correct process. Nonetheless, such processes MUST
	check the received Nonce and ignore extraneous Replies.		check the received Nonce and ignore extraneous Replies.
	If true communication security is required, IPsec [11] must be used.		If true communication security is required, IPsec [12] MUST be used.
	Providing the infrastructure to authenticate NI Queries and Replies		Providing the infrastructure to authenticate NI Queries and Replies
	may be quote difficult outside of a well-defined community.		may be quite difficult outside of a well-defined community.
	Upon receiving a NI Query, the Responder must check the Query's IPv6		Upon receiving an NI Query, the Responder must check the Query's IPv6
	destination address and discard the Query without further processing		destination address and discard the Query without further processing
	unless it is one of the Responder's unicast or anycast addresses, or		unless it is one of the Responder's unicast or anycast addresses, or
	a link-local scope multicast address which the Responder has joined.		a link-local scope multicast address which the Responder has joined.
	Typically the latter will be a NI Group Address for a name belonging		Typically the latter will be an NI Group Address for a name belonging
	to the Responder or a NI Group Address for a name for which the		to the Responder. A node MAY be configured to discard NI Queries to
	Responder is providing proxy service. A node MAY be configurable to		multicast addresses other than its NI Group Address(es) but if so,
	discard NI Queries to multicast addresses other than its NI Group		the default configuration MUST be not to discard them.
	Address(es) but if so, the default configuration MUST be not to
	discard them.
	A Responder must also silently discard a Query whose Subject Address		A Responder must also silently discard a Query whose Subject Address
	or Name (in the Data field) does not belong to that node, unless it		or Name (in the Data field) does not belong to that node. A single-
	is providing proxy service for that Subject. A single-component		component Subject Name matches any fully-qualified name whose first
	Subject Name matches any fully-qualified name whose first label		label 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 [6].		independent manner consistent with DNSSEC name canonicalization [6].
	Next, if Qtype is unknown to the Responder, it must return a NI Reply		Next, if Qtype is unknown to the Responder, it must return an NI
	with ICMPv6 Code = 2 and no Reply Data. The Responder should rate-		Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should
	limit such replies as it would ICMPv6 error replies [5].		rate-limit such replies as it would ICMPv6 error replies [5].
	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. (See "Security Considerations" for recommended		on local policy. (See "Security Considerations" for recommended
	default behavior.) If an answer is refused, the Responder may send a		default behavior.) If an answer is refused, the Responder may send
	NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the		an NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the
	Responder should rate-limit such replies as it would ICMPv6 error		Responder should rate-limit such replies as it would ICMPv6 error
	replies [5].		replies [5].
	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 NI		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 the		Reply in accordance with the definition of the Qtype and transmit the
	NI Reply with an ICMPv6 source address equal to the Queried Address,		NI Reply. The source address of the NI Reply SHOULD be selected
	unless that address was an anycast or a multicast address. If the		using the rules defined in [7].
	Queried Address was anycast or multicast, the source address for the
	Reply SHOULD be one belonging to the interface on which the Query was
	received.
	If the Query was sent to an anycast or multicast address,		If the Query was sent to a multicast address, transmission of the
	transmission of the Reply MUST be delayed by a random interval		Reply MUST be delayed by a random interval between zero and
	between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor		MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor Discovery [8].
	Discovery [7].
	6. Defined Qtypes		6. Defined Qtypes
	The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be		The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be
	supported by any implementation of this protocol. Qtype 4 SHOULD be		supported by any implementation of this protocol. Qtype 4 SHOULD be
	supported by any implementation of this protocol on an IPv4/IPv6		supported by any implementation of this protocol 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.
	+-------------+----------------+		+-------------+----------------+
	| Qtype Value | Qtype Name |		| Qtype Value | Qtype Name |
	skipping to change at page 8, line 19		skipping to change at page 8, line 18
	| 0 | NOOP |		| 0 | NOOP |
	| 1 | unused |		| 1 | unused |
	| 2 | Node Name |		| 2 | Node Name |
	| 3 | Node Addresses |		| 3 | Node Addresses |
	| 4 | IPv4 Addresses |		| 4 | IPv4 Addresses |
	+-------------+----------------+		+-------------+----------------+
	6.1 NOOP		6.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 an 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 0.		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.		On reception of a NOOP Query or Reply, the Code must be ignored.
	6.2 Node Name		6.2 Node Name
	The NI Node 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
	skipping to change at page 8, line 45		skipping to change at page 8, line 44
	| TTL |		| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Node Names ... |		| Node Names ... |
	+ +		+ +
	/ /		/ /
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o TTL - MUST be zero. Any non-zero value received MUST be treated		o TTL - MUST be zero. Any non-zero value received MUST be treated
	as zero.		as zero. This field is no longer used but is present to preserve
			backwards compatibility with older implementations.
	o Node Names - The fully-qualified or single-component name or names		o Node Names - The fully-qualified or single-component name or names
	of the Responder which correspond(s) to the Subject Address or		of the Responder which correspond(s) to the Subject Address or
	Name, in DNS wire format [2]. Each name MUST be fully-qualified		Name, in DNS wire format [2]. Each name MUST be fully-qualified
	if the responder knows the domain suffix, and otherwise be a		if the responder knows the domain suffix, and otherwise be a
	single DNS label followed by two zero-length labels. When		single DNS label followed by two zero-length labels. When
	multiple node names are returned and more than one of them is		multiple node names are returned and more than one of them is
	fully-qualified, DNS name compression [2] SHOULD be used, and the		fully-qualified, DNS name compression [2] SHOULD be used, and the
	offsets are counted from the first octet of the Data field. An		offsets are counted from the first octet of the Data field. An
	offset of 4, for example, will point to the beginning of the first		offset of 4, for example, will point to the beginning of the first
	skipping to change at page 9, line 24		skipping to change at page 9, line 23
	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 Node Names (or a Reply with Code=1 indicating		with TTL=0 and no Node Names (or a Reply with Code=1 indicating
	refusal to answer). The Querier will be able to determine from the		refusal to answer). The Querier will be able to determine from the
	packet length that the Data field contains no names.		packet length that the Data field contains no names.
	6.3 Node Addresses		6.3 Node Addresses
	The NI Node Addresses Query requests some set of the Responder's IPv6		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 value, with		addresses, each address preceded by a separate 32-bit TTL value, with
	Preferred addresses listed before Deprecated addresses [7], but		Preferred addresses listed before Deprecated addresses [8], but
	otherwise in no special order. Five flag bits are defined in the		otherwise in no special order. Five flag bits are defined in the
	Query, and six in the Reply.		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Qtype=3 | unused |G|S|L|C|A|T|		| Qtype=3 | unused |G|S|L|C|A|T|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o G - If set to 1, Global-scope addresses [8] are requested.		o G - If set to 1, Global-scope addresses [9] are requested.
	o S - If set to 1, Site-local addresses [8] are requested.		o S - If set to 1, Site-local addresses [9] are requested. However,
			Site-local addresses are now deprecated [13] and this flag is for
			backwards compatibility.
	o L - If set to 1, Link-local addresses [8] are requested.		o L - If set to 1, Link-local addresses [9] are requested.
	o C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are		o C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are
	requested.		requested. As the IPv4-compatible addresses are now deprecated,
			this flag is for backwards compatibility with older
			implementations,
	o A - If set to 1, all the Responder's unicast addresses (of the		o A - If set to 1, all the Responder's unicast addresses (of the
	specified scope(s)) are requested. If 0, only those addresses are		specified scope(s)) are requested. If 0, only those addresses are
	requested which belong to the interface (or any one interface)		requested which belong to the interface (or any one interface)
	which has the Subject Address, or which are associated with the		which has the Subject Address, or which are associated with the
	Subject Name.		Subject Name.
	o T Defined in a Reply only, indicates that the set of addresses		o T Defined in a Reply only, indicates that the set of addresses is
	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 MUST be zero.		The TTL associated with each address MUST be zero.
	IPv4-mapped addresses can only be returned by a Node Information
	proxy, since they represent addresses of IPv4-only nodes, which
	perforce do not implement this protocol.
	6.4 IPv4 Addresses		6.4 IPv4 Addresses
	The NI IPv4 Addresses Query requests some set of the Responder's IPv4		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		unicast addresses. The Reply Data is a sequence of 32-bit IPv4
	addresses, each address preceded by a 32-bit TTL value. One flag bit		addresses, each address preceded by a 32-bit TTL value. One flag bit
	is defined in the Query, and two in the Reply.		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|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o A - If set to 1, all the Responder's unicast addresses are		o A - If set to 1, all the Responder's unicast addresses are
	requested. If 0, only those addresses are requested which belong		requested. If 0, only those addresses are requested which belong
	to the interface (or any one interface) which has the Subject		to the interface (or any one interface) which has the Subject
	Address.		Address.
	o T Defined in a Reply only, indicates that the set of addresses		o T Defined in a Reply only, indicates that the set of addresses is
	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 MUST be zero.		The TTL associated with each address MUST be zero.
	6.4.1 Discussion		6.4.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 same		interfaces as distinct, even though they are associated with the same
	hardware. When such a node is responding to a NI Query having a		hardware. When such a node is responding to an NI Query having a
	Subject Address of one type requesting the other type, and the Query		Subject Address of one type requesting the other type, and the Query
	has the A flag set to 0, it SHOULD consider IP interfaces, other than		has the A flag set to 0, it SHOULD consider IP interfaces, other than
	tunnels, associated with the same hardware as being the same		tunnels, associated with the same hardware as being the same
	interface.		interface.
	7. IANA Considerations		7. IANA Considerations
	ICMPv6 type values 139 and 140 were previously assigned by IANA for		ICMPv6 type values 139 and 140 were previously assigned by IANA for
	this protocol. This document defines three values of the ICMPv6 Code		this 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 [12].		may be defined only by IETF Consensus [14].
	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 [12], new values, and their		Following the policies outlined in [14], new values, and their
	associated Flags and Reply Data, are to be defined by IETF Consensus.		associated Flags and Reply Data, are to be defined by IETF Consensus.
	The IANA is requested to assign the IPv6 multicast prefix FF02:0:0:0:		The IANA is requested to assign the IPv6 multicast prefix FF02:0:0:0:
	0:2::/96 for use in Node Information Queries as defined in section		0:2::/96 for use in Node Information Queries as defined in Section 5.
	Section 5.
	8. Security Considerations		8. Security Considerations
	This protocol shares the security issues of ICMPv6 that are		This protocol shares the security issues of ICMPv6 that are
	documented in the "Security Considerations" section of [5].		documented in the "Security Considerations" section of [5].
	This protocol has the potential of revealing information useful to a		This protocol has the potential of revealing information useful to a
	would-be attacker. An implementation of this protocol SHOULD have a		would-be attacker. An implementation of this protocol SHOULD have a
	default configuration which refuses to answer queries from global-		default configuration which refuses to answer queries from global-
	scope [3] addresses.		scope [3] addresses.
	skipping to change at page 11, line 38		skipping to change at page 11, line 36
	The anti-spoofing Nonce does not give any protection from spoofers		The anti-spoofing Nonce does not give any protection from spoofers
	who can eavesdrop the Query or the Reply.		who can eavesdrop the Query or the Reply.
	The information learned via this protocol SHOULD not be trusted for		The information learned via this protocol SHOULD not be trusted for
	making security relevant decisions unless some other mechanisms		making security relevant decisions unless some other mechanisms
	beyond the scope of this document is used to authenticate this		beyond the scope of this document is used to authenticate this
	information.		information.
	An implementation of this protocol SHOULD provide the ability to		An implementation of this protocol SHOULD provide the ability to
	control the dissemination of information related to IPv6 Privacy		control the dissemination of information related to IPv6 Privacy
	Addresses [13]. The default action of this policy SHOULD NOT provide		Addresses [15]. The default action of this policy SHOULD NOT provide
	a reponse to a Query that contains a node's Privacy Addresses.		a reponse to a Query that contains a node's Privacy Addresses.
	9. Acknowledgments		9. 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. Other useful comments were received from Robert Elz		Tatuya Jinmei. Other useful comments were received from Robert Elz
	and Keith Moore. Bob Hinden and Brian Haberman have acted as		and Keith Moore. Bob Hinden and Brian Haberman have acted as
	document editors during the IETF advancement process.		document editors during the IETF advancement process.
	This document is not the first proposal of a direct query mechanism		This document is not the first proposal of a direct query mechanism
	for address-to-name translation. The idea had been discussed briefly		for address-to-name translation. The idea had been discussed briefly
	in the IPng working group and RFC 1788 [14] describes such a		in the IPng working group and RFC 1788 [16] describes such a
	mechanism for IPv4.		mechanism for IPv4.
	10. References		10. References
	10.1 Normative References		10.1 Normative References
	[1] Mockapetris, P., "Domain names - concepts and facilities",		[1] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[2] Mockapetris, P., "Domain names - implementation and		[2] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)		[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Addressing Architecture", RFC 3513, April 2003.		Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in
			progress), May 2005.
	[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[5] Conta, A. and S. Deering, "Internet Control Message Protocol		[5] 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.
	[6] Eastlake, D., "Domain Name System Security Extensions",		[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	RFC 2535, March 1999.		"Resource Records for the DNS Security Extensions", RFC 4034,
			March 2005.
	[7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery		[7] Draves, R., "Default Address Selection for Internet Protocol
			version 6 (IPv6)", RFC 3484, February 2003.
			[8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
	[8] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast		[9] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast
	Address Format", RFC 2374, July 1998.		Address Format", RFC 2374, July 1998.
	[9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	10.2 Informative References		10.2 Informative References
	[10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[11] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.		April 1992.
	[11] Kent, S. and R. Atkinson, "Security Architecture for the		[12] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
	[12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[13] Huitema, C. and B. Carpenter, "Deprecating Site Local
			Addresses", RFC 3879, September 2004.
			[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434,		Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.		October 1998.
	[13] Narten, T. and R. Draves, "Privacy Extensions for Stateless		[15] Narten, T. and R. Draves, "Privacy Extensions for Stateless
	Address Autoconfiguration in IPv6", RFC 3041, January 2001.		Address Autoconfiguration in IPv6", RFC 3041, January 2001.
	[14] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.		[16] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.
	Authors' Addresses		Authors' Addresses
	Matt Crawford		Matt Crawford
	Fermilab		Fermilab
	PO Box 500		PO Box 500
	Batavia, IL 60510		Batavia, IL 60510
	US		US
	Phone: +1 630 840 3461		Phone: +1 630 840 3461
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/