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

Tue Oct 18 00:34:17 UTC 2005

----- Original Message ----- 
From: "Fred Baker" <fred at cisco.com>
To: "Per Heldal" <heldal at eml.cc>
Cc: <nanog at merit.edu>
Sent: Monday, October 17, 2005 15:12
Subject: Re: And Now for Something Completely Different (was Re: IPv6 news)


> 
> 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".
> 
> 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.
> 
> 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.
> 
> 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.
> 
> On Oct 17, 2005, at 12:42 PM, Per Heldal wrote:
> 
>> mon, 17,.10.2005 kl. 11.29 -0700, Fred Baker:
>>
>>> OK. What you just described is akin to an enterprise network with  
>>> a  default route. It's also akin to the way DNS works.
>>
>> No default, just one or more *potential* routes.
>>
>> Your input is appreciated, and yes I'm very much aware that many  
>> people who maintain solutions that assume full/total control of the  
>> entire routing-table will be screaming bloody murder if that is  
>> going to change. Further details about future inter-domain-routing  
>> concepts belong in other fora (e.g. ietf's inter-domain-routing wg).
>>
>> The long-term operational impact is that the current inter-domain- 
>> routing concepts (BGP etc) don't scale indefinitely and will have  
>> to be changed some time in the future. Thus expect the size of the  
>> routing-table to be eliminated from the list of limiting factors,  
>> or that the bar is considerably raised.
>>
>> ---
>>
>> Note that I'm not saying that nothing should be done to preserve  
>> and optimise the use of the resources that are available today just  
>> because there will be something better available in a distant  
>> future. I'm in favor of the most restrictive allocation policies in  
>> place today. The development of the internet has for a long time  
>> been based on finding better ways to use available resources (CIDR  
>> anyone). To me a natural next-step in that process is for RIR's to  
>> start reclaiming unused v4 address-blocks, or at least start  
>> collect data to document that space is not being used (if they're  
>> not already doing so). E.g prevously announced address-blocks that  
>> has disappeared from the global routing-table for more than X  
>> months should go back to the RIR-pool (X<=6).
>>
>>
>> //Per
>>
>