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

Fred Baker fred at cisco.com
Mon Oct 17 20:12:04 UTC 2005


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
>



More information about the NANOG mailing list