Steven M. Bellovin wrote: > In message > <[EMAIL PROTECTED]>, Pekka Savola > writes: > >On Sun, 9 Jun 2002, Ralph Droms wrote: > >> problem. A router can't know when it's forwarding a > packet outside of a > >> site unless it's been configured with information about > site borders. So > >> network architects and admins have to define what makes up > sites and > >> configure the routers at the borders to know about those site > >> borders. And, I don't think there's a good way to define > default behavior > >> or auto-discovery for site-local addressing... > > > >Precisely. > > Yup -- and now we're elevating it to an architectural principle. > > > >> I don't see much difference between RFC 1918 addresses and > site-local > >> addresses in the areas of network design and deployment... > > > >Me neither. More probable outcome is that someone starts to > request that > >people implement NATv6, because 1) they're already used to > it (and like > >its "security") in v4 world, and 2) they think it's easier > for them to do > >NAT than to renumber. > > > >Site-locals were born in the era that not all sites had internet > >connectivity. Now that assumption is not all that valid > anymore. It's > >just easier for people to use a global address block (even > if we define > >that address block to be 3ffe:eff3::/32 or whatever) even with these > >"internal needs" (note: I believe there should be > _something_ that does > >not require you to fill any kind of paperwork). > > > > Yah. Let's pick a prefix, and tell folks to pick a random > number (more > precisely, use an RFC 1750-compatible RNG) to fill out the > rest of the > high-order bits to a /48 or a /64. We encourage ISPs to provide real > prefixes to companies that are using application-layer gateways, and > hence don't "need" a routable prefix. We promise two months of > connectivity to folks using non-conflicting random prefixes when they > connect, while they renumber. We think of other, creative solutions > that exploit the fact that we have a really large address space that > we're not going to exhaust. > > In short, that we do *something* that isn't going to cause long-term > architectural and operational pain.
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. 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] --------------------------------------------------------------------
