1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
|
<pre>Network Working Group M. Crawford
Request for Comments: 4620 Fermilab
Category: Experimental B. Haberman, Ed.
JHU APL
August 2006
<span class="h1">IPv6 Node Information Queries</span>
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a protocol for asking an IPv6 node to supply
certain network information, such as its hostname or fully-qualified
domain name. IPv6 implementation experience has shown that direct
queries for a hostname are useful, and a direct query mechanism for
other information has been found useful in serverless environments
and for debugging.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Applicability Statement .........................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-2">2</a>
<a href="#section-4">4</a>. Node Information Messages .......................................<a href="#page-3">3</a>
<a href="#section-5">5</a>. Message Processing ..............................................<a href="#page-5">5</a>
<a href="#section-6">6</a>. Defined Qtypes ..................................................<a href="#page-6">6</a>
<a href="#section-6.1">6.1</a>. NOOP .......................................................<a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. Node Name ..................................................<a href="#page-7">7</a>
<a href="#section-6.3">6.3</a>. Node Addresses .............................................<a href="#page-8">8</a>
<a href="#section-6.4">6.4</a>. IPv4 Addresses .............................................<a href="#page-9">9</a>
<a href="#section-6.4.1">6.4.1</a>. Discussion ..........................................<a href="#page-9">9</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-10">10</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-10">10</a>
<a href="#section-9">9</a>. Acknowledgements ...............................................<a href="#page-11">11</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-11">11</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-11">11</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-12">12</a>
<span class="grey">Crawford & Haberman Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies a mechanism for discovering information about
names and addresses. The applicability of these mechanisms is
currently limited to diagnostic and debugging tools and network
management (e.g., node discovery). In the global internet, the
Domain Name System (DNS) [<a href="#ref-1" title=""Domain names - concepts and facilities"">1</a>][2] is the authoritative source of such
information and this specification is not intended to supplant or
supersede it. In fact, in a well-supported network, the names and
addresses dealt with by this mechanism will be the same ones, with
the same relationships, as those listed in the DNS.
This new Node Information protocol provides facilities that are not
found in the DNS, for example, discovering relationships between
addresses without reference to names. The functions that do overlap
with the DNS may be useful in serverless environments, for debugging,
or in regard to link-local and unique-local addresses [<a href="#ref-3" title=""IP Version 6 Addressing Architecture"">3</a>] that often
will not be listed in the DNS.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Applicability Statement</span>
IPv6 Node Information Queries include the capability to provide
forward and reverse name lookups independent of the DNS by sending
packets directly to IPv6 nodes or groups of nodes.
The applicability of these mechanisms is currently limited to
diagnostic and debugging tools and network management (e.g., node
discovery). These mechanisms can be used to learn the addresses and
names for nodes on the other end of a point-to-point link or nodes on
a shared-medium link such as an Ethernet. This is very useful when
debugging problems or when bringing up IPv6 service where there is no
global routing or DNS name services available. IPv6's large auto-
configured addresses make debugging network problems and bringing up
IPv6 service difficult without these mechanisms. An example of an
IPv6 debugging tool using IPv6 Node Information Queries is the ping6
program in the KAME (<a href="http://www.kame.net">http://www.kame.net</a>), USAGI, and other IPv6
implementations.
The mechanisms defined in this document may have wider applicability
in the future, but any use beyond debugging and diagnostic tools is
left for further study and is beyond the scope of this document.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
A "Node Information Query" (or "NI Query") message is sent by a
"Querier" node to a "Responder" node in an ICMPv6 packet addressed to
the "Queried Address". The Query contains a "Subject Address" (which
may differ from the Queried Address and may be an IPv6 or IPv4
<span class="grey">Crawford & Haberman Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
address) or a "Subject Name". The Responder sends a "Node
Information Reply" to the Querier, containing information associated
with the node at the Queried Address. A node receiving an NI Query
will be termed a Responder even if it does not send a reply.
The word "name" in this document refers to a hostname with or without
the domain. Where necessary, the cases of fully-qualified and
single-label names will be distinguished.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="#ref-4" title=""Key words for use in RFCs to Indicate Requirement Levels"">4</a>].
Packet fields marked "unused" must be zero on transmission and, aside
from inclusion in checksums or message integrity checks, ignored on
reception.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Node Information Messages</span>
Two types of Node Information messages, the NI Query and the NI
Reply, are carried in ICMPv6 [<a href="#ref-5" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">5</a>] packets. They have the same format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nonce +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node Information Messages
Fields:
o Type
* 139 - NI Query
* 140 - NI Reply
<span class="grey">Crawford & Haberman Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
o Code
* For NI Query
+ 0 - Indicates that the Data field contains an IPv6 address
that is the Subject of this Query.
+ 1 - Indicates that the Data field contains a name that is
the Subject of this Query, or is empty, as in the case of a
NOOP.
+ 2 - Indicates that the Data field contains an IPv4 address
that is the Subject of this Query.
* For NI Reply
+ 0 - Indicates a successful reply. The Reply Data field may
or may not be empty.
+ 1 - Indicates that the Responder refuses to supply the
answer. The Reply Data field will be empty.
+ 2 - Indicates that the Qtype of the Query is unknown to the
Responder. The Reply Data field will be empty.
o Checksum - The ICMPv6 checksum.
o Qtype - A 16-bit field that designates the type of information
requested in a Query or supplied in a Reply. Its value in a Reply
is always copied from the corresponding Query by the Responder.
Five values of Qtype are specified in this document.
o Flags - Qtype-specific flags that may be defined for certain Query
types and their Replies. Flags not defined for a given Qtype must
be zero on transmission and ignored on reception, and must not be
copied from a Query to a Reply unless so specified in the
definition of the Qtype.
o Nonce - An opaque 64-bit field to help avoid spoofing and/or to
aid in matching Replies with Queries. Its value in a Query is
chosen by the Querier. Its value in a Reply is always copied from
the corresponding Request by the Responder.
o Data - In a Query, the Subject Address or Name. In a Reply,
Qtype-specific data is present only when the ICMPv6 Code field is
zero. The length of the Data may be inferred from the IPv6
header's Payload Length field [<a href="#ref-6" title=""Internet Protocol, Version 6 (IPv6) Specification"">6</a>], the length of the fixed portion
<span class="grey">Crawford & Haberman Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
of the NI packet, and the lengths of the ICMPv6 header and
intervening extension headers.
Note that the type of information present in the Data field of a
Query is declared by the ICMP Code, whereas the type of information,
if any, in the Data field of a Reply is determined by the Qtype.
When the Subject of a Query is a name, the name MUST be in DNS wire
format [<a href="#ref-2" title=""Domain names - implementation and specification"">2</a>]. The name may be either a fully-qualified domain name,
including the terminating zero-length label, or a single DNS label
followed by two zero-length labels. Since a Query contains at most
one name, DNS name compression MUST NOT be used.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Message Processing</span>
The Querier constructs an ICMP NI Query and sends it to the address
from which information is wanted. When the Subject of the Query is
an IPv6 address, that address will normally be used as the IPv6
destination address of the Query, but need not be if the Querier has
useful a priori information about the addresses of the target node.
An NI Query may also be sent to a multicast address of link-local
scope [<a href="#ref-3" title=""IP Version 6 Addressing Architecture"">3</a>].
When the Subject is a name, either fully-qualified or single-
component, and the Querier does not have a unicast address for the
target node, the query MUST be sent to a link-scope multicast address
formed in the following way. The Subject Name is converted to the
canonical form defined by DNS Security [<a href="#ref-7" title=""Resource Records for the DNS Security Extensions"">7</a>], which is uncompressed
with all alphabetic characters in lowercase. (If additional DNS
label types or character sets for hostnames are defined, the rules
for canonicalizing those labels will be found in their defining
specification.) Compute the MD5 hash [<a href="#ref-8" title=""The MD5 Message-Digest Algorithm"">8</a>] of the first label of the
Subject Name--the portion beginning with the first one-octet length
field and up to, but excluding, any subsequent length field. Append
the first 24 bits of that 128-bit hash to the prefix
FF02:0:0:0:0:2:FF00::/104. The resulting multicast address will be
termed the "NI Group Address" for the name. A node will support an
"NI Group Address" for each unique single-label name.
The Nonce MUST be a random or good pseudo-random value to foil
spoofed replies. An implementation that allows multiple independent
processes to send NI Queries MAY use the Nonce value to deliver
Replies to the correct process. Nonetheless, such processes MUST
check the received Nonce and ignore extraneous Replies.
If true communication security is required, IP Security (IPsec) [<a href="#ref-14" title=""Security Architecture for the Internet Protocol"">14</a>]
should be used. Providing the infrastructure to authenticate NI
<span class="grey">Crawford & Haberman Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
Queries and Replies may be quite difficult outside of a well-defined
community.
Upon receiving an NI Query, the Responder must check the Query's IPv6
destination address and discard the Query without further processing
unless it is one of the Responder's unicast or anycast addresses, or
a link-local scope multicast address that the Responder has joined.
Typically, the latter will be an NI Group Address for a name
belonging to the Responder. A node MAY be configured to discard NI
Queries to multicast addresses other than its NI Group Address(es),
but if so, the default configuration SHOULD be not to discard them.
A Responder must also silently discard a Query whose Subject Address
or Name (in the Data field) does not belong to that node. A single-
component Subject Name matches any fully-qualified name whose first
label matches the Subject. All name matching is done in a case-
independent manner consistent with DNS Security (DNSSEC) name
canonicalization [<a href="#ref-7" title=""Resource Records for the DNS Security Extensions"">7</a>].
Next, if Qtype is unknown to the Responder, it must return an NI
Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should
rate-limit such replies as it would ICMPv6 error replies [<a href="#ref-5" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">5</a>].
Next, the Responder should decide whether to refuse an answer, based
on local policy. (See the "Security Considerations" section for
recommended default behavior.) If an answer is refused, depending on
local policy the Responder can elect to silently discard the query or
send an NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the
Responder should rate-limit such replies as it would ICMPv6 error
replies [<a href="#ref-5" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">5</a>].
Finally, if the Qtype is known and the response is allowed by local
policy, the Responder MUST fill in the Flags and Reply Data of the NI
Reply in accordance with the definition of the Qtype and transmit the
NI Reply. The source address of the NI Reply SHOULD be selected
using the rules defined in [<a href="#ref-9" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">9</a>].
If the Query was sent to a multicast address, transmission of the
Reply MUST be delayed by a random interval between zero and [Query
Response Interval], as defined by Multicast Listener Discovery
Version 2 [<a href="#ref-10" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">10</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Defined Qtypes</span>
The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be
supported by any implementation of this protocol. Qtype 4 SHOULD be
supported by any implementation of this protocol on an IPv4/IPv6
dual-stack node and MAY be supported on an IPv6-only node.
<span class="grey">Crawford & Haberman Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
+-------------+----------------+
| Qtype Value | Qtype Name |
+-------------+----------------+
| 0 | NOOP |
| 1 | unused |
| 2 | Node Name |
| 3 | Node Addresses |
| 4 | IPv4 Addresses |
+-------------+----------------+
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. NOOP</span>
This NI type has no defined flags and never has a Data field. A
Reply to an NI NOOP Query tells the Querier that a node with the
Queried Address is up and reachable and implements the Node
Information protocol. On transmission, the ICMPv6 Code in a NOOP
Query must be set to 1 and the Code in a NOOP Reply must be 0. On
reception of a NOOP Query or Reply, the Code must be ignored.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Node Name</span>
The NI Node Name Query requests the fully-qualified or single-
component name corresponding to the Subject Address or Name. The
Reply Data has the following format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Names ... |
+ +
/ /
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Node Information Reply Message
o TTL (Time to Live) - MUST be zero. Any non-zero value received
MUST be treated as zero. This field is no longer used but is
present to preserve backward compatibility with older
implementations.
o Node Names - The fully-qualified or single-component name or names
of the Responder that correspond(s) to the Subject Address or
Name, in DNS wire format, Section 3.1 of [<a href="#ref-2" title=""Domain names - implementation and specification"">2</a>]. Each name MUST be
fully-qualified if the responder knows the domain suffix;
<span class="grey">Crawford & Haberman Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
otherwise, each name MUST be a single DNS label followed by two
zero-length labels. When multiple node names are returned and
more than one of them is fully-qualified, DNS name compression,
Section 4.1.4 of [<a href="#ref-2" title=""Domain names - implementation and specification"">2</a>], SHOULD be used, and the offsets are counted
from the first octet of the Data field. An offset of 4, for
example, will point to the beginning of the first name.
The Responder must fill in the TTL field of the Reply with zero.
Only one TTL is included in the Reply.
If the Responder does not know its name at all, it MUST send a Reply
with TTL=0 and no Node Names (or a Reply with Code=1 indicating
refusal to answer). The Querier will be able to determine from the
packet length that the Data field contains no names.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Node Addresses</span>
The NI Node Addresses Query requests some set of the Responder's IPv6
unicast addresses. The Reply Data is a sequence of 128-bit IPv6
addresses, with each address preceded by a separate 32-bit TTL value,
with Preferred addresses listed before Deprecated addresses [<a href="#ref-11" title=""Neighbor Discovery for IP Version 6 (IPv6)"">11</a>];
otherwise, they are in no special order. Five flag bits are defined
in the Query and six in the Reply.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype=3 | unused |G|S|L|C|A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Node Information Address Query
o G - If set to 1, Global-scope addresses [<a href="#ref-12" title=""IPv6 Global Unicast Address Format"">12</a>] are requested.
o S - If set to 1, Site-local addresses [<a href="#ref-12" title=""IPv6 Global Unicast Address Format"">12</a>] are requested.
However, Site-local addresses are now deprecated [<a href="#ref-15" title=""Deprecating Site Local Addresses"">15</a>] and this
flag is for backward compatibility.
o L - If set to 1, Link-local addresses [<a href="#ref-12" title=""IPv6 Global Unicast Address Format"">12</a>] are requested.
o C - If set to 1, IPv4-compatible (now deprecated) and IPv4-mapped
addresses [<a href="#ref-3" title=""IP Version 6 Addressing Architecture"">3</a>] are requested. Responses SHOULD include IPv4
addresses in IPv4-mapped form.
o A - If set to 1, all the Responder's unicast addresses (of the
specified scope(s)) are requested. If 0, only those addresses are
requested that belong to the interface (or any one interface) that
<span class="grey">Crawford & Haberman Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
has the Subject Address or that are associated with the Subject
Name.
o T - Defined in a Reply only, indicates that the set of addresses
is incomplete for space reasons.
Flags G, S, L, C, and A are copied from a Query to the corresponding
Reply.
The TTL associated with each address MUST be zero.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. IPv4 Addresses</span>
The NI IPv4 Addresses Query requests some set of the Responder's IPv4
unicast addresses. The Reply Data is a sequence of 32-bit IPv4
addresses, each address preceded by a 32-bit TTL value. One flag bit
is defined in the Query and two in the Reply.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Qtype=4 | unused |A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Node Information IPv4 Address Query
o A - If set to 1, all the Responder's unicast addresses are
requested. If 0, only those addresses are requested that belong
to the interface (or any one interface) that has the Subject
Address.
o T - Defined in a Reply only, indicates that the set of addresses
is incomplete for space reasons.
Flag A is copied from a Query to the corresponding Reply.
The TTL associated with each address MUST be zero.
<span class="h4"><a class="selflink" id="section-6.4.1" href="#section-6.4.1">6.4.1</a>. Discussion</span>
It is possible that a node may treat IPv4 interfaces and IPv6
interfaces as distinct, even though they are associated with the same
hardware. When such a node is responding to an NI Query having a
Subject Address of one type requesting the other type, and the Query
has the A flag set to 0, it SHOULD consider IP interfaces, other than
tunnels, associated with the same hardware as being the same
interface.
<span class="grey">Crawford & Haberman Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
ICMPv6 type values 139 and 140 were previously assigned by IANA for
this protocol. This document defines three values of the ICMPv6 Code
field for each of these ICMPv6 Type values. Additional Code values
may be defined using the "Specification Required" criteria from [<a href="#ref-16" title="">16</a>].
IANA has established and will maintain a registry for the Code fields
associated with the Node Information Query ICMPv6 Types as a part of
its ICMPv6 Registry updated in [<a href="#ref-13" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">13</a>].
This document defines five values of Qtype, numbers 0 through 4.
Following the policies outlined in [<a href="#ref-16" title="">16</a>], new values, and their
associated Flags and Reply Data, are to be defined by IETF Consensus.
The IANA has assigned the IPv6 multicast prefix
FF02:0:0:0:0:2:FF00::/104 for use in Node Information Queries as
defined in <a href="#section-5">Section 5</a>. It should be noted that this assignment does
conform with the requirements defined in [<a href="#ref-17" title=""Allocation Guidelines for IPv6 Multicast Addresses"">17</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
This protocol shares the security issues of ICMPv6 that are
documented in the "Security Considerations" section of [<a href="#ref-5" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">5</a>].
This protocol has the potential of revealing information useful to a
would-be attacker. An implementation of this protocol MUST have a
default configuration that refuses to answer queries from global-
scope [<a href="#ref-3" title=""IP Version 6 Addressing Architecture"">3</a>] addresses.
Implementations SHOULD apply rate-limiting to NI responses to avoid
being used in a denial-of-service attack.
The anti-spoofing Nonce does not give any protection from spoofers
who can eavesdrop the Query or the Reply.
The information learned via this protocol SHOULD NOT be trusted for
making security-relevant decisions unless some other mechanisms
beyond the scope of this document are used to authenticate this
information.
An implementation of this protocol SHOULD provide the ability to
control the dissemination of information related to IPv6 Privacy
Addresses [<a href="#ref-18" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">18</a>]. The default action of this policy SHOULD NOT provide
a response to a Query that contains a node's Privacy Addresses.
A node MUST NOT include Privacy Addresses in any Node Addresses
response that includes a public address, or for which the source
address of the response, the destination address of the request, or
<span class="grey">Crawford & Haberman Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
the Subject Address of the request is a public address. Similarly, a
node MUST NOT include any address other than the (single) Privacy
Address in any Node Addresses response that includes the Privacy
Address, or for which the source address of the response, the
destination address of the request, or the Subject Address of the
request is the Privacy Address.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
Alain Durand contributed to this specification, and valuable feedback
and implementation experience were provided by Jun-Ichiro Hagino and
Tatuya Jinmei. Other useful comments were received from Robert Elz,
Keith Moore, Elwyn Davies, Pekka Savola, and Dave Thaler. Bob Hinden
and Brian Haberman have acted as document editors during the IETF
advancement process.
This document is not the first proposal of a direct query mechanism
for address-to-name translation. The idea had been discussed briefly
in the IPng working group, and <a href="./rfc1788">RFC 1788</a> [<a href="#ref-19" title=""ICMP Domain Name Messages"">19</a>] describes such a
mechanism for IPv4.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Mockapetris, P., "Domain names - concepts and facilities", STD
13, <a href="./rfc1034">RFC 1034</a>, November 1987.
[<a id="ref-2">2</a>] Mockapetris, P., "Domain names - implementation and
specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.
[<a id="ref-3">3</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc4291">RFC 4291</a>, February 2006.
[<a id="ref-4">4</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-5">5</a>] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", <a href="./rfc2463">RFC 2463</a>, December 1998.
[<a id="ref-6">6</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-7">7</a>] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", <a href="./rfc4034">RFC 4034</a>,
March 2005.
<span class="grey">Crawford & Haberman Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
[<a id="ref-8">8</a>] Rivest, R., "The MD5 Message-Digest Algorithm", <a href="./rfc1321">RFC 1321</a>, April
1992.
[<a id="ref-9">9</a>] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", <a href="./rfc3484">RFC 3484</a>, February 2003.
[<a id="ref-10">10</a>] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", <a href="./rfc3810">RFC 3810</a>, June 2004.
[<a id="ref-11">11</a>] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>, December 1998.
[<a id="ref-12">12</a>] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast
Address Format", <a href="./rfc3587">RFC 3587</a>, August 2003.
[<a id="ref-13">13</a>] Conta, A., Deering, S., and M. Gupta, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", <a href="./rfc4443">RFC 4443</a>, March 2006.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-14">14</a>] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-15">15</a>] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", <a href="./rfc3879">RFC 3879</a>, September 2004.
[<a id="ref-16">16</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>, October
1998.
[<a id="ref-17">17</a>] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", <a href="./rfc3307">RFC 3307</a>, August 2002.
[<a id="ref-18">18</a>] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", <a href="./rfc3041">RFC 3041</a>, January 2001.
[<a id="ref-19">19</a>] Simpson, W., "ICMP Domain Name Messages", <a href="./rfc1788">RFC 1788</a>, April 1995.
<span class="grey">Crawford & Haberman Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
Authors' Addresses
Matt Crawford
Fermilab
PO Box 500
Batavia, IL 60510
US
Phone: +1 630 840 3461
EMail: crawdad@fnal.gov
Brian Haberman (editor)
Johns Hopkins University Applied Physics Lab
11100 Johns Hopkins Road
Laurel, MD 20723-6099
US
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
<span class="grey">Crawford & Haberman Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4620">RFC 4620</a> IPv6 Node Information Queries August 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Crawford & Haberman Experimental [Page 14]
</pre>
|
