-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-ietf-6man-rfc6434-bis-06.xml
1712 lines (1387 loc) · 68.9 KB
/
draft-ietf-6man-rfc6434-bis-06.xml
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
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.35) -->
<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="3"?>
<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>
<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc category="bcp" ipr="trust200902" obsoletes="6434" docName="draft-ietf-6man-rfc6434-bis-06">
<front>
<title>IPv6 Node Requirements</title>
<author fullname="Tim Chown" initials="T." surname="Chown">
<organization> Jisc </organization>
<address>
<postal>
<street> Lumen House, Library Avenue </street>
<city> Harwell Oxford, Didcot</city>
<code> OX11 0SG </code>
<country> United Kingdom </country>
</postal>
<email> tim.chown@jisc.ac.uk </email>
</address>
</author>
<author fullname="John Loughney" initials="J" surname="Loughney">
<organization>Intel</organization>
<address>
<postal>
<street></street>
<city> Santa Clara, CA</city>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>john.loughney@gmail.com</email>
</address>
</author>
<author fullname="Timothy Winters" initials="T." surname="Winters">
<organization abbrev="UNH-IOL">University of New Hampshire, Interoperability Lab (UNH-IOL)</organization>
<address>
<postal>
<street></street>
<city> Durham</city>
<region>NH</region>
<code></code>
<country> United States </country>
</postal>
<email>twinters@iol.unh.edu</email>
</address>
</author>
<date month="March" year="2018" />
<area> Internet </area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>IPv6</keyword>
<keyword>Internet Protocol Version 6</keyword>
<keyword>Internet Protocol</keyword>
<keyword>IP</keyword>
<abstract>
<t>This document defines requirements for IPv6 nodes. It is
expected that IPv6 will be deployed in a wide range of devices and
situations. Specifying the requirements for IPv6 nodes allows
IPv6 to function well and interoperate in a large number of
situations and deployments.</t>
<t>This document obsoletes RFC 6434, and in turn RFC 4294.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document defines common functionality required by both
IPv6 hosts and routers. Many IPv6 nodes will implement optional
or additional features, but this document collects and summarizes
requirements from other published Standards Track documents in one
place.</t>
<t>This document tries to avoid discussion of protocol details
and references RFCs for this purpose. This document is intended
to be an applicability statement and to provide guidance as to which
IPv6 specifications should be implemented in the general case and
which specifications may be of interest to specific deployment
scenarios. This document does not update any individual protocol
document RFCs.</t>
<t>Although this document points to different specifications, it
should be noted that in many cases, the granularity of a
particular requirement will be smaller than a single specification,
as many specifications define multiple, independent pieces, some
of which may not be mandatory. In addition, most specifications
define both client and server behavior in the same specification,
while many implementations will be focused on only one of those
roles. </t>
<t> This document defines a minimal level of requirement needed
for a device to provide useful internet service and considers a
broad range of device types and deployment scenarios. Because of
the wide range of deployment scenarios, the minimal requirements
specified in this document may not be sufficient for all
deployment scenarios. It is perfectly reasonable (and indeed
expected) for other profiles to define additional or stricter
requirements appropriate for specific usage and deployment
environments. For example, this document does not mandate that all
clients support DHCP, but some deployment scenarios may deem
it appropriate to make such a requirement. For example,
government agencies in the USA have defined profiles for
specialized requirements for IPv6 in target environments (see
<xref target='USGv6' />).</t>
<t>As it is not always possible for an implementer to know the
exact usage of IPv6 in a node, an overriding requirement for IPv6
nodes is that they should adhere to Jon Postel's Robustness
Principle: "Be conservative in what you do, be liberal in what you accept
from others" <xref target='RFC0793' />.</t>
<section title="Scope of This Document">
<t> IPv6 covers many specifications. It is intended that IPv6
will be deployed in many different situations and environments.
Therefore, it is important to develop requirements for IPv6
nodes to ensure interoperability. </t>
<t>This document assumes that all IPv6 nodes meet the minimum
requirements specified here.</t>
</section>
<section title="Description of IPv6 Nodes">
<t>From the Internet Protocol, Version 6 (IPv6) Specification <xref target='RFC8200' />, we have
the following definitions:</t>
<figure><artwork><![CDATA[
IPv6 node - a device that implements IPv6.
IPv6 router - a node that forwards IPv6 packets not explicitly
addressed to itself.
IPv6 host - any node that is not a router.
]]></artwork></figure>
</section>
</section>
<section title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Abbreviations Used in This Document">
<figure><artwork><![CDATA[
AH Authentication Header
DAD Duplicate Address Detection
ESP Encapsulating Security Payload
ICMP Internet Control Message Protocol
IKE Internet Key Exchange
MIB Management Information Base
MLD Multicast Listener Discovery
MTU Maximum Transmission Unit
NA Neighbor Advertisement
NBMA Non-Broadcast Multiple Access
ND Neighbor Discovery
NS Neighbor Solicitation
NUD Neighbor Unreachability Detection
PPP Point-to-Point Protocol
]]></artwork></figure>
</section>
<section title="Sub-IP Layer">
<t>An IPv6 node must include support for one or more IPv6
link-layer specifications. Which link-layer specifications an
implementation should include will depend upon what link-layers
are supported by the hardware available on the system. It is
possible for a conformant IPv6 node to support IPv6 on some of its
interfaces and not on others. </t>
<t>As IPv6 is run over new layer 2 technologies, it is expected
that new specifications will be issued. In the following, we list some of
the layer 2 technologies for which an IPv6 specification has been developed.
It is provided for informational purposes only and may
not be complete.</t>
<t>
<list style="hanging">
<t hangText="-"> Transmission of IPv6 Packets over Ethernet
Networks <xref target='RFC2464' /></t>
<t hangText="-"> Transmission of IPv6 Packets over Frame
Relay Networks Specification <xref target='RFC2590' /></t>
<t hangText="-"> Transmission of IPv6 Packets over IEEE 1394
Networks <xref target='RFC3146' /></t>
<t hangText="-"> Transmission of IPv6, IPv4, and Address
Resolution Protocol (ARP) Packets over Fibre Channel
<xref target='RFC4338' /></t>
<t hangText="-"> Transmission of IPv6 Packets over IEEE
802.15.4 Networks <xref target='RFC4944' /></t>
<t hangText="-"> Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks
<xref target='RFC5121' /></t>
<t hangText="-"> IP version 6 over PPP
<xref target='RFC5072' /></t>
</list>
</t>
<t> In addition to traditional physical link-layers, it is also
possible to tunnel IPv6 over other protocols. Examples
include:</t>
<t>
<list style="hanging">
<t hangText="-"> Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs) <xref target='RFC4380'
/></t>
<t hangText="-"> Section 3 of "Basic Transition Mechanisms for IPv6
Hosts and Routers" <xref target='RFC4213' /></t>
</list>
</t>
</section>
<section title="IP Layer">
<section title="Internet Protocol Version 6 - RFC 8200">
<t>The Internet Protocol Version 6 is specified in <xref target='RFC8200' />. This specification MUST be supported.</t>
<t>The node MUST follow the packet transmission rules in RFC 8200.</t>
<t>All conformant IPv6 implementations MUST be
capable of sending and receiving IPv6 packets; forwarding
functionality MAY be supported.
Nodes MUST always be able to send, receive, and process
fragment headers. </t>
<t> IPv6 nodes must not create
overlapping fragments. Also, when reassembling an IPv6
datagram, if one or more of its constituent fragments is
determined to be an overlapping fragment, the entire datagram
(and any constituent fragments) must be silently discarded.
See [RFC5722] for more information.</t>
<t>
As recommended in <xref target='RFC8021'/>, nodes MUST NOT
generate atomic fragments, i.e., where the fragment is a whole datagram.
As per <xref target='RFC6946'/>, if a receiving node reassembling
a datagram encounters an atomic fragment,
it should be processed as a fully reassembled packet, and
any other fragments that match this packet should be processed independently.
</t>
<t>
<xref target='RFC6946'/> discusses IPv6 atomic fragments, and
recommends that IPv6 atomic fragments are processed independently
of any other fragments, to protect against fragmentation-based
attacks.
</t>
<t>
To mitigate a variety of potential attacks,
nodes SHOULD avoid using predictable fragment Identification values
in Fragment Headers, as discussed in <xref target='RFC7739'/>.
</t>
<t>All nodes SHOULD support the setting and use of the IPv6 Flow
Label field as defined in the IPv6 Flow Label specification
<xref target='RFC6437' />. Forwarding nodes such as routers and load distributors
MUST NOT depend only on Flow Label values being uniformly
distributed. It is RECOMMENDED that source hosts support the flow
label by setting the Flow Label field for all packets of a given
flow to the same value chosen from an approximation to a discrete
uniform distribution.
</t>
</section>
<section title="Support for IPv6 Extension Headers">
<t>RFC 8200 specifies extension headers and the processing for
these headers.</t>
<t>
Extension headers (except for the Hop-by-Hop Options header) are not
processed, inserted, or deleted by any node along a packet's delivery
path, until the packet reaches the node (or each of the set of nodes,
in the case of multicast) identified in the Destination Address field
of the IPv6 header.
</t>
<t>Any unrecognized extension headers or options MUST be
processed as described in RFC 8200. Note that where
Section 4 of RFC 8200
refers to the action to be taken when a Next Header value
in the current header is not recognized by a node, that action
applies whether the value is an unrecognized Extension
Header or an unrecognized upper layer protocol (ULP). </t>
<t> An IPv6 node MUST be able to process these headers. An
exception is Routing Header type 0 (RH0), which was deprecated
by <xref target='RFC5095' /> due to security concerns and
which MUST be treated as an unrecognized routing type.</t>
<t>
Further, <xref target='RFC7045'/> adds specific requirements for
processing of Extension Headers, in particular that any forwarding
node along an IPv6 packet's path, which forwards the packet for
any reason, SHOULD do so regardless of any extension headers
that are present.
</t>
<t>
As per RFC 8200, when a node fragments an IPv6 datagram,
it MUST include the entire IPv6 Header Chain in the first fragment.
The Per-Fragment headers must
consist of the IPv6 header plus any extension headers that must be
processed by nodes en route to the destination,
that is, all headers up to and including the Routing
header if present, else the Hop-by-Hop Options header if present,
else no extension headers. On reassembly,
if the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem, Code 3, message should be sent to
the source of the fragment, with the Pointer field set to zero.
See <xref target='RFC7112'/> for a discussion of why oversized
IPv6 Extension Header chains are avoided.
</t>
<t>
Defining new IPv6 extension headers is not recommended, unless there
are no existing IPv6 extension headers that can be used by specifying
a new option for that IPv6 extension header. A proposal to specify a
new IPv6 extension header must include a detailed technical
explanation of why an existing IPv6 extension header can not be used
for the desired new function, and in such cases need to follow the format
described in Section 8 of RFC 8200. For further background
reading on this topic, see <xref target='RFC6564'/>.
</t>
</section>
<section title="Protecting a node from excessive EH options">
<t>
As per RFC 8200, end hosts are expected to process all extension headers,
destination options, and hop-by-hop options in a packet. Given that
the only limit on the number and size of extension headers is the MTU,
the processing of received packets could be considerable. It is also
conceivable that a long chain of extension headers might be used as a
form of denial-of-service attack. Accordingly, a host may place limits
on the number and sizes of extension headers and options it is willing
to process.
</t>
<t>
A host MAY limit the number of consecutive PAD1 options in destination
options or hop-by-hop options to seven. In this case, if the more than
seven consecutive PAD1 options are present the packet should be
silently discarded. The rationale is that if padding of eight or more
bytes is required than the PADN option should be used.
</t>
<t>
A host MAY limit number of bytes in a PADN option to be less than
eight. In such a case, if a PADN option is present that has a length
greater than seven then the packet should be silently discarded. The
rationale for this guideline is that the purpose of padding is for
alignment and eight bytes is the maximum alignment used in IPv6.
</t>
<t>
A host MAY disallow unknown options in destination options or
hop-by-hop options. This should be configurable where the default is
to accept unknown options and process them per
<xref target='RFC8200' />. If a packet
with unknown options is received and the host is configured to
disallow them, then the packet should be silently discarded.
</t>
<t>
A host MAY impose a limit on the maximum number of non-padding options
allowed in a destination options and hop-by-hop extension headers. If
this feature is supported the maximum number should be configurable
and the default value SHOULD be set to eight. The limits for
destination options and hop-by-hop options may be separately
configurable. If a packet is received and the number of destination or
hop-by-hop optines exceeds the limit, then the packet should be
silently discarded.
</t>
<t>
A host MAY impose a limit on the maximum length of destination options
or hop-by-hop options extension header. This value should be
configurable and the default is to accept options of any length. If a
packet is received and the length of destination or hop-by-hop options
extension header exceeds the length limit, then the packet should be
silently discarded.
</t>
</section>
<section title="Neighbor Discovery for IPv6 - RFC 4861" anchor="ND">
<t>Neighbor Discovery is defined in <xref target='RFC4861' />; the
definition was updated by <xref target='RFC5942' />. Neighbor Discovery
SHOULD be supported. RFC 4861 states:</t>
<t><list style='hanging'> <t>
Unless specified otherwise (in a document that covers operating IP
over a particular link type) this document applies to all link types.
However, because ND uses link-layer multicast for some of its
services, it is possible that on some link types (e.g., Non-Broadcast
Multi-Access (NBMA) links), alternative protocols or mechanisms to
implement those services will be specified (in the appropriate
document covering the operation of IP over a particular link type).
The services described in this document that are not directly
dependent on multicast, such as Redirects, next-hop determination,
Neighbor Unreachability Detection, etc., are expected to be provided
as specified in this document.
The details of how one uses ND on
NBMA links are addressed in <xref target='RFC2491' />.
</t> </list></t>
<t>Some detailed analysis of Neighbor Discovery follows:</t>
<t>Router Discovery is how hosts locate routers that reside on
an attached link. Hosts MUST support Router Discovery
functionality.</t>
<t>Prefix Discovery is how hosts discover the set of address
prefixes that define which destinations are on-link for an
attached link. Hosts MUST support Prefix Discovery.</t>
<t>Hosts MUST also implement Neighbor Unreachability Detection
(NUD) for all paths between hosts and neighboring nodes. NUD is
not required for paths between routers. However, all nodes MUST
respond to unicast Neighbor Solicitation (NS) messages.</t>
<t>
<xref target='RFC7048'/> discusses NUD, in particular cases
where it behaves too impatiently. It states that if a node
transmits more than a certain number of packets, then it
SHOULD use the exponential backoff of the retransmit timer,
up to a certain threshold point.
</t>
<t>Hosts MUST support the sending of Router Solicitations and
the receiving of Router Advertisements. The ability to
understand individual Router Advertisement options is dependent
on supporting the functionality making use of the particular
option.</t>
<t>
<xref target='RFC7559'/> discusses packet loss resliency
for Router Solicitations, and requires that nodes MUST use
a specific exponential backoff algorithm for RS retransmissions.
</t>
<t>All nodes MUST support the sending and receiving of Neighbor
Solicitation (NS) and Neighbor Advertisement (NA) messages. NS
and NA messages are required for Duplicate Address Detection
(DAD).</t>
<t>Hosts SHOULD support the processing of Redirect
functionality. Routers MUST support the sending of Redirects,
though not necessarily for every individual packet (e.g., due to
rate limiting). Redirects are only useful on networks supporting
hosts. In core networks dominated by routers, Redirects are
typically disabled. The sending of Redirects SHOULD be disabled
by default on backbone routers. They MAY be enabled by default
on routers intended to support hosts on edge networks. </t>
<t> "IPv6 Host-to-Router Load Sharing" <xref target='RFC4311'/> includes additional recommendations on how to select from a
set of available routers. <xref target='RFC4311'/> SHOULD be supported. </t>
</section>
<section title="SEcure Neighbor Discovery (SEND) - RFC 3971">
<t>
SEND <xref target='RFC3971' /> and Cryptographically Generated
Addresses (CGAs) <xref target='RFC3972' /> provide a way to
secure the message exchanges of Neighbor Discovery. SEND
has the potential to address certain classes of spoofing
attacks, but it does not provide specific protection for threats
from off-link attackers.
</t>
<t>
There have been relatively few implementations of SEND
in common operating systems and platforms since its publication in 2005,
and thus deployment experience remains very limited to date.
</t>
<t>At this time, support for SEND is considered optional. Due to the
complexity in deploying SEND, and its heavyweight provisioning,
its deployment is only
likely to be considered where nodes are operating in a
particularly strict security environment.</t>
</section>
<section title="IPv6 Router Advertisement Flags Option - RFC 5175">
<t> Router Advertisements include an 8-bit field of single-bit
Router Advertisement flags. The Router Advertisement Flags
Option extends the number of available flag bits by 48 bits. At
the time of this writing, 6 of the original 8 single-bit flags have
been assigned, while 2 remain available for future
assignment. No flags have been defined that make use of the new
option, and thus, strictly speaking, there is no requirement to
implement the option today. However, implementations that are
able to pass unrecognized options to a higher-level entity that
may be able to understand them (e.g., a user-level process using
a "raw socket" facility) MAY take steps to handle the option in
anticipation of a future usage.</t>
</section>
<section title="Path MTU Discovery and Packet Size">
<section title="Path MTU Discovery - RFC 8201">
<t> "Path MTU Discovery for IP version 6" <xref target='RFC8201' /> SHOULD be
supported. From <xref target='RFC8200' />:</t>
<t><list style='hanging'>
<t> It is strongly recommended that IPv6 nodes implement
Path MTU Discovery <xref target='RFC8201' />, in order to
discover and
take advantage of path MTUs greater than 1280 octets.
However, a minimal IPv6 implementation (e.g., in a boot
ROM) may simply restrict itself to sending packets no
larger than 1280 octets, and omit implementation of Path
MTU Discovery.</t>
</list></t>
<t> The rules in <xref target='RFC8200' /> and
<xref target='RFC5722' /> MUST be followed for packet
fragmentation and reassembly. </t>
<t>
As described in RFC 8201,
nodes implementing Path MTU Discovery and sending packets larger than
the IPv6 minimum link MTU are susceptible to problematic connectivity
if ICMPv6 messages are blocked or not transmitted. For
example, this will result in connections that complete the TCP three-
way handshake correctly but then hang when data is transferred. This
state is referred to as a black-hole connection
<xref target='RFC2923' />. Path MTU
Discovery relies on ICMPv6 Packet Too Big (PTB) to determine the MTU
of the path (and thus these should not be filtered, as per the
recommendation in <xref target='RFC4890' />).
</t>
<t>
An extension to Path MTU Discovery defined in RFC 8201 can be
found in <xref target='RFC4821' />, which defines a method for Packetization
Layer Path MTU Discovery (PLPMTUD) designed for use over paths where
delivery of ICMPv6 messages to a host is not assured.
</t>
</section>
<section title="Minimum MTU considerations">
<t>
While an IPv6 link MTU can be set to 1280 bytes,
it is recommended that for IPv6 UDP in particular,
which includes DNS operation, the sender use a
large MTU if they can, in order to avoid gratuitous
fragmentation-caused packet drops.
</t>
</section>
</section>
<section title="ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443">
<t>ICMPv6 <xref target='RFC4443' /> MUST be supported. "Extended
ICMP to Support Multi-Part Messages" <xref target='RFC4884' />
MAY be supported.</t>
</section>
<section title="Default Router Preferences and More-Specific Routes - RFC 4191">
<t>"Default Router Preferences and More-Specific Routes" <xref target='RFC4191' /> provides support for nodes attached to
multiple (different) networks, each providing routers that
advertise themselves as default routers via Router
Advertisements. In some scenarios, one router may provide
connectivity to destinations the other router does not, and
choosing the "wrong" default router can result in reachability
failures. In order to resolve this scenario IPv6 Nodes MUST implement <xref target='RFC4191' />
and SHOULD implement the Type C host role defined in RFC4191.</t>
</section>
<section title="First-Hop Router Selection - RFC 8028">
<t>
In multihomed scenarios, where a host has more than one prefix,
each allocated by an upstream network that is assumed to implement
BCP 38 ingress filtering, the host may have multiple routers to
choose from.
</t>
<t>Hosts that may be deployed in such multihomed environments
SHOULD follow the guidance given in <xref target='RFC8028' />.
</t>
</section>
<section title="Multicast Listener Discovery (MLD) for IPv6 - RFC 3810" anchor="mld">
<t> Nodes that need to join multicast groups MUST support MLDv2
<xref target='RFC3810' />. MLD is needed by any node that is
expected to receive and process multicast traffic and in particular
MLDv2 is required for support for source-specific multicast (SSM) as
per <xref target='RFC4607' />.
</t>
<t> Previous versions of this document only required MLDv1
(<xref target='RFC2710' />) to be implemented
on all nodes. Since participation of any
MLDv1-only nodes on a link require that all other nodeas on the link then
operate in version 1 compatibility mode, the requirement to support MLDv2
on all nodes was upgraded to a MUST. Further, SSM is now the preferred
multicast distribution method, rather than ASM.</t>
<t>
Note that
Neighbor Discovery (as used on most link types -- see <xref
target="ND" />) depends on multicast and requires that nodes join Solicited
Node multicast addresses.</t>
</section>
<section title="Explicit Congestion Notification (ECN) - RFC 3168">
<t>
An ECN-aware router may set a mark in the IP header in order to signal
impending congestion, rather than dropping a packet. The receiver of
the packet echoes the congestion indication to the sender, which can then
reduce its transmission rate as if it detected a dropped packet.
</t>
<t>Nodes that may be deployed in environments where they would benefit
from such early congestion notification SHOULD implement
<xref target='RFC3168' />. In such cases, the updates presented in
<xref target='RFC8311' /> may also be relevant.
</t>
</section>
</section>
<section title="Addressing and Address Configuration">
<section title="IP Version 6 Addressing Architecture - RFC 4291">
<t>The IPv6 Addressing Architecture <xref target='RFC4291' />
MUST be supported.</t>
<t>The current IPv6 Address Architecture is based on a 64-bit boundary for subnet prefixes.
The reasoning behind this decision is documented in <xref target='RFC7421'/>.
</t>
<t>Implementations MUST also support the Multicast flag updates
documented in <xref target='RFC7371' /> </t>
</section>
<section title="Host Address Availability Recommendations">
<t>
Hosts may be configured with addresses through a variety of methods,
including SLAAC, DHCPv6, or manual configuration.
</t>
<t>
<xref target='RFC7934'/> recommends that networks provide general-purpose end
hosts with multiple global IPv6 addresses when they attach, and it
describes the benefits of and the options for doing so. Routers SHOULD support
<xref target='RFC7934'/> for assigning multiple address to a host. Host SHOULD support
assigning multiple addresses as described in <xref target='RFC7934'/>.
</t>
<t>Nodes SHOULD support the capability to be assigned a prefix per host as
documented in <xref target='RFC8273' />.
Such an approach can offer improved host
isolation and enhanced subscriber management on shared network segments.
</t>
</section>
<section title="IPv6 Stateless Address Autoconfiguration - RFC 4862">
<t>Hosts MUST support IPv6 Stateless Address Autoconfiguration.
It is recommended, as described in <xref target='RFC8064'/>, that unless there
is a specific requirement for MAC addresses to be embedded in
an IID, nodes follow the procedure in <xref target='RFC7217'/> to generate SLAAC-based
addresses, rather than using <xref target='RFC4862' />.
Addresses generated through RFC7217 will be the same
whenever a given device (re)appears on the same subnet (with a
specific IPv6 prefix), but the IID will vary on each subnet visited.
</t>
<t>Nodes that are routers MUST be able to generate link-local
addresses as described in <xref target='RFC4862'/>.</t>
<t>From RFC 4862:</t>
<t><list style='hanging'> <t>
The autoconfiguration process specified in this document
applies only to hosts and not routers. Since host
autoconfiguration uses information advertised by routers,
routers will need to be configured by some other means.
However, it is expected that routers will generate link-local
addresses using the mechanism described in this document. In
addition, routers are expected to successfully pass the
Duplicate Address Detection procedure described in this
document on all addresses prior to assigning them to an
interface.</t> </list></t>
<t>All nodes MUST implement Duplicate Address Detection. Quoting
from Section 5.4 of RFC 4862:</t>
<t><list style='hanging'> <t> Duplicate Address Detection MUST
be performed on all unicast addresses prior to assigning them
to an interface, regardless of whether they are obtained
through stateless autoconfiguration, DHCPv6, or manual
configuration, with the following [exceptions noted therein].
</t> </list></t>
<t>"Optimistic Duplicate Address Detection (DAD) for
IPv6" <xref target='RFC4429' /> specifies a mechanism to reduce
delays associated with generating addresses via Stateless
Address Autoconfiguration <xref target='RFC4862' />. RFC 4429
was developed in conjunction with Mobile IPv6 in order to reduce
the time needed to acquire and configure addresses as devices
quickly move from one network to another, and it is desirable to
minimize transition delays. For general purpose devices, RFC 4429 remains optional at this time.
</t>
<t>
<xref target='RFC7527'/> discusses enhanced DAD, and describes an
algorithm to automate the detection of looped back IPv6 ND messages
used by DAD. Nodes SHOULD implement this behaviour where such
detection is beneficial.
</t>
</section>
<section title="Privacy Extensions for Address Configuration in IPv6 - RFC 4941">
<t>
A node using Stateless Address
Autoconfiguration <xref target='RFC4862' /> to form a globally
unique IPv6 address using its MAC address to generate the IID
will see that IID remain the same on any visited
network, even though the network prefix part changes.
Thus it is possible for 3rd party devices such nodes communicate
with to track the activities of the node as it moves
around the network. Privacy Extensions for Stateless Address
Autoconfiguration <xref target='RFC4941' /> address this
concern by allowing nodes to configure an additional temporary address
where the IID is effectively randomly generated. Privacy addresses
are then used as source addresses for new communications initiated by the node.
</t>
<t> General issues regarding privacy issues for IPv6 addressing are discussed in <xref target='RFC7721' />.
</t>
<t>
RFC 4941 SHOULD be supported. In some scenarios,
such as dedicated servers in a data
center, it provides limited or no benefit, or may complicate network management.
Thus devices implementing this specification MUST provide a way for the
end user to explicitly enable or disable the use of such temporary
addresses.
</t>
<t>Note that RFC4941 can be used independently of traditional SLAAC, or
of RFC7217-based SLAAC.</t>
<t>Implementers of RFC 4941 should be aware that certain
addresses are reserved and should not be chosen for use as
temporary addresses. Consult "Reserved IPv6 Interface
Identifiers" <xref target='RFC5453' /> for more details.
</t>
</section>
<section title="Stateful Address Autoconfiguration (DHCPv6) - RFC 3315" anchor="stateful1">
<t> DHCPv6 <xref target='RFC3315' /> can be used to obtain and
configure addresses. In general, a network may provide for the
configuration of addresses through SLAAC,
DHCPv6, or both. There will be a wide range of IPv6 deployment
models and differences in address assignment requirements,
some of which may require DHCPv6 for stateful address assignment.
Consequently, all hosts SHOULD implement address configuration
via DHCPv6.</t>
<t> In the absence of observed Router Advertisement messages, IPv6 nodes
MAY initiate DHCP to obtain IPv6 addresses
and other configuration information, as described in Section
5.5.2 of <xref target='RFC4862' />.</t>
<t>Where devices are likely to be carried by users and attached
to multiple visisted networks, DHCPv6 client
anonymity profiles SHOULD be supported as described in <xref target='RFC7844' />
to minimise the disclosure of identifying information.
Section 5 of RFC7844 describes operational considerations on the use of
such anonymity profiles.</t>
</section>
<section title="Default Address Selection for IPv6 - RFC 6724">
<t>IPv6 nodes will invariably have multiple addresses configured simultaneously,
and thus will need to choose which addresses to use for which communications.
The rules specified in the Default Address Selection for
IPv6 <xref target='RFC6724' /> document MUST be implemented.
<xref target='RFC8028' /> updates rule 5.5 from <xref target='RFC6724' />; implementations
SHOULD implement this rule.</t>
</section>
</section>
<section title="DNS">
<t>DNS is described in <xref target='RFC1034' />, <xref
target='RFC1035' />, <xref target='RFC3363' />, and <xref
target='RFC3596' />. Not all nodes will need to resolve names;
those that will never need to resolve DNS names do not need to
implement resolver functionality. However, the ability to
resolve names is a basic infrastructure capability on which
applications rely, and most nodes will need to provide
support. All nodes SHOULD implement stub-resolver <xref target='RFC1034'
/> functionality, as in <xref target='RFC1034'/>, Section
5.3.1, with support for:</t>
<t><list style='hanging'>
<t hangText="-">AAAA type Resource Records <xref target='RFC3596' />;</t>
<t hangText="-">reverse addressing in ip6.arpa using PTR records <xref target='RFC3596' />;</t>
<t hangText="-">Extension Mechanisms for DNS (EDNS0) <xref target='RFC6891' /> to allow for DNS packet sizes larger than 512 octets.</t>
</list></t>
<t>Those nodes are RECOMMENDED to support DNS security extensions <xref target='RFC4033' /> <xref target='RFC4034' /> <xref target='RFC4035' />.</t>
<t>A6 Resource Records, which were only ever defined with Experimental status in <xref target='RFC3363' />,
are now classified as Historic, as per <xref target='RFC6563'/>. </t>
</section>
<section title="Configuring Non-Address Information" anchor="OtherConfig">
<section title="DHCP for Other Configuration Information">
<t>DHCP <xref target='RFC3315' /> Specifies a mechanism for IPv6 nodes to obtain
address configuration information (see <xref target="stateful1" />) and to
obtain additional (non-address) configuration. If a host
implementation supports applications or other protocols that
require configuration that is only available via DHCP, hosts
SHOULD implement DHCP. For specialized devices on which no
such configuration need is present, DHCP may not be
necessary.</t>
<t>An IPv6 node can use the subset of DHCP (described in
<xref target='RFC3736' />) to obtain other configuration
information.</t>
<t>If an IPv6 node implements DHCP it MUST implement the DNS options <xref target='RFC3646' />
as most deployments will expect these options are available.</t>
</section>
<section title="Router Advertisements and Default Gateway">
<t>There is no defined DHCPv6 Gateway option.</t>
<t>Nodes using the Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) are thus expected to determine their default router
information and on-link prefix information from received
Router Advertisements.
</t>
</section>
<section title="IPv6 Router Advertisement Options for DNS
Configuration - RFC 8106">
<t>Router Advertisement Options have historically been limited to
those that are critical to basic IPv6 functionality. Originally,
DNS configuration was not included as an RA option, and DHCP
was the recommended way to obtain DNS configuration
information. Over time, the thinking surrounding such an
option has evolved. It is now generally recognized that few
nodes can function adequately without having access to a
working DNS resolver, and thus a
Standards Track document has been published to provide this
capability <xref target='RFC8106' />.</t>
<t>Implementations MUST include support for the DNS RA option
<xref target='RFC8106' />. </t>
</section>
<section title="DHCP Options versus Router Advertisement Options for Host Configuration">
<t> In IPv6, there are two main protocol mechanisms for
propagating configuration information to hosts: Router
Advertisements (RAs) and DHCP. RA options have been
restricted to those deemed essential for basic network
functioning and for which all nodes are configured with exactly
the same information. Examples include the Prefix Information
Options, the MTU option, etc. On the other hand, DHCP has
generally been preferred for configuration of more general
parameters and for parameters that may be client-specific.
Generally speaking, however, there has been a desire
to define only one mechanism for configuring a given option,
rather than defining multiple (different) ways of configuring
the same information.</t>
<t>One issue with having multiple ways of configuring the same
information is that interoperability suffers if a host chooses one
mechanism but the
network operator chooses a different mechanism. For "closed"
environments, where the network operator
has significant influence over what devices connect to the
network and thus what configuration mechanisms they support, the
operator may be able to ensure that a particular mechanism is
supported by all connected hosts. In more open environments,
however, where arbitrary devices may connect (e.g., a WIFI
hotspot), problems can arise. To maximize interoperability in
such environments, hosts would need to implement multiple
configuration mechanisms to ensure interoperability.</t>
</section>
</section>
<section title="Service Discovery Protocols">