below... Margaret Wasserman wrote: > > Hi Brian, > > > > Welcome to NATv6. > > > >It's our job to stop that happening. > > I agree, and I actually consider our job to be even bigger > than this... > > We need to create the technologies and policies that will enable a > globally-addressable, "flat" IPv6 Internet. > > We need to understand and document how a flat IPv6 Internet can be > deployed in parallel with the existing IPv4 Internet without > introducing serious operational or security problems. > > We need to provide enough education regarding the advantages of > a globally-addressable, flat Internet that we can change the way > that large numbers of people think about network architecture. > Remember there are more Internet administrators who were spawned > and trained during a time of widespread NAT use than there are > those of us who remember the flat IPv4 Internet. > > AND, in the meantime, we need to avoid advocating NAT or NAT-like > solutions to problems that can be solved without destroying the > global-addressability or "flatness" of the IPv6 Internet. > > >Also, the vast majority of Internet users are not in the least > >possessive about their IP address; it's different every time they > >connect. Those who are possessive are those who run services of one > >kind or another. It's our job to make that possible without forcing > >them down the NAThole. > > I completely agree. > > But, what I don't understand is how the use of overlapping site-local > addresses on globally-attached networks is any better than NAT.
My recollection is that site-local entered the architecture to cover the somewhat theoretical case of a multi-subnet site that for whatever reason wasn't connected, and so didn't have a global prefix. And our problems with SL come from trying to use it outside that limited scenario. If we keep it inside that scenario, it seems easy enough to deal with. So, why not simply deprecate SL for sites that have at least one global prefix? Or am I too simple minded? That would then leave us with a couple of real problems to avoid NAT: multihoming, and easy renumbering. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
