Subject: Fwd: Why SiteLocal is not what solves the problems people want to solve

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 20:26:00 -0500

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-masked]>
>Date: tor apr 3, 2003  15:25:51 Europe/Stockholm
>To: [email-masked]
>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-masked]
--------------------------------------------------------------------