idnits 2.17.1 draft-ietf-ipngwg-icmp-name-lookups-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 627. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2006) is 6646 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3513 (ref. '3') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. '6') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '8') ** Obsolete normative reference: RFC 3484 (ref. '9') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 2461 (ref. '11') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 3587 (ref. '12') -- Possible downref: Normative reference to a draft: ref. '13' -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '16') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '18') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 1788 (ref. '19') (Obsoleted by RFC 6918) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 WG M. Crawford 3 Internet-Draft Fermilab 4 Expires: August 17, 2006 B. Haberman, Ed. 5 JHU APL 6 February 13, 2006 8 IPv6 Node Information Queries 9 draft-ietf-ipngwg-icmp-name-lookups-15 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 17, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes a protocol for asking an IPv6 node to supply 43 certain network information, such as its hostname or fully-qualified 44 domain name. IPv6 implementation experience has shown that direct 45 queries for a hostname are useful, and a direct query mechanism for 46 other information has been found useful in serverless environments 47 and for debugging. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Node Information Messages . . . . . . . . . . . . . . . . . . 4 55 5. Message Processing . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Defined Qtypes . . . . . . . . . . . . . . . . . . . . . . . . 7 57 6.1. NOOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 6.2. Node Name . . . . . . . . . . . . . . . . . . . . . . . . 8 59 6.3. Node Addresses . . . . . . . . . . . . . . . . . . . . . . 9 60 6.4. IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . 10 61 6.4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . 10 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . . . 15 71 1. Introduction 73 This document specifies a mechanism for discovering information about 74 names and addresses. The applicability of these mechanisms is 75 currently limited to diagnostic and debugging tools and network 76 management (e.g. node discovery). In the global internet, the Domain 77 Name System[1][2] is the authoritative source of such information and 78 this specification is not intended to supplant or supersede it. And 79 in fact, in a well-supported network, the names and addresses dealt 80 with by this mechanism will be the same ones, and with the same 81 relationships, as those listed in the DNS. 83 This new Node Information protocol does provide facilities which are 84 not found in the DNS - for example discovering relationships between 85 addresses without reference to names. And the functions that do 86 overlap with the DNS may be useful in serverless environments, for 87 debugging, or in regard to link-local and unique-local addresses [3] 88 which often will not be listed in the DNS. 90 2. Applicability Statement 92 IPv6 Node Information Queries include the capability to provide 93 forward and reverse name lookups independent of the DNS by sending 94 packets directly to IPv6 nodes or groups of nodes. 96 The applicability of these mechanisms is currently limited to 97 diagnostic and debugging tools and network management (e.g. node 98 discovery). These mechanisms can be used to learn the addresses and 99 names for nodes on the other end of a point-to-point link or nodes on 100 a shared-medium link such as an Ethernet. This is very useful when 101 debugging problems or when bringing up IPv6 service where there isn't 102 global routing or DNS name services available. IPv6's large auto- 103 configured addresses make debugging network problems and bringing up 104 IPv6 service difficult without these mechanisms. An example of an 105 IPv6 debugging tool using IPv6 Node Information Queries is the ping6 106 program in the KAME (), USAGI, and other IPv6 107 implementations. 109 The mechanisms defined in this document may have wider applicability 110 in the future, but any use beyond debugging and diagnostic tools is 111 left for further study and is beyond the scope of this document. 113 3. Terminology 115 A "Node Information (or NI) Query" message is sent by a "Querier" 116 node to a "Responder" node in an ICMPv6 packet addressed to the 117 "Queried Address." The Query contains a "Subject Address" (which may 118 differ from the Queried Address and may be an IPv6 or IPv4 address) 119 or a "Subject Name". The Responder sends a "Node Information Reply" 120 to the Querier, containing information associated with the node at 121 the Queried Address. A node receiving an NI Query will be termed a 122 Responder even if it does not send a reply. 124 The word "name" in this document refers to a hostname with or without 125 the domain. Where necessary, the cases of fully-qualified and 126 single-label names will be distinguished. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [4]. 132 Packet fields marked "unused" must be zero on transmission and, aside 133 from inclusion in checksums or message integrity checks, ignored on 134 reception. 136 4. Node Information Messages 138 Two types of Node Information messages, the NI Query and the NI 139 Reply, are carried in ICMPv6 [5] packets. They have the same format. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Type | Code | Checksum | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Qtype | Flags | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | 149 + Nonce + 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | 153 / Data / 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 1: Node Information Messages 159 Fields: 161 o Type 162 * 139 - NI Query 164 * 140 - NI Reply 166 o Code 168 * For NI Query 170 + 0 - Indicates that the Data field contains an IPv6 address 171 which is the Subject of this Query. 173 + 1 - Indicates that the Data field contains a name which is 174 the Subject of this Query, or is empty, as in the case of a 175 NOOP. 177 + 2 - Indicates that the Data field contains an IPv4 address 178 which is the Subject of this Query. 180 * For NI Reply 182 + 0 - Indicates a successful reply. The Reply Data field may 183 or may not be empty. 185 + 1 - Indicates that the Responder refuses to supply the 186 answer. The Reply Data field will be empty. 188 + 2 - Indicates that the Qtype of the Query is unknown to the 189 Responder. The Reply Data field will be empty. 191 o Checksum - The ICMPv6 checksum. 193 o Qtype - A 16-bit field which designates the type of information 194 requested in a Query or supplied in a Reply. Its value in a Reply 195 is always copied from the corresponding Query by the Responder. 196 Five values of Qtype are specified in this document. 198 o Flags - Qtype-specific flags which may be defined for certain 199 Query types and their Replies. Flags not defined for a given 200 Qtype must be zero on transmission and ignored on reception, and 201 must not be copied from a Query to a Reply unless so specified in 202 the definition of the Qtype. 204 o Nonce - An opaque 64-bit field to help avoid spoofing and/or to 205 aid in matching Replies with Queries. Its value in a Query is 206 chosen by the Querier. Its value in a Reply is always copied from 207 the corresponding Request by the Responder. 209 o Data - In a Query, the Subject Address or Name. In a Reply, 210 Qtype-specific data is present only when the ICMPv6 Code field is 211 zero. The length of the Data may be inferred from the IPv6 212 header's Payload Length field[6], the length of the fixed portion 213 of the NI packet and the lengths of the ICMPv6 header and 214 intervening extension headers. 216 Note that the type of information present in the Data field of a 217 Query is declared by the ICMP Code, while the type of information, if 218 any, in the Data field of a Reply is determined by the Qtype. 220 When the Subject of a Query is a name, the name MUST be in DNS wire 221 format [2]. The name may be either a fully-qualified domain name, 222 including the terminating zero-length label, or a single DNS label 223 followed by two zero-length labels. Since a Query contains at most 224 one name, DNS name compression MUST NOT be used. 226 5. Message Processing 228 The Querier constructs an ICMP NI Query and sends it to the address 229 from which information is wanted. When the Subject of the Query is 230 an IPv6 address, that address will normally be used as the IPv6 231 destination address of the Query, but need not be if the Querier has 232 useful a priori information about the addresses of the target node. 233 An NI Query may also be sent to a multicast address of link-local 234 scope [3]. 236 When the Subject is a name, either fully-qualified or single- 237 component, and the Querier does not have a unicast address for the 238 target node, the query MUST be sent to a link-scope multicast address 239 formed in the following way. The Subject Name is converted to the 240 canonical form defined by DNS Security [7], which is uncompressed 241 with all alphabetic characters in lower case. (If additional DNS 242 label types or character sets for host names are defined, the rules 243 for canonicalizing those labels will be found in their defining 244 specification.) Compute the MD5 hash [8] of the first label of the 245 Subject Name -- the portion beginning with the first one-octet length 246 field and up to, but excluding, any subsequent length field. Append 247 the first 24 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2: 248 FF00::/104. The resulting multicast address will be termed the "NI 249 Group Address" for the name. A node will support an "NI Group 250 Address" for each unique single-label name. 252 The Nonce MUST be a random or good pseudo-random value to foil 253 spoofed replies. An implementation which allows multiple independent 254 processes to send NI queries MAY use the Nonce value to deliver 255 Replies to the correct process. Nonetheless, such processes MUST 256 check the received Nonce and ignore extraneous Replies. 258 If true communication security is required, IPsec [14] should be 259 used. Providing the infrastructure to authenticate NI Queries and 260 Replies may be quite difficult outside of a well-defined community. 262 Upon receiving an NI Query, the Responder must check the Query's IPv6 263 destination address and discard the Query without further processing 264 unless it is one of the Responder's unicast or anycast addresses, or 265 a link-local scope multicast address which the Responder has joined. 266 Typically the latter will be an NI Group Address for a name belonging 267 to the Responder. A node MAY be configured to discard NI Queries to 268 multicast addresses other than its NI Group Address(es) but if so, 269 the default configuration SHOULD be not to discard them. 271 A Responder must also silently discard a Query whose Subject Address 272 or Name (in the Data field) does not belong to that node. A single- 273 component Subject Name matches any fully-qualified name whose first 274 label matches the Subject. All name matching is done in a case- 275 independent manner consistent with DNSSEC name canonicalization [7]. 277 Next, if Qtype is unknown to the Responder, it must return an NI 278 Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should 279 rate-limit such replies as it would ICMPv6 error replies [5]. 281 Next, the Responder should decide whether to refuse an answer, based 282 on local policy. (See "Security Considerations" for recommended 283 default behavior.) If an answer is refused, depending on local 284 policy the Responder can elect to silently discard the query or send 285 an NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the 286 Responder should rate-limit such replies as it would ICMPv6 error 287 replies [5]. 289 Finally, if the Qtype is known and the response is allowed by local 290 policy, the Responder MUST fill in the Flags and Reply Data of the NI 291 Reply in accordance with the definition of the Qtype and transmit the 292 NI Reply. The source address of the NI Reply SHOULD be selected 293 using the rules defined in [9]. 295 If the Query was sent to a multicast address, transmission of the 296 Reply MUST be delayed by a random interval between zero and [Query 297 Response Interval], as defined by Multicast Listener Discovery 298 Version 2 [10]. 300 6. Defined Qtypes 302 The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be 303 supported by any implementation of this protocol. Qtype 4 SHOULD be 304 supported by any implementation of this protocol on an IPv4/IPv6 305 dual-stack node and MAY be supported on an IPv6-only node. 307 +-------------+----------------+ 308 | Qtype Value | Qtype Name | 309 +-------------+----------------+ 310 | 0 | NOOP | 311 | 1 | unused | 312 | 2 | Node Name | 313 | 3 | Node Addresses | 314 | 4 | IPv4 Addresses | 315 +-------------+----------------+ 317 6.1. NOOP 319 This NI type has no defined flags and never has a Data field. A 320 Reply to an NI NOOP Query tells the Querier that a node with the 321 Queried Address is up and reachable and implements the Node 322 Information protocol. On transmission, the ICMPv6 Code in a NOOP 323 Query must be set to 1 and the Code in a NOOP Reply must be 0. On 324 reception of a NOOP Query or Reply, the Code must be ignored. 326 6.2. Node Name 328 The NI Node Name Query requests the fully-qualified or single- 329 component name corresponding to the Subject Address or Name. The 330 Reply Data has the following format. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | TTL | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Node Names ... | 338 + + 339 / / 340 + + 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 2: Node Information Reply Message 346 o TTL - MUST be zero. Any non-zero value received MUST be treated 347 as zero. This field is no longer used but is present to preserve 348 backwards compatibility with older implementations. 350 o Node Names - The fully-qualified or single-component name or names 351 of the Responder which correspond(s) to the Subject Address or 352 Name, in DNS wire format, Section 3.1 of [2]. Each name MUST be 353 fully-qualified if the responder knows the domain suffix, and 354 otherwise be a single DNS label followed by two zero-length 355 labels. When multiple node names are returned and more than one 356 of them is fully-qualified, DNS name compression, Section 4.1.4 of 357 [2], SHOULD be used, and the offsets are counted from the first 358 octet of the Data field. An offset of 4, for example, will point 359 to the beginning of the first name. 361 The Responder must fill in the TTL field of the Reply with zero. 363 Only one TTL is included in the reply. 365 If the Responder does not know its name at all it MUST send a Reply 366 with TTL=0 and no Node Names (or a Reply with Code=1 indicating 367 refusal to answer). The Querier will be able to determine from the 368 packet length that the Data field contains no names. 370 6.3. Node Addresses 372 The NI Node Addresses Query requests some set of the Responder's IPv6 373 unicast addresses. The Reply Data is a sequence of 128-bit IPv6 374 addresses, each address preceded by a separate 32-bit TTL value, with 375 Preferred addresses listed before Deprecated addresses [11], but 376 otherwise in no special order. Five flag bits are defined in the 377 Query, and six in the Reply. 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Qtype=3 | unused |G|S|L|C|A|T| 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 3: Node Information Address Query 387 o G - If set to 1, Global-scope addresses [12] are requested. 389 o S - If set to 1, Site-local addresses [12] are requested. 390 However, Site-local addresses are now deprecated [15] and this 391 flag is for backwards compatibility. 393 o L - If set to 1, Link-local addresses [12] are requested. 395 o C - If set to 1, IPv4-compatible (now deprecated) and IPv4-mapped 396 addresses [3] are requested. Responses SHOULD include IPv4 397 addresses in IPv4-mapped form. 399 o A - If set to 1, all the Responder's unicast addresses (of the 400 specified scope(s)) are requested. If 0, only those addresses are 401 requested which belong to the interface (or any one interface) 402 which has the Subject Address, or which are associated with the 403 Subject Name. 405 o T - Defined in a Reply only, indicates that the set of addresses 406 is incomplete for space reasons. 408 Flags G, S, L, C and A are copied from a Query to the corresponding 409 Reply. 411 The TTL associated with each address MUST be zero. 413 6.4. IPv4 Addresses 415 The NI IPv4 Addresses Query requests some set of the Responder's IPv4 416 unicast addresses. The Reply Data is a sequence of 32-bit IPv4 417 addresses, each address preceded by a 32-bit TTL value. One flag bit 418 is defined in the Query, and two in the Reply. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Qtype=4 | unused |A|T| 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 4: Node Information IPv4 Address Query 428 o A - If set to 1, all the Responder's unicast addresses are 429 requested. If 0, only those addresses are requested which belong 430 to the interface (or any one interface) which has the Subject 431 Address. 433 o T - Defined in a Reply only, indicates that the set of addresses 434 is incomplete for space reasons. 436 Flag A is copied from a Query to the corresponding Reply. 438 The TTL associated with each address MUST be zero. 440 6.4.1. Discussion 442 It is possible that a node may treat IPv4 interfaces and IPv6 443 interfaces as distinct, even though they are associated with the same 444 hardware. When such a node is responding to an NI Query having a 445 Subject Address of one type requesting the other type, and the Query 446 has the A flag set to 0, it SHOULD consider IP interfaces, other than 447 tunnels, associated with the same hardware as being the same 448 interface. 450 7. IANA Considerations 452 ICMPv6 type values 139 and 140 were previously assigned by IANA for 453 this protocol. This document defines three values of the ICMPv6 Code 454 field for each of these ICMPv6 Type values. Additional Code values 455 may be defined using the "Specification Required" criteria from [16]. 456 IANA is requested to establish and maintain a registry for the Code 457 fields associated with the Node Information Query ICMPv6 Types as a 458 part of its ICMPv6 Registry updated in [13]. 460 This document defines five values of Qtype, numbers 0 through 4. 461 Following the policies outlined in [16], new values, and their 462 associated Flags and Reply Data, are to be defined by IETF Consensus. 464 The IANA is requested to assign the IPv6 multicast prefix FF02:0:0:0: 465 0:2:FF00::/104 for use in Node Information Queries as defined in 466 Section 5. It should be noted that this request does conform with 467 the requirements defined in [17]. 469 8. Security Considerations 471 This protocol shares the security issues of ICMPv6 that are 472 documented in the "Security Considerations" section of [5]. 474 This protocol has the potential of revealing information useful to a 475 would-be attacker. An implementation of this protocol MUST have a 476 default configuration which refuses to answer queries from global- 477 scope [3] addresses. 479 Implementations SHOULD apply rate-limiting to NI responses to avoid 480 being used in a denial of service attack. 482 The anti-spoofing Nonce does not give any protection from spoofers 483 who can eavesdrop the Query or the Reply. 485 The information learned via this protocol SHOULD not be trusted for 486 making security relevant decisions unless some other mechanisms 487 beyond the scope of this document is used to authenticate this 488 information. 490 An implementation of this protocol SHOULD provide the ability to 491 control the dissemination of information related to IPv6 Privacy 492 Addresses [18]. The default action of this policy SHOULD NOT provide 493 a response to a Query that contains a node's Privacy Addresses. 495 A node MUST NOT include Privacy Addresses in any Node Addresses 496 response which includes a public address, or for which the source 497 address of the response, the destination address of the request, or 498 the Subject Address of the request, is a public address. Similarly, 499 a node MUST NOT include any address other than the (single) Privacy 500 Address in any Node Addresses response which includes the Privacy 501 Address, or for which the source address of the response, the 502 destination address of the request, or the Subject Address of the 503 request, is the Privacy Address. 505 9. Acknowledgments 507 Alain Durand contributed to this specification and valuable feedback 508 and implementation experience was provided by Jun-Ichiro Hagino and 509 Tatuya Jinmei. Other useful comments were received from Robert Elz, 510 Keith Moore, Elwyn Davies, Pekka Savola, and Dave Thaler. Bob Hinden 511 and Brian Haberman have acted as document editors during the IETF 512 advancement process. 514 This document is not the first proposal of a direct query mechanism 515 for address-to-name translation. The idea had been discussed briefly 516 in the IPng working group and RFC 1788 [19] describes such a 517 mechanism for IPv4. 519 10. References 521 10.1. Normative References 523 [1] Mockapetris, P., "Domain names - concepts and facilities", 524 STD 13, RFC 1034, November 1987. 526 [2] Mockapetris, P., "Domain names - implementation and 527 specification", STD 13, RFC 1035, November 1987. 529 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 530 Addressing Architecture", RFC 3513, April 2003. 532 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 533 Levels", BCP 14, RFC 2119, March 1997. 535 [5] Conta, A. and S. Deering, "Internet Control Message Protocol 536 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 537 Specification", RFC 2463, December 1998. 539 [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 540 Specification", RFC 2460, December 1998. 542 [7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 543 "Resource Records for the DNS Security Extensions", RFC 4034, 544 March 2005. 546 [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 547 April 1992. 549 [9] Draves, R., "Default Address Selection for Internet Protocol 550 version 6 (IPv6)", RFC 3484, February 2003. 552 [10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 553 (MLDv2) for IPv6", RFC 3810, June 2004. 555 [11] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 556 for IP Version 6 (IPv6)", RFC 2461, December 1998. 558 [12] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast 559 Address Format", RFC 3587, August 2003. 561 [13] Conta, A., "Internet Control Message Protocol (ICMPv6) for the 562 Internet Protocol Version 6 (IPv6) Specification", 563 draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005. 565 10.2. Informative References 567 [14] Kent, S. and K. Seo, "Security Architecture for the Internet 568 Protocol", RFC 4301, December 2005. 570 [15] Huitema, C. and B. Carpenter, "Deprecating Site Local 571 Addresses", RFC 3879, September 2004. 573 [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 574 Considerations Section in RFCs", BCP 26, RFC 2434, 575 October 1998. 577 [17] Haberman, B., "Allocation Guidelines for IPv6 Multicast 578 Addresses", RFC 3307, August 2002. 580 [18] Narten, T. and R. Draves, "Privacy Extensions for Stateless 581 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 583 [19] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. 585 Authors' Addresses 587 Matt Crawford 588 Fermilab 589 PO Box 500 590 Batavia, IL 60510 591 US 593 Phone: +1 630 840 3461 594 Email: crawdad@fnal.gov 596 Brian Haberman (editor) 597 Johns Hopkins University Applied Physics Lab 598 11100 Johns Hopkins Road 599 Laurel, MD 20723-6099 600 US 602 Phone: +1 443 778 1319 603 Email: brian@innovationslab.net 605 Intellectual Property Statement 607 The IETF takes no position regarding the validity or scope of any 608 Intellectual Property Rights or other rights that might be claimed to 609 pertain to the implementation or use of the technology described in 610 this document or the extent to which any license under such rights 611 might or might not be available; nor does it represent that it has 612 made any independent effort to identify any such rights. Information 613 on the procedures with respect to rights in RFC documents can be 614 found in BCP 78 and BCP 79. 616 Copies of IPR disclosures made to the IETF Secretariat and any 617 assurances of licenses to be made available, or the result of an 618 attempt made to obtain a general license or permission for the use of 619 such proprietary rights by implementers or users of this 620 specification can be obtained from the IETF on-line IPR repository at 621 http://www.ietf.org/ipr. 623 The IETF invites any interested party to bring to its attention any 624 copyrights, patents or patent applications, or other proprietary 625 rights that may cover technology that may be required to implement 626 this standard. Please address the information to the IETF at 627 ietf-ipr@ietf.org. 629 Disclaimer of Validity 631 This document and the information contained herein are provided on an 632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 634 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 635 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 636 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Copyright Statement 641 Copyright (C) The Internet Society (2006). This document is subject 642 to the rights, licenses and restrictions contained in BCP 78, and 643 except as set forth therein, the authors retain all their rights. 645 Acknowledgment 647 Funding for the RFC Editor function is currently provided by the 648 Internet Society.