Bob, As one who has worked with you a long time and always fight to not break existing implementations in this case I don't find your (and mine to some degree) abstracts for site-local compelling enough. I think they are very bad and evil for the Internet too and more importantly private enterprise.
The code changes for this are quite minimal too. API tweek which can be done in follow releases, and the base IP stack has not evolved for scoping and now routing exists with this feature. I think we should kill these now. /jim > -----Original Message----- > From: Bob Hinden [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 07, 2002 6:57 PM > To: Steven M. Bellovin > Cc: [EMAIL PROTECTED] > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > Steve, > > Thanks for raising this issue on the list. I think it has > been lurking for > a while. > > (with no hat on) > > Here is my personal explanation about why site-local > addresses exist. My > intent of the email is to not take a strong position on either side. > > I think the important question is the one at the end of your email: > > >Finally -- and perhaps least important -- I'm not sure what problem > >they solve. I can understand site-local multicast, since (most) > >inter-site traffic traverses links that are not inherently > >multicast-capable. There is thus considerable extra > expense. But why > >do I need site-local unicast addresses? > > It may be the most important question, not the least important :-) > > One of the original reasons for site-local unicast addresses > was for sites > that were not connected to the Internet (and didn't have any global > addresses). They would allow IPv6 be used inside the site > initially. Later when the site become connected to the > Internet it would > be easy to renumber to a global prefix because the subnet part of the > addresses (/48 in current assignment practice) could be > reused without any > site subnet renumbering. This usage of site-local unicast > may still have > some value and avoids some of the complexity of using a > mixture of global > and site-local addresses. > > Later as many people came to belive that private addresses > (and NAT) in > IPv4 provide a security mechanism, Site-local addresses were > looked on as > filling that role in IPv6. I understand that the belief that private > addresses provide security is faulty and has many nasty > consequences, but > many people do believe it. I think this has evolved to where > there is a > view that using site-local unicast addresses for services > that need to be > restricted to the site is a good thing. I think there is > some value here, > but am not sure if it's benefits justify it's costs. I think > there are a > range of opinions here. > > All of the issues you point out about site-local regarding > DNS and routers > are real. However with the widespread use of IPv4 private > addresses in the > internet, that vendors have leaned how to deal with addressing domain > issues. I don't think the IETF has done very much to > "standardize" this > usage (probably a good thing). I think most vendors building these > products know how to deal with the issues and users have > learned how to > configure the products to solve their problem. The vendors built it > because their customers wanted it. It is all very ugly and > nasty. It is > hard to set up and even harder to debug problems. Perhaps > even as you say > "an administrative and technical nightmare". But as far as I > can tell it > does exist. If vendors are going to build products that want to use > site-local, then it might be best for the IETF to at least > document it's > usage to allow for interoperability. > > (with my IPv6 co-chair hat on) > > I think the w.g. has some choices to make regarding > site-local addresses. > > 1) Remove site-local from the IPv6. > > This would involve remove it from the IPv6 addressing > documents and find > all other documents that mention them and update these. Some > of these may > require significant modification if use site-local as a basic > part of their > mechanisms. There will also be an impact to shipping IPv6 > implementations. This would have to be sorted out. A good > understanding > of what different vendors plan here would be useful. > > 2) Keep site-local but limit it's scope of usage. > > This would be something like writing an applicability > document that defines > it usage and for example restricts it use to sites not > connected to the > Internet. Other usage would be for future study. This would > be consistent > with most of the current specifications. It would make > completing the > scoped address architecture document simpler. There might be other > specifications to update if they were using site-local and > didn't have any > provision to move to global addresses. > > 3) Keep site-local and allow full usage > > This would mean fully specifying how to use site-local, > documenting the > router and DNS issues, completing the scoped addressing architecture > document, perhaps enhancing IPv6 routing protocols to have > more knowledge > of site-local addresses, etc. > > The working group has been going down 3) for some time now. > I think your > email is a good start at seeing if should continue in this > direction or > change course. > > Bob > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
