I agree with Steve here, we have plenty of tools at our disposal here and eight tries to get it right. Variable length addresses would be much more expensive to support and there really is no reason to expect 128 bits to be insufficient unless the allocation mechanism is completely broken, something that more bits will not cure. If variable length addressing had been proposed when IPv4 was being designed it might well have avoided the need for IPv6, or at least the need for IPv6 to affect the end user to the extent it does. At this point the IPv6 address space is a decision that has already been made and would take over a decade to change. IPv4 space runs into exhaustion first so that is not an acceptable option. > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@xxxxxxxxxxxxxxx] > Sent: Thursday, March 30, 2006 11:11 PM > To: ietf@xxxxxxxx > Subject: Re: 128 bits should be enough for everyone, was: > IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: > StupidNAT tricks and how to stop them.) > > On Thu, 30 Mar 2006 20:43:14 -0600, "Stephen Sprunk" > <stephen@xxxxxxxxxx> wrote: > > > > > That's why 85% of the address space is reserved. The /3 we > are using > > (and even then only a tiny fraction thereof) will last a long, long > > time even with the most pessimistic projections. If it turns out > > we're still wrong about that, we can come up with a > different policy for the next /3 we use. > > Or we could change the policy for the existing /3(s) to > avoid needing > > to consume new ones. > > > > I really shouldn't waste my time on this thread; I really do know > better. > > You're absolutely right about the /3 business -- this was a very > deliberate design decision. So, by the way, was the decision to use > 128-bit, fixed-length addresses -- we really did think about this > stuff, way back when. > > When the IPng directorate was designing/selecting what's now IPv6, > there was a variable-length address candidate on the table: CLNP. It > was strongly favored by some because of the flexibility; > others pointed > out how slow that would be, especially in hardware. > > There was another proposal, one that was almost adopted, for something > very much like today's IPv6 but with 64/128/192/256-bit addresses, > controlled by the high-order two bits. That looked fast enough in > hardware, albeit with the the destination address coming first in the > packet. OTOH, that would have slowed down source address checking > (think BCP 38), so maybe it wasn't a great idea. > > There was enough opposition to that scheme that a compromise was > reached -- those who favored the 64/128/192/256 scheme would accept > fixed-length addresses if the length was changed to 128 bits from 64, > partially for future-proofing and partially for flexibility in usage. > That decision was derided because it seemed to be too much address > space to some, space we'd never use. > > I'm carefully not saying which option I supported. I now > think, though, > that 128 bits has worked well. > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf