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, > http://www.research.att.com/~smb (me) > > http://www.wilyhacker.com ("Firewalls" book) > > > > -------------------------------------------------------------------- > > 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] > > -------------------------------------------------------------------- > > -- > Randall R. Stewart > [EMAIL PROTECTED] 815-342-5222 (cell phone) > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
