Subject: RE: Node Requirements Issue 3

From: "Richard Draves" <[email-masked]>
Date: Fri, 25 Oct 2002 10:46:01 -0700

How do site-locals work?

For a single-sited host, I think the main requirement is
draft-ietf-ipv6-default-addr-select-09. For applications that send
addresses to correspondents (note this is a small minority of
applications) it can get more complicated but it's still not bad - see
kre's recent emails about this. I know MS is porting/developing such
applications but I'm not involved.

For DNS, I implemented draft-ietf-ipngwg-site-prefixes-05 and it works
great. Unfortunately since that draft seems to be dead, I think the
fall-back for now is that to use site-locals you'll need a two-faced
DNS.

For a multi-sited host, one additional requirement is that applications
should deal with sockaddrs instead of directly with addresses, so that
the scope-id is preserved & passed around as needed. Another additional
requirement is routing table lookup needs to be cognizant of scoping.

We recently implemented some logic to infer when two interfaces are in
different sites in many common scenarios (eg when you VPN into an
intranet, the VPN interface gets a different site scope-id) but in
general manual configuration may be required to specify which interfaces
belong to which sites.

Rich

> -----Original Message-----
> From: Roy Brabson [mailto:[email-masked]] 
> Sent: Thursday, October 24, 2002 11:32 AM
> To: Richard Draves
> Cc: [email-masked]; Keith Moore; Margaret Wasserman
> Subject: RE: Node Requirements Issue 3
> 
> 
> > This is craziness. We (I don't mean just MS) have shipping 
> > implementations that support site-locals. We have operational 
> > deployments using site-locals. We have applications that work just 
> > fine with site-locals.
> 
> Could you (or someone else who has this working) publish an ID which 
> describes how site-locals work?  I've seen many postings on various 
> aspects of site-locals which do not work as currently 
> defined, from DNS to 
> routing to applications using site-locals in referrals.  
> There have been 
> some proposals on how to address some of these issues, such 
> as updates to 
> dynamic routing protocols, but others (like DNS) don't seem 
> to have any 
> agreed upon solutions in multi-sited configurations and, 
> arguably in the 
> case of DNS, single-sited configurations.  Without standards, 
> or at least 
> standards-track IDs, its hard to see how site-locals can be viewed as 
> useful beyond a single-site configuration, with anything 
> beyond that being 
> experimental and/or proprietary.
> 
> Roy
> 

--------------------------------------------------------------------
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: Roy Brabson <[email-masked]>
Date: Fri, 25 Oct 2002 14:27:51 -0400

> applications but I'm not involved.

I'd agree as long as the single-sited host is not connected to the global 
internet.  When connected to the global internet, many applications will 
work just fine.  But there are some application protocols as currently 
defined which do not work.  It would seem useful to try to identify the 
classes of applications which break in these configurations and what 
actions need to take to occur to update the protocols and/or applications 
to allow this to work.  Once this is understood, it would be easier to 
gauge whether using site-local addresses when a site is connected to the 
global internet is worth the effort.

> fall-back for now is that to use site-locals you'll need a two-faced

Yes, although not pretty two-faced DNS works for single-sited hosts.

> requirement is routing table lookup needs to be cognizant of scoping.

If the DNS resolver fills in the appropriate scope zone ID for site-local 
addresses, then the application can use the sockaddr for communication. 
How the scope zone ID gets filled in, and how the DNS resolver queries 
two-faced DNS name servers in different sites and consolidates the (now 
different) responses is what has not been defined.  For instance, since 
each site would need to run two-faced DNS to allow site-locals to be 
placed in DNS, each may return different results for the same host. 
Depending on which site the DNS query is sent and how DNS is configured, 
the resolver may receive no addresses, only global addresses, or a mixture 
of global and site-local addresses.  This was covered on this list 
previously with no agreed-upon resolution on how to make this work, not to 
mention any IDs with concrete proposals to be reviewed.

There are, of course, additional issues for multi-sited hosts.  At a 
minimum, there are the routing changes which have been discussed here 
previously, and possibly others which have yet to be identified.

None of this is insurmountable.  With sufficient architecture and updates 
to susceptible applications, support for multi-sited hosts can likely be 
made functional.  Whether it is worth the effort is a different question, 
though, and one which only this WG can answer.
 
Roy

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Oct 2002 15:10:17 -0400

> though, and one which only this WG can answer.

actually I doubt this wg has enough expertise in applications to be able
to answer that question.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Oct 2002 15:08:50 -0400

> applications) 

the number of applications is irrelevant.  what's important is how
badly this impairs the functionality of the Internet.  performance-
sensitive apps need to pass addresses around.  

> it can get more complicated but it's still not bad - see
> kre's recent emails about this. 

if each hosts prunes the addresses it advertises, it prevents 
some things from working.  example: A and B use C as an intermediary;
A and B each advertise their addresses to C.  A and B share an address
scope which isn't accessible by C.  So if A prunes its addresses
when giving them to C, C isn't able to give B an address that it can
use.   Of course that is assuming that A knows which address scopes
C has access to, which it doesn't.  

> fall-back for now is that to use site-locals you'll need a two-faced

DNS has the same problem as any other app that does referrals - it
has no way of knowing which address scopes are accessible to the 
user of those addresses.

> the scope-id is preserved & passed around as needed. 

no, you can't pass sockaddrs across the net.

> Another additional

no, that's just too much hair.  

Keith