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.)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 30 Mar 2006 10:22:23 -0800

> From: Tim Chown [mailto:[email-masked]] 

> I noticed that by deafult MS Vista doesn't use autoconf as 
> per 2462, rather it uses a 3041-like random address.  See:
> http://www.microsoft.com/technet/itsolutions/network/evaluate/
> new_network.mspx

This should hardly be a surprise. The inability of the IETF to accept as
legitimate real world security concerns at the time 2462 was written was as
notorious as its insistence on certain irrelevant concerns being absolute.

It the real world I am actually very concerned if someone is able to
determine my MAC address. It opens up a significant amount of information
about my internal network that in the real world I have no intention of
sharing.

During the 1990s many people, myself included mistook applying cryptography
for security. 

In the real world what network managers want to do and will insist on having
tools to acomplish is to guard the boundary between the internal and
external network as closely as possible and to prevent any piece of
unnecessary information crossing that barrier in either direction.

It is certainly a mistake to consider this practice a sufficient condition
for security but anyonje who does not understand that it is a necessary
party of a security strategy has little to contribute to today's security
architecture.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 31 Mar 2006 07:48:56 -0800

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:[email-masked]] 
> Sent: Thursday, March 30, 2006 11:11 PM
> To: [email-masked]
> 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"
> <[email-masked]> 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
>