Thomas Narten <[EMAIL PROTECTED]> 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.
We know how to achieve it. You may not like the way we achieve it because
it doesn't meet your standards for architectural purity, but until you have
a better approach, how about letting use keep our impure solutions?
|> |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...
As I explained below, you don't have to use split DNS. But people do
use split DNS and if they are satisfied with the result, who are we to
tell them to stop? This notion of giving up critical functionality
today so that perhaps in the future we will get back some subset of that
functionality in a more pure form just doesn't fly in the real world.
|> 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?
By configuring them to do so
|How do you even know which ones are "critical"? Isn't
|critical in the eye of the user?
How do you know which machines need uninterruptible power supplies? How
do you know which switches need redundant links to the backbone? You seem
to be suggesting that a solution is no good unless the protocol automagically
makes decisions about which applications are critical. In the real world,
people make these decisions all the time. In the real world, people probably
don't even _want_ your protocol to be making these decisions for them.
|> 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.
I can't imagine why you would take it that way. Believe it or not, in
the real world, people are sometimes capable of doing things that are
_not_ trivial and obvious. Especially when they have no alternative.
|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.
The "community" is never in complete agreement about _anything_. There
are always subtleties and potential gotchas. This is a characteristic
of all but the most trivial systems. It is not an adequate reason to abandon
a useful solution, especially when you offer no alternative.
|> 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?
No, I have only one name for a given service and the services are available
only internally. I have other names for the hosts that happen to run the
services. Those names would continue to point to a global address in my
v6 scenario (unless of course the machine had no global address at all). I
would use the same name to, e.g., telnet to the machine from inside or outside.
Telneting to the machine is not the kind of critical, long-term connection that
I feel I need to protect from renumbering. Other sites might have different
ideas about which connections are critical and they would configure accordingly.
|And if you are
|inside your site, you use the internal name, and when you are outside
|you use the external name?
No, because these services are internal-only. That's the whole point.
|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.
I suspect that you suspect wrong. People are using these (or worse)
models in conjunction with NAT. These models are well understood.
If you do not wish to support them cleanly in v6 with scoped addresses
people will use NAT (unless you give them PI addresses). If you also
manage to eliminate NAT from v6, people just won't use v6.
|> 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.
I'm afraid that in the real world people have to get by with solutions
that do not rise to the level of perfection that you seek. If you deprive
users of the flexibility they need to implement the obvious solution they
will probably find a way to do something that you will like even less. If
you purify the protocol to the point that users really can't do what they
want, you won't have any users to worry about.
Dan Lanciani
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
