Thomas Narten <[EMAIL PROTECTED]> wrote:
|> |Thomas Narten <[EMAIL PROTECTED]> wrote:
|> |
|> |> - Site-locals should be retained as a means for internal
|> |> connections to survive global prefix renumbering.
|> |
|> |4) This is strikes me as a nice requirement, but something we don't
|> | have a solution for, even with SLs. We need to accept that we have
|> | no solution and SL is doesn't really seem to be a help here.
|
|> Please explain why you feel that internal connections using site-locals will
|> not survive global prefix renumbering.
|
|Internal connections using SLs will survive renumbering. But that is
|the easy part and by itself is largely uninteresting.
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.
|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. 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.
|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. 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. 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.
|So, IMO, the notion that SLs protect a site agains the impact of a
|renumbering event is one of those IPv6 myths for which there is no
|real story to back up the desire. I wish it were otherwise.
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.
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]
--------------------------------------------------------------------
