[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: apps people?

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

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

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 majordomo@sunroof.eng.sun.com