> I agree with Keith that the logical conclusion is that whenever a site-local
> and global address are returned the only non-ambiguous decision to take is
> to prefer the global address.  But that means we lose the nice property of
> prefering site-locals intra-site to help maintain long-standing connections
> (e.g. NFS) through external renumbering or connectivity events that alter
> global prefixes seen within the site.
> 
> It seems the only way around that is to either use a special unique
> "site-local global" prefix internally (plucked from some method as yet
> undefined, Keith's ideas to date there are "woolly" at best :) or to use a
> parallel/split DNS naming structure internally (be it foo.site or otherwise,
> indeed in my own NATed v4 home network I use .home in the scope of my home
> network for that purpose on Net10, not pretty but it works), or to use only
> site-local literals.  Are there other solutions?

I actually think that all applications that expect to keep associations
around more than some well-known (and explicitly chosen) lifetime need 
to have mechanisms for surviving renumbering.   And unless/until 
we introduce renumbering support into TCP, UDP, and SCTP, this means
providing that support in layer 7.

I also think there needs to be a minimum overlap time during renumbering
(during which both prefixes are valid), which is greater than or equal 
to the max reliable association lifetime above.  That way, if an application 
gets a valid prefix when it starts, that prefix will remain valid for at 
least the max reliable association lifetime.

In other words, I'd rather make a distinction between applications with
long associations and applications which don't need long associations
than between site-local applications and applications that might need
to cross site boundaries.  In practice I don't think there are many
inherently site-local applications.


Keith

p.s. offhand I suggest that that lifetime should be 10 days.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to