Subject: Re: [Idr] Link Local Next Hop Capability for BGP

From: Robert Raszuk <[email-masked]>
Date: Sat, 1 Jan 2022 13:48:00 +0100

> If it were desirable by operators to configure hardcoded intuitive LL
address

That would no longer be a link-local address - it would be a global
address. Per definition of IPv6 addressing architecture link local
addresses are automatically assigned as long as the interface comes up.
They have no meaning other than on a particular link.

With that there is no guarantee that two peers on differrent interfaces of
the same router will not assign the same LL addresses - and if that happens
and LL addresses is used as next hop that brings new requirements to next
hop validation procedure by BGP (mainly interface_id awareness). All
doable, but drastic departure from current practice and deployed code.

Also the draft while trying to say something about this in section 4 IMO
does not spell out this issue of LL next hop validation well enough.

Best,
R.

On Wed, Dec 29, 2021 at 1:28 AM Gyan Mishra <[email-masked]> wrote:

>
> Hi Donatas
>
> By default most vendors generate the LL via EUI64 MAC address with FFFE
> bit stuff.
>
> If it were desirable by operators to configure hardcoded intuitive LL
> address would there be any issue in the capabilities advertisement should
> pick up the configured LL?
>
> Also in BGP only DC fabrics where no IGP exists for recursion, however in
> NVO3 multi tiered fabrics where the leaf, spine and BL/BS nodes sit in the
> same AS with spine acting as RR, how would recursive routing work to the LL
> next hop attribute as the LL is only locally reachable?
>
> I think the standard next-hop-self rewrite to loopback routable would
> solve the recursive issue.  However maybe cases where the external peering
> link must have reachability for NMS telemetry or maybe other reasons.
>
> Other that that the draft looks sound and I support progressing.
>
> Kind Regards
>
> Gyan
>
>
> On Tue, Dec 28, 2021 at 4:12 AM Donatas Abraitis <
> [email-masked]> wrote:
>
>> Hi, folks!
>>
>> More and more issues come dealing with inter-operability handling IPv6
>> link-local next-hops. Especially it's tricky how to handle 32-bytes length
>> next-hops and every implementation handles this independently which makes
>> things even worse.
>>
>> Some open-source daemons set NH length to 32-bytes, but the global address
>> (GA) is set to `::`. How this should be handled correctly? In such a case,
>> a DUT device can be in trouble while setting next-hop at receiving side (if
>> global is preferred).
>>
>> If IPv6 GA does not exist, sending LL(LL) with 32-bytes is the correct way
>> or not again?
>>
>> Controversially, is it OKay sending GA(::) (I didn't see and even expect
>> this to happen, but...).
>>
>> Proposing a new BGP capability:
>> https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability
>>
>> It covers some cases where 32-bytes length next-hops and/or 16-bytes
>> link-local ONLY next-hops are sent/received.
>>
>> Waiting for comments!
>>
>> --
>> Donatas
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [email-masked] <[email-masked]>*
>
>
>
> *M 301 502-1347*
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 1 Jan 2022 13:46:15 -0500

Statically configured ipv6 link-local addresses are used by a number of operators.  How they get used is effectively a matter of religion.

You can find related discussion under RFC 4291 §2.5.1.

Most relevant to this discussion is that some operators will configure a given address with the expectation that collisions are fatal and stuff won't work properly when that happens.  In the absence of intentional configuration, IPv6 duplicate address detection procedures usually resolve the issue, although they introduce some ugliness in the timing of routing protocols coming up.

-- Jeff

> On Jan 1, 2022, at 7:48 AM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> > If it were desirable by operators to configure hardcoded intuitive LL address
> 
> That would no longer be a link-local address - it would be a global address. Per definition of IPv6 addressing architecture link local addresses are automatically assigned as long as the interface comes up. They have no meaning other than on a particular link. 
> 
> With that there is no guarantee that two peers on differrent interfaces of the same router will not assign the same LL addresses - and if that happens and LL addresses is used as next hop that brings new requirements to next hop validation procedure by BGP (mainly interface_id awareness). All doable, but drastic departure from current practice and deployed code. 
> 
> Also the draft while trying to say something about this in section 4 IMO does not spell out this issue of LL next hop validation well enough. 
> 
> Best,
> R.
> 
> 
> On Wed, Dec 29, 2021 at 1:28 AM Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Donatas
> 
> By default most vendors generate the LL via EUI64 MAC address with FFFE bit stuff.  
> 
> If it were desirable by operators to configure hardcoded intuitive LL address would there be any issue in the capabilities advertisement should pick up the configured LL?
> 
> Also in BGP only DC fabrics where no IGP exists for recursion, however in NVO3 multi tiered fabrics where the leaf, spine and BL/BS nodes sit in the same AS with spine acting as RR, how would recursive routing work to the LL next hop attribute as the LL is only locally reachable?  
> 
> I think the standard next-hop-self rewrite to loopback routable would solve the recursive issue.  However maybe cases where the external peering link must have reachability for NMS telemetry or maybe other reasons.
> 
> On Tue, Dec 28, 2021 at 4:12 AM Donatas Abraitis <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, folks!
> 
> https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability <https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> -- 
> Gyan Mishra
> Network Solutions Architect 
> Email [email-masked] <mailto:[email-masked]>
> M 301 502-1347
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 1 Jan 2022 14:13:21 -0500

