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
