Was: Re: Naming and site-local addresses
Keith Moore wrote:
>
> > If so, how do they cope with interface failure tearing down TCP
> > sessions, other than just failing.
>
> well, it depends on the application. for instance, SMTP can just
> detect that the connection was broken and retry sending the entire
> message. but SMTP by its very nature buffers messages and has
> explicit acks, so having SMTP cope with interface failures
> requires little or no extra effort.
>
> for that matter, most SMTP sessions are fairly brief. apps that
> use only brief connections won't experience many errors due to
> interface failures. other sources of failure are often more
> significant.
Again we consider the problem of address selection for long-running apps...
Here are three models for address selection when both site-local and global
addresses are available. Which (if any) is preferred:
* Leave it up to application, but recommend preferring global addresses:
Pros:
Pick the address with global scope.
Cons:
If we are using site-locals because global addresses are unreliable,
then we are picking the less robust address.
* Leave it up to application, but recommend preferring local addresses:
Pros:
Site local addresses may persist where global addresses come and go.
Cons:
Default selection is not globally scoped.
* Provide addresses to application 'in order', defaulting to global first.
Networks that consider their global addresses 'transient' may change
priorities to favour site local addresses.
Pros:
Doesn't require smart applications, but applications can override if
they want.
Cons:
Need mechanism to propagate address selection preferences to hosts.
Note that short-running apps (say 10 minutes or less, to pull a number out
of the air) don't really care which address they use as long as it is valid,
which means these apps can reasonably prefer globals in multi-homed
situations (as long as the address is still within it's 'preferred'
lifetime.
Though there is the problem of how long to cache an address for.
--
Andrew White [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]
--------------------------------------------------------------------