Also relevant:
https://datatracker.ietf.org/doc/html/rfc7136 <https://datatracker.ietf.org/doc/html/rfc7136>

-- Jeff

> On Jan 1, 2022, at 1:46 PM, Jeffrey Haas <[email-masked]> wrote:
> 
>> On Jan 1, 2022, at 7:48 AM, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 1 Jan 2022 14:20:02 -0500

Hi Robert

Comments in-line

Happy New Year !!

> They have no meaning other than on a particular link.

    Gyan> Agreed.  The hardcoded LL was for eBGP or iBGP direct local
peering as LL is on-link and not iBGP peering.  Also for IGP when GUI used
on P2P links.  For IGP IPv6 processing can occur with a knob without IPv6
address using vendor knob which is helpful for deployments and there is an
RFC Jeff mentioned that helps with operations traceroute.

For non directly connected peers iBGP or eBGP multihop scenario, the next
hop rewrite “next-hop-self” of both GUI and LL solves the next hop having
to be unique and within the domain.  So there maybe cases where next hop
rewrite is not desirable and maintaining next hop unchanged over eBGP or
iBGP peering scenario and only for those BGP underlay scenario in NVO
overlay environment would we have a new requirement for BGP next hop
validation.

> doable, but drastic departure from current practice and deployed code.

Gya> By default all interfaces generate an EUI-64 FFFE bit stuff.  LL
address based on RFC 4291.  IPV6 DAD and optimistic DAD RFac 4429 runs to
ensure uniqueness for on-link as LL is local on-link relevant only so
uniqueness per RFC 4291 is only for on-link. Optimistic DAD allows the
interface IPv6 address to both LL and Global to be used once in new
“optimistic”  state before DAD is completed which is when the interface
IPv6 address becomes usable when it transitions to VALID state.  Optimistic
DAD updates RFC 4861 ND process and RFC 4862 SLAAC process for DAD to now
take into account optimistic state.  With DAD as LL is on-link directly
connected DAD only ensures the local next hop is unique so only applies to
directly connected local iBGP or eBGP peers.  By advertisement of LL within
the domain the LL it now must have at a minimum closed domain wide
uniqueness between all routes within that domain similar to global address.
  DAD only runs locally so there is no way to extend DAD process to support
domain wide uniqueness.   In your scenario DAD maintains uniqueness on a
link by link basis.  However DAD is not checking for uniqueness between
links between routers.  One solution could be to make this a requirement
for operators for next hop validation to ensure operators hardcode next hop
based on proper numbering plan to ensure uniqueness.  Another possibility
would be to routers to support random IID via privacy extension RFC 4941 or
RFC 7217 Semantically opaque IID based on stable IID RFC 8064.  Also now
all host OS by default do not use EUI64 MAC based and use Random IID so
that Random IID could be utilized and that could also reduce the
probability of collision.  We would still need BGP next hop validation to
ensure domain wide uniqueness.  When the BGP scanner runs best path
algorithm BGP next hop scan now it would have to check LL next hop
validity.  Checking the local IPv6 neighbor cache would not be enough.

I can run this by 6MAN to get there thoughts on this issue with
advertisement of LL next hop capability.

> does not spell out this issue of LL next hop validation well enough.

Gyan> Good point as this brings up new requirements for BGP next hop
validation procedure. I can help make that more clear as to problem and
also possible solutions described above.

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 1 Jan 2022 16:09:40 -0500

RFC 7136 deprecates the use of U/I 2 bits  in EUI-64 IID generation.
Basically the two bits can be used as don’t care for anything but are not
meant to signify unique or local semantics.  RFC 4291 is updated by this
RFC as far as EUI64 IID generation for both LL and Global addresses.

   The following statement in Section 2.5.1
