> It is not a red herring. Input sent to me for the requirements doc: But this case is exactly the same as what I categorized as #1 in my list - isolating communication local to the site from site renumbering. The only added twist is that site renumber occurs when the site attaches and detaches from the Internet.
> Research ships at sea intermittently connect via INMARSAT, or when in > port, the shipboard network is connected to shore via Ethernet. 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. (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. 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. 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. 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. If you believe in Mobile IPv6 route optimization you might also believe that the Nemo work can be extended to provide route optimization to/from correspondent nodes in the Internet at large (by reusing the MIPv6 approach). I personally think the utility of this remains to be proven, but if it is it would help with the routing inefficiencies caused by routing. So once again, this is not a case where I think site-locals help. Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
