Patrick wrote:
[...]
|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).
Ok, so let's fix all the IP stacks to use names in the packets and in their
APIs. Then we can fix the DNS to track renumbering events. Once that is
done we can get rid of site-locals for good.
|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....
You are the third person in the last 24 hours to assert that site-locals
cannot provide for stable internal connections. Such assertions (which
are obviously based on unstated assumptions about how perfectly any such
solution must work) are very disturbing. The deprecation of site-locals
supposedly came with some vague assurance that we would look at alternate
ways to provide the functionality that was being removed. It is far too
convenient to say that in retrospect site-locals never did provide for
stable internal connections and thus we need not consider a replacement (or,
as others have claimed, that we don't even know how to provide a replacement).
Moreover, I'm concerned that stable internal connections will join the growing
list of "features" (including the high availability that should have come from
multi-homing) whose recommended implementation reduces to: send your ISP more
money.
[...]
|I rather see (in my possibly na�ve view) sites like
|this really getting PI address space.
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.
[...]
|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
I have made proposals over the years for portable identifiers. Did you
support them?
|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.
Great. Let's fix the routing problem FIRST and THEN nobody will care
about site-locals.
|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...
I can't imagine why you would even ask if site-locals would address this
hypothetical issue in a hypothetical solution...
[...]
|Just Say No to Site Local.
Why not try a more positive approach like, ``Just say yes to PI space.''?
All of the things that you suggest have been proposed many times over
the years. They are consistently shot down as impossible. In fact, it
is common knowledge that merely talking about PI space can cause the immediate
death of the net as we know it--unless of course you talk about PI in
conjunction with the deprecation of site-locals. The it's ok because we
know that once site-locals are gone we can forget about PI again...
Dan Lanciani
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
