> Keith Moore wrote: > > or to state this better, it's fine if apps simply avoid > > passing some kinds of addresses around as long as they can > > easily tell which ones to pass around and which ones to not > > pass around. > > Yet you want to ban apps from recognizing the defined flags FE80, > FEC0, FC00, ...
more precisely, I want to discourage the expectation that apps can make do with *just* these. and if apps have more portable addresses available to them, why should apps deal with these at all? > > it's not fine if there's not an > > easily-identifiable, portable address available for every > > host that is expected to work with an app. > > 2::/3 ??? Or are you talking about portable as in PI? portable as in uniquely identifying every host that is participating in the app, and being usable to reach any of those hosts from any of those hosts if such communication is permitted. > > > * Applications should not assume that addresses can be forwarded > > > at-will, unless provided with additional (configured?) information > > > > > > that would support this assumption. > > > > applications should be able to forward addresses to other > > hosts; this is an essential capability. that doesn't mean > > that they can expect those addresses to be usable from remote > > locations. but if they're not usable, the reason should be > > either network failure or administrative prohibition - in > > other words, something that the app should not be expected to > > work around. > > So there should only be a single address per host, or all addresses > must have exactly the same policy and reachability characteristics??? more or less. I'm still trying to formulate a precise statement of this that accomodates renumbering, multihoming, local addressing, ad hoc networks, etc. > This is the limitation of the IPv4 world. it's not a limitation, it's a feature. and while it was never mandated in the v4 world, having multiple interfaces per host turned out to cause problems when it mattered which address you used, so people tended to avoid doing so except in special cases. > There is nothing preventing > an app from continuing down that path. Unfortunately there are some > who want to preclude anyone else from taking a different path. some people don't want a predictable environment for applications; or they want to limit the kinds of apps that can be supported. one could conclude that they want to harm the ability of the Internet to support new apps, or to reduce the size of the market for new apps. I prefer to think of them as just naive and/or obtuse. > > > * Applications that do not care to do their own address management > > > > > > need a higher level abstraction to the current sockets and > > getaddrinfo > > > APIs. > > > > not sure what you mean by this. > > Not to put words in Andrew's mouth, but I suspect he meant 'if it is > more complex than the app wants to deal with, let the stack take care > of it'. the important thing is giving apps a model they can work with. but it's not clear you can solve these problems in the stack any better than you can in the app. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
