rfc9898.original.xml   rfc9898.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
3) --> -ietf-v6ops-nd-considerations-14" number="9898" updates="" obsoletes="" consensu
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft s="true" category="info" submissionType="IETF" tocInclude="true" sortRefs="true"
-ietf-v6ops-nd-considerations-14" category="info" submissionType="IETF" tocInclu symRefs="true" version="3" xml:lang="en">
de="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.28.1 -->
<front> <front>
<title abbrev="nd-considerations">Neighbor Discovery Considerations in IPv6 <title abbrev="ND Considerations">Neighbor Discovery Considerations in IPv6
Deployments</title> Deployments</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-v6ops-nd-considerations- <seriesInfo name="RFC" value="9898"/>
14"/>
<author fullname="XiPeng Xiao"> <author fullname="XiPeng Xiao">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>xipengxiao@huawei.com</email> <email>xipengxiao@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Eduard Vasilenko"> <author fullname="Eduard Vasilenko">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>vasilenko.eduard@huawei.com</email> <email>vasilenko.eduard@huawei.com</email>
skipping to change at line 45 skipping to change at line 45
<address> <address>
<email>gyan.s.mishra@verizon.com</email> <email>gyan.s.mishra@verizon.com</email>
</address> </address>
</author> </author>
<author fullname="Nick Buraglio"> <author fullname="Nick Buraglio">
<organization>Energy Sciences Network</organization> <organization>Energy Sciences Network</organization>
<address> <address>
<email>buraglio@es.net</email> <email>buraglio@es.net</email>
</address> </address>
</author> </author>
<date year="2025" month="June" day="06"/> <date year="2025" month="November"/>
<area>Operations and Management</area> <area>OPS</area>
<workgroup>IPv6 Operations (v6ops) Working Group</workgroup> <workgroup>v6ops</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 57?>
<t>The Neighbor Discovery (ND) protocol is a critical component of the <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<!--[rfced] Authors' Addresses:
Regarding the postal addresses for XiPeng and Eduard,
the markdown file you provided does not match the approved
Internet-Draft in that the postal addresses were removed. Would
you like your postal address information to be included in
the RFC? If so, we will restore it.
-->
<!-- [rfced] Regarding section titles:
a) May we update these section titles as follows? This would make them
consistent in the table of contents (all terms would appear with their
abbreviations) and more closely align with the items in the "ND solution"
column in Table 1. (Part b is about the sections not included in this list.)
Original:
3. Review of DN Mitigation Solutions..............................9
3.1. ND Solution in Mobile Broadband IPv6.....................10
3.2. ND Solution in Fixed Broadband IPv6......................11
3.3. Unique IPv6 Prefix per Host (UPPH).......................12
3.5. Scalable Address Resolution Protocol.....................14
3.9. Gratuitous Neighbor Discovery (GRAND)....................15
Perhaps:
3. Review of ND Mitigation Solutions
3.1. Mobile Broadband IPv6 (MBBv6)
3.2. Fixed Broadband IPv6 (FBBv6)
3.3. Unique IPv6 Prefix per Host (UPPH)
3.5. Scalable Address Resolution Protocol (SARP)
3.9. Gratuitous Neighbor Discovery (GRAND)
b) We note the following inconsistencies between the section titles below and
their respective entries in Table 1. May we make the following updates for
consistency?
i) We were unable to find "Subnet ND" explicitly mentioned in this
section. May we update as follows to match "WiND" in Table 1?
Original:
3.4. Wireless ND and Subnet ND
Perhaps:
3.4. Wireless ND (WiND)
ii) The item for this section appears as "ND TRILL" in Table 1.
May we drop "ARP" from this section title and update as follows?
Original:
3.6. ARP and ND Optimization for TRILL
Perhaps:
3.6. ND Optimization for TRILL
iii) May we update as follows to match Table 1?
Original:
3.7. Proxy ARP/ND in Ethernet Virtual Private Networks (EVPN)
Perhaps:
3.7. ND in Ethernet Virtual Private Networks (ND EVPN)
iv) Section 3.10: The item for this section appears as "SAVI/RA G/G+" in Table 1
.
In addition, we were unable to find "G+" defined in this section. May we
update both this section title and its respective entry in Table 1 as follows?
Original (section title):
3.10. Source Address Validation Improvement (SAVI) and Router
Advertisement Guard
Original (table entry):
SAVI/
RA
G/G+
Perhaps (new section title):
3.10. Source Address Validation Improvement (SAVI) and Router
Advertisement Guard (RA-Guard)
Perhaps (new table entry):
SAVI/
RA-G
-->
<abstract>
<t>The Neighbor Discovery (ND) protocol is a critical component of the
IPv6 architecture. The protocol uses multicast in many messages. It IPv6 architecture. The protocol uses multicast in many messages. It
also assumes a security model where all nodes on a link are trusted. also assumes a security model where all nodes on a link are trusted.
Such a design might be inefficient in some scenarios (e.g., use of Such a design might be inefficient in some scenarios (e.g., use of
multicast in wireless networks) or when nodes are not trustworthy multicast in wireless networks) or when nodes are not trustworthy
(e.g., public access networks). These security and operational (e.g., public access networks). These security and operational
issues and the associated mitigation solutions are documented in issues and the associated mitigation solutions are documented in
more than 20 RFCs. There is a need to track these issues and more than twenty RFCs. There is a need to track these issues and
solutions in a single document.</t> solutions in a single document.</t>
<t>To that aim, this document summarizes the published ND issues and <t>To that aim, this document summarizes the published ND issues and
then describes how all these issues originate from three causes. then describes how all these issues originate from three causes.
Addressing the issues is made simpler by addressing the causes. This Addressing the issues is made simpler by addressing the causes. This
document also analyzes the mitigation solutions and demonstrates document also analyzes the mitigation solutions and demonstrates
that isolating hosts into different subnets and links can help to that isolating hosts into different subnets and links can help to
address the three causes. Guidance is provided for selecting a address the three causes. Guidance is provided for selecting a
suitable isolation method to prevent potential ND issues.</t> suitable isolation method to prevent potential ND issues.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 77?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Neighbor Discovery (ND) <xref target="RFC4861"/> specifies the mechanis ms that IPv6 <t>Neighbor Discovery (ND) <xref target="RFC4861"/> specifies the mechanis ms that IPv6
nodes (hosts and routers) on the same link use to communicate and nodes (hosts and routers) on the same link use to communicate and
learn about each other. Stateless Address Autoconfiguration (SLAAC) learn about each other. Stateless Address Autoconfiguration (SLAAC)
<xref target="RFC4862"/> builds on those ND mechanisms to let nodes configure their <xref target="RFC4862"/> builds on those ND mechanisms to let nodes configure their
own IPv6 addresses. When analyzing the issues nodes may encounter own IPv6 addresses. When analyzing the issues nodes may encounter
with ND, it helps to view the ND messages they exchange throughout with ND, it helps to view the ND messages they exchange throughout
their life-cycle, taking SLAAC into consideration.</t> their life cycle, taking SLAAC into consideration.</t>
<t>For a host, the overall procedure is as follows:</t> <t>For a host, the overall procedure is as follows:</t>
<artwork><![CDATA[ <ol spacing="normal" type="1">
1. LLA DAD: The host forms a Link-Local Address (LLA) and performs <li>LLA DAD: The host forms a Link-Local Address (LLA) and performs
Duplicate Address Detection (DAD) using multicast Neighbor Duplicate Address Detection (DAD) using multicast Neighbor Solicitations
Solicitations (NSs). (NSs).</li>
2. Router Discovery: The host sends multicast Router Solicitations <li>Router discovery: The host sends multicast Router Solicitations (RSs) to
(RSs) to discover a router on the link. The router responds discover a router on the link. The router responds with Router
with Router Advertisements (RAs), providing subnet prefixes and Advertisements (RAs), providing subnet prefixes and other information. The
other information. The host installs a Neighbor Cache Entry host installs a Neighbor Cache Entry (NCE) for that router upon receiving
(NCE) for that router upon receiving the RAs. In contrast, the the RAs. In contrast, the router cannot install an NCE for the host at this
router cannot install an NCE for the host at this moment of the moment of the exchange because the host's global IP address is still
exchange because the host's global IP address is still unknown. unknown. When the router later needs to forward a packet to the host's
When the router later needs to forward a packet to the host's global address, it will perform address resolution and install an NCE for
global address, it will perform address resolution and install the host.</li>
an NCE for the host. <li>GUA DAD: The host forms a Global Unicast Address (GUA) <xref
3. GUA DAD: The host forms a Global Unicast Address (GUA) target="RFC3587"/> or a Unique Local Address (ULA) <xref target="RFC4193"/>
{{RFC3587}} or a Unique Local Address (ULA) {{RFC4193}} and uses and uses multicast NSs for DAD. For simplicity of description, this document
multicast NSs for DAD. For simplicity of description, this will not further distinguish GUA and ULA.</li>
document will not further distinguish GUA and ULA. <li>Next-hop determination and address resolution: When the host needs to
4. Next-hop determination and address resolution: When the host send a packet, it will first determine whether the next hop is a router or
needs to send a packet, it will first determine whether the an on-link host (which is the destination). If the next hop is a router, the
next-hop is a router or an on-link host (which is the host already has the NCE for that router. If the next hop is an on-link
destination). If the next-hop is a router, the host already has host, it will use multicast NSs to perform address resolution for the
the NCE for that router. If the next-hop is an on-link host, it destination host. As a result, the source host installs an NCE for the
will use multicast NSs to perform address resolution for the destination host.</li>
destination host. As a result, the source host installs an NCE <li>Node Unreachability Detection (NUD): The host uses unicast NSs to
for the destination host. determine whether another node with an NCE is still reachable.</li>
5. Node Unreachability Detection (NUD): The host uses unicast NSs <li>Link-layer address change announcement: If a host's link-layer address
to determine whether another node with an NCE is still changes, it may use multicast Node Advertisements (NAs) to announce its new
reachable. link-layer address to other nodes.</li>
6. Link-layer address change announcement: If a host's link-layer </ol>
address changes, it may use multicast Node Advertisements (NAs)
to announce its new link-layer address to other nodes.
]]></artwork>
<t>For a router, the procedure is similar except that there is no <t>For a router, the procedure is similar except that there is no
Router Discovery. Instead, routers perform a Redirect procedure that router discovery. Instead, routers perform a Redirect procedure that
hosts do not have. A router sends a Redirect to inform a node of a hosts do not have. A router sends a Redirect to inform a node of a
better next-hop for the node's traffic.</t> better next hop for the node's traffic.</t>
<!-- [rfced] Introduction: To make this list parallel in structure, may we
adjust the punctuation as follows?
Original:
ND uses multicast in many messages, trusts messages from all nodes,
and routers may install NCEs for hosts on demand when they are to
forward packets to these hosts.
Perhaps:
ND uses multicast in many messages and trusts messages from all nodes;
in addition, routers may install NCEs for hosts on demand when they are to
forward packets to these hosts.
-->
<t>ND uses multicast in many messages, trusts messages from all nodes, <t>ND uses multicast in many messages, trusts messages from all nodes,
and routers may install NCEs for hosts on demand when they are to and routers may install NCEs for hosts on demand when they are to
forward packets to these hosts. These may lead to issues. forward packets to these hosts. These may lead to issues.
Concretely, various ND issues and mitigation solutions have been Concretely, various ND issues and mitigation solutions have been
published in more than 20 RFCs, including:</t> published in more than 20 RFCs, including:</t>
<artwork><![CDATA[
* ND Trust Models and Threats {{RFC3756}}, <!-- [rfced] Introduction:
* Secure ND {{RFC3971}},
* Cryptographically Generated Addresses {{RFC3972}}, a) The items in the list below appear to be a mixture of both RFC titles and
* ND Proxy {{RFC4389}}, "ND issues and mitigation solutions". In addition, some of these terms (e.g.,
* Optimistic ND {{RFC4429}}, Wireless ND (WiND)) do not explicitly appear in the RFCs that follow.
* ND for mobile broadband {{RFC6459}}{{RFC7066}},
* ND for fixed broadband {{TR177}}, May we update these items to their full RFC titles for consistency and
* ND Mediation {{RFC6575}}, clarity? For the list items that contain multiple RFCs, we would separate each
* Operational ND Problems {{RFC6583}}, RFC or reference into a separate bullet point.
* Wireless ND (WiND) {{RFC6775}}{{RFC8505}}{{RFC8928}}{{RFC8929}}{{I-D.ietf-6ma
n-ipv6-over-wireless}}, Original:
* DAD Proxy {{RFC6957}}, Concretely, various ND issues and mitigation solutions have been
* Source Address Validation Improvement {{RFC7039}}, published in more than 20 RFCs, including:
* Router Advertisement Guard {{RFC6105}}{{RFC7113}},
* Enhanced Duplicate Address Detection {{RFC7527}}, . ND Trust Models and Threats [RFC3756],
* Scalable ARP {{RFC7586}}, . Secure ND [RFC3971],
* Reducing Router Advertisements {{RFC7772}}, . Cryptographically Generated Addresses [RFC3972],
* Unique Prefix Per Host {{RFC8273}}, . ND Proxy [RFC4389],
* ND Optimization for Transparent Interconnection of Lots of . Optimistic ND [RFC4429],
Links (TRILL) {{RFC8302}}, . ND for mobile broadband [RFC6459][RFC7066],
* Gratuitous Neighbor Discovery {{RFC9131}},
* Proxy ARP/ND for EVPN {{RFC9161}}, and [etc.]
* Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
IPv6 Prefixes per Client in Large Broadcast Networks {{RFC9663}}. Perhaps:
]]></artwork> Concretely, various ND issues and mitigation solutions have been
published in more than 20 RFCs, including:
* "IPv6 Neighbor Discovery (ND) Trust Models and Threats" [RFC3756]
* "SEcure Neighbor Discovery (SEND)" [RFC3971]
* "Cryptographically Generated Addresses (CGA)" [RFC3972]
* "Neighbor Discovery Proxies (ND Proxy)" [RFC4389]
* "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429]
* "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (
EPS)" [RFC6459]
* "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" [RFC
7066]
[etc.]
b) We note that the title of RFC 4429 is "Optimistic Duplicate Address
Detection (DAD) for IPv6" (rather than "Optimistic ND"); may this be
updated to the full title of RFC 4429?
Original:
. Optimistic ND [RFC4429],
Perhaps:
* "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429]
-->
<ul spacing="normal">
<li>ND Trust Models and Threats <xref target="RFC3756"/></li>
<li>Secure ND <xref target="RFC3971"/></li>
<li>Cryptographically Generated Addresses <xref target="RFC3972"/></li>
<li>ND Proxy <xref target="RFC4389"/></li>
<li>Optimistic ND <xref target="RFC4429"/></li>
<li>ND for mobile broadband <xref target="RFC6459"/> <xref target="RFC7066"/><
/li>
<li>ND for fixed broadband <xref target="TR177"/></li>
<li>ND Mediation <xref target="RFC6575"/></li>
<li>Operational ND Problems <xref target="RFC6583"/></li>
<li>Wireless ND (WiND) <xref target="RFC6775"/> <xref target="RFC8505"/> <xref
target="RFC8928"/> <xref target="RFC8929"/> <xref target="I-D.ietf-6man-ipv6-ov
er-wireless"/></li>
<li>DAD Proxy <xref target="RFC6957"/></li>
<li>Source Address Validation Improvement <xref target="RFC7039"/></li>
<li>Router Advertisement Guard <xref target="RFC6105"/> <xref target="RFC7113"
/></li>
<li>Enhanced Duplicate Address Detection <xref target="RFC7527"/></li>
<li>Scalable ARP <xref target="RFC7586"/></li>
<li>Reducing Router Advertisements <xref target="RFC7772"/></li>
<li>Unique Prefix Per Host <xref target="RFC8273"/></li>
<li>ND Optimization for Transparent Interconnection of Lots of Links (TRILL) <
xref target="RFC8302"/></li>
<li>Gratuitous Neighbor Discovery <xref target="RFC9131"/></li>
<li>Proxy ARP/ND for EVPN <xref target="RFC9161"/></li>
<li>Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixe
s per Client in Large Broadcast Networks <xref target="RFC9663"/></li>
</ul>
<t>This document summarizes these RFCs into a one-stop reference (as of <t>This document summarizes these RFCs into a one-stop reference (as of
the time of writing) for easier access. This document also the time of writing) for easier access. This document also
identifies three causes of the issues and defines three host identifies three causes of the issues and defines three host
isolation methods to address the causes and prevent potential ND isolation methods to address the causes and prevent potential ND
issues.</t> issues.</t>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>This document uses the terms defined in <xref target="RFC4861"/>. Add itional terms <t>This document uses the terms defined in <xref target="RFC4861"/>. Add itional terms
are defined in this section.</t> are defined in this section.</t>
<dl> <dl spacing="normal" newline="false">
<dt>MAC:</dt> <dt>MAC:</dt>
<dd> <dd><t>Media Access Control. To avoid confusion with link-local addres
<t>To avoid confusion with link-local addresses, link-layer ses, link-layer
addresses are referred to as MAC addresses in this document.</t> addresses are referred to as "MAC addresses" in this document.</t></dd
</dd> >
</dl> <dt>Host isolation:</dt>
<t>Host Isolation: <dd>Separating hosts into different subnets or links.</dd>
:separating hosts into different subnets or links.</t> <dt>L3 Isolation:</dt>
<t>L3 Isolation: <dd>Allocating a Unique Prefix per Host (UPPH) <xref
:allocating a unique prefix per host target="RFC8273"/> <xref target="RFC9663"/> so that every host is in
<xref target="RFC8273"/><xref target="RFC9663"/> so that every host i a different subnet. Given that a unique prefix can be allocated per
s in a different host on shared media, hosts in different subnets may be on the same
subnet. Given that a unique prefix can be allocated per host link.</dd>
on shared media, hosts in different subnets may be on the <dt>L2 Isolation:</dt>
same link.</t> <dd>Taking measures to prevent a host from reaching other hosts
<t>L2 Isolation: directly in Layer 2 (L2) so that every host is in a different
:taking measures to prevent a host from reaching other link. Due to the existence of Multi-Link Subnet <xref
hosts directly in Layer 2 (L2) so that every host is in a target="RFC4903"/>, hosts in different links may be in the same
different link. Due to the existence of Multi-Link Subnet subnet. Therefore, L2 Isolation does not imply L3 Isolation, and L3
<xref target="RFC4903"/>, hosts in different links may be in the same Isolation does not imply L2 Isolation either.</dd>
subnet. Therefore, L2 Isolation does not imply L3 Isolation, <dt>L3+L2 Isolation:</dt>
and L3 Isolation does not imply L2 Isolation either.</t> <dd>Applying L3 Isolation and L2 Isolation simultaneously so that
<t>L3+L2 Isolation: every host is in a different subnet and on a different link.</dd>
:applying L3 Isolation and L2 Isolation <dt>Partial L2 Isolation:</dt>
simultaneously so that every host is in a different subnet <dd>Using an L3 ND Proxy <xref target="RFC4389"/> device to
and on a different link.</t> represent the hosts behind it to other hosts in the same
<t>Partial L2 Isolation: subnet. Within the subnet, ND multicast exchange is segmented into
:using an L3 ND proxy <xref target="RFC4389"/> device to multiple smaller scopes, each represented by an ND Proxy device.</dd>
represent the hosts behind it to other hosts in the same </dl>
subnet. Within the subnet, ND multicast exchange is
segmented into multiple smaller scopes, each represented by
an ND proxy device.</t>
</section> </section>
</section> </section>
<section anchor="review-of-inventoried-nd-issues"> <section anchor="review-of-inventoried-nd-issues">
<name>Review of Inventoried ND Issues</name> <name>Review of Inventoried ND Issues</name>
<section anchor="multicast-may-cause-performance-and-reliability-issues"> <section anchor="multicast-may-cause-performance-and-reliability-issues">
<name>Multicast May Cause Performance and Reliability Issues</name> <name>Multicast May Cause Performance and Reliability Issues</name>
<t>In some cases, ND uses multicast for NSs, NAs, RSs, and RAs. While <t>In some cases, ND uses multicast for NSs, NAs, RSs, and RAs. While
multicast can be highly efficient in certain scenarios, e.g., in multicast can be highly efficient in certain scenarios (e.g., in
wired networks, multicast can also be inefficient in other wired networks), multicast can also be inefficient in other
scenarios, e.g., in large L2 networks or wireless networks.</t> scenarios (e.g., in large L2 networks or wireless networks).</t>
<t>Typically, multicast can create a large amount of protocol traffic <t>Typically, multicast can create a large amount of protocol traffic
in large L2 networks. This can consume network bandwidth, increase in large L2 networks. This can consume network bandwidth, increase
processing overhead, and degrade network performance <xref target="RFC7342"/> .</t> processing overhead, and degrade network performance <xref target="RFC7342"/> .</t>
<t>In wireless networks, multicast can be inefficient or even <t>In wireless networks, multicast can be inefficient or even
unreliable due to a higher probability of transmission interference, unreliable due to a higher probability of transmission interference,
lower data rate, and lack of acknowledgements (Section 3.1 of <xref target="R FC9119"/>).</t> lower data rate, and lack of acknowledgements (<xref target="RFC9119" section ="3.1"/>).</t>
<t>Multicast-related performance issues of the various ND messages are <t>Multicast-related performance issues of the various ND messages are
summarized below:</t> summarized below:</t>
<artwork><![CDATA[
* Issue 1: LLA DAD Degrading Performance - in an L2 network of N <!-- [rfced] Please review the following questions regarding the "Issues"
addresses (which can be much larger than the number of hosts, defined in this document.
as each host can have multiple addresses), there can be N such
multicast messages. This may cause performance issues when N is a) May we update the "Issues" to appear in sentence case rather than title
large. case? We would make these changes in Sections 2.1, 2.2, 2.3, and 2.4 and
* Issue 2: Router's Periodic Unsolicited RAs Draining Hosts' wherever else they appear in this document. For example:
Battery - multicast RAs are generally limited to one packet
every MIN_DELAY_BETWEEN_RAS (3 seconds), and there are usually Original:
only one or two routers on the link, so it is unlikely to cause . Issue 1: LLA DAD Degrading Performance
a performance issue. However, for battery-powered hosts, such
messages may wake them up and drain their batteries {{RFC7772}}. Perhaps:
* Issue 3: GUA DAD Degrading Performance - same as in Issue 1. * Issue 1: LLA DAD degrading performance
* Issue 4: Router's Address Resolution for Hosts Degrading
Performance - same as in Issue 1. b) Should the issue names in Section 2.4 match those in Sections 2.1,
* Issue 5: Host's Address Resolution for Hosts Degrading 2.2, and 2.3? For example, the following issue is slightly different in
Performance - same as in Issue 1. Sections 2.1 and 2.4:
* (For Further Study) Hosts' MAC Address Change NAs Degrading
Performance - with randomized and changing MAC addresses In Section 2.1:
{{I-D.ietf-madinas-use-cases}}, there may be many such multicast messages. . Issue 2: Router's Periodic Unsolicited RAs Draining Hosts'
]]></artwork> Battery
<t>In wireless networks, multicast is more likely to cause packet loss.
Because DAD treats no response as no duplicate address detected, In Section 2.4:
packet loss may cause duplicate addresses to be undetected. o Issue 2: Unsolicited RA Draining Host Battery Life.
Multicast reliability issues are summarized below:</t>
<artwork><![CDATA[ c) We note that several Issues contain verbs that end in "-ing" (e.g.,
* Issue 6: LLA DAD Not Completely Reliable in Wireless Networks. "degrading" and "draining"). Would updating these verbs to their forms
* Issue 7: GUA DAD Not Completely Reliable in Wireless Networks. "degrades" and "drains" retain their meaning? This update would clarify the
]]></artwork> subject and object of these "-ing" verbs.
Original:
. Issue 1: LLA DAD Degrading Performance
. Issue 2: Router's Periodic Unsolicited RAs Draining Hosts'
Battery
. Issue 3: GUA DAD Degrading Performance - same as in Issue 1.
. Issue 4: Router's Address Resolution for Hosts Degrading
Performance
. Issue 5: Host's Address Resolution for Hosts Degrading
Performance
Perhaps:
* Issue 1: LLA DAD Degrades Performance
* Issue 2: Router's Periodic Unsolicited RAs Drain Host's Battery
* Issue 3: GUA DAD Degrades Performance
* Issue 4: Router's Address Resolution for Hosts Degrades
Performance
* Issue 5: Host's Address Resolution for Hosts Degrades Performance
d) How may we adjust the verbs in the item below for clarity? (Note that we
have also adjusted this list item so that it is formatted consistently with
the other items.)
Original:
. (For Further Study) Hosts' MAC Address Change NAs Degrading
Performance - with randomized and changing MAC addresses
[MADINAS], there may be many such multicast messages.
Perhaps:
* Issue for further study: Host's MAC Address Changes to NAs Degrades
Performance
With randomized and changing MAC addresses [MADINAS], there may be
many such multicast messages.
-->
<ul spacing="normal">
<li>
<t>Issue 1: LLA DAD Degrading Performance</t>
<t>In an L2 network of N addresses (which can be much larger than the
number of hosts, as each host can have multiple addresses), there can
be N such multicast messages. This may cause performance issues when N
is large.</t>
</li>
<li>
<t>Issue 2: Router's Periodic Unsolicited RAs Draining Host's Battery</t>
<t>Multicast RAs are generally limited to one packet every
MIN_DELAY_BETWEEN_RAS (3 seconds), and there are usually only one or
two routers on the link, so it is unlikely to cause a performance
issue. However, for battery-powered hosts, such messages may wake them
up and drain their batteries <xref target="RFC7772"/>.</t>
</li>
<li>
<t>Issue 3: GUA DAD Degrading Performance</t>
<t>This is the same as in Issue 1.</t>
</li>
<li>
<t>Issue 4: Router's Address Resolution for Hosts Degrading Performance</
t>
<t>This is the same as in Issue 1.</t>
</li>
<li>
<t>Issue 5: Host's Address Resolution for Hosts Degrading Performance</t>
<t>This is the same as in Issue 1.</t>
</li>
<li>
<t>Issue for further study: Host's MAC Address Change NAs Degrading Perfo
rmance</t>
<t>With randomized and changing MAC addresses <xref target="RFC9797"/>,
there may be many such multicast messages.</t>
</li>
</ul>
<t>In wireless networks, multicast is more likely to cause packet loss.
Because DAD treats no response as no duplicate address detected, packet
loss may cause duplicate addresses to be undetected. Multicast
reliability issues are summarized below:</t>
<ul spacing="normal">
<li>
<t>Issue 6: LLA DAD Not Completely Reliable in Wireless Networks</t>
</li>
<li>
<t>Issue 7: GUA DAD Not Completely Reliable in Wireless Networks</t>
</li>
</ul>
<t>Note: IPv6 address collisions are extremely unlikely. As a result, <t>Note: IPv6 address collisions are extremely unlikely. As a result,
these two issues are largely theoretical rather than practical.</t> these two issues are largely theoretical rather than practical.</t>
</section> </section>
<section anchor="trusting-all-hosts-may-cause-on-link-security-issues"> <section anchor="trusting-all-hosts-may-cause-on-link-security-issues">
<name>Trusting-all-hosts May Cause On-link Security Issues</name> <name>Trusting-All-Hosts May Cause On-Link Security Issues</name>
<!--[rfced] Trusting-All-Hosts vs. Trusting-all-nodes
These terms are both used within this document. If they have the same
meaning, how would you like to make this consistent? For example:
Section 2.2:
2.2. Trusting-All-Hosts May Cause On-Link Security Issues
Section 2.4:
These issues stem from three primary causes:
multicast, Trusting-all-nodes, and Router-NCE-on-Demand.
-->
<t>In scenarios such as public access networks, some nodes may not be <t>In scenarios such as public access networks, some nodes may not be
trustworthy. An attacker on the link can cause the following on-link trustworthy. An attacker on the link can cause the following on-link
security issues <xref target="RFC3756"/><xref target="RFC9099"/>:</t> security issues <xref target="RFC3756"/> <xref target="RFC9099"/>:</t>
<artwork><![CDATA[
* Issue 8: Source IP Address Spoofing - an attacker can use <ul spacing="normal">
another node's IP address as the source address of its ND <li>
message to pretend to be that node. The attacker can then <t>Issue 8: Source IP Address Spoofing</t>
launch various Redirect or Denial-of-Service (DoS) attacks. <t>An attacker can use another node's IP address as the source address
* Issue 9: Denial of DAD - an attacker can repeatedly reply to a of its ND message to pretend to be that node. The attacker can then
victim's DAD messages, causing the victim's address launch various Redirect or Denial-of-Service (DoS) attacks.</t>
configuration procedure to fail, resulting in a DoS to the </li>
victim. <li>
* Issue 10: Rogue RAs - an attacker can send RAs to victim hosts <t>Issue 9: Denial of DAD</t>
to pretend to be a router. The attacker can then launch various <t>An attacker can repeatedly reply to a victim's DAD messages, causing
Redirect or DoS attacks. the victim's address configuration procedure to fail, resulting in a
* Issue 11: Spoofed Redirects - an attacker can send forged DoS to the victim.</t>
Redirects to victim hosts to redirect their traffic to the </li>
legitimate router itself. <li>
* Issue 12: Replay Attacks - an attacker can capture valid ND <t>Issue 10: Rogue RAs</t>
messages and replay them later. <t>An attacker can send RAs to victim hosts to pretend to be a
]]></artwork> router. The attacker can then launch various Redirect or DoS
attacks.</t>
</li>
<li>
<t>Issue 11: Spoofed Redirects</t>
<t>An attacker can send forged Redirects to victim hosts to redirect
their traffic to the legitimate router itself.</t>
</li>
<li>
<t>Issue 12: Replay Attacks</t>
<t>An attacker can capture valid ND messages and replay them later.</t>
</li>
</ul>
</section> </section>
<section anchor="router-nce-on-demand-may-cause-forwarding-delay-nce-exhau stion-and-address-accountability-issues"> <section anchor="router-nce-on-demand-may-cause-forwarding-delay-nce-exhau stion-and-address-accountability-issues">
<name>Router-NCE-on-Demand May Cause Forwarding Delay, NCE Exhaustion, a nd Address Accountability Issues</name> <name>Router-NCE-on-Demand May Cause Forwarding Delay, NCE Exhaustion, a nd Address Accountability Issues</name>
<t>When a router needs to forward a packet to a node but does not yet <t>When a router needs to forward a packet to a node but does not yet
have a Neighbor-Cache Entry (NCE) for that node, it first creates an have a Neighbor-Cache Entry (NCE) for that node, it first creates an
NCE in the INCOMPLETE state. The router then multicasts an NS to the NCE in the INCOMPLETE state. The router then multicasts an NS to the
node's solicited-node multicast address. When the destination node's solicited-node multicast address. When the destination
replies with an NA containing its MAC address, the router updates replies with an NA containing its MAC address, the router updates
the NCE with that address and changes its state to REACHABLE, the NCE with that address and changes its state to REACHABLE,
thereby completing the entry. This process is referred to as Router- thereby completing the entry. This process is referred to as "Router&nbhy;NCE
NCE-on-Demand in this document.</t> &nbhy;on&nbhy;Demand" in this document.</t>
<t>Router-NCE-on-Demand can cause the following issues:</t> <t>Router-NCE-on-Demand can cause the following issues:</t>
<t>*Issue 13: NCE Exhaustion - an attacker can send a high volume <ul spacing="normal">
of packets targeting non-existent IP addresses, causing the <li>
router to create numerous NCEs in the INCOMPLETE state. The <t>Issue 13: NCE Exhaustion</t>
resulting resource exhaustion may cause the router to <t>An attacker can send a high volume of packets targeting
malfunction. This vulnerability, described as "NCE Exhaustion" non-existent IP addresses, causing the router to create numerous
in this document, does not require the attacker to be on-link. NCEs in the INCOMPLETE state. The resulting resource exhaustion
* Issue 14: Router Forwarding Delay - when a packet arrives at a may cause the router to malfunction. This vulnerability, described
router, the router buffers it while attempting to determine the as "NCE Exhaustion" in this document, does not require the
host's MAC address. This buffering delays forwarding and, attacker to be on-link.</t>
depending on the router's buffer size, may lead to packet loss. </li>
This delay is referred to as "Router-NCE-on-Demand Forwarding <li>
Delay" in this document. <t>Issue 14: Router Forwarding Delay</t>
* Issue 15: Lack of Address Accountability - with SLAAC, hosts <t>When a packet arrives at a router, the router buffers it while
generate their IP addresses. The router does not become aware attempting to determine the host's MAC address. This buffering
of a host's IP address until an NCE entry is created. With delays forwarding and, depending on the router's buffer size, may
DHCPv6 <xref target="RFC8415"/>, the router may not know the host's addr lead to packet loss. This delay is referred to as
esses "Router&nbhy;NCE&nbhy;on&nbhy;Demand Forwarding Delay" in this docume
unless it performs DHCPv6 snooping. In public access networks, nt.</t>
where subscriber management often relies on IP address (or </li>
prefix) identification, this lack of address accountability <li>
poses a challenge <xref target="I-D.ccc-v6ops-address-accountability"/>. <t>Issue 15: Lack of Address Accountability</t>
Without knowledge of the host's IP <t>With SLAAC, hosts generate their IP addresses. The router does
address, network administrators are unable to effectively not become aware of a host's IP address until an NCE entry is
manage subscribers, which is particularly problematic in public created. With DHCPv6 <xref target="RFC8415"/>, the router may not
access networks. Moreover, once a router has created its NCEs, know the host's addresses unless it performs DHCPv6 snooping. In
ND <xref target="RFC4861"/> provides no mechanism to retrieve them for public access networks, where subscriber management often relies
management or monitoring, as noted in <xref section="2.6.1" sectionForma on IP address (or prefix) identification, this lack of address
t="of" target="RFC9099"/>.</t> accountability poses a challenge <xref
target="I-D.ccc-v6ops-address-accountability"/>. Without knowledge
of the host's IP address, network administrators are unable to
effectively manage subscribers, which is particularly problematic
in public access networks. Moreover, once a router has created its
NCEs, ND <xref target="RFC4861"/> provides no mechanism to
retrieve them for management or monitoring, as noted in <xref
section="2.6.1" sectionFormat="of" target="RFC9099"/>.</t>
</li>
</ul>
</section> </section>
<section anchor="summary-of-nd-issues"> <section anchor="summary-of-nd-issues">
<name>Summary of ND Issues</name> <name>Summary of ND Issues</name>
<t>The ND issues, as discussed in Sections 2.1 to 2.3, are summarized <t>The ND issues, as discussed in Sections <xref target="multicast-may-c ause-performance-and-reliability-issues" format="counter"/>, <xref target="trust ing-all-hosts-may-cause-on-link-security-issues" format="counter"/>, and <xref t arget="router-nce-on-demand-may-cause-forwarding-delay-nce-exhaustion-and-addres s-accountability-issues" format="counter"/>, are summarized
below. These issues stem from three primary causes: multicast, below. These issues stem from three primary causes: multicast,
Trusting-all-nodes, and Router-NCE-on-Demand. Eliminating any of Trusting-all-nodes, and Router-NCE-on-Demand. Eliminating any of
these causes would also mitigate the corresponding issues. These these causes would also mitigate the corresponding issues. These
observations provide guidance for addressing and preventing ND- observations provide guidance for addressing and preventing ND-
related issues.</t> related issues.</t>
<t>(1) Multicast-related issues:</t>
<artwork><![CDATA[ <!-- [rfced] Regarding Table 1
* Performance issues
o Issue 1: LLA DAD Degrading Performance. a) We note that a few RFC numbers appear in the "ND solution" column. For
o Issue 2: Unsolicited RA Draining Host Battery Life. consistency with the other items in this column, what terminology would you
o Issue 3: GUA DAD degrading performance. like to replace these RFC numbers with?
o Issue 4: Router Address Resolution for Hosts Degrading
Performance. (Note that we will also update the section titles that correspond with these
o Issue 5: Host Address Resolution for Other Hosts Degrading table entries to match.)
Performance.
* Reliability issues Original entries in table 1:
o Issue 6: LLA DAD Not Completely Reliable in Wireless
Networks 7772
o Issue 7: GUA DAD Not Completely Reliable in Wireless 6583
Networks 9686
]]></artwork>
<t>(2) Trusting-all-nodes related issues:</t> Corresponding section titles:
<artwork><![CDATA[
o Issue 8: Source IP Address Spoofing 3.8. Reducing Router Advertisements
o Issue 9: Denial of DAD 3.11. RFC 6583 Dealing with NCE Exhaustion Attacks
o Issue 10: Rogue RAs 3.12. Registering Self-generated IPv6 Addresses using DHCPv6
o Issue 11: Spoofed Redirects
o Issue 12: Replay Attacks b) Some abbreviations in this table do not clearly correspond to the
]]></artwork> list of issues in Section 2.4 (e.g., "No A. Acct."). Would you like to
<t>(3) Router-NCE-on-Demand related issues:</t> add a legend above or below Table 1, or add the abbreviations in
<artwork><![CDATA[ Section 2.4? Also, FYI, we updated the abbreviations as shown below.
o Issue 13: NCE Exhaustion
o Issue 14: Router Forwarding Delay Current abbreviations:
o Issue 15: Lack of Address Accountability On-link securi.
]]></artwork> NCE Exhau.
Fwd. Delay
No A. Acct.
Perhaps:
The abbreviations in Table 1 correspond to Section 2.4 as follows.
On-link Sec. = Trusting-all-nodes related issues
NCE Exh. = NCE Exhaustion
Fwd. Delay = Router Forwarding Delay
No Addr. Acc. = Lack of Address Accountability
c) FYI - We renamed the "RFC type" column to "RFC cat." (RFC category)
to align with the text that precedes the table.
d) FYI - We updated "U" to "N/A" to make it clear that the
corresponding items are not specified in RFCs.
Original:
I - Informational
B - Best Current Practice
U - Unknown (not formally defined by the IETF)
Current:
I: Informational
B: Best Current Practice
N/A: Not Applicable (not an RFC)
-->
<ol spacing="normal" type="1">
<li><t>Multicast-related issues:</t>
<ul spacing="normal">
<li><t>Performance issues:</t>
<ul spacing="normal">
<li>Issue 1: LLA DAD Degrading Performance</li>
<li>Issue 2: Unsolicited RA Draining Host Battery Life</li>
<li>Issue 3: GUA DAD degrading performance</li>
<li>Issue 4: Router Address Resolution for Hosts Degrading Performance</li
>
<li>Issue 5: Host Address Resolution for Other Hosts Degrading Performance
</li>
</ul></li>
<li><t>Reliability issues:</t>
<ul spacing="normal">
<li>Issue 6: LLA DAD Not Completely Reliable in Wireless Networks</li>
<li>Issue 7: GUA DAD Not Completely Reliable in Wireless Networks</li>
</ul></li>
</ul></li>
<li><t>Trusting-all-nodes related issues:</t>
<ul spacing="normal">
<li>Issue 8: Source IP Address Spoofing</li>
<li>Issue 9: Denial of DAD</li>
<li>Issue 10: Rogue RAs</li>
<li>Issue 11: Spoofed Redirects</li>
<li>Issue 12: Replay Attacks</li>
</ul></li>
<li><t>Router-NCE-on-Demand related issues:</t>
<ul spacing="normal">
<li>Issue 13: NCE Exhaustion</li>
<li>Issue 14: Router Forwarding Delay</li>
<li>Issue 15: Lack of Address Accountability</li>
</ul>
</li>
</ol>
<t>These issues are potential vulnerabilities and may not manifest in <t>These issues are potential vulnerabilities and may not manifest in
all usage scenarios.</t> all usage scenarios.</t>
<t>When these issues may occur in a specific deployment, it is <t>When these issues may occur in a specific deployment, it is
advisable to consider the mitigation solutions available. They are advisable to consider the mitigation solutions available. They are
described in the following section.</t> described in the following section.</t>
</section> </section>
</section> </section>
<section anchor="review-of-nd-mitigation-solutions"> <section anchor="review-of-nd-mitigation-solutions">
<name>Review of ND Mitigation Solutions</name> <name>Review of ND Mitigation Solutions</name>
<t>Table 1 summarizes ND mitigation solutions available for Issues 1-15 <t><xref target="solutions-table"/> summarizes ND mitigation solutions ava
described in Section 2.4. Similar solutions are grouped, beginning ilable for Issues 1-15
described in <xref target="summary-of-nd-issues" format="default"/>. Similar
solutions are grouped, beginning
with those that address the most issues. Unrelated solutions are with those that address the most issues. Unrelated solutions are
ordered based on the issues (listed in Section 2.4) they address. ordered based on the issues (listed in <xref target="summary-of-nd-issues" fo rmat="default"/>) they address.
Each solution in the table will be explained in a sub-section later, Each solution in the table will be explained in a sub-section later,
where abbreviations in the table are described.</t> where abbreviations in the table are described.</t>
<t>In the table, a letter code indicates the RFC category of the <t>In <xref target="solutions-table"/>, a letter code indicates the RFC ca
mitigation solution (see BCP 9 <xref target="RFC2026"/> for explanation of th tegory of the
ese mitigation solution (see BCP 9 <xref target="RFC2026"/> for an explanation of
these
categories):</t> categories):</t>
<artwork><![CDATA[ <!--[rfced] We suggest removing "Draft Standard" from this list
S - Standards Track (Proposed Standard, Draft Standard, or because that Standards Track maturity level is no longer in use,
Internet Standard) per RFC 6410. (Also, it appears that zero of the ND solutions listed
E - Experimental in Table 1 are specified in a Draft Standard; please review.
I - Informational We note that RFCs 4861 and 4862 are Draft Standards, but they are
B - Best Current Practice not listed in Table 1.)
U - Unknown (not formally defined by the IETF)
]]></artwork> Original:
<artwork><![CDATA[ S - Standards Track (Proposed Standard, Draft Standard, or
+-----+---+-------------------+--------+-------+-------+------+-----+ Internet Standard)
|ND |RFC| Multicast | Reli- |On-link|NCE |Fwd. |No A.|
|solu-|ty-| performance | ability|securi.|Exhau. |Delay |Acct.| Suggested:
|tion |pe |---+---+---+---+---+---+----+-------+-------+------+-----+ S: Standards Track (Proposed Standard or Internet Standard)
| | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8-12 | 13 | 14 | 15 | -->
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
|MBBv6| I | All identified issues solved | <dl spacing="compact" newline="false" indent="5">
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <dt>S:</dt><dd>Standards Track (Proposed Standard, Draft Standard, or Inter
|FBBv6| U | All identified issues solved | net Standard)</dd>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <dt>E:</dt><dd>Experimental</dd>
|UPPH | I | | X | | X | X | | X | | X | X | X | <dt>I:</dt><dd>Informational</dd>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <dt>B:</dt><dd>Best Current Practice</dd>
|WiND | S |All issues solved for Low-Power and Lossy Networks (LLNs)| <dt>N/A:</dt><dd>Not Applicable (not an RFC)</dd>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ </dl>
|SARP | E | | | | | X | | | | | | |
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <table anchor="solutions-table">
|ND | S | | | | | X | | | | | | | <name>Solutions for Identified Issues</name>
|TRILL| | | | | | | | | | | | | <thead>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <tr>
|ND | S | | | | | X | | | | | | | <th rowspan="2">ND solution</th>
|EVPN | | | | | | | | | | | | | <th rowspan="2">RFC cat.</th>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <th colspan="5">Multicast performance</th>
|7772 | B | | X | | | | | | | | | | <th colspan="2">Reliability</th>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <th>On-link sec.</th>
|GRAND| S | | | | X | | | | | | X | | <th>NCE Exh.</th>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <th>Fwd. Delay</th>
|SAVI/| | | | | | | | | | | | | <th>No Addr. Acc.</th>
|RA | I | | | | | | | | X | | | | </tr>
|G/G+ | | | | | | | | | | | | | <tr>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <th align="center">1</th>
|6583 | I | | | | | | | | | X | | | <th align="center">2</th>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <th align="center">3</th>
|9686 | S | | | | | | | | | | | X | <th align="center">4</th>
+-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+ <th align="center">5</th>
Table 1. Solutions for identified issues <th align="center">6</th>
]]></artwork> <th align="center">7</th>
<th align="center">8-12</th>
<th align="center">13</th>
<th align="center">14</th>
<th align="center">15</th>
</tr>
</thead>
<tbody>
<tr>
<td>MBBv6</td>
<td align="center">I</td>
<td colspan="11" align="center">All identified issues solved</td>
</tr>
<tr>
<td>FBBv6</td>
<td align="center">N/A</td>
<td colspan="11" align="center">All identified issues solved</td>
</tr>
<tr>
<td>UPPH</td>
<td align="center">I</td>
<td></td>
<td align="center">X</td>
<td></td>
<td align="center">X</td>
<td align="center">X</td>
<td></td>
<td align="center">X</td>
<td></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td>WiND</td>
<td align="center">S</td>
<td colspan="11" align="center">All issues solved for Low-Power and Lossy
Networks (LLNs)</td>
</tr>
<tr>
<td>SARP</td>
<td align="center">E</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>ND TRILL</td>
<td align="center">S</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>ND EVPN</td>
<td align="center">S</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>7772</td>
<td align="center">B</td>
<td></td>
<td align="center">X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>GRAND</td>
<td align="center">S</td>
<td></td>
<td></td>
<td></td>
<td align="center">X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">X</td>
<td></td>
</tr>
<tr>
<td>SAVI/RA G/G+</td>
<td align="center">I</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>6583</td>
<td align="center">I</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">X</td>
<td></td>
<td></td>
</tr>
<tr>
<td>9686</td>
<td align="center">S</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">X</td>
</tr>
</tbody>
</table>
<section anchor="nd-solution-in-mobile-broadband-ipv6"> <section anchor="nd-solution-in-mobile-broadband-ipv6">
<name>ND Solution in Mobile Broadband IPv6</name> <name>ND Solution in Mobile Broadband IPv6</name>
<t>The IPv6 solution defined in "IPv6 in 3GPP EPS" <xref target="RFC6459 <t>The IPv6 solution defined in "IPv6 in 3rd Generation Partnership
"/>, "IPv6 for Project (3GPP) Evolved Packet System (EPS)" <xref target="RFC6459"/>,
3GPP Cellular Hosts" <xref target="RFC7066"/>, and "Extending an IPv6 /64 Pre "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts"
fix <xref target="RFC7066"/>, and "Extending an IPv6 /64 Prefix from a
from a Third Generation Partnership Project (3GPP) Mobile Interface Third Generation Partnership Project (3GPP) Mobile Interface to a LAN
to a LAN Link" <xref target="RFC7278"/> is called Mobile Broadband IPv6 (MBBv Link" <xref target="RFC7278"/> is called Mobile Broadband IPv6
6) in (MBBv6) in this document. They are Informational RFCs. The key points
this document. They are Informational RFCs. The key points are:</t> are:</t>
<artwork><![CDATA[ <ul spacing="normal">
* Putting every host, e.g., the mobile User Equipment (UE), in a <li><t>Putting every host (e.g., the mobile User Equipment (UE)) in a
Point-to-Point (P2P) link with the router, e.g., the mobile Point-to-Point (P2P) link with the router (e.g., the mobile
gateway. Consequently: gateway) has the following outcomes:</t>
o All multicast is effectively turned into unicast. <ul spacing="normal">
o The P2P links do not have a MAC address. Therefore, Router- <li>All multicast is effectively turned into unicast.</li>
NCE-on-Demand is not needed. <li>The P2P links do not have a MAC address. Therefore, Router-
o Trusting-all-nodes is only relevant to the router. By NCE-on-Demand is not needed.</li>
applying filtering at the router, e.g., dropping RAs from <li>Trusting-all-nodes is only relevant to the router. By applying
the hosts, even malicious hosts cannot cause harm. filtering at the router (e.g., dropping RAs from the hosts), even
* Assigning a unique /64 prefix to each host. Together with the malicious hosts cannot cause harm.</li>
P2P link, this puts each host on a separate link and subnet. </ul></li>
* Maintaining (prefix, interface) binding at the router for <li>Assigning a unique /64 prefix to each host. Together with the
forwarding purposes. P2P link, this puts each host on a separate link and subnet.</li>
]]></artwork> <li>Maintaining (prefix, interface) binding at the router for
forwarding purposes.</li>
</ul>
<t>Since all the three causes of ND issues are addressed, all the <t>Since all the three causes of ND issues are addressed, all the
issues discussed in Section 2.4 are addressed.</t> issues discussed in <xref target="summary-of-nd-issues" format="default"/> ar e addressed.</t>
</section> </section>
<section anchor="nd-solution-in-fixed-broadband-ipv6"> <section anchor="nd-solution-in-fixed-broadband-ipv6">
<name>ND Solution in Fixed Broadband IPv6</name> <name>ND Solution in Fixed Broadband IPv6</name>
<t>The IPv6 solution defined in "IPv6 in the context of TR-101" <xref ta rget="TR177"/> <t>The IPv6 solution defined in "IPv6 in the context of TR-101" <xref ta rget="TR177"/>
is called Fixed Broadband IPv6 (FBBv6) in this document. FBBv6 has is called Fixed Broadband IPv6 (FBBv6) in this document. FBBv6 has
two flavors:</t> two flavors:</t>
<artwork><![CDATA[ <ul spacing="normal">
* P2P: Every host, e.g., the Residential Gateway (RG), is in a <li>P2P: Every host (e.g., the Residential Gateway (RG)) is in a
P2P link with the router, e.g., the Broadband Network Gateway P2P link with the router (e.g., the Broadband Network Gateway
(BNG). In this case, the solution is functionally similar to (BNG)). In this case, the solution is functionally similar to
MBBv6. All ND issues discussed in Section 2.4 are solved. MBBv6. All ND issues discussed in <xref target="summary-of-nd-issues" format
* Point-to-Multi-Point (P2MP): All hosts, e.g., the RGs, ="default"/> are solved.</li>
connected to an access device, e.g., the Optical Line Terminal <li>Point to Multipoint (P2MP): All hosts (e.g., the RGs)
(OLT), are in a P2MP link with the router, e.g., the BNG. This connected to an access device (e.g., the Optical Line Terminal
(OLT)) are in a P2MP link with the router (e.g., the BNG). This
is achieved by placing all hosts in a single VLAN on the router is achieved by placing all hosts in a single VLAN on the router
and configuring the OLT to block any frame from being forwarded and configuring the OLT to block any frame from being forwarded
between its access ports; traffic from each host can travel between its access ports; traffic from each host can travel
only up toward the router, not sideways to another host, only up toward the router, not sideways to another host,
thereby preventing direct host-to-host communication. thereby preventing direct host-to-host communication.</li>
]]></artwork> </ul>
<t>The following summarizes the two key aspects of the FBBv6-P2MP <t>The following list summarizes the two key aspects of the FBBv6-P2MP
architecture as described in <xref target="TR177"/> and the associated benefi ts:</t> architecture as described in <xref target="TR177"/> and the associated benefi ts:</t>
<artwork><![CDATA[ <ul spacing="normal">
* Implementing DAD Proxy {{RFC6957}}: <li><t>Implementing DAD proxy <xref target="RFC6957"/>:</t>
<t>In a P2MP architecture described above, the normal ND DAD procedure
In a P2MP architecture described above, the normal ND DAD will break down because hosts cannot exchange NSs with one another. To
procedure will breaks down because hosts cannot exchange NSs address this, the router participates in the DAD process as a DAD Proxy
with one another. To address this, the router participates in to resolve address duplication.</t>
the DAD process as a DAD Proxy to resolve address duplication. <t>The benefits are:</t>
<ul spacing="normal">
The benefits are: <li>Multicast traffic from all hosts to the router is effectively
converted into unicast, as hosts can only communicate directly with the
o Multicast traffic from all hosts to the router is router.</li>
effectively converted into unicast, as hosts can only <li>The Trusting-all-nodes model is limited to the router. By applying
communicate directly with the router. simple filtering (e.g., dropping RAs from hosts), the router can
mitigate security risks, even from malicious hosts.</li>
o The Trusting-all-nodes model is limited to the router. By </ul></li>
applying simple filtering, e.g., dropping RAs from hosts, <li><t>Assigning a unique /64 prefix to each host:</t>
the router can mitigate security risks, even from <t>Assigning each host a unique /64 prefix results in several operational
malicious hosts improvements:</t>
<ul spacing="normal">
* Assigning a unique /64 prefix to each host: <li>The router can proactively install a forwarding entry for that
prefix towards the host, eliminating the need for
Assigning each host a unique /64 prefix results in several Router-NCE-on-Demand.</li>
operational improvements: <li>Since each host resides in a different subnet, traffic between
hosts is routed through the router, eliminating the need for hosts to
o The router can proactively install a forwarding entry for perform address resolution for one another.</li>
that prefix towards the host, eliminating the need for <li>Without address resolution, router multicast to hosts is limited to
Router-NCE-on-Demand. unsolicited RAs. As each host resides in its own subnet, these RAs are
o Since each host resides in a different subnet, traffic sent as unicast packets to individual hosts. This follows the approach
between hosts is routed through the router, eliminating specified in <xref target="RFC6085"/>, where the host's MAC address repla
the need for hosts to perform address resolution for one ces the
another. multicast MAC address in the RA.</li>
o Without address resolution, router multicast to hosts is </ul></li>
limited to unsolicited RAs. As each host resides in its </ul>
own subnet, these RAs are sent as unicast packets to
individual hosts. This follows the approach specified in
{{RFC6085}}, where the host's MAC address replaces the
multicast MAC address in the RA.
]]></artwork>
<t>Since all three causes of ND issues are addressed, all ND issues <t>Since all three causes of ND issues are addressed, all ND issues
(Section 2.4) are also addressed.</t> (<xref target="summary-of-nd-issues" format="default"/>) are also addressed.< /t>
</section> </section>
<section anchor="unique-ipv6-prefix-per-host-upph"> <section anchor="unique-ipv6-prefix-per-host-upph">
<name>Unique IPv6 Prefix per Host (UPPH)</name> <name>Unique IPv6 Prefix per Host (UPPH)</name>
<t>UPPH solutions are described in <xref target="RFC8273"/> and <xref ta rget="RFC9663"/>. Both are <t>Unique IPv6 Prefix per Host (UPPH) solutions are described in <xref t arget="RFC8273"/> and <xref target="RFC9663"/>. Both are
Informational RFCs. <xref target="RFC8273"/> relies on SLAAC for unique prefi x Informational RFCs. <xref target="RFC8273"/> relies on SLAAC for unique prefi x
allocation while <xref target="RFC9663"/> relies on DHCP-PD. That difference in allocation while <xref target="RFC9663"/> relies on DHCPv6 Prefix Delegation (DHCPv6-PD). That difference in
allocation mechanism does not change the discussion on ND issues, allocation mechanism does not change the discussion on ND issues,
because every IPv6 node is still required to run SLAAC, even when it because every IPv6 node is still required to run SLAAC, even when it
receives its prefix via DHCP-PD. Therefore, discussing <xref target="RFC8273" /> receives its prefix via DHCPv6-PD. Therefore, discussing <xref target="RFC827 3"/>
alone is sufficient.</t> alone is sufficient.</t>
<t><xref target="RFC8273"/> "improves host isolation and enhanced subscr iber <t><xref target="RFC8273"/> "improves host isolation and enhanced subscr iber
management on shared network segments" such as Wi-Fi or Ethernet. management on shared network segments" such as Wi-Fi or Ethernet.
The key points are:</t> The key points are:</t>
<artwork><![CDATA[ <ul spacing="normal">
* When a prefix is allocated to the host, the router can <li>When a prefix is allocated to the host, the router can proactively
proactively install a forwarding entry for that prefix towards install a forwarding entry for that prefix towards the host. There is no
the host. There is no more Router-NCE-on-Demand. more Router-NCE-on-Demand.</li>
<li>Without address resolution, router multicast to hosts consists
* Without address resolution, router multicast to hosts consists
only of unsolicited RAs. They will be sent to hosts one by one only of unsolicited RAs. They will be sent to hosts one by one
in unicast because the prefix for every host is different. in unicast because the prefix for every host is different.</li>
* Since different hosts are in different subnets, hosts will send <li>Since different hosts are in different subnets, hosts will send
traffic to other hosts via the router. There is no host-to-host traffic to other hosts via the router. There is no host-to-host
address resolution. address resolution.</li>
]]></artwork> </ul>
<t>Therefore, ND issues caused by Router-NCE-on-Demand and router <t>Therefore, ND issues caused by Router-NCE-on-Demand and router
multicast to hosts are prevented.</t> multicast to hosts are prevented.</t>
<t><xref target="RFC8273"/> indicates that a "network implementing a uni <t><xref target="RFC8273"/> indicates that a "network implementing a
que IPv6 unique IPv6 prefix per host can simply ensure that devices cannot send
prefix per host can simply ensure that devices cannot send packets packets to each other except through the first-hop router". However,
to each other except through the first-hop router". But when hosts when hosts are on a shared medium like Ethernet, ensuring "devices
are on a shared medium like Ethernet, ensuring "devices cannot send cannot send packets to each other except through the first-hop router"
packets to each other except through the first-hop router" requires requires additional measures like Private VLAN <xref
additional measures like Private VLAN <xref target="RFC5517"/>. Without such target="RFC5517"/>. Without such additional measures, on a shared
additional measures, on a shared medium, hosts can still reach each medium, hosts can still reach each other in L2 as they belong to the
other in L2 as they belong to the same Solicited-Node Multicast same Solicited-Node Multicast Group. Therefore, Trusting-all-nodes and
Group. Therefore, Trusting-all-nodes and host multicast to routers host multicast to routers may cause issues. Of the host multicast
may cause issues. Of the host multicast issues (i.e., Issues 1, 3, issues (i.e., Issues 1, 3, 5, 6, and 7), UPPH prevents Issues 5 and 7,
5, 6, and 7), Unique Prefix per Host prevents Issues 5 and 7, because there is no need for address resolution among hosts (Issue 5),
because there is no need for address resolution among hosts (Issue and there is no possibility of GUA duplication (Issue 7). However,
5) and there is no possibility of GUA duplication (Issue 7). But Issues 1, 3, and 6 may occur.</t>
Issues 1, 3, and 6 may occur.</t>
</section> </section>
<!-- [rfced] Section 3.4: As the phrase "WiND" does not explicitly appear in
the RFCs mentioned below, may we adjust the text below to indicate this a new
term?
Original:
Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929] (Standards
Track) defines a fundamentally different ND solution for Low-Power
and Lossy Networks (LLNs) [RFC7102].
Perhaps:
The term "Wireless ND (WiND)" is used in this document to describe the
fundamentally different ND solution for Low-Power and Lossy Networks (LLNs)
[RFC7102] that is defined in [RFC6775], [RFC8505], [RFC8928], and [RFC8929]
(Standards Track).
-->
<section anchor="wireless-nd-and-subnet-nd"> <section anchor="wireless-nd-and-subnet-nd">
<name>Wireless ND and Subnet ND</name> <name>Wireless ND and Subnet ND</name>
<t>Wireless ND (WiND) <xref target="RFC6775"/><xref target="RFC8505"/><x ref target="RFC8928"/><xref target="RFC8929"/> (Standards <t>Wireless ND (WiND) <xref target="RFC6775"/> <xref target="RFC8505"/> <xref target="RFC8928"/> <xref target="RFC8929"/> (Standards
Track) defines a fundamentally different ND solution for Low-Power Track) defines a fundamentally different ND solution for Low-Power
and Lossy Networks (LLNs) <xref target="RFC7102"/>. WiND changes host and rou ter and Lossy Networks (LLNs) <xref target="RFC7102"/>. WiND changes host and rou ter
behaviors to use multicast only for router discovery. The key points behaviors to use multicast only for router discovery. The key points
are:</t> are:</t>
<artwork><![CDATA[ <ul spacing="normal">
* Hosts use unicast to proactively register their addresses at <li>Hosts use unicast to proactively register their addresses at
the routers. Routers use unicast to communicate with hosts and the routers. Routers use unicast to communicate with hosts and
become an abstract registrar and arbitrator for address become an abstract registrar and arbitrator for address
ownership. ownership.</li>
* The router also proactively installs NCEs for the hosts. This <li>The router also proactively installs NCEs for the hosts. This
avoids the need for address resolution for the hosts. avoids the need for address resolution for the hosts.</li>
* The router sets Prefix Information Option (PIO) L-bit to 0. <li>The router sets the Prefix Information Option (PIO) L-bit to 0.
Each host communicates only with the router ({{Section 6.3.4 of RFC4861}}). Each host communicates only with the router (<xref target="RFC4861" section=
* Other functionalities that are relevant only to LLNs. "6.3.4"/>).</li>
]]></artwork> <li>Other functionalities that are relevant only to LLNs.</li>
<t>WiND addresses all ND issues (Section 2.4) in LLNs. However, WiND </ul>
<t>WiND addresses all ND issues (<xref target="summary-of-nd-issues" for
mat="default"/>) in LLNs. However, WiND
support is not mandatory for general-purpose hosts. Therefore, it support is not mandatory for general-purpose hosts. Therefore, it
cannot be relied upon as a deployment option without imposing cannot be relied upon as a deployment option without imposing
additional constraints on the participating nodes.</t> additional constraints on the participating nodes.</t>
</section> </section>
<section anchor="scalable-address-resolution-protocol"> <section anchor="scalable-address-resolution-protocol">
<name>Scalable Address Resolution Protocol</name> <name>Scalable Address Resolution Protocol</name>
<t>Scalable Address Resolution Protocol <xref target="RFC7586"/> was an <t>The Scalable Address Resolution Protocol (SARP) <xref
Experimental target="RFC7586"/> was an Experimental solution. That experiment ended
solution. That experiment ended in 2017, two years after the RFC was in 2017, two years after the RFC was published. Because the idea has
published. Because the idea has been used in mitigation solutions been used in mitigation solutions for more specific scenarios
for more specific scenarios (described in Sections 3.6 and 3.7), it (described in Sections <xref
is worth describing here. The usage scenario is Data Centers (DCs), target="arp-and-nd-optimization-for-trill" format="counter"/> and
where large L2 domains span across multiple sites. In each site, <xref target="proxy-arpnd-in-ethernet-virtual-private-networks-evpn"
multiple hosts are connected to a switch. The hosts can be Virtual format="counter"/>), it is worth describing here. The usage scenario
Machines (VMs), so the number can be large. The switches are is Data Centers (DCs), where large L2 domains span across multiple
interconnected by a native or overlay L2 network.</t> sites. In each site, multiple hosts are connected to a switch. The
<t>The switch will snoop and install (IP, MAC address) proxy table for hosts can be Virtual Machines (VMs), so the number can be large. The
switches are interconnected by a native or overlay L2 network.</t>
<t>The switch will snoop and install a (IP, MAC address) proxy table for
the local hosts. The switch will also reply to address resolution the local hosts. The switch will also reply to address resolution
requests from other sites to its hosts with its own MAC address. In requests from other sites to its hosts with its own MAC address. In
doing so, all hosts within a site will appear to have a single MAC doing so, all hosts within a site will appear to have a single MAC
address to other sites. As such, a switch only needs to build a MAC address to other sites. As such, a switch only needs to build a MAC
address table for the local hosts and the remote switches, not for address table for the local hosts and the remote switches, not for
all the hosts in the L2 domain. Consequently, the MAC address table all the hosts in the L2 domain. Consequently, the MAC address table
size of the switches is significantly reduced. A switch will also size of the switches is significantly reduced. A switch will also
add the (IP, MAC address) replies from remote switches to its proxy add the (IP, MAC address) replies from remote switches to its proxy
ND table so that it can reply to future address resolution requests ND table so that it can reply to future address resolution requests
from local hosts for such IPs directly. This greatly reduces the from local hosts for such IPs directly. This greatly reduces the
number of address resolution multicast in the network.</t> number of address resolution multicast in the network.</t>
<t>Unlike MBBv6, FBBv6, and UPPH, which try to address all ND issues <t>Unlike MBBv6, FBBv6, and UPPH, which try to address all ND issues
discussed in Section 2.4, SARP focuses on reducing address discussed in <xref target="summary-of-nd-issues" format="default"/>, SARP foc uses on reducing address
resolution multicast to improve the performance and scalability of resolution multicast to improve the performance and scalability of
large L2 domains in DCs.</t> large L2 domains in DCs.</t>
</section> </section>
<section anchor="arp-and-nd-optimization-for-trill"> <section anchor="arp-and-nd-optimization-for-trill">
<name>ARP and ND Optimization for TRILL</name> <name>ARP and ND Optimization for TRILL</name>
<t>ARP and ND Optimization for TRILL <xref target="RFC8302"/> (Standards <t>ARP and ND optimization for Transparent Interconnection of Lots of Li
Track) is nks (TRILL) <xref target="RFC8302"/>
similar to SARP (Section 3.5). It can be considered an application (Standards Track) is similar to SARP (<xref
of SARP in the TRILL environment.</t> target="scalable-address-resolution-protocol" format="default"/>). It
<t>Like SARP, ARP, and ND Optimization for TRILL focuses on reducing can be considered an application of SARP in the TRILL environment.</t>
multicast address resolution. That is, it addresses Issue 5 (Section 2.1).</t
> <!-- [rfced] Should the comma after "ARP" be removed in the text below so
that "ARP and ND optimization" appear as one item?
Original:
Like SARP, ARP, and ND Optimization for TRILL focuses on reducing
multicast address resolution.
Perhaps:
Like SARP, ARP and ND optimization for TRILL focuses on reducing
multicast address resolution.
-->
<t>Like SARP, ARP, and ND optimization for TRILL focuses on reducing
multicast address resolution. That is, it addresses Issue 5 (<xref target="mu
lticast-may-cause-performance-and-reliability-issues" format="default"/>).</t>
</section> </section>
<section anchor="proxy-arpnd-in-ethernet-virtual-private-networks-evpn"> <section anchor="proxy-arpnd-in-ethernet-virtual-private-networks-evpn">
<name>Proxy ARP/ND in Ethernet Virtual Private Networks (EVPN)</name> <name>Proxy ARP/ND in Ethernet Virtual Private Networks (EVPN)</name>
<t>Proxy ARP/ND in EVPN is specified in <xref target="RFC9161"/> (Standa rds Track). <t>Proxy ARP/ND in EVPN is specified in <xref target="RFC9161"/> (Standa rds Track).
The usage scenario is DCs where large L2 domains span across The usage scenario is DCs where large L2 domains span across
multiple sites. In each site, multiple hosts are connected to a multiple sites. In each site, multiple hosts are connected to a
Provider Edge (PE) router. The PEs are interconnected by EVPN Provider Edge (PE) router. The PEs are interconnected by EVPN
tunnels.</t> tunnels.</t>
<t>PE of each site snoops the local address resolution NAs to build <t>The PE of each site snoops the local address resolution NAs to build
(IP, MAC address) Proxy ND table entries. PEs then propagate such (IP, MAC address) Proxy ND table entries. PEs then propagate such
Proxy ND entries to other PEs via the Border Gateway Protocol (BGP). Proxy ND entries to other PEs via the Border Gateway Protocol (BGP).
Each PE also snoops local hosts' address resolution NSs for remote Each PE also snoops local hosts' address resolution NSs for remote
hosts. If an entry exists in its Proxy ND table for the remote hosts. If an entry exists in its Proxy ND table for the remote
hosts, the PE will reply directly. Consequently, the number of hosts, the PE will reply directly. Consequently, the number of
multicast address resolution messages is significantly reduced.</t> multicast address resolution messages is significantly reduced.</t>
<t>Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address <t>Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address
resolution multicast.</t> resolution multicast.</t>
</section> </section>
<section anchor="reducing-router-advertisements"> <section anchor="reducing-router-advertisements">
<name>Reducing Router Advertisements</name> <name>Reducing Router Advertisements</name>
<t>Maintaining IPv6 connectivity requires that hosts be able to receive <t>Maintaining IPv6 connectivity requires that hosts be able to receive
periodic multicast RAs <xref target="RFC4861"/>. Hosts that process unicast periodic multicast RAs <xref target="RFC4861"/>. Hosts that process unicast
packets while they are asleep must also process multicast RAs while packets while they are asleep must also process multicast RAs while
they are asleep. An excessive number of RAs can significantly reduce they are asleep. An excessive number of RAs can significantly reduce
the battery life of mobile hosts. <xref target="RFC7772"/> (Best Current Prac tice) the battery life of mobile hosts. <xref target="RFC7772"/> (Best Current Prac tice)
specifies a solution to reduce RAs:</t> specifies a solution to reduce RAs:</t>
<artwork><![CDATA[ <ul spacing="normal">
* The router should respond to RS with unicast RA (rather than <li>The router should respond to RS with unicast RA (rather than
the normal multicast RA) if the host's source IP address is the normal multicast RA) if the host's source IP address is
specified and the host's MAC address is valid. This way, other specified and the host's MAC address is valid. This way, other
hosts will not receive this RA. hosts will not receive this RA.</li>
* The router should reduce the multicast RA frequency <li>The router should reduce the multicast RA frequency.</li>
]]></artwork> </ul>
<t><xref target="RFC7772"/> addresses Issue 2 (Section 2.1).</t> <t><xref target="RFC7772"/> addresses Issue 2 (<xref target="multicast-m
ay-cause-performance-and-reliability-issues" format="default"/>).</t>
</section> </section>
<section anchor="gratuitous-neighbor-discovery-grand"> <section anchor="gratuitous-neighbor-discovery-grand">
<name>Gratuitous Neighbor Discovery (GRAND)</name> <name>Gratuitous Neighbor Discovery (GRAND)</name>
<t>GRAND <xref target="RFC9131"/> (Standards Track) changes ND in the fo llowing ways:</t> <t>GRAND <xref target="RFC9131"/> (Standards Track) changes ND in the fo llowing ways:</t>
<artwork><![CDATA[ <ul spacing="normal">
* A node sends unsolicited NAs upon assigning a new IPv6 address <li>A node sends unsolicited NAs upon assigning a new IPv6 address
to its interface. to its interface.</li>
* A router creates a new NCE for the node and sets its state to <li>A router creates a new NCE for the node and sets its state to
STALE. STALE.</li>
]]></artwork> </ul>
<t>When a packet for the host later arrives, the router can use the <t>When a packet for the host later arrives, the router can use the
existing STALE NCE to forward it immediately (<xref target="RFC4861"/> Sectio existing STALE NCE to forward it immediately (<xref target="RFC4861" sectionF
n ormat="comma" section="7.2.2"/>). It then verifies reachability by sending a uni
7.2.2). It then verifies reachability by sending a unicast NS rather cast NS rather
than a multicast one for address resolution. In this way, GRAND than a multicast one for address resolution. In this way, GRAND
eliminates the Router Forwarding Delay. But it does not solve other eliminates the Router Forwarding Delay, but it does not solve other
Router-NCE-on-Demand issues. For example, NCE Exhaustion can still Router-NCE-on-Demand issues. For example, NCE Exhaustion can still
happen.</t> happen.</t>
</section> </section>
<section anchor="source-address-validation-improvement-savi-and-router-adv ertisement-guard"> <section anchor="source-address-validation-improvement-savi-and-router-adv ertisement-guard">
<name>Source Address Validation Improvement (SAVI) and Router Advertisem ent Guard</name> <name>Source Address Validation Improvement (SAVI) and Router Advertisem ent Guard</name>
<t>SAVI <xref target="RFC7039"/> (Informational) binds an address to a p ort on an L2 <t>Source Address Validation Improvement (SAVI) <xref target="RFC7039"/> (Informational) binds an address to a port on an L2
switch and rejects claims from other ports for that address. switch and rejects claims from other ports for that address.
Therefore, a node cannot spoof the IP address of another node.</t> Therefore, a node cannot spoof the IP address of another node.</t>
<t>Router Advertisement Guard (RA-Guard) <xref target="RFC6105"/><xref t arget="RFC7113"/> <t>Router Advertisement Guard (RA-Guard) <xref target="RFC6105"/> <xref target="RFC7113"/>
(Informational) only allows RAs from a port that a router is (Informational) only allows RAs from a port that a router is
connected to. Therefore, nodes on other ports cannot pretend to be a connected to. Therefore, nodes on other ports cannot pretend to be a
router.</t> router.</t>
<t>SAVI and RA-Guard address the on-link security issues.</t> <t>SAVI and RA-Guard address the on-link security issues.</t>
</section> </section>
<section anchor="rfc-6583-dealing-with-nce-exhaustion-attacks"> <section anchor="rfc-6583-dealing-with-nce-exhaustion-attacks">
<name>RFC 6583 Dealing with NCE Exhaustion Attacks</name> <name>RFC 6583 Dealing with NCE Exhaustion Attacks</name>
<t><xref target="RFC6583"/> (Informational) deals with the NCE Exhaustio <t><xref target="RFC6583"/> (Informational) deals with the NCE
n attack issue Exhaustion attack issue (<xref
(Section 2.3). It recommends that:</t> target="router-nce-on-demand-may-cause-forwarding-delay-nce-exhaustion-and-addre
<artwork><![CDATA[ ss-accountability-issues"
* Operators should format="default"/>). It recommends that:</t>
o Filter unused address space so that messages to such <ul spacing="normal">
addresses can be dropped rather than triggering NCE <li>
creation. <t>Operators should:</t>
o Implement rate-limiting mechanisms for ND message <ul spacing="normal">
processing to prevent CPU and memory resources from being <li>Filter unused address space so that messages to such
overwhelmed. addresses can be dropped rather than triggering NCE
* Vendors should creation.</li>
o Prioritizing NDP processing for existing NCEs over creating <li>Implement rate-limiting mechanisms for ND message
new NCEs processing to prevent CPU and memory resources from being
]]></artwork> overwhelmed.</li>
</ul>
</li>
<li>
<t>Vendors should:</t>
<ul spacing="normal">
<li>Prioritize NDP processing for existing NCEs over creating
new NCEs.</li>
</ul>
</li>
</ul>
<t><xref target="RFC6583"/> acknowledges that "some of these options are 'kludges', <t><xref target="RFC6583"/> acknowledges that "some of these options are 'kludges',
and can be operationally difficult to manage". <xref target="RFC6583"/> parti and can be operationally difficult to manage". <xref target="RFC6583"/> p
ally artially
addresses the Router NCE Exhaustion issue. In practice, router addresses the Router NCE Exhaustion issue. In practice, router
vendors cap the number of NCEs per interface to prevent cache vendors cap the number of NCEs per interface to prevent cache
exhaustion. If the link has more addresses than that cap, the router exhaustion. If the link has more addresses than that cap, the router
cannot keep an entry for every address, and packets destined for cannot keep an entry for every address, and packets destined for
addresses without an NCE are simply dropped <xref target="RFC9663"/>.</t> addresses without an NCE are simply dropped <xref target="RFC9663"/>.</t>
</section> </section>
<section anchor="registering-self-generated-ipv6-addresses-using-dhcpv6"> <section anchor="registering-self-generated-ipv6-addresses-using-dhcpv6">
<name>Registering Self-generated IPv6 Addresses using DHCPv6</name> <name>Registering Self-Generated IPv6 Addresses Using DHCPv6</name>
<t>In IPv4, network administrators can retrieve a host's IP address <t>In IPv4, network administrators can retrieve a host's IP address
from the DHCP server and use it for subscriber management. In IPv6 from the DHCP server and use it for subscriber management. In IPv6
and SLAAC, this is not possible (Section 2.3).</t> and SLAAC, this is not possible (<xref target="router-nce-on-demand-may-cause
-forwarding-delay-nce-exhaustion-and-address-accountability-issues" format="defa
ult"/>).</t>
<t><xref target="RFC9686"/> (Standards Track) defines a method for infor ming a DHCPv6 <t><xref target="RFC9686"/> (Standards Track) defines a method for infor ming a DHCPv6
server that a host has one or more self-generated or statically server that a host has one or more self-generated or statically
configured addresses. This enables network administrators to configured addresses. This enables network administrators to
retrieve the IPv6 addresses for each host from the DHCPv6 server. retrieve the IPv6 addresses for each host from the DHCPv6 server.
<xref target="RFC9686"/> provides a solution for Issue 15 (Section 2.3).</t> <xref target="RFC9686"/> provides a solution for Issue 15 (<xref target="rout er-nce-on-demand-may-cause-forwarding-delay-nce-exhaustion-and-address-accountab ility-issues" format="default"/>).</t>
</section> </section>
<section anchor="enhanced-dad"> <section anchor="enhanced-dad">
<name>Enhanced DAD</name> <name>Enhanced DAD</name>
<t>Enhanced DAD <xref target="RFC7527"/> (Standards Track) addresses a D AD failure <t>Enhanced DAD <xref target="RFC7527"/> (Standards Track) addresses a D AD failure
issue in a specific situation: a looped back interface. DAD will issue in a specific situation: a looped-back interface. DAD will
fail in a looped-back interface because the sending host will fail in a looped-back interface because the sending host will
receive the DAD message back and will interpret it as another host receive the DAD message back and will interpret it as another host
is trying to use the same address. The solution is to include a is trying to use the same address. The solution is to include a
Nonce option <xref target="RFC3971"/> in each DAD message so that the sending host Nonce option <xref target="RFC3971"/> in each DAD message so that the sending host
can detect that the looped-back DAD message is sent by itself.</t> can detect that the looped-back DAD message is sent by itself.</t>
<t>Enhanced DAD does not solve any ND issue. It extends ND to work in a <t>Enhanced DAD does not solve any ND issue. It extends ND to work in a
new scenario: looped-back interface. It is reviewed here only for new scenario: a looped-back interface. It is reviewed here only for
completeness.</t> completeness.</t>
</section> </section>
<section anchor="nd-mediation-for-ip-interworking-of-layer-2-vpns"> <section anchor="nd-mediation-for-ip-interworking-of-layer-2-vpns">
<name>ND Mediation for IP Interworking of Layer 2 VPNs</name> <name>ND Mediation for IP Interworking of Layer 2 VPNs</name>
<t>ND mediation is specified in <xref target="RFC6575"/> (Standards Trac k). When two <t>ND mediation is specified in <xref target="RFC6575"/> (Standards Trac k). When two
Attachment Circuits (ACs) are interconnected by a Virtual Private Attachment Circuits (ACs) are interconnected by a Virtual Private
Wired Service (VPWS), and the two ACs are of different media (e.g., Wired Service (VPWS), and the two ACs are of different media (e.g.,
one is Ethernet while the other is Frame Relay), the two PEs must one is Ethernet while the other is Frame Relay), the two PEs must
interwork to provide mediation service so that a Customer Edge (CE) interwork to provide mediation service so that a Customer Edge (CE)
can resolve the MAC address of the remote end. <xref target="RFC6575"/> speci fies can resolve the MAC address of the remote end. <xref target="RFC6575"/> speci fies
such a solution.</t> such a solution.</t>
<t>ND Mediation does not address any ND issue. It extends ND to work in <t>ND mediation does not address any ND issue. It extends ND to work in
a new scenario: two ACs of different media interconnected by a VPWS. a new scenario: two ACs of different media interconnected by a VPWS.
It is reviewed here only for completeness.</t> It is reviewed here only for completeness.</t>
</section> </section>
<section anchor="nd-solutions-defined-before-the-latest-versions-of-nd"> <section anchor="nd-solutions-defined-before-the-latest-versions-of-nd">
<name>ND Solutions Defined before the Latest Versions of ND</name> <name>ND Solutions Defined Before the Latest Versions of ND</name>
<t>The latest versions of ND and SLAAC are specified in <xref target="RF C4861"/> and <t>The latest versions of ND and SLAAC are specified in <xref target="RF C4861"/> and
<xref target="RFC4862"/>. Several ND mitigation solutions were published befo re <xref target="RFC4862"/>. Several ND mitigation solutions were published befo re
<xref target="RFC4861"/>. They are reviewed in this section only for complete ness.</t> <xref target="RFC4861"/>. They are reviewed in this section only for complete ness.</t>
<section anchor="secure-neighbor-discovery-send"> <section anchor="secure-neighbor-discovery-send">
<name>Secure Neighbor Discovery (SeND)</name> <name>Secure Neighbor Discovery (SEND)</name>
<t>The purpose of SeND <xref target="RFC3971"/> (Standards Track) is t <t>The purpose of SEND <xref target="RFC3971"/> (Standards Track) is t
o ensure that o ensure that
hosts and routers are trustworthy. SeND defined three new ND hosts and routers are trustworthy. SEND defined three new ND
options, i.e., Cryptographically Generated Addresses (CGA) <xref target="RFC3 972"/> options, i.e., Cryptographically Generated Addresses (CGA) <xref target="RFC3 972"/>
(Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce, (Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce,
an authorization delegation discovery process, an address ownership an authorization delegation discovery process, an address ownership
proof mechanism, and requirements for the use of these components in proof mechanism, and requirements for the use of these components in
the ND protocol.</t> the ND protocol.</t>
<!-- [rfced] Please clarify; after the 3 options are listed, how does
the second part of this sentence relate to the first part?
Original:
SeND defined three new ND options, i.e., Cryptographically Generated
Addresses (CGA) [RFC3972] (Standards Track), RSA public-key cryptosystem,
and Timestamp/Nonce, an authorization delegation discovery process, an
address ownership proof mechanism, and requirements for the use of these
components in the ND protocol.
Perhaps:
SEND defined three new ND options: Cryptographically Generated Addresses
(CGA) [RFC3972] (Standards Track), RSA public-key cryptosystem, and
Timestamp/Nonce. These are an authorization delegation discovery process,
an address ownership proof mechanism, and requirements for the use of
these components in the ND protocol, respectively.
-->
</section> </section>
<section anchor="cryptographically-generated-addresses-cga"> <section anchor="cryptographically-generated-addresses-cga">
<name>Cryptographically Generated Addresses (CGA)</name> <name>Cryptographically Generated Addresses (CGA)</name>
<t>The purpose of CGA is to associate a cryptographic public key with <t>The purpose of CGA is to associate a cryptographic public key with
an IPv6 address in the SeND protocol. The key point is to generate an IPv6 address in the SEND protocol. The key point is to generate
the Interface Identifier (IID) of an IPv6 address by computing a the Interface Identifier (IID) of an IPv6 address by computing a
cryptographic hash of the public key. The resulting IPv6 address is cryptographic hash of the public key. The resulting IPv6 address is
called a CGA. The corresponding private key can then be used to called a CGA. The corresponding private key can then be used to
sign messages sent from the address.</t> sign messages sent from the address.</t>
<t>CGA assumes that a legitimate host does not care about the bit <t>CGA assumes that a legitimate host does not care about the bit
combination of the IID that would be created by some hash procedure. combination of the IID that would be created by some hash procedure.
The attacker needs an exact IID to impersonate the legitimate hosts, The attacker needs an exact IID to impersonate the legitimate hosts,
but then the attacker is challenged to do a reverse hash calculation but then the attacker is challenged to do a reverse hash calculation,
which is a strong mathematical challenge.</t> which is a strong mathematical challenge.</t>
<t>CGA is part of SeND. There is no reported deployment.</t> <t>CGA is part of SEND. There is no reported deployment.</t>
</section> </section>
<section anchor="nd-proxy"> <section anchor="nd-proxy">
<name>ND Proxy</name> <name>ND Proxy</name>
<t>ND Proxy <xref target="RFC4389"/> (Experimental) aims to enable mul tiple links <t>ND Proxy <xref target="RFC4389"/> (Experimental) aims to enable mul tiple links
joined by an ND Proxy device to work as a single link.</t> joined by an ND Proxy device to work as a single link.</t>
<artwork><![CDATA[ <ul spacing="normal">
* When an ND Proxy receives an ND request from a host on a link, <li>When an ND Proxy receives an ND request from a host on a link,
it will proxy the message out the "best" (defined in the next it will proxy the message out the "best" (defined in the next
paragraph) outgoing interface. If there is no best interface, paragraph) outgoing interface. If there is no best interface,
the ND Proxy will proxy the message to all other links. Here, the ND Proxy will proxy the message to all other links. Here,
proxy means acting as if the ND message originates from the ND proxy means acting as if the ND message originates from the ND
Proxy itself. That is, the ND Proxy will change the ND Proxy itself. That is, the ND Proxy will change the ND
message's source IP and source MAC address to the ND Proxy's message's source IP and source MAC address to the ND Proxy's
outgoing interface's IP and MAC address, and create an NCE outgoing interface's IP and MAC address, and create an NCE
entry at the outgoing interface accordingly. entry at the outgoing interface accordingly.</li>
* When ND Proxy receives an ND reply, it will act as if the ND <li>When ND Proxy receives an ND reply, it will act as if the ND
message is destined for itself, and update the NCE entry state message is destined for itself, and update the NCE entry state
at the receiving interface. Based on such state information, at the receiving interface. Based on such state information,
the ND Proxy can determine the "best" outgoing interface for the ND Proxy can determine the "best" outgoing interface for
future ND requests. The ND Proxy then proxies the ND message future ND requests. The ND Proxy then proxies the ND message
back to the requesting host. back to the requesting host.</li>
]]></artwork> </ul>
<t>ND Proxy is widely used in SARP (Sections 3.5), ND Optimization for <t>ND Proxy is widely used in SARP (<xref
TRILL (Sections 3.6), and Proxy ARP/ND in EVPN (Sections 3.7).</t> target="scalable-address-resolution-protocol" format="default"/>),
ND optimization for TRILL (<xref
target="arp-and-nd-optimization-for-trill" format="default"/>), and
Proxy ARP/ND in EVPN (<xref
target="proxy-arpnd-in-ethernet-virtual-private-networks-evpn"
format="default"/>).</t>
</section> </section>
<section anchor="optimistic-dad"> <section anchor="optimistic-dad">
<name>Optimistic DAD</name> <name>Optimistic DAD</name>
<t>Optimistic DAD <xref target="RFC4429"/> (Standards Track) seeks to minimize address <t>Optimistic DAD <xref target="RFC4429"/> (Standards Track) seeks to minimize address
configuration delays in the successful case and to reduce disruption configuration delays in the successful case and to reduce disruption
as far as possible in the failure case. That is, Optimistic DAD lets as far as possible in the failure case. That is, Optimistic DAD lets
hosts immediately use the newly formed address to communicate before hosts immediately use the newly formed address to communicate before
DAD completes, assuming that DAD will succeed anyway. If the address DAD completes, assuming that DAD will succeed anyway. If the address
turns out to be duplicate, Optimistic DAD provides a set of turns out to be duplicate, Optimistic DAD provides a set of
mechanisms to minimize the impact. Optimistic DAD modified the mechanisms to minimize the impact. Optimistic DAD modified the
original ND <xref target="RFC2461"/> and SLAAC <xref target="RFC2462"/>, but original ND <xref target="RFC2461"/> and original SLAAC <xref target="RFC2462
the solution was not "/> (both of which are obsolete), but the solution was not
incorporated into the latest specifications of <xref target="RFC4861"/> and incorporated into the latest specifications of ND <xref target="RFC4861"/> an
<xref target="RFC4862"/>. However, implementations of Optimistic DAD exist.</ d
t> SLAAC <xref target="RFC4862"/>. However, implementations of Optimistic DAD ex
<t>Optimistic DAD does not solve any ND issue (Section 2). It is ist.</t>
<t>Optimistic DAD does not solve any ND issue (<xref target="review-of
-inventoried-nd-issues" format="default"/>). It is
reviewed here only for completeness.</t> reviewed here only for completeness.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="guidelines-for-prevention-of-potential-nd-issues"> <section anchor="guidelines-for-prevention-of-potential-nd-issues">
<name>Guidelines for Prevention of Potential ND Issues</name> <name>Guidelines for Prevention of Potential ND Issues</name>
<t>By knowing the potential ND issues and associated mitigation <t>By knowing the potential ND issues and associated mitigation
solutions, network administrators of existing IPv6 deployments can solutions, network administrators of existing IPv6 deployments can
assess whether these issues may occur in their networks and, if so, assess whether these issues may occur in their networks and, if so,
whether to deploy the mitigation solutions proactively. Deploying whether to deploy the mitigation solutions proactively. Deploying
these solutions may take time and additional resources. Therefore, these solutions may take time and additional resources. Therefore,
it is advisable to plan.</t> it is advisable to plan.</t>
<t>Network administrators planning to start their IPv6 deployments can <t>Network administrators planning to start their IPv6 deployments can
use the issue-solution information to help plan their deployments. use the issue-solution information to help plan their deployments.
Moreover, they can take proactive action to prevent potential ND Moreover, they can take proactive action to prevent potential ND
issues.</t> issues.</t>
<section anchor="learning-host-isolation-from-the-existing-solutions"> <section anchor="learning-host-isolation-from-the-existing-solutions">
<name>Learning Host Isolation from the Existing Solutions</name> <name>Learning Host Isolation from the Existing Solutions</name>
<t>While various ND solutions may initially appear unrelated, <t>While various ND solutions may initially appear unrelated,
categorizing them into four distinct groups highlights an important categorizing them into four distinct groups highlights an important
observation: "host isolation" is an effective strategy for observation: host isolation is an effective strategy for
mitigating ND-related issues.</t> mitigating ND-related issues.</t>
<t>Group 1: L3 and L2 Isolation</t>
<t>This group includes MBBv6 and FBBv6, which isolate hosts at both L3 <ul spacing="normal">
and L2 by placing each host within its subnet and link. This <li><t>Group 1: L3 and L2 Isolation</t>
prevents ND issues caused by multicast and Trusting-all-nodes, as <t>This group includes MBBv6 and FBBv6, which isolate hosts at both L3 and
each host operates within its isolated domain. Furthermore, since L2 by placing each host within its subnet and link. This prevents ND issues
routers can route packets to a host based on its unique prefix, the caused by multicast and Trusting-all-nodes, as each host operates within its
need for Router-NCE-on-Demand is also eliminated. Therefore, L3 and isolated domain. Furthermore, since routers can route packets to a host
L2 Isolation prevent all ND issues.</t> based on its unique prefix, the need for Router-NCE-on-Demand is also
<t>Group 2: L3 Isolation</t> eliminated. Therefore, L3 and L2 Isolation prevent all ND issues.</t></li>
<t>This group includes UPPH solutions like <xref target="RFC8273"/> and <li><t>Group 2: L3 Isolation</t>
<xref target="RFC9663"/>, <t>This group includes UPPH solutions like <xref target="RFC8273"/> and
which isolate hosts into separate subnets while potentially leaving <xref target="RFC9663"/>, which isolate hosts into separate subnets while
them on the same shared medium. This approach mitigates ND issues potentially leaving them on the same shared medium. This approach mitigates
caused by router multicast to hosts and eliminates the need for ND issues caused by router multicast to hosts and eliminates the need for
"Router-NCE-on-Demand", as detailed in Section 3.3.</t> Router-NCE-on-Demand, as detailed in <xref
<t>Group 3: Partial L2 Isolation</t> target="unique-ipv6-prefix-per-host-upph" format="default"/>.</t></li>
<t>This group encompasses solutions such as WiND, SARP, ND Optimization <li><t>Group 3: Partial L2 Isolation</t>
for TRILL, and Proxy ND in EVPN. These solutions use a proxy device <t>This group encompasses solutions such as WiND, SARP, ND optimization for
to represent the hosts behind it, effectively isolating those hosts TRILL, and Proxy ND in EVPN. These solutions use a proxy device to represent
into distinct multicast domains. While hosts are still located the hosts behind it, effectively isolating those hosts into distinct
within the same subnet, their separation into different multicast multicast domains. While hosts are still located within the same subnet,
domains reduces the scope of ND issues related to multicast-based their separation into different multicast domains reduces the scope of ND
address resolution.</t> issues related to multicast-based address resolution.</t></li>
<t>Group 4: Non-Isolating Solutions</t> <li><t>Group 4: Non-Isolating Solutions</t>
<t>The final group includes remaining solutions that do not implement <t>The final group includes remaining solutions that do not implement host
host isolation. These solutions do not prevent ND issues but instead isolation. These solutions do not prevent ND issues but instead focus on
focus on addressing specific ND problems.</t> addressing specific ND problems.</t></li>
</ul>
<t>The analysis demonstrates that the stronger the isolation of hosts, <t>The analysis demonstrates that the stronger the isolation of hosts,
the more ND issues can be mitigated. This correlation is intuitive, the more ND issues can be mitigated. This correlation is intuitive,
as isolating hosts reduces the multicast scope, minimizes the number as isolating hosts reduces the multicast scope, minimizes the number
of nodes that must be trusted, and may eliminate the need for of nodes that must be trusted, and may eliminate the need for
"Router-NCE-on-Demand", the three primary causes of ND issues.</t> Router-NCE-on-Demand, the three primary causes of ND issues.</t>
<t>This understanding can be used to prevent ND issues.</t> <t>This understanding can be used to prevent ND issues.</t>
</section> </section>
<section anchor="applicability-of-various-isolation-methods"> <section anchor="applicability-of-various-isolation-methods">
<name>Applicability of Various Isolation Methods</name> <name>Applicability of Various Isolation Methods</name>
<section anchor="applicability-of-l3l2-isolation"> <section anchor="applicability-of-l3l2-isolation">
<name>Applicability of L3+L2 Isolation</name> <name>Applicability of L3+L2 Isolation</name>
<t>Benefits:</t> <t>Benefits:</t>
<t>o All ND issues (Section 2.4) can be effectively mitigated.</t> <ul spacing="normal">
<li><t>All ND issues (<xref target="summary-of-nd-issues" format="de
fault"/>) can be effectively mitigated.</t></li>
</ul>
<!-- [rfced] We note a mixture of sentence and title case for several of the
list items that appear in Sections 4.2.1, 4.2.2, and 4.2.3. For consistency,
may we update these list items to sentence case? Some examples below:
Original:
3. Privacy Issue from Unique Prefix Identifiability:
1. Unique Prefix Allocation
2. Router Support for L3 Isolation
. Reduced Multicast Traffic:
. Router Support for Partial L2 Isolation:
Perhaps:
3. Privacy issue from unique prefix identifiability:
1. Unique prefix allocation
2. Router support for L3 isolation
* Reduced multicast traffic:
* Router support for partial L2 isolation:
-->
<t>Constraints:</t> <t>Constraints:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<dl> <li>
<dt>L2 Isolation:</dt> <t>L2 Isolation:</t>
<dd>
<t>Actions must be taken to isolate hosts in L2. The required <t>Actions must be taken to isolate hosts in L2. The required
effort effort varies by the chosen method and deployment context. For
varies by the chosen method and deployment context. For example, the example, the P2P method <xref target="RFC7066"/> is
P2P method <xref target="RFC7066"/> is heavy-weight, while the Private VLAN meth heavyweight, while the Private VLAN method <xref
od target="RFC5517"/> is more manageable.</t>
<xref target="RFC5517"/> is more manageable.</t>
</dd>
</dl>
</li> </li>
<li> <li>
<dl> <t>Unique Prefix Allocation:</t>
<dt>Unique Prefix Allocation:</dt> <t>A large number of prefixes will be required, with one prefix
<dd> assigned per host. This is generally not a limitation for
<t>A large number of prefixes will be required, with one prefi IPv6. For instance, members of a Regional Internet Registry
x (RIR) can obtain a /29 prefix allocation <xref
assigned per host. This is generally not a limitation for IPv6. For target="RIPE738"/>, which provides 32 billion /64 prefixes --
instance, members of a Regional Internet Registry (RIR) can obtain a sufficient for any foreseeable deployment scenarios. Practical
/29 prefix allocation <xref target="RIPE738"/>, which provides 32 billion /64 implementations, such as MBBv6 assigning /64 prefixes to
prefixes - sufficient for any foreseeable deployment scenarios. billions of mobile UEs <xref target="RFC6459"/>, and FBBv6
Practical implementations, such as MBBv6 assigning /64 prefixes to assigning /56 prefixes to hundreds of millions of routed RGs
billions of mobile UEs <xref target="RFC6459"/> and FBBv6 assigning /56 prefixes <xref target="TR177"/>, demonstrate the feasibility of this
to approach.</t>
hundreds of millions of routed RGs <xref target="TR177"/>, demonstrate the
feasibility of this approach.</t>
</dd>
</dl>
</li> </li>
<li> <li>
<dl> <t>Privacy Issue from Unique Prefix Identifiability:</t>
<dt>Privacy Issue from Unique Prefix Identifiability:</dt> <t>Assigning a unique prefix to each host may theoretically
<dd> reduce privacy, as hosts can be directly identified by their
<t>Assigning a unique prefix to each host may theoretically re assigned prefix. However, alternative host identification
duce methods, such as cookies, are commonly used. Therefore, unique
privacy, as hosts can be directly identified by their assigned prefix identifiability may not make much difference. The actual
prefix. However, alternative host identification methods, such as impact on privacy is therefore likely to be limited.</t>
cookies, are commonly used. Therefore, unique prefix identifiability
may not make much difference. The actual impact on privacy is
therefore likely to be limited.</t>
</dd>
</dl>
</li> </li>
<li> <li>
<dl> <t>Router Support for L3 Isolation:</t>
<dt>Router Support for L3 Isolation:</dt> <t>The router must support an L3 Isolation solution, e.g., <xref
<dd> target="RFC8273"/> or <xref target="RFC9663"/>.</t>
<t>The router must support an L3 Isolation solution, e.g., <xr
ef target="RFC8273"/> or
<xref target="RFC9663"/>.</t>
</dd>
</dl>
</li> </li>
<li> <li>
<dl> <t>A Large Number of Router Interfaces May be Needed:</t>
<dt>A Large Number of Router Interfaces May be Needed:</dt> <t>If the P2P method is used, the router must instantiate a
<dd> separate logical interface for every attached host. In this
<t>If the P2P method is used, the router must instantiate a se case, a large number of interfaces will be needed at the
parate router.</t>
logical interface for every attached host. In this case, a large
number of interfaces will be needed at the router.</t>
</dd>
</dl>
</li> </li>
<li> <li>
<dl> <t>Router as a Bottleneck:</t>
<dt>Router as a Bottleneck:</dt> <t>Since all communication between hosts is routed through the
<dd> router, the router may become a performance bottleneck in
<t>Since all communication between hosts is routed through the high-traffic scenarios.</t>
router,
the router may become a performance bottleneck in high-traffic
scenarios.</t>
</dd>
</dl>
</li> </li>
<li> <li>
<dl> <t>Incompatibility with Host-Based Multicast Services:</t>
<dt>Incompatibility with Host-Based Multicast Services:</dt> <t>Services that rely on multicast communication among hosts,
<dd> such as the Multicast Domain Name System <xref target="RFC6762"/>,
<t>Services that rely on multicast communication among hosts, will be disrupted.</t>
such as
Multicast Domain Name System <xref target="RFC6762"/>, will be disrupted.</t>
</dd>
</dl>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="applicability-of-l3-isolation"> <section anchor="applicability-of-l3-isolation">
<name>Applicability of L3 Isolation</name> <name>Applicability of L3 Isolation</name>
<t>Benefits:</t> <t>Benefits:</t>
<artwork><![CDATA[ <ul spacing="normal">
* All ND issues (Section 2.4) are mitigated, with the exception <li><t>All ND issues (<xref target="summary-of-nd-issues" format="default"/>)
of: are mitigated, with the exception
o LLA DAD multicast degrading performance, of:</t>
o LLA DAD not reliable in wireless networks, and <ul spacing="normal">
o On-link security <li>LLA DAD multicast degrading performance,</li>
<li>LLA DAD not reliable in wireless networks, and</li>
<li>on-link security.</li>
</ul>
<t>
These remaining issues depend on the characteristics of the These remaining issues depend on the characteristics of the
shared medium: shared medium:</t>
<ul spacing="normal">
o If the shared medium is Ethernet, the issues related to LLA <li>If the shared medium is Ethernet, the issues related to LLA
DAD multicast are negligible. DAD multicast are negligible.</li>
o If nodes can be trusted, such as in private networks, on- <li>If nodes can be trusted, such as in private networks, on-link security
link security concerns are not significant. concerns are not significant.</li>
</ul></li>
* No need for L2 Isolation. Consequently, this method can be <li>There is no need for L2 Isolation. Consequently, this method can be
applied in a wide range of scenarios, making it possibly the applied in a wide range of scenarios, making it possibly the
most practical host isolation method. most practical host isolation method.</li>
]]></artwork> </ul>
<t>Constraints, as discussed in Section 4.2.1:</t> <t>Constraints (as discussed in <xref target="applicability-of-l3l2-is
olation" format="default"/>):</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Unique Prefix Allocation</t> <t>Unique Prefix Allocation</t>
</li> </li>
<li> <li>
<t>Router Support for L3 Isolation</t> <t>Router Support for L3 Isolation</t>
</li> </li>
<li> <li>
<t>Router as a Bottleneck</t> <t>Router as a Bottleneck</t>
</li> </li>
<li> <li>
<t>Privacy Issue from Unique Prefix Identifiability.</t> <t>Privacy Issue from Unique Prefix Identifiability.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="applicability-of-partial-l2-isolation"> <section anchor="applicability-of-partial-l2-isolation">
<name>Applicability of Partial L2 Isolation</name> <name>Applicability of Partial L2 Isolation</name>
<t>Benefits:</t>
<artwork><![CDATA[
* Reduced Multicast Traffic:
This method reduces multicast traffic, particularly for address <t>Benefit:</t>
<ul spacing="normal">
<li>Reduced Multicast Traffic: This method reduces multicast traffic,
particularly for address
resolution, by dividing the subnet into multiple multicast resolution, by dividing the subnet into multiple multicast
domains. domains.</li>
]]></artwork> </ul>
<t>Constraint:</t> <t>Constraint:</t>
<artwork><![CDATA[ <ul spacing="normal">
* Router Support for Partial L2 Isolation: <li>Router Support for Partial L2 Isolation:
]]></artwork> The router must implement a Partial L2 Isolation solution such as
<t>The router must implement a Partial L2 Isolation solution such as WiND, SARP, ND optimization for TRILL, and Proxy ND in EVPN to
WiND, SARP, ND Optimization for TRILL, and Proxy ND in EVPN to support this method.</li>
support this method.</t> </ul>
</section> </section>
</section> </section>
<section anchor="guidelines-for-applying-isolation-methods"> <section anchor="guidelines-for-applying-isolation-methods">
<name>Guidelines for Applying Isolation Methods</name> <name>Guidelines for Applying Isolation Methods</name>
<t>Based on the applicability analysis provided in the preceding <t>Based on the applicability analysis provided in the preceding
sections, network administrators can determine whether to implement sections, network administrators can determine whether to implement
an isolation method and, if so, which method is most appropriate for an isolation method and, if so, which method is most appropriate for
their specific deployment.</t> their specific deployment.</t>
<t>A simple guideline is to consider the isolation methods in the order <t>A simple guideline is to consider the isolation methods in the order
listed in the preceding sections, progressing from the strongest listed in the preceding sections, progressing from the strongest
isolation to the weakest:</t> isolation to the weakest:</t>
<artwork><![CDATA[ <ul spacing="normal">
* Stronger isolation methods can prevent more ND issues, but may <li>Stronger isolation methods can prevent more ND issues, but may
also impose higher entry requirements. also impose higher entry requirements.</li>
* Weaker isolation methods have fewer entry requirements but may <li>Weaker isolation methods have fewer entry requirements but may
leave some ND issues unmitigated. leave some ND issues unmitigated.</li>
]]></artwork> </ul>
<t>The choice between L3+L2 Isolation and L3 Isolation often depends on <t>The choice between L3+L2 Isolation and L3 Isolation often depends on
the cost of implementing L2 Isolation:</t> the cost of implementing L2 Isolation:</t>
<artwork><![CDATA[ <ul spacing="normal">
* If the cost is acceptable, L3+L2 Isolation is preferable <li>If the cost is acceptable, L3+L2 Isolation is preferable
because it eliminates every ND issue listed in Section 2.4. because it eliminates every ND issue listed in <xref target="summary-of-nd-i
* Otherwise, L3 Isolation addresses most of those issues while ssues" format="default"/>.</li>
keeping the implementation effort reasonable. <li>Otherwise, L3 Isolation addresses most of those issues while
]]></artwork> keeping the implementation effort reasonable.</li>
</ul>
<t>Selecting an isolation method that is either too strong or too weak <t>Selecting an isolation method that is either too strong or too weak
does not result in serious consequences:</t> does not result in serious consequences:</t>
<artwork><![CDATA[ <ul spacing="normal">
* Choosing an overly strong isolation method may require the <li>Choosing an overly strong isolation method may require the
network administrator to meet higher entry requirements network administrator to meet higher entry requirements
initially, such as measures for L2 Isolation, additional initially, such as measures for L2 Isolation, additional
prefixes, or additional router capabilities. prefixes, or additional router capabilities.</li>
* Choosing a "weaker isolation method" may necessitate deploying <li>Choosing a weaker isolation method may necessitate deploying
supplemental ND mitigation techniques to address any unresolved supplemental ND mitigation techniques to address any unresolved
ND issues. ND issues.</li>
]]></artwork> </ul>
<t>In either case, the resulting solution can be functional and <t>In either case, the resulting solution can be functional and
effective.</t> effective.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document is a review of known ND issues and solutions, <t>This document is a review of known ND issues and solutions,
including security. It does not introduce any new solutions. including security. It does not introduce any new solutions.
Therefore, it does not introduce new security issues.</t> Therefore, it does not introduce new security issues.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no request to IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ccc-v6ops-address-accountability" to="AddrAcc"
/>
<displayreference target="RFC9797" to="MADINAS"/>
<displayreference target="I-D.ietf-6man-ipv6-over-wireless" to="SND"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
861" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"> 861.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<title>Neighbor Discovery for IP version 6 (IPv6)</title> 862.xml"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="W. Simpson" initials="W." surname="Simpson"/>
<author fullname="H. Soliman" initials="H." surname="Soliman"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the Neighbor Discovery protocol for IP
Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each o
ther's presence, to determine each other's link-layer addresses, to find routers
, and to maintain reachability information about the paths to active neighbors.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4861"/>
<seriesInfo name="DOI" value="10.17487/RFC4861"/>
</reference>
<reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4
862" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the steps a host takes in deciding how
to autoconfigure its interfaces in IP version 6. The autoconfiguration process i
ncludes generating a link-local address, generating global addresses via statele
ss address autoconfiguration, and the Duplicate Address Detection procedure to v
erify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="TR177">
<!-- FYI:
We've added URLs for the following reference(s):
[TR177]
-->
<reference anchor="TR177" target="https://www.broadband-forum.org/pdfs/t
r-177-1-0-1.pdf">
<front> <front>
<title>IPv6 in the context of TR-101</title> <title>IPv6 in the context of TR-101</title>
<author> <author>
<organization>Broadband Forum, TR-177</organization> <organization>Broadband Forum</organization>
</author> </author>
<date/> <date month="11" year="2017"/>
</front> </front>
<refcontent>TR-177</refcontent>
</reference> </reference>
<reference anchor="RIPE738" target="https://www.ripe.net/publications/do cs/ripe-738"> <reference anchor="RIPE738" target="https://www.ripe.net/publications/do cs/ripe-738">
<front> <front>
<title>IPv6 Address Allocation and Assignment Policy</title> <title>IPv6 Address Allocation and Assignment Policy</title>
<author> <author>
<organization>RIPE</organization> <organization>RIPE</organization>
</author> </author>
<date/> <date month="03" year="2020"/>
</front>
</reference>
<reference anchor="RFC3587" target="https://www.rfc-editor.org/info/rfc3
587" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3587.xml">
<front>
<title>IPv6 Global Unicast Address Format</title>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<date month="August" year="2003"/>
<abstract>
<t>This document obsoletes RFC 2374, "An IPv6 Aggregatable Global
Unicast Address Format". It defined an IPv6 address allocation structure that in
cludes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document
makes RFC 2374 and the TLA/NLA structure historic. This memo provides informati
on for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3587"/>
<seriesInfo name="DOI" value="10.17487/RFC3587"/>
</reference>
<reference anchor="RFC4193" target="https://www.rfc-editor.org/info/rfc4
193" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml">
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="B. Haberman" initials="B." surname="Haberman"/>
<date month="October" year="2005"/>
<abstract>
<t>This document defines an IPv6 unicast address format that is gl
obally unique and is intended for local communications, usually inside of a site
. These addresses are not expected to be routable on the global Internet. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4193"/>
<seriesInfo name="DOI" value="10.17487/RFC4193"/>
</reference>
<reference anchor="RFC3756" target="https://www.rfc-editor.org/info/rfc3
756" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3756.xml">
<front>
<title>IPv6 Neighbor Discovery (ND) Trust Models and Threats</title>
<author fullname="P. Nikander" initials="P." role="editor" surname="
Nikander"/>
<author fullname="J. Kempf" initials="J." surname="Kempf"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<date month="May" year="2004"/>
<abstract>
<t>The existing IETF standards specify that IPv6 Neighbor Discover
y (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Auth
entication Header (AH). However, the current specifications limit the security s
olutions to manual keying due to practical problems faced with automatic key man
agement. This document specifies three different trust models and discusses the
threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is
to define the requirements for Securing IPv6 Neighbor Discovery. This memo provi
des information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3756"/>
<seriesInfo name="DOI" value="10.17487/RFC3756"/>
</reference>
<reference anchor="RFC3971" target="https://www.rfc-editor.org/info/rfc3
971" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml">
<front>
<title>SEcure Neighbor Discovery (SEND)</title>
<author fullname="J. Arkko" initials="J." role="editor" surname="Ark
ko"/>
<author fullname="J. Kempf" initials="J." surname="Kempf"/>
<author fullname="B. Zill" initials="B." surname="Zill"/>
<author fullname="P. Nikander" initials="P." surname="Nikander"/>
<date month="March" year="2005"/>
<abstract>
<t>IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discove
r other nodes on the link, to determine their link-layer addresses to find route
rs, and to maintain reachability information about the paths to active neighbors
. If not secured, NDP is vulnerable to various attacks. This document specifies
security mechanisms for NDP. Unlike those in the original NDP specifications, th
ese mechanisms do not use IPsec. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3971"/>
<seriesInfo name="DOI" value="10.17487/RFC3971"/>
</reference>
<reference anchor="RFC3972" target="https://www.rfc-editor.org/info/rfc3
972" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3972.xml">
<front>
<title>Cryptographically Generated Addresses (CGA)</title>
<author fullname="T. Aura" initials="T." surname="Aura"/>
<date month="March" year="2005"/>
<abstract>
<t>This document describes a method for binding a public signature
key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Crypto
graphically Generated Addresses (CGA) are IPv6 addresses for which the interface
identifier is generated by computing a cryptographic one-way hash function from
a public key and auxiliary parameters. The binding between the public key and t
he address can be verified by re-computing the hash value and by comparing the h
ash with the interface identifier. Messages sent from an IPv6 address can be pro
tected by attaching the public key and auxiliary parameters and by signing the m
essage with the corresponding private key. The protection works without a certif
ication authority or any security infrastructure. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3972"/>
<seriesInfo name="DOI" value="10.17487/RFC3972"/>
</reference>
<reference anchor="RFC4389" target="https://www.rfc-editor.org/info/rfc4
389" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4389.xml">
<front>
<title>Neighbor Discovery Proxies (ND Proxy)</title>
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
<author fullname="M. Talwar" initials="M." surname="Talwar"/>
<author fullname="C. Patel" initials="C." surname="Patel"/>
<date month="April" year="2006"/>
<abstract>
<t>Bridging multiple links into a single entity has several operat
ional advantages. A single subnet prefix is sufficient to support multiple physi
cal links. There is no need to allocate subnet numbers to the different networks
, simplifying management. Bridging some types of media requires network-layer su
pport, however. This document describes these cases and specifies the IP-layer s
upport that enables bridging under these circumstances. This memo defines an Exp
erimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4389"/>
<seriesInfo name="DOI" value="10.17487/RFC4389"/>
</reference>
<reference anchor="RFC4429" target="https://www.rfc-editor.org/info/rfc4
429" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4429.xml">
<front>
<title>Optimistic Duplicate Address Detection (DAD) for IPv6</title>
<author fullname="N. Moore" initials="N." surname="Moore"/>
<date month="April" year="2006"/>
<abstract>
<t>Optimistic Duplicate Address Detection is an interoperable modi
fication of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Addres
s Autoconfiguration (RFC 2462) processes. The intention is to minimize address c
onfiguration delays in the successful case, to reduce disruption as far as possi
ble in the failure case, and to remain interoperable with unmodified hosts and r
outers. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4429"/>
<seriesInfo name="DOI" value="10.17487/RFC4429"/>
</reference>
<reference anchor="RFC6459" target="https://www.rfc-editor.org/info/rfc6
459" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6459.xml">
<front>
<title>IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Pac
ket System (EPS)</title>
<author fullname="J. Korhonen" initials="J." role="editor" surname="
Korhonen"/>
<author fullname="J. Soininen" initials="J." surname="Soininen"/>
<author fullname="B. Patil" initials="B." surname="Patil"/>
<author fullname="T. Savolainen" initials="T." surname="Savolainen"/
>
<author fullname="G. Bajko" initials="G." surname="Bajko"/>
<author fullname="K. Iisakkila" initials="K." surname="Iisakkila"/>
<date month="January" year="2012"/>
<abstract>
<t>The use of cellular broadband for accessing the Internet and ot
her data services via smartphones, tablets, and notebook/netbook computers has i
ncreased rapidly as a result of high-speed packet data networks such as HSPA, HS
PA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deplo
yed networks based on 3rd Generation Partnership Project (3GPP) network architec
tures are facing IPv4 address shortages at the Internet registries and are feeli
ng pressure to migrate to IPv6. This document describes the support for IPv6 in
3GPP network architectures. This document is not an Internet Standards Track spe
cification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6459"/>
<seriesInfo name="DOI" value="10.17487/RFC6459"/>
</reference>
<reference anchor="RFC7066" target="https://www.rfc-editor.org/info/rfc7
066" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7066.xml">
<front>
<title>IPv6 for Third Generation Partnership Project (3GPP) Cellular
Hosts</title>
<author fullname="J. Korhonen" initials="J." role="editor" surname="
Korhonen"/>
<author fullname="J. Arkko" initials="J." role="editor" surname="Ark
ko"/>
<author fullname="T. Savolainen" initials="T." surname="Savolainen"/
>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<date month="November" year="2013"/>
<abstract>
<t>As the deployment of third and fourth generation cellular netwo
rks progresses, a large number of cellular hosts are being connected to the Inte
rnet. Standardization organizations have made the Internet Protocol version 6 (I
Pv6) mandatory in their specifications. However, the concept of IPv6 covers many
aspects and numerous specifications. In addition, the characteristics of cellul
ar links in terms of bandwidth, cost, and delay put special requirements on how
IPv6 is used. This document considers IPv6 for cellular hosts that attach to the
General Packet Radio Service (GPRS), Universal Mobile Telecommunications System
(UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referre
d to as Third Generation Partnership Project (3GPP) networks). This document als
o lists specific IPv6 functionalities that need to be implemented in addition to
what is already prescribed in the IPv6 Node Requirements document (RFC 6434). I
t also discusses some issues related to the use of these components when operati
ng in these networks. This document obsoletes RFC 3316.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7066"/>
<seriesInfo name="DOI" value="10.17487/RFC7066"/>
</reference>
<reference anchor="RFC6575" target="https://www.rfc-editor.org/info/rfc6
575" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6575.xml">
<front>
<title>Address Resolution Protocol (ARP) Mediation for IP Interworki
ng of Layer 2 VPNs</title>
<author fullname="H. Shah" initials="H." role="editor" surname="Shah
"/>
<author fullname="E. Rosen" initials="E." role="editor" surname="Ros
en"/>
<author fullname="G. Heron" initials="G." role="editor" surname="Her
on"/>
<author fullname="V. Kompella" initials="V." role="editor" surname="
Kompella"/>
<date month="June" year="2012"/>
<abstract>
<t>The Virtual Private Wire Service (VPWS), detailed in RFC 4664,
provides point-to-point connections between pairs of Customer Edge (CE) devices.
It does so by binding two Attachment Circuits (each connecting a CE device with
a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In gener
al, the Attachment Circuits must be of the same technology (e.g., both Ethernet
or both ATM), and the pseudowire must carry the frames of that technology. Howev
er, if it is known that the frames' payload consists solely of IP datagrams, it
is possible to provide a point-to-point connection in which the pseudowire conne
cts Attachment Circuits of different technologies. This requires the PEs to perf
orm a function known as "Address Resolution Protocol (ARP) Mediation". ARP Media
tion refers to the process of resolving Layer 2 addresses when different resolut
ion protocols are used on either Attachment Circuit. The methods described in th
is document are applicable even when the CEs run a routing protocol between them
, as long as the routing protocol runs over IP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6575"/>
<seriesInfo name="DOI" value="10.17487/RFC6575"/>
</reference>
<reference anchor="RFC6583" target="https://www.rfc-editor.org/info/rfc6
583" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6583.xml">
<front>
<title>Operational Neighbor Discovery Problems</title>
<author fullname="I. Gashinsky" initials="I." surname="Gashinsky"/>
<author fullname="J. Jaeggli" initials="J." surname="Jaeggli"/>
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
<date month="March" year="2012"/>
<abstract>
<t>In IPv4, subnets are generally small, made just large enough to
cover the actual number of machines on the subnet. In contrast, the default IPv
6 subnet size is a /64, a number so large it covers trillions of addresses, the
overwhelming number of which will be unassigned. Consequently, simplistic implem
entations of Neighbor Discovery (ND) can be vulnerable to deliberate or accident
al denial of service (DoS), whereby they attempt to perform address resolution f
or large numbers of unassigned addresses. Such denial-of-service attacks can be
launched intentionally (by an attacker) or result from legitimate operational to
ols or accident conditions. As a result of these vulnerabilities, new devices ma
y not be able to "join" a network, it may be impossible to establish new IPv6 fl
ows, and existing IPv6 transported flows may be interrupted.</t>
<t>This document describes the potential for DoS in detail and sug
gests possible implementation improvements as well as operational mitigation tec
hniques that can, in some cases, be used to protect against or at least alleviat
e the impact of such attacks. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6583"/>
<seriesInfo name="DOI" value="10.17487/RFC6583"/>
</reference>
<reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc6
775" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml">
<front>
<title>Neighbor Discovery Optimization for IPv6 over Low-Power Wirel
ess Personal Area Networks (6LoWPANs)</title>
<author fullname="Z. Shelby" initials="Z." role="editor" surname="Sh
elby"/>
<author fullname="S. Chakrabarti" initials="S." surname="Chakrabarti
"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="November" year="2012"/>
<abstract>
<t>The IETF work in IPv6 over Low-power Wireless Personal Area Net
work (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar li
nk technologies have limited or no usage of multicast signaling due to energy co
nservation. In addition, the wireless network may not strictly follow the tradit
ional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not design
ed for non- transitive wireless links, as its reliance on the traditional IPv6 l
ink concept and its heavy use of multicast make it inefficient and sometimes imp
ractical in a low-power and lossy network. This document describes simple optimi
zations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate add
ress detection for Low- power Wireless Personal Area Networks and similar networ
ks. The document thus updates RFC 4944 to specify the use of the optimizations d
efined here. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6775"/>
<seriesInfo name="DOI" value="10.17487/RFC6775"/>
</reference>
<reference anchor="RFC8505" target="https://www.rfc-editor.org/info/rfc8
505" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml">
<front>
<title>Registration Extensions for IPv6 over Low-Power Wireless Pers
onal Area Network (6LoWPAN) Neighbor Discovery</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="T
hubert"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="S. Chakrabarti" initials="S." surname="Chakrabarti
"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<date month="November" year="2018"/>
<abstract>
<t>This specification updates RFC 6775 -- the Low-Power Wireless P
ersonal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify th
e role of the protocol as a registration technique and simplify the registration
operation in 6LoWPAN routers, as well as to provide enhancements to the registr
ation capabilities and mobility detection for different network topologies, incl
uding the Routing Registrars performing routing for host routes and/or proxy Nei
ghbor Discovery in a low-power network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8505"/>
<seriesInfo name="DOI" value="10.17487/RFC8505"/>
</reference>
<reference anchor="RFC8928" target="https://www.rfc-editor.org/info/rfc8
928" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml">
<front>
<title>Address-Protected Neighbor Discovery for Low-Power and Lossy
Networks</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="T
hubert"/>
<author fullname="B. Sarikaya" initials="B." surname="Sarikaya"/>
<author fullname="M. Sethi" initials="M." surname="Sethi"/>
<author fullname="R. Struik" initials="R." surname="Struik"/>
<date month="November" year="2020"/>
<abstract>
<t>This document updates the IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 an
d 8505. The new extension is called Address-Protected Neighbor Discovery (AP-ND)
, and it protects the owner of an address against address theft and impersonatio
n attacks in a Low-Power and Lossy Network (LLN). Nodes supporting this extensio
n compute a cryptographic identifier (Crypto-ID), and use it with one or more of
their Registered Addresses. The Crypto-ID identifies the owner of the Registere
d Address and can be used to provide proof of ownership of the Registered Addres
ses. Once an address is registered with the Crypto-ID and a proof of ownership i
s provided, only the owner of that address can modify the registration informati
on, thereby enforcing Source Address Validation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8928"/>
<seriesInfo name="DOI" value="10.17487/RFC8928"/>
</reference>
<reference anchor="RFC8929" target="https://www.rfc-editor.org/info/rfc8
929" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml">
<front>
<title>IPv6 Backbone Router</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="T
hubert"/>
<author fullname="C.E. Perkins" initials="C.E." surname="Perkins"/>
<author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abeg
noli"/>
<date month="November" year="2020"/>
<abstract>
<t>This document updates RFCs 6775 and 8505 in order to enable pro
xy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone R
outers". Backbone Routers are placed along the wireless edge of a backbone and f
ederate multiple wireless links to form a single Multi-Link Subnet (MLSN).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8929"/>
<seriesInfo name="DOI" value="10.17487/RFC8929"/>
</reference>
<reference anchor="I-D.ietf-6man-ipv6-over-wireless" target="https://dat
atracker.ietf.org/doc/html/draft-ietf-6man-ipv6-over-wireless-08" xml:base="http
s://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-over-wireless.x
ml">
<front>
<title>Architecture and Framework for IPv6 over Non-Broadcast Access
</title>
<author fullname="Pascal Thubert" initials="P." surname="Thubert"/>
<author fullname="Michael Richardson" initials="M." surname="Richard
son">
<organization>Sandelman Software Works</organization>
</author>
<date day="19" month="May" year="2025"/>
<abstract>
<t>This document presents an architecture and framework for IPv6 a
ccess networks that decouples the network-layer concepts of Links, Interface, an
d Subnets from the link-layer concepts of links, ports, and broadcast domains, a
nd limits the reliance on link-layer broadcasts. This architecture is suitable f
or IPv6 over any network, including non-broadcast networks, which is typically t
he case for intangible media such as wireless and virtual networks such as overl
ays. A study of the issues with IPv6 ND over intangible media is presented, and
a framework to solve those issues within the new architecture is proposed.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-ipv6-over-wir
eless-08"/>
</reference>
<reference anchor="RFC6957" target="https://www.rfc-editor.org/info/rfc6
957" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6957.xml">
<front>
<title>Duplicate Address Detection Proxy</title>
<author fullname="F. Costa" initials="F." surname="Costa"/>
<author fullname="J-M. Combes" role="editor" surname="J-M. Combes"/>
<author fullname="X. Pougnard" initials="X." surname="Pougnard"/>
<author fullname="H. Li" initials="H." surname="Li"/>
<date month="June" year="2013"/>
<abstract>
<t>The document describes a proxy-based mechanism allowing the use
of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint arc
hitecture with a "split-horizon" forwarding scheme, primarily deployed for Digit
al Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signal
ing, the first-hop router stores in a Binding Table all known IPv6 addresses use
d on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an
address already used by another node, the first-hop router defends the address r
ather than the device using the address.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6957"/>
<seriesInfo name="DOI" value="10.17487/RFC6957"/>
</reference>
<reference anchor="RFC7039" target="https://www.rfc-editor.org/info/rfc7
039" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7039.xml">
<front>
<title>Source Address Validation Improvement (SAVI) Framework</title
>
<author fullname="J. Wu" initials="J." surname="Wu"/>
<author fullname="J. Bi" initials="J." surname="Bi"/>
<author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="C. Vogt" initials="C." role="editor" surname="Vogt
"/>
<date month="October" year="2013"/>
<abstract>
<t>Source Address Validation Improvement (SAVI) methods were devel
oped to prevent nodes attached to the same IP link from spoofing each other's IP
addresses, so as to complement ingress filtering with finer-grained, standardiz
ed IP source address validation. This document is a framework document that desc
ribes and motivates the design of the SAVI methods. Particular SAVI methods are
described in other documents.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7039"/>
<seriesInfo name="DOI" value="10.17487/RFC7039"/>
</reference>
<reference anchor="RFC6105" target="https://www.rfc-editor.org/info/rfc6
105" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6105.xml">
<front>
<title>IPv6 Router Advertisement Guard</title>
<author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abeg
noli"/>
<author fullname="G. Van de Velde" initials="G." surname="Van de Vel
de"/>
<author fullname="C. Popoviciu" initials="C." surname="Popoviciu"/>
<author fullname="J. Mohacsi" initials="J." surname="Mohacsi"/>
<date month="February" year="2011"/>
<abstract>
<t>Routed protocols are often susceptible to spoof attacks. The ca
nonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that i
s non-trivial to deploy. This document proposes a light-weight alternative and c
omplement to SEND based on filtering in the layer-2 network fabric, using a vari
ety of filtering criteria, including, for example, SEND status. This document is
not an Internet Standards Track specification; it is published for informationa
l purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6105"/>
<seriesInfo name="DOI" value="10.17487/RFC6105"/>
</reference>
<reference anchor="RFC7113" target="https://www.rfc-editor.org/info/rfc7
113" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7113.xml">
<front>
<title>Implementation Advice for IPv6 Router Advertisement Guard (RA
-Guard)</title>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<date month="February" year="2014"/>
<abstract>
<t>The IPv6 Router Advertisement Guard (RA-Guard) mechanism is com
monly employed to mitigate attack vectors based on forged ICMPv6 Router Advertis
ement messages. Many existing IPv6 deployments rely on RA-Guard as the first lin
e of defense against the aforementioned attack vectors. However, some implementa
tions of RA-Guard have been found to be prone to circumvention by employing IPv6
Extension Headers. This document describes the evasion techniques that affect t
he aforementioned implementations and formally updates RFC 6105, such that the a
forementioned RA-Guard evasion vectors are eliminated.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7113"/>
<seriesInfo name="DOI" value="10.17487/RFC7113"/>
</reference>
<reference anchor="RFC7527" target="https://www.rfc-editor.org/info/rfc7
527" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7527.xml">
<front>
<title>Enhanced Duplicate Address Detection</title>
<author fullname="R. Asati" initials="R." surname="Asati"/>
<author fullname="H. Singh" initials="H." surname="Singh"/>
<author fullname="W. Beebee" initials="W." surname="Beebee"/>
<author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
<author fullname="E. Dart" initials="E." surname="Dart"/>
<author fullname="W. George" initials="W." surname="George"/>
<date month="April" year="2015"/>
<abstract>
<t>IPv6 Loopback Suppression and Duplicate Address Detection (DAD)
are discussed in Appendix A of RFC 4862. That specification mentions a hardware
-assisted mechanism to detect looped back DAD messages. If hardware cannot suppr
ess looped back DAD messages, a software solution is required. Several service p
rovider communities have expressed a need for automated detection of looped back
Neighbor Discovery (ND) messages used by DAD. This document includes mitigation
techniques and outlines the Enhanced DAD algorithm to automate the detection of
looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhan
ced DAD algorithm allows IPv6 to self-heal after a loopback is placed and remove
d. Further, for certain access networks, this document automates resolving a spe
cific duplicate address conflict. This document updates RFCs 4429, 4861, and 486
2.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7527"/>
<seriesInfo name="DOI" value="10.17487/RFC7527"/>
</reference>
<reference anchor="RFC7586" target="https://www.rfc-editor.org/info/rfc7
586" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7586.xml">
<front>
<title>The Scalable Address Resolution Protocol (SARP) for Large Dat
a Centers</title>
<author fullname="Y. Nachum" initials="Y." surname="Nachum"/>
<author fullname="L. Dunbar" initials="L." surname="Dunbar"/>
<author fullname="I. Yerushalmi" initials="I." surname="Yerushalmi"/
>
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
<date month="June" year="2015"/>
<abstract>
<t>This document introduces the Scalable Address Resolution Protoc
ol (SARP), an architecture that uses proxy gateways to scale large data center n
etworks. SARP is based on fast proxies that significantly reduce switches' Filte
ring Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery
(ND) on network elements in an environment where hosts within one subnet (or VLA
N) can spread over various locations. SARP is targeted for massive data centers
with a significant number of Virtual Machines (VMs) that can move across various
physical locations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7586"/>
<seriesInfo name="DOI" value="10.17487/RFC7586"/>
</reference>
<reference anchor="RFC7772" target="https://www.rfc-editor.org/info/rfc7
772" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7772.xml">
<front>
<title>Reducing Energy Consumption of Router Advertisements</title>
<author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko
"/>
<author fullname="L. Colitti" initials="L." surname="Colitti"/>
<date month="February" year="2016"/>
<abstract>
<t>Frequent Router Advertisement messages can severely impact host
power consumption. This document recommends operational practices to avoid such
impact.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="202"/>
<seriesInfo name="RFC" value="7772"/>
<seriesInfo name="DOI" value="10.17487/RFC7772"/>
</reference>
<reference anchor="RFC8273" target="https://www.rfc-editor.org/info/rfc8
273" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8273.xml">
<front>
<title>Unique IPv6 Prefix per Host</title>
<author fullname="J. Brzozowski" initials="J." surname="Brzozowski"/
>
<author fullname="G. Van de Velde" initials="G." surname="Van de Vel
de"/>
<date month="December" year="2017"/>
<abstract>
<t>This document outlines an approach utilizing existing IPv6 prot
ocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IP
v6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix ov
er a unique service-provider IPv6 address include improved host isolation and en
hanced subscriber management on shared network segments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8273"/>
<seriesInfo name="DOI" value="10.17487/RFC8273"/>
</reference>
<reference anchor="RFC8302" target="https://www.rfc-editor.org/info/rfc8
302" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8302.xml">
<front>
<title>Transparent Interconnection of Lots of Links (TRILL): ARP and
Neighbor Discovery (ND) Optimization</title>
<author fullname="Y. Li" initials="Y." surname="Li"/>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="L. Dunbar" initials="L." surname="Dunbar"/>
<author fullname="R. Perlman" initials="R." surname="Perlman"/>
<author fullname="M. Umair" initials="M." surname="Umair"/>
<date month="January" year="2018"/>
<abstract>
<t>This document describes mechanisms to optimize the Address Reso
lution Protocol (ARP) and Neighbor Discovery (ND) traffic in a Transparent Inter
connection of Lots of Links (TRILL) campus. TRILL switches maintain a cache of I
P / Media Access Control (MAC) address / Data Label bindings that are learned fr
om ARP/ND requests and responses that pass through them. In many cases, this cac
he allows an edge Routing Bridge (RBridge) to avoid flooding an ARP/ND request b
y either responding to it directly or encapsulating it and unicasting it. Such o
ptimization reduces packet flooding over a TRILL campus.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8302"/>
<seriesInfo name="DOI" value="10.17487/RFC8302"/>
</reference>
<reference anchor="RFC9131" target="https://www.rfc-editor.org/info/rfc9
131" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9131.xml">
<front>
<title>Gratuitous Neighbor Discovery: Creating Neighbor Cache Entrie
s on First-Hop Routers</title>
<author fullname="J. Linkova" initials="J." surname="Linkova"/>
<date month="October" year="2021"/>
<abstract>
<t>Neighbor Discovery (RFC 4861) is used by IPv6 nodes to determin
e the link-layer addresses of neighboring nodes as well as to discover and maint
ain reachability information. This document updates RFC 4861 to allow routers to
proactively create a Neighbor Cache entry when a new IPv6 address is assigned t
o a node. It also updates RFC 4861 and recommends that nodes send unsolicited Ne
ighbor Advertisements upon assigning a new IPv6 address. These changes will mini
mize the delay and packet loss when a node initiates connections to an off-link
destination from a new IPv6 address.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9131"/>
<seriesInfo name="DOI" value="10.17487/RFC9131"/>
</reference>
<reference anchor="RFC9161" target="https://www.rfc-editor.org/info/rfc9
161" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9161.xml">
<front>
<title>Operational Aspects of Proxy ARP/ND in Ethernet Virtual Priva
te Networks</title>
<author fullname="J. Rabadan" initials="J." role="editor" surname="R
abadan"/>
<author fullname="S. Sathappan" initials="S." surname="Sathappan"/>
<author fullname="K. Nagaraj" initials="K." surname="Nagaraj"/>
<author fullname="G. Hankins" initials="G." surname="Hankins"/>
<author fullname="T. King" initials="T." surname="King"/>
<date month="January" year="2022"/>
<abstract>
<t>This document describes the Ethernet Virtual Private Network (E
VPN) Proxy ARP/ND function augmented by the capability of the ARP/ND Extended Co
mmunity. From that perspective, this document updates the EVPN specification to
provide more comprehensive documentation of the operation of the Proxy ARP/ND fu
nction. The EVPN Proxy ARP/ND function and the ARP/ND Extended Community help op
erators of Internet Exchange Points, Data Centers, and other networks deal with
IPv4 and IPv6 address resolution issues associated with large Broadcast Domains
by reducing and even suppressing the flooding produced by address resolution in
the EVPN network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9161"/>
<seriesInfo name="DOI" value="10.17487/RFC9161"/>
</reference>
<reference anchor="RFC9663" target="https://www.rfc-editor.org/info/rfc9
663" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9663.xml">
<front>
<title>Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
IPv6 Prefixes per Client in Large Broadcast Networks</title>
<author fullname="L. Colitti" initials="L." surname="Colitti"/>
<author fullname="J. Linkova" initials="J." role="editor" surname="L
inkova"/>
<author fullname="X. Ma" initials="X." role="editor" surname="Ma"/>
<date month="October" year="2024"/>
<abstract>
<t>This document discusses an IPv6 deployment scenario when indivi
dual nodes connected to large broadcast networks (such as enterprise networks or
public Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegati
on (DHCPv6-PD), as specified in RFC 8415.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9663"/>
<seriesInfo name="DOI" value="10.17487/RFC9663"/>
</reference>
<reference anchor="RFC4903" target="https://www.rfc-editor.org/info/rfc4
903" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4903.xml">
<front>
<title>Multi-Link Subnet Issues</title>
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
<date month="June" year="2007"/>
<abstract>
<t>There have been several proposals around the notion that a subn
et may span multiple links connected by routers. This memo documents the issues
and potential problems that have been raised with such an approach. This memo pr
ovides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4903"/>
<seriesInfo name="DOI" value="10.17487/RFC4903"/>
</reference>
<reference anchor="RFC7342" target="https://www.rfc-editor.org/info/rfc7
342" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7342.xml">
<front>
<title>Practices for Scaling ARP and Neighbor Discovery (ND) in Larg
e Data Centers</title>
<author fullname="L. Dunbar" initials="L." surname="Dunbar"/>
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
<author fullname="I. Gashinsky" initials="I." surname="Gashinsky"/>
<date month="August" year="2014"/>
<abstract>
<t>This memo documents some operational practices that allow ARP a
nd Neighbor Discovery (ND) to scale in data center environments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7342"/>
<seriesInfo name="DOI" value="10.17487/RFC7342"/>
</reference>
<reference anchor="RFC9119" target="https://www.rfc-editor.org/info/rfc9
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9119.xml">
<front>
<title>Multicast Considerations over IEEE 802 Wireless Media</title>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<author fullname="M. McBride" initials="M." surname="McBride"/>
<author fullname="D. Stanley" initials="D." surname="Stanley"/>
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
<author fullname="JC. Zúñiga" initials="JC." surname="Zúñiga"/>
<date month="October" year="2021"/>
<abstract>
<t>Well-known issues with multicast have prevented the deployment
of multicast in 802.11 (Wi-Fi) and other local-area wireless environments. This
document describes the known limitations of wireless (primarily 802.11) Layer 2
multicast. Also described are certain multicast enhancement features that have b
een specified by the IETF and by IEEE 802 for wireless media, as well as some op
erational choices that can be made to improve the performance of the network. Fi
nally, some recommendations are provided about the usage and combination of thes
e features and operational choices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9119"/>
<seriesInfo name="DOI" value="10.17487/RFC9119"/>
</reference>
<reference anchor="I-D.ietf-madinas-use-cases" target="https://datatrack
er.ietf.org/doc/html/draft-ietf-madinas-use-cases-19" xml:base="https://bib.ietf
.org/public/rfc/bibxml3/reference.I-D.ietf-madinas-use-cases.xml">
<front>
<title>Randomized and Changing MAC Address: Context, Network Impacts
, and Use Cases</title>
<author fullname="Jerome Henry" initials="J." surname="Henry">
<organization>Cisco Systems</organization>
</author>
<author fullname="Yiu Lee" initials="Y." surname="Lee">
<organization>Comcast</organization>
</author>
<date day="20" month="December" year="2024"/>
<abstract>
<t>To limit the privacy issues created by the association between
a device, its traffic, its location, and its user in [IEEE_802] networks, client
and client Operating System vendors have started implementing MAC address rando
mization. This technology is particularly important in Wi-Fi [IEEE_802.11] netwo
rks due to the over-the-air medium and device mobility. When such randomization
happens, some in-network states may break, which may affect network connectivity
and user experience. At the same time, devices may continue using other stable
identifiers, defeating the MAC address randomization purposes. This document lis
ts various network environments and a range of network services that may be affe
cted by such randomization. This document then examines settings where the user
experience may be affected by in-network state disruption. Last, this document e
xamines two existing frameworks to maintain user privacy while preserving user q
uality of experience and network operation efficiency.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-madinas-use-cases-
19"/>
</reference>
<reference anchor="RFC9099" target="https://www.rfc-editor.org/info/rfc9
099" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9099.xml">
<front>
<title>Operational Security Considerations for IPv6 Networks</title>
<author fullname="É. Vyncke" surname="É. Vyncke"/>
<author fullname="K. Chittimaneni" initials="K." surname="Chittimane
ni"/>
<author fullname="M. Kaeo" initials="M." surname="Kaeo"/>
<author fullname="E. Rey" initials="E." surname="Rey"/>
<date month="August" year="2021"/>
<abstract>
<t>Knowledge and experience on how to operate IPv4 networks secure
ly is available, whether the operator is an Internet Service Provider (ISP) or a
n enterprise internal network. However, IPv6 presents some new security challeng
es. RFC 4942 describes security issues in the protocol, but network managers als
o need a more practical, operations-minded document to enumerate advantages and/
or disadvantages of certain choices.</t>
<t>This document analyzes the operational security issues associat
ed with several types of networks and proposes technical and procedural mitigati
on techniques. This document is only applicable to managed networks, such as ent
erprise networks, service provider networks, or managed residential networks.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="9099"/>
<seriesInfo name="DOI" value="10.17487/RFC9099"/>
</reference>
<reference anchor="RFC8415" target="https://www.rfc-editor.org/info/rfc8
415" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml">
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
<author fullname="B. Volz" initials="B." surname="Volz"/>
<author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko
"/>
<author fullname="M. Richardson" initials="M." surname="Richardson"/
>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<author fullname="T. Lemon" initials="T." surname="Lemon"/>
<author fullname="T. Winters" initials="T." surname="Winters"/>
<date month="November" year="2018"/>
<abstract>
<t>This document describes the Dynamic Host Configuration Protocol
for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network c
onfiguration parameters, IP addresses, and prefixes. Parameters can be provided
statelessly, or in combination with stateful assignment of one or more IPv6 addr
esses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition
to stateless address autoconfiguration (SLAAC).</t>
<t>This document updates the text from RFC 3315 (the original DHCP
v6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv
6 (RFC 3736), an option to specify an upper bound for how long a client should w
ait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6
clients when DHCPv6 service is not available (RFC 7083), and relay agent handlin
g of unknown messages (RFC 7283). In addition, this document clarifies the inter
actions between models of operation (RFC 7550). As such, this document obsoletes
RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8415"/>
<seriesInfo name="DOI" value="10.17487/RFC8415"/>
</reference>
<reference anchor="I-D.ccc-v6ops-address-accountability" target="https:/
/datatracker.ietf.org/doc/html/draft-ccc-v6ops-address-accountability-00" xml:ba
se="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ccc-v6ops-address-acco
untability.xml">
<front>
<title>IPv6 Address Accountability Considerations</title>
<author fullname="Tim Chown" initials="T." surname="Chown">
<organization>Jisc</organization>
</author>
<author fullname="Chris Cummings" initials="C." surname="Cummings">
<organization>Energy Sciences Network</organization>
</author>
<author fullname="Dale W. Carder" initials="D. W." surname="Carder">
<organization>ESnet</organization>
</author>
<date day="21" month="October" year="2024"/>
<abstract>
<t>Hosts in IPv4 networks typically acquire addresses by use of DH
CP, and retain that address and only that address while the DHCP lease remains v
alid. In IPv6 networks, hosts may use DHCPv6, but may instead autoconfigure thei
r own global address(es), and potentially use many privacy addresses over time.
This behaviour places an additional burden on network operators who require addr
ess accountability for their users and devices. There has been some discussion o
f this issue on various mail lists; this text attempts to capture the issues to
encourage further discussion.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ccc-v6ops-address-accou
ntability-00"/>
</reference>
<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2
026" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml">
<front>
<title>The Internet Standards Process -- Revision 3</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="October" year="1996"/>
<abstract>
<t>This memo documents the process used by the Internet community
for the standardization of protocols and procedures. It defines the stages in th
e standardization process, the requirements for moving a document between stages
and the types of documents used during this process. This document specifies an
Internet Best Current Practices for the Internet Community, and requests discus
sion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="2026"/>
<seriesInfo name="DOI" value="10.17487/RFC2026"/>
</reference>
<reference anchor="RFC7278" target="https://www.rfc-editor.org/info/rfc7
278" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7278.xml">
<front>
<title>Extending an IPv6 /64 Prefix from a Third Generation Partners
hip Project (3GPP) Mobile Interface to a LAN Link</title>
<author fullname="C. Byrne" initials="C." surname="Byrne"/>
<author fullname="D. Drown" initials="D." surname="Drown"/>
<author fullname="A. Vizdal" initials="A." surname="Vizdal"/>
<date month="June" year="2014"/>
<abstract>
<t>This document describes requirements for extending an IPv6 /64
prefix from a User Equipment Third Generation Partnership Project (3GPP) radio i
nterface to a LAN link and describes two implementation examples.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7278"/>
<seriesInfo name="DOI" value="10.17487/RFC7278"/>
</reference>
<reference anchor="RFC6085" target="https://www.rfc-editor.org/info/rfc6
085" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6085.xml">
<front>
<title>Address Mapping of IPv6 Multicast Packets on Ethernet</title>
<author fullname="S. Gundavelli" initials="S." surname="Gundavelli"/
>
<author fullname="M. Townsley" initials="M." surname="Townsley"/>
<author fullname="O. Troan" initials="O." surname="Troan"/>
<author fullname="W. Dec" initials="W." surname="Dec"/>
<date month="January" year="2011"/>
<abstract>
<t>When transmitting an IPv6 packet with a multicast destination a
ddress, the IPv6 destination address is mapped to an Ethernet link-layer multica
st address. This document clarifies that a mapping of an IPv6 packet with a mult
icast destination address may in some circumstances map to an Ethernet link-laye
r unicast address. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6085"/>
<seriesInfo name="DOI" value="10.17487/RFC6085"/>
</reference>
<reference anchor="RFC5517" target="https://www.rfc-editor.org/info/rfc5
517" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5517.xml">
<front>
<title>Cisco Systems' Private VLANs: Scalable Security in a Multi-Cl
ient Environment</title>
<author fullname="S. HomChaudhuri" initials="S." surname="HomChaudhu
ri"/>
<author fullname="M. Foschiano" initials="M." surname="Foschiano"/>
<date month="February" year="2010"/>
<abstract>
<t>This document describes a mechanism to achieve device isolation
through the application of special Layer 2 forwarding constraints. Such a mecha
nism allows end devices to share the same IP subnet while being Layer 2 isolated
, which in turn allows network designers to employ larger subnets and so reduce
the address management overhead.</t>
<t>Some of the numerous deployment scenarios of the aforementioned
mechanism (which range from data center designs to Ethernet-to-the-home-basemen
t networks) are mentioned in the following text to exemplify the mechanism's pos
sible usages; however, this document is not intended to cover all such deploymen
t scenarios nor delve into their details. This document is not an Internet Stand
ards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5517"/>
<seriesInfo name="DOI" value="10.17487/RFC5517"/>
</reference>
<reference anchor="RFC7102" target="https://www.rfc-editor.org/info/rfc7
102" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml">
<front>
<title>Terms Used in Routing for Low-Power and Lossy Networks</title
>
<author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
<date month="January" year="2014"/>
<abstract>
<t>This document provides a glossary of terminology used in routin
g requirements and solutions for networks referred to as Low-Power and Lossy Net
works (LLNs). An LLN is typically composed of many embedded devices with limited
power, memory, and processing resources interconnected by a variety of links. T
here is a wide scope of application areas for LLNs, including industrial monitor
ing, building automation (e.g., heating, ventilation, air conditioning, lighting
, access control, fire), connected home, health care, environmental monitoring,
urban sensor networks, energy management, assets tracking, and refrigeration.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="7102"/>
<seriesInfo name="DOI" value="10.17487/RFC7102"/>
</reference>
<reference anchor="RFC9686" target="https://www.rfc-editor.org/info/rfc9
686" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9686.xml">
<front>
<title>Registering Self-Generated IPv6 Addresses Using DHCPv6</title
>
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<author fullname="R. Asati" initials="R." surname="Asati"/>
<author fullname="L. Colitti" initials="L." surname="Colitti"/>
<author fullname="J. Linkova" initials="J." surname="Linkova"/>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<date month="December" year="2024"/>
<abstract>
<t>This document defines a method to inform a DHCPv6 server that a
device has one or more self-generated or statically configured addresses.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9686"/>
<seriesInfo name="DOI" value="10.17487/RFC9686"/>
</reference>
<reference anchor="RFC2461" target="https://www.rfc-editor.org/info/rfc2
461" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2461.xml">
<front>
<title>Neighbor Discovery for IP Version 6 (IPv6)</title>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="W. Simpson" initials="W." surname="Simpson"/>
<date month="December" year="1998"/>
<abstract>
<t>This document specifies the Neighbor Discovery protocol for IP
Version 6. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2461"/>
<seriesInfo name="DOI" value="10.17487/RFC2461"/>
</reference>
<reference anchor="RFC2462" target="https://www.rfc-editor.org/info/rfc2
462" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2462.xml">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="December" year="1998"/>
<abstract>
<t>This document specifies the steps a host takes in deciding how
to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2462"/>
<seriesInfo name="DOI" value="10.17487/RFC2462"/>
</reference>
<reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6
762" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml">
<front>
<title>Multicast DNS</title>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
<author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
<date month="February" year="2013"/>
<abstract>
<t>As networked devices become smaller, more portable, and more ub
iquitous, the ability to operate with less configured infrastructure is increasi
ngly important. In particular, the ability to look up DNS resource record data t
ypes (including, but not limited to, host names) in the absence of a conventiona
l managed DNS server is useful.</t>
<t>Multicast DNS (mDNS) provides the ability to perform DNS-like o
perations on the local link in the absence of any conventional Unicast DNS serve
r. In addition, Multicast DNS designates a portion of the DNS namespace to be fr
ee for local use, without the need to pay any annual fee, and without the need t
o set up delegations or otherwise configure a conventional DNS server to answer
for those names.</t>
<t>The primary benefits of Multicast DNS names are that (i) they r
equire little or no administration or configuration to set them up, (ii) they wo
rk when no infrastructure is present, and (iii) they work during infrastructure
failures.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6762"/> <refcontent>RIPE-738</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC6762"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
587.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
193.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
756.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
971.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
972.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
389.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
429.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
459.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
066.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
575.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
583.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
775.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
505.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
928.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
929.xml"/>
<!-- [SND]
draft-ietf-6man-ipv6-over-wireless-08
IESG State: I-D Exists as of 08/01/25
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-6man-ipv6-over-wireless.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
957.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
039.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
105.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
113.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
527.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
586.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
772.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
273.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
302.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
131.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
161.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
663.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
903.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
342.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
119.xml"/>
<!-- [MADINAS] Note to PE:
Updated draft-ietf-madinas-use-cases-19 to RFC 9797
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
797.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
099.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
415.xml"/>
<!-- [AddrAcc]
draft-ccc-v6ops-address-accountability-00
IESG State: Expired as of 08/01/25
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ccc-v6ops-address-accountability.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
026.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
278.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
085.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
517.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
102.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
686.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
461.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
462.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
762.xml"/>
</references> </references>
</references> </references>
<?line 1029?>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors would like to thank Eric Vyncke, Gunter Van de Velde, <t>The authors would like to thank <contact fullname="Eric Vyncke"/>,
Lorenzo Colitti, Erik Kline, Warren Kumari, Mohamed Boucadair, Gorry <contact fullname="Gunter Van de Velde"/>, <contact fullname="Lorenzo
Fairhurst, Pascal Thubert, Jen Linkova, Brian Carpenter, Mike Colitti"/>, <contact fullname="Erik Kline"/>, <contact fullname="Warren
Ackermann, Nalini Elkins, Ed Horley, Ole Troan, David Thaler, Kumari"/>, <contact fullname="Mohamed Boucadair"/>, <contact
Chongfeng Xie, Chris Cummings, Dale Carder, Tim Chown, Priyanka fullname="Gorry Fairhurst"/>, <contact fullname="Pascal Thubert"/>,
Sinha, Aijun Wang, Ines Robles, Magnus Westerlund, Barry Leiba, Deb <contact fullname="Jen Linkova"/>, <contact fullname="Brian
Cooley and Paul Wouters for their reviews and comments. The authors Carpenter"/>, <contact fullname="Mike Ackermann"/>, <contact
would also like to thank Tim Winters for being the document fullname="Nalini Elkins"/>, <contact fullname="Ed Horley"/>, <contact
shepherd.</t> fullname="Ole Troan"/>, <contact fullname="David Thaler"/>, <contact
fullname="Chongfeng Xie"/>, <contact fullname="Chris Cummings"/>,
<contact fullname="Dale Carder"/>, <contact fullname="Tim Chown"/>,
<contact fullname="Priyanka Sinha"/>, <contact fullname="Aijun Wang"/>,
<contact fullname="Ines Robles"/>, <contact fullname="Magnus
Westerlund"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Deb
Cooley"/>, and <contact fullname="Paul Wouters"/> for their reviews and
comments. The authors would also like to thank <contact fullname="Tim
Winters"/> for being the document shepherd.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source: </rfc>
H4sIAAAAAAAAA9V9a3MbyRHYd/6KCf3hCBvAiaRESkylYvAhHWOKhyL1uFQq
5VoAA2CtxS68D0K4k/Pb0895LJaUZJ8rDqsokcRuz0xPT7+7ZzAY7NVpndkz <!-- [rfced] Terminology and abbreviations:
s39r08VyUpTmMq2mxYMtt+aiyKt0ZsukTuEnk+bmevxwYi7tOiu2K5vX1f5e
MpmU9uHMmHw2mEbP782KaZ6sAPasTOb1ILX1fPBwUqyrwc6zg8Pne3t76bo8 a) FYI, we updated each instance of "SeND" to "SEND" to match
M3XZVPXRs2evnh3tVXWSz5KsyC393e4lpU1grj+v3aTgAfM2yZOFxQnt720W usage in RFC 3971 as well as most usage in recent RFCs.
ZzzL4JkDGrVnPhblpzRfmDdl0az3Pm3gyby2ZW7rwSVOcW+a1GewzHmxVzWT
VVpV8Hq9XcPo11fvXu/tTYsZvH9mGljJy711emb+V11M+6Yqyrq08wp+2q7w b) Should "IPv6" be removed from this abbreviation for a more 1:1 relationship
h/+9t5c09bIoz/bMYM/A17zJMsbGL+nYwiR+SZOCPinKRZKnv9Jcz8xPTbKx between abbreviation and expansion (and to match other uses of "Unique Prefix
qXlnp8u8yIpFait6yq6SNDszn9M1vPwZ3v3zkp4cTovV7hhXsyYpZ+ZDUqWZ Per Host [RFC8273]" in this document)?
zT/9EwM96KtDS7C+Zbi3tv61Y6S/jG/N7fDDMATPQIcreOPPn9Z5N9g32yQ3
b9NqWSYdYD/YMv21AJrMpxHoBbw1rIYreu/PD/xU9wC36fSTOW/KZJGlXTi6 Original:
ym252Jr7aWrzqa3Mra03QEPhaBN5+8+2GgIhARED+ZQrAPBgz/bwyXd3h6en 3.3. Unique IPv6 Prefix per Host (UPPH)
Z/QOful5IyKFI1UvrYHDUNvPtSnm8PTg8Nnhvnt8ltTw9DzJKuv+5kgr+BpE
v+E6zsx5WSSzCZ6Q10XZrPoE/PSUZnV3Pb46PX75yLxGs1lpq8qMsqyYEjLo Perhaps:
oI3gRCxyPGhmXGTpdPv0POukXFg4Ucu6XldnP/642WyGJRAwIurHdTMBCHxC 3.3. Unique Prefix per Host (UPPH)
fwRWUf2IHw1gTt+9TlxL8Le9vcFgYJJJVZfJtOY9ACR3MLiD28ueWZcFHOIi
MylwEzMt0xqmlcGerNbAeHLaFdgkBEO4ScrpMq3ttG5KOyTIDkJTAZGsmgwh c) FYI - For consistency with RFC 9663, we have expanded "DHCP-PD" to "DHCPv6
VDXu7irJt2YFqAQGVQ3NdY1gAEmFSaqqgQ9gyMpOGxgVnitmNjObpS0tPJOZ Prefix Delegation (DHCPv6-PD)" and updated another instance of "DHCP-PD" to
HH6vDOLeZGn+CUa2zB7tjCj+vpku4TN4CHbFrGB5tZlYGNbO5ynSLE2hKlbW "DHCPv6-PD". Please review.
VFObJ2VaADO0w8Wwj1OFhSGUaL6btLQZ7nzOpA5cEzAGU8plNjiHvKh5HvBE
vdwiEIHKm2qS6TSCQWiCAd1KkZgKZdBJhhCA2zaW+TkeCUBPMU2BqGawsDpd
MBFWRdYI34d5ANU0SIzwTJrTUgrE0BK4xtEzc/f6oqKB4W+0tbmFB+vCIFl8
wkEqG4yK73vwKSK9Amaf+WGGTEoFjlCbJIUDVS8Bsn5uYENXgORfASAugZBR
LWHQ28vWQDUiFNAJ1DaBvy6LDW14NKeiTBdpDhgw87JYwWelBU6RII3R7ssZ
RYGGo8lbMJ9VMgNUp6t1ZkszAWTHDwoIwExKHN9Nn8kStmOrK+jGPOzQzK7g
R0BkzVKDMJLCM/AwDLMsqhpxCMiepfM57ABhZwIEwe8jOVcwk9wsbbaGTaFj
IUwHR45Wa9406SwBDoyrg8P2AIrDzACbBYLK4CDikCQhqiatk0lmdSowb5Aw
y4K2fQ16Cs5jXdTwXwpH3G3LkFnGKp3NMru39wfUC8pi1kwRBO36Y8zjt9/+
C9DZ85cnh//4h6nWdprOU0UeSFaQJdWqYvQg80BQfI4OGEeIDNBGQAvBk8bS
oALZxAceDynMHFjRqsmRWVoloMwmJZDoBF41NgE2UMCb5dDc1/AQHWDHwhvk
Tfk8XTR83MzB/c1odNFDMG76RzD9SZNms4pnUcDIgJ5wDQUMWsvsFSBulE1L
BFVsRD2UbcR9+4hkzhTVIlMGs0q2BiRr0aAahkA2ab2EcfsmrYkyaNiH1G7o
XZoQs1L8Hd79jNNbELkUzWIJ2JDTlZaAwbkdTLfTzMI5TUjxo4UzXUb6J59s
EJJw6HFf+jQcbjOeSqC4KegrwkYqIDyQipuKpbsxh0NzczMyl6PLM5IGCACJ
c4U85wa2cXBToEDRDTmAp3u08cAA6Tkn0i6bdcbbrA9fWpQ0tGswQA8oAtfh
WbbSpQNxj3IZToFovrf3wH35w6OhuSNK8zQcTLiy+SyUXfJoBM4NcnAHYA2d
boYEK2UqVhpG8mXhKH+H1YA4nXkYtNUyymgGMOq0Ih0eZn03qnp9Oem4XmYd
eILn6WfPRVkDQMI3TuuCzfSLSoFHwQ7iRrgDfAGnxYJmV5dbv57bi6seMRQ6
qTLlBiYM857a9EGpFyYGQjwnha1MhFAcGHkP2BpKSBkcJmsAvECXicEgJDpW
xSrWMOjLkfXEEgd07/1QmUVWTICYrseOXQKYqk5hoCb/lMMpHDo4dPxqvwfA
EuFfFIN0rmBGG1TbE7MGgQj4RdnoRnJQZEQZjo7mBocT6nXzgH9ERhBxy/K9
MreLBpnpMTD4948doDc8+vucydIdInij52D/9tt/BzZ2/OLlKbAxOsXw/N8b
a1on7z2ePH74+eGrY3gYZ4oyxoEKjtZ9RbOFeQ2JN5BIxdOwxQ1j6b3G9bIe
4FVhFaiEJiSFeVMSlcJxQWHVgFZAS8bRYU6Ch+dDoNLP9WBZrAE6bNUKxb/i
cxfNZ36DEWVufLfBeKbd7vqNm6clLE9HsKjd0exCEsx1IqQ56dkucReLfEDC
ibbpYLNMQfqkVfQ24KaWuYPud03U3QmyHxyJDGz72dYsE49JYvqOaNzJ7AYZ
zwyXG/CajJTz1u6iUvA4EQuldi2KqRfMIVyIrQAoL6QqmnK6w3uI8B0YPQA7
4PiJF0AEIBuBgEuU68kkzZDgAjlw+/6yFxwUsjma3K3KI6/o2OMkZ36J8pdZ
sJxL5SKemfHwmZWJnQxZmGXJFuEIvoRRIcdrQEFDsj/D3UmUX2XuHc8JoneZ
o6Am0NognGFbMNyCYAgXqOMCCDQ3NsFwXp0sjF9zFYr6kAYjIQ8nPc2SEhmx
XddMerUaEjkpq21RimIBDLNk1ld9ztOWubMzsKumdTAKwkQ4rAbOCuITy+QB
TMqRnjeWycHrsBQWdGjNIH6AD5HiO7E1s3Y5D0pk+BBsAsgqtAh57aBFfcVO
7bN1V3ltiywQZ5L2SVv3mivtnoo7ICbmm7yyAu2cFT68EWa1ZTuWsKgiiFlU
JRKoYtKu1GxE8KDwkhavCju8fFHk0xIoPNv2zQMat00VW1rd9gsiGRBmyWL0
NhoioW0+Amnm06whp59oe3/EId4hesxbNNd5oHdgriQwfxFEpy9O/vGPvr5w
j1Yvaa/y8avTw+Dji3K7rotFmayX6HjItuaNzVExhUmNVJf2rx4FrwLIcVl8
3qpMO375Kvj0ZxBOK5Q4Uz/28+dHr2IAuFWrAtgMIMX5i/jhk+cv4GH++fTZ
ycnui6iOzaL3yNsVP/gWyJc3QcC+OH0RTdP5AWRBwHRWlXv45XHw8Ef1T8CT
Bx9TNsHouVMEyj+/fPHM//zq6GXwM6/nenA5JHf0CVDmIF0/nAzwEA/U+xEM
CNI/wvHJqxfh8u6Z46uG8SHJwFKltV6vUH8lxmUUhcch7rt0X7B08TjIUId+
GaeHhyEarvIl2sOzJy0GefPFUTRhIDEykUd3Y/fEy3Brgds0U1R4u5Vzeec0
IkRRt8akoJsxvPUTyiZB+9HpcUwRTJnsZSU6elcmebVOyE9APnlQsHNZBvC4
mwI5ydxx/htyHxy8u7u+uVECeHn8LJzRG6CpJq2JJ+za7vzKq8Pj8CDyNgNe
fhTqvvowvnWPooXf95YHrJlMscufLtDolZVfAvkIwzngTwbjS7KUxJNqBVVu
Kdf+bUsiw1xk6rm7Qf8pe3HF2GN/ms7p5ATwKl6pJxxRwEGRmbHdmwBHtoOq
BiEBg6JnBsj3IFH0ku8lXZFk2aArNF+wYWSTKkWhSp69YWs89ByRD2+GnhXx
gHgHjtg3IWeewYJz95iqr223DQmE0C0k8Mh47nDneD8iYOUPfzDvSPvB6Ma2
A0sEihZs0dbgKZEgCL06QzxZqfAnepKkH7of/QtkzFVMsLwhb0cXZwZ/OEOP
YfJQpDPymjQYU2LNi3UVslCcz6S/ozC5j2hM2rOS/ZiwaTBK8IBOJHZY0km8
VsySN/2ssnDYvsFXV5TsqmNIN8dtOInEB9ABh0ooMgG20omUI7PEmIgfhDQM
0pmVLEunk/VnccK6SYWAeH5gN6YPpFSgP7Y1PjoXJ+RHp3M365wQKgbLBPG5
QiHVd9jowAVqIQCQHRzRZNRfR1i6OYqRdCa+pxWcIFADqtAVmYiti9oV6dv4
ICmrIXxREUkFzLbMGFDBPTIHN0e9J3AXAvHrYdfMZWPV3refQUkgPgDn9C1q
hQNksOaeFr67f89fPUN+3oUr9usKplLvzuzaO/LMA2ux/QhnQL3kH4RVgLm9
jYiuH8JBJhB+uPNiCNSm5B+lDTr+084eJWt4A5EfAaQRgkejVaSoPye5BQkD
g30LAcvK22so4occIY2TktjazmTZBwjkDZMFSbXe0QCBMz2kU9Wx9au0QHYV
DqE2dwW7BCQ3QwPMWUluV5/au4+ATn2E/tQn56yzKJwHK3CL4Ot24eI1MCA9
vwZdpFrBMUWDZ1qskQeSR9vNFzXMbYw1v25eKrJ7UFzIUwxEfJ3j8SrKlGMv
1yQSSCK8dVN8C0R6Qd61MdtpFGDADbmzWap2t74Ko15LKA3exjnumlEoJsEA
h49G8M8d/kTgRuQJBwU7jrYJg1qCcgIEFIXspqBwJRi606gdoITiaxzmQjV1
5qJr/RZMCuPshgEdW+kAajLSNIDSFChF/dqxQFE1tmu2U9oDT9EGshisJGjJ
Cv36uB0uPip2KInpjkFFrSBYYKmBDNOPDFoXm3RWL8kkg4E4zEz2NIe2ULFb
kv3N+gUYVDP//jrYY9Fgj58fqfZ03RH4bK+uhVFUiR7YhmzykigGQ4XMVRPa
VSBomN9ESQmVIFRzJa8EjwBMijUwYmxZsUEfYVInBq0/XkiGsUo086fo3M3s
bKG+kHvRj4+Hh/iA6qmHwAB6ooPoAgYwQZWBDg0aZmTdLDCgndUPgpGjaqJN
wjm0MElvCtPpMIdnGgAB/RfRjtsRHqoBMcI82Goc9bbtEMKoGLsTBd8rjG8T
lZRslpNLo1lN0Bc5Z07lRQKoQ8Q3iPlSaBENfcdj3CC9vvhyZJRbWOB02eEA
9mF7IkuUauyO78AiOTduQ3ZH8x7GmDo6E6PqhwoRlBYzsM3f5xUHWSzxCnNZ
wtFHFKLiVv3gAJ4n6OPZAjaDKM2I1cIFeQzQd5CBYVWzfgiKvjhWfGSBxNPb
69u/Xl7djP7nX8+v3n28urr9693o3hwcowaLMZpeX8PwmIgA303VIHAfc8lh
JASPbqZN4fxAQfAHk6JQrqTonMzSTxbewLAbItBv2S4qh7DsDU6zT/x0wose
rPFswLJ4z1s7pvSKO7RJPlG8ZGWaNXMCRKeEBBlaamMrtrVJx2cajniUnEnj
Szgjjo9AC8bzYKPVML+LXcu0u34Et5rvHOnFGUH6N45zgM7S1xLBuK+b2bYn
pEnmhw57wQL/dvT1wcj6AVY4K1bEVXCbSF9ATEcmTRjhcU6bFcJOqgFQ0oCE
MSqjTKyieZI3E2mk6zR/E8en2FyJpBxRrkbKsqJiH+S5ROiQWmr2AeaFBDsr
wij8OnNOGrVlZ+SksTPiXgHMgMnsvMSmA6yuyfX1YcTlTRkoLmprl/ar/PvE
8+9b0J4vCswcQbeqaEIZqfLe8+a0gQjKqT823weFfNIFZo+F6QOgAWRZWrlc
H/sZ0LtCcMpO4viLOC8wWLopwtUTH8YtXFrYUM7tAvG6VJmyxiQx/Ku4DNC1
C3Q4AIY3YF3Ya4o/S4DpXvOYWuqhS7Ii2oPN786H6rMi6XMg0GiZEFsM0qpg
fSA16xqpI4qrs4LkAsOcjkAqEE+PZLbOUDAROqZFU3j2CjSFNi28PFOX5vXY
He37dVHMcYABSnE3JZxGxM2D2BLwoyBEnVRheEz/CiIcwzbstgk5uZjINYYv
meTJtkK4HNyPpoC5VIHUbXJAvWozLnKC3j+bgzk1KOaDe1uSfXRwWdz3BFib
nF+dyQs4TSTq3bWDgYIK7wyIC35kLuFtbhihTleAB3zZR1Zw3zSbwD0iGHHv
xvk6QdCoMPMkzfpC9AiHTExYhxjzreFbizp8hnJp0VAiQ8eKKGCMH1HWDQJg
gRuG3OKNSVxItnNfWvvh4ET7ApPv3oND0CyJ9lAzkjcenTbIl4Wd7Yywsxb8
vXQBNVILxCxpozCzixReQxYsATkgV5vN27NErQ72H87xiJfRMcVpssZ8UUBE
ls46SF4ywRgMqS+UrME8iVWJwe3F1QCO+CWH0zxXes1BNPJGg54PdhkGdK8+
LxNkZZieQLm7mg82pXyrDgOXs7V0rU+miUj4cdLU3uuyZT2TtG6fbzMI8m3a
eTYIg6K/nJHA9iNigkQCBqWZ6V3fXvz8dnxz9e7KVJjfFiUWEZk5wc3h9vA0
CDdyOvaAZu4lvZy9oU+mCCLzCAA3BVVGFy0fUfqPKOnIwQKVpR/m2zTrmU+Q
5EwGAsL+SuWNqvygA7eueIU4/7ur0cVPo/ObK5VtpZ1sKS0Z5KqyEIt4FQNF
jGHUXVpuYiEgQWtARN0e4056e0zosIBhOfJHORGgQsck+NihZUPZPIDCGjia
0GWgAWFKIcdxcpiKeCrrQLa0eKqDodRRqFsC7EZbkoWLAeqnKMvDcFwW00JI
dlm/JK+qBVseuNxWSTYH5qcpaYDlhyZDM41PXt/l/85wi/ZjhPnE+vYW9f2J
K+3fm5RzMD1umS+LKkCsyjEqZ5XssAxUyvn0yxlPyjJ9wLNYByItzJeQ9U4a
9FtWlFuELi6ch12tmT7DBJRwbyQ1JDg2giCGhu/OcFaV8h72d868rT8D0ZvP
WOcJpvODgjAVqLv9KHGgrbnTFweECAO7p2a/8xx41DkohML9jsMUIh8MtRvx
5TzCisUwoiTVfkvwLiQlQCRWSP8RN3S0MQFTHk26jThx9GC5xJxAPYM5pC5P
kTgKYoPPzYydvX6tHO+USM7zwxdifOkEVJ1Fb1WYt7hr0oEeT9yqdnmwCrzK
i2INCKZUy0dUaAeGyyWqZsKHCWeg1WCwXuAWZBZxHUWw5oMgZ5YjRj0XvuSq
FMnudw445dfRpnkYBYXokJVnmUVLWEzW6XQqVW8CYRBDwAgjYhgzuZ2LT71y
bq/avrK+86QlMzhfKeXiFyWbPE1O5hZQsYXDMMVSpMB5w/gJMAbAXBbfGoMO
0waMJtBn15yKkWAGSao74WcS78jQvAX7qiDPTUGudCWJZeKIiRV+YMB+/yg1
JUiil/x+Mpxd+jkrbXWZ2gfx7syD/Qt3HJNZ8hR9//miz/Z3rUFd9ZgeDU/Y
Z+rtIFa07slSJldtEDYwUj+kqUUEFjOfG6BnAi2AK4B8iFM9Gh73W6Y3QiHr
W5OaxDADebYKCzzWZUpT4Ej3mVdUCGORdcq5WBxj6OBUQ3OFzsBcwrP51of4
KxdJ3xRNNuOQgSRLsTiZFqVkbHsZLzNHGMWkAhtKksxlx8xCqzRQwQuKToJo
Pf56ezlgtYpd0i5eD387OOx1OK1DDYPyNHbcr0FwqPhGp/Sw4x1Q5GNnbOyL
dR7Ym3Te+X7gOZy5MddPj+ll8nf67+jrKwsS5+BjoH8mc/17B/hjFCB7dAO+
z6sUj6rOoQ6w3+dmegQs0dpRr+M4mW6ii6bwpI+k4/m2K6GLWkPDvOvzLku4
67kdW5TXetzrVuq/YbW7ynzXQ4+rll1Pf1UXUqYbVOgBN/WpPqEmnWqyp2ge
sDA4n5TWilASSv0miafuuaE3d6OKO4RQTKdNKeV/XM41RW1TCt77HNIguLOH
tFI5q9VET1TNPSQpJd4RF91qbM3bAGKReMPKpxOFoW3Mp/Tw7xU+I4ymcxim
f2E478npECNgSWcOB4cvdiblhebzobmXxOi4DnOB9fR21gcBt0jzXE6BmLpF
ZWODl1DECRIsVTDVnckwAktyppxR2GeSoKQVXV926yBDY7A9x56kGItdgUCu
MCroGJ/gmesEqTBggmYdnBlN5kpQNxoI+tkPQ8JXCnOp4UHqeyJ4aJwUJrhz
cQb3eR9D45yoPUUfRArCdUoeDyoten1h8LdFwQqIGEwdu2cOKlAUzi/G5pXo
4UfPjk5AdaI8PVyJlBUwFJbYAhoOS0+P+T1YHPfUYaGcVZiCCSfyYFwWqMrO
3Cd9Q70Rgt9V89LmCe4jSc2/ArhXn0HupXhkEikpuIa/XvsqLf3zOfz5HE/r
RVNS/suY/fFitLyHj99zXZM5oFIaBICBTs2+m2zZkr9697q3t/d/4Ave/NMA
v/4k3+2vP7V/aP0vbwOcL3B+4F9A8Reajo+14NcXkjkD+EECA1+QUeIHrzeg
fsHbhRkNvyAc3LvBl3o7YDhh2BPhCNv7wm774RditkPzhY3zL8Aca4ZD+/pl
bc2XYH3t729Yl8wfvw/h+wi+j+H7OXy/gO8T/OwU/3k5ODyiBw+P6YXD5/TO
C/h3B8//wnzenp8/nHwBIvkSCuwRnE6XUzpzKnORPcBv7a/fdT6veT7v/1Pm
8348/skofr6YX4L/9Wf5QTf2F///F/7395wPpt4D3HugTcRJhAhkQzfFZjCm
fBZKoiuqauvTlw9ubm6r3u86n3tMZ/8CrOeLo2vTwpX+s/v/l99/v5hvIH7+
pfl8oRT3XRjx9/+H66LU+v+gdWEmCMA931nL/6P5vLkb3V7u4vmXr87nl3/P
fO5HH65//Nf36wvY1CbgY0/A+eVJOG9+fPOn/yT6wTKlb1tXx/r+DfN5dfLy
5JFz+k34+Z3lRetLDJWht19IaOyIVlbn0DMHfOc+0ODfcsGab3BEzTXUU0d5
JE5bDso0XNOl4zfjsbka3+9HlW59eUB8i/TQhc0ydIeym2TflXJRNRwJt/2r
z7UEIxJpgfHjyXOp6UE4XDyJsYZyprV9ODFM8IZfqmW6xtqjv2FA+gAH7en6
SMOeJ6wMU9j1ZnRL1U9uIkenL0Hzp6zZLINVdmLGHJB+1ROTOI5SOHs0Vs99
/xzzCT5fFylmncJjgSOuqcmj55PeNaWYbTyayfsKlICrvzfpmhy0B++vev24
OmGMoAd1MaAfwAQ5AgxQoouYkNZFntrQfXwEzJtNsh1Szzr79waGyrZh5yiq
wIoTvALnuKmbMte0dCmmjh1qiAeYmFQ4BPW6sCmtQJYrawjCrv6rFYDlaA0G
2yWdy4+465xKK069ROfWQ5K7jg2ag3G+jcdyZQ3zNKs5sMaVzC2EzsDoW1PJ
34hrfWMwrl6gTznPGNlMp5RfwxkV0vCCg6HLpPRpJ9wwLCoPwrMhJToYoNCM
XUBcseAadd11TyCCd4nIrJs6TPWl+gkpaJIEKcSslCroTN6Cea8x+wMevy8p
2HC+emaSyhEO8RNFGYJY5LopKd7DNv59SuEO7t+0U/gWVCSXPpcP09T5BYQg
D3TFFNCnEb857GKIr6kQ95/mh3VnEzpfzsuTVB7TNZg5eK0sps1f6APt64DZ
efMseSjK0KN/ND4zV51c5M5WLBaAI73hQ24O7t4gD2kVOSmVPMU1/JzFGFGY
DsrB+e2b3pD9NrTiympvB8U2HBGJ65MjQpsFBKF/4rZD4jh++5/cXTadHLU6
lsjlWI4xvh33zgisHkePpzdBTE2qZyWSnWuojmtlwrewEBcTIm8wRM/VkuqY
QVz8fPOux4Escovh+F9H8e2boXHNxegLu3NMlxi7I3fNOkuovjjRdUTd1j6g
iIui+j7imM9capwmwMAUKeUhK6afKMg1LzGVmWTuxBLv43Mb5IZNYO8t8DEM
Rgpq1kVZV//VZYLR63E1AXwEksLBID7cYOsySo4KcYG8EIl2gxkMtAG+ssrv
kSb0BJExSUrD53DveWjX+8uVlr6L3cRx0zk8XyivE/Re1668g87gADeQfNdB
C0MKZoYOX3fou3rxTUB9mQPegrxRDMCsZAXd1fI+rnDtyCiaQpAJMyke5MDl
5OnDAxTETHwuJLtuS5uQON7krllSJJNcIVrQGYWIF6sXZGOGVKHrvNNpnMTF
EfF0TY7a1AU/8AlcrSZdJRj898uneDUdap/zLQndbh+N7KXiNFSumMYCf2NE
mf7kRApAq9rORBoOHBys428pORTLdhgjqo5BhL3nXAlq6/gP40njmjqUF+5u
iRkVvkTlm5QXbmXodZhHtZZ2RZDbKN+Yy0e5XYZ0mVafVLPZ1X1auo4j+2/X
bPyW+nc8a+l6m/POiC1WlprQKYSgZyZWuWqDiXbk7l28ZnguUTJwXclCfYZz
fkJlR1CX1H5FGwoTqC4ICAuyC+i8Wvb9xTA6MxOiybL65DFSksR/pHi2H9YQ
+i/l6CJOKl49ci/qCxiLKj/vXUrRRfjj9ZUOUcBHWmQrTCVaoyb47ALpu8Qp
f9QLt44YdHBwmrhojGohOlGY1i0gyCodLrk5hBSRUW1w4ptJ+aY8MQTUlB/S
WZNkvk1P6toissRYE80tXUvMWcA6+UsExLOXlEHGsbUg5SmwqTgtemrjHmP0
5ZEWPi8K7d1oVz//Dt3cfUgR9CjESE9Tt9RYKdc+KEFTD2o7QEkYB+jD79GM
yJvf6mUbi2DfJ8H4fjzS8MOcF5iJzBHSLps9et1nv3H3SyTaqFOCBMm1zzOn
cUbdGTwITNAbjC9xx4E16OHEPJy8BcanbrmURNer06ouTEHKPMis2qOzzHKc
vQqESkrZdn0OJe2VzkHZ5JowSQycsli58xt3bpSsauFiD2kSrsFZ6jofYGUh
8nhNqCrg4I0W/zJZRVjeF25cae1/2EPAarcen3NHod0gbc31odC0PimVr/Zd
LdHHdPA6xQS3K+Qvats+5Z+RhH5ZO2rhrhlG0Oqx3xKR7oR9u9jokhShoisW
vm/GjLl9WF7XLR3c/P8prkm5GGHuLFerznd5Jjm+NAWAOyMoENzzyTbi7nAu
lTOGfTll1XMuCA+aPzjR5aw6ZkRepEkLYDavdhqOaIMNmiBmy3uM+nqVsGcD
EneoUIXYDm0Kb0/t4NUZGHowPIekFZP91plJ5NvB7UV82WGUEnjY1tHkiOgE
hdkQ1M5lX49CGloYTl/SdsqtdjNcW8AdQGxeaas9sX2dXUDVByLgxLnq2yj7
vn9ee6ASFeqtx6vcBzbc1MxvXKo2rpHdUb6pTLOiIlJ3avs8LVzLfsekaEm+
G953Tkp5o2Qoub5FrvkMTWVcpg+oApOpzZvw4sXhaZiJrAXWHTD6HUvsBzaE
MmmcOf6DYLRJL7YASKR5M2bDcpVArU2v712RDnV/dNYPgqBLOyKm3WFjIBUS
FUQEKOXpzHO1aEOzj372mdaRe5hzjNKhBUtD86P65phE1Iu+OWHn/2mv32p+
5uS9EHulb7/gFyIZVwdH1KmeXQ11V4Vr1XRA8GgavaBOn4GsC5BivuEEpkoG
dqe8C7Mm6iX9IVgaQTvxaXCs1IQt9/ABbguENWz4/u/QkA+UK81CIu6DiUg9
1yEsQW/bLOFUIsz7cXwSRoxUcZdzQIT7WNqBBk4OsV0cEjyA0fortsgiTjax
y+Qhxcx61LqjDqUkV3Bgrb3wvUBjqSyswQtmTrlFaCpRqLDSi9vSLjC5rZRy
j6AHWB3JVaFs7ey9AzO03slod13nA2cYF4rk7sYMGb1MOHkjKScpVxeE1Oml
60ZiWE7MBdYnKckdekTl24S64MIwdhpSy7QqNsoe79IrIDqmUCEnlbMZKMvk
+sQTMb7+uWduBhPugfTM221X3v3nsSgBmJYDxBz44oKT4fHwOZ49X9PQc/Pi
jGvvPubsVRZ41N1N4jo0CEwHKVayVZFOAzqIXMuxdYJsFt/znTTwZQRSNWt0
dGrUCQU37itTsfQQGUhwI2jBqgyX9WoRVhPLdsGM+6ST/8snypqC0bsReQIC
uajE4g5kypRvkSDVVXy+3t/GVX8zbebnO1fuZrOPpcMQ23vf8GDU+tJsEqob
bSctOq2IzR3rPgYRPmNL7ejZ4WmfnK5bm2D5zVxOLeVzbjjm4ZrMDl2/CMpj
ndmEimOwGa1pJDLQla5LUWQqbUEzXdOSgztdujJ2K3M8PKETfDxEMZVKi0VD
7QXU4KQWgFZvsokTpfHhS2xHdIFKG6zu4PKi6gW5sK6D06xYwSaCjbSmaENJ
rSxcdy+Q6Nw2n3QC/LXvlER8wCuIceDCVEA+06Vv6F9pz54PaVk3vElvqW0e
HoIPb7FzTcX6hLQJkue5GQ9bSwzUtzdKg36jrOAmJqf7m9DYQoaOOZi+d5F3
wjMkUdCxZi1sfA+ydtwP3RI96VhWa9r1njBxbgHpj1sElzioby+wwwDZ0gX9
A7FDTlDWtQjp1DC5rpwhAduOv6ILKIpZXxOYWUHe1qIf+Jc33OgtIXgyo/Xa
UrhLw98SuAGIe4FR4YwT2f4Rd8Xou21lJufKzOn2EQ6mR2BcknoLVS46UdpV
Uftt5fiLoFeDslFTO0evcbYA28GhH4nGJkaQ/upK8hz5UJ/wRU71gvg+dhVo
pnjIRzs7KCsiALt0oRXm0gcyWo5uIdEOggGuzzjRloNprd0omEbmDYd1dmWl
0gmxExwrRCddp4OuhuuxbzYprr0FVu+5FTo/nG/F1TFY1F6cpXhwfN5TExcO
lPY5OsXqJ7rGtB4RvQsB0e845R6LqPYNpYPOiyk7+nKeOJmPXnvpnCtimz05
LIxarQErEi2qXiOUHRYIUwEuySILZ0HB5q6Wx5jZSbj46lNRh+NAW1ZVmbUm
H4fm5QcN4l5gRNu1sdNiFeq8RGEWMQ/IUpvz27JpPL7NH9KyyH2HgBvcPHyu
b+ifp6ffsRGxk6DDEcEiN+XbAbzeI3VtocZz2GNkR+2bYfpqcKuwcGavNwgw
C5U9sjsvY34qnvDAfx21gt7dBueO6xCiF9U3SMxIJnYJza9LTFnKA9UiXWEh
8cH4quc8QpzFdKU+p7bcw0WTUGrgj5konuMrpAk3CRZ0VcCNO87+7cizdPKe
77A8xrfjZehJTHG9OLkafSpwBtcJB+rEFeFekYe9hMGX1Pl1TiVDLlXE6XsH
52/GPV8OBKsiySqrCRjhD50LkrtgmDkjFBHXeNVFLo5Q6k6hQZf2ClWCtSCw
0BlfsahgHu6Zb4d8cjz3ayfId5Z5VFC1j3LnISA0/ROsVFrXPNlMnrtUBplZ
5O3X3u8PFJ0VhxbLOu1aa7TwTpz8pGVrQ8W4PWLcy1tMb/FXc+he7OXQ88ZB
kFoTI5Mqs3YNgKvambT0ajzURpu8tl6kTl7ovqsq1Cq92MSX2F+5uz2qHUoH
RLrODN+RtEqhv7CPIdB4VyEVVWX5q+kS7zThTkgwFk7EeydC43lJ9eFSCk5d
ae5Zj1Qnw93IHATt1CLvhGRwhEgCYRV1NqhcIa2/zsrB8MxXdb2O4CD2VcGm
SqKqbLD/UdxCO3Cjc9cUIhnO77obdfoMdNmEHBw4XAPoTnQmp9vAiy1b0JZU
R12S6um7CQ4o95/FEv0Y3VbQIf7Ve8WHto6ygzAHye/siCNpfK9MGA5Bhi1m
vE9rwPt0wpZ8fm9ZJXXZkz7d04WRtJUTAQnv/aIJkCqF5yxseOTA378b3VwF
NbquKU10hRpfZiZ9atoxLCM2NsIgtky3/yFcmkzQ1QrreVfU/J2KyA+kjzb3
opCtQyinw6PhEatRJJ/wXmE6T9E1TSBEK80FDy5lkoaDfKRR3kdeRPuIb8tn
IRJREy3QgiSBQQtHu+uuOT6RBg26OB3JnY3OMI56xV9TKWmCkZd2OzHv5Ccp
huZgLh6ab7oM5QBrSXpB24quK1DYkQMPRnengCIRhrs5a5dcN4HVmVAyHwUp
MN5A3I/NMa54/xvlxU2zJF1FFjOlAPpoZlhBHPjApPOZRmywJp/rTz0HQ3so
aIUY9tTqvO3l4G40oJ+c63zn4hdWouK1k/mccM6Fy4CSxUsILUoLCzXFyK3n
rhkO8SALbHX7I2Ef5HzRDnGTc15CVOWt97G1mlGKZvD6wlDVzKUFOkFWRXd/
xqQWNjEI7wPaQcYMgFTeLdsCw82xeHhCpefJx3ymS/SCr4gvIu48y+TbidD/
z0LBcSlM63lNKWlw0Ml5p0sHlX7qzXN/Y2kRty2mLy8vxDijpDYAFrYoBXV3
seD0/fAmOfoiTkuR23BiLimTOokPKHGIL6Fw97lSt3rXmTIGGrRVD26ruBi/
50YLoMKWW9cTrQqSbWMwKM/A7MlWQWbzB8DxI9gE+6zAK2d+5S4x43AaXNou
jJxiB3TtKK++Pa7InA6yCbqoixK4T61YtVJe3NZsIP3wKWvwwR/cfWeyR0EW
ngSksGUSOQ84p2N/GA+75qscOLcyaOfruXeLYKUV9rVrT2v7QUzqQXA4Tdax
TcCYWVOoVWRzuIFTbMXIIlFHclcp8sWJibQ9DueYyAUrMFooZoNQwCdUjp0Z
5DMhXK+qxAfbpbuiTxX0Q2msQBqRUUoaB/L1ULTuPSL7ggNlJN9tNh8s3N1p
4UX2eEVicF2TtmaAR54/2kmLnWrSc6qjbZrzolEqMMA12BNJKp4pwlyLU62j
NdlQhj9R0pIkJhL3Ep7hWC7o+jG7Cqgaq/w6VUIfPJX7r6m8jlgm6yaCB5SN
PGmRGKRaIRlId3eOOMSIxTXhjcBTpWh3G/TM76ao45ZakVWP4Zi1vrCzV+sO
abl7SiNxEb6xqIUmP9zBiGsilsQhYu0/s4NSICV/p9qIQ9vhH6LL1DoQHkTm
6HFs09uUvrin1VGmSuuGL3TBniBFsaYeJyiinE5NYDaiZSE4BsEPD+KHo4Qk
VUAJYQrAGz02bEjMg9LtjGgeEUAU+eR0q6LKBQkewQkXseDGo9bxQflbVCpD
V1biHYqiPdxSbziJDob3IeLyaKPD6akQba9LmI/0UffPhNgJ4dDtXMABQT/X
Hr47O9zSk7GWRL3NpCJYKvMkMwsWxZlJUn+EAkf9fWfdW0QgqMckdvLBmwws
JQtlLu9aOrvCMasqV+Pl704k8h1zSSgOTs0v5+4qqA/j20qv91y5l7o9mHwB
Y4cHU3oibehUku61JCXiIi2nDdpqB6OLqveI9zBpO1o5bI1cwTXc/jD+eO9v
l6C4KUDkvKl5kNpBKzAHlOdPXmlOwXQuXeef0cyiyrymup87NH34hg+Cjq5B
dNu4QB/tG2dbUNM6j6tKJqk0l5gLeBG0A/WkXlz1lO60tqMdMRJjQGI4Fpvw
RSh3bhiOxqNNYuLcu2jPHUn6ZsHfQpQkU1pEqajuQHPnVsJGEVt9imq7SdbX
dF9qix4yNDj2hmZrDVpgya39KQnbBVQz/vQh+tSLR1YJdulZrHXJanEOP8rv
uecCikcbYeG1IsEtsDxVL0/Ub/hOPXoOE61b/55Ayh/cDbAdzp57q74eRIDm
XmAUxrYujO0M/FCOoE9zdH7l6Hpeum83vFiAYGsdKCfFk85M7gVRgfuGc9++
7Xrag4s37mp1vqSW7azWjPFarJE0Eh1ggtSUoFdbbIPJfOFdCky7TlbrH0lU
iO5tkgb0mFJjSzN/z6bLulJzoR/6A1x20h6bNehAVRuoLw4BcjDzpUrqYWqq
wCbADQUGlNda/0UW5qW71ko2+TsQ1bXf8HfZT1duh+1kQ6DaC/eT5QwkQU10
bYZ4AGmH3QTjfDQZRhU6XZFrNmCutQ9DCXb29WWPPRrxONKKvOGkXOKL0VRB
h1wqO/TTlhCUb6wdz539FFxknCBG5Pm4G+la4nhEP3rRwMRyBg1rlOjE9JY3
iX6nOjrHDj6IWAd8Nyufdxy0/ScVytcvkEd/giYKOeYlHapYTdKo4ZoBnDEw
7q6KIVdpf4v+QbQ3CTuultFFDl0Tb86KQJPqMybkEUCKTAMxF7k2aW3NVMon
GvFQ1iHAtPKdicmbMyvo7hRktTIdwDs2/lWHp2sJDBKqLjH9dIUuiRUr/h6a
x6O0D1bmFSeglxb9SnYW5IjJudFLrFX87d5obQ7CzCzQP9BzR4yPwkAuKkq9
GRDK3wptDcdXBY6DqwKdnKSMNcldcZcuGl83EbzpSkn4j5JHoR4334WAmhQ4
X0TK6rem/WAUQdRRJaH9CYDZx/St4CZZS9e4OyjY14AOVQ9fWxR86YfXKudR
/u+EG1/Kx1G1sV/OI7NC1gMfsEbF176anwC0h8LvrGyCHpIpH/1KIzremQQW
YroQD7U7dsGdFzwLUcR9oH93jkHF0O6VGXH0CCMK/FuUwVNEUH8I0lZ3cCnG
PV6tEd7nQH4fudkwj/xv7O4Qy2MXHnUKJ4d8th1GpPU4Xa0xzKt0gyc/RG8b
AVRkEnhTBKM8Zb57wjlDea4UanFgtNUFTaJFVufacJOUVA7RpN7l+ghhqUnm
Wv4rhXdgJ2qtwSlL/miJIekAa0rA51TcZh2eS7K3tKaYwai5OIx5C0ZUQPfH
An5NHgoTZirKmOl3JbQQo6aclvDhEzFpOuPn4YOnPeF5DLfCxurqbYj/pPzv
eStBXjW/ytpPRN7oTsFb1EKvVHx9kFyl4K5rpYYH8yaj3hZsirk4MChTZbNW
EQDEN8ck8Mq7ojTAyO4NAhGc4NYaMimukey7IMymvgPQOllrXgX+81beulfJ
EaZq19SFHeQ2Vx/D+Oou4RVSzHhLHYHEwRngB5v9VMyEKazhrlrbWUHoR7K1
Zl14J3q4ATgISGg4tcM2mFUxY5NFQpLCHzPjVPyj52rCiKnj/oyX2qtQ956V
DXe2Z7MW2AwI18TV9tfelFKPk7SrdfeEPmUyubRxV3jl324tjFzywy76fcKb
EjjfeuIWYRfVN9mY5k2DZ5fcm/j5WPpnsPo1Dm6DDxv4n2/pcgWtVQ8vjQ+v
pQ86XXhrkRRKNRgfdRdjkpQGKEir9YpOpWWVCZoAlAomwZ3Hmk/XVPbhLuPF
u09QDlSFJl/z+4UMwmK8y7wNai+GYI/jwxIu4cH9kzh+TZdnpitmC0Gevov1
hIHDPdZxUEUMe2Fj/2FhuN2YwgdycSKCZCn1Gq7HsOby5RFRg6CRsy/mwGRk
m60JtEALAPE1ie52CsrOIcMBl+swRBoNw9KASUgmzpUrno4bm5T+agB/abhT
eK5c3kHUpJtugg6v2423ABDFoSLNs260O3afjSNu4/yrUPKKT/wcdgeZN4wH
SgP14674Zmn45kuxsAKjBDFCPCO4v+HM7Mcly/u0o7lvHmJo5+zCeSqV0vgy
h66LHKhYj+5gON69RZ2tHUorxqfEPVxxMjA9LvnAaoLgiy7nsTYTLH+/OdbI
CcAOmgr5WIGkrlOKCZes0X3KqOm7SiNXo9dV5xpk16FfouvqDQIStCKjwKCt
wrFl+jOXcy5Xqa4o9l5hSbCPqkvUCX8Oq0DFxnBd0BFuVMPfdynZWir1SHYH
p6+5DJJZlAjAm4Vgwv1ypyHKvw73+Yj2+esb3Gp7QBngT7Y66IeGaEgFRPSu
55sUTItX2B3ajC5/evD8bqU1RhSyiApYJVzl+lZom5iAMvj4KXE8Xn9OFf9x
ik7YGqXzVql9vlPG1qBXxensx8PjENXHZ9Q2ElnSU2fK5ig2SdwECPedBG4v
+5Lz2VJyKdikiduhVus1Wr3AxsNFBp2IcchGNiGcjH6QHFRY74owJhZOBuZd
9aP2RMJ+iKu56jPx2heetXl8SwL1UBiqz4jm+mNpdEAExIfRb7zvfpKWSkUs
UWgo5x0Py481XzsogTDVFA583EdEmSEqhu4iGzq3Qax7p+Ce9/b5GUbHBtcO
E63bHajgG6Vx61iVdiXps35LuOadu1Q6NU51cc/rd/dS3tEz71eGKiiWNtlk
xkQybShpKLjox4U32feId0dVvloqgalvK7JZV1z254r9CZnkZJLiOd8/I7rn
ndScorQRu+ar4uW8ahooeQwzFwSDnW1SpLS+2DWe3Jhwwm31NEYb3HcqfhVk
W5AUnUvuFCf6NNQZgj3t1ERGLiVxzOCbeQFFrzqug4pobegPPd4IXVZoI+KK
BCXiDt3dSqlN4boPXyv+QVQSz/jfUu5AxSbrzvM3x3/aYUHnYXu4wrQ6IMZl
qjLNkAn4XWSnoq8O5YSsw2HE9ai/65kZiX3tNgDUOlLj2jIDXpbL8rSDDAwO
ShG7EFAls5XeJzFFLpRr+gRdJO+LW6VVZitNstbuRNiJUl4M2wUjIS5BIG0H
GwwE1f0gjBm1ZOB3GVbYnsHoreScR0K3yRBejoatJgQj14hHcSSVJz5ViBUH
W7kGKIqUvm+Q5xsEGckMBpxppw05aShzuHI44/t3Eu5TFUatsRnma/X3UH0k
RnYwkQyvn+NrCTGTh2wNd60I5/ZgkOzu+o7ppZhgpYA2/fzx6JW2/wg6D/32
2931+Or0+CX3lULlwZnxx6ArwnLxsR9PnjMUh4hB0OKHU3JzUnmBQRKuQwoI
7hLiLddbxNtGc99JXVFvXYK1b/hmfY8tmV0VZPq/v9Lru7lLtdeQQ2AvTnaB
LYEvlBhIQGABYGmOdvem8s0e+yFb9qQ8t0nYT6IOlSSmveMhE+9U7hJmAygm
Rw0oCfdQmtxtodfRPo8NU395e1QgYTgYNN22+hhOgmaFQVdxPtvYUEGIOaSA
wPGRYFqn1ACzwIxuhpQD6veWwUyL4lNKZgHVZa1W3CO0amnZ8VLTGDUMyV9l
9QnFEYzhW23JTdtTyrRgf5MhJZ33QMsnah2Q1GyuDMVCaG4hx1v3XPtGmHtp
DEBtNI53OOw7n1xPTFb7CGCCdfC0UyO0Q2Ok3Ov5byXxwV9eYMnsDfGnW18b
w+O5qGRFN15PMIqOvbJlZuLcCzhuSvroLL6UtKlq4Tu1BFbVeOA5ZcWCD2/o
ntYsRsqDsTNhenFn4IT5KkPxzDX1s1b2yi2+4/7SvPwTtw0Ukjov6joDjjr9
JGv0/euiZrDf0/TQ0UR4Tat2/oiqXCdudBSY6EIYRB0XW5eonSJCyNaolU2Q
9ECnyICDCL6HqaQBVbIu9zvrTyVSaVSMGy836IHTOnjBEJekpptb6iZEWQWu
HQ17UnU7xNMtnfs61ZundBtD5S5PaDfIA5w60/eZ6dzFKQ1u0SvmcZ96vTUx
MHW6LpPsd77EBU7+IsSNtudxF+dGzV/w1Z9bWfphb9rKBtaF9rGmu5fVlJ6C
FQ0syJbk+tUMKAUR2djt6wWlnj5qlRUkefW90y+yq2CpARxjWshCxOd2kaWL
lPSj1pCssIuMcKq6yug0d9kFHmGgmccDxkUNU0xTKSVnnHs/u2o+H1O+DRo8
hTrsbg8CVPKYlfEsfbwOSVSvqMMAlikpPAood6cS77z+xPfSa9BmG24I37y3
dtpKq1shD7yjfT964y2IkKPhoVPOH1NCVUn9irRRfaKbG6rI+l5t47ED/qgf
Zfeg33HBbMBn3jFPPAsOi983NSYD5xA/3o/vV+5opxS2OJxgbQHorRq0EC8m
eSlczkPkpMAv9Yu09jBYzO4mdKHizBnukRB1hSVJ51s+QhVw6Cf8TV9zNmk+
j0w2OB1SShkHg0baM7rDiMWdDa+RTCKCcN4JsRVcMsYa4+N6Ma4k+z0eBYoj
4EGgJnLCoDu+debCGI9YLV6hoUNLajdwJ2ROvnsMerB27ynl3R9p6+yFYklS
v6LrStszcaFiqqTfI36nF21GCAmwATNbqBfIBUDEo6Op4zqKBCg3FpTbKqDL
e3UA7U6Im1izGyP2/3BodBVc4EAObmo3ZUl9wc6JlPwQJvr5fAycRdeQ1Ntm
bjedr+8Min5my6ldXiFo8pY/4x37FVJK2GfdreVE4YBGqFLzFfYsc9Hfpm6w
KcUb5nFzzN3zSx365/6NlG88WMuFpO3hU+6Ui1frBpfraHUByJTAsc3asQvq
dt7GGjc+26QVRxmC9brEyJUsiN2/gkJXUU9fWGekzDA2s8WRg8W4mB/nHCP3
oPxInlLHkeP2ObCSVE5poaluBf+GNMrOXwlmc+IiN2Znb9lUpfc0vKL8YlkU
cvc5d5DaKuSdSaAmLrQVCepOBkN+ZQtC4FHKdu+7QKLXblwX0LYS0g9ivQ6A
uhPwwtcoFqxV1mt3//Jwd91mf9N9tPbZurVU2Ud5RbMwLE1fyO5ld9uZ27Wd
LknaV1FroHxLgVK+RsXBaflKsZkKb7W/1sWnojrJJcqh79KnKrNzVVIewr0q
gBfCTZPQVx/cgMNJlKW7wplvs40TD3x+Acc80LUvLJYGoTwJR4Ygz8uCEnZw
4ZTor++365XTztfold2qXHM9uh19fT3LRFI6OQ0S9gHfAwCDwYDSsBCUGfla
S6bM387YQLaz/7Y/BzZt9//hgwOU3l1JxixFBklOJKBpX5Ug2z5s8+knWM+b
Bk1r84HkrPlgsxlbQjew2vzXAiYPJFmnfXzrk/kLCr2++ZhgSwzzlwZvSumb
t8UywYSj86KZJrMkLQFsUZbEzl/Dr8umxLbY4wTbPcH0Gpg0/P4/kF+D6l88
JH1zDoI4NxdJuabeeAAU5kxCF/NtwUKDQ3WLhc2pucpAI4djdDUDs7jMLJzI
nzO8IqNI4KHLBNQNTKHKxE6HM5Qv5hY2/5cU5n6xBNPKXDQrTHWq8Hl49wIv
tIFB36UrfH6TY/OWdAvYItfofZovYY6j9G9NDovHKzOuUUW6w5gMwHibLHLg
XR8tlk5mDWoe54Cirbmx6QRevLQT1h6LDMseUC9Lmsx8lBi1ZMmnpRB1JTfz
rFi2hhtK8TfaU5LL8cbi7D+muYPJ9/XgqVRSI51raddAzyBD/y8igndxr7wA
AA==
d) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Media Access Control (MAC)
DHCPv6 Prefix Delegation (DHCPv6-PD)
--> -->
</rfc> <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether "native" should be updated in the text
below:
The switches are interconnected by a native or overlay L2 network.
-->
 End of changes. 113 change blocks. 
2079 lines changed or deleted 1396 lines changed or added

This html diff was produced by rfcdiff 1.48.