Samita,
An appendix describing typical use cases for the ABRO and context /
prefix distribution is a very good idea.
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. "
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
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
