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

From: Donatas Abraitis <[email-masked]>
Date: Tue, 7 Dec 2021 17:49:24 +0200

Hi, All,

we drafted another paper that combines Link-Local Next-Hop capability and
all the edge cases to handle as we discussed in this thread.

Jeff, you might be interested to review it
https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability-00
and I believe you can add it to
https://trac.ietf.org/trac/idr/wiki/idr-draft-status#IPv6LinkLocalNexthopWork
.

On Wed, Nov 10, 2021 at 6:56 PM Gyan Mishra <[email-masked]> wrote:

>
>
> On Wed, Nov 10, 2021 at 9:59 AM Jeffrey Haas <[email-masked]> wrote:
>
>>
>>
>> On Nov 8, 2021, at 10:01 AM, Gyan Mishra <[email-masked]> wrote:
>>
>> Once upon a time, Linux used to encode its interface ID for ipv6 link
>>> local
>>> in those "must be zero" bits in its data structures.  I've not read that
>>> source in years so it may have changed. :-)
>>>
>>>    Gyan> RFC 4291 states the 54 bits proceeding the fe80:: must be 0's.
>> I have seen not having that 0 break ND and a nightmare to troubleshoot
>>
>>
>> This was understood.
>>
>> It's a common coding technique when you rely on minimal memory use to
>> leverage well-understood requirements like this and simply steal bits.
>>
>> If you KNOW that you must have zero fields, you can do things like insert
>> a 32-bit interface index into that field.
>>
>> As long as you have consistent mutators and accessors in your API, you
>> don't notice.  Just beware of raw memcpy. :-)
>>
>> -- Jeff
>>
>
> Gyan> Agreed
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [email-masked] <[email-masked]>*
>
>
>
> *M 301 502-1347*
>
>

-- 
Donatas