Router ID on IPv6-Only

Saku Ytti saku at
Fri Sep 9 07:28:16 UTC 2022

On Fri, 9 Sept 2022 at 09:31, Crist Clark <cjc+nanog at> 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.


More information about the NANOG mailing list