Skip to main content

Link Local Next Hop Handling for BGP

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Russ White , Donald Sharp , Dinesh Dutt , Biswajit Sadhu , Jeff Tantsura , Donatas Abraitis
Last updated 2022-05-11 (Latest revision 2021-11-07)
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


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.


Russ White
Donald Sharp
Dinesh Dutt
Biswajit Sadhu
Jeff Tantsura
Donatas Abraitis

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)