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