Re: [RRG] Moving forward...

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Iljitsch,

On 2008-06-07 23:18, Iljitsch van Beijnum wrote:
> 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.

Wait a minute. Wouldn't the *entire* space put us well above 10 million
/24s? Are you saying that we can definitely build routers that could
handle say, 10 million NATted /24s, so that all small and medium
businesses can multihome?  That problem seems to be essentially
as hard as a network in which all small and medium businesses have
their own PI prefix for IPv6. So it seems that whatever the future
holds, we have the same fundamental problem. At the architectural
level, the absolute address length seems irrelevant. It's the
number of deaggregated prefixes that seems to matter.

> 
>> 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.

And we don't for IPv6 either.

> 
>> 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.

Maybe not, but if so, that is when they will start using IPv6
as a cheaper way to grow their business. And the number of prefixes
will grow just the same, regardless of the address length.

> 
> 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.

Is it OK if only 95% of telephones can be called, too?

> 
> 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.

Yes, but that's just part of any v4/v6 coexistence model. Why is
it relevant here?

    Brian

> 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
> 

--
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