Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve

From: Dan Lanciani <[email-masked]>
Date: Sat, 5 Apr 2003 15:24:11 -0500 (EST)

=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]> wrote:

|On lördag, apr 5, 2003, at 00:37 Europe/Stockholm, Dan Lanciani wrote:
|
|> Great.  Let's make this PI space available FIRST and THEN we can get 
|> rid
|> of site-locals with little trouble.
|>
|> |Yes, aggregation can not happen,
|> |but, so what? I claim the number of routes today is still manageable,
|> |and the _real_ problem is that an IP address is both for addressing 
|> and
|> |routing.
|>
|> Great.  Let's work on that problem now.
|
|Yes, of course we should. But, I think we can not get real force behind 
|such work before we _first_ agree Site Local is not solving this 
|problem, and we therefore agree Site Local should go away.

Please help me to understand something.  I have been trying to get people to
look at the portable identifier/routing problem for _years_.  Such attempts
have been consistently shot down, often on grounds similar to the ones being
used to attack site-locals, e.g., that we don't understand the problem well
enough to even know whether research or engineering is required.  (And no,
I don't really understand why this--even if true--is a reason to not look
at a problem.  But that's a different question.)  In fact, I believe some
of the same people who want to deprecate site-locals are making the same
arguments they used against solving the routing problem.  Now, in all those
years, nobody ever raised the claim that site-locals were an obstacle to
working on the routing problem.  Explain two things:

-When (and how) did site-locals become the main obstacle standing in the
way of solving the routing/identifier problem?

-When (and how) did all the other reasons that have been advanced to stymie
any work on the routing/identifier problem evaporate?

				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: Sat, 05 Apr 2003 16:12:57 -0500

Hi Dan,

>look at the portable identifier/routing problem for _years_.

Various people _have_ been looking at this problem for years.  In fact,
the IPv6 WG toyed with it for a while in the mid-1990s.  I agree that
this is _the_ problem that we (the IETF, not necessarily the IPv6 WG)
need to fix if we want to have an architecturally clean Internet that
scales.  Is there a particular solution (or type of solution) that
you favor?

>way of solving the routing/identifier problem?

I don't see site-locals as an obstacle to solving this problem at
all.  So, if I said something that gave you that impression, I must
have been unclear.  The only obstacle to solving the routing/identifier
problem (that I know of) is that we haven't found a solution to it (yet).

So, people are currently forced to choose between global-routability
and provider-independence in a particular address; no address has
both properties.  Some people will choose provider-independence over
global-routability for (some of) their addresses.  So, until we
can solve the routing/identifier problem, we will be stuck with some
type of provider-independent, local addressing.

I just happen to think that site-locals (the FECO::/10 prefix, with
the semantics currently defined in the scoped addressing architecture
I-D) are a very poor way to provide local, provider-independent
addressing.

While local (non-globally-routed) addresses will always, by definition,
be unreachable from some portions of the network, there is no reason why
they need to be ambiguous.  The ambiguity of site-locals creates a great
deal of complexity, and imposes unnecessary limitations on their use.

As long as people use firewalls for security, we will have unreachable
addresses, and there really isn't any fundamental difference between
an unreachable local address and an unreachable global address.
Applications already have to deal with the fact that some addresses
will be unreachable, and people who intentionally make some of their
addresses unreachable already have to deal with the consequences
(split DNS, inability to use some applications, etc.).

But, there really isn't any excuse for creating ambiguous IPv6 addresses
and expecting applications, routers and other parts of the protocol
stack to deal with them...

>any work on the routing/identifier problem evaporate?

I never once suggested that there is a reason not to work on this
problem.  In fact, I think that it is vitally important to solve
this problem, and people are working on it (in the IRTF and the
multi6 WG, among other places).  If you have a viable proposal to
solve this problem, I'd love to see it.

Margaret

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 6 Apr 2003 10:02:40 +0200

> any work on the routing/identifier problem evaporate?

<rant>
 From my point of view, as an apps person, people stopped looking at 
these alternatives when they found out they can force applications to 
have clue about routing topologies, force applications to use this clue 
to do clever source address selections, and more people started 
thinking Site Local was not only a solution to this, but also the magic 
pixie-dust which solves other problems as well.
</rant>

The problem I see is that we have the classical hammer problem here. 
You have a hammer, or manage to define something which looks like a 
hammer, and feels like a hammer, and then you look for nails.

This is something we see in many areas of the IETF, including 
Applications Area where I was Area Director for 5 years until March 
this year (so I am not blaming other Areas for these things).

Maybe it is because Internet technologies are so difficult to 
understand nowadays one only look at a solution within the space one 
work in, and then ignore (more or less) the cost in other areas?

Take the multiple addresses for example, which applications people hate.

The way an application do it's work is like the following:

- Take a hostname
- Call gethostbyname (and get a struct back with (at least) one IP 
address)
- Ask the IP strack to connect to whatever is described by that struct

That's pretty simple, isnt't it?

Further, another general rule for applications is:

If A uses address a(B) to contact B, C should also use a(B), because so 
many applications work in a scenario where A send to C not "B", but 
a(B), i.e. the address.

So, for applications to work, one need to only use global addresses all 
the time. Or, one can patch in local addressing by using things similar 
to split-DNS, which really is not a fun thing, because one get a view 
of the world which is different depending on where you are looking 
from. I.e. context dependent.

Note that I only talk about addressing in the above. Not routing.

So, yes, it would be very natural to talk much more about 
differentiating between routing and addressing.

Maybe one doesn't talk about it because for example apps and internet 
people don't talk so much with each other?

     paf

---

From: Ronald van der Pol <[email-masked]>
Date: Mon, 7 Apr 2003 17:10:03 +0200

> people don't talk so much with each other?

It is interesting to note that on one side there is a move to a
dumb (core) network and move complexity to the edges. On the other
hand there is the layering argument that applications should not
know about topology.

What _exactly_ should the "ideal" network provide as a service?
Two extremes are probably:

- Applications deal with several (locator) addresses.
  Input to the network layer are two (locator) addresses (src and dst).
  The network delivers packets between exactly one pair of (locator)
  addresses (multiple path may exist between these addresses).
  The upper layers pick the "best" source and destination (locator)
  addresses.
  The upper layers react when a path breaks.

- Applications deal with one identifier.
  Input to the network layer are two identifiers (src and dst).
  The network picks the "best" path out of several (probably by
  choosing the "best" (locator) addresses).
  The network reacts when a path breaks.
  The upper layers use some kind of stable identifier instead of a
  (locator) address.

Where do we put the complexity?

	rvdp