<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.white-linklocal-capability" target="https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability-00">
   <front>
      <title>Link-Local Next Hop Capability for BGP</title>
      <author initials="R." surname="White" fullname="Russ White">
         <organization>Juniper Networks</organization>
      </author>
      <author initials="D." surname="Abraitis" fullname="Donatas Abraitis">
         <organization>Hostinger</organization>
      </author>
      <date month="December" day="7" year="2021" />
      <abstract>
	 <t>   BGP, described in [RFC4271], was originally designed to provide
   reachability between domains and between the edges of a domain.  As
   such, BGP assumes the next hop towards any reachable destination may
   not reside on the advertising speaker, but rather may either be
   through a router connected to the same subnet as the speaker, or
   through a router only reachable by traversing multiple hops through
   the network.  Because of this, BGP does not recognize the use of IPv6
   link-local addresses, as described in [RFC4291], as a valid next hop
   for forwarding purposes.

   However, BGP speakers are now often deployed on point-to-point links
   in networks where multihop reachability of any kind is not assumed or
   desired (all next hops are assumed to be the speaker reachable
   through a directly connected point-to-point link).  This is common,
   for instance, in data center fabrics.  In these situations, a global
   IPv6 address is not required for the advertisement of reachability
   information; in fact, providing global IPv6 addresses in these kinds
   of networks can be detrimental to Zero Touch Provisioning (ZTP).

   This draft standardizes the operation of BGP over a point-to-point
   link using link-local IPv6 addressing only.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-white-linklocal-capability-00" />
   
</reference>
