> 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'? >
I was refering the Moore-Hain discussion in the "local vs. nonlocal address stability" thread. [snip] > 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 > My suggestion is to use scoping explicitly; the application will KNOW that packets with mismatched address scopes WILL get filtered in the first node they encounter. Nodes may still do address selection as per your suggestions, but only if the source node and the destination node have several configured addresses in shared scopes. > 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. > agreed. > > 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? > I think we already know that there is a strong opposition to that. > > 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 never suggested that. I don't think anyone does. > > > 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. > I think that anything less than that will take us again to the currently ongoing debate. I'm in favor of answering the major requirements, and otherwise keeping things simple. In my eyes, the major requirements are: - Provide an addressing solution to disconnected networks. - Provide address stability, at least internally. - Allow various administrative scenarios (merging, connecting/disconnecting the internet), while minimizing the chance to harm other entities (implying uniqeness) - Make address selection, and applications in general, as simple as possible; make it even simpler to the users Regards, -- Nir Arad -------------------------------------------------------------------- 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] --------------------------------------------------------------------
