The IDR Working Group, which standardizes BGP in the IETF, is doing last call for the linklocal capability feature.
IPv6-linklocal-only peering is a popular mechanism for some operators who want to avoid uniquely numbering links in network scenarios where the number is irrelevant. This is especially the case for things that are otherwise point to point links. Some people like these in data center use cases!
However, linklocal-only peering has been underspecified and buggy between implementations. This draft fixes that.
Please consider reviewing the draft and providing feedback to the working group mailing list.[1] This can be "yeah, it's ready to go" or "I see a problem here"...
https://datatracker.ietf.org/doc/draft-ietf-idr-linklocal-capability/

Link-Local Next Hop Capability for BGP
To support IPv6 [RFC4291] reachability, BGP [RFC4271] relies on the Multiprotocol Extensions as defined in [RFC4760]. [RFC2545] defines the structure of IPv6 next hops. These IPv6 next hops may contain a Global IPv6 address, and optionally can contain an IPv6 Link-Local address when the BGP peer is directly attached and shares a common subnet with the IPv6 Global address. This document updates [RFC2545] to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 Link-Local address is available. A new BGP Capability [RFC5492] is defined to signal support for this updated encoding. This clarification applies specifically to IPv6 Link-Local addresses and does not pertain to IPv4 Link-Local addresses as defined in [RFC3927].



