Subject: Re: Why I support deprecating SLs

From: Dan Lanciani <[email-masked]>
Date: Thu, 3 Apr 2003 21:24:37 -0500 (EST)

Thomas Narten <[email-masked]> wrote:

|> |Thomas Narten <[email-masked]> 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
				ddl@danlan.*com
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 21:41:39 -0500

>I realize that there

It is also a way to avoid breaking Mobile IP.  And, it is a way to
avoid losing your connection if the site becomes "concave" or
fragments due to a router or link failure...

>is an important capability.  Do not be so quick to dismiss it.

Do you really need site-local addresses as currently defined
(ambiguous, scoped address) to achieve this?  Or would it be
better to have your own globally-unique, provider-independent
prefix (perhaps assigned by a registry) that wouldn't require
any special treatment from hosts, applications, etc. and that
you could choose to filter at your firewalls?

Margaret

---

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Apr 2003 21:58:55 -0500

Dan Lanciani <[email-masked]> 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.

> 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.

> 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?

> 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.

> 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

---

From: Scott Bradner <[email-masked]>
Date: Thu, 3 Apr 2003 22:17:38 -0500 (EST)

> prefix (perhaps assigned by a registry)

I do not see how this could work without blowing up the routing tables 

(CIDR 101)

Scott

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 22:32:13 -0500

Who said that they need to be globally routable?  If the purpose
is for private addressing, there is no need to route them.

Margaret

---

From: [email-masked]
Date: Fri, 04 Apr 2003 14:01:23 +1000

> I do not see how this could work without blowing up the routing tables 

	This prefix would *not* be advertised into the global routing
	table.  You would have *other* prefixes for those machines that
	wish global connectivity assigned from your access providers.

	This is a prefix to replace the "site-local" prefix.  

			     site-local    private prefix

	* globally routable	NO		NO
	* locally routable	YES		YES
	* privately routable	NO		YES
	* ambigious		YES		NO
	* DNS			NO		YES
	* requires second	YES		YES
	  prefix for global
	  reachability.
	* allows intra site	YES		YES
	  connections to
	  survive renumber
	  events
	* requires renumber	YES		NO
	  on site mergers

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Scott Bradner <[email-masked]>
Date: Thu, 3 Apr 2003 23:04:26 -0500 (EST)

> Who said that they need to be globally routable?  If the purpose

you had edge filtering as an option - 

how would you ensure they would not be routabe?

and if they are not, just how are they all that differennt than
site-local (seems to me that all of the same problems are there
except for two sites merging

Scott

---

From: Greg Daley <[email-masked]>
Date: Fri, 04 Apr 2003 14:49:43 +1000

Hi Scott,

 > I do not see how this could work without blowing up the routing tables

V4 address allocation systems today are based on
registries, and provide CIDR (albeit in some cases poorly).
This aggregation is basically because short prefixes are
managed in blocks.

The idea of Globally Unique Provider independent
is a good idea, if it can be made workable.
GUPI doesn't have to be routable.

The ideal goal for many is to have Globally Routable
Unique Provider Independent.

Tony Hain currently has an interesting idea about providing
uniqueness based on geography (not the first time this
has been attempted either).  Tony's idea is geographically
aggregatable, and may provide a base routable model
in some cases.

Of course, geographic systems need to be worked out to
determine how routes are advertised outside the domain,
but there is a potential that similarly located addresses
could be used to provide aggregatable blocks.
These address blocks could be used in Internet communication,
and allocated based on land occupancy, or (apartment
block/city/jurisdictional) regional cooperation.

Greg D.

---

From: Scott Bradner <[email-masked]>
Date: Fri, 4 Apr 2003 00:02:41 -0500 (EST)

> Unique Provider Independent.

its a great goal, too bad it runs up against the reality of 
the routing protocols

> aggregatable, and may provide a base routable model
  
that also would be gerat and as soon as there is a reasonable level of
local ISP to ISP connectivity it just migt work (but that could take a
rather long time)

Scott

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 4 Apr 2003 09:07:15 -0800

Thomas Narten wrote:
> 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. 

> 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

---

From: Bill Manning <[email-masked]>
Date: Fri, 4 Apr 2003 09:33:31 -0800 (PST)

% > 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. 
% 
% Tony

	This is something else that seems to have crept out of the 
	woodwork.  Split DNS.  Doe folks really think that this
	"feature" is going to be required in addition to mandating
	a functional DNS?

	If so, what does this say to/about the IAB statement on the
	requirement for a single DNS context?

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 4 Apr 2003 13:41:47 -0800

Bill Manning wrote:
> ... 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. 
> % 
> % Tony
> 

As I recall, the IAB statement says there must be a single root for the
'public name space', and I agree. It does not say we must leak
information about filtered addresses outside the scope of the private
network. The requirement to do that is coming from members of the app
community who insist that despite the reality of private use address
space, their right to build 'ignorant apps'R (pass opaque blobs around
without a clue about the validity of the content at the receiver)
supercede the rights of the network manager to get his job done. 

The argument 'passing around blobs doesn't hurt as long as the values
are not ambiguous' ignores the fact that the network manager that put in
the filter may not want information about internal use nodes exposed in
any shape or form, because configuration errors do happen. The DNS (and
for that matter every name resolution mechanism) needs to be aligned
with the reality of the topology that it is handing out locators for.
The DNS as deployed was defined for the unified Internet of 1985, while
the current Internet includes routing filters (addresses with limited
scope). This discrepancy needs to be fixed. The implementation of the
fix may or may not include what we currently see deployed as split-DNS.
Maybe it is time for a complete overhaul (DNSng) to deal with this and
make the system capable of handling the identifier role being discussed
wrt the multihoming problem.

Tony

---

From: [email-masked]
Date: Sat, 05 Apr 2003 10:01:34 +1000

> 	requirement for a single DNS context?

	There are alternatives to split DNS.  I would hope that the
	WG would take up those alternatives if it keeps site-local.

	They would be useful even with the alternatives to site-local
	by putting reachability information into the DNS.  However
	now in not the time to debate this.  Lets get site-local
	decided first.

	Mark