Router ID on IPv6-Only

Mon Sep 12 11:15:32 UTC 2022

Indeed, someone was recently complaining that FRR is unhappy with a peer with router-id from class E range…

Cheers,
Jeff

> On Sep 9, 2022, at 09:30, Saku Ytti <saku at ytti.fi> wrote:
> 
> On Fri, 9 Sept 2022 at 09:31, Crist Clark <cjc+nanog at pumpky.net> wrote:
> 
>> As I said in the original email, I realize router IDs just need to be
>> unique in
>> an AS. We could have done random ones with IPv4, but using a well chosen
> 
> In some far future this will be true. We meet eBGP speakers across the
> world, and not everyone supports route refresh, _TODAY_, I suspect
> mostly because internally developed eBGP implementations and
> developers were not very familiar with how real life BGP works.
> RFC6286 is not supported by all common implementations, much less
> uncommon. And even for common implementations it requires a very new
> image (20.4 for Junos, many are even in 17.4 still).
> 
> So while we can consider BGP router-id to be only locally significant
> when RFC6286 is implemented, in practice you want to be defensive in
> your router-id strategy, i.e. avoid at least scheme of 1,2,3,4,5,6...
> on thesis that will be common scheme and liable to increase support
> costs down the line due to collision probability being higher. While
> it might also add commercial advantage for transit providers, to have
> low router-id to win billable traffic.
> 
>> And to get even a little more specific about our particular use case and
>> the
>> suggestion here to build the device location into the ID, we're
>> generally not
> 
> I would strongly advise against any information-to-ID mapping schemes.
> This adds complexity and reduces flexibility and requires you to know
> the complete problem ahead of time, which is difficult, only have
> rules you absolutely must have. I am sure most people here have
> experience having too cutesy addressing schemes some time in their
> past, where forming an IP address had unnecessary rules in them, which
> just created complexity and cost in future.
> If you can add an arbitrary 32b ID to your database, this problem
> becomes very easy. If not, it's tricky.
> 
> -- 
>  ++ytti