I support Bob Hinden's email, quoted below. I don't understand why we are spending so much time on this issue. I get this impression that the folks who haven't yet implemented support for site-local addresses are worried that they will suddenly be stuck implementing and testing a bunch of code they don't want. That's really not the case.
I do not advocate requiring every host and router implementation to have multi-site support. I think all that's required for host implementations is the default address selection rules, and all that's required for router implementations is to have two modes (either all interfaces are in the same site so site-locals are treated like globals, or all interfaces are in different sites so site-locals are filtered). This is really very little burden for host and router implementations. I do not advocate requiring applications to work well on multi-sited hosts. Some developers will want to support this, some will not and that's OK. For distributed applications that do referrals, a simple policy is to run in either "global mode" (only using global addresses) or "site mode" (only using site-local addresses). This takes very little code to implement. Anything more sophisticated should be at the discretion of the developer. Rich > -----Original Message----- > From: Michel Py [mailto:michel@;arneill-py.sacramento.ca.us] > Sent: Thursday, November 14, 2002 7:56 AM > To: Bob Hinden; [EMAIL PROTECTED] > Subject: RE: Scoping Scoped Addresses > > > Ipv6 folk, > > I think there are some of you that need to re-read what Bob > Hinden post here ten days and several hundreds email ago. > > I support Bob in the statement he made as chair and I will > continue to work within the framework outlined below. > > Michel > > > Bob Hinden wrote: > [Working group chair hat on] > > I have been trying to make some sense of this discussion. > The only obvious > conclusion is that there is not a consensus in the working > group on how > site-local addresses should be used. > > Some people think that site-local is an important feature > with many uses, > others think they are bad and should not be used. Some think > they provide > security, some do not. Some thing they help with > renumbering, some do > not. Some thing they help avoid IPv6 NAT's, some think they > encourage IPv6 > NAT's. Etc., etc. The only thing that is clear is there are > a significant > number of people who have different views on this topic. > It's doubtful > that one group will convince the other group. One positive > result of the > discussion was that the issues and benefits are better > understood. The > real question for the working group is what to do next. > > Now that the IPv6 Address Architecture was approved as a > Draft Standard and > the Default Address Selection document was previously > approved, we have > site-local addresses in IPv6 and a set of default rules for how an > implementation selects them. What we don't have is how they > should be used > or not-used. > > Even though there is no consensus on how site-local addresses > should be > used, I think there is enough people who want to use > site-local that it is > reasonable that the w.g. should continue trying to flesh out > site-local > usage as well as pitfalls of usage. > > Here is a proposal for how to proceed from here that tries to > take into > account both sides of the discussion. > > 1) Node Requirements should not require any multi-site > implementations. The only site-local requirement should be > limited to what > is currently in the address selection rules and for routers > to configure > > site-locals just like any other unicast prefix. Vendors are > free to go > beyond this in their products, but the IETF won't require it. > > 2) People who think the usage of site-local is harmful should > write a draft > titled something like "Use of Site-local Addresses Considered > Harmful". The people in the other camp can comment to make sure the > arguments are accurate. > > 3) People who want to use site-local addresses should work on > completing > > the "IPv6 Scoped Address Architecture" document (and other docs if > needed). I think a good focus for this would be to focus on > the simplest > cases. Topics to cover need to include site border routers, adding > site-local addresses in the DNS, routing protocols, the use > of firewalls to > enforce site boundaries, and guidelines on how applications > might want to > select between global and site-local addresses. The people > in the other > > camp can review this work and make sure the technical content > is accurate. > > I believe this approach should help provide the larger > community (e.g., > vendors, ISP's, enterprise operators, etc.) the information > they need to > > make an informed decision on the usage of site-locals. > > Bob > > p.s. I will also send out a few personal comments on site-locals in a > separate email. > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
