When an apps cycle through the list of potential src/dst addresses,
it does not fail over from one to the other immediately, especially
when the destination is remote and ICMP unreachable message may or may not
be received. TCP time out kicks in and RFC1123 says that an app MUST wait
at least 3 minutes in SYN state before timing out
(of course not all TCP implementation implement this MUST)
Anyway, my point is that if this trial/error process of walking through the list of possible destination before finding a correct one can be extremely time consuming. So, if the "routing view" of the world is not in sync with the "DNS view" of the world, unacceptable delays may/will occur.
- Alain.
On Wednesday, August 6, 2003, at 06:31 PM, Andrew White wrote:
Unless I'm missing something, the 'apps' problem can be neatly divided into
two issues:
(1) If there are multiple addresses per node, then the application needs to
somehow iterate through the various src/dest combos until it finds one that
works. If multiple ones would work, how does it choose the best combo?
(2) If there are filters in place, then addresses that work from one node
attached at one point may not work from a different node or a different
location.
If we agree to remove filters and have one address per node, then we can
continue to write simplistic apps. If not, then applications need to use
techniques that allow them to cope with these issues.
Notice that if an application only creates connections using a single pair
of endpoints then (assuming no mobility) it only has to deal with issue #1.
Issue #2 only comes into play when applications forward IP address to other
applications and expect them to keep working. Sending DNS addresses instead
may be a solution for some applications. Manual configuration is the other
option.
This discussion is only relevant to 'local' addresses in as much as local
addresses are one class of filtered address. As soon as you introduce
filters you MUST consider #2, regardless of your address 'scope'.
Christian's point about apps not wanting to deal with scope ids to resolve
overlapping mutually ambiguous scopes is taken, but I think most of us agree
with that aspect.
Network ambiguity is largely irrelevant - the connection succeeds or it doesn't (remember that most nodes have a unique interface id). Rather, ambiguity is a big bugbear for network merging.
-- Andrew White -------------------------------------------------------------------- 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] --------------------------------------------------------------------
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
