>> Let's be clear. Our group (Windows Networking) has received a lot >> of feedback from developers of applications on the Windows >> platform. The negative developers' feedback was mostly centered on the >> difficulty of identifying the scope of an address, specially when a >> node is connected to several sites (e.g. home network and VPN to the >> corporate network), or when a node moves from site to site. > > Which is to say, topology information which it didn't > have to consider in the past and for which it has little > information at its disposal from which to make decisions.
No, I specifically did not say "topology information". Topology is a very wide notion, and application developers are actually OK with some amount of topology handling, e.g. doing things differently with folks that are "near me". The feedback on local addresses was very specific. Applications would learn or remember that the address of some correspondent was "FEC0::1234:5678:9ABC", they would try to feed the address in a socket address structure and issue a connect, and the call will fail because they did not fill up the "site identifier" variable, as in "FEC0::1234:5678:9ABC&1". The problem is compounded by the fact that the site identifier varies with the host instantiation, e.g. sometimes &1 and sometimes &2, and thus that the host identifier cannot be remembered in memory, or learned from a name server. Having a non ambiguous address solves that problem, because the stack will know over which interface a connect request to "FC00:DEAD:BEEF::1234:5678:9ABC" shall be routed! . The application will not have to handle "site identifiers", and that is a very good thing. -- Christian Huitema -------------------------------------------------------------------- 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] --------------------------------------------------------------------
