I tend to agree with Erik on the research ship case; since the ship is a rather large and coherent entity (most likley owned by an even larger organization) it makes sense for it to have one or several globally unique prefix assignments that can be used whether/not the ship has a connection to the global Internet. But, I still havn't seen a solution proposal for ad-hoc networks of individuals that come together for arbitrary purposes and wish to form a network.
For example, if Bob, Ted and Alice find themselves in a common space with no proximity to an Internet access point, they should be able to form a network and have persistent communications that survive even if an Internet access point is later encountered. But, since Bob, Ted and Alice are just private individuals, it seems unlikely that any would own a globally unique prefix - so how do they decide on a common prefix to use that supports communications even in the intermittently-connected case?
I have seen at least one IEEE 802.11 product vendor that solves this problem at the MAC layer by choosing the MAC address of the first node to join the network as the I-D to use for the IBSS (i.e., the ad-hoc network "cluster"). When two nodes come together for the first time, there is some sort of tie-breaking to decide whose MAC address will be used. When multiple IBSS's merge (e.g., when John and Sue join), the I-D of one IBSS is chosen as the I-D of the merged IBSS. When, an IBSS partitions (e.g., when John and Alice leave) new I-D's are chosen.
But, this all seems too dynamic of a model to adopt for choosing network-layer addresses in which stable addresses are needed both regardless of the underlying topology dynamics and without a provider-assigned prefix. How do we solve this?
Fred [EMAIL PROTECTED]
Erik Nordmark wrote:
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] --------------------------------------------------------------------
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
