Hello all,
As the IPv4 space get smaller and smaller, does anyone think we'll see a time when /25's will be accepted for global BGP prefix announcement. The current smallest size is a /24 and generally ok for most people, but the crunch gets tighter, routers continue to have more and more ram will it always be /24 the smallest size?
Cheers,
Mike
RAM != FIB.
The forwarding hardware is generally going to be the limit, and
that's going to be painful enough as we approach a half million
prefixes.
You couldn't even consider such a thing until after that pain
point.
--msa
As the fragmentation will progress and we will be closing to the magic
limit of 500.000, people will filter out /24 and then /23 and so on.
Back to static (default) routing!
Quite the opposite. As the technical limitations of the routing gear are reached, shorter and shorter prefixes will be tolerated until IPv4 is utterly unusable if we try to stay on IPv4 that long.
Owen
500k is imho no different than 250k 128k 100k. Some devices are going to fall off the applecart. some folks will engage in heroic measures to police their fib size and the world will move on. million route and 2 million route fib platforms abound. if we cross the million mark in 10 years we're fine. if we cross it in 2 (which doesn't seem likely) then we have a problem. the v6 table imho is the one to watch.
As the IPv4 space get smaller and smaller, does anyone think we'll
see a time when /25's will be accepted for global BGP prefix
announcement. The current smallest size is a /24 and generally
ok for most people, but the crunch gets tighter, routers continue
to have more and more ram will it always be /24 the smallest size?
No.
1. Too many ASes whose operators are a part of too many cultures and
speak too many languages apply a blind filter at /24. Too hard to
change.
2. TCAM != RAM
However....
It is possible for a tunnel provider to:
1. Draw a covering route in to a well chosen set of data centers,
2. Set up a nice redundant set of tunnels from each data center to
each of its customers' Internet links,
3. Accept smaller-than-/24 routes at a higher priority than the
tunnels from its peers where those routes originate from the customers
to whom it assigned those addresses
4. Help the customers negotiate with the specific handful of ISPs that
operate the paths between them so that they'll accept the sourced
packets natively and propagate the smaller-than-/24 route within their
system.
It hasn't been done with any regularity, but it's technically
feasible, can be implemented within a few percent of optimal routing
and resilience and requires cooperation from few enough parties (all
of them directly paid) that it could happen if the economics were
right.
Hello all,
As the IPv4 space get smaller and smaller, does anyone think we'll see a
time when /25's will be accepted for global BGP prefix announcement. The
I am confident there are providers that will accept /25s from some of
their customer(s) or peer(s); either due to negotiations with some of
their customer(s); or as a result of ignorance or administrative
error (failing to reject /25s, and not realizing it).
current smallest size is a /24 and generally ok for most people, but the
Well, current smallest size intended to be accepted is /24 for many
major providers.
Some will be more restrictive. /24 is useful as a rule of thumb
but not "an exact size" that every network allows.
Further address fragmentation will eventually demand that networks
become more restrictive, OR that the underlying protocol and
hardware gets redesigned; which again, leads to netwroks becoming
more restrictive, to avoid spending $$$ on hardware, software, and
config upgrades.
Majdi S. Abbas wrote:
As the IPv4 space get smaller and smaller, does anyone think we'll see
a time when /25's will be accepted for global BGP prefix announcement.
The current smallest size is a /24 and generally ok for most people, but
the crunch gets tighter, routers continue to have more and more ram will
it always be /24 the smallest size?RAM != FIB.
For /24, cheap 16M entry SRAM == FIB
The forwarding hardware is generally going to be the limit, and
that's going to be painful enough as we approach a half million
prefixes.
True. And that's why we must avoid IPv6.
Masataka Ohta
The forwarding hardware is generally going to be the limit, and
that's going to be painful enough as we approach a half million
prefixes.True. And that's why we must avoid IPv6.
Masataka Ohta
Great comment. 
The forwarding hardware is generally going to be the limit, and
that's going to be painful enough as we approach a half million
prefixes.True. And that's why we must avoid IPv6.
This is not only wrong, it makes no sense whatsoever.
Owen
The forwarding hardware is generally going to be the limit, and
that's going to be painful enough as we approach a half million
prefixes.
I would expect that we might finally see some pushback against
networks that announce lots of disaggregated prefixes. The current
CIDR report notes that the 400K prefixes could be 260K if aggregated.
I realize it's not quite that simple due to issues of longer prefixes
taking precedence over shorter ones, but it is my impression that
there's a lot of sloppiness.
So here's a question: has anyone done any musings/reasearch on how big of a global IPv6 table we could expect given current policies if IPv6 were as widely deployed and used as IPv4 (or if IPv4 didn't exist)?
Yes… It will probably settle out somewhere around 100-125K routes.
Owen
Owen -
Can you elaborate some on this estimate? (i.e. what approximations
and/or assumptions are you using to reach this number?)
Thanks!
/John
RFC 3587 - IPv6 Global Unicast Address Format
The forwarding hardware is generally going to be the limit, and
that's going to be painful enough as we approach a half million
prefixes.True. And that's why we must avoid IPv6.
This is not only wrong, it makes no sense whatsoever.
Neither did the first part of his statement. Gigabit srams are neither
particularly cheap nor particularly better suited to implementing a
FIB than plain old dram.
So here's a question: has anyone done any musings/reasearch on how big of a
global IPv6 table we could expect given current policies if IPv6 were as
widely deployed and used as IPv4 (or if IPv4 didn't exist)?
Too soon to tell.
On the one hand, we shouldn't have the registry-driven fragmentation.
They're trying hard to allocate enough addresses for all foreseeable
demand, not just near term, and they're leaving space to bump the
netmask for the next request when it comes. They're also selecting
policies which discourage multihomed end users from breaking up their
ISP's block instead of getting their own. On the other side of the
hump with IPv4 in decline, both of these should reduce the total
number of announcements chosen by each organization.
On the other hand, IPv6 addresses consume upwards of 4 times the bits
in the FIB.
On the fence, the tools for traffic engineering have not changed, the
registries are making no attempt to allocate in a manner that
facilitates TE filtering, and there's still no better way than a BGP
announcement for an end-user to multihome. Number transfers for
mergers, acquisitions and divestitures, and renumbering in general
suffer from all the same ailments they do in IPv4. At 128 bits
instead of 32 bits, all of these factors should impact IPv6 the in
same manner they have impacted IPv4.
Regards,
Bill Herrin
Looking at the number of autonomous systems in the IPv6 routing table and the total number of routes, it looks like it will shake out somewhere in the neighborhood of 3-5 prefixes/ASN. Since there are ~35,000 unique ASNs in the IPv4 table, I figured simple multiplication provided as good an estimate as any at this early time.
Owen
Deaggregating of IPv4 announcements is done for traffic engineering and
to fight ddoses (just the attacked /24 stops being announced to
internet). I think some people will just copy their v4 habits into v6
and then we might have explosion of /48's.
I wouldn't be so sure about just 3-5 prefixes/ASN.
Some ASNs will be more, some will be less. Since there's already some DDOS and such on IPv6, I would expect the current prefix table to include a reasonable example of all of the behaviors you describe.
Owen
John Levine wrote:
I realize it's not quite that simple due to issues of longer prefixes
taking precedence over shorter ones, but it is my impression that
there's a lot of sloppiness.
16M /24 is just a cheap 16M entry SRAM.
However, 16M /32 means 4G entry SRAM or 16M entry CAM.
16M entry with /40 or /48 prefix means 16M entry CAM, which is hard,
which is why IPv6 is hard.
Masataka Ohta