--- 1/draft-ietf-ipngwg-icmp-name-lookups-13.txt 2006-02-04 17:01:06.000000000 +0100 +++ 2/draft-ietf-ipngwg-icmp-name-lookups-14.txt 2006-02-04 17:01:06.000000000 +0100 @@ -1,19 +1,19 @@ IPv6 WG M. Crawford Internet-Draft Fermilab -Expires: July 7, 2006 B. Haberman, Ed. +Expires: July 5, 2006 B. Haberman, Ed. JHU APL - January 3, 2006 + January 2006 IPv6 Node Information Queries - draft-ietf-ipngwg-icmp-name-lookups-13 + draft-ietf-ipngwg-icmp-name-lookups-14 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +24,21 @@ 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. - This Internet-Draft will expire on July 7, 2006. + This Internet-Draft will expire on July 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct @@ -46,26 +46,26 @@ other information has been found useful in serverless environments and for debugging. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Node Information Messages . . . . . . . . . . . . . . . . . . 4 5. Message Processing . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Defined Qtypes . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Defined Qtypes . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. NOOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Node Name . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Node Addresses . . . . . . . . . . . . . . . . . . . . . . 9 6.4. IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . 10 - 6.4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . 11 + 6.4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 1. Introduction @@ -107,21 +107,21 @@ implementations. The mechanisms defined in this document may have wider applicability in the future, but any use beyond debugging and diagnostic tools is left for further study and is beyond the scope of this document. 3. Terminology A "Node Information (or NI) Query" message is sent by a "Querier" 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 contains a "Subject Address" (which may differ from the Queried Address and may be an IPv6 or IPv4 address) or a "Subject Name". The Responder sends a "Node Information Reply" to the Querier, containing information associated with the node at the Queried Address. A node receiving an NI Query will be termed a Responder even if it does not send a reply. The word "name" in this document refers to a hostname with or without the domain. Where necessary, the cases of fully-qualified and single-label names will be distinguished. @@ -200,24 +200,24 @@ Qtype must be zero on transmission and ignored on reception, and must not be copied from a Query to a Reply unless so specified in the definition of the Qtype. o Nonce - An opaque 64-bit field to help avoid spoofing and/or to aid in matching Replies with Queries. Its value in a Query is chosen by the Querier. Its value in a Reply is always copied from the corresponding Request by the Responder. o Data - In a Query, the Subject Address or Name. In a Reply, - Qtype-specific data present only when the ICMPv6 Code field is + Qtype-specific data is present only when the ICMPv6 Code field is zero. The length of the Data may be inferred from the IPv6 - header's Payload Length field [2460], the length of the fixed - portion of the NI packet and the lengths of the ICMPv6 header and + header's Payload Length field[6], the length of the fixed portion + of the NI packet and the lengths of the ICMPv6 header and intervening extension headers. Note that the type of information present in the Data field of a Query is declared by the ICMP Code, while the type of information, 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 format [2]. The name may be either a fully-qualified domain name, including the terminating zero-length label, or a single DNS label followed by two zero-length labels. Since a Query contains at most @@ -230,82 +230,79 @@ 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 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 scope [3]. When the Subject is a name, either fully-qualified or single- 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 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 [7], which is uncompressed with all alphabetic characters in lower case. (If additional DNS label types or character sets for host names are defined, the rules for canonicalizing those labels will be found in their defining - specification.) Compute the MD5 hash [7] of the first label of the + specification.) Compute the MD5 hash [8] of the first label of the Subject Name -- the portion beginning with the first one-octet length 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:2: - FF::/104. The resulting multicast address will be termed the "NI + the first 24 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2: + FF00::/104. The resulting multicast address will be termed the "NI Group Address" for the name. A node will support an "NI Group - Address" for each associated Subject Name. + Address" for each unique single-label name. The Nonce MUST be a random or good pseudo-random value to foil spoofed replies. An implementation which allows multiple independent processes to send NI queries MAY use the Nonce value to deliver Replies to the correct process. Nonetheless, such processes MUST check the received Nonce and ignore extraneous Replies. - If true communication security is required, IPsec [13] should be + If true communication security is required, IPsec [14] should be used. Providing the infrastructure to authenticate NI Queries and Replies may be quite difficult outside of a well-defined community. Upon receiving an NI Query, the Responder must check the Query's IPv6 destination address and discard the Query without further processing unless it is one of the Responder's unicast or anycast addresses, or a link-local scope multicast address which the Responder has joined. Typically the latter will be an NI Group Address for a name belonging to the Responder. A node MAY be configured to discard NI Queries to multicast addresses other than its NI Group Address(es) but if so, - the default configuration SHOULD be not to discard them. An - exception is made in the previous rule in the case of the All-Routers - (FF02::2) and All-Nodes (FF02::1) multicast addresses. The default - configuration for responding to NI Queries to these multicast - addresses MUST be to discard them. + the default configuration SHOULD be not to discard them. A Responder must also silently discard a Query whose Subject Address or Name (in the Data field) does not belong to that node. A single- component Subject Name matches any fully-qualified name whose first label 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 [7]. Next, if Qtype is unknown to the Responder, it must return an NI Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should rate-limit such replies as it would ICMPv6 error replies [5]. Next, the Responder should decide whether to refuse an answer, based on local policy. (See "Security Considerations" for recommended default behavior.) If an answer is refused, depending on local policy the Responder can elect to silently discard the query or send an NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the Responder should rate-limit such replies as it would ICMPv6 error replies [5]. 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 Reply in accordance with the definition of the Qtype and transmit the NI Reply. The source address of the NI Reply SHOULD be selected - using the rules defined in [8]. + using the rules defined in [9]. If the Query was sent to a multicast address, transmission of the - Reply MUST be delayed by a random interval between zero and - MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor Discovery [9]. + Reply MUST be delayed by a random interval between zero and [Query + Response Interval], as defined by Multicast Listener Discovery + Version 2 [10]. 6. Defined Qtypes 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 on an IPv4/IPv6 dual-stack node and MAY be supported on an IPv6-only node. +-------------+----------------+ | Qtype Value | Qtype Name | @@ -367,53 +365,54 @@ 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 refusal to answer). The Querier will be able to determine from the packet length that the Data field contains no names. 6.3. Node Addresses 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 addresses, each address preceded by a separate 32-bit TTL value, with - Preferred addresses listed before Deprecated addresses [9], but + Preferred addresses listed before Deprecated addresses [11], but otherwise in no special order. Five flag bits are defined in the Query, and six in the Reply. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qtype=3 | unused |G|S|L|C|A|T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Node Information Address Query - o G - If set to 1, Global-scope addresses [10] are requested. + o G - If set to 1, Global-scope addresses [12] are requested. - o S - If set to 1, Site-local addresses [10] are requested. - However, Site-local addresses are now deprecated [14] and this + o S - If set to 1, Site-local addresses [12] are requested. + However, Site-local addresses are now deprecated [15] and this flag is for backwards compatibility. - o L - If set to 1, Link-local addresses [10] are requested. + o L - If set to 1, Link-local addresses [12] are requested. o C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are requested. As the IPv4-compatible addresses are now deprecated, this flag is for backwards compatibility with older - implementations, + implementations. Responses SHOULD include IPv4 addresses in IPv4- + mapped form. 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 requested which belong to the interface (or any one interface) which has the Subject Address, or which are associated with the Subject Name. - o T Defined in a Reply only, indicates that the set of addresses is - incomplete for space reasons. + o T - Defined in a Reply only, indicates that the set of addresses + is incomplete for space reasons. Flags G, S, L, C and A are copied from a Query to the corresponding Reply. The TTL associated with each address MUST be zero. 6.4. IPv4 Addresses 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 @@ -426,55 +425,55 @@ | Qtype=4 | unused |A|T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Node Information IPv4 Address Query o A - If set to 1, all the Responder's unicast addresses are requested. If 0, only those addresses are requested which belong to the interface (or any one interface) which has the Subject Address. - o T Defined in a Reply only, indicates that the set of addresses is - incomplete for space reasons. + o T - Defined in a Reply only, indicates that the set of addresses + is incomplete for space reasons. Flag A is copied from a Query to the corresponding Reply. The TTL associated with each address MUST be zero. 6.4.1. Discussion It is possible that a node may treat IPv4 interfaces and IPv6 interfaces as distinct, even though they are associated with the same 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 has the A flag set to 0, it SHOULD consider IP interfaces, other than tunnels, associated with the same hardware as being the same interface. 7. IANA Considerations ICMPv6 type values 139 and 140 were previously assigned by IANA for this protocol. This document defines three values of the ICMPv6 Code field for each of these ICMPv6 Type values. Additional Code values - may be defined using the "Specification Required" criteria from [15]. + may be defined using the "Specification Required" criteria from [16]. IANA is requested to establish and maintain a registry for the Code fields associated with the Node Information Query ICMPv6 Types as a - part of its ICMPv6 Registry updated in [11]. + part of its ICMPv6 Registry updated in [13]. This document defines five values of Qtype, numbers 0 through 4. - Following the policies outlined in [15], new values, and their + Following the policies outlined in [16], new values, and their 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: 0:2:FF::/104 for use in Node Information Queries as defined in Section 5. It should be noted that this request does conform with - the requirements defined in [16]. + the requirements defined in [17]. 8. Security Considerations This protocol shares the security issues of ICMPv6 that are documented in the "Security Considerations" section of [5]. This protocol has the potential of revealing information useful to a would-be attacker. An implementation of this protocol MUST have a default configuration which refuses to answer queries from global- scope [3] addresses. @@ -485,100 +484,112 @@ The anti-spoofing Nonce does not give any protection from spoofers who can eavesdrop the Query or the Reply. The information learned via this protocol SHOULD not be trusted for making security relevant decisions unless some other mechanisms beyond the scope of this document is used to authenticate this information. An implementation of this protocol SHOULD provide the ability to control the dissemination of information related to IPv6 Privacy - Addresses [17]. The default action of this policy SHOULD NOT provide - a reponse to a Query that contains a node's Privacy Addresses. + Addresses [18]. The default action of this policy SHOULD NOT provide + a response to a Query that contains a node's Privacy Addresses. + + A node MUST NOT include Privacy Addresses in any Node Addresses + response which includes a public address, or for which the source + address of the response, the destination address of the request, or + the Subject Address of the request, is a public address. Similarly, + a node MUST NOT include any address other than the (single) Privacy + Address in any Node Addresses response which includes the Privacy + Address, or for which the source address of the response, the + destination address of the request, or the Subject Address of the + request, is the Privacy Address. 9. Acknowledgments Alain Durand contributed to this specification and valuable feedback and implementation experience was provided by Jun-Ichiro Hagino and Tatuya Jinmei. Other useful comments were received from Robert Elz, - Keith Moore, Elwyn Davies, and Pekka Savola. Bob Hinden and Brian - Haberman have acted as document editors during the IETF advancement - process. + Keith Moore, Elwyn Davies, Pekka Savola, and Dave Thaler. Bob Hinden + and Brian Haberman have acted as document editors during the IETF + advancement process. 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 [18] describes such a + in the IPng working group and RFC 1788 [19] describes such a mechanism for IPv4. 10. References 10.1. Normative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. - [3] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in - progress), May 2005. + [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. - [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. - [7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. - [8] Draves, R., "Default Address Selection for Internet Protocol + [9] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. - [9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery + [10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 + (MLDv2) for IPv6", RFC 3810, June 2004. + + [11] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. - [10] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast - Address Format", RFC 2374, July 1998. + [12] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast + Address Format", RFC 3587, August 2003. - [11] Conta, A., "Internet Control Message Protocol (ICMPv6) for the + [13] Conta, A., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. - [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 2460, December 1998. - 10.2. Informative References - [13] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. + [14] Kent, S. and K. Seo, "Security Architecture for the Internet + Protocol", RFC 4301, December 2005. - [14] Huitema, C. and B. Carpenter, "Deprecating Site Local + [15] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004. - [15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - [16] Haberman, B., "Allocation Guidelines for IPv6 Multicast + [17] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. - [17] Narten, T. and R. Draves, "Privacy Extensions for Stateless + [18] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. - [18] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. + [19] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. Authors' Addresses Matt Crawford Fermilab PO Box 500 Batavia, IL 60510 US Phone: +1 630 840 3461