Hi, >From the discussions on this thread, it seems that there is a room for some mis-configuration or mis-interpretation of the intent of usage of the current low-power-nd draft in case of multiple 6LBRs.
I agree that in the body of specification, we may not want to impose too much restrictions based on a specific deployment, however, if it helps the implementors and early adopters to provide some guideline on possible problem avoidance - it makes sense to provide such examples/guidelines in the Appendix section. Will that be a workable solution? We know that the separation of two LoWPANs are expected to happen in L2 [ assuming the lowpower networks are configured with proper L2-security]. Also implementation of 6LRs can have knobs to reject/ignore mismatched prefixes from different 6LBRs. I have heard some discussions in a deployment where they might want to do ND-09 RS in a unsecured link to get RA first to find out the default-router address and use PANA authentication mechanism to get a group key for L2-security. This breaks the assumption that LLN-ND operation will be done on a secured l2-link. Anyway, I think discussing possible deployment issues and known solutions in the Appendix would be helpful for interoperability and adoption of the specification. Thanks, -Samita > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Erik Nordmark > Sent: Friday, June 11, 2010 5:59 AM > To: Zach Shelby > Cc: [email protected] > Subject: Re: [6lowpan] Multiple 6LBRs > > 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
