[Idr] Re: WG last call and IPR call for draft-ietf-idr-linklocal-capability (May 13, 2026 to May 27, 2026)

[Donatas Abraitis <[e-mail]>]

Thank you for the feedback.

I doubt for "4. Section 9 missing ND security context". We already had a
discussion about kinda this sort of thing and decided to avoid
ND/reachability stuff inside this document (it's kinda related, but not
really to the problem we are trying to solve here).

I addressed all other comments here =>
https://github.com/ietf-wg-idr/draft-ietf-idr-linklocal-capability/pull/35,
does it look good to you?

On Wed, May 27, 2026 at 10:37 PM satya praveen kumar pasalapudi <
[e-mail]> wrote:

> Hi Jie and Authors,
>
> I am not aware of any IPR related to this draft.
>
> Comments below from an implementation perspective.
> Support publication, with the following points I would like to see
> addressed:
>
> 1. Interaction with RFC 8950 (IPv4 NLRI with IPv6 Next Hop)
>
> -------------------------------------------------------------------------------
> RFC 8950 Section 3 requires the Next Hop field to be 32 octets -- a
> global-or-unspecified address followed by a link-local -- whenever
> IPv4 NLRI is carried with an IPv6 Next Hop.
> Section 3 of this draft introduces a 16-octet link-local-only encoding
> that directly contradicts that requirement.
>
> The draft does not address this interaction. Implementations will diverge.
> Would suggest adding an explicit subsection in Section 4 stating that
> when both this capability and RFC 8950 have been negotiated, a
> 16-octet link-local-only Next Hop is permitted for IPv4 NLRI to a
> directly attached peer.
> Otherwise RFC 8950 Section 3 rules apply unchanged.
>
>
> 2. Receiver-side classification of the 16-octet Next Hop field
>
> ----------------------------------------------------------------------------------
> A length=16 Next Hop may now carry either a Global (per RFC 2545) or a
> Link-Local Next Hop.
> Receivers must disambiguate by inspecting the address, but Section 3
> does not say so normatively.
> The behavior when capability 77 has not been negotiated and a 16-octet
> link-local Next Hop is received is undefined.
>
> Suggested text, after the second paragraph of Section 3:
>
>     A BGP speaker receiving an MP_REACH_NLRI with the Next Hop field
> length set to 16 SHALL classify the address as follows.
>     If the address is in fe80::/10, the Next Hop is a Link-Local-only
> Next Hop as defined in this document, and the Link-Local Next Hop
>     Capability MUST have been negotiated; if it has not, the
> implementation MUST handle the message using the approach of
>     "treat-as-withdraw" (Section 2 of [RFC7606]). Otherwise, the
> address is treated as a Global IPv6 Next Hop per [RFC2545].
>
> 3. Link-Local address lifecycle is not addressed
> --------------------------------------------------------------------
> The draft treats a Link-Local address as a stable property of an
> interface for the lifetime of a BGP session.
> >From an IPv6 stack perspective this is not generally true: operator
> reconfiguration can alter an interface's Link-Local while a session is
> up.
>
> The observable consequences include TCP socket invalidation, stale
> Neighbor Cache entries on peers, and stale third-party Link-Local
> Next Hops on peers that learned the route via re-advertisement.
> These should be acknowledged in the draft.
>
> I would suggest a sentence in Section 1 noting that Link-Local
> addresses are not required to be stable across interface bring-up or
> reconfiguration, and that a change triggers session reset and normal
> re-advertisement.
> Speakers SHOULD NOT advertise a Link-Local address in the IPv6
> tentative state (RFC 4862 Section 5.4).
>
> 4. Section 9 missing ND security context
> --------------------------------------------------------------------
> This capability increases reliance on ND for data-plane forwarding,
> since Link-Local Next Hops are resolved via ND on the bound
> interface rather than via recursive RIB resolution. ND spoofing on a
> shared layer-2 segment can therefore redirect data-plane traffic.
> Section 9 does not mention this or the associated mitigations (SEND
> [RFC3971] or infrastructure-layer ND inspection).
>
> Additionally, the security boundary moves from L3 (where Global Next
> Hops can be filtered at routed boundaries) to L2 (where protection
> depends on per-link controls). Section 9 should acknowledge both the
> ND exposure and this shift.
>
> 5. Graceful Restart interaction
> --------------------------------------------------------------------
> Graceful Restart (RFC 4724) is not addressed in -05. If a Restarting
> Speaker's Link-Local address changes during restart (configured vs.
> running Link-Local mismatch across restart), peers retaining its
> routes as stale will have those routes pointing to the previous
> Link-Local.
> ND resolution fails and forwarding is silently lost until the Restart
> Time expires or new advertisements propagate.
>
> Unlike global next hops, where routing may provide alternative
> reachability, link-local next hops are resolved purely via ND on the
> bound interface -- there is no routing fallback.
>
> A paragraph in Section 6 noting this interaction, or an explicit
> statement that this combination is out of scope, would close the gap.
>
>
> Rgds,
> Satya Praveen Kumar Pasalapudi,
> HPE
> [e-mail]
>
>
>
>
> On Tue, May 12, 2026 at 11:31 PM Dongjie (Jimmy)
> <jie.dong=[e-mail]> wrote:
> >
> > This begins a 2-week working group last call for
> draft-ietf-idr-linklocal-capability-04. This WG last call ends on May 27th,
> 2026.
> >
> >
> >
> > https://datatracker.ietf.org/doc/draft-ietf-idr-linklocal-capability
> >
> >
> >
> > Please review and provide feedbacks to this last call with an indication
> of “Support” or “Not Support”. For “Not support”, it is appreciated to also
> give explanations and suggestions to resolve them.
> >
> >
> >
> > For the purposes of the shepherd's report and according to IETF BCP
> 78/79, the authors are requested to declare whether they are aware of any
> undisclosed IPR covering this draft. Members of the working group are
> similarly obligated to report any IPR they are aware of as well.
> >
> >
> >
> > Best regards,
> >
> > Jie (as WG secretary & document shepherd)
> >
> >
> >
> > _______________________________________________
> > Idr mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 
Donatas