[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