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] --------------------------------------------------------------------
