At the moment I believe we are stuck relying on two-faced DNS for resolving names to site-local addresses. Luckily(?) two-faced DNS is widely deployed.
There are other approaches. For example draft-ietf-ipngwg-site-prefixes-05 was nice - among other things it generalized easily to other name translation systems or more generally to distributed apps that pass around addresses. But it has the problem of not being backwards-compatible with existing implementations. More recently (see the list archives around Oct 29) Mark Andrews has proposed another way to put site-locals (and link-locals) in the DNS. I agree that in practice to reduce complexity, site-local boundaries should align with security boundaries. Rich > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@;alvestrand.no] > Sent: Sunday, November 10, 2002 5:38 AM > To: [EMAIL PROTECTED] > Subject: Naming and site-local addresses > > > Forgive me if I am treading well-trodden paths here, but I am > trying to > understand.... > > It seems to me that using site-local addresses in > applications means that > applications have to get hold of these addresses somehow; very few > applications are fed addresses directly by their users. > > 99% of applications do some kind of name-to-address lookup > *before* they > start getting into what kind of addresses to use. (And I'm not just > thinking about DNS - SDP is an example of a non-DNS > name-to-address lookup > - find the session using name/description, and pick the IP from the > description fields). > > If a name-to-address lookup mechanism (ANY such mechanism) returns an > off-site site-local to the application, without the info that > this is an > off-site site-local, the application will not behave as > expected. (it will either connect to the address and fail, or > it will (worse) connect > to the address and succeed, but not to the point it wanted to go). > > That seems to me to mean that the name lookup mechanism has > to not only > return globals and local-site site-locals, but has to > *suppress* off-site > site-locals. > > Which again means that the lookup mechanism has to know the > scope identity > of BOTH the requester and the target resource, or choose to > return *no* > site-locals. > > now, a lot of DNS is two-faced, meaning that the DNS servers > have to be > aware of scopes around them; mainly, two-faced DNS > distinguishes between > "within the security boundary" and "not within the security > boundary". But a lot of the DNS is not. > > So using site-local with the DNS seems to require capturing > all DNS traffic > within the site, in case it tries to query for local resources, and > *keeping* it to DNS servers that know about the site of the > requester; this > would seem to mandate two-faced DNS, even when it's not necessary for > security, and, if security by firewall is in use, make it *extremely* > complex to configure site boundaries at any other place than > at security > boundaries. > > This seems to me to be actually harder than configuring the > site border > routers for routing........ not nicely behaved wrt DNS at > all, and maybe > even less nicely behaved with other naming schemes... > > This seems to lead me to one of two conclusions: > > - Address lookup is significantly more complex in the presence of > site-local than if only global-scoped addresses are used > > - I missed something. > > Comments? > > Harald > > > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
