Re: And Now for Something Completely Different (was Re: IPv6 news)

[Per Heldal <heldal () eml cc>]

It doesn't look like were talking about the same thing.

A. Address conservation and aggregation (IPv4 and IPv6) is very
important to get the most out of what we've got. Read; limit the
combined routing-table to a manageable size whatever that may be.

B. There seems to be widespread fear that the global routing-table will
grow to a non-manageable size sooner or later regardless of the efforts
under A. So the limit has to be removed.

What you address below mostly belong under A (and I mostly agree),
whereas I so far have focused on B.


On Mon, 2005-10-17 at 13:12 -0700, Fred Baker wrote:
> That is an assumption that I haven't found it necessary to make. I  
> have concluded that there is no real debate about whether the  
> Internet will have to change to something that gives us the ability  
> to directly address (e.g. not behind a NAT, which imposes some  
> "interesting" requirements at the application layer and gateways of  
> the sort which were what the Internet came about to not need) a whole  
> lot more things than it does today. The debate is about how and when.  
> "when" seems pretty solidly in the 3-10 year timeframe, exactly where  
> in that timeframe being a point of some discussion, and "how" comes  
> down to a choice of "IPv6" or "something else".

Sure, something has to replace IPv4 sooner or later and IPv6 is almost
certainly the thing. Personally I belive the most trustworthy
projections points towards 2010 as the time we'll run out of addresses
in V4 with an additional 2-3 years if we can manage to reclaim up to 90%
of those previously allocated addressblocks which are not used or not
announced to the public internet.

> Fleming's IPv8 was a non-stupid idea that has a fundamental flaw in  
> that it re-interprets parts of the IPv4 header as domain identifiers  
> - it effectively extends the IP address by 16 bits, which is good,  
> but does so in a way that is not backward compatible. If we could  
> make those 16 bits be AS numbers (and ignoring for the moment the  
> fact that we seem to need larger AS numbers), the matter follows  
> pretty quickly. If one is going to change the header, though, giving  
> up fragmentation as a feature sees a little tough; one may as well  
> change the header and manage to keep the capability. One also needs  
> to change some other protocols, such as routing AS numbers and  
> including them in DNS records as part of the address.

For the record: You brought up IPv8. Nothing of what I've mentioned
requires any change to transport protocols wether implemented on top of
IPv4 or 6.

>  From my perspective, we are having enough good experience with IPv6  
> that we should simply choose that approach; there isn't a real good  
> reason to find a different one. Yes, that means there is a long  
> coexistence period yada yada yada. This is also true of any other  
> fundamental network layer protocol change.
>
> The RIRs have been trying pretty hard to make IPv6 allocations be one  
> prefix per ISP, with truly large edge networks being treated as  
> functionally equivalent to an ISP (PI addressing without admitting it  
> is being done). Make the bald assertion that this is equal to one  
> prefix per AS (they're not the same statement at all, but the number  
> of currently assigned AS numbers exceeds the number of prefixes under  
> discussion, so in my mind it makes a reasonable thumb-in-the-wind- 
> guesstimate), that is a reduction of the routing table size by an  
> order of magnitude.

I wouldn't even characterise that as being bald. Initial allocations of
more than one prefix per AS should not be allowed. Further; initial
allocations should differentiate between network of various sizes into
separate address-blocks to simplify and promote strict prefix-filtering
policies. Large networks may make arrangements with their neighbors to
honor more specifics, but that shouldn't mean that the rest of the world
should accept those.
> If we are able to reduce the routing table size by an order of  
> magnitude, I don't see that we have a requirement to fundamentally  
> change the routing technology to support it. We may *want* to (and  
> yes, I would like to, for various reasons), but that is a different  
> assertion.

Predictions disagree. 


//Per