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. > |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... > Hasn't this been the idea behind scoped addressing from the > beginning? I realize that there have been suggestions recently that > you should always use a global address if one is available, but > that's not a problem with scoped addressing--it's a way to > deliberately break scoped addressing. > |Note that it is not enough for a handful > |of applications to use SLs and survive renumbering, my assumption is > |you want pretty much all intra-site communication to use SLs. I.e., if > |only 30% of your intra-site traffic is using SLs, and a renumbering > |takes place, 70% of your traffic is still potentially impacted. That > |doesn't seem like much of a real solution to me. > I believe that your assumption is false. If the 30% consists of a few > critical builds running over a remote file system, security information, > etc., while the 70% represents much less important traffic then there > could still be significant benefit. Fine. How do you ensure that the critical applications do in fact use SL addresses? How do you even know which ones are "critical"? Isn't critical in the eye of the user? > |I have yet to see what I believe is a credible approach to getting > |applications to prefer SLs across the board. Some people suggest we > |need to do split DNS. But their is no real consensus in the community > |for doing this. For example, I'll note that the DNS community has > |never been willing to officially bless split DNS behavior. They > |understand folks use it, but there are problems with the approach, and > |the DNS community has never had consensus that the benefits outweighed > |the problems. Hence, no IETF spec officially advocates split DNS, > |AFAIK. So, approaches that rely heavily on split DNS being even more > |widely deployed that it is already (e.g., in homes and other places > |with no clueful operations support) seems like an uphill fight at best > 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. > 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. > All my automation services would then be protected from ISP > renumbering. I can do something similar with file servers. And > please let's not get into a debate about the impurity of using > different names to reference different addresses on a single > machine. We were doing that long before the DNS existed. > It is true that site-locals do not by their mere existence automatically > protect a site against renumbering, but that is a straw man. Site-locals > allow a site that cares to protect connections that it cares about. This > is an important capability. Do not be so quick to dismiss it. 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. Thomas -------------------------------------------------------------------- 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] --------------------------------------------------------------------
