idnits 2.17.1 draft-ietf-ipngwg-icmp-name-lookups-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 28, 2000) is 8642 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: '2374' is mentioned on line 434, but not defined == Unused Reference: '2462' is defined on line 594, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1788 (Obsoleted by RFC 6918) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 16 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPng Working Group Matt Crawford 2 Internet Draft Fermilab 3 August 28, 2000 5 IPv6 Node Information Queries 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress." 21 To view the list Internet-Draft Shadow Directories, see 22 http://www.ietf.org/shadow.html. 24 Abstract 26 This document describes a protocol for asking an IPv6 node to supply 27 certain network information, such as its fully-qualified domain 28 name. IPv6 implementation experience has shown that direct queries 29 for a DNS name are useful, and a direct query mechanism for other 30 information has been requested. 32 1. Terminology 34 A "Node Information (or NI) Query" message is sent by a "Querier" 35 node to a "Responder" node in an ICMPv6 packet addressed to the 36 "Queried Address." The Query concerns a "Subject Address" which may 37 differ from the Queried Address, or a "Subject Name". The Responder 38 sends a "Node Information Reply" to the Querier, containing 39 information associated with the node at the Queries address. A node 40 receiving a NI Query will be termed a Responder even if it does not 41 send a Reply. 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in [2119]. 47 Packet fields marked "unused" must be zero on transmission and, 48 aside from inclusion in checksums or message integrity checks, 49 ignored on reception. 51 2. Node Information Messages 53 Two types of Node Information messages, the NI Query and the NI 54 Reply, are carried in ICMPv6 [2463] packets. They have the same 55 format. 57 0 1 2 3 58 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 59 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 60 | Type | Code | Checksum | 61 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 62 | Qtype | Flags | 63 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 64 | | 65 + Nonce + 66 | | 67 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68 | | 69 / Data / 70 | | 71 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 Fields: 75 Type 139 - NI Query. 76 140 - NI Reply. 78 Code For NI Query: 80 0 Indicates that the Data field contains an IPv6 81 address which is the Subject of this Query. 83 1 Indicates that the Data field contains a domain name 84 which is the Subject of this Query, or is empty, as 85 in the case of a NOOP or Supported Qtypes query. 87 2 Indicates that the Data field contains an IPv4 88 address which is the Subject of this Query. 90 For NI Reply: 92 0 Indicates a successful reply. The Reply Data field 93 may or may not be empty. 95 1 Indicates that the Responder refuses to supply the 96 answer. The Reply Data field will be empty. 98 2 Indicates that the Qtype of the Query is unknown to 99 the Responder. The Reply Data field will be empty. 101 Checksum The ICMPv6 checksum. 103 Qtype A 16-bit field which designates the type if information 104 requested in a Query or supplied in a Reply. Its value 105 in a Reply is always copied from the corresponding Query 106 by the Responder. Five values of Qtype are specified in 107 this document. 109 Flags Qtype-specific flags which may be defined for certain 110 Query types and their Replies. Flags not defined for a 111 given Qtype must be zero on transmission and ignored on 112 reception, and must not be copied from a Query to a 113 Reply unless so specified in the definition of the 114 Qtype. 116 Nonce An opaque 64-bit field to help avoid spoofing and/or to 117 aid in matching Replies with Queries. Its value in a 118 Query is chosen by the Querier. Its value in a Reply is 119 always copied from the corresponding Request by the 120 Responder. 122 Data In a Query, the Subject Address or Name. In a Reply, 123 Qtype-specific data present only when the ICMPv6 Code 124 field is zero. The length of the Data may be inferred 125 from the IPv6 header's Payload Length field [2460], the 126 length of the fixed portion of the NI packet and the 127 lengths of the ICMPv6 header and intervening extension 128 headers. 130 Note that the type of information present in the Data field of a 131 Query is inferred from the ICMP Code, while the type of information, 132 if any, in the Data field of a Reply is inferred from the Qtype. 134 When the Subject of a Query is a name, the name MUST be in DNS wire 135 format [1035]. The name may be either a fully-qualified domain 136 name, including the terminating zero-length label, or a single DNS 137 label followed by two zero-length labels. Since a Query contains at 138 most one DNS name, DNS compression will not be used. 140 3. Message Processing 142 The Querier constructs an ICMP NI Query and sends it to the address 143 from which information is wanted. When the Subject of the Query is 144 an IPv6 address, that address will normally be used as the IPv6 145 destination address of the Query, but need not be if the Querier has 146 useful a priori information about the addresses of the target node. 147 An NI Query may also be sent to a multicast address of link-local 148 scope [2373]. 150 When the Subject is a domain name, either fully-qualified or 151 single-component, and the Querier does not have a unicast address 152 for the target node, the query MUST be sent to a link-scope 153 multicast address formed in the following way. The Subject Name is 154 converted to canonical form, as defined by DNS Security [2535], 155 which is uncompressed with all alphabetic characters in lower case. 156 (If additional DNS label types for host names are defined, the rules 157 for canonicalizing those labels will be found in the defining 158 specification.) Compute the MD5 hash [1321] of the first label of 159 the Subject Name -- the portion beginning with the first one-octet 160 length field and up to, but excluding, any subsequent length field. 161 Append the first 32 bits of that 128-bit hash to the prefix 162 FF02:0:0:0:0:2::/96. The resulting multicast address will be termed 163 the "NI Group Address" for the name. 165 The Nonce should be a random or good pseudo-random value to foil 166 spoofed replies. An implementation which allows multiple 167 independent processes to send NI queries MAY use the Nonce value to 168 deliver Replies to the correct process. Nonetheless, such processes 169 MUST check the received Nonce and ignore extraneous Replies. 171 If true communication security is required, IPsec [2401] must be 172 used. 174 Upon receiving a NI Query, the Responder must check the Query's IPv6 175 destination address and discard the Query without further processing 176 unless it is one of the Responder's unicast or anycast addresses, or 177 a link-local scope multicast address which the Responder has joined. 178 Typically the latter will be a NI Group Address for a name belonging 179 to the Responder or a NI Group Address for a name for which the 180 Responder is providing proxy service. A node MAY be configurable to 181 discard NI Queries to multicast addresses other than its NI Group 182 Address(es) but if so, the default configuration MUST be not to 183 discard them. 185 A Responder must also silently discard a Query whose Subject Address 186 or Name (in the Data field) does not belong to that node, unless it 187 is providing proxy service for that Subject. A single-component 188 Subject Name matches any fully-qualified name whose first label 189 matches the Subject. All name matching is done in a case- 190 independent manner consistent with DNSSEC name canonicalization 191 [2535]. 193 Next, if Qtype is unknown to the Responder, it must return a NI 194 Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should 195 rate-limit such replies as it would ICMPv6 error replies [2463, 196 2.4(f)]. 198 Next, the Responder should decide whether to refuse an answer, based 199 on local policy not addressed in this document. If an answer is 200 refused, the Responder may send a NI Reply with ICMPv6 Code = 1 and 201 no Reply Data. Again, the Responder should rate-limit such replies 202 as it would ICMPv6 error replies [2463, 2.4(f)]. 204 Finally, if the Qtype is known and the response is allowed by local 205 policy, the Responder must fill in the Flags and Reply Data of the 206 NI Reply in accordance with the definition of the Qtype and transmit 207 the NI Reply with an ICMPv6 source address equal to the Queried 208 Address, unless that address was an anycast or a multicast address. 209 If the Queried Address was anycast or multicast, the source address 210 for the Reply SHOULD be one belonging to the interface on which the 211 Query was received. 213 If the Query was sent to an anycast or multicast address, 214 transmission of the Reply MUST be delayed by a random interval 215 between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor 216 Discovery [2461]. 218 4. Defined Qtypes 220 The following five Qtypes are defined. The first four (number 0 to 221 3) MUST be supported by any implementation of this protocol. The 222 last one SHOULD be supported by any implementation on an IPv4/IPv6 223 dual-stack node and MAY be supported on an IPv6-only node. 225 0 NOOP. 227 1 Supported Qtypes. 229 2 DNS Name. 231 3 Node Addresses. 233 4 IPv4 Addresses. 235 4.1. NOOP 237 This NI type has no defined flags and never has a Data field. A 238 Reply to a NI NOOP Query tells the Querier that a node with the 239 Queried Address is up and reachable, implements the Node Information 240 protocol, and incidentally happens to reveal whether the Queried 241 Address was an anycast address. On transmission, the ICMPv6 Code in 242 a NOOP Query must be set to 1 and the Code in a NOOP Reply must be 243 0. On reception of a NOOP Query or Reply, the Code must be ignored. 245 4.2. Supported Qtypes 247 This Query contains no Data field. The Reply Data is a bit-vector 248 showing which Qtypes are supported by the Responder. The Reply Data 249 has two variant forms: uncompressed and compressed. The 250 uncompressed Data format is one or more complete 32-bit words, each 251 word a bitmask with the low-order bit in each word corresponding to 252 the lowest numbered Qtype in a group of 32. The first word 253 describes the Responder's support for Qtypes 0 to 31, the second 254 word 32 to 63, and so on. 256 A 1-valued bit indicates support for the corresponding Qtype. The 257 lowest-order four bits in the first 32-bit word must be set to 1, 258 showing support for the four mandatory Qtypes defined in this 259 specification. Thus the Data field of a NI Supported Qtypes Reply 260 from a Responder implementing only the mandatory Qtypes will contain 261 32 bits in the following form: 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |0 0 0 . . . 0 0 0 1 1 1 1| 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 The compressed form of the Reply Data consists of a sequence of 270 blocks, each block consisting of two 16-bit unsigned integers, nWord 271 and nSkip, followed by nWord 32-bit bitmasks describing the 272 Responder's support for 32 consecutive Qtypes. nSkip is a count of 273 32-bit words following the included words which would have been 274 all-zero and have been suppressed. The last block MUST have nSkip = 275 0. As an example, a Responder supporting Qtypes 0, 1, 2, 3, 60, and 276 4097 could express that information with the following Reply Data 277 (nWord and nSkip fields are written in decimal for easier reading): 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | 2 | 126 | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |0 0 0 . . . 0 0 0 1 1 1 1| 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |0 0 0 1 0 0 0 . . . 0 0 0| 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | 1 | 0 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |0 0 0 . . . 0 0 0 1 0| 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 One flag bit is defined. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Qtype=1 | unused |C| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 In a Query, a C-flag set to 1 indicates that the Querier will accept 302 the compressed form of the Reply Data. In a Reply, a C-flag set to 303 1 indicates that the Reply Data is compressed. The compressed form 304 MAY be used in a Reply only if the Query had the C-flag set. 305 Implementations of this specification SHOULD support the compressed 306 form and if they do, SHOULD set the C-flag in all Supported Qtypes 307 Queries and SHOULD use the compressed form in Supported Qtypes 308 Replies (when allowed by the C-flag in the query) if doing so would 309 avoid fragmentation or save significant space in the Reply. 311 4.3. DNS Name 313 The NI DNS Name Query requests the fully-qualified or single- 314 component name corresponding to the Subject Address or Name. The 315 Reply Data has the following format. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | TTL | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | DNS Names ... | 323 + + 324 / / 325 + + 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 TTL The number of seconds that the name may be cached. For 330 compatibility with DNS [1035], this is a 32-bit signed, 331 2's-complement number, which must not be negative. 333 DNS Names The fully-qualified or single-component name or names of 334 the Responder which correspond(s) to the Subject Address 335 or Name, in DNS wire format [1035]. Each name MUST be 336 fully-qualified if the responder knows the domain 337 suffix, and otherwise be a single DNS label followed by 338 two zero-length labels. 340 When multiple DNS names are returned, DNS name 341 compression [1035] SHOULD be used, and the offsets are 342 counted from the first octet of the Data field. An 343 offset of 4, for example, will point to the beginning of 344 the first name. 346 The Responder must fill in the TTL field of the Reply with a 347 meaningful value if possible. That value should be one of the 348 following. 350 The remaining lifetime of a DHCP lease on the Subject Address; 352 The remaining Valid Lifetime of a prefix from which the Subject 353 Address was derived through Stateless Autoconfiguration [2461, 354 2462]; 356 The TTL of an existing AAAA or A6 record which associates the 357 Subject Address with the DNS Name being returned. 359 If the Responder returns multiple names but considers one name to be 360 official or canonical, that name MUST be placed immediately after 361 the TTL. 363 Only one TTL is included in the reply. If the Responder considers 364 different names to be cacheable for different times, the TTL field 365 must be set no larger than the minimum of those times. 367 If the Responder does not know its name at all it MUST send a Reply 368 with TTL=0 and no DNS Names. The Querier will be able to determine 369 from the packet length that the Data field contains only a TTL. 371 One Flag bit is defined, in the Reply only. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Qtype=2 | unused |T| 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 A T-flag set to 1 in a NI DNS Name Reply indicates that the TTL 380 field contains a meaningful value. If the T-flag is 0, the TTL 381 SHOULD be set to zero by the Responder and MUST be ignored by the 382 Querier. 384 If a name rather than an address was the Subject of the Query, the 385 T-flag MUST be zero and the TTL SHOULD be zero. 387 The information in a NI DNS Name Reply with T-flag 1 may be cached 388 and used for the period indicated by that TTL. If a Reply has no 389 TTL (T-flag 0), the information in that Reply must not be used more 390 than once. If the Query was sent by a DNS server on behalf of a DNS 391 client, the result may be returned to that client as a DNS response 392 with TTL zero. However, if the server has the matching AAAA record, 393 either in cache or in an authoritative zone, then the TTL of that 394 record may be used as the missing TTL of the NI DNS Name Reply and 395 the information in the reply may be cached and used for that period. 397 It would be an implementation choice for a server to perform a DNS 398 query for the AAAA or A6 record that matches a received NI DNS Name 399 Reply. This might be done to obtain a TTL to make the Reply 400 cacheable or in anticipation of such a AAAA query from the client 401 that caused the DNS Name Query. 403 4.3.1. Discussion 405 Because a node can only answer a DNS Name Request when it is up and 406 reachable, it may be useful to create a proxy responder for a group 407 of nodes, for example a subnet or a site. Such a mechanism is not 408 addressed here. 410 IPsec can be applied to NI DNS Name messages to achieve greater 411 trust in the information obtained, but such a need may be obviated 412 by applying IPsec directly to some other communication which is 413 going on (or contemplated) between the Querier and Responder. 415 4.4. Node Addresses 417 The NI Node Addresses Query requests some set of the Responder's 418 IPv6 unicast addresses. The Reply Data is a sequence of 128-bit 419 IPv6 addresses, each address preceded by separate a 32-bit TTL 420 value, with Preferred addresses listed before Deprecated addresses 421 [2461], but otherwise in no special order. Five flag bits are 422 defined in the Query, and six in the Reply. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Qtype=3 | unused |G|S|L|C|A|T| 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 G If set to 1, Global-scope addresses [2374] are requested. 432 S If set to 1, Site-local addresses [2374] are requested. 434 L If set to 1, Link-local addresses [2374] are requested. 436 C If set to 1, IPv4-compatible and IPv4-mapped addresses [2373] 437 are requested. 439 A If set to 1, all the Responder's unicast addresses (of the 440 specified scope(s)) are requested. If 0, only those addresses 441 are requested which belong to the interface (or any one 442 interface) which has the Subject Address, or which are 443 associated with the Subject Name. 445 T Defined in a Reply only, indicates that the set of addresses is 446 incomplete for space reasons. 448 Flags G, S, L, C and A are copied from a Query to the corresponding 449 Reply. 451 The TTL associated with each address are to be determined by the 452 rules in section 4.3, applied to the returned address rather than 453 the Subject. If no meaningful caching time can be given for an 454 address, the corresponding TTL field MUST be zero. 456 Each address with non-zero TTL in a NI Node Address Reply may be 457 cached and used for the period indicated by that TTL. If the TTL is 458 zero, the corresponding address must not be used more than once. If 459 the Query was sent by a DNS server on behalf of a DNS client, the 460 result may be returned to that client as a DNS response with TTL 461 zero. 463 IPv4-mapped addresses can only be returned by a Node Information 464 proxy, since they represent addresses of IPv4-only nodes, which 465 perforce do not implement this protocol. 467 4.5. IPv4 Addresses 469 The NI IPv4 Addresses Query requests some set of the Responder's 470 IPv4 unicast addresses. The Reply Data is a sequence of 32-bit IPv4 471 addresses, each address preceded by a 32-bit TTL value. One flag 472 bit is defined in the Query, and two in the Reply. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Qtype=4 | unused |A|T| 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 A If set to 1, all the Responder's unicast addresses are 481 requested. If 0, only those addresses are requested which 482 belong to the interface (or any one interface) which has the 483 Subject Address. 485 T Defined in a Reply only, indicates that the set of addresses is 486 incomplete for space reasons. 488 Flag A is copied from a Query to the corresponding Reply. 490 The TTL associated with each address are to be determined by the 491 rules in section 4.3, applied to the returned address rather than 492 the Subject, excluding the autoconfiguration Valid Lifetime. If no 493 meaningful caching time can be given for an address, the 494 corresponding TTL field MUST be zero. 496 Each address with non-zero TTL in a NI IPv4 Address Reply may be 497 cached and used for the period indicated by that TTL. If the TTL is 498 zero, the corresponding address must not be used more than once. If 499 the Query was sent by a DNS server on behalf of a DNS client, the 500 result may be returned to that client as a DNS response with TTL 501 zero. 503 4.5.1. Discussion 505 It is possible that a node may treat IPv4 interfaces and IPv6 506 interfaces as distinct, even though they are associated with the 507 same hardware. When such a node is responding to a NI Query having 508 a Subject Address of one type requesting the other type, and the 509 Query has the A flag set to 0, it SHOULD consider IP interfaces, 510 other than tunnels, associated with the same hardware as being the 511 same interface. 513 5. IANA Considerations 515 ICMPv6 type values 139 and 140 have been assigned by IANA for this 516 protocol. This document defines three values of the ICMPv6 Code 517 field for each of these ICMPv6 Type values. Additional Code values 518 may be defined only by IETF Consensus [2434]. 520 This document defines five values of Qtype, numbers 0 through 4. 521 Following the policies outlined in "Guidelines for Writing an IANA 522 Considerations Section in RFCs" [2434], new values, and their 523 associated Flags and Reply Data, may be defined as follows. 525 Qtypes 5 through 255, by IETF Consensus. 527 Qtypes 256 through 1023, Specification Required. 529 Qtypes 1024 through 4095, First Come First Served. 531 Qtypes 4096 through 65535, Private Use. 533 Users of Private Use values should note that values above 8000 to 534 9000 are likely to lead to fragmentation of "Supported Qtypes" 535 Replies unless the compressed form of the Reply Data is used. 537 Assignment of the multicast address prefix FF02:0:0:0:0:2::/96 used 538 in section 3 as a destination for IPv6 Node Information Queries is 539 requested. 541 6. Security Considerations 543 The anti-spoofing Nonce does not give any protection from spoofers 544 who can snoop the Query or the Reply. 546 In a large Internet with relatively frequent renumbering, the 547 maintenance of of KEY and SIG records [2535] in the zones used for 548 address-to-name translations will be no easier than the maintenance 549 of the NS, SOA and PTR records themselves, which already appears to 550 be difficult in many cases. The author expects, therefore, that 551 address-to-name mappings, either through the original DNS mechanism 552 or through this new mechanism, will generally be used as only a hint 553 to find more trustworthy information using the returned name as an 554 index. 556 7. Acknowledgments 558 Alain Durand contributed to this specification and valuable feedback 559 and implementation experience was provided by Jun-Ichiro Hagino and 560 Tatuya Jinmei. This document is not the first proposal of a direct 561 query mechanism for address-to-name translation. The idea had been 562 discussed briefly in the IPng working group and RFC 1788 [1788] 563 describes such a mechanism for IPv4. 565 8. References 567 [1035] P. Mockapetris, "Domain Names - Implementation and 568 Specification", RFC 1035, STD 13, November 1987. 570 [1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 571 April 1992. 573 [1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788, April 574 1995. 576 [2119] S. Bradner, "Key words for use in RFCs to Indicate 577 Requirement Levels," RFC 2119, March 1997. 579 [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 580 Architecture", RFC 2373, July 1998. 582 [2401] Kent, S. and R. Atkinson, "Security Architecture for the 583 Internet Protocol", RFC 2401, November 1998. 585 [2434] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an 586 IANA Considerations Section in RFCs", RFC 2434, October 1998. 588 [2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 589 (IPv6) Specification", RFC 2460, December 1998. 591 [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 592 for IP Version 6 (IPv6)", RFC 2461, December 1998. 594 [2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 595 Autoconfiguration", RFC 2462, December 1998. 597 [2463] Conta, A. and S. Deering, "Internet Control Message Protocol 598 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 599 Specification", RFC 2463, December 1998. 601 [2535] D. Eastlake 3rd, "Domain Name System Security Extensions", 602 RFC 2535, March 1999. 604 9. Author's Address 606 Matt Crawford 607 Fermilab MS 368 608 PO Box 500 609 Batavia, IL 60510 610 USA 612 Phone: +1 630 840 3461 614 Email: crawdad@fnal.gov