Re: Router ID on IPv6-Only

2022-09-13 Thread Bjørn Mork
Jeff Tantsura  writes:

> Looking at the fix, Donald has only removed IPV4_CLASS_DE(a) 
> uint32_t)(a)) & 0xe000) == 0xe000)
> 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) 0x), which is the only illegal value.


Bjørn


Re: Router ID on IPv6-Only

2022-09-13 Thread Jeff Tantsura
Looking at the fix, Donald has only removed IPV4_CLASS_DE(a) uint32_t)(a)) 
& 0xe000) == 0xe000)
validation but kept INADDR_ANY. 
I’ll bring up RFC6286 to him

Cheers,
Jeff

> On Sep 12, 2022, at 13:41, Bjørn Mork  wrote:
> Jeff Tantsura  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/b5c2113e47f846d0c48fb4ef63e29bf96bd2fbe2
> 
> 
> Bjørn


Re: Router ID on IPv6-Only

2022-09-12 Thread Bjørn Mork
Jeff Tantsura  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/b5c2113e47f846d0c48fb4ef63e29bf96bd2fbe2


Bjørn


Re: Router ID on IPv6-Only

2022-09-12 Thread Jeff Tantsura
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  wrote:
> 
> On Fri, 9 Sept 2022 at 09:31, Crist Clark  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


Re: Router ID on IPv6-Only

2022-09-11 Thread guardian . wheel9069
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.


Re: Router ID on IPv6-Only

2022-09-09 Thread Saku Ytti
On Fri, 9 Sept 2022 at 09:31, Crist Clark  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


Re: Router ID on IPv6-Only

2022-09-09 Thread Crist Clark
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  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


Re: Router ID on IPv6-Only

2022-09-08 Thread Jon Lewis

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_


Re: Router ID on IPv6-Only

2022-09-08 Thread Randy Bush
enke and jenny yuan cleaned this up in 6286

randy


Re: Router ID on IPv6-Only

2022-09-08 Thread heasley
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


Re: Router ID on IPv6-Only

2022-09-08 Thread 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}

so an RID 'collision' with a foreign AS should not be possible

randy



Re: Router ID on IPv6-Only

2022-09-08 Thread heasley
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.



Re: Router ID on IPv6-Only

2022-09-08 Thread Tom Beecher
>
> Is there really such as thing as pure IPV6 only?
>

Yup.

On Thu, Sep 8, 2022 at 11:32 AM Paul Amaral via NANOG 
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  *On Behalf Of *Crist
> Clark
> *Sent:* Thursday, September 8, 2022 1:39 AM
> *To:* nanog@nanog.org list 
> *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.
>


RE: Router ID on IPv6-Only

2022-09-08 Thread Paul Amaral via NANOG
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  On Behalf Of Crist Clark
Sent: Thursday, September 8, 2022 1:39 AM
To: nanog@nanog.org list 
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.



Re: Router ID on IPv6-Only

2022-09-08 Thread J. Hellenthal via NANOG
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  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.








Re: Router ID on IPv6-Only

2022-09-08 Thread 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.

randy


Re: Router ID on IPv6-Only

2022-09-08 Thread Saku Ytti
On Thu, 8 Sept 2022 at 10:22, Bjørn Mork  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


Re: Router ID on IPv6-Only

2022-09-08 Thread Bjørn Mork
Saku Ytti  writes:

> On Thu, 8 Sept 2022 at 10:01, Bjørn Mork  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


Re: Router ID on IPv6-Only

2022-09-08 Thread Saku Ytti
On Thu, 8 Sept 2022 at 10:01, Bjørn Mork  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


Re: Router ID on IPv6-Only

2022-09-08 Thread Bjørn Mork
Crist Clark  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


Re: Router ID on IPv6-Only

2022-09-07 Thread Saku Ytti
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