It is time to get off this thread and back to real work. Those who want SL removed should get 1918 moved to historic first, get all products using that off the market, then come back and raise the issue. Since we know that won't happen, the constructive thing to do is for those that don't think they can support SL to leave it out of their implementation, while those that have figured out how to use it as a differentiator can leave it in. Yes that might cause interoperability problems, but only in the case where a site was running with SL as its only prefix. When a node doesn't support SL, it will be hard pressed to register an SL address in whatever name resolution system is being used, and if a product can't respond correctly to an SL address, an administrator shouldn't register it. Every node should be able to work when only a global address is returned, so in any realistic scenario, where is the interoperability problem?
On the topic of documenting when and how SL interacts with DNS or SIP or your favorite name-to-address-mapper, yes more work is needed. I would argue this belongs in the DNS WGs, but if their approach is to ignore it because it is different from current operation, then the IPv6 community will have to corner some DNS experts long enough to learn the issues. In any case it doesn't make sense to waste time arguing that 'XYZ configuration will not work', when no sane network manager would configure a network that way. When particular configurations don't work, pointing that out in documentation makes sense, but demanding to throw out the mechanism because an obscure corner case fails is not good engineering. One issue that I am surprised has not been raised here is the case where a node has administrative restrictions on which prefixes it can learn from an RA (specifically so that it will only work on the home network), and that list includes SL. If that node appeared on a foreign net, it would ignore the globals, but would happly accept any SL and may be wide open. One could argue that it shouldn't happen, but consider the case where enterprise-A uses 802.11, and a laptop with it built-in (and no administrative rights to the user to turn it off) were to show up at enterprise-B. The sys-admin may have thought the machine was reasonably protected by the filter list on the RA, but by using SL left that node wide open when it was away from home. This is not an argument that SL shoudl be dropped, just that it is not appropriate in all contexts. One case where it does make sense is in consumer electronics that are intended for local in-home use, and have no reason for global addressibility (say a light switch). Those who want SL removed are arguing that the average consumer will be required to manage a firewall to keep the global address of the light switch from being reached externally. Many of them can't even get self-configuring NATs to work with help from a support desk, so forget any hope that they will do something more complex. While having the light switch accessed by a control unit could be done with LL, does it make sense to have a control unit connect to every possible link technology in a home, or does it make more sense to use SL from a stand-alone control unit and have a routing device attach to the different segments? We typically define control and routing jobs as separate functions, so why would someone expect that they now magically show up in the same box? The router should be a cheap box with nothing but connectors, while the control unit has a fancy UI and may be replicated in multiple locations. As I scan through this thread, it started by questioning the lack of documentation about how SL should work in a particular context, but quickly degraded into an attack on change. The IETF is about managing the consistent change that has been taking place in networking, so standing up and saying 'take this out because it requires us to change the way we have done it forever' is counter to our role. Documenting that a mechanims works in configuration A, not at all in configuration B, and we haven't figured out configuraion C, is what we need to do here, so lets get on with it. Tony Jim Bound wrote: > As all know I wanted these dreaded site-locals gone since we > invented them in IPv6. > This has been discussed before if we can revisit this again > that is a very good thing. > Steve and Randy are 100% correct. > > I would also add they break lots of stuff. > > /jim > > > -----Original Message----- > > From: Randall Stewart [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 06, 2002 2:46 PM > > To: Steven M. Bellovin > > Cc: [EMAIL PROTECTED] > > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > > > > Steve: > > > > Having implemented SCTP and IPv6 together I could not agree with you > > more. > > I know in our work on scoping of addresses it got very very > tricky on > > attempting to figure out which set of addresses to tell the other > > SCTP endpoint about to avoid black hole conditions. So in the end > > the only way you could handle it is if the destination address > > of your INIT packet (consider it a SYN) was TO a site-local then > > you could include your site-locals... This means that if the user > > sent the INIT to the global address then the peer NEVER > gets informed > > of site locals.... maybe something not desired but unavoidable... > > > > > > Now with the new addition of site-scoping even this will break since > > one must all of a sudden be cognizant of what site the peer > is on and > > only send a sub-set of the site-local addresses (gak!!). > > > > In all of this I have tried to figure out what use these site locals > > are? > > > > If I have a global address why would I ever want to use a > site-local? > > If no global-addresses are available and I am not attached to the > > public inter-net I could possibly see using a site-local.. maybe but > > I would think this is more the 'dentists' office scenario where in > > link-local will suffice... If the 'dentist' wants to talk to the > > insurance company I doubt that it would be in the > 'dentist's' site... > > so he would need a connection to the global address space... and the > > problem goes away.... > > > > Only in a large company would I see a site-local being > applied.. but > > in such a company why not just use a global address? What does it > > buy me to have this extra address? I already know my > assigned address > > space... I can have my company border routers prevent spoofing of > > my address into my network... so I can use the source being the > > global address that is assigned to me to "know" that I am in the > > same company...if thats what I want... > > > > I may be able to see (maybe) that a large company wants to NOT > > connect to the global address space... so here site-local MIGHT be > > something I could use... but adding in scoped site-locals I > just can't > > see a use for... It just causes all sorts of fun problems. > > > > I would much rather see the company that is NOT going to want to > > connect to the global address space just have a way to get some > > global address space.... I realize with the current number scheme > > this is not possible so maybe a site-local does make sense in > > this one strange instance... but in this case the company > > does not need > > to worry about global mixed with site-local :> > > > > So maybe site-local (if allowed) should only be valid if NO global > > address is defined :> > > > > R > > > > "Steven M. Bellovin" wrote: > > > > > > In message > > <[EMAIL PROTECTED]>, Margaret Wasserm > > > an writes: > > > > > > > >I sent the attached message to the routing area discussion > > list. I thought th > > > >at people on > > > >the IPv6 list might be interested in this discussion, so I > > will forward a mess > > > >age containing > > > >the responses after this one. I suppose I just should > > have cc:ed the IPv6 gro > > > >up in the > > > >first place... > > > > > > > > > > My strong preference would be to drop site-local addresses > > completely. > > > I think they're an administrative and technical nightmare. > > > > > > Margaret has pointed out that our routing protocols don't support > > > site-local addresses. The only alternative suggestion I've > > seen thus > > > far is to run multiple instances of, say, OSPF on all > > routers within a > > > site. But how are these distinguished from each other? > > OSPF runs with > > > an IP protocol number, not a port number, so we can't > have multiple > > > instances that way. And RFC 2740's specification of the necessary > > > multicast addresses notes that they're all link-local. > > Still, there's > > > apparently running code; I look forward to seeing the details. > > > > > > I'm very concerned about DNS entries. When should a DNS > > server -- or a > > > caching resolver -- return a site-local address? (If the > DNS never > > > returns such things, they're useless.) One suggestion > I've heard is > > > two-faced DNS servers -- only return site-local information if the > > > querier is within the same site. Apart from the fact > that I have no > > > idea how that determination can be made -- surely no one > > will suggest > > > putting site-local addresses into NS records -- RFC 2182 > > (aka BCP 0016) > > > specifically warns against putting all secondary servers > for a zone > > > within a site: > > > > > > Consequently, placing all servers at the local site, > > while easy to > > > arrange, and easy to manage, is not a good policy. > > Should a single > > > link fail, or there be a site, or perhaps even > building, or room, > > > power failure, such a configuration can lead to all > servers being > > > disconnected from the Internet. > > > > > > Secondary servers must be placed at both topologically and > > > geographically dispersed locations on the Internet, to > > minimise the > > > likelihood of a single failure disabling all of them. > > > > > > Etc. > > > > > > There will also be a lot of unnecessary pain in DNS maintenance as > > > "sites" are split or merged. v6 is designed to support > > easy renumbering > > > of global addresses, but those are designed to reflect topology. > > > Site-local addresses do not, which increases the probability of > > > address space collision during a merger. > > > > > > Philosophically, I think that the problem is that a > "site" is a new > > > (and deliberately poorly defined) concept. The DNS is > > designed to work > > > with administrative boundaries, while routing and > addressing reflect > > > topology. We now have a new concept that is neither > > administrative nor > > > topological, but one that must be supported by administrative and > > > topological mechanisms. > > > > > > 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? > > > > > > --Steve Bellovin, -------------------------------------------------------------------- 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] --------------------------------------------------------------------
