Daniel, Just to clarify on what I said below. We haven't decided on the exact text to clarify that yet, but we will definitely clarify it in the nd-10 release. Let's come back to this after the release and check that it is OK.
Zach On Jun 14, 2010, at 11:35 AM, Zach Shelby wrote: > 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 -- 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
