<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-v6ops-nd-considerations-14" number="9898" updates="" obsoletes="" consensus="true" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2025-11-20T15:49:20" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-considerations-14" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9898" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ND Considerations">Neighbor Discovery Considerations in IPv6 Deployments</title>
    <seriesInfo name="RFC" value="9898" stream="IETF"/>
    <author fullname="XiPeng Xiao">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <email>xipengxiao@huawei.com</email>
      </address>
    </author>
    <author fullname="Eduard Vasilenko">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <email>vasilenko.eduard@huawei.com</email>
      </address>
    </author>
    <author fullname="Eduard Metz">
      <organization showOnFrontPage="true">KPN N.V.</organization>
      <address>
        <email>eduard.metz@kpn.com</email>
      </address>
    </author>
    <author fullname="Gyan Mishra">
      <organization showOnFrontPage="true">Verizon Inc.</organization>
      <address>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>
    <author fullname="Nick Buraglio">
      <organization showOnFrontPage="true">Energy Sciences Network</organization>
      <address>
        <email>buraglio@es.net</email>
      </address>
    </author>
    <date month="11" year="2025"/>
    <area>OPS</area>
    <workgroup>v6ops</workgroup>
    <keyword>ND</keyword>
    <keyword>NDP</keyword>
    <keyword>SLACC</keyword>
    <keyword>DHCPv6-PD</keyword>
    <keyword>host isolation</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The Neighbor Discovery (ND) protocol is a critical component of the
   IPv6 architecture. The protocol uses multicast in many messages. It
   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
   multicast in wireless networks) or when nodes are not trustworthy
   (e.g., public access networks). These security and operational
   issues and the associated mitigation solutions are documented in
   more than twenty RFCs. There is a need to track these issues and
   solutions in a single document.</t>
      <t indent="0" pn="section-abstract-2">To that aim, this document summarizes the published ND issues and
   then describes how all these issues originate from three causes.
   Addressing the issues is made simpler by addressing the causes. This
   document also analyzes the mitigation solutions and demonstrates
   that isolating hosts into different subnets and links can help to
   address the three causes. Guidance is provided for selecting a
   suitable isolation method to prevent potential ND issues.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9898" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-review-of-inventoried-nd-is">Review of Inventoried ND Issues</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multicast-may-cause-perform">Multicast May Cause Performance and Reliability Issues</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-trusting-all-nodes-may-caus">Trusting-All-Nodes May Cause On-Link Security Issues</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-router-nce-on-demand-may-ca">Router-NCE-on-Demand May Cause Forwarding Delay, NCE Exhaustion, and Address Accountability Issues</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.4">
                <t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-summary-of-nd-issues">Summary of ND Issues</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-review-of-nd-mitigation-sol">Review of ND Mitigation Solutions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mobile-broadband-ipv6-mbbv6">Mobile Broadband IPv6 (MBBv6)</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fixed-broadband-ipv6-fbbv6">Fixed Broadband IPv6 (FBBv6)</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unique-prefix-per-host-upph">Unique Prefix per Host (UPPH)</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wireless-nd-wind">Wireless ND (WiND)</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scalable-address-resolution">Scalable Address Resolution Protocol (SARP)</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nd-optimization-for-trill">ND Optimization for TRILL</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.7">
                <t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-proxy-nd-in-ethernet-virtua">Proxy ND in Ethernet Virtual Private Networks (ND EVPN)</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.8">
                <t indent="0" pn="section-toc.1-1.3.2.8.1"><xref derivedContent="3.8" format="counter" sectionFormat="of" target="section-3.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reducing-router-advertiseme">Reducing Router Advertisements per RFC 7772</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.9">
                <t indent="0" pn="section-toc.1-1.3.2.9.1"><xref derivedContent="3.9" format="counter" sectionFormat="of" target="section-3.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gratuitous-neighbor-discove">Gratuitous Neighbor Discovery (GRAND)</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.10">
                <t indent="0" pn="section-toc.1-1.3.2.10.1"><xref derivedContent="3.10" format="counter" sectionFormat="of" target="section-3.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-source-address-validation-i">Source Address Validation Improvement (SAVI) and Router
        Advertisement Guard (RA-Guard)</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.11">
                <t indent="0" pn="section-toc.1-1.3.2.11.1"><xref derivedContent="3.11" format="counter" sectionFormat="of" target="section-3.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-dealing-with-nce-exhaustion">Dealing with NCE Exhaustion Attacks per RFC 6583</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.12">
                <t indent="0" pn="section-toc.1-1.3.2.12.1"><xref derivedContent="3.12" format="counter" sectionFormat="of" target="section-3.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-registering-self-generated-">Registering Self-Generated IPv6 Addresses Using DHCPv6 per RFC 9686</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.13">
                <t indent="0" pn="section-toc.1-1.3.2.13.1"><xref derivedContent="3.13" format="counter" sectionFormat="of" target="section-3.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-enhanced-dad">Enhanced DAD</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.14">
                <t indent="0" pn="section-toc.1-1.3.2.14.1"><xref derivedContent="3.14" format="counter" sectionFormat="of" target="section-3.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-nd-mediation-for-ip-interwo">ND Mediation for IP Interworking of Layer 2 VPNs</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.15">
                <t indent="0" pn="section-toc.1-1.3.2.15.1"><xref derivedContent="3.15" format="counter" sectionFormat="of" target="section-3.15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-nd-solutions-defined-before">ND Solutions Defined Before the Latest Versions of ND</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.15.2">
                  <li pn="section-toc.1-1.3.2.15.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.15.2.1.1"><xref derivedContent="3.15.1" format="counter" sectionFormat="of" target="section-3.15.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-secure-neighbor-discovery-s">Secure Neighbor Discovery (SEND)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.15.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.15.2.2.1"><xref derivedContent="3.15.2" format="counter" sectionFormat="of" target="section-3.15.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cryptographically-generated">Cryptographically Generated Addresses (CGA)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.15.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.15.2.3.1"><xref derivedContent="3.15.3" format="counter" sectionFormat="of" target="section-3.15.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nd-proxy">ND Proxy</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.15.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.15.2.4.1"><xref derivedContent="3.15.4" format="counter" sectionFormat="of" target="section-3.15.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-optimistic-dad">Optimistic DAD</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidelines-for-prevention-o">Guidelines for Prevention of Potential ND Issues</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-learning-host-isolation-fro">Learning Host Isolation from the Existing Solutions</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability-of-various-is">Applicability of Various Isolation Methods</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability-of-l3l2-isola">Applicability of L3+L2 Isolation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability-of-l3-isolati">Applicability of L3 Isolation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability-of-partial-l2">Applicability of Partial L2 Isolation</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidelines-for-applying-iso">Guidelines for Applying Isolation Methods</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Neighbor Discovery (ND) <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/> specifies the mechanisms that IPv6
   nodes (hosts and routers) on the same link use to communicate and
   learn about each other. Stateless Address Autoconfiguration (SLAAC)
   <xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/> builds on those ND mechanisms to let nodes configure their
   own IPv6 addresses. When analyzing the issues nodes may encounter
   with ND, it helps to view the ND messages they exchange throughout
   their life cycle, taking SLAAC into consideration.</t>
      <t indent="0" pn="section-1-2">For a host, the overall procedure is as follows:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-3">
  <li pn="section-1-3.1" derivedCounter="1.">LLA DAD: The host forms a Link-Local Address (LLA) and performs
  Duplicate Address Detection (DAD) using multicast Neighbor Solicitations
  (NSs).</li>
        <li pn="section-1-3.2" derivedCounter="2.">Router discovery: The host sends multicast Router Solicitations (RSs) to
  discover a router on the link. The router responds with Router
  Advertisements (RAs), providing subnet prefixes and other information. The
  host installs a Neighbor Cache Entry (NCE) for that router upon receiving
  the RAs. In contrast, the router cannot install an NCE for the host at this
  moment of the exchange because the host's global IP address is still
  unknown.  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
  the host.</li>
        <li pn="section-1-3.3" derivedCounter="3.">GUA DAD: The host forms a Global Unicast Address (GUA) <xref target="RFC3587" format="default" sectionFormat="of" derivedContent="RFC3587"/> or a Unique Local Address (ULA) <xref target="RFC4193" format="default" sectionFormat="of" derivedContent="RFC4193"/>
  and uses multicast NSs for DAD. For simplicity of description, this document
  will not further distinguish GUA and ULA.</li>
        <li pn="section-1-3.4" derivedCounter="4.">Next-hop determination and address resolution: When the host needs to
  send a packet, it will first determine whether the next hop is a router or
  an on-link host (which is the destination). If the next hop is a router, the
  host already has the NCE for that router. If the next hop is an on-link
  host, it will use multicast NSs to perform address resolution for the
  destination host. As a result, the source host installs an NCE for the
  destination host.</li>
        <li pn="section-1-3.5" derivedCounter="5.">Node Unreachability Detection (NUD): The host uses unicast NSs to
  determine whether another node with an NCE is still reachable.</li>
        <li pn="section-1-3.6" derivedCounter="6.">Link-layer address change announcement: If a host's link-layer address
  changes, it may use multicast Neighbor Advertisements (NAs) to announce its new
  link-layer address to other nodes.</li>
      </ol>
      <t indent="0" pn="section-1-4">For a router, the procedure is similar except that there is no
   router discovery. Instead, routers perform a Redirect procedure that
   hosts do not have. A router sends a Redirect to inform a node of a
   better next hop for the node's traffic.</t>
      <t indent="0" pn="section-1-5">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.  These may lead to issues.
   Concretely, various ND issues and mitigation solutions have been
   published in more than 20 RFCs, including:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-6">
        <li pn="section-1-6.1">"IPv6 Neighbor Discovery (ND) Trust Models and Threats" <xref target="RFC3756" format="default" sectionFormat="of" derivedContent="RFC3756"/></li>
        <li pn="section-1-6.2">"SEcure Neighbor Discovery (SEND)" <xref target="RFC3971" format="default" sectionFormat="of" derivedContent="RFC3971"/></li>
        <li pn="section-1-6.3">"Cryptographically Generated Addresses (CGA)" <xref target="RFC3972" format="default" sectionFormat="of" derivedContent="RFC3972"/></li>
        <li pn="section-1-6.4">"Neighbor Discovery Proxies (ND Proxy)" <xref target="RFC4389" format="default" sectionFormat="of" derivedContent="RFC4389"/></li>
        <li pn="section-1-6.5">"Optimistic Duplicate Address Detection (DAD) for IPv6" <xref target="RFC4429" format="default" sectionFormat="of" derivedContent="RFC4429"/></li>
        <li pn="section-1-6.6">"IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)" <xref target="RFC6459" format="default" sectionFormat="of" derivedContent="RFC6459"/></li>
        <li pn="section-1-6.7">"IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" <xref target="RFC7066" format="default" sectionFormat="of" derivedContent="RFC7066"/></li>
        <li pn="section-1-6.8">"IPv6 in the context of TR-101" <xref target="TR177" format="default" sectionFormat="of" derivedContent="TR177"/></li>
        <li pn="section-1-6.9">"Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs" <xref target="RFC6575" format="default" sectionFormat="of" derivedContent="RFC6575"/></li>
        <li pn="section-1-6.10">"Operational Neighbor Discovery Problems" <xref target="RFC6583" format="default" sectionFormat="of" derivedContent="RFC6583"/></li>
        <li pn="section-1-6.11">"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" <xref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/></li>
        <li pn="section-1-6.12">"Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/></li>
        <li pn="section-1-6.13">"Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" <xref target="RFC8928" format="default" sectionFormat="of" derivedContent="RFC8928"/></li>
        <li pn="section-1-6.14">"IPv6 Backbone Router" <xref target="RFC8929" format="default" sectionFormat="of" derivedContent="RFC8929"/></li>
        <li pn="section-1-6.15">"Architecture and Framework for IPv6 over Non-Broadcast Access" <xref target="I-D.ietf-6man-ipv6-over-wireless" format="default" sectionFormat="of" derivedContent="SND"/></li>
        <li pn="section-1-6.16">"Duplicate Address Detection Proxy" <xref target="RFC6957" format="default" sectionFormat="of" derivedContent="RFC6957"/></li>
        <li pn="section-1-6.17">"Source Address Validation Improvement (SAVI) Framework" <xref target="RFC7039" format="default" sectionFormat="of" derivedContent="RFC7039"/></li>
        <li pn="section-1-6.18">"IPv6 Router Advertisement Guard" <xref target="RFC6105" format="default" sectionFormat="of" derivedContent="RFC6105"/></li>
        <li pn="section-1-6.19">"Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)" <xref target="RFC7113" format="default" sectionFormat="of" derivedContent="RFC7113"/></li>
        <li pn="section-1-6.20">"Enhanced Duplicate Address Detection" <xref target="RFC7527" format="default" sectionFormat="of" derivedContent="RFC7527"/></li>
        <li pn="section-1-6.21">"The Scalable Address Resolution Protocol (SARP) for Large Data Centers" <xref target="RFC7586" format="default" sectionFormat="of" derivedContent="RFC7586"/></li>
        <li pn="section-1-6.22">"Reducing Energy Consumption of Router Advertisements" <xref target="RFC7772" format="default" sectionFormat="of" derivedContent="RFC7772"/></li>
        <li pn="section-1-6.23">"Unique IPv6 Prefix per Host" <xref target="RFC8273" format="default" sectionFormat="of" derivedContent="RFC8273"/></li>
        <li pn="section-1-6.24">"Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization" <xref target="RFC8302" format="default" sectionFormat="of" derivedContent="RFC8302"/></li>
        <li pn="section-1-6.25">"Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers" <xref target="RFC9131" format="default" sectionFormat="of" derivedContent="RFC9131"/></li>
        <li pn="section-1-6.26">"Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks" <xref target="RFC9161" format="default" sectionFormat="of" derivedContent="RFC9161"/></li>
        <li pn="section-1-6.27">"Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks" <xref target="RFC9663" format="default" sectionFormat="of" derivedContent="RFC9663"/></li>
      </ul>
      <t indent="0" pn="section-1-7">This document summarizes these RFCs into a one-stop reference (as of
   the time of writing) for easier access. This document also
   identifies three causes of the issues and defines three host
   isolation methods to address the causes and prevent potential ND
   issues.</t>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.1-1">This document uses the terms defined in <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/>. Additional terms are defined in this section.</t>
        <dl spacing="normal" newline="false" indent="3" pn="section-1.1-2">
          <dt pn="section-1.1-2.1">MAC:</dt>
          <dd pn="section-1.1-2.2">
            <t indent="0" pn="section-1.1-2.2.1">Media Access Control. To avoid confusion with link-local addresses, link-layer
          addresses are referred to as "MAC addresses" in this document.</t>
          </dd>
          <dt pn="section-1.1-2.3">Host Isolation:</dt>
          <dd pn="section-1.1-2.4">Separating hosts into different subnets or links.</dd>
          <dt pn="section-1.1-2.5">L3 Isolation:</dt>
          <dd pn="section-1.1-2.6">Allocating a Unique Prefix per Host (UPPH) <xref target="RFC8273" format="default" sectionFormat="of" derivedContent="RFC8273"/> <xref target="RFC9663" format="default" sectionFormat="of" derivedContent="RFC9663"/> so that every host is in
	  a different subnet. Given that a unique prefix can be allocated per
	  host on shared media, hosts in different subnets may be on the same
	  link.</dd>
          <dt pn="section-1.1-2.7">L2 Isolation:</dt>
          <dd pn="section-1.1-2.8">Taking measures to prevent a host from reaching other hosts
	  directly in Layer 2 (L2) so that every host is in a different
	  link. Due to the existence of Multi-Link Subnet <xref target="RFC4903" format="default" sectionFormat="of" derivedContent="RFC4903"/>, hosts in different links may be in the same
	  subnet. Therefore, L2 Isolation does not imply L3 Isolation, and L3
	  Isolation does not imply L2 Isolation either.</dd>
          <dt pn="section-1.1-2.9">L3+L2 Isolation:</dt>
          <dd pn="section-1.1-2.10">Applying L3 Isolation and L2 Isolation simultaneously so that
	  every host is in a different subnet and on a different link.</dd>
          <dt pn="section-1.1-2.11">Partial L2 Isolation:</dt>
          <dd pn="section-1.1-2.12">Using an L3 ND Proxy <xref target="RFC4389" format="default" sectionFormat="of" derivedContent="RFC4389"/> device to
	  represent the hosts behind it to other hosts in the same
	  subnet. Within the subnet, ND multicast exchange is segmented into
	  multiple smaller scopes, each represented by an ND Proxy device.</dd>
        </dl>
      </section>
    </section>
    <section anchor="review-of-inventoried-nd-issues" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-review-of-inventoried-nd-is">Review of Inventoried ND Issues</name>
      <section anchor="multicast-may-cause-performance-and-reliability-issues" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-multicast-may-cause-perform">Multicast May Cause Performance and Reliability Issues</name>
        <t indent="0" pn="section-2.1-1">In some cases, ND uses multicast for NSs, NAs, RSs, and RAs. While
   multicast can be highly efficient in certain scenarios (e.g., in
   wired networks), multicast can also be inefficient in other
   scenarios (e.g., in large L2 networks or wireless networks).</t>
        <t indent="0" pn="section-2.1-2">Typically, multicast can create a large amount of protocol traffic
   in large L2 networks. This can consume network bandwidth, increase
   processing overhead, and degrade network performance <xref target="RFC7342" format="default" sectionFormat="of" derivedContent="RFC7342"/>.</t>
        <t indent="0" pn="section-2.1-3">In wireless networks, multicast can be inefficient or even
   unreliable due to a higher probability of transmission interference,
   lower data rate, and lack of acknowledgements (<xref target="RFC9119" section="3.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9119#section-3.1" derivedContent="RFC9119"/>).</t>
        <t indent="0" pn="section-2.1-4">Multicast-related performance issues of the various ND messages are
   summarized below:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.1-5">
          <li pn="section-2.1-5.1">
            <t indent="0" pn="section-2.1-5.1.1">Issue 1: LLA DAD degrades performance</t>
            <t indent="0" pn="section-2.1-5.1.2">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 pn="section-2.1-5.2">
            <t indent="0" pn="section-2.1-5.2.1">Issue 2: Router's periodic unsolicited RAs drain host's battery</t>
            <t indent="0" pn="section-2.1-5.2.2">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" format="default" sectionFormat="of" derivedContent="RFC7772"/>.</t>
          </li>
          <li pn="section-2.1-5.3">
            <t indent="0" pn="section-2.1-5.3.1">Issue 3: GUA DAD degrades performance</t>
            <t indent="0" pn="section-2.1-5.3.2">This is the same as in Issue 1.</t>
          </li>
          <li pn="section-2.1-5.4">
            <t indent="0" pn="section-2.1-5.4.1">Issue 4: Router's address resolution for hosts degrades performance</t>
            <t indent="0" pn="section-2.1-5.4.2">This is the same as in Issue 1.</t>
          </li>
          <li pn="section-2.1-5.5">
            <t indent="0" pn="section-2.1-5.5.1">Issue 5: Host's address resolution for hosts degrades performance</t>
            <t indent="0" pn="section-2.1-5.5.2">This is the same as in Issue 1.</t>
          </li>
          <li pn="section-2.1-5.6">
            <t indent="0" pn="section-2.1-5.6.1">Issue for further study: Multicast NAs for host's MAC address changes may degrade performance</t>
            <t indent="0" pn="section-2.1-5.6.2">With randomized and changing MAC addresses <xref target="RFC9797" format="default" sectionFormat="of" derivedContent="MADINAS"/>,
       there may be many such multicast messages.</t>
          </li>
        </ul>
        <t indent="0" pn="section-2.1-6">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" bare="false" empty="false" indent="3" pn="section-2.1-7">
          <li pn="section-2.1-7.1">
            <t indent="0" pn="section-2.1-7.1.1">Issue 6: LLA DAD not completely reliable in wireless networks</t>
          </li>
          <li pn="section-2.1-7.2">
            <t indent="0" pn="section-2.1-7.2.1">Issue 7: GUA DAD not completely reliable in wireless networks</t>
          </li>
        </ul>
        <t indent="0" pn="section-2.1-8">Note: IPv6 address collisions are extremely unlikely. As a result,
        these two issues are largely theoretical rather than practical.</t>
      </section>
      <section anchor="trusting-all-nodes-may-cause-on-link-security-issues" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-trusting-all-nodes-may-caus">Trusting-All-Nodes May Cause On-Link Security Issues</name>
        <t indent="0" pn="section-2.2-1">In scenarios such as public access networks, some nodes may not be
   trustworthy. An attacker on the link can cause the following on-link
   security issues <xref target="RFC3756" format="default" sectionFormat="of" derivedContent="RFC3756"/> <xref target="RFC9099" format="default" sectionFormat="of" derivedContent="RFC9099"/>:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-2">
          <li pn="section-2.2-2.1">
            <t indent="0" pn="section-2.2-2.1.1">Issue 8: Source IP address spoofing</t>
            <t indent="0" pn="section-2.2-2.1.2">An attacker can use another node's IP address as the source address
       of its ND message to pretend to be that node. The attacker can then
       launch various Redirect or Denial-of-Service (DoS) attacks.</t>
          </li>
          <li pn="section-2.2-2.2">
            <t indent="0" pn="section-2.2-2.2.1">Issue 9: Denial of DAD</t>
            <t indent="0" pn="section-2.2-2.2.2">An attacker can repeatedly reply to a victim's DAD messages, causing
       the victim's address configuration procedure to fail, resulting in a
       DoS to the victim.</t>
          </li>
          <li pn="section-2.2-2.3">
            <t indent="0" pn="section-2.2-2.3.1">Issue 10: Rogue RAs</t>
            <t indent="0" pn="section-2.2-2.3.2">An attacker can send RAs to victim hosts to pretend to be a
       router. The attacker can then launch various Redirect or DoS
       attacks.</t>
          </li>
          <li pn="section-2.2-2.4">
            <t indent="0" pn="section-2.2-2.4.1">Issue 11: Spoofed redirects</t>
            <t indent="0" pn="section-2.2-2.4.2">An attacker can send forged Redirects to victim hosts to redirect
       their traffic to the legitimate router itself.</t>
          </li>
          <li pn="section-2.2-2.5">
            <t indent="0" pn="section-2.2-2.5.1">Issue 12: Replay attacks</t>
            <t indent="0" pn="section-2.2-2.5.2">An attacker can capture valid ND messages and replay them later.</t>
          </li>
        </ul>
      </section>
      <section anchor="router-nce-on-demand-may-cause-forwarding-delay-nce-exhaustion-and-address-accountability-issues" numbered="true" removeInRFC="false" toc="include" pn="section-2.3">
        <name slugifiedName="name-router-nce-on-demand-may-ca">Router-NCE-on-Demand May Cause Forwarding Delay, NCE Exhaustion, and Address Accountability Issues</name>
        <t indent="0" pn="section-2.3-1">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
   NCE in the INCOMPLETE state. The router then multicasts an NS to the
   node's solicited-node multicast address. When the destination
   replies with an NA containing its MAC address, the router updates
   the NCE with that address and changes its state to REACHABLE,
   thereby completing the entry. This process is referred to as "Router‑NCE‑on‑Demand" in this document.</t>
        <t indent="0" pn="section-2.3-2">Router-NCE-on-Demand can cause the following issues:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3-3">
          <li pn="section-2.3-3.1">
            <t indent="0" pn="section-2.3-3.1.1">Issue 13: NCE exhaustion</t>
            <t indent="0" pn="section-2.3-3.1.2">An attacker can send a high volume of packets targeting
	    non-existent IP addresses, causing the router to create numerous
	    NCEs in the INCOMPLETE state. The resulting resource exhaustion
	    may cause the router to malfunction. This vulnerability, described
	    as "NCE exhaustion" in this document, does not require the
	    attacker to be on-link.</t>
          </li>
          <li pn="section-2.3-3.2">
            <t indent="0" pn="section-2.3-3.2.1">Issue 14: Router forwarding delay</t>
            <t indent="0" pn="section-2.3-3.2.2">When a packet arrives at a router, the router buffers it while
	    attempting to determine the host's MAC address. This buffering
	    delays forwarding and, depending on the router's buffer size, may
	    lead to packet loss.  This delay is referred to as
	    "Router‑NCE‑on‑Demand forwarding delay" in this document.</t>
          </li>
          <li pn="section-2.3-3.3">
            <t indent="0" pn="section-2.3-3.3.1">Issue 15: Lack of address accountability</t>
            <t indent="0" pn="section-2.3-3.3.2">With SLAAC, hosts generate their IP addresses. The router does
	    not become aware of a host's IP address until an NCE entry is
	    created. With DHCPv6 <xref target="RFC8415" format="default" sectionFormat="of" derivedContent="RFC8415"/>, the router may not
	    know the host's addresses unless it performs DHCPv6 snooping. In
	    public access networks, where subscriber management often relies
	    on IP address (or prefix) identification, this lack of address
	    accountability poses a challenge <xref target="I-D.ccc-v6ops-address-accountability" format="default" sectionFormat="of" derivedContent="AddrAcc"/>. 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" format="default" sectionFormat="of" derivedContent="RFC4861"/> provides no mechanism to
	    retrieve them for management or monitoring, as noted in <xref section="2.6.1" sectionFormat="of" target="RFC9099" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9099#section-2.6.1" derivedContent="RFC9099"/>.</t>
          </li>
        </ul>
      </section>
      <section anchor="summary-of-nd-issues" numbered="true" removeInRFC="false" toc="include" pn="section-2.4">
        <name slugifiedName="name-summary-of-nd-issues">Summary of ND Issues</name>
        <t indent="0" pn="section-2.4-1">The ND issues, as discussed in Sections <xref target="multicast-may-cause-performance-and-reliability-issues" format="counter" sectionFormat="of" derivedContent="2.1"/>, <xref target="trusting-all-nodes-may-cause-on-link-security-issues" format="counter" sectionFormat="of" derivedContent="2.2"/>, and <xref target="router-nce-on-demand-may-cause-forwarding-delay-nce-exhaustion-and-address-accountability-issues" format="counter" sectionFormat="of" derivedContent="2.3"/>, are summarized
   below. These issues stem from three primary causes: multicast,
   Trusting-all-nodes, and Router-NCE-on-Demand. Eliminating any of
   these causes would also mitigate the corresponding issues. These
   observations provide guidance for addressing and preventing ND-
   related issues.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2.4-2">
  <li pn="section-2.4-2.1" derivedCounter="1.">
            <t indent="0" pn="section-2.4-2.1.1">Multicast-related issues:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.4-2.1.2">
              <li pn="section-2.4-2.1.2.1">
                <t indent="0" pn="section-2.4-2.1.2.1.1">Performance issues:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.4-2.1.2.1.2">
                  <li pn="section-2.4-2.1.2.1.2.1">Issue 1: LLA DAD degrades performance</li>
                  <li pn="section-2.4-2.1.2.1.2.2">Issue 2: Router's periodic unsolicited RAs drain host's battery</li>
                  <li pn="section-2.4-2.1.2.1.2.3">Issue 3: GUA DAD degrades performance</li>
                  <li pn="section-2.4-2.1.2.1.2.4">Issue 4: Router's address resolution for hosts degrades performance</li>
                  <li pn="section-2.4-2.1.2.1.2.5">Issue 5: Host's address resolution for hosts degrades performance</li>
                </ul>
              </li>
              <li pn="section-2.4-2.1.2.2">
                <t indent="0" pn="section-2.4-2.1.2.2.1">Reliability issues:</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.4-2.1.2.2.2">
                  <li pn="section-2.4-2.1.2.2.2.1">Issue 6: LLA DAD not completely reliable in wireless networks</li>
                  <li pn="section-2.4-2.1.2.2.2.2">Issue 7: GUA DAD not completely reliable in wireless networks</li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-2.4-2.2" derivedCounter="2.">
            <t indent="0" pn="section-2.4-2.2.1">Trusting-all-nodes related issues:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.4-2.2.2">
              <li pn="section-2.4-2.2.2.1">Issue 8: Source IP address spoofing</li>
              <li pn="section-2.4-2.2.2.2">Issue 9: Denial of DAD</li>
              <li pn="section-2.4-2.2.2.3">Issue 10: Rogue RAs</li>
              <li pn="section-2.4-2.2.2.4">Issue 11: Spoofed redirects</li>
              <li pn="section-2.4-2.2.2.5">Issue 12: Replay attacks</li>
            </ul>
          </li>
          <li pn="section-2.4-2.3" derivedCounter="3.">
            <t indent="0" pn="section-2.4-2.3.1">Router-NCE-on-Demand related issues:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.4-2.3.2">
              <li pn="section-2.4-2.3.2.1">Issue 13: NCE exhaustion</li>
              <li pn="section-2.4-2.3.2.2">Issue 14: Router forwarding delay</li>
              <li pn="section-2.4-2.3.2.3">Issue 15: Lack of address accountability</li>
            </ul>
          </li>
        </ol>
        <t indent="0" pn="section-2.4-3">These issues are potential vulnerabilities and may not manifest in
   all usage scenarios.</t>
        <t indent="0" pn="section-2.4-4">When these issues may occur in a specific deployment, it is
   advisable to consider the mitigation solutions available. They are
   described in the following section.</t>
      </section>
    </section>
    <section anchor="review-of-nd-mitigation-solutions" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-review-of-nd-mitigation-sol">Review of ND Mitigation Solutions</name>
      <t indent="0" pn="section-3-1"><xref target="solutions-table" format="default" sectionFormat="of" derivedContent="Table 1"/> summarizes ND mitigation solutions available for Issues 1-15
   described in <xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/>. Similar solutions are grouped, beginning
   with those that address the most issues. Unrelated solutions are
   ordered based on the issues (listed in <xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/>) they address.
   Each solution in the table will be explained in a sub-section later,
   where abbreviations in the table are described.</t>
      <t indent="0" pn="section-3-2">In <xref target="solutions-table" format="default" sectionFormat="of" derivedContent="Table 1"/>, a letter code indicates the RFC category of the
   mitigation solution (see BCP 9 <xref target="RFC2026" format="default" sectionFormat="of" derivedContent="RFC2026"/> for an explanation of these
   categories):</t>
      <dl spacing="compact" newline="false" indent="5" pn="section-3-3">
        <dt pn="section-3-3.1">S:</dt>
        <dd pn="section-3-3.2">Standards Track (Proposed Standard or Internet Standard)</dd>
        <dt pn="section-3-3.3">E:</dt>
        <dd pn="section-3-3.4">Experimental</dd>
        <dt pn="section-3-3.5">I:</dt>
        <dd pn="section-3-3.6">Informational</dd>
        <dt pn="section-3-3.7">B:</dt>
        <dd pn="section-3-3.8">Best Current Practice</dd>
        <dt pn="section-3-3.9">N/A:</dt>
        <dd pn="section-3-3.10">Not Applicable (not an RFC)</dd>
      </dl>
      <t indent="0" pn="section-3-4">The abbreviations in <xref target="solutions-table" format="default" sectionFormat="of" derivedContent="Table 1"/> correspond to <xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/> as follows:</t>
      <dl spacing="compact" newline="false" indent="5" pn="section-3-5">
        <dt pn="section-3-5.1">On-link sec.:</dt>
        <dd pn="section-3-5.2">Trusting-all-nodes related issues</dd>
        <dt pn="section-3-5.3">NCE exh.:</dt>
        <dd pn="section-3-5.4">NCE exhaustion</dd>
        <dt pn="section-3-5.5">Fwd. delay:</dt>
        <dd pn="section-3-5.6">Router forwarding delay</dd>
        <dt pn="section-3-5.7">No addr. acc.:</dt>
        <dd pn="section-3-5.8">Lack of address accountability</dd>
      </dl>
      <table anchor="solutions-table" align="center" pn="table-1">
        <name slugifiedName="name-solutions-for-identified-is">Solutions for Identified Issues</name>
        <thead>
          <tr>
            <th rowspan="2" align="left" colspan="1">ND solution</th>
            <th rowspan="2" align="left" colspan="1">RFC cat.</th>
            <th colspan="5" align="left" rowspan="1">Multicast performance</th>
            <th colspan="2" align="left" rowspan="1">Reliability</th>
            <th align="left" colspan="1" rowspan="1">On-link sec.</th>
            <th align="left" colspan="1" rowspan="1">NCE exh.</th>
            <th align="left" colspan="1" rowspan="1">Fwd. delay</th>
            <th align="left" colspan="1" rowspan="1">No addr. acc.</th>
          </tr>
          <tr>
            <th align="center" colspan="1" rowspan="1">1</th>
            <th align="center" colspan="1" rowspan="1">2</th>
            <th align="center" colspan="1" rowspan="1">3</th>
            <th align="center" colspan="1" rowspan="1">4</th>
            <th align="center" colspan="1" rowspan="1">5</th>
            <th align="center" colspan="1" rowspan="1">6</th>
            <th align="center" colspan="1" rowspan="1">7</th>
            <th align="center" colspan="1" rowspan="1">8-12</th>
            <th align="center" colspan="1" rowspan="1">13</th>
            <th align="center" colspan="1" rowspan="1">14</th>
            <th align="center" colspan="1" rowspan="1">15</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">MBBv6</td>
            <td align="center" colspan="1" rowspan="1">I</td>
            <td colspan="11" align="center" rowspan="1">All identified issues solved</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">FBBv6</td>
            <td align="center" colspan="1" rowspan="1">N/A</td>
            <td colspan="11" align="center" rowspan="1">All identified issues solved</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">UPPH</td>
            <td align="center" colspan="1" rowspan="1">I</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="center" colspan="1" rowspan="1">X</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">WiND</td>
            <td align="center" colspan="1" rowspan="1">S</td>
            <td colspan="11" align="center" rowspan="1">All issues solved for Low-Power and Lossy Networks (LLNs)</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SARP</td>
            <td align="center" colspan="1" rowspan="1">E</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ND TRILL</td>
            <td align="center" colspan="1" rowspan="1">S</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ND EVPN</td>
            <td align="center" colspan="1" rowspan="1">S</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">RFC 7772</td>
            <td align="center" colspan="1" rowspan="1">B</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">GRAND</td>
            <td align="center" colspan="1" rowspan="1">S</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SAVI/RA-G</td>
            <td align="center" colspan="1" rowspan="1">I</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">RFC 6583</td>
            <td align="center" colspan="1" rowspan="1">I</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">RFC 9686</td>
            <td align="center" colspan="1" rowspan="1">S</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="center" colspan="1" rowspan="1">X</td>
          </tr>
        </tbody>
      </table>
      <section anchor="nd-solution-in-mobile-broadband-ipv6" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-mobile-broadband-ipv6-mbbv6">Mobile Broadband IPv6 (MBBv6)</name>
        <t indent="0" pn="section-3.1-1">The IPv6 solution defined in "IPv6 in 3rd Generation Partnership
        Project (3GPP) Evolved Packet System (EPS)" <xref target="RFC6459" format="default" sectionFormat="of" derivedContent="RFC6459"/>,
        "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts"
        <xref target="RFC7066" format="default" sectionFormat="of" derivedContent="RFC7066"/>, and "Extending an IPv6 /64 Prefix from a
        Third Generation Partnership Project (3GPP) Mobile Interface to a LAN
        Link" <xref target="RFC7278" format="default" sectionFormat="of" derivedContent="RFC7278"/> is called Mobile Broadband IPv6
        (MBBv6) in this document. They are Informational RFCs. The key points
        are:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2">
          <li pn="section-3.1-2.1">
            <t indent="0" pn="section-3.1-2.1.1">Putting every host (e.g., the mobile User Equipment (UE)) in a
     Point-to-Point (P2P) link with the router (e.g., the mobile
     gateway) has the following outcomes:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2.1.2">
              <li pn="section-3.1-2.1.2.1">All multicast is effectively turned into unicast.</li>
              <li pn="section-3.1-2.1.2.2">The P2P links do not have a MAC address. Therefore, Router-
      NCE-on-Demand is not needed.</li>
              <li pn="section-3.1-2.1.2.3">Trusting-all-nodes is only relevant to the router. By applying
      filtering at the router (e.g., dropping RAs from the hosts), even
      malicious hosts cannot cause harm.</li>
            </ul>
          </li>
          <li pn="section-3.1-2.2">Assigning a unique /64 prefix to each host. Together with the
    P2P link, this puts each host on a separate link and subnet.</li>
          <li pn="section-3.1-2.3">Maintaining (prefix, interface) binding at the router for
    forwarding purposes.</li>
        </ul>
        <t indent="0" pn="section-3.1-3">Since all the three causes of ND issues are addressed, all the
   issues discussed in <xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/> are addressed.</t>
      </section>
      <section anchor="nd-solution-in-fixed-broadband-ipv6" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-fixed-broadband-ipv6-fbbv6">Fixed Broadband IPv6 (FBBv6)</name>
        <t indent="0" pn="section-3.2-1">The IPv6 solution defined in "IPv6 in the context of TR-101" <xref target="TR177" format="default" sectionFormat="of" derivedContent="TR177"/>
   is called Fixed Broadband IPv6 (FBBv6) in this document. FBBv6 has
   two flavors:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-2">
          <li pn="section-3.2-2.1">P2P: Every host (e.g., the Residential Gateway (RG)) is in a
    P2P link with the router (e.g., the Broadband Network Gateway
    (BNG)). In this case, the solution is functionally similar to
    MBBv6. All ND issues discussed in <xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/> are solved.</li>
          <li pn="section-3.2-2.2">Point to Multipoint (P2MP): All hosts (e.g., the RGs)
    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
    and configuring the OLT to block any frame from being forwarded
    between its access ports; traffic from each host can travel
    only up toward the router, not sideways to another host,
    thereby preventing direct host-to-host communication.</li>
        </ul>
        <t indent="0" pn="section-3.2-3">The following list summarizes the two key aspects of the FBBv6-P2MP
   architecture as described in <xref target="TR177" format="default" sectionFormat="of" derivedContent="TR177"/> and the associated benefits:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-4">
          <li pn="section-3.2-4.1">
            <t indent="0" pn="section-3.2-4.1.1">Implementing DAD proxy <xref target="RFC6957" format="default" sectionFormat="of" derivedContent="RFC6957"/>:</t>
            <t indent="0" pn="section-3.2-4.1.2">In a P2MP architecture described above, the normal ND DAD procedure
     will break down because hosts cannot exchange NSs with one another. To
     address this, the router participates in the DAD process as a DAD Proxy
     to resolve address duplication.</t>
            <t indent="0" pn="section-3.2-4.1.3">The benefits are:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-4.1.4">
              <li pn="section-3.2-4.1.4.1">Multicast traffic from all hosts to the router is effectively
       converted into unicast, as hosts can only communicate directly with the
       router.</li>
              <li pn="section-3.2-4.1.4.2">The Trusting-all-nodes model is limited to the router. By applying
       simple filtering (e.g., dropping RAs from hosts), the router can
       mitigate security risks, even from malicious hosts.</li>
            </ul>
          </li>
          <li pn="section-3.2-4.2">
            <t indent="0" pn="section-3.2-4.2.1">Assigning a unique /64 prefix to each host:</t>
            <t indent="0" pn="section-3.2-4.2.2">Assigning each host a unique /64 prefix results in several operational
   improvements:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-4.2.3">
              <li pn="section-3.2-4.2.3.1">The router can proactively install a forwarding entry for that
       prefix towards the host, eliminating the need for
       Router-NCE-on-Demand.</li>
              <li pn="section-3.2-4.2.3.2">Since each host resides in a different subnet, traffic between
       hosts is routed through the router, eliminating the need for hosts to
       perform address resolution for one another.</li>
              <li pn="section-3.2-4.2.3.3">Without address resolution, router multicast to hosts is limited to
       unsolicited RAs. As each host resides in its own subnet, these RAs are
       sent as unicast packets to individual hosts. This follows the approach
       specified in <xref target="RFC6085" format="default" sectionFormat="of" derivedContent="RFC6085"/>, where the host's MAC address replaces the
       multicast MAC address in the RA.</li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-3.2-5">Since all three causes of ND issues are addressed, all ND issues
   (<xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/>) are also addressed.</t>
      </section>
      <section anchor="unique-ipv6-prefix-per-host-upph" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-unique-prefix-per-host-upph">Unique Prefix per Host (UPPH)</name>
        <t indent="0" pn="section-3.3-1">Unique Prefix per Host (UPPH) solutions are described in <xref target="RFC8273" format="default" sectionFormat="of" derivedContent="RFC8273"/> and <xref target="RFC9663" format="default" sectionFormat="of" derivedContent="RFC9663"/>. Both are
   Informational RFCs. <xref target="RFC8273" format="default" sectionFormat="of" derivedContent="RFC8273"/> relies on SLAAC for unique prefix
   allocation while <xref target="RFC9663" format="default" sectionFormat="of" derivedContent="RFC9663"/> relies on DHCPv6 Prefix Delegation (DHCPv6-PD). That difference in
   allocation mechanism does not change the discussion on ND issues,
   because every IPv6 node is still required to run SLAAC, even when it
   receives its prefix via DHCPv6-PD. Therefore, discussing <xref target="RFC8273" format="default" sectionFormat="of" derivedContent="RFC8273"/>
   alone is sufficient.</t>
        <t indent="0" pn="section-3.3-2"><xref target="RFC8273" format="default" sectionFormat="of" derivedContent="RFC8273"/> "improves host isolation and enhanced subscriber
   management on shared network segments" such as Wi-Fi or Ethernet.
   The key points are:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3-3">
          <li pn="section-3.3-3.1">When a prefix is allocated to the host, the router can proactively
     install a forwarding entry for that prefix towards the host.  There is no
     more Router-NCE-on-Demand.</li>
          <li pn="section-3.3-3.2">Without address resolution, router multicast to hosts consists
    only of unsolicited RAs. They will be sent to hosts one by one
    in unicast because the prefix for every host is different.</li>
          <li pn="section-3.3-3.3">Since different hosts are in different subnets, hosts will send
    traffic to other hosts via the router. There is no host-to-host
    address resolution.</li>
        </ul>
        <t indent="0" pn="section-3.3-4">Therefore, ND issues caused by Router-NCE-on-Demand and router
   multicast to hosts are prevented.</t>
        <t indent="0" pn="section-3.3-5"><xref target="RFC8273" format="default" sectionFormat="of" derivedContent="RFC8273"/> indicates that a "network implementing a
        unique IPv6 prefix per host can simply ensure that devices cannot send
        packets to each other except through the first-hop router". However,
        when hosts are on a shared medium like Ethernet, ensuring "devices
        cannot send packets to each other except through the first-hop router"
        requires additional measures like Private VLAN <xref target="RFC5517" format="default" sectionFormat="of" derivedContent="RFC5517"/>. Without such additional measures, on a shared
        medium, hosts can still reach each other in L2 as they belong to the
        same Solicited-Node Multicast Group. Therefore, Trusting-all-nodes and
        host multicast to routers may cause issues. Of the host multicast
        issues (i.e., Issues 1, 3, 5, 6, and 7), UPPH prevents Issues 5 and 7,
        because there is no need for address resolution among hosts (Issue 5),
        and there is no possibility of GUA duplication (Issue 7). However,
        Issues 1, 3, and 6 may occur.</t>
      </section>
      <section anchor="wireless-nd-and-subnet-nd" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-wireless-nd-wind">Wireless ND (WiND)</name>
        <t indent="0" pn="section-3.4-1">The term "Wireless ND (WiND)" is used in this document to describe
        the fundamentally different ND solution for Low-Power and Lossy
        Networks (LLNs) <xref target="RFC7102" format="default" sectionFormat="of" derivedContent="RFC7102"/> that is defined in <xref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775"/>, <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/>, <xref target="RFC8928" format="default" sectionFormat="of" derivedContent="RFC8928"/>, and <xref target="RFC8929" format="default" sectionFormat="of" derivedContent="RFC8929"/> (Standards Track).
        WiND changes host and router behaviors to use multicast only for
        router discovery. The key points are:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4-2">
          <li pn="section-3.4-2.1">Hosts use unicast to proactively register their addresses at
    the routers. Routers use unicast to communicate with hosts and
    become an abstract registrar and arbitrator for address
    ownership.</li>
          <li pn="section-3.4-2.2">The router also proactively installs NCEs for the hosts. This
    avoids the need for address resolution for the hosts.</li>
          <li pn="section-3.4-2.3">The router sets the Prefix Information Option (PIO) L-bit to 0.
    Each host communicates only with the router (<xref target="RFC4861" section="6.3.4" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc4861#section-6.3.4" derivedContent="RFC4861"/>).</li>
          <li pn="section-3.4-2.4">Other functionalities that are relevant only to LLNs.</li>
        </ul>
        <t indent="0" pn="section-3.4-3">WiND addresses all ND issues (<xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/>) in LLNs. However, WiND
   support is not mandatory for general-purpose hosts. Therefore, it
   cannot be relied upon as a deployment option without imposing
   additional constraints on the participating nodes.</t>
      </section>
      <section anchor="scalable-address-resolution-protocol" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-scalable-address-resolution">Scalable Address Resolution Protocol (SARP)</name>
        <t indent="0" pn="section-3.5-1">The Scalable Address Resolution Protocol (SARP) <xref target="RFC7586" format="default" sectionFormat="of" derivedContent="RFC7586"/> was an Experimental solution. That experiment ended
        in 2017, two years after the RFC was published. Because the idea has
        been used in mitigation solutions for more specific scenarios
        (described in Sections <xref target="arp-and-nd-optimization-for-trill" format="counter" sectionFormat="of" derivedContent="3.6"/> and
        <xref target="proxy-arpnd-in-ethernet-virtual-private-networks-evpn" format="counter" sectionFormat="of" derivedContent="3.7"/>), it is worth describing here. The usage scenario
        is Data Centers (DCs), where large L2 domains span across multiple
        sites. In each site, multiple hosts are connected to a switch. The
        hosts can be Virtual Machines (VMs), so the number can be large.  The
        switches are interconnected by a pure or overlay L2 network.</t>
        <t indent="0" pn="section-3.5-2">The switch will snoop and install a (IP, MAC address) proxy table for
   the local hosts. The switch will also reply to address resolution
   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
   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
   all the hosts in the L2 domain. Consequently, the MAC address table
   size of the switches is significantly reduced. A switch will also
   add the (IP, MAC address) replies from remote switches to its proxy
   ND table so that it can reply to future address resolution requests
   from local hosts for such IPs directly. This greatly reduces the
   number of address resolution multicast in the network.</t>
        <t indent="0" pn="section-3.5-3">Unlike MBBv6, FBBv6, and UPPH, which try to address all ND issues
   discussed in <xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/>, SARP focuses on reducing address
   resolution multicast to improve the performance and scalability of
   large L2 domains in DCs.</t>
      </section>
      <section anchor="arp-and-nd-optimization-for-trill" numbered="true" removeInRFC="false" toc="include" pn="section-3.6">
        <name slugifiedName="name-nd-optimization-for-trill">ND Optimization for TRILL</name>
        <t indent="0" pn="section-3.6-1">ARP and ND optimization for Transparent Interconnection of Lots of Links (TRILL) <xref target="RFC8302" format="default" sectionFormat="of" derivedContent="RFC8302"/>
        (Standards Track) is similar to SARP (<xref target="scalable-address-resolution-protocol" format="default" sectionFormat="of" derivedContent="Section 3.5"/>). It
        can be considered an application of SARP in the TRILL environment.</t>
        <t indent="0" pn="section-3.6-2">Like SARP, ND optimization for TRILL focuses on reducing multicast address resolution. That is, it addresses Issue 5 (<xref target="multicast-may-cause-performance-and-reliability-issues" format="default" sectionFormat="of" derivedContent="Section 2.1"/>).</t>
      </section>
      <section anchor="proxy-arpnd-in-ethernet-virtual-private-networks-evpn" numbered="true" removeInRFC="false" toc="include" pn="section-3.7">
        <name slugifiedName="name-proxy-nd-in-ethernet-virtua">Proxy ND in Ethernet Virtual Private Networks (ND EVPN)</name>
        <t indent="0" pn="section-3.7-1">Proxy ARP/ND in EVPN is specified in <xref target="RFC9161" format="default" sectionFormat="of" derivedContent="RFC9161"/> (Standards Track).
   The usage scenario is DCs where large L2 domains span across
   multiple sites. In each site, multiple hosts are connected to a
   Provider Edge (PE) router.  The PEs are interconnected by EVPN
   tunnels.</t>
        <t indent="0" pn="section-3.7-2">The PE of each site snoops the local address resolution NAs to build
   (IP, MAC address) Proxy ND table entries. PEs then propagate such
   Proxy ND entries to other PEs via the Border Gateway Protocol (BGP).
   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, the PE will reply directly.  Consequently, the number of
   multicast address resolution messages is significantly reduced.</t>
        <t indent="0" pn="section-3.7-3">Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address
   resolution multicast.</t>
      </section>
      <section anchor="reducing-router-advertisements" numbered="true" removeInRFC="false" toc="include" pn="section-3.8">
        <name slugifiedName="name-reducing-router-advertiseme">Reducing Router Advertisements per RFC 7772</name>
        <t indent="0" pn="section-3.8-1">Maintaining IPv6 connectivity requires that hosts be able to receive
   periodic multicast RAs <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/>.  Hosts that process unicast
   packets while they are asleep must also process multicast RAs while
   they are asleep. An excessive number of RAs can significantly reduce
   the battery life of mobile hosts. <xref target="RFC7772" format="default" sectionFormat="of" derivedContent="RFC7772"/> (Best Current Practice)
   specifies a solution to reduce RAs:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.8-2">
          <li pn="section-3.8-2.1">The router should respond to RS with unicast RA (rather than
    the normal multicast RA) if the host's source IP address is
    specified and the host's MAC address is valid. This way, other
    hosts will not receive this RA.</li>
          <li pn="section-3.8-2.2">The router should reduce the multicast RA frequency.</li>
        </ul>
        <t indent="0" pn="section-3.8-3"><xref target="RFC7772" format="default" sectionFormat="of" derivedContent="RFC7772"/> addresses Issue 2 (<xref target="multicast-may-cause-performance-and-reliability-issues" format="default" sectionFormat="of" derivedContent="Section 2.1"/>).</t>
      </section>
      <section anchor="gratuitous-neighbor-discovery-grand" numbered="true" removeInRFC="false" toc="include" pn="section-3.9">
        <name slugifiedName="name-gratuitous-neighbor-discove">Gratuitous Neighbor Discovery (GRAND)</name>
        <t indent="0" pn="section-3.9-1">GRAND <xref target="RFC9131" format="default" sectionFormat="of" derivedContent="RFC9131"/> (Standards Track) changes ND in the following ways:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.9-2">
          <li pn="section-3.9-2.1">A node sends unsolicited NAs upon assigning a new IPv6 address
	  to its interface.</li>
          <li pn="section-3.9-2.2">A router creates a new NCE for the node and sets its state to
	  STALE.</li>
        </ul>
        <t indent="0" pn="section-3.9-3">When a packet for the host later arrives, the router can use the
        existing STALE NCE to forward it immediately (<xref target="RFC4861" sectionFormat="comma" section="7.2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4861#section-7.2.2" derivedContent="RFC4861"/>). It then verifies
        reachability by sending a unicast NS rather than a multicast one for
        address resolution. In this way, GRAND eliminates the router
        forwarding delay, but it does not solve other Router-NCE-on-Demand
        issues. For example, NCE exhaustion can still happen.</t>
      </section>
      <section anchor="source-address-validation-improvement-savi-and-router-advertisement-guard" numbered="true" removeInRFC="false" toc="include" pn="section-3.10">
        <name slugifiedName="name-source-address-validation-i">Source Address Validation Improvement (SAVI) and Router
        Advertisement Guard (RA-Guard)</name>
        <t indent="0" pn="section-3.10-1">Source Address Validation Improvement (SAVI) <xref target="RFC7039" format="default" sectionFormat="of" derivedContent="RFC7039"/> (Informational) binds an address to a port on an L2
   switch and rejects claims from other ports for that address.
   Therefore, a node cannot spoof the IP address of another node.</t>
        <t indent="0" pn="section-3.10-2">Router Advertisement Guard (RA-Guard) <xref target="RFC6105" format="default" sectionFormat="of" derivedContent="RFC6105"/> <xref target="RFC7113" format="default" sectionFormat="of" derivedContent="RFC7113"/>
   (Informational) only allows RAs from a port that a router is
   connected to. Therefore, nodes on other ports cannot pretend to be a
   router.</t>
        <t indent="0" pn="section-3.10-3">SAVI and RA-Guard address the on-link security issues.</t>
      </section>
      <section anchor="rfc-6583-dealing-with-nce-exhaustion-attacks" numbered="true" removeInRFC="false" toc="include" pn="section-3.11">
        <name slugifiedName="name-dealing-with-nce-exhaustion">Dealing with NCE Exhaustion Attacks per RFC 6583</name>
        <t indent="0" pn="section-3.11-1"><xref target="RFC6583" format="default" sectionFormat="of" derivedContent="RFC6583"/> (Informational) deals with the NCE
        exhaustion attack issue (<xref target="router-nce-on-demand-may-cause-forwarding-delay-nce-exhaustion-and-address-accountability-issues" format="default" sectionFormat="of" derivedContent="Section 2.3"/>). It recommends that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.11-2">
          <li pn="section-3.11-2.1">
            <t indent="0" pn="section-3.11-2.1.1">Operators should:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.11-2.1.2">
              <li pn="section-3.11-2.1.2.1">Filter unused address space so that messages to such
              addresses can be dropped rather than triggering NCE
              creation.</li>
              <li pn="section-3.11-2.1.2.2">Implement rate-limiting mechanisms for ND message
              processing to prevent CPU and memory resources from being
              overwhelmed.</li>
            </ul>
          </li>
          <li pn="section-3.11-2.2">
            <t indent="0" pn="section-3.11-2.2.1">Vendors should:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.11-2.2.2">
              <li pn="section-3.11-2.2.2.1">Prioritize NDP processing for existing NCEs over creating
              new NCEs.</li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-3.11-3"><xref target="RFC6583" format="default" sectionFormat="of" derivedContent="RFC6583"/> acknowledges that "some of these options are 'kludges',
	and can be operationally difficult to manage". <xref target="RFC6583" format="default" sectionFormat="of" derivedContent="RFC6583"/> partially
	addresses the Router NCE exhaustion issue. In practice, router
	vendors cap the number of NCEs per interface to prevent cache
	exhaustion. If the link has more addresses than that cap, the router
	cannot keep an entry for every address, and packets destined for
	addresses without an NCE are simply dropped <xref target="RFC9663" format="default" sectionFormat="of" derivedContent="RFC9663"/>.</t>
      </section>
      <section anchor="registering-self-generated-ipv6-addresses-using-dhcpv6" numbered="true" removeInRFC="false" toc="include" pn="section-3.12">
        <name slugifiedName="name-registering-self-generated-">Registering Self-Generated IPv6 Addresses Using DHCPv6 per RFC 9686</name>
        <t indent="0" pn="section-3.12-1">In IPv4, network administrators can retrieve a host's IP address
	from the DHCP server and use it for subscriber management. In IPv6
   and SLAAC, this is not possible (<xref target="router-nce-on-demand-may-cause-forwarding-delay-nce-exhaustion-and-address-accountability-issues" format="default" sectionFormat="of" derivedContent="Section 2.3"/>).</t>
        <t indent="0" pn="section-3.12-2"><xref target="RFC9686" format="default" sectionFormat="of" derivedContent="RFC9686"/> (Standards Track) defines a method for informing a DHCPv6
   server that a host has one or more self-generated or statically
   configured addresses. This enables network administrators to
   retrieve the IPv6 addresses for each host from the DHCPv6 server.
   <xref target="RFC9686" format="default" sectionFormat="of" derivedContent="RFC9686"/> provides a solution for Issue 15 (<xref target="router-nce-on-demand-may-cause-forwarding-delay-nce-exhaustion-and-address-accountability-issues" format="default" sectionFormat="of" derivedContent="Section 2.3"/>).</t>
      </section>
      <section anchor="enhanced-dad" numbered="true" removeInRFC="false" toc="include" pn="section-3.13">
        <name slugifiedName="name-enhanced-dad">Enhanced DAD</name>
        <t indent="0" pn="section-3.13-1">Enhanced DAD <xref target="RFC7527" format="default" sectionFormat="of" derivedContent="RFC7527"/> (Standards Track) addresses a DAD failure
   issue in a specific situation: a looped-back interface. DAD will
   fail in a looped-back interface because the sending host will
   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
   Nonce option <xref target="RFC3971" format="default" sectionFormat="of" derivedContent="RFC3971"/> in each DAD message so that the sending host
   can detect that the looped-back DAD message is sent by itself.</t>
        <t indent="0" pn="section-3.13-2">Enhanced DAD does not solve any ND issue. It extends ND to work in a
   new scenario: a looped-back interface. It is reviewed here only for
   completeness.</t>
      </section>
      <section anchor="nd-mediation-for-ip-interworking-of-layer-2-vpns" numbered="true" removeInRFC="false" toc="include" pn="section-3.14">
        <name slugifiedName="name-nd-mediation-for-ip-interwo">ND Mediation for IP Interworking of Layer 2 VPNs</name>
        <t indent="0" pn="section-3.14-1">ND mediation is specified in <xref target="RFC6575" format="default" sectionFormat="of" derivedContent="RFC6575"/> (Standards Track). When two
   Attachment Circuits (ACs) are interconnected by a Virtual Private
   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
   interwork to provide mediation service so that a Customer Edge (CE)
   can resolve the MAC address of the remote end. <xref target="RFC6575" format="default" sectionFormat="of" derivedContent="RFC6575"/> specifies
   such a solution.</t>
        <t indent="0" pn="section-3.14-2">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.
   It is reviewed here only for completeness.</t>
      </section>
      <section anchor="nd-solutions-defined-before-the-latest-versions-of-nd" numbered="true" removeInRFC="false" toc="include" pn="section-3.15">
        <name slugifiedName="name-nd-solutions-defined-before">ND Solutions Defined Before the Latest Versions of ND</name>
        <t indent="0" pn="section-3.15-1">The latest versions of ND and SLAAC are specified in <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/> and
   <xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/>. Several ND mitigation solutions were published before
   <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/>. They are reviewed in this section only for completeness.</t>
        <section anchor="secure-neighbor-discovery-send" numbered="true" removeInRFC="false" toc="include" pn="section-3.15.1">
          <name slugifiedName="name-secure-neighbor-discovery-s">Secure Neighbor Discovery (SEND)</name>
          <t indent="0" pn="section-3.15.1-1">The purpose of SEND <xref target="RFC3971" format="default" sectionFormat="of" derivedContent="RFC3971"/> (Standards Track) is
          to ensure that hosts and routers are trustworthy.  SEND defined
          three new ND options: Cryptographically Generated Addresses (CGA)
          <xref target="RFC3972" format="default" sectionFormat="of" derivedContent="RFC3972"/> (Standards Track), RSA public-key
          cryptosystem, and Timestamp/Nonce. In addition, SEND also defined an
          authorization delegation discovery process, an address ownership
          proof mechanism, and requirements for the use of these components in
          the ND protocol.</t>
        </section>
        <section anchor="cryptographically-generated-addresses-cga" numbered="true" removeInRFC="false" toc="include" pn="section-3.15.2">
          <name slugifiedName="name-cryptographically-generated">Cryptographically Generated Addresses (CGA)</name>
          <t indent="0" pn="section-3.15.2-1">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
   the Interface Identifier (IID) of an IPv6 address by computing a
   cryptographic hash of the public key.  The resulting IPv6 address is
   called a CGA.  The corresponding private key can then be used to
   sign messages sent from the address.</t>
          <t indent="0" pn="section-3.15.2-2">CGA assumes that a legitimate host does not care about the bit
   combination of the IID that would be created by some hash procedure.
   The attacker needs an exact IID to impersonate the legitimate hosts,
   but then the attacker is challenged to do a reverse hash calculation,
   which is a strong mathematical challenge.</t>
          <t indent="0" pn="section-3.15.2-3">CGA is part of SEND. There is no reported deployment.</t>
        </section>
        <section anchor="nd-proxy" numbered="true" removeInRFC="false" toc="include" pn="section-3.15.3">
          <name slugifiedName="name-nd-proxy">ND Proxy</name>
          <t indent="0" pn="section-3.15.3-1">ND Proxy <xref target="RFC4389" format="default" sectionFormat="of" derivedContent="RFC4389"/> (Experimental) aims to enable multiple links
   joined by an ND Proxy device to work as a single link.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.15.3-2">
            <li pn="section-3.15.3-2.1">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
    paragraph) outgoing interface. If there is no best interface,
    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 itself. That is, the ND Proxy will change the ND
    message's source IP and source MAC address to the ND Proxy's
    outgoing interface's IP and MAC address, and create an NCE
    entry at the outgoing interface accordingly.</li>
            <li pn="section-3.15.3-2.2">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
    at the receiving interface. Based on such state information,
    the ND Proxy can determine the "best" outgoing interface for
    future ND requests. The ND Proxy then proxies the ND message
    back to the requesting host.</li>
          </ul>
          <t indent="0" pn="section-3.15.3-3">ND Proxy is widely used in SARP (<xref target="scalable-address-resolution-protocol" format="default" sectionFormat="of" derivedContent="Section 3.5"/>),
          ND optimization for TRILL (<xref target="arp-and-nd-optimization-for-trill" format="default" sectionFormat="of" derivedContent="Section 3.6"/>), and
          Proxy ARP/ND in EVPN (<xref target="proxy-arpnd-in-ethernet-virtual-private-networks-evpn" format="default" sectionFormat="of" derivedContent="Section 3.7"/>).</t>
        </section>
        <section anchor="optimistic-dad" numbered="true" removeInRFC="false" toc="include" pn="section-3.15.4">
          <name slugifiedName="name-optimistic-dad">Optimistic DAD</name>
          <t indent="0" pn="section-3.15.4-1">Optimistic DAD <xref target="RFC4429" format="default" sectionFormat="of" derivedContent="RFC4429"/> (Standards Track) seeks to minimize address
   configuration delays in the successful case and to reduce disruption
   as far as possible in the failure case. That is, Optimistic DAD lets
   hosts immediately use the newly formed address to communicate before
   DAD completes, assuming that DAD will succeed anyway. If the address
   turns out to be duplicate, Optimistic DAD provides a set of
   mechanisms to minimize the impact. Optimistic DAD modified the
   original ND <xref target="RFC2461" format="default" sectionFormat="of" derivedContent="RFC2461"/> and original SLAAC <xref target="RFC2462" format="default" sectionFormat="of" derivedContent="RFC2462"/> (both of which are obsolete), but the solution was not
   incorporated into the latest specifications of ND <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/> and
   SLAAC <xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/>. However, implementations of Optimistic DAD exist.</t>
          <t indent="0" pn="section-3.15.4-2">Optimistic DAD does not solve any ND issue (<xref target="review-of-inventoried-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2"/>). It is
   reviewed here only for completeness.</t>
        </section>
      </section>
    </section>
    <section anchor="guidelines-for-prevention-of-potential-nd-issues" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-guidelines-for-prevention-o">Guidelines for Prevention of Potential ND Issues</name>
      <t indent="0" pn="section-4-1">By knowing the potential ND issues and associated mitigation
   solutions, network administrators of existing IPv6 deployments can
   assess whether these issues may occur in their networks and, if so,
   whether to deploy the mitigation solutions proactively. Deploying
   these solutions may take time and additional resources. Therefore,
   it is advisable to plan.</t>
      <t indent="0" pn="section-4-2">Network administrators planning to start their IPv6 deployments can
   use the issue-solution information to help plan their deployments.
   Moreover, they can take proactive action to prevent potential ND
   issues.</t>
      <section anchor="learning-host-isolation-from-the-existing-solutions" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-learning-host-isolation-fro">Learning Host Isolation from the Existing Solutions</name>
        <t indent="0" pn="section-4.1-1">While various ND solutions may initially appear unrelated,
   categorizing them into four distinct groups highlights an important
   observation: host isolation is an effective strategy for
   mitigating ND-related issues.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2">
          <li pn="section-4.1-2.1">
            <t indent="0" pn="section-4.1-2.1.1">Group 1: L3 and L2 Isolation</t>
            <t indent="0" pn="section-4.1-2.1.2">This group includes MBBv6 and FBBv6, which isolate hosts at both L3 and
  L2 by placing each host within its subnet and link. This prevents ND issues
  caused by multicast and Trusting-all-nodes, as each host operates within its
  isolated domain. Furthermore, since routers can route packets to a host
  based on its unique prefix, the need for Router-NCE-on-Demand is also
  eliminated. Therefore, L3 and L2 Isolation prevent all ND issues.</t>
          </li>
          <li pn="section-4.1-2.2">
            <t indent="0" pn="section-4.1-2.2.1">Group 2: L3 Isolation</t>
            <t indent="0" pn="section-4.1-2.2.2">This group includes UPPH solutions like <xref target="RFC8273" format="default" sectionFormat="of" derivedContent="RFC8273"/> and
  <xref target="RFC9663" format="default" sectionFormat="of" derivedContent="RFC9663"/>, which isolate hosts into separate subnets while
  potentially leaving them on the same shared medium. This approach mitigates
  ND issues caused by router multicast to hosts and eliminates the need for
  Router-NCE-on-Demand, as detailed in <xref target="unique-ipv6-prefix-per-host-upph" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.</t>
          </li>
          <li pn="section-4.1-2.3">
            <t indent="0" pn="section-4.1-2.3.1">Group 3: Partial L2 Isolation</t>
            <t indent="0" pn="section-4.1-2.3.2">This group encompasses solutions such as WiND, SARP, ND optimization for
  TRILL, and Proxy ND in EVPN. These solutions use a proxy device to represent
  the hosts behind it, effectively isolating those hosts into distinct
  multicast domains. While hosts are still located within the same subnet,
  their separation into different multicast domains reduces the scope of ND
  issues related to multicast-based address resolution.</t>
          </li>
          <li pn="section-4.1-2.4">
            <t indent="0" pn="section-4.1-2.4.1">Group 4: Non-Isolating Solutions</t>
            <t indent="0" pn="section-4.1-2.4.2">The final group includes remaining solutions that do not implement host
  isolation. These solutions do not prevent ND issues but instead focus on
  addressing specific ND problems.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-3">The analysis demonstrates that the stronger the isolation of hosts,
   the more ND issues can be mitigated. This correlation is intuitive,
   as isolating hosts reduces the multicast scope, minimizes the number
   of nodes that must be trusted, and may eliminate the need for
   Router-NCE-on-Demand, the three primary causes of ND issues.</t>
        <t indent="0" pn="section-4.1-4">This understanding can be used to prevent ND issues.</t>
      </section>
      <section anchor="applicability-of-various-isolation-methods" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-applicability-of-various-is">Applicability of Various Isolation Methods</name>
        <section anchor="applicability-of-l3l2-isolation" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1">
          <name slugifiedName="name-applicability-of-l3l2-isola">Applicability of L3+L2 Isolation</name>
          <t indent="0" pn="section-4.2.1-1">Benefits:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.1-2">
            <li pn="section-4.2.1-2.1">
              <t indent="0" pn="section-4.2.1-2.1.1">All ND issues (<xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/>) can be effectively mitigated.</t>
            </li>
          </ul>
          <t indent="0" pn="section-4.2.1-3">Constraints:</t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.2.1-4">
	    <li pn="section-4.2.1-4.1" derivedCounter="1.">
              <t indent="0" pn="section-4.2.1-4.1.1">L2 Isolation:</t>
              <t indent="0" pn="section-4.2.1-4.1.2">Actions must be taken to isolate hosts in L2. The required
              effort varies by the chosen method and deployment context. For
              example, the P2P method <xref target="RFC7066" format="default" sectionFormat="of" derivedContent="RFC7066"/> is
              heavyweight, while the Private VLAN method <xref target="RFC5517" format="default" sectionFormat="of" derivedContent="RFC5517"/> is more manageable.</t>
            </li>
            <li pn="section-4.2.1-4.2" derivedCounter="2.">
              <t indent="0" pn="section-4.2.1-4.2.1">Unique prefix allocation:</t>
              <t indent="0" pn="section-4.2.1-4.2.2">A large number of prefixes will be required, with one prefix
              assigned per host. This is generally not a limitation for
              IPv6. For instance, members of a Regional Internet Registry
              (RIR) can obtain a /29 prefix allocation <xref target="RIPE738" format="default" sectionFormat="of" derivedContent="RIPE738"/>, which provides 32 billion /64 prefixes --
              sufficient for any foreseeable deployment scenarios.  Practical
              implementations, such as MBBv6 assigning /64 prefixes to
              billions of mobile UEs <xref target="RFC6459" format="default" sectionFormat="of" derivedContent="RFC6459"/>, and FBBv6
              assigning /56 prefixes to hundreds of millions of routed RGs
              <xref target="TR177" format="default" sectionFormat="of" derivedContent="TR177"/>, demonstrate the feasibility of this
              approach.</t>
            </li>
            <li pn="section-4.2.1-4.3" derivedCounter="3.">
              <t indent="0" pn="section-4.2.1-4.3.1">Privacy issue from unique prefix identifiability:</t>
              <t indent="0" pn="section-4.2.1-4.3.2">Assigning a unique prefix to each host may theoretically
              reduce privacy, as hosts can be directly identified by their
              assigned prefix. However, alternative host identification
              methods, such as 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>
            </li>
            <li pn="section-4.2.1-4.4" derivedCounter="4.">
              <t indent="0" pn="section-4.2.1-4.4.1">Router support for L3 Isolation:</t>
              <t indent="0" pn="section-4.2.1-4.4.2">The router must support an L3 Isolation solution, e.g., <xref target="RFC8273" format="default" sectionFormat="of" derivedContent="RFC8273"/> or <xref target="RFC9663" format="default" sectionFormat="of" derivedContent="RFC9663"/>.</t>
            </li>
            <li pn="section-4.2.1-4.5" derivedCounter="5.">
              <t indent="0" pn="section-4.2.1-4.5.1">A large number of router interfaces may be needed:</t>
              <t indent="0" pn="section-4.2.1-4.5.2">If the P2P method is used, the router must instantiate a
              separate logical interface for every attached host. In this
              case, a large number of interfaces will be needed at the
              router.</t>
            </li>
            <li pn="section-4.2.1-4.6" derivedCounter="6.">
              <t indent="0" pn="section-4.2.1-4.6.1">Router as a bottleneck:</t>
              <t indent="0" pn="section-4.2.1-4.6.2">Since all communication between hosts is routed through the
              router, the router may become a performance bottleneck in
              high-traffic scenarios.</t>
            </li>
            <li pn="section-4.2.1-4.7" derivedCounter="7.">
              <t indent="0" pn="section-4.2.1-4.7.1">Incompatibility with host-based multicast services:</t>
              <t indent="0" pn="section-4.2.1-4.7.2">Services that rely on multicast communication among hosts,
              such as the Multicast Domain Name System <xref target="RFC6762" format="default" sectionFormat="of" derivedContent="RFC6762"/>,
              will be disrupted.</t>
            </li>
          </ol>
        </section>
        <section anchor="applicability-of-l3-isolation" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.2">
          <name slugifiedName="name-applicability-of-l3-isolati">Applicability of L3 Isolation</name>
          <t indent="0" pn="section-4.2.2-1">Benefits:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.2-2">
            <li pn="section-4.2.2-2.1">
              <t indent="0" pn="section-4.2.2-2.1.1">All ND issues (<xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/>) are mitigated, with the exception
    of:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.2-2.1.2">
                <li pn="section-4.2.2-2.1.2.1">LLA DAD multicast degrades performance,</li>
                <li pn="section-4.2.2-2.1.2.2">LLA DAD not reliable in wireless networks, and</li>
                <li pn="section-4.2.2-2.1.2.3">on-link security.</li>
              </ul>
              <t indent="0" pn="section-4.2.2-2.1.3">
   These remaining issues depend on the characteristics of the
   shared medium:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.2-2.1.4">
                <li pn="section-4.2.2-2.1.4.1">If the shared medium is Ethernet, the issues related to LLA
         DAD multicast are negligible.</li>
                <li pn="section-4.2.2-2.1.4.2">If nodes can be trusted, such as in private networks, on-link security concerns are not significant.</li>
              </ul>
            </li>
            <li pn="section-4.2.2-2.2">There is no need for L2 Isolation. Consequently, this method can be
    applied in a wide range of scenarios, making it possibly the
    most practical host isolation method.</li>
          </ul>
          <t indent="0" pn="section-4.2.2-3">Constraints (as discussed in <xref target="applicability-of-l3l2-isolation" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>):</t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.2.2-4"><li pn="section-4.2.2-4.1" derivedCounter="1.">
              <t indent="0" pn="section-4.2.2-4.1.1">Unique prefix allocation</t>
            </li>
            <li pn="section-4.2.2-4.2" derivedCounter="2.">
              <t indent="0" pn="section-4.2.2-4.2.1">Router support for L3 Isolation</t>
            </li>
            <li pn="section-4.2.2-4.3" derivedCounter="3.">
              <t indent="0" pn="section-4.2.2-4.3.1">Router as a bottleneck</t>
            </li>
            <li pn="section-4.2.2-4.4" derivedCounter="4.">
              <t indent="0" pn="section-4.2.2-4.4.1">Privacy issue from unique prefix identifiability</t>
            </li>
          </ol>
        </section>
        <section anchor="applicability-of-partial-l2-isolation" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.3">
          <name slugifiedName="name-applicability-of-partial-l2">Applicability of Partial L2 Isolation</name>
          <t indent="0" pn="section-4.2.3-1">Benefit:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.3-2">
            <li pn="section-4.2.3-2.1">Reduced multicast traffic: This method reduces multicast
	    traffic, particularly for address resolution, by dividing the
	    subnet into multiple multicast domains.</li>
          </ul>
          <t indent="0" pn="section-4.2.3-3">Constraint:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.3-4">
            <li pn="section-4.2.3-4.1">Router support for Partial L2 Isolation:
          The router must implement a Partial L2 Isolation solution such as
   WiND, SARP, ND optimization for TRILL, and Proxy ND in EVPN to
   support this method.</li>
          </ul>
        </section>
      </section>
      <section anchor="guidelines-for-applying-isolation-methods" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-guidelines-for-applying-iso">Guidelines for Applying Isolation Methods</name>
        <t indent="0" pn="section-4.3-1">Based on the applicability analysis provided in the preceding
   sections, network administrators can determine whether to implement
   an isolation method and, if so, which method is most appropriate for
   their specific deployment.</t>
        <t indent="0" pn="section-4.3-2">A simple guideline is to consider the isolation methods in the order
   listed in the preceding sections, progressing from the strongest
   isolation to the weakest:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-3">
          <li pn="section-4.3-3.1">Stronger isolation methods can prevent more ND issues, but may
    also impose higher entry requirements.</li>
          <li pn="section-4.3-3.2">Weaker isolation methods have fewer entry requirements but may
    leave some ND issues unmitigated.</li>
        </ul>
        <t indent="0" pn="section-4.3-4">The choice between L3+L2 Isolation and L3 Isolation often depends on
   the cost of implementing L2 Isolation:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-5">
          <li pn="section-4.3-5.1">If the cost is acceptable, L3+L2 Isolation is preferable
    because it eliminates every ND issue listed in <xref target="summary-of-nd-issues" format="default" sectionFormat="of" derivedContent="Section 2.4"/>.</li>
          <li pn="section-4.3-5.2">Otherwise, L3 Isolation addresses most of those issues while
    keeping the implementation effort reasonable.</li>
        </ul>
        <t indent="0" pn="section-4.3-6">Selecting an isolation method that is either too strong or too weak
   does not result in serious consequences:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-7">
          <li pn="section-4.3-7.1">Choosing an overly strong isolation method may require the
    network administrator to meet higher entry requirements
    initially, such as measures for L2 Isolation, additional
    prefixes, or additional router capabilities.</li>
          <li pn="section-4.3-7.2">Choosing a weaker isolation method may necessitate deploying
    supplemental ND mitigation techniques to address any unresolved
    ND issues.</li>
        </ul>
        <t indent="0" pn="section-4.3-8">In either case, the resulting solution can be functional and
   effective.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">This document is a review of known ND issues and solutions,
   including security. It does not introduce any new solutions.
   Therefore, it does not introduce new security issues.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <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" pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4861" quoteTitle="true" derivedAnchor="RFC4861">
          <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"/>
            <author fullname="H. Soliman" initials="H." surname="Soliman"/>
            <date month="September" year="2007"/>
            <abstract>
              <t indent="0">This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other'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/rfc4862" quoteTitle="true" derivedAnchor="RFC4862">
          <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 indent="0">This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify 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 anchor="sec-informative-references" pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ccc-v6ops-address-accountability" target="https://datatracker.ietf.org/doc/html/draft-ccc-v6ops-address-accountability-00" quoteTitle="true" derivedAnchor="AddrAcc">
          <front>
            <title>IPv6 Address Accountability Considerations</title>
            <author fullname="Tim Chown" initials="T." surname="Chown">
              <organization showOnFrontPage="true">Jisc</organization>
            </author>
            <author fullname="Chris Cummings" initials="C." surname="Cummings">
              <organization showOnFrontPage="true">Energy Sciences Network</organization>
            </author>
            <author fullname="Dale W. Carder" initials="D. W." surname="Carder">
              <organization showOnFrontPage="true">ESnet</organization>
            </author>
            <date day="21" month="October" year="2024"/>
            <abstract>
              <t indent="0">Hosts in IPv4 networks typically acquire addresses by use of DHCP, and retain that address and only that address while the DHCP lease remains valid. In IPv6 networks, hosts may use DHCPv6, but may instead autoconfigure their own global address(es), and potentially use many privacy addresses over time. This behaviour places an additional burden on network operators who require address accountability for their users and devices. There has been some discussion of 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-accountability-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC9797" target="https://www.rfc-editor.org/info/rfc9797" quoteTitle="true" derivedAnchor="MADINAS">
          <front>
            <title>Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases</title>
            <author fullname="J. Henry" initials="J." surname="Henry"/>
            <author fullname="Y. Lee" initials="Y." surname="Lee"/>
            <date month="June" year="2025"/>
            <abstract>
              <t indent="0">To limit the privacy issues created by the association between a device, its traffic, its location, and its user in IEEE 802 networks, client vendors and client OS vendors have started implementing Media Access Control (MAC) address randomization. This technology is particularly important in Wi-Fi networks (defined in IEEE 802.11) 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 purpose of MAC address randomization.</t>
              <t indent="0">This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines some existing frameworks that maintain user privacy while preserving user quality of experience and network operation efficiency.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9797"/>
          <seriesInfo name="DOI" value="10.17487/RFC9797"/>
        </reference>
        <reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026" quoteTitle="true" derivedAnchor="RFC2026">
          <front>
            <title>The Internet Standards Process -- Revision 3</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="October" year="1996"/>
            <abstract>
              <t indent="0">This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the 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 discussion 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="RFC2461" target="https://www.rfc-editor.org/info/rfc2461" quoteTitle="true" derivedAnchor="RFC2461">
          <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 indent="0">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/rfc2462" quoteTitle="true" derivedAnchor="RFC2462">
          <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 indent="0">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="RFC3587" target="https://www.rfc-editor.org/info/rfc3587" quoteTitle="true" derivedAnchor="RFC3587">
          <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 indent="0">This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3587"/>
          <seriesInfo name="DOI" value="10.17487/RFC3587"/>
        </reference>
        <reference anchor="RFC3756" target="https://www.rfc-editor.org/info/rfc3756" quoteTitle="true" derivedAnchor="RFC3756">
          <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 indent="0">The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. 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 provides 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/rfc3971" quoteTitle="true" derivedAnchor="RFC3971">
          <front>
            <title>SEcure Neighbor Discovery (SEND)</title>
            <author fullname="J. Arkko" initials="J." role="editor" surname="Arkko"/>
            <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 indent="0">IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, 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, these 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/rfc3972" quoteTitle="true" derivedAnchor="RFC3972">
          <front>
            <title>Cryptographically Generated Addresses (CGA)</title>
            <author fullname="T. Aura" initials="T." surname="Aura"/>
            <date month="March" year="2005"/>
            <abstract>
              <t indent="0">This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically 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 the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification 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="RFC4193" target="https://www.rfc-editor.org/info/rfc4193" quoteTitle="true" derivedAnchor="RFC4193">
          <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 indent="0">This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4193"/>
          <seriesInfo name="DOI" value="10.17487/RFC4193"/>
        </reference>
        <reference anchor="RFC4389" target="https://www.rfc-editor.org/info/rfc4389" quoteTitle="true" derivedAnchor="RFC4389">
          <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 indent="0">Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. This memo defines an Experimental 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/rfc4429" quoteTitle="true" derivedAnchor="RFC4429">
          <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 indent="0">Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4429"/>
          <seriesInfo name="DOI" value="10.17487/RFC4429"/>
        </reference>
        <reference anchor="RFC4903" target="https://www.rfc-editor.org/info/rfc4903" quoteTitle="true" derivedAnchor="RFC4903">
          <front>
            <title>Multi-Link Subnet Issues</title>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <date month="June" year="2007"/>
            <abstract>
              <t indent="0">There have been several proposals around the notion that a subnet 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 provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4903"/>
          <seriesInfo name="DOI" value="10.17487/RFC4903"/>
        </reference>
        <reference anchor="RFC5517" target="https://www.rfc-editor.org/info/rfc5517" quoteTitle="true" derivedAnchor="RFC5517">
          <front>
            <title>Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment</title>
            <author fullname="S. HomChaudhuri" initials="S." surname="HomChaudhuri"/>
            <author fullname="M. Foschiano" initials="M." surname="Foschiano"/>
            <date month="February" year="2010"/>
            <abstract>
              <t indent="0">This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such a mechanism 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 indent="0">Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the-home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. This document is not an Internet Standards 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="RFC6085" target="https://www.rfc-editor.org/info/rfc6085" quoteTitle="true" derivedAnchor="RFC6085">
          <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 indent="0">When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link-layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6085"/>
          <seriesInfo name="DOI" value="10.17487/RFC6085"/>
        </reference>
        <reference anchor="RFC6105" target="https://www.rfc-editor.org/info/rfc6105" quoteTitle="true" derivedAnchor="RFC6105">
          <front>
            <title>IPv6 Router Advertisement Guard</title>
            <author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abegnoli"/>
            <author fullname="G. Van de Velde" initials="G." surname="Van de Velde"/>
            <author fullname="C. Popoviciu" initials="C." surname="Popoviciu"/>
            <author fullname="J. Mohacsi" initials="J." surname="Mohacsi"/>
            <date month="February" year="2011"/>
            <abstract>
              <t indent="0">Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6105"/>
          <seriesInfo name="DOI" value="10.17487/RFC6105"/>
        </reference>
        <reference anchor="RFC6459" target="https://www.rfc-editor.org/info/rfc6459" quoteTitle="true" derivedAnchor="RFC6459">
          <front>
            <title>IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet 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 indent="0">The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6459"/>
          <seriesInfo name="DOI" value="10.17487/RFC6459"/>
        </reference>
        <reference anchor="RFC6575" target="https://www.rfc-editor.org/info/rfc6575" quoteTitle="true" derivedAnchor="RFC6575">
          <front>
            <title>Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs</title>
            <author fullname="H. Shah" initials="H." role="editor" surname="Shah"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="G. Heron" initials="G." role="editor" surname="Heron"/>
            <author fullname="V. Kompella" initials="V." role="editor" surname="Kompella"/>
            <date month="June" year="2012"/>
            <abstract>
              <t indent="0">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 general, 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. However, 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 connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this 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/rfc6583" quoteTitle="true" derivedAnchor="RFC6583">
          <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 indent="0">In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.</t>
              <t indent="0">This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate 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="RFC6762" target="https://www.rfc-editor.org/info/rfc6762" quoteTitle="true" derivedAnchor="RFC6762">
          <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 indent="0">As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</t>
              <t indent="0">Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</t>
              <t indent="0">The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6762"/>
          <seriesInfo name="DOI" value="10.17487/RFC6762"/>
        </reference>
        <reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc6775" quoteTitle="true" derivedAnchor="RFC6775">
          <front>
            <title>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
            <author fullname="Z. Shelby" initials="Z." role="editor" surname="Shelby"/>
            <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 indent="0">The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6775"/>
          <seriesInfo name="DOI" value="10.17487/RFC6775"/>
        </reference>
        <reference anchor="RFC6957" target="https://www.rfc-editor.org/info/rfc6957" quoteTitle="true" derivedAnchor="RFC6957">
          <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 indent="0">The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used 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 rather 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/rfc7039" quoteTitle="true" derivedAnchor="RFC7039">
          <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 indent="0">Source Address Validation Improvement (SAVI) methods were developed 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, standardized IP source address validation. This document is a framework document that describes 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="RFC7066" target="https://www.rfc-editor.org/info/rfc7066" quoteTitle="true" derivedAnchor="RFC7066">
          <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="Arkko"/>
            <author fullname="T. Savolainen" initials="T." surname="Savolainen"/>
            <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
            <date month="November" year="2013"/>
            <abstract>
              <t indent="0">As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular 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 referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating 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="RFC7102" target="https://www.rfc-editor.org/info/rfc7102" quoteTitle="true" derivedAnchor="RFC7102">
          <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 indent="0">This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, 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="RFC7113" target="https://www.rfc-editor.org/info/rfc7113" quoteTitle="true" derivedAnchor="RFC7113">
          <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 indent="0">The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7113"/>
          <seriesInfo name="DOI" value="10.17487/RFC7113"/>
        </reference>
        <reference anchor="RFC7278" target="https://www.rfc-editor.org/info/rfc7278" quoteTitle="true" derivedAnchor="RFC7278">
          <front>
            <title>Extending an IPv6 /64 Prefix from a Third Generation Partnership 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 indent="0">This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface 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="RFC7342" target="https://www.rfc-editor.org/info/rfc7342" quoteTitle="true" derivedAnchor="RFC7342">
          <front>
            <title>Practices for Scaling ARP and Neighbor Discovery (ND) in Large 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 indent="0">This memo documents some operational practices that allow ARP and 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="RFC7527" target="https://www.rfc-editor.org/info/rfc7527" quoteTitle="true" derivedAnchor="RFC7527">
          <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 indent="0">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 suppress looped back DAD messages, a software solution is required. Several service provider 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 Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862.</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/rfc7586" quoteTitle="true" derivedAnchor="RFC7586">
          <front>
            <title>The Scalable Address Resolution Protocol (SARP) for Large Data 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 indent="0">This document introduces the Scalable Address Resolution Protocol (SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering 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 VLAN) 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/rfc7772" quoteTitle="true" derivedAnchor="RFC7772">
          <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 indent="0">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/rfc8273" quoteTitle="true" derivedAnchor="RFC8273">
          <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 Velde"/>
            <date month="December" year="2017"/>
            <abstract>
              <t indent="0">This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced 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/rfc8302" quoteTitle="true" derivedAnchor="RFC8302">
          <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 3rd"/>
            <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 indent="0">This document describes mechanisms to optimize the Address Resolution Protocol (ARP) and Neighbor Discovery (ND) traffic in a Transparent Interconnection of Lots of Links (TRILL) campus. TRILL switches maintain a cache of IP / Media Access Control (MAC) address / Data Label bindings that are learned from ARP/ND requests and responses that pass through them. In many cases, this cache allows an edge Routing Bridge (RBridge) to avoid flooding an ARP/ND request by either responding to it directly or encapsulating it and unicasting it. Such optimization 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="RFC8415" target="https://www.rfc-editor.org/info/rfc8415" quoteTitle="true" derivedAnchor="RFC8415">
          <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 indent="0">This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).</t>
              <t indent="0">This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions 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="RFC8505" target="https://www.rfc-editor.org/info/rfc8505" quoteTitle="true" derivedAnchor="RFC8505">
          <front>
            <title>Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <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 indent="0">This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor 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/rfc8928" quoteTitle="true" derivedAnchor="RFC8928">
          <front>
            <title>Address-Protected Neighbor Discovery for Low-Power and Lossy Networks</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <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 indent="0">This document updates the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 and 8505. The new extension is called Address-Protected Neighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power and Lossy Network (LLN). Nodes supporting this extension 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 Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, 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/rfc8929" quoteTitle="true" derivedAnchor="RFC8929">
          <front>
            <title>IPv6 Backbone Router</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <author fullname="C.E. Perkins" initials="C.E." surname="Perkins"/>
            <author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abegnoli"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate 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="RFC9099" target="https://www.rfc-editor.org/info/rfc9099" quoteTitle="true" derivedAnchor="RFC9099">
          <front>
            <title>Operational Security Considerations for IPv6 Networks</title>
            <author fullname="É. Vyncke" surname="É. Vyncke"/>
            <author fullname="K. Chittimaneni" initials="K." surname="Chittimaneni"/>
            <author fullname="M. Kaeo" initials="M." surname="Kaeo"/>
            <author fullname="E. Rey" initials="E." surname="Rey"/>
            <date month="August" year="2021"/>
            <abstract>
              <t indent="0">Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices.</t>
              <t indent="0">This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise 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="RFC9119" target="https://www.rfc-editor.org/info/rfc9119" quoteTitle="true" derivedAnchor="RFC9119">
          <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 indent="0">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 been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be made to improve the performance of the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9119"/>
          <seriesInfo name="DOI" value="10.17487/RFC9119"/>
        </reference>
        <reference anchor="RFC9131" target="https://www.rfc-editor.org/info/rfc9131" quoteTitle="true" derivedAnchor="RFC9131">
          <front>
            <title>Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers</title>
            <author fullname="J. Linkova" initials="J." surname="Linkova"/>
            <date month="October" year="2021"/>
            <abstract>
              <t indent="0">Neighbor Discovery (RFC 4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document updates RFC 4861 to allow routers to proactively create a Neighbor Cache entry when a new IPv6 address is assigned to a node. It also updates RFC 4861 and recommends that nodes send unsolicited Neighbor Advertisements upon assigning a new IPv6 address. These changes will minimize 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/rfc9161" quoteTitle="true" derivedAnchor="RFC9161">
          <front>
            <title>Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks</title>
            <author fullname="J. Rabadan" initials="J." role="editor" surname="Rabadan"/>
            <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 indent="0">This document describes the Ethernet Virtual Private Network (EVPN) Proxy ARP/ND function augmented by the capability of the ARP/ND Extended Community. From that perspective, this document updates the EVPN specification to provide more comprehensive documentation of the operation of the Proxy ARP/ND function. The EVPN Proxy ARP/ND function and the ARP/ND Extended Community help operators 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/rfc9663" quoteTitle="true" derivedAnchor="RFC9663">
          <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="Linkova"/>
            <author fullname="X. Ma" initials="X." role="editor" surname="Ma"/>
            <date month="October" year="2024"/>
            <abstract>
              <t indent="0">This document discusses an IPv6 deployment scenario when individual nodes connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegation (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="RFC9686" target="https://www.rfc-editor.org/info/rfc9686" quoteTitle="true" derivedAnchor="RFC9686">
          <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 indent="0">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="RIPE738" target="https://www.ripe.net/publications/docs/ripe-738" quoteTitle="true" derivedAnchor="RIPE738">
          <front>
            <title>IPv6 Address Allocation and Assignment Policy</title>
            <author>
              <organization showOnFrontPage="true">RIPE</organization>
            </author>
            <date month="03" year="2020"/>
          </front>
          <refcontent>RIPE-738</refcontent>
        </reference>
        <reference anchor="I-D.ietf-6man-ipv6-over-wireless" target="https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-over-wireless-09" quoteTitle="true" derivedAnchor="SND">
          <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="Richardson">
              <organization showOnFrontPage="true">Sandelman Software Works</organization>
            </author>
            <date day="9" month="November" year="2025"/>
            <abstract>
              <t indent="0">This document presents an architecture and framework for IPv6 access networks that decouples the network-layer concepts of Links, Interface, and Subnets from the link-layer concepts of links, ports, and broadcast domains, and limits the reliance on link-layer broadcasts. This architecture is suitable for IPv6 over any network, including non-broadcast networks, which is typically the case for intangible media such as wireless and virtual networks such as overlays. 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-wireless-09"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="TR177" target="https://www.broadband-forum.org/pdfs/tr-177-1-0-1.pdf" quoteTitle="true" derivedAnchor="TR177">
          <front>
            <title>IPv6 in the context of TR-101</title>
            <author>
              <organization showOnFrontPage="true">Broadband Forum</organization>
            </author>
            <date month="11" year="2017"/>
          </front>
          <refcontent>TR-177</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgements" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Éric Vyncke"/>,
      <contact fullname="Gunter Van de Velde"/>, <contact fullname="Lorenzo       Colitti"/>, <contact fullname="Erik Kline"/>, <contact fullname="Warren       Kumari"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Gorry Fairhurst"/>, <contact fullname="Pascal Thubert"/>,
      <contact fullname="Jen Linkova"/>, <contact fullname="Brian       Carpenter"/>, <contact fullname="Mike Ackermann"/>, <contact fullname="Nalini Elkins"/>, <contact fullname="Ed Horley"/>, <contact 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 anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="XiPeng Xiao">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <email>xipengxiao@huawei.com</email>
        </address>
      </author>
      <author fullname="Eduard Vasilenko">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <email>vasilenko.eduard@huawei.com</email>
        </address>
      </author>
      <author fullname="Eduard Metz">
        <organization showOnFrontPage="true">KPN N.V.</organization>
        <address>
          <email>eduard.metz@kpn.com</email>
        </address>
      </author>
      <author fullname="Gyan Mishra">
        <organization showOnFrontPage="true">Verizon Inc.</organization>
        <address>
          <email>gyan.s.mishra@verizon.com</email>
        </address>
      </author>
      <author fullname="Nick Buraglio">
        <organization showOnFrontPage="true">Energy Sciences Network</organization>
        <address>
          <email>buraglio@es.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
