Subject: Naming and site-local addresses

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 10 Nov 2002 14:38:11 +0100

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

---

From: Keith Moore <[email-masked]>
Date: Sun, 10 Nov 2002 10:05:02 -0500

> site-local than if only global-scoped addresses are used

I concur with the first conclusion.  But the problem is not limited to 
name-to-address lookup - it applies to any means of obtaining addresses.  
Even if you could fix DNS to work in the presence of scoped addresses it 
wouldn't solve the problems with those other means of obtaining
addresses.

(while I'd probably agree that 99% of apps do use name-to-address lookup
to obtain addresses, that doesn't mean that even those apps use it as
their only means of obtaining addressess)

Keith

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 12 Nov 2002 09:53:27 +0100

> site-local than if only global-scoped addresses are used
I agree with this conclusion. But I think that site-locals comes with a 
lot more problems than that. I think it will drag us into the "RFC1918 
swamp" of problems we have today with NAT and PT problems for new 
protocols and applications.

Best regards,

- kurtis -