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.
Hey,
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 :/. -- ++ytti
Crist Clark <cjc+nanog@pumpky.net> writes:
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? Bjørn
On Thu, 8 Sept 2022 at 10:01, Bjørn Mork <bjorn@mork.no> wrote:
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?
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'. -- ++ytti
Saku Ytti <saku@ytti.fi> writes:
On Thu, 8 Sept 2022 at 10:01, Bjørn Mork <bjorn@mork.no> wrote:
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?
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'.
I'm not used to punching anything, so I probably have too simple a view of the world. But I still don't understand how this changes the ID allocation scheme, which is how I understood the question. I assume the punched value was based on input from somewhere? Bjørn
On Thu, 8 Sept 2022 at 10:22, Bjørn Mork <bjorn@mork.no> wrote:
I'm not used to punching anything, so I probably have too simple a view of the world.
But I still don't understand how this changes the ID allocation scheme, which is how I understood the question. I assume the punched value was based on input from somewhere?
Today 1. Don't punch - wont work, you have to (junos) 2. Punch IPv4 - won't work So what to do tomorrow? -- ++ytti
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. randy
Right! 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... BOL
On Sep 8, 2022, at 10:13, Randy Bush <randy@psg.com> wrote:
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.
randy
-- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
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. On 2022-09-08 08:28, J. Hellenthal wrote:
Right!
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...
BOL
On Sep 8, 2022, at 10:13, Randy Bush <randy@psg.com> wrote:
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.
randy
On Fri, 9 Sept 2022 at 09:31, Crist Clark <cjc+nanog@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
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@ytti.fi> wrote:
On Fri, 9 Sept 2022 at 09:31, Crist Clark <cjc+nanog@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
Jeff Tantsura <jefftant.ietf@gmail.com> writes:
Indeed, someone was recently complaining that FRR is unhappy with a peer with router-id from class E range…
This made me curious enough to dig up the fix. If anyone else is interested: https://github.com/FRRouting/frr/commit/b5c2113e47f846d0c48fb4ef63e29bf96bd2... Bjørn
Looking at the fix, Donald has only removed IPV4_CLASS_DE(a) ((((uint32_t)(a)) & 0xe0000000) == 0xe0000000) validation but kept INADDR_ANY. I’ll bring up RFC6286 to him Cheers, Jeff
On Sep 12, 2022, at 13:41, Bjørn Mork <bjorn@mork.no> wrote: Jeff Tantsura <jefftant.ietf@gmail.com> writes:
Indeed, someone was recently complaining that FRR is unhappy with a peer with router-id from class E range…
This made me curious enough to dig up the fix. If anyone else is interested: https://github.com/FRRouting/frr/commit/b5c2113e47f846d0c48fb4ef63e29bf96bd2...
Bjørn
Jeff Tantsura <jefftant.ietf@gmail.com> writes:
Looking at the fix, Donald has only removed IPV4_CLASS_DE(a) ((((uint32_t)(a)) & 0xe0000000) == 0xe0000000) validation but kept INADDR_ANY. I’ll bring up RFC6286 to him
I believe it is implementing the RFC6286 requirements. INADDR_ANY is ((in_addr_t) 0x00000000), which is the only illegal value. Bjørn
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.
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 thought that was only for AGGREGATOR?
so an RID 'collision' with a foreign AS should not be possible
randy
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. Paul From: NANOG <nanog-bounces+razor=meganet.net@nanog.org> On Behalf Of Crist Clark Sent: Thursday, September 8, 2022 1:39 AM To: nanog@nanog.org list <nanog@nanog.org> Subject: Router ID on IPv6-Only 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.
Is there really such as thing as pure IPV6 only?
Yup. On Thu, Sep 8, 2022 at 11:32 AM Paul Amaral via NANOG <nanog@nanog.org> wrote:
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.
Paul
*From:* NANOG <nanog-bounces+razor=meganet.net@nanog.org> *On Behalf Of *Crist Clark *Sent:* Thursday, September 8, 2022 1:39 AM *To:* nanog@nanog.org list <nanog@nanog.org> *Subject:* Router ID on IPv6-Only
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.
On Wed, 7 Sep 2022, Crist Clark wrote:
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.
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?" ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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. -binarp On Thu, Sep 8, 2022, at 1:38 AM, Crist Clark wrote:
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.
participants (11)
-
Bjørn Mork -
Crist Clark -
guardian.wheel9069＠fastmail.com -
heasley -
J. Hellenthal -
Jeff Tantsura -
Jon Lewis -
Paul Amaral -
Randy Bush -
Saku Ytti -
Tom Beecher