> > For what it's worth I agree. If we now specify a RFC1918 > > like structure for IPv6, we will be faced with people doing NAT like > > structures - for whatever reason, and a lot of what is considered the drive > > for IPv6 is gone. > > => Why is it gone ? Not everyone wants NATs and for those who > do, deprecating SL addresses will not help. It will just make > their (Network admins) behaviour less predictable.
it's not the case that NATs only affect networks that use them. widespread use of NATs makes the market for some kinds of apps so small, and the circumstances under which they can be used so difficult to recognize, that those apps essentially cannot be made commercially viable - at least not without adding a huge amount of overhead and complexity in the form of proxies and/or centralized servers, an doing addressing and routing internal to the app. similarly, it's not the case that SLs only affect networks that use them if SLs are widely used. > > A lot of people have then told me that IPv6 would > > help with peer-to-peer communications. With SL this is > > gone. > > => Obviously, if you choose to use SL for a disconnected > network you're not interested in P2P on a global level. > If you choose to use SL with globally routable addresses > in the same network, you can get P2P. presuming of course that the globally routable addresses are usable by any node that needs them. > > Even if there might be reasons for a site to not need globally unique > > addresses, the problem is that at some point in the future > > that device will be on the net, and instead of renumbering, someone > > will do IPv6 NAT and the peer-to-peer/end-to-end models are gone. > > I agree that I don't think the installed base is a problem. If the small > > installations we have now is a problem, the problem of renumbering these > > sites with global addresses is not going to become smaller. > > > > History will repeat it self. > > => i don't know why some people try to resist existing > facts. If you can't change it accept it and try to make > the best out of it, i.e. write a BCP to tell people > about the consequences of certain actions. Any attempt > to change the world by deprecating SLs is an exercise > in futility. Much better to educate people and hope that > in time we will reduce the number of myths on the net. SLs were not carved in stone by the hand of God and brought down from the mountain. They can indeed be deprecated, though I don't see much support for doing that. They can also be discouraged. A BCP that discourages uses of SLs except in certain narrow cases and explains why is probably more useful than a BCP that tries to explain exactly when SLs cause problems and when they don't. Of course, it's quite possible to have both. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
