North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Per Heldal
  • Date: Mon Oct 17 17:10:17 2005

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.