On 06/11/10 02:48 AM, Zach Shelby wrote:
Yep, I agree with Erik here. In an enterprise environment you will be able to manage the whole 6LBR infrastructure (and the contexts), so we are OK there. In home environments you will probably keep LoWPANs separate using L2 encryption.
OK
However as public/urban 6LoWPAN networks become more common (we are deploying one right now in Oulu, Finland), there will be situations where a 6LR will hear RAs originated from different authoritative border routers with different points of attachment to the Internet (and different sets of context). We have two choices what to do in this situation:
I think it is hard to discuss what technical approaches we should take here without understanding something about the envisioned usage and associated business model.
The notion of having devices that pick up on any (wireless) connectivity and just try to use it isn't something that we've seen anywhere else.
For instance, for a cell phone there is a business arrangement with an operator, combined with roaming agreements between operators, which ensure that the cell phone connects to a predictable set of operator networks. (And in many cases the user can control the selection.) For free WiFi networks there is normally a user interface where the user can choose which network to associate with.
In both of those cases there isn't likely to be a radical change just because the radio connectivity changed.
What mechanisms will there be in this public 6LoWPAN for devices to select which 6lowpans they will participate in? What prevents the public 6LoWPAN from interfering with devices that are part of a (private) factory or building 6LoWPAN?
a) Say nothing about it. Here we have a risk that a poor 6LR implementation will start mixing contexts, or will even advertise two sets of RAs - which is obviously broken. This is the case Daniel (and myself) are concerned about. b) Explicitly say what the 6LR should do in this case. If we explicitly forbid a 6LR from attaching to two different LoWPANs at the same time, then this fixes this potential problem (it can obviously still attach to multiple default routers in the same LoWPAN). This way the host -> 6LR -> 6LBR attachments are always under the same authoritative border router (which might be a coordinated one as pointed out above).
I don't think the fact that the network is route-over and we have 6LRs introduces anything fundamentally new. A single-hop network where the hosts hear RAs from multiple routers is just as problematic. For example, the host might configure an IP address from the prefix of operator A, and the packets get routed via operator B, and ingress filtering blocks all those packets. (That is a fundamental issue in what could be called "ad-hoc multihoming"; nothing specific to wireless or 6LoWPAN here.)
You say "forbid a 6LR from attaching ..." but there isn't any notion of attaching to a network in IP. This is something that is handled below IP (802.11 associations, PPP authentication, VLANs, or early stages of IP configuration in the case of PANA.)
The issue is that at whatever level that association happens, the same level needs to provide sufficient isolation with respect to routing. That is necessary to avoid the mismatch between the addresses a node configures and where its packets are routed.
Erik _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
