Note that both #1 will always be the case for nodes that support both IPv4 and IPv6. And #2 is always a concern for apps that need to run on nodes/networks that may support either version of IP or both, and wish to talk to other nodes/networks that may support either version of IP or both.
In other words, expecting to have only one IP address per node is an increasingly na�ve assumption for an app to make (not even true very often for IPv4 today), and likewise is expecting everyone else's connectivity to be the same (i.e. you can't forward the IPv4 address of one of your peers to another one of your peers and expect them to be able to deal with it - the second peer may be an IPv6 only node). There are issues here that have nothing to do with site-locals. --Brian > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andrew White > Sent: Wednesday, 06 August, 2003 18:31 > Cc: [EMAIL PROTECTED] > Subject: 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 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] --------------------------------------------------------------------
