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

[satya praveen kumar pasalapudi <[e-mail]>]

Looks good. Thanks for taking care of the comments.

Rgds,
Praveen.


On Thu, May 28, 2026 at 4:41 AM Donatas Abraitis
<[e-mail]> wrote:
>
> 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