Subject: RE: Naming and site-local addresses

From: Margaret Wasserman <[email-masked]>
Date: Mon, 11 Nov 2002 17:02:39 -0500

>
>I agree that in practice to reduce complexity, site-local boundaries
>should align with security boundaries.

To retain the "convexity" property needed for sites, the site boundaries
also have to align with routing protocol area boundaries.

So, in order to make the use of site-local addressing less complex,
we will need to force site boundaries, security boundaries, "two faced"
DNS boundaries and routing protocol area boundaries to coincide.
And, these boundaries have to be in the middle of nodes, not on
links.

Is this acceptable?  I realized that this may be common for simple
leaf networks, but would it even work in a complex network?

The inter-node boundary doesn't really work for some routing protocols
that have their area boundaries on links (IS-IS and BGP), so we will
be forced to use unnumbered "dummy sites" to make those protocols
work properly across site boundaries.  Will this be compatible
with the security and "two faced" DNS boundaries?

How would a site-border node (which exists in multiple sites), that
has no knowledge of which site a particular domain name belongs to,
decide which interface to use to send a DNS request?  Does it need
to try more than one and somehow combine or choose between the results?

If a site-border node sends a DNS request and receives a site-local
address in return, how does it know in which of its attached sites
the site-local adddress is valid?  Some people have stated that it
can use the zone ID of the interface on which the DNS response is
returned, but I think that this would only work if the "two faced"
DNS server is topologically located inside the site.  Is that a
reasonable restriction?

I am personally somewhat uncomfortable with the idea of all of these
boundaries being tied together like this.  In particularly, I thought
that the DNS hierarchy was intentionally supposed to be independent
of routing topology...

Margaret

--------------------------------------------------------------------
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: Andrew White <[email-masked]>
Date: Tue, 12 Nov 2002 16:17:20 +1100

> DNS server is topologically located inside the site.  Is that a

As far as I can see, the safe way to do "two-faced" DNS with site locals is
to make the site-scoped DNS itself be addressable only by a site-scoped
address.  Otherwise, you breach the principle that a site local address MUST
NOT exist outside the site.

>From this, it follows that the DNS is topologically located inside the site.

-- 
Andrew White                [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Nov 2002 11:01:06 -0500

> As far as I can see, the safe way to do "two-faced" DNS with site locals is

there is no safe way to do DNS with site locals, because the DNS server
has no idea who is acutally going to use the results of the query.
it's not reasonable to assume that the results will be used by the
host immediately making that query.

this is a problem with two-faced DNS in general, not specific to site locals.
the fact that two-faced DNS exists does not mean that it's technically
sound for general use.

Keith

---

From: Andrew White <[email-masked]>
Date: Thu, 14 Nov 2002 12:22:03 +1100

> host immediately making that query.

Let me add the obvious clarification that this is only as safe as any other
site local mechanism.  Like site local addresses themselves, the site-local
namespace has to be protected against leakage.

Again, with multi-homed hosts the problem can be placed squarely in the
hands of the application and the user.  In a situation where we have some
hosts within the "site" using only globals and some hosts using only site
locals it becomes much hairier, as we remove the ability for applications to
treat global and site local operation as independent.

I may be out of step here, but I consider site-locals (and site-local
naming) an orthogonal addressing (and naming) scheme to global addresses for
sites that don't have 'reliable' global address stability (read 'dial-up' or
'mobile' neworks with changing global prefixes that may or may not exist).

And thus why I think the deployment issues ultimately boil down to:
  (1) filters on routers
  (2) address selection on hosts

I realise #2 is not necessarily trivial.