[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Moving forward...
On 6 jun 2008, at 19:20, Scott Brim wrote:
Our recommended solution should be applicable to IPv6. It may also
apply to IPv4, but at the very least must provide a path forward
for IPv6.
I agree. Let me reword: if we can fix scalability for IPv6 and not for
IPv4, that's not ideal but still a success. If we can fix scalability
for IPv4 and not IPv6, that's a failure.
At current rates of deaggregation we can build routers with a FIB that
can handle the entire IPv4 unicast space as /24s before we've used up
and deaggregated the entire IPv4 unicast space as /24s.
I think applicability to IPv4 is equally important. First, it will
be years before there are more IPv6 packets than IPv4 packets --
longer than the time frame in which we must get our new technology
deployed -- and efficient control of IPv4 forwarding is important.
The vendors tell us we don't have an immediate problem.
Second, the granularity of IPv4 allocations is very probably going
to go up dramatically in these final days, and that "state*rate"
load will not go away for a long time.
Network operators abhor a vacuum. So they'll come up with inter-domain
routing practices that use up whatever the hardware and the protocols
give them. But for obvious reasons, not much more than that.
I looked at the prefix length distributions between the respective RIR
allocations and BGP announcements for both v4 and v6 recently. In v4,
the correlation between allocations/assignments and advertisements is
pretty much 1 for > /8, < /16. For longer prefixes there are (many)
more announcements than allocations, culminating in a factor 4 (135k
vs 35k) for /24.
http://www.bgpexpert.com/presentations/lacnic-ivb-ipv6-routingtable.pdf
Interestingly, at first I used the wrong data: I thought I had the
most recent rouing table report but it was one from 2003. Although the
number of /24 allocations/assignments back then wasn't all that much
lower than now, the number of announcements was only half.
So what I'm saying is that the announcement of long prefixes seems to
be an automomous process that happens mostly regardless of the
assignment/allocation of new prefixes. This means it will continue
after we run out of IPv4 space.
But I don't see much reason to expect that it will start going faster
then. I don't see how the largest telcos in the world that use up
addresses by the millions are going to scrape the net for thousands
of /24s when then can no longer get a /12. It's just not cost effective.
Also note that 95% of all announcements is for 6% of the address
space. When push comes to shove being able to reach 95% of the
internet may not seem like a bad deal and suddenly a turn-of-the-
century router can keep up again.
In addition, client/server works quite well with the clients on v6 and
the servers on v4, even today. For peer-to-peer stuff this is a bit
harder but with IETF work like ICE this is relatively easy to fix.
Dino said:
There needs to be a very compelling reason to make the solutions
different for v4 versus v6. We would be doing a disservice to the
community to purposely make them different.
In fact, let me make a stronger statement. If they are different,
that could be another barrier to getting IPv6 deployed.
If it's a good solution, it could be a "killer app" for v6...
Iljitsch
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg