Re: maximum ipv4 bgp prefix length of /24 ?
Each unit of mask length increase doubles the size of the table theoretically. About 60% of the table is /24 routes. Just going to /25 will probably double the table size. Not sure I'd like to extrapolate the estimate out to /27. Kind Regards, Jakob ----------------------------------------------------------------------------- Date: Fri, 29 Sep 2023 00:25:55 +0300 From: VOLKAN SAL?H <volkan.salih.06@gmail.com> To: nanog@nanog.org hello, I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24.. I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient for most of the small and medium sized organizations and also home office workers like youtubers, and professional gamers and webmasters! It is because BGP research and experiment networks can not get /24 due to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world. What do you think about this? What could be done here? Is it unacceptable; considering most big networks that do full-table-routing also use multi-core routers with lots of RAM? those would probably handle /27s and while small networks mostly use default routing, it should be reasonable to allow /25-/27? Thanks for reading, regards..
About 60% of the table is /24 routes. Just going to /25 will probably double the table size.
or maybe just add 60%, not 100%. and it would take time. agree it would be quite painful. would rather not go there. sad to say, i suspect some degree of lengthening is inevitable. we have ourselves to blame; but blame does not move packets. randy, who was in the danvers cabal for the /19 agreement
I think it is going to have to happen. We have several folks on the IX and various consulting clients who only need 3-6 Ips but have to burn a full /24 to participate in BGP. I wrote a blog post awhile back on this topic https://blog.j2sw.com/data-center/unpopular-opinion-bgp-should-accept-smalle... Justin Wilson j2sw@mtin.net — https://j2sw.com (AS399332) https://blog.j2sw.com - Podcast and Blog
On Sep 30, 2023, at 1:48 PM, Randy Bush <randy@psg.com> wrote:
About 60% of the table is /24 routes. Just going to /25 will probably double the table size.
or maybe just add 60%, not 100%. and it would take time.
agree it would be quite painful. would rather not go there. sad to say, i suspect some degree of lengthening is inevitable. we have ourselves to blame; but blame does not move packets.
randy, who was in the danvers cabal for the /19 agreement
lists@mtin.net (Justin Wilson (Lists)) wrote:
I think it is going to have to happen. We have several folks on the IX and various consulting clients who only need 3-6 Ips but have to burn a full /24 to participate in BGP. I wrote a blog post awhile back on this topic https://blog.j2sw.com/data-center/unpopular-opinion-bgp-should-accept-smalle...
Justin, I'm not sure you're not confusing scope here. Everybody and their sister accept smaller blocks from their customers; we're all talking about the DFZ here, not customer routes that you aggregate. I would estimate most of the "consulting clients" have no need for multihoming. If they do, they can always use IP, and abandon legacy IP. Elmar. PS: I'm convinced we'll never agree to put longer prefixes into the DFZ. The gear everybody's using doesn't handle it well, and as people have stated before, there's just no incentive. I, personally, don't even take /24s in many places (sometimes cutting off at /20), but then I take defaults from my transits who have less ancient gear.
On 10/4/23 09:27, Elmar K. Bins wrote:
Justin,
I'm not sure you're not confusing scope here.
Everybody and their sister accept smaller blocks from their customers; we're all talking about the DFZ here, not customer routes that you aggregate.
Actually, we don't. From our customers, the most we are accepting today is a /24 and a /48. This is for transit customers with their own AS and address space. Of course, if it's a DIA customer, we can assign longer prefixes, but that is internal address space that belongs to us. Mark.
Re Mark, mark@tinka.africa (Mark Tinka) wrote:
From our customers, the most we are accepting today is a /24 and a /48. This is for transit customers with their own AS and address space.
Oh sure - I was looking at those customers who might need multihoming to their ISP, but not multihoming in the DFZ, unlike the ones you're looking at here.
Of course, if it's a DIA customer, we can assign longer prefixes, but that is internal address space that belongs to us.
Exactly what I was referring to. This is what I believe to be the standard case. Elmar.
On Oct 4, 2023, at 03:18, Mark Tinka <mark@tinka.africa> wrote:
On 10/4/23 09:27, Elmar K. Bins wrote:
Justin,
I'm not sure you're not confusing scope here.
Everybody and their sister accept smaller blocks from their customers; we're all talking about the DFZ here, not customer routes that you aggregate.
Actually, we don't.
From our customers, the most we are accepting today is a /24 and a /48. This is for transit customers with their own AS and address space.
Of course, if it's a DIA customer, we can assign longer prefixes, but that is internal address space that belongs to us.
Mark.
Which if you read his message carefully is pretty much exactly what he said. Owen
On Tue, Oct 3, 2023 at 11:56 AM Justin Wilson (Lists) <lists@mtin.net> wrote:
I think it is going to have to happen. We have several folks on the IX and various consulting clients who only need 3-6 Ips but have to burn a full /24 to participate in BGP. I wrote a blog post awhile back on this topic
Hi Justin, The Internet is not one network, it's tens of thousands of them all run by different people who make their own choices. To participate in BGP with a more specific prefix than /24, you must convince nearly all of them to allow it. How are you planning to reach a human being at those networks, much less a human being in a position to make that choice? Let alone talk them into the change... When it was a handful of networks trying to filter at /19, it was possible to beat that handful over the head. Even then it took years before they gave up on the idea. /24 has been the de facto minimum since forever. It's not a handful of networks, it's nearly everybody. So, if you'd like to make a wager on /25 and more specifics becoming a real thing on the backbone, I'll be happy to take your money. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Which one is easier, 1. Convincing the tens of thousands of network operators and equipment vendors to modify configs and code to accept more specifics than /24, or 2. Moving to IPv6 a protocol that has been here for 20+ years ??? On Wed, 4 Oct 2023 at 12:41, William Herrin <bill@herrin.us> wrote:
On Tue, Oct 3, 2023 at 11:56 AM Justin Wilson (Lists) <lists@mtin.net> wrote:
I think it is going to have to happen. We have several folks on the IX and various consulting clients who only need 3-6 Ips but have to burn a full /24 to participate in BGP. I wrote a blog post awhile back on this topic
Hi Justin,
The Internet is not one network, it's tens of thousands of them all run by different people who make their own choices. To participate in BGP with a more specific prefix than /24, you must convince nearly all of them to allow it. How are you planning to reach a human being at those networks, much less a human being in a position to make that choice? Let alone talk them into the change...
When it was a handful of networks trying to filter at /19, it was possible to beat that handful over the head. Even then it took years before they gave up on the idea. /24 has been the de facto minimum since forever. It's not a handful of networks, it's nearly everybody.
So, if you'd like to make a wager on /25 and more specifics becoming a real thing on the backbone, I'll be happy to take your money.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On 10/4/23 12:11, Musa Stephen Honlue wrote:
Which one is easier,
1. Convincing the tens of thousands of network operators and equipment vendors to modify configs and code to accept more specifics than /24, or
Equipment vendors can already support 10 million entries in FIB. They just ask for a little bit of cash for it. Mark.
If you maximally disaggregate to /24, you end up with about 12M fib entries. At /25 this doubles and you double it again for every bit you move right. At /24, we are on borrowed time without walking right. Also, the CPU in most routers won’t handle the churn of a 10M prefix RIB. Owen
On Oct 4, 2023, at 03:15, Mark Tinka <mark@tinka.africa> wrote:
On 10/4/23 12:11, Musa Stephen Honlue wrote:
Which one is easier,
1. Convincing the tens of thousands of network operators and equipment vendors to modify configs and code to accept more specifics than /24, or
Equipment vendors can already support 10 million entries in FIB. They just ask for a little bit of cash for it.
Mark.
Been resisting adding to this thread... But if the assumption is that networks will always eventually totally deaggregate to the maximum, we're screwed. Routing IPv4 /32s would be nothing. The current practice of accepting /48s could swell to about 2^(48 - 3) = 2^45 = 35184372088832. What will prevent unrestricted growth of the IPv6 table if operators push everything out to /48 "to counter hijacks" or other misguided reasons? On Wed, Oct 4, 2023 at 8:14 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
If you maximally disaggregate to /24, you end up with about 12M fib entries. At /25 this doubles and you double it again for every bit you move right.
At /24, we are on borrowed time without walking right. Also, the CPU in most routers won’t handle the churn of a 10M prefix RIB.
Owen
On Oct 4, 2023, at 03:15, Mark Tinka <mark@tinka.africa> wrote:
On 10/4/23 12:11, Musa Stephen Honlue wrote:
Which one is easier,
1. Convincing the tens of thousands of network operators and equipment vendors to modify configs and code to accept more specifics than /24, or
Equipment vendors can already support 10 million entries in FIB. They just ask for a little bit of cash for it.
Mark.
On 10/5/23 07:49, Crist Clark wrote:
But if the assumption is that networks will always eventually totally deaggregate to the maximum, we're screwed. Routing IPv4 /32s would be nothing. The current practice of accepting /48s could swell to about 2^(48 - 3) = 2^45 = 35184372088832.
What will prevent unrestricted growth of the IPv6 table if operators push everything out to /48 "to counter hijacks" or other misguided reasons?
Expecting that the Internet would ever operate at maximum de-aggregation is unrealistic. There are too many checkpoints to make that a feasible possibility. It's not an outcome I would spend any brain cycles on, unless as an academic exercise. Mark.
I think it needs to be slightly more nuanced than that… Because IPv4 is driven to dense-packing and tight allocations, I think disaggregation of IPv4 will only increase over time. The hope is that by issuing larger than needed blocks of IPv6, less disaggregation becomes necessary over time. So far, that seems to be largely the case, with more than 50% of ASNs represented in the DFZ in IPv6, we see roughly 191884 unique destinations in IPv6 and 942750 unique destinations in IPv4 (admittedly an instantaneous snapshot a few moments ago from a single DFZ router, YMMV). Even if we double the IPv6 prefix count or even quadruple it, we’re still looking at a much smaller level of disaggregation in IPv6 than IPv4 in the current state. Owen
On Oct 4, 2023, at 22:49, Crist Clark <cjc+nanog@pumpky.net> wrote:
Been resisting adding to this thread...
But if the assumption is that networks will always eventually totally deaggregate to the maximum, we're screwed. Routing IPv4 /32s would be nothing. The current practice of accepting /48s could swell to about 2^(48 - 3) = 2^45 = 35184372088832.
What will prevent unrestricted growth of the IPv6 table if operators push everything out to /48 "to counter hijacks" or other misguided reasons?
On Wed, Oct 4, 2023 at 8:14 AM Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:
If you maximally disaggregate to /24, you end up with about 12M fib entries. At /25 this doubles and you double it again for every bit you move right.
At /24, we are on borrowed time without walking right. Also, the CPU in most routers won’t handle the churn of a 10M prefix RIB.
Owen
On Oct 4, 2023, at 03:15, Mark Tinka <mark@tinka.africa> wrote:
On 10/4/23 12:11, Musa Stephen Honlue wrote:
Which one is easier,
1. Convincing the tens of thousands of network operators and equipment vendors to modify configs and code to accept more specifics than /24, or
Equipment vendors can already support 10 million entries in FIB. They just ask for a little bit of cash for it.
Mark.
On Thu, Oct 5, 2023 at 12:11 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:
So far, that seems to be largely the case, with more than 50% of ASNs represented in the DFZ in IPv6, we see roughly 191884 unique destinations in IPv6 and 942750 unique destinations in IPv4 (admittedly an instantaneous snapshot a few moments ago from a single DFZ router, YMMV).
When you realize that an IPv6 address takes 4 times the space as an IPv4 address that picture isn't so rosy any more. The impact on critical-path router resources isn't quite 4x of course, but as you say: only 50% of the ASes are represented. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
participants (9)
-
Crist Clark
-
Elmar K. Bins
-
Jakob Heitz (jheitz)
-
Justin Wilson (Lists)
-
Mark Tinka
-
Musa Stephen Honlue
-
Owen DeLong
-
Randy Bush
-
William Herrin