Erik Nordmark <[EMAIL PROTECTED]> wrote:
|Looking at your resarch ship case a bit more in detail it occurs
|to me that even using site-locals plus globals while connected doesn't
|necessarily protect the local communication. The introduction of the
|global prefix/addresses when the ship is connected might very well
|trigger different address selection behaviors in the stack or in the
|applications. Thus it seems like the robustness provided by site-locals
|only apply to communication established (and addresses selected)
|before the global prefix is introduced. Later communication is subject
|to any bugs or poor interaction in the address selection domain - something
|that is bound to have some corner cases due to its complexity.
It goes without saying that bugs in the implementation can cause problems.
This (and similar claims being made by other contributors) is not a valid
argument against site-locals. Bugs in the implementation of any solution
are going to cause problems. Unless you have a solution that is demonstrably
_so_ much easier to implement that the chance of its having bugs is materially
smaller then there is no point in trying to make such a comparison.
|(Note that this is a property that applies to #1 in my list that I've
|previously not realized.) While the effect of this probably is less than
|the effect of renumbering the ships network each time it attaches to the
|Internet, it still doesn't isolate the ships internal network from
|being attached to the Internet when site-locals are used as you propose.
Site-locals and scoping allow sites that care to isolate connections that
they care about from global prefix changes. Nobody has ever claimed more.
You are generalizing the problem to the point where it cannot be solved and
using that as a justification for not allowing a solution in the simple cases
that people actually use.
|So if I were to design this ship I'd use neiether renumbering at
|attachment time nor site-locals. Instead I'd have the research ship get
|a stable prefixe (a few /64's might suffice) from the organization that runs
|it which are globally unique and can be used whether the ship is connected
|or disconnected. This completely isolates the addressing of the ship internals
|from whether it is connected or disconnected; the only difference is the when
|disconnected off-ship destinations are unreachable.
This is in effect giving the ship "virtual" PI space. I'm all in favor of
PI space as long as it is available to everybody.
|When it gets connected
|tunnel(s) need to be established back to the research organization in order
|for routing to work. Such tunnels could be cobbled up today with some existing
|tunnel establishment mechanism, and the Nemo WG is working on an IETF standard
|for such tunnel establishment.
It's good to see that folks are coming around to my way of thinking. Note
that with auto-tunnels such as I once proposed the routing becomes more and
more efficient as more and more sites buy into the system to get virtual PI
space. In the limit the tunnel always connects the endpoints and you are
down to the encapsulation overhead.
|So if you want internal stability you have to
|pay by having less efficient routing - going bidirectionally over the tunnel
|to "home" - no free lunch.
Great. Tunnel-based routing is a tradeoff that I (and I suspect some others)
would be happy to make in exchange for stable address space. How can we make
sure that this option is in fact available to everyone who wants to use it?
Making globally unique "unroutable" (but tunnelable) address space available
would be a good start.
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]
--------------------------------------------------------------------
