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