Patrik Fältström sent this message to the IPv6 list many hours ago, but it hasn't appeared on the list. I told him that I would resend it for him, so here it is...
Margaret
From: Patrik Fältström <[EMAIL PROTECTED]> Date: tor apr 3, 2003 15:25:51 Europe/Stockholm To: [EMAIL PROTECTED] Subject: Why SiteLocal is not what solves the problems people want to solve
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 PROTECTED] --------------------------------------------------------------------
