> Immediately blowing 2^125 addresses is absurd. We want to network the world inside and around us and then automate it. IPv6 is timely and suits well both purposes. peter@xxxxxxxxxxxxxxxx --- "Anthony G. Atkielski" <anthony@xxxxxxxxxxxxx> wrote: > Dave Cridland writes: > > > I do understand your argument, and you're correct > in all its > > assertions, but not the conclusion. I suspect > that's the case for > > everyone at this point. > > Not as long as I still see people claiming that 128 > bits will provided > 2^128 addresses _and_ that it can still be divided > into multiple bit > fields. > > > You state, loosely, that 128 bits will not > realistically yield > > 2**128 addresses, which is entirely true. > > Yes. > > > It's been pointed out that IPv6 wasn't designed > for that, instead, > > it was designed to yield 2**64 subnets, and even > so, it's > > acknowledged that a considerable amount of that > space will be > > wasted. People have agreed with this, but pointed > out that the > > "subnet" level can be moved down, since we're only > using an eighth > > of the available address space. > > I don't think many people appreciate just how > quickly such policies > can exhaust an address space--mainly because they > keep emphasizing > that 2^n addresses are available in n bits, > apparently oblivious to > the multiple factors that will waste most of the > addresses. > > > Your conclusion, however, is that we should be > switching to a > > zero-wastage allocation mechanism preferably based > on variable > > bitlength addresses. > > That is one option. Another is to stop trying to > plan the entire > future of IP addressing today. As I've said, just > adding one more bit > to 32-bit addresses would hold the Internet together > for years to > come. Immediately blowing 2^125 addresses is > absurd. > > > In response to this, several people have commented > that this > > is unworkable using both current hardware and any > hardware > > predicted to be available within the next few > years. I don't > > know about that, but I'm prepared to accept that > opinion. > > I'll accept the opinion, but as long as it remains > opinion, I can > continue to assert the contrary. I don't see any > insurmountable > obstacle that would prevent this type of > implementation. Indeed, I > should think it would greatly simplify routing. > > > There's an additional unanswered question your > argument has, which is > > whether the - very real - issues you're pointing > out with prefix > > based allocations will cause actual operational > problems within a > > timeframe short enough for anyone to worry over > for a few decades, > > and - a related issue - would these problems hit > sufficiently quickly > > that a replacement for IPv6 couldn't be developed > in time? > > In this respect I'm going by past history. As I've > said, engineers > routinely underestimate capacity and overestimate > their own ability to > foresee the future, often with expensive and > defect-ridden results. > The Internet gets bigger all the time, and the cost > of these mistakes > will be astronomically high in the future--more than > high enough to > justify changing this mindset. I'm just trying to > limit the damage by > suggesting changes as early as possible. > > Has anyone else noticed that the simplest standards > tend to last the > longest, and that complex, committee-designed > standards are often > obsolete even before the 6000-page specifications > are printed and > bound? I see that SMTP is still around, but I don't > see too many > people using X.400. I see people writing code in C, > but not in Ada. > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf