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] --------------------------------------------------------------------