<https://datatracker.ietf.org/doc/html/rfc7136#section-2.5.1> of the
IPv6 addressing architecture [RFC4291
<https://datatracker.ietf.org/doc/html/rfc4291>] is obsoleted:

      The use of the universal/local bit in the Modified EUI-64 format
      identifier is to allow development of future technology that can
      take advantage of interface identifiers with universal scope.

Kind Regards

Gyan

On Sat, Jan 1, 2022 at 2:13 PM Jeffrey Haas <[email-masked]> wrote:

> Also relevant:
> https://datatracker.ietf.org/doc/html/rfc7136
>
> -- Jeff
>
>
> Statically configured ipv6 link-local addresses are used by a number of
> operators.  How they get used is effectively a matter of religion.
>
> Most relevant to this discussion is that some operators will configure a
> given address with the expectation that collisions are fatal and stuff
> won't work properly when that happens.  In the absence of intentional
> configuration, IPv6 duplicate address detection procedures usually resolve
> the issue, although they introduce some ugliness in the timing of routing
> protocols coming up.
>
> -- Jeff
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Donatas Abraitis <[email-masked]>
Date: Tue, 25 Jan 2022 08:30:45 +0200

Folks,

I'm not much familiar with the flow actually, what should be the next step
by moving forward with this draft (or not moving)?

On Sat, Jan 1, 2022 at 11:10 PM Gyan Mishra <[email-masked]> wrote:

>    The following statement in Section 2.5.1 <https://datatracker.ietf.org/doc/html/rfc7136#section-2.5.1> of the IPv6 addressing architecture [RFC4291 <https://datatracker.ietf.org/doc/html/rfc4291>] is obsoleted:
>
>> With that there is no guarantee that two peers on differrent interfaces
>> of the same router will not assign the same LL addresses - and if that
>> happens and LL addresses is used as next hop that brings new requirements
>> to next hop validation procedure by BGP (mainly interface_id awareness).
>> All doable, but drastic departure from current practice and deployed code.
>>
>>> Also in BGP only DC fabrics where no IGP exists for recursion, however
>>> in NVO3 multi tiered fabrics where the leaf, spine and BL/BS nodes sit in
>>> the same AS with spine acting as RR, how would recursive routing work to
>>> the LL next hop attribute as the LL is only locally reachable?
>>>

-- 
Donatas

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Jan 2022 08:19:46 -0500

Donatas,

Sorry that the Chairs have been a bit distracted by other things.  We'll queue talking about this during our usual weekly chat, but let me provide some early input:

Normally the next step would be to request the working group to adopt the draft for work.  To date, there's been a lot of discussion (good!) but that step hasn't been taken. The chairs would then run an adoption poll - see the one for my fairly uncontroversial bfd subcode draft for comparison.

After adoption, we run through the usual IETF edit cycle to get it to RFC quality status.  Once there, a Working Group Last Call happens.

IDR requires two interoperable implementations of the behavior to advance the document to an RFC.

More than you ever wanted to know about how we work![1]

Process issues aside, here's part of what I'd be discussing with the other Chairs:
As noted in the email threads, this isn't the first time this idea has come up.  So, the work would be incorporating a lot of prior discussion and some of the prior ideas.  While this has been submitted as an individual draft, given how much prior work has been done we'd likely suggest one or more of the current authors take on the role of editors of the draft.  Prior work gets noted in an Acknowledgments section.  Aside from that, work proceeds as per a normal draft.

-- Jeff

[1] https://www.ietf.org/standards/process/informal/

> On Jan 25, 2022, at 1:30 AM, Donatas Abraitis <[email-masked]> wrote:
> 
> Folks,
> 
> I'm not much familiar with the flow actually, what should be the next step by moving forward with this draft (or not moving)? 
> 
> On Sat, Jan 1, 2022 at 11:10 PM Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
> 
> RFC 7136 deprecates the use of U/I 2 bits  in EUI-64 IID generation.  Basically the two bits can be used as don’t care for anything but are not meant to signify unique or local semantics.  RFC 4291 is updated by this RFC as far as EUI64 IID generation for both LL and Global addresses.
> 
> On Sat, Jan 1, 2022 at 2:13 PM Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> Also relevant:
>> On Jan 1, 2022, at 1:46 PM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Donatas Abraitis <[email-masked]>
Date: Tue, 25 Jan 2022 21:06:44 +0200

Thanks, Jeffrey, for the clarification.

On Tue, Jan 25, 2022 at 3:19 PM Jeffrey Haas <[email-masked]> wrote:

> Donatas,
>
> Sorry that the Chairs have been a bit distracted by other things.  We'll
> queue talking about this during our usual weekly chat, but let me provide
> some early input:
>
> Normally the next step would be to request the working group to adopt the
> draft for work.  To date, there's been a lot of discussion (good!) but that
> step hasn't been taken. The chairs would then run an adoption poll - see
> the one for my fairly uncontroversial bfd subcode draft for comparison.
>
> After adoption, we run through the usual IETF edit cycle to get it to RFC
> quality status.  Once there, a Working Group Last Call happens.
>
> As noted in the email threads, this isn't the first time this idea has
> come up.  So, the work would be incorporating a lot of prior discussion and
> some of the prior ideas.  While this has been submitted as an individual
> draft, given how much prior work has been done we'd likely suggest one or
> more of the current authors take on the role of editors of the draft.
> Prior work gets noted in an Acknowledgments section.  Aside from that, work
> proceeds as per a normal draft.
>
>
>
> -- Jeff
>

-- 
Donatas