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

From: Alain Durand <[email-masked]>
Date: Fri, 04 Apr 2003 10:27:09 -0800

This message did not go through, I'm resending it on behalf of Patrick.

    - Alain.

I have been quiet on this list, but have been talking with many many 
people about the view I as an application person have on Site Local.

I don't like it.

I have seen a few cases which people bring up where site local would be 
useful:

[1] Networks which are intermittently connected
[2] Networks which have multiple upstream providers, and they want to 
have a contiguous addressing scheme internally in the network
[3] Networks which should not be reachable from the Internet

Let me address them one by one:

[1] Let's say we have two computers connected to a home network. They 
communicate with each other without any problem regardless of what 
addresses they have, but, when the network is connected, we end up 
having problems.

If all nodes are renumbering, the 5-tuple which identifies existing 
flows between the computers will change which means that existing 
communication will break.

But, this is a well known fact, and nothing we can do anything about. 
An application *should*always* use the hostname when communicating, and 
that imply it should not cache the IP address of the peers or itself 
between the flows are initiated which it needs. Yes, applications fail 
regarding this, and IP stacks are too bad at keeping the local IP 
address which happen to be assigned at the time a "listen" call is 
made. Application should be better at this, and I claim they _are_ 
getting better as computers more and more move around already today 
(due to DHCP, 802.11b etc).

The broken 5-tuple is not much we can do anything about, BUT, 
site-local is not solving this problem either. Yes, I know the idea is 
that when two nodes can share the site local scoping to minimize the 
risk for the 5-tuple to break....

More below why this kind of solution is broken.

[2] Networks which have multiple upstream providers have two prefixes 
they can choose from. Question is whether the network should use one, 
or the other, or both (or site local, neither) prefixes. This is of 
course something multi6 should take care of, but, from an application 
point of view, having multiple addresses because of routing issues is 
not a good idea. I rather see (in my possibly naïve view) sites like 
this really getting PI address space. 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.

Having a third prefix (site local) which is used will force the use of 
NAT, and I really hope people understand how bad NAT is. I will not 
here repeat what I hope will end up in a document which Leif and Keith 
is writing about address management in applications. Applications which 
partially one can say is broken as they use IP addresses in the payload 
and not domain names, BUT, applications we have today. Applications we 
can not get rid of (like ftp, sip etc).

[3] This is the most stupid idea...that NAT == Security...and because 
of that, nodes which only is thought of initiating flows towards 
something else should be behind a NAT. Security is one thing, 
addressing another. If an address is not to be accessible, filter out 
packets to it. A firewall doesn't have to include NAT functionality. 
Yes, many do, but I also think for these reasons many of them are 
broken.

What one have to remember when talking about all of these problems is 
how the Internet should work. Not how it is implemented today, because 
things like NAT etc do exist, and yes, we will continue to see it for a 
while.

First of all, we have one big mistake regarding addressing, and that is 
the overload of use of the IP addresses. We use it both as a unique 
identifier of an endpoint and for routing. addressing != routing

This has created the problems we have with the routing protocols of 
today, as the Internet is no longer hierarchal. It is a mesh, a 
complete mesh. And, when navigating a mesh, one need different 
algorithms and mechanisms than when navigating a hierarchy. Site Local 
will not solve this problem.

Secondly, the 5-tuple we use for flow identification is rigid, and we 
don't accept a change of any of the 5 values without having an 
interrupt in the flow. Maybe we should have some ICMP which say "please 
redirect flow to this address"? How to secure it? Will Site Local solve 
this problem? Don't think so...

Thirdly, I think it is important applications uses names of things 
(domain names for example) when talking about and with others, while 
the IP network is the one which should know about the IP addresses. 
When an application have to know about the underlying network topology 
I would get very very nervous. Yes, FTP and SIP uses IP addresses, and 
I am not defending those two protocols. They are possibly flawed, but, 
even if they use the domain names in their payload, they don't have to 
know the topology (=routing) to know what source address they should 
use in a multihomed network.

As someone said at the meeting in San Francisco: The day an application 
is required to know about routing and network topology we have a 
layering violation.

I could possibly continue for a while, but I will stop here.

Just Say No to Site Local.

Or, as we say in Sweden "Gör om, gör rätt". ("Try again, and do it 
right this time")

	 paf

--------------------------------------------------------------------
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: "Michel Py" <[email-masked]>
Date: Sat, 5 Apr 2003 11:20:22 -0800

Margaret,

> Margaret Wasserman wrote:
> Tony, allowing an interface to have two addresses:
> - One that is globally routable and globally accessible,
>      and
> - One that is stable and local,
> is _exactly_ what I am proposing.
> However, I am proposing that there is _no reason_ why
> the stable, local addresses have to be ambiguous.

These are worthy goals and I like them very much. However, given the
history, I think you put them in the wrong order. I would like to see:

1. - One that is stable and local and not ambiguous.
then
2. - One that is globally routable and globally accessible.

Although there is nothing that says that 1 needs to be delivered before
2, I will remind everyone that the quest for 2 has started 10 years ago
and that we still have to see a result. As of 1, it has its own set of
challenges, one being that there must be some kind of architectural
limitation to prevent it to become 2 with a routing table explosion. I
will post soon more details about what I think is required to achieve 1.

Michel.

---

From: Dan Lanciani <[email-masked]>
Date: Sun, 6 Apr 2003 05:08:14 -0400 (EDT)

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

|On lördag, apr 5, 2003, at 22:24 Europe/Stockholm, Dan Lanciani wrote:
|
|> -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?
|
|<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>

I understand why you might think that (especially given the recent discussions)
but if you review the archives for the past few years I think you will see that
site-locals did not play a significant role in discouraging the development of
real routing/identifier solutions.  Frankly I find it really disturbing that
the issues are being coupled this way.

				Dan Lanciani
				ddl@danlan.*com

---

From: "Michel Py" <[email-masked]>
Date: Wed, 9 Apr 2003 21:40:31 -0700

Ronald,

> Ronald van der Pol wrote:
> 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?

These are not mutually exclusive. The first one would likely be used in
a soho-like multihomed site and the second one in a large organization
setup.

Michel.