idnits 2.17.1 draft-ietf-ipngwg-icmp-name-lookups-12.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 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 597. ** 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 (July 12, 2005) is 6856 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) == Missing Reference: '2460' is mentioned on line 213, but not defined == Unused Reference: '10' is defined on line 532, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3484 (ref. '7') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2374 (ref. '9') (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2460 (ref. '10') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '12') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '14') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '15') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 1788 (ref. '16') (Obsoleted by RFC 6918) Summary: 8 errors (**), 0 flaws (~~), 5 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: January 13, 2006 B. Haberman, Ed. 5 JHU APL 6 July 12, 2005 8 IPv6 Node Information Queries 9 draft-ietf-ipngwg-icmp-name-lookups-12 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 January 13, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . . . 10 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 10.1 Normative References . . . . . . . . . . . . . . . . . . . 12 67 10.2 Informative References . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . 14 71 1. Introduction 73 This document specifies a mechanism for discovering information about 74 names and addresses. The applicability of these mechanics 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 mechanics 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 (for example, name lookups in zero configuration 111 networks, global reverse name lookups, etc.), but any use beyond 112 debugging and diagnostic tools is left for further study and is 113 beyond the scope of this document. 115 3. Terminology 117 A "Node Information (or NI) Query" message is sent by a "Querier" 118 node to a "Responder" node in an ICMPv6 packet addressed to the 119 "Queried Address." The Query concerns a "Subject Address" (which may 120 differ from the Queried Address and may be an IPv6 or IPv4 address) 121 or a "Subject Name". The Responder sends a "Node Information Reply" 122 to the Querier, containing information associated with the node at 123 the Queried Address. A node receiving an NI Query will be termed a 124 Responder even if it does not send a reply. 126 The word "name" in this document refers to a hostname with or without 127 the domain. Where necessary, the cases of fully-qalified and single- 128 label names will be distinguished. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [4]. 134 Packet fields marked "unused" must be zero on transmission and, aside 135 from inclusion in checksums or message integrity checks, ignored on 136 reception. 138 4. Node Information Messages 140 Two types of Node Information messages, the NI Query and the NI 141 Reply, are carried in ICMPv6 [5] packets. They have the same format. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type | Code | Checksum | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Qtype | Flags | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | | 151 + Nonce + 152 | | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 / Data / 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Fields: 161 o Type 163 * 139 - NI Query 165 * 140 - NI Reply 167 o Code 169 * For NI Query 171 + 0 - Indicates that the Data field contains an IPv6 address 172 which is the Subject of this Query. 174 + 1 - Indicates that the Data field contains a name which is 175 the Subject of this Query, or is empty, as in the case of a 176 NOOP or Supported Qtypes query. 178 + 2 - Indicates that the Data field contains an IPv4 address 179 which is the Subject of this Query. 181 * For NI Reply 183 + 0 - Indicates a successful reply. The Reply Data field may 184 or may not be empty. 186 + 1 - Indicates that the Responder refuses to supply the 187 answer. The Reply Data field will be empty. 189 + 2 - Indicates that the Qtype of the Query is unknown to the 190 Responder. The Reply Data field will be empty. 192 o Checksum - The ICMPv6 checksum. 194 o Qtype - A 16-bit field which designates the type of information 195 requested in a Query or supplied in a Reply. Its value in a Reply 196 is always copied from the corresponding Query by the Responder. 197 Five values of Qtype are specified in this document. 199 o Flags - Qtype-specific flags which may be defined for certain 200 Query types and their Replies. Flags not defined for a given 201 Qtype must be zero on transmission and ignored on reception, and 202 must not be copied from a Query to a Reply unless so specified in 203 the definition of the Qtype. 205 o Nonce - An opaque 64-bit field to help avoid spoofing and/or to 206 aid in matching Replies with Queries. Its value in a Query is 207 chosen by the Querier. Its value in a Reply is always copied from 208 the corresponding Request by the Responder. 210 o Data - In a Query, the Subject Address or Name. In a Reply, 211 Qtype-specific data present only when the ICMPv6 Code field is 212 zero. The length of the Data may be inferred from the IPv6 213 header's Payload Length field [2460], the length of the fixed 214 portion of the NI packet and the lengths of the ICMPv6 header and 215 intervening extension headers. 217 Note that the type of information present in the Data field of a 218 Query is declared by the ICMP Code, while the type of information, if 219 any, in the Data field of a Reply is determined by the Qtype. 221 When the Subject of a Query is a name, the name MUST be in DNS wire 222 format [2]. The name may be either a fully-qualified domain name, 223 including the terminating zero-length label, or a single DNS label 224 followed by two zero-length labels. Since a Query contains at most 225 one name, DNS name compression MUST NOT be used. 227 5. Message Processing 229 The Querier constructs an ICMP NI Query and sends it to the address 230 from which information is wanted. When the Subject of the Query is 231 an IPv6 address, that address will normally be used as the IPv6 232 destination address of the Query, but need not be if the Querier has 233 useful a priori information about the addresses of the target node. 234 An NI Query may also be sent to a multicast address of link-local 235 scope [3]. 237 When the Subject is a name, either fully-qualified or single- 238 component, and the Querier does not have a unicast address for the 239 target node, the query MUST be sent to a link-scope multicast address 240 formed in the following way. The Subject Name is converted to the 241 canonical form defined by DNS Security [6], which is uncompressed 242 with all alphabetic characters in lower case. (If additional DNS 243 label types or character sets for host names are defined, the rules 244 for canonicalizing those labels will be found in their defining 245 specification.) Compute the MD5 hash [11] of the first label of the 246 Subject Name -- the portion beginning with the first one-octet length 247 field and up to, but excluding, any subsequent length field. Append 248 the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0: 249 2::/96. The resulting multicast address will be termed the "NI Group 250 Address" for the name. A node will support an "NI Group Address" for 251 each associated Subject Name. 253 The Nonce should be a random or good pseudo-random value to foil 254 spoofed replies. An implementation which allows multiple independent 255 processes to send NI queries MAY use the Nonce value to deliver 256 Replies to the correct process. Nonetheless, such processes MUST 257 check the received Nonce and ignore extraneous Replies. 259 If true communication security is required, IPsec [12] MUST be used. 260 Providing the infrastructure to authenticate NI Queries and Replies 261 may be quite difficult outside of a well-defined community. 263 Upon receiving an NI Query, the Responder must check the Query's IPv6 264 destination address and discard the Query without further processing 265 unless it is one of the Responder's unicast or anycast addresses, or 266 a link-local scope multicast address which the Responder has joined. 267 Typically the latter will be an NI Group Address for a name belonging 268 to the Responder. A node MAY be configured to discard NI Queries to 269 multicast addresses other than its NI Group Address(es) but if so, 270 the default configuration MUST be not to discard them. 272 A Responder must also silently discard a Query whose Subject Address 273 or Name (in the Data field) does not belong to that node. A single- 274 component Subject Name matches any fully-qualified name whose first 275 label matches the Subject. All name matching is done in a case- 276 independent manner consistent with DNSSEC name canonicalization [6]. 278 Next, if Qtype is unknown to the Responder, it must return an NI 279 Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should 280 rate-limit such replies as it would ICMPv6 error replies [5]. 282 Next, the Responder should decide whether to refuse an answer, based 283 on local policy. (See "Security Considerations" for recommended 284 default behavior.) If an answer is refused, the Responder may 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 [7]. 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 297 MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor Discovery [8]. 299 6. Defined Qtypes 301 The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be 302 supported by any implementation of this protocol. Qtype 4 SHOULD be 303 supported by any implementation of this protocol on an IPv4/IPv6 304 dual-stack node and MAY be supported on an IPv6-only node. 306 +-------------+----------------+ 307 | Qtype Value | Qtype Name | 308 +-------------+----------------+ 309 | 0 | NOOP | 310 | 1 | unused | 311 | 2 | Node Name | 312 | 3 | Node Addresses | 313 | 4 | IPv4 Addresses | 314 +-------------+----------------+ 316 6.1 NOOP 318 This NI type has no defined flags and never has a Data field. A 319 Reply to an NI NOOP Query tells the Querier that a node with the 320 Queried Address is up and reachable, implements the Node Information 321 protocol, and incidentally happens to reveal whether the Queried 322 Address was an anycast address. On transmission, the ICMPv6 Code in 323 a NOOP Query must be set to 1 and the Code in a NOOP Reply must be 0. 324 On 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 o TTL - MUST be zero. Any non-zero value received MUST be treated 345 as zero. This field is no longer used but is present to preserve 346 backwards compatibility with older implementations. 348 o Node Names - The fully-qualified or single-component name or names 349 of the Responder which correspond(s) to the Subject Address or 350 Name, in DNS wire format [2]. Each name MUST be fully-qualified 351 if the responder knows the domain suffix, and otherwise be a 352 single DNS label followed by two zero-length labels. When 353 multiple node names are returned and more than one of them is 354 fully-qualified, DNS name compression [2] SHOULD be used, and the 355 offsets are counted from the first octet of the Data field. An 356 offset of 4, for example, will point to the beginning of the first 357 name. 359 The Responder must fill in the TTL field of the Reply with zero. 361 Only one TTL is included in the reply. 363 If the Responder does not know its name at all it MUST send a Reply 364 with TTL=0 and no Node Names (or a Reply with Code=1 indicating 365 refusal to answer). The Querier will be able to determine from the 366 packet length that the Data field contains no names. 368 6.3 Node Addresses 370 The NI Node Addresses Query requests some set of the Responder's IPv6 371 unicast addresses. The Reply Data is a sequence of 128-bit IPv6 372 addresses, each address preceded by a separate 32-bit TTL value, with 373 Preferred addresses listed before Deprecated addresses [8], but 374 otherwise in no special order. Five flag bits are defined in the 375 Query, and six in the Reply. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Qtype=3 | unused |G|S|L|C|A|T| 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 o G - If set to 1, Global-scope addresses [9] are requested. 385 o S - If set to 1, Site-local addresses [9] are requested. However, 386 Site-local addresses are now deprecated [13] and this flag is for 387 backwards compatibility. 389 o L - If set to 1, Link-local addresses [9] are requested. 391 o C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are 392 requested. As the IPv4-compatible addresses are now deprecated, 393 this flag is for backwards compatibility with older 394 implementations, 396 o A - If set to 1, all the Responder's unicast addresses (of the 397 specified scope(s)) are requested. If 0, only those addresses are 398 requested which belong to the interface (or any one interface) 399 which has the Subject Address, or which are associated with the 400 Subject Name. 402 o T Defined in a Reply only, indicates that the set of addresses is 403 incomplete for space reasons. 405 Flags G, S, L, C and A are copied from a Query to the corresponding 406 Reply. 408 The TTL associated with each address MUST be zero. 410 6.4 IPv4 Addresses 412 The NI IPv4 Addresses Query requests some set of the Responder's IPv4 413 unicast addresses. The Reply Data is a sequence of 32-bit IPv4 414 addresses, each address preceded by a 32-bit TTL value. One flag bit 415 is defined in the Query, and two in the Reply. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Qtype=4 | unused |A|T| 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 o A - If set to 1, all the Responder's unicast addresses are 424 requested. If 0, only those addresses are requested which belong 425 to the interface (or any one interface) which has the Subject 426 Address. 428 o T Defined in a Reply only, indicates that the set of addresses is 429 incomplete for space reasons. 431 Flag A is copied from a Query to the corresponding Reply. 433 The TTL associated with each address MUST be zero. 435 6.4.1 Discussion 437 It is possible that a node may treat IPv4 interfaces and IPv6 438 interfaces as distinct, even though they are associated with the same 439 hardware. When such a node is responding to an NI Query having a 440 Subject Address of one type requesting the other type, and the Query 441 has the A flag set to 0, it SHOULD consider IP interfaces, other than 442 tunnels, associated with the same hardware as being the same 443 interface. 445 7. IANA Considerations 447 ICMPv6 type values 139 and 140 were previously assigned by IANA for 448 this protocol. This document defines three values of the ICMPv6 Code 449 field for each of these ICMPv6 Type values. Additional Code values 450 may be defined only by IETF Consensus [14]. 452 This document defines five values of Qtype, numbers 0 through 4. 453 Following the policies outlined in [14], new values, and their 454 associated Flags and Reply Data, are to be defined by IETF Consensus. 456 The IANA is requested to assign the IPv6 multicast prefix FF02:0:0:0: 457 0:2::/96 for use in Node Information Queries as defined in Section 5. 459 8. Security Considerations 461 This protocol shares the security issues of ICMPv6 that are 462 documented in the "Security Considerations" section of [5]. 464 This protocol has the potential of revealing information useful to a 465 would-be attacker. An implementation of this protocol SHOULD have a 466 default configuration which refuses to answer queries from global- 467 scope [3] addresses. 469 Implementations SHOULD apply rate-limiting to NI responses to avoid 470 being used in a denial of service attack. 472 The anti-spoofing Nonce does not give any protection from spoofers 473 who can eavesdrop the Query or the Reply. 475 The information learned via this protocol SHOULD not be trusted for 476 making security relevant decisions unless some other mechanisms 477 beyond the scope of this document is used to authenticate this 478 information. 480 An implementation of this protocol SHOULD provide the ability to 481 control the dissemination of information related to IPv6 Privacy 482 Addresses [15]. The default action of this policy SHOULD NOT provide 483 a reponse to a Query that contains a node's Privacy Addresses. 485 9. Acknowledgments 487 Alain Durand contributed to this specification and valuable feedback 488 and implementation experience was provided by Jun-Ichiro Hagino and 489 Tatuya Jinmei. Other useful comments were received from Robert Elz 490 and Keith Moore. Bob Hinden and Brian Haberman have acted as 491 document editors during the IETF advancement process. 493 This document is not the first proposal of a direct query mechanism 494 for address-to-name translation. The idea had been discussed briefly 495 in the IPng working group and RFC 1788 [16] describes such a 496 mechanism for IPv4. 498 10. References 500 10.1 Normative References 502 [1] Mockapetris, P., "Domain names - concepts and facilities", 503 STD 13, RFC 1034, November 1987. 505 [2] Mockapetris, P., "Domain names - implementation and 506 specification", STD 13, RFC 1035, November 1987. 508 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 509 Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in 510 progress), May 2005. 512 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 513 Levels", BCP 14, RFC 2119, March 1997. 515 [5] Conta, A. and S. Deering, "Internet Control Message Protocol 516 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 517 Specification", RFC 2463, December 1998. 519 [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 520 "Resource Records for the DNS Security Extensions", RFC 4034, 521 March 2005. 523 [7] Draves, R., "Default Address Selection for Internet Protocol 524 version 6 (IPv6)", RFC 3484, February 2003. 526 [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 527 for IP Version 6 (IPv6)", RFC 2461, December 1998. 529 [9] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast 530 Address Format", RFC 2374, July 1998. 532 [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 533 Specification", RFC 2460, December 1998. 535 10.2 Informative References 537 [11] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 538 April 1992. 540 [12] Kent, S. and R. Atkinson, "Security Architecture for the 541 Internet Protocol", RFC 2401, November 1998. 543 [13] Huitema, C. and B. Carpenter, "Deprecating Site Local 544 Addresses", RFC 3879, September 2004. 546 [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 547 Considerations Section in RFCs", BCP 26, RFC 2434, 548 October 1998. 550 [15] Narten, T. and R. Draves, "Privacy Extensions for Stateless 551 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 553 [16] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. 555 Authors' Addresses 557 Matt Crawford 558 Fermilab 559 PO Box 500 560 Batavia, IL 60510 561 US 563 Phone: +1 630 840 3461 564 Email: crawdad@fnal.gov 566 Brian Haberman (editor) 567 Johns Hopkins University Applied Physics Lab 568 11100 Johns Hopkins Road 569 Laurel, MD 20723-6099 570 US 572 Phone: +1 443 778 1319 573 Email: brian@innovationslab.net 575 Intellectual Property Statement 577 The IETF takes no position regarding the validity or scope of any 578 Intellectual Property Rights or other rights that might be claimed to 579 pertain to the implementation or use of the technology described in 580 this document or the extent to which any license under such rights 581 might or might not be available; nor does it represent that it has 582 made any independent effort to identify any such rights. Information 583 on the procedures with respect to rights in RFC documents can be 584 found in BCP 78 and BCP 79. 586 Copies of IPR disclosures made to the IETF Secretariat and any 587 assurances of licenses to be made available, or the result of an 588 attempt made to obtain a general license or permission for the use of 589 such proprietary rights by implementers or users of this 590 specification can be obtained from the IETF on-line IPR repository at 591 http://www.ietf.org/ipr. 593 The IETF invites any interested party to bring to its attention any 594 copyrights, patents or patent applications, or other proprietary 595 rights that may cover technology that may be required to implement 596 this standard. Please address the information to the IETF at 597 ietf-ipr@ietf.org. 599 Disclaimer of Validity 601 This document and the information contained herein are provided on an 602 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 603 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 604 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 605 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 606 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 607 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 609 Copyright Statement 611 Copyright (C) The Internet Society (2005). This document is subject 612 to the rights, licenses and restrictions contained in BCP 78, and 613 except as set forth therein, the authors retain all their rights. 615 Acknowledgment 617 Funding for the RFC Editor function is currently provided by the 618 Internet Society.