Thomas Narten wrote: > Dan Lanciani <[EMAIL PROTECTED]> writes: > > > I can't speak for others, but to me it is very interesting (and > > important) to have internal connections that are not at the > mercy of > > my ISP's renumbering policy. > > I agree that this is a very desirable property to have. But > wanting this doesn't mean we know how to achieve it.
Then why insist on taking away the current tool that does achieve it? If we don't have a viable replacement that works at least as well, it is irresponsible to deprecate the tool that currently does the job. > > > |The tough question is, how do we get applications in general to > > |prefer SLs for local communication. > > > If an application wants to maximize the stability of its > connection it > > always uses the addresses of smallest scope that will do the job. > > How do applications get addresses? In my experience, a lot of > them get them out of the DNS. But, if we put SLs into the > DNS, we have to have split DNS... We need to do that anyway, because there is no valid reason to leak filtered addresses outside of their scope of routability. Ambiguity is the ruse that is use to make this an issue, but the real issue is that resolving a name to an address that is not routable from that point is a broken concept. Even if a site uses global scope addresses for its internal use nodes & applications, a name resolution that includes both filtered and unfiltered addresses will cause applications that falsely assume a single address scope to fail. > ... > > Well, personally, I'm getting a little tired of worrying > about what is > > and is not blessed. People will use what works. > > I take it from the above that you believe that making split > DNS work is trivial and obvious, so folks can and will just > use it no problem. My point is that the community doesn't > seem to be in complete agreement about that, which means > there are almost certainly subtleties and potential gotchas > that can and will get in the way. If it were just trivial and > obvious how to do this, I somehow doubt folk would have > issues with split DNS. >From my observations, the IETF DNS community considers the reality of route filtering to be the edge of their flat-earth. What that perspective misses is that there are nodes that live in both worlds and need tools for a view that matches the network reality. From RFC 791: The function or purpose of Internet Protocol is to move datagrams through an interconnected set of networks. 'Interconnected' does not say without filtering, so if the IETF is responsible for the Internet Protocol and the associated infrastructure, it should also be responsible for defining infrastructure components that match the reality of the deployed network. > > > That said, I see no need to use split DNS in order to benefit from > > site-local's stable internal connections. As an example, my own > > network already uses separate names for the automation > services that > > are accessed internally. Currently these are aliases for > the global > > v4 addresses of the hosts which support the services. Under v6 I > > could change them to the site-local addresses of those same > machines. > > So, in your system you have two names for the same service, > one for the global address, one for the internal address? And > if you are inside your site, you use the internal name, and > when you are outside you use the external name? > > If this is the basic idea, I suspect most users won't like > this approach and will not consider it to have solved the > problem acceptably. You are probably correct about most users, but the job still needs to be done and if the IETF only gives you a hammer ... > ... > I've seen people say they think SLs are important to protect > internal communication for years. The problem is I still > don't see a coherent proposal for how this can be made to > work in practice that seems to solve the problem in a > reasonable way for a broad class of users. Back to back internal/external servers with a replication process that ignores records with the local prefix. It is more expensive, but I haven't seen any arguments that it raises technical concerns. Setting that up for a broad class of users that includes consumers would most likely require a consistent local use prefix for the replication process to key off of. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
