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.
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-smaller-than-a-24/
Justin Wilson
j2sw@mtin.net
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 Unpopular opinion: BGP should accept smaller than a /24 - j2sw Blog
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.
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
Which one is easier,
- Convincing the tens of thousands of network operators and equipment vendors to modify configs and code to accept more specifics than /24, or
- Moving to IPv6 a protocol that has been here for 20+ years
???
Equipment vendors can already support 10 million entries in FIB. They just ask for a little bit of cash for it.
Mark.
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.
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
Which if you read his message carefully is pretty much exactly what he said.
Owen
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?
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.
Were you expecting it to be lower than IPv4? Mark.
I think the fact that RIR’s allocate very large IPv6 address space to their members may well be what is driving this. Historically, network operators do enjoy de-aggregating address space. One can get significantly more /48’s out of a /32 (or shorter) than they would /24’s out of any IPv4 allocation they acquired. One way to control this escalation is to shorten the maximum prefix length that all operators are willing to accept into the DFZ. The other way would be to get RIR’s to lengthen the minimum allocation they can make to their members. Neither of these solutions is likely to be popular, but nor is having to pay large sums of money for more FIB. 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
Ratio of FIB to RIB is only part of the equation.
IPv6 is NOT under the disaggregation pressure that IPv4 is under because there is no pressure (other than perhaps scarcity mentality from those that don’t properly understand IPv6) to dense-pack IPv6 assignments or undersize IPv6 allocations.
Look at the difference in prefixes per ASN across the two tables and that tells a much grimmer story for IPv4 in terms of RIB growth vs. IPv6.
Owen
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
I’ve dug through the mailman mirror on nanog.org, and there’s currently no post by Geoff Huston saying that:
https://community.nanog.org/search?q=geoff%20huston%20order%3Alatest
But I’ll play along.
There’s significantly less pressure to deaggregate IPv6 space right now, because we don’t see many attacks on IPv6 number resources.
Once we start to see v6 prefix hijackings, /48s being announced over /32 prefixes to pull traffic, then I think we’ll see IPv6 deaggregation completely swamp IPv4 deaggregation.
Either that, or content sites will simply turn off IPv6 AAAA records during periods of attack, and let the traffic shift back to IPv4 instead.
When your IPv4 space gets hijacked, there’s no fallback; you announce /24s, because that’s all you can do.
When your IPv6 space gets hijacked, there’s always IPv4 as the fallback, so there’s less pressure to announce /48s for all your space, just in case someone tries to hijack itl.
Otherwise, we would already be seeing the IPv6 deaggregation completely overwhelming the IPv4 deaggregation.
Thanks!
Matt