During some IPv6 numbering discussions at work today, someone had a question that I hadn’t really considered before. How to choose 32-bit router IDs for IPv6-only routers.
Quick background. We have a requirement to convert a significant portion of our network to IPv6-only over the next few years. Previously, I, and everyone else on the team, have only ever set up routers in dual-stack environments. Choosing a router ID for use in routing protocols just followed whatever rules you used for your IPv4 networking. You used the same router ID in IPv4 and IPv6.
Well, now there is no IPv4. But BGP, OSPFv3, and other routing protocols still use 32-bit router IDs for IPv6. On the one hand, there are plenty of 32-bit numbers to use. Generally speaking, router IDs just need to be unique inside of an AS to do their job, but (a) for humans or automation to generate them and (b) to easily recognize them, it’s convenient to have some algorithm or methodology for assigning them.
Has anyone thought about this or have a good way to do it? We had ideas like use bits 32-63 from an interface. Seems like it could work, but also could totally break down if we’re using >64-bit prefixes for things like router-to-router links or pulling router loopbacks out of a common /64.
Also, various network OS implementations will typically automatically choose a router ID from the IPv4 addresses on the router by some algorithm (e.g. numerically lowest) if not explicitly configured. Was curious what IPv6-only routers do. Haven’t had the chance to get on some lab gear or GNS3 to just try it and see.
Well, now there is no IPv4. But BGP, OSPFv3, and other routing protocols still use 32-bit router IDs for IPv6. On the one hand, there are plenty of 32-bit numbers to use. Generally speaking, router IDs just need to be unique inside of an AS to do their job, but (a) for humans or automation to generate them and (b) to easily recognize them, it's convenient to have some algorithm or methodology for assigning them.
2nd hand knowledge, but when this was discussed early on in
standardization, someone argued against 128b ID, because it would
require too much bandwidth in their OSPF network. Joys of everyone
plays standardisation.
Has anyone thought about this or have a good way to do it? We had ideas like use bits 32-63 from an interface. Seems like it could work, but also could totally break down if we're using >64-bit prefixes for things like router-to-router links or pulling router loopbacks out of a common /64.
If your data is in a database I think the best bet is to
algorithmically generate multiple forms of IDs in your device and
interface rows, to satisfy various restrictions on what forms of IDs
are accepted. And then use these IDs. If your data is in configs, you
don't have really good solutions, but you could choose 32b from your
IPv6 loopback right side :/.
During some IPv6 numbering discussions at work today, someone had a
question that I hadn't really considered before. How to choose 32-bit
router IDs for IPv6-only routers.
Why would you do it differently than for dual-stack routers, except that
you skip the step where you configure the ID as a loopback address?
Of course you don't have care about routing the 32bit IDs anymore
either. But that doesn't really change anything either. Except that
can skip even more configuration.
It's obviously possible to connect the ID to some IPv6 address on the
router, as long as you understand the structure of that allocation and
can select the right bits or hash to make it unique. But if you don't
do that for dual-stack today, then why care? Or if you do it for
dual-stack, then what changed?
Because you may not have an option, if you're IPv6 only, vendors (e.g.
junos) may expect you to punch it manually. Of course most of us punch
it manually as loopback0 IPv4 to have more control over outcome.
Question is legitimate and represents change where previously used
mechanisms do not apply, therefore OP is right to ask 'well what
should I do now'.
During some IPv6 numbering discussions at work today, someone had a
question that I hadn't really considered before. How to choose 32-bit
router IDs for IPv6-only routers.
arbitrary 32 bit number unique in the autonomous system. even in an
ipv4 world it does not need to match any configured interface address.
Personally it just needs to be unique. Relying on a Id to be unique when ascociated to an IP address that may be used on a failover system seems really poor to me.
Assign a random ID and plug it into your IPAM!. If at anything assign a router ID to a rack location and associate every bit of information about that location in whatever you're tracking management can provide.
Personally I prefer date originated generated numbers that allow me to filter upon such and spill out the results to tell me where its at what rack its in, slot number etc...
But then again this is from a failover system perspective...
Is there really such as thing as pure IPV6 only? I don’t think you will be able to run IPV6 for transport without the router locally knowing how to handle IPV4, at least not right now as there’s a lot of legacy code. Usually IPV6 is enabled longer after IPV4 has been running. With that said, can’t you just enable ipv4 and not route it passed the router, then use RFC1918 to manually general your 32 bit ID.
Thu, Sep 08, 2022 at 08:13:33AM -0700, Randy Bush:
> During some IPv6 numbering discussions at work today, someone had a
> question that I hadn't really considered before. How to choose 32-bit
> router IDs for IPv6-only routers.
arbitrary 32 bit number unique in the autonomous system. even in an
ipv4 world it does not need to match any configured interface address.
A question Dorian and I discussed but never answered is, how are open
collisions handled if two speakers, presumably an external AS, happen
to have the RID? Which would be possible if an AS chose their RIDs
randomly or intentionally used low numbers (eg: 0/24) to attract traffic
as a result of the BGP path selection process.
4172:
Based on the value of the BGP Identifier, a convention is established
for detecting which BGP connection is to be preserved when a
collision occurs. The convention is to compare the BGP Identifiers
of the peers involved in the collision and to retain only the
connection initiated by the BGP speaker with the higher-valued BGP
Identifier.
Easily answered by testing, and could yield fun results (bugs). I
presume both would (should) close and reconnect later, possibly repeatedly
before success, thereby delaying session establishment.
A question Dorian and I discussed but never answered is, how are open
collisions handled if two speakers, presumably an external AS, happen
to have the RID?
the uniqueness is supposed to be on the tuple {AS,RID}
so an RID 'collision' with a foreign AS should not be possible
Thu, Sep 08, 2022 at 10:18:13AM -0700, Randy Bush:
> A question Dorian and I discussed but never answered is, how are open
> collisions handled if two speakers, presumably an external AS, happen
> to have the RID?
the uniqueness is supposed to be on the tuple {AS,RID}
I have no idea what your v6 numbering plan is, but given ours, I don't see how we could get away with using bits 32-63 from any (loopback or real) interface v6 address [that we've assigned] as the router id.
As you say, it's just a 32-bit number, and has to be unique within your AS. You could easily abuse some of your v4 space to be tracked in your IPAM or some other db as router IDs (and still use those IPs on servers or whatever since the routers aren't really "using them" from an IPv4 routing perspective). Or you might pick a suitably sized subnet from 100.64.0.0/10 to be used as router IDs. That would avoid the confusion of "why is server X's IP the router-id for these routes?"
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
address assigned to the router guarantees uniqueness as well as some other useful
properties. I was wondering if people had some ways to do something similar with
IPv6.
But I think the most notable thing from the handful of responses (and thanks to
all that responded) was that no one piped up who is actually doing it. I guess
most everything is still dual-stack.
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
really talking about one ID per physical router here. I'm really talking about
IPv6-only VRFs. The router (L3 switch, firewall, or whatever it may be) may
have a mix of IPv6-only, IPv4-only, and dual-stack VRFs. I think multiple VRFs
per device is no longer exotic configuration and closer to the norm.
And before anyone suggests borrowing IPv4 addresses from other VRFs to use in
the IPv6-only VRFs, that was something we discounted right away for what I think
are pretty obvious reasons.
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.
I assume you would still have a Loopback0 address. While I’m not completely sure it’s a hard guaranty of uniqueness as I don’t know your numbering scheme, if it is, why not use the last 32bits of the IPv6 Loopback0 address. This should closely approximate previous modes of operation and not require outside things like an IPAM to track it.