Steven M. Bellovin wrote: > In message <[EMAIL PROTECTED]>, > "Tony Hain" writes > : > > > > > >While I am all for avoiding architectural and operational > pain, I don't > >see this is as big a deal as the thread seems to be making > it out to be. > >There is no need for fixing the IGPs to deal with SiteLocal > as they run > >within the context of the site, therefore shouldn't know > about any other > >sites. Implementations where a given router will have an interface in > >multiple sites will need a way to tag and keep each IGP isolated. The > >simplest way is to track which interface the IGP message > comes in on and > >make sure it maps to the corresponding IGP process. > > > >I think most of this thread is focused on what are simply > implementation > >details, not an issue for the standards per se. The biggest > issue I saw > >was related to DNS returning SL or not, and this is not an > issue as long > >as the DNS server is not expected to deal with multiple > sites. As long > >as routing is filtering SL at the borders, the only way a DNS query > >would get to the SL of the DNS server would be within a site, and the > >only reason a DNS server should return an SL address is if > the query was > >addressed to its SL address. Maybe this needs to be stated clearly in > >the ngtrans doc on DNS issues, but this should be obvious from the > >perspective of 'don't return an answer that can't be used'. > > > >What this means is that an SP will not provide SL addresses for > >customers. This is not a problem today, unless an SP DNS is > resolving to > >RFC1918 addresses. > > The problem is that the definition of "site" you assume above doesn't > match the RFCs, which are deliberately vague. If it were AS-local or > organization-local addresses, I'd be much less concerned. But it's > site-local, which is not the same thing. Quoting > draft-ietf-ipngwg-scoping-arch-03.txt: > > A "site" is, by intent, not > rigorously defined, but is typically expected to cover a > region of topology that belongs to a single organization > and is located within a single geographic location, such > as an office, an office complex, or a campus. > > For a multi-site company, that's smaller than an AS. As I noted > earlier, DNS servers are supposed to be distributed across multiple > sites, and a remote one doesn't know whether or not a querier > is in the > same site as the destination. Maybe a DNS server could look > to see if > the querying address is site-local, but that implies site-local > addresses (indirectly) in NS records. It also implies that > even within > a site, a host will sometimes get the site-local address of the > destination and sometimes the global address, depending on which DNS > server it happened to query. This strikes me as seriously > ugly. And, > as Allison has pointed out, it's not at all clear that we've worked > through all the cases for caching servers or mobile IP. >
THere is a mismatch between the DNS perception of 'site' and the site-local definition of 'site'. The DNS version is much stricter about physical separation, but there shouldn't be a requirement that DNS servers for a segment of an AS have to be in differrent SL regions. It sounds like there is more to do on the DNS operations document... In any case, the only way a DNS server should return a SL in a response is if the query was received on a SL. This is the only reasonable way for the server to know if the answer is usable. If the DNS servers for a given set of hosts are split across multiple SL zones, then some of the answers will be global. This is logically the right thing to do from the DNS query/response perspective, but from the operations perspective, the servers shouldn't be in separate SL zones. If a particular network doesn't want to add to the DNS infrastructure, there is no requirement to populate it with SL addresses. If the routers don't announce them in the RA, and they aren't in the DNS, they don't get used. That does not mean we should get rid of them, because smaller organizations will typically find them useful to minimize the impact of changing providers. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
