Nir Arad wrote: > As for internal communications (here's another flame bait): > I propose to prefer global addresses too. > Only those "special, internal applications" that should maintain very > long term connections at the transport layer should be a little > complicated by allowing the user to prefer local addresses, thus > addressing the debated stability issue. > Hosts will be forced down to local addressing only if the destination > has only a local scope address (e.g. an internal printer).
Define 'special, internal applications'? - Is my NFS mount a special, internal application? - What about my game session? - My ssh session to a server? Define 'very long term'? >From an IPv6 ISP I'm probably safe up to a week. However, if my global connection is from a hot spot or 6to4 address I have very little guarantee that the prefix will persist more than a few hours. In contrast, my local address prefix is guaranteed to last as long as the router or network does. Applications that don't do forwarding of IP addresses simply need an address that they can route to. The local address is as good as any, and has the nice side effect of being more robust against failure (or deprecation) external to the site. Applications that do forward IP addresses can't a-priori trust any address, since they can't know where the filters are (if any). Safe strategies include: - manual configuration - send DNS names and let the target choose - send all available options and let the target choose (this isn't a very good option) - additional information I'll also note that no deployment is forced to use local addresses - if someone or something doesn't configure them then they won't exist. There is a solution that will cause all these considerations to be obsolete - strictly enforce one (and only one) address per node. And ban filters while you're at it. Any takers? Side point: a policy which allows for local addresses but auto-deprecates them when an external address becomes available causes local addresses to lose one advantage - the local address is now subject to failure because of site-external events. > I would like to point out again, that as per my suggestion, nodes MUST > NOT send, receive or forward traffic in which the source and destination > addresses are not of the same scope. I think this is unnecessarily stringent. Certainly nodes should prefer not to send packets with non-matching 'scopes' (see "default address selection"), but I don't see it as an error condition to do so. -- 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] --------------------------------------------------------------------
