Hi, On Jun 14, 2010, at 11:29 AM, Daniel Gavelle wrote:
> Samita, > > An appendix describing typical use cases for the ABRO and context / prefix > distribution is a very good idea. Yep, I will make a ticket on that. nd-10 is just about ready, so we probably won't get it in this version though. > > I also think the text around section 8.1.3 and 8.1.4 could be clarified. The > lines below imply that if two 6LBRs are sending different context information > then the 6LR needs to store and forward both sets of contexts. > > > "The router keeps state for each 6LBR that it sees with an ABRO. This > includes the version number, and the complete set of Prefix > Information options and 6LoWPAN Context options. " Yes, this is a problem we have identified. Currently we are looking at adding a couple assumptions that make it clear that context must be kept consistent throughout a LoWPAN, etc. We also need to fix the draft in a few places that might break that (like the text above). Cheers, Zach > > > From the discussions we have had, there should only ever be one set of > contexts in a correctly configured network and the 6LR only needs to store > (and forward) one set of context information. > > Daniel. > > > Samita Chakrabarti wrote: >> 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 > > -- > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK > Comp Reg No: 3191371 Registered In England > http://www.jennic.com > __________________________________________________ -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
