<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema
      validation and schema-aware editing --> 
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> --> 
<!-- This third-party XSLT can be enabled for direct transformations
in XML processors, including most browsers --> 

<!DOCTYPE rfc [
  <!ENTITY filename "draft-eastlake-lldp-mac-02">
  <!ENTITY nbsp   "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be
added to the DOCTYPE above. Use of an external entity file is not
recommended. --> 
<?rfc strict="yes" ?>
<?rfc toc="yes"?>

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="&filename;"
  ipr="trust200902"
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">
<!-- 
    * docName should be the name of your draft * category should be
    one of std, bcp, info, exp, historic * ipr should be one of
    trust200902, noModificationTrust200902, noDerivativesTrust200902,
    pre5378Trust200902 * updates can be an RFC number as NNNN *
    obsoletes can be an RFC number as NNNN
-->


<!-- ____________________FRONT_MATTER____________________ -->
<front>
  <title abbrev="L3 LLDP MAC Address">MAC Address for Layer 3 Link
  Local Discovery Protocol (LLDP)</title>
   <!--  The abbreviated title is required if the full title is
        longer than 39 characters --> 

   <seriesInfo name="Internet-Draft"
               value="&filename;"/>

   <author fullname="Donald E. Eastlake 3rd" initials="D."
           surname="Eastlake">
     <organization>Independent</organization>
     <address>
       <postal>
         <street>2386 Panoramic Circle</street>
         <city>Apopka</city>
         <region>Florida</region>
         <code>32703</code>
         <country>USA</country>
       </postal>        
       <phone>+1-508-333-2270</phone>
       <email>d3e3e3@gmail.com</email>
     </address>
   </author>

   <date year="2024" month="6" day="17"/>

   <area></area>
   <workgroup>Network Working Group</workgroup>
   <!-- "Internet Engineering Task Force" is fine for individual
        submissions.  If this element is not present, the default is
        "Network Working Group", which is used by the RFC Editor as a
        nod to the history of the RFC Series. --> 

   <keyword></keyword>
   <!-- Multiple keywords are allowed.  Keywords are incorporated
        into HTML output files for use by search engines. --> 

<abstract>
  <t>IEEE 802 has defined a number of protocols which can operate
  between adjacent Ethernet stations at Layer 2, including bridges,
  and may be useful between Layer 3 aware stations such as IP routers
  and hosts. An example is the Link Layer Discover Protocol (IEEE Std
  802.1AB, LLDP). This document specifies a MAC address that can be
  used for this purpose for interoperability despite intervening
  bridges.</t>
</abstract>
 
</front>


<!-- ____________________MIDDLE_MATTER____________________ -->
<middle>
    
<section>  <!-- 1. -->
  <name>Introduction</name>

<t>IEEE 802 <xref target="IEEE802"/> has defined a number of protocols
which operate between adjacent Ethernet stations at Layer 2, including
bridges, such as the Link Layer Discover Protocol (<xref
target="IEEE802.1AB"/> LLDP) and the Link Aggregation Control Protocol
(<xref target="IEEE802.1AX"/> LACP). LLDP and other such protocols may
be useful between adjacent Layer 3 <xref target="ISO"/> aware stations
such as IP routers and hosts. This document specifies a MAC address
that can be used for that purpose despite intervening bridges.</t>

<section>  <!-- 1.1 -->
  <name>Notations Used in This Document</name>
  
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>

<t>In this document the terms/acronyms listed below have the indicated
meaning:</t>

<dl>
  <dt>"LACP"</dt><dd>Link Aggregation Control Protocol <xref
  target="IEEE802.1AX"/>.</dd>

  <dt>"Layer 2"</dt><dd>Layer 2 in the ISO model <xref
  target="ISO"/>.</dd>

  <dt>"Layer 3"</dt><dd>Layer 3 in the ISO model <xref
  target="ISO"/>.</dd>

  <dt>"LLDP"</dt><dd>Link Layer Discovery Protocol <xref
  target="IEEE802.1AB"/>.</dd>

  <dt>"MAC"</dt><dd>Media Access Control <xref target="RFC9542"/>
  (not Message Authentication Code).</dd>

  <dt>"PDU"</dt><dd>Protocol Data Unit.</dd>
</dl>

</section>
</section> <!-- 1. -->

<section>  <!-- 2. -->
  <name>Network Layers and MAC Addresses</name>

  <t>LLDP <xref target="IEEE802.1AB"/> is a Layer 2 <xref
  target="ISO"/> protocol providing for the unacknowledged
  announcement of information by an Ethernet station to other stations
  on the same Ethernet link.  There are proposals for the use of LLDP
  between L3 aware stations such as between a host and its first hop
  IP router or between IP adjacent routers. Examples are <xref
  target="LLDP1"/> <xref target="LLDP2"/> <xref target="LLDP3"/>.</t>

  <t>As illustrated in the figure below, uses of LLDP and similar
  protocols between Ethernet stations have a scope of adjacency
  controlled by the multicast destination MAC address <xref
  target="RFC9542"/> of the Ethernet frame used to transmit the
  LLDP PDU.</t>

  <ul>
    <li>Customer bridges use 0x0180C2000000 for LLDP and the
    like. Frames sent to that address are transparently forwarded
    through any lower level bridges, such as the provider bridges
    shown below. On the other hand, IP routers do not forward frames
    sent to unknown multicast addresses unless configured to do
    so. Thus, frames sent to this address by the customer bridge shown
    near the bottom of the figure will not reach either of the
    customer bridges shown higher up in the figure due to the
    intervening IP router.</li>

    <li>Provider bridges use 0x0180C2000008 for LLDP. Frames sent to
    that address are transparently forwarded by lower level bridges
    (not shown in the figure) and are blocked by higher level bridges,
    such as customer bridges. They are also blocked as described in
    the previous point by IP routers.</li>
  </ul>

  <t>LLDP or similar Ethernet frames intended to be between adjacent
  IP routers or between a host and its first hop IP router need to
  avoid use of a destination MAC address that might be intercepted by
  any intervening bridge. The multicast destination MAC addresses used
  by bridges are the block from 0x0180C2000000 to 0x0180C200003F but
  it would be best to be conservative and avoid all addresses from
  0x0180C2000000 to 0x0180C2FFFFFF.  An address meeting this criterion
  is specified in Section 3 below and its use is RECOMMENDED.</t>

  
<figure anchor="NetDiagram">
  <name>Geneve Header</name>
    <artwork type="ascii-art" align="center">
<![CDATA[
 +-------+
 |  Host |
 +-------+
     |
+---------+
|L3 Router|
+---------+
     .     \
     .      +---------------+
     .      |Customer Bridge|
     .      +---------------+
     .              :        \
     .              :         +---------------+
     .              :         |Provider Bridge|
     .              :         +---------------+
     .              :                |
     .              :         +---------------+
     .              :         |Provider Bridge|
     .              :         +---------------+
     .              :        /
     .      +---------------+
     .      |Customer Bridge|
     .      +---------------+
     .     /
+---------+
|L3 Router|
+---------+
     .     \
     .      +---------------+
     .      |Customer Bridge|
     .      +---------------+
     .     /
 +-------+
 |  Host |
 +-------+
]]>
    </artwork>
</figure>

<t indent="3">Note: The above figure is simplified. For example,
where one or two customer bridges or provider bridges are shown, there
could be zero or some larger number. There could also be one or more
bridges between the host shown at the top of the figure and its first
hop IP router. Only two levels of bridge are shown (customer and
provider) but <xref target="IEEE802.1Q"/> specifies additional levels
of bridges.</t>

</section>  <!-- 2. -->

<section anchor="IANA">  <!-- 3. -->
  <name>IANA Considerations</name>
  
<t>IANA is requested to assign a 48-bit multicast MAC address
[0x00000E900004 suggested] under the IANA OUI for use with Link Layer
Discovery Protocol and similar protocols between Layer 3 routers as
per the request in Appendix A. The entry in the "IANA Multicast 48-bit
MAC Addresses" registry is as follows:</t>

<artwork type="ascii-art" align="center">
 Addresses   Usage                      Reference
---------  -------------------------  ---------------
 [tbd]     Layer 3 LLDP and the like  [this document]
</artwork>

<t>(Alternatively, there could be more than on MAC address assigned
for different L3 or higher layer <xref target="ISO"/> purposes.)</t>

</section> <!-- 3. -->

<section>  <!-- 4. -->
  <name>Security Considerations</name>

<t>TBD</t>

</section> <!-- end Security Considerations -->


</middle>


<!-- ____________________BACK_MATTER____________________ -->
<back>

<references>
  <name>Normative References</name>

  <reference anchor="IEEE802.1AB">
    <front>
      <title>IEEE Standard for Local and metropolitan area networks -
      Station and Media Access Control Connectivity Discovery</title>
      <author initials="IEEE" surname="802"/>
      <date day="29" month="January" year="2016"/>
    </front>
    <seriesInfo name="IEEE Std" value="802.1AB-2016"/>
</reference>

<xi:include
    href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>

<xi:include
    href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
<xi:include
    href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9542.xml"/>


</references>
 
<references>
  <name>Informative References</name>

<reference anchor="IEEE802.1AX">
  <front>
    <title>IEEE Standard for Local and metropolitan area networks -
    Link Aggregation</title>
    <author initials="IEEE" surname="802"/>
  </front>
  <seriesInfo name="IEEE Std" value="802.1AX-2014"/>
</reference>

<reference anchor="IEEE802.1Q">
  <front>
  <title>Bridges and Bridged Networks</title>
  <author initials="IEEE" surname="802.1 WG"
          fullname="IEEE 802.1 Working Group"> 
      <organization>Institute for Electrical and Electronic
      Engineers</organization>
  </author>
  <date year="2014" month="November" day="3"/>
  </front>
  <seriesInfo name="IEEE Std" value="802.1Q-2014"/>
</reference>

<reference anchor="IEEE802" target="http://www.ieee802.org">
  <front>
    <title>IEEE 802 LAN/MAN Standards Committee</title>
    <author initials="IEEE" surname="802"/>
  </front>
  <seriesInfo name="IEEE Std" value="802"/>
</reference>

<reference anchor="ISO">
  <front>
    <title>Information technology - Open Systems Interconnection -
    Basic Reference Model: The Basic Model</title>
    <author initials="" surname="ISO/IEC"/>
    <date day="15" month="June" year="1996"/>
  </front>
  <seriesInfo name="ISO/IEC" value="7498-1:1994(E)"/>
</reference>

<reference anchor="LLDP1"
	   target="https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-discovery/">
  <front>
    <title>BGP Logical
Link Discovery Protocol (LLDP) Peer Discovery</title>
    <author initials="A." surname="Lindem"/>
    <author initials="K." surname="Patel"/>
    <author initials="S." surname="Zandi"/>
    <author initials="J." surname="Haas"/>
    <author initials="X." surname="Xu"/>
  </front>
  <seriesInfo name="Work in" value="progress"/>
</reference>

<reference anchor="LLDP2"
	   target="https://datatracker.ietf.org/doc/draft-congdon-lsvr-lldp-tlvs/">
  <front>
    <title>LSVR IETF Organizationally Specific TLVs for IEEE Std
    802.1AB (LLDP)</title>
    <author initials="P." surname="Congdon"/>
    <author initials="P." surname="Bottorff"/>
  </front>
  <seriesInfo name="work in" value="progress"/>
</reference>

<reference anchor="LLDP3"
	   target="https://datatracker.ietf.org/doc/draft-richardson-anima-l2-friendly-acp/">
  <front>
    <title>Autonomic Control Plane design for Layer-Two Switched
    Networks</title>
    <author initials="M." surname="Richardson"/>
    <author initials="L." surname="Xia"/>
  </front>
  <seriesInfo name="Work in" value="progress"/>
</reference>

</references>

<section>  <!-- Appendix A -->
  <name> EUI-48 Assignment Request</name>

<t>(not yet submitted)</t>

<t>Applicant Name: Donald E. Eastlake III</t>

<t>Applicant Email: d3e3e3@gmail.com</t>

<t>Applicant Telephone: +1-508-333-2270</t>

<t>Use Name: L3-LLDP</t>

<t>Document: [this document]</t>

<t>Specify whether this is an application for EUI-48 or EUI-64
identifiers: EUI-48</t>

<t>Size of Block requested: 1</t>

<t>Specify multicast, unicast, or both: multicast</t>

</section>

</back>

</rfc>
