Subject: [6lowpan] Comments on 6lowpan-ND draft

From: "Reddy, Joseph" <[email-masked]>
Date: Tue, 8 Jun 2010 00:12:57 -0500

Some more miscellaneous comments/questions on the ND draft ( I originally sent this email over the weekend but it bounced )

1.  If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a router solicitation from a host?  Should it send multiple router advertisement messages in response ?

2. If a context with valid lifetime = 0 is received from another 6LR or 6LBR, does a 6LR have to delete the context only after completing the dissemination of the context? How long should this time be ( considering that sleeping devices can sleep for very long times.. ). In general updating of context information seems unreliable in presence of sleeping nodes

3. If a host completes DaD on a global address where the IID is derived from its link layer address, can it safely assume that a link local address derived from the same IID is also unique ? That is, can it automatically configure a LL address based on that IID without going through the registration process again for that address ?

4. Add a new failure status code for the NA ( "neighbor cache at capacity" ). This will be used if the 6LR has a full neighbor table and cannot allow another host to register through it. The host can then attempt registration through another 6LR

-Regards, Joseph

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Jun 2010 01:21:57 -0700

On 06/ 7/10 10:12 PM, Reddy, Joseph wrote:
>
>
> Some more miscellaneous comments/questions on the ND draft ( I
> originally sent this email over the weekend but it bounced )
>
> 1.  If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a
> router solicitation from a host?  Should it send multiple router
> advertisement messages in response ?

Since we allow 6LRs to send RS messages as part of prefix and context 
dissemination, a 6LR can't tell whether the RS was from a host or a 
router. Hence, if RA is used for prefix and context dissemination, then 
there would be one RA for each ABRO. If RA is not used for prefix and 
context dissemination from the 6LBRs to the 6LRs, then AFAIK there 
wouldn't be any ABRO options hence everything could put in one RA.

That is what the first paragraph in section 6.3 tries to say. 
Suggestions on how to make this more clear?

> 2. If a context with valid lifetime = 0 is received from another 6LR
> or 6LBR, does a 6LR have to delete the context only after completing
> the dissemination of the context? How long should this time be (
> considering that sleeping devices can sleep for very long times.. ).
> In general updating of context information seems unreliable in
> presence of sleeping nodes

The 'C' bit is used to robustly be able to remove the context; it needs 
to be advertised with C=0 to make all nodes stop using it for 
compression. Section 7.2 specifies this and has a min time of 60 
seconds. That is too short to handle hosts that might sleep for an 
abitrarily long time. To handle that it would make more sense to rely on 
not having the "expiration time" move backwards.
For instance, if a context was advertised at time T0 with valid lifetime 
V0, at time T1 with valid lifetime V1, etc, then the latest expiration 
time any node could have is the max(Ti+Vi). Hence even if hosts can 
sleep for an unbounded time the context would expire no later than that 
time. This can be used to robustly remove contexts.

>
> 3. If a host completes DaD on a global address where the IID is
> derived from its link layer address, can it safely assume that a link
> local address derived from the same IID is also unique ? That is, can
> it automatically configure a LL address based on that IID without
> going through the registration process again for that address ?

The answer is completely different if "link layer address" is EUI-64 or 
a short address.

For an EUI-64 we do not do any DAD; we merely do registrations.
If applications (running on the neighboring 6LR) might use the host's 
link-local address, then the host should register that address with the 
6LRs so that the routers have the IPv6->link-layer address mapping in 
their Neighbor Cache. But I don't know a case when application usage of 
link-locals make any sense since those addresses will be useless should 
the topology change.

For IPv6 addresses based on short addresses (or anything but EUI-64) we 
need to do DAD across a scope that is consistent with the address scope. 
Thus for the global address it is across the 6lowpan, and for the 
link-local it is just with the neighboring 6LRs. (I guess the draft 
should make it clear that a 6LR doesn't send a ARO towards the 6LBRs for 
a link-local address.)

The fact that the interface ID is the same doesn't help since we want to 
be consistent with the IPv6 standards. (IPv6 originally did duplicate 
IID detection which was later clarified to be duplicate address detection.)

> 4. Add a new failure status code for the NA ( "neighbor cache at
> capacity" ). This will be used if the 6LR has a full neighbor table
> and cannot allow another host to register through it. The host can
> then attempt registration through another 6LR

OK
Presumably if there is no other reachable 6LR the host should also 
continue to keep poking that 6LR, and/or multicast RS messages to try to 
find an available 6LR that has capacity. I wonder if we should recommend 
some retransmission behaviors for those cases.

    Erik

---

From: Daniel Gavelle <[email-masked]>
Date: Tue, 08 Jun 2010 11:21:59 +0100

I think there are two separate cases where more than one 6LBR may be 
visible on a 15.4 PAN.  Other MACs may reach point (2) sooner if they 
don't have the concept of a PAN ID.

(1) 6LBRs are acting together to provide redundancy.  Their context and 
prefix information is synchronised by an "out of scope method".  In this 
case, wouldn't it be better if all the 6LBRs all advertise using the 
same identifier (i.e. the current 6LBR Address identifies the network 
rather than an individual 6LBR).

(2) Two networks that were intended to be kept separate but use the same 
PAN and channel have grown out and come into range of each other.  In 
this case, the 6LR and hosts of one network are not interested in the 
context and prefix information from the other network.  Using the 
context / prefix from the other network would only result in confusion.

I think both cases would be better covered by the 6LR selecting a 6LBR 
(or set of redundant 6LBRs) and only forwarding the ABRO messages from 
the network that it is participating in.

I agree that we need an error code for when the 6LR has reached capacity 
and rules for retry.  I think the host should send multicast RS rather 
than poking that particular 6LR as another router may come into range 
before the one that is full drops a child.

Do we also need a separate code for when the DAD table on the 6LBR 
becomes full?

Daniel.

Erik Nordmark wrote:
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> 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
__________________________________________________

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Jun 2010 06:45:12 -0700

> rather than an individual 6LBR).

As long as they also synchronize the sequence numbers used in the ABRO 
they can do that. In essence this might look like one master 6BLR which 
owns the sequence number space, and the others are slaves that have 
their configuration kept in synch with the master.

> context and prefix information from the other network. Using the context
> / prefix from the other network would only result in confusion.

"confusion" is a fairly mild statement, since the compression contexts 
would now be different hence packets that are compressed would not 
decompress correctly.

> the network that it is participating in.

Not only would the 6LRs need to be configured with the ABRO to accept, 
but all the hosts would need the same configuration.

Using ABRO for this really sounds like solving the problem at the wrong 
level. Wouldn't there be potential security issues since a router in one 
lowpan could fake an ABRO pretending to be part of the other lowpan?
Wouldn't one want to use some L2 security mechanisms to keep the two 
networks apart?

> Do we also need a separate code for when the DAD table on the 6LBR

What would a 6LR do to recover from such an error? The assumption is 
there there is some external out-of-scope mechanism to keep the DAD 
tables on multiple 6LBRs in synch, thus doing multihop DAD against 
another 6LBR would still get back to the overloaded 6LBR.

    Erik

>> router. Hence, if RA is used for prefix and context dissemination,
>> then there would be one RA for each ABRO. If RA is not used for prefix
>> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there
>> The 'C' bit is used to robustly be able to remove the context; it
>> needs to be advertised with C=0 to make all nodes stop using it for
>> abitrarily long time. To handle that it would make more sense to rely
>> on not having the "expiration time" move backwards.
>> For instance, if a context was advertised at time T0 with valid
>> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest
>> expiration time any node could have is the max(Ti+Vi). Hence even if
>> hosts can sleep for an unbounded time the context would expire no
>> later than that time. This can be used to robustly remove contexts.
>>
>>>
>> The answer is completely different if "link layer address" is EUI-64
>> or a short address.
>>
>> link-local address, then the host should register that address with
>> the 6LRs so that the routers have the IPv6->link-layer address mapping
>> in their Neighbor Cache. But I don't know a case when application
>> usage of link-locals make any sense since those addresses will be
>> useless should the topology change.
>>
>> For IPv6 addresses based on short addresses (or anything but EUI-64)
>> we need to do DAD across a scope that is consistent with the address
>> scope. Thus for the global address it is across the 6lowpan, and for
>> the link-local it is just with the neighboring 6LRs. (I guess the
>> draft should make it clear that a 6LR doesn't send a ARO towards the
>> 6LBRs for a link-local address.)
>>
>> The fact that the interface ID is the same doesn't help since we want
>> to be consistent with the IPv6 standards. (IPv6 originally did
>> duplicate IID detection which was later clarified to be duplicate
>> address detection.)
>>
>> continue to keep poking that 6LR, and/or multicast RS messages to try
>> to find an available 6LR that has capacity. I wonder if we should
>> recommend some retransmission behaviors for those cases.
>>
>> Erik

---

From: Daniel Gavelle <[email-masked]>
Date: Wed, 09 Jun 2010 09:28:05 +0100

Eric,

If the L2 takes care of multiple overlapping networks, I think the 
protocol could be simplified and context distribution made safer by 
removing the 6LBR address field from the ABRO and requiring all 6LBRS to 
use the same version number.

For example:-
6LBR1 has address aaaa.  It has been running for a while and is on 
version 10.
6LBR2 is brought on line with address bbbb.  It is loaded with the same 
context information as aaaa and is on version 1.

The administrator decides to update the contexts.  6LBR2 receives the 
update OK but 6LBR1 doesn't.  I'll call the old contexts ctx1 and the 
new contexts ctx2 although in reality there will be no way of telling 
from the contexts themselves which is the newer set.

A 6BR sees two messages: aaaa v2 with ctx 2 and bbbb v10 with ctx1.  In 
the existing spec, it must store both (aaaa v2 ctx2) and (bbbb v10 
ctx1).  This takes up more memory and means the 6LR can't just use its 
own context tables for storing context information as more than one set 
must be stored.

When a host sends 6BR an RS, 6BR must generate two separate RAs: (aaaa 
v2 ctx2) and (bbbb ctx1 v10).

Both the 6LR and the host need to decide which context to use based only 
on the above information.  If they pick differently, their contexts 
won't be in sync and they won't be able to communicate.

If the address were removed and the requirement was made to update the 
version number at the same time as the contexts, aaaa would send (v11 
ctx2) and bbbb would send (v10 ctx1).  The 6LR would only need to store 
a single version number and could read out the context information from 
its tables when responding to an RS.  It would respond to an RS with a 
single RA with the most up to date context info.

Daniel.

---

From: Daniel Gavelle <[email-masked]>
Date: Wed, 09 Jun 2010 09:33:55 +0100

Erik,

I agree that a host that gets a DAD full error won't be able to retry 
another 6LBR.  Administrative action is required on the 6LBR to solve 
this problem.

However, a DAD table full error code is still useful in communicating 
the error to the human who needs to take action.  If the host has a GUI 
(or LED that can flash a fault code), it would be better for it to 
indicate a "DAD table full" error than a "failure to register address". 
  Even without such help from the host, an installer working on a large 
commissioned network with a packet sniffer would be able to home in on 
the problem more quickly with the additional error code.

Daniel.

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 09 Jun 2010 12:17:28 -0600

Daniel,
  I'm not sure that we need a new error code for DAD table full.  If the
DAD table is full on the 6LBR it should deal with that problem - it
could flash some error code or send some message.

	geoff

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 9 Jun 2010 14:28:17 -0700

Hi Daniel,

> (2) Two networks that were intended to be kept separate but use the same
PAN
> and channel have grown out and come into range of each other.  In this
case,
> the 6LR and hosts of one network are not interested in the context and
> prefix information from the other network.  Using the context / prefix
from
> the other network would only result in confusion.
> 

[SC>] This case seems to be out of scope of LLN-ND spec [ LLN-ND seems to be
a better acronym of ND-09]. As Erik mentioned before, hopefully there will
be PAN-level security which will prevent such misconfiguration from
happening.

Thanks,
-Samita

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Jun 2010 10:51:04 -0700

On 06/ 9/10 01:28 AM, Daniel Gavelle wrote:

> update OK but 6LBR1 doesn't. I'll call the old contexts ctx1 and the new
> contexts ctx2 although in reality there will be no way of telling from
> the contexts themselves which is the newer set.
>
> on the above information. If they pick differently, their contexts won't
> be in sync and they won't be able to communicate.

I think the network is more broken that that, because presumably 6LBR1 
will use the contexts it advertised and 6LBR2 the ones it advertised. 
Thus even if we could get the 6LRs and hosts to agree on one set of 
context information (e.g., ctx2), the packets being routed out via 6LBR2 
would not decompress correctly; ditto for packets arriving in via 6LBR2.

However, the gradual introduction and change of contexts specified in 
nd-09 means that as long as the new context are propagated to 6LBR2 and 
distributed with its ABRO before the C bit is changed, there will be no 
incorrect decompressions.
Thus the out-of-scope mechanism which keeps 6LBR1 and 6LBR2 in synch 
with respect to the contexts need to be able to update both of them 
before the next update (which might change the C bit) or otherwise the 
network will fall apart.

> ctx2) and bbbb would send (v10 ctx1). The 6LR would only need to store a
> single version number and could read out the context information from

But the packets being forwarded via LBR2 would still use the old 
compression context, hence would be turned into garbage.

Thus while I can see that using a single logical 6LBR (that feeds via 
multiple actual 6LBRs) reduces the memory requirements, and might be a 
good deployment practice, it doesn't remove the need for all the 6LBRs 
to be updated with the compression contexts.

    Erik

>> they can do that. In essence this might look like one master 6BLR
>> which owns the sequence number space, and the others are slaves that
>> have their configuration kept in synch with the master.
>>
>> Using ABRO for this really sounds like solving the problem at the
>> wrong level. Wouldn't there be potential security issues since a
>> router in one lowpan could fake an ABRO pretending to be part of the
>> other lowpan?

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Jun 2010 11:00:55 -0700

> the problem more quickly with the additional error code.

OK, as long as the blinking in morse code of the LED is well-understood ;-)

Seriously, I don't see a problem adding such an error code. We just need 
to make sure we describe that, unlike the error from the 6LR, there 
isn't a useful fallback.

    Erik

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 10 Jun 2010 12:09:43 -0600

I still do not agree that we need this error code in ND.  It is an error
on the 6LBR and the 6LBR should communicate the error to the operator
and since it is "well connected" it has a much better chance to getting
the message to someone that can do something.

Lets not add complexity to this draft.

	geoff

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Jun 2010 11:28:11 -0700

> the message to someone that can do something.

I agree it would be much easier for the operator to get the error out of 
a log or SNMP trap from the 6LBR, then it would be to get the error from 
the hosts.

> Lets not add complexity to this draft.

Works for me.

    Erik

---

From: Zach Shelby <[email-masked]>
Date: Thu, 10 Jun 2010 22:45:08 +0300

On Jun 10, 2010, at 9:28 PM, Erik Nordmark wrote:

> I agree it would be much easier for the operator to get the error out of a log or SNMP trap from the 6LBR, then it would be to get the error from the hosts.
> 

+1

-- 
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

---

From: Daniel Gavelle <[email-masked]>
Date: Fri, 11 Jun 2010 09:18:11 +0100

Erik,

I agree that it is very important to keep the contexts in sync within a 
network.  I can also see that the L2 security can be used to separate 
networks.  Given these two conditions, when would there be a need for 
two 6LBRS in a network to have different addresses / version number spaces?

Daniel.

Erik Nordmark wrote:
>>>> context

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Jun 2010 02:25:43 -0700

On 06/11/10 01:18 AM, Daniel Gavelle wrote:
> networks. Given these two conditions, when would there be a need for two
> 6LBRS in a network to have different addresses / version number spaces?

There is a difference between how I would build a product today using 
the specification, and what we should support in the specification.

In a product, especially one that uses compression contexts, it makes 
sense having the ABRO originate from a logical management entity to 
ensure that all the 6LBRs send out the same information. But that 
belongs in the vendor's product spec.

But for general applicability to route-over networks I think allowing 
the 6LBRs to be autonomous is the right thing to do in the protocol 
specification.

Thus the protocol specification isn't the same as the product specification.

    Erik

---

From: Zach Shelby <[email-masked]>
Date: Fri, 11 Jun 2010 12:48:24 +0300

On Jun 11, 2010, at 12:25 PM, Erik Nordmark wrote:

> There is a difference between how I would build a product today using the specification, and what we should support in the specification.
> 
> In a product, especially one that uses compression contexts, it makes sense having the ABRO originate from a logical management entity to ensure that all the 6LBRs send out the same information. But that belongs in the vendor's product spec.
> 
> But for general applicability to route-over networks I think allowing the 6LBRs to be autonomous is the right thing to do in the protocol specification.
> 

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. 

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:

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). 

Zach

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Jun 2010 12:13:53 +0200

Hi Zach:

> 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).

Inside a given instance, RPL has made that exact same decision. A router
can
only attach to one DODAGID. Nodes get the configuration from that
router,
that is authoritative for the prefixes and everything else the routers
need to
operate RPL.
 
OTOH, RPL also demands that a node can attach to multiple parents, 
that is an absolute MUST for us. RPL ensures that the parents all report
to a same root. 

Cheers,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Zach Shelby
> Sent: Friday, June 11, 2010 11:48 AM
> To: Erik Nordmark
> Cc: [email-masked]
> Subject: Re: [6lowpan] Multiple 6LBRs
> 
> >> I agree that it is very important to keep the contexts in sync
within
> >> a network. I can also see that the L2 security can be used to
> >> separate networks. Given these two conditions, when would there be
a
> >> need for two 6LBRS in a network to have different addresses /
version
> number spaces?
> >
> > There is a difference between how I would build a product today
using the
> specification, and what we should support in the specification.
> >
> > In a product, especially one that uses compression contexts, it
makes sense
> having the ABRO originate from a logical management entity to ensure
that
> all the 6LBRs send out the same information. But that belongs in the
vendor's
> product spec.
> >
> > But for general applicability to route-over networks I think
allowing the
> 6LBRs to be autonomous is the right thing to do in the protocol
specification.
> 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.
> 
> 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:
> 
> 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).
> 
> Zach
> 
> >
> >   Erik
> >

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Jun 2010 05:58:53 -0700

On 06/11/10 02:48 AM, Zach Shelby wrote:

> 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?

> 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.
>
> 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

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

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 11 Jun 2010 14:16:26 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Erik Nordmark
> Sent: Friday, June 11, 2010 5:59 AM
> To: Zach Shelby
> Cc: [email-masked]
> > able to manage the whole 6LBR infrastructure (and the contexts), so we
> > are OK there. In home environments you will probably keep LoWPANs
here
> without understanding something about the envisioned usage and associated
> business model.
> 
and
> just try to use it isn't something that we've seen anywhere else.
> 
> 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.
> 
> 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?
> 
> > 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).
> 
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.)
> 
level
> needs to provide sufficient isolation with respect to routing.

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 14 Jun 2010 09:29:06 +0100

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.

---

From: Zach Shelby <[email-masked]>
Date: Mon, 14 Jun 2010 11:35:46 +0300

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.
> 
> 

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.
> 
> 
>> 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
>> from different 6LBRs. I have heard some discussions in a deployment where they might want to do
>> on a secured l2-link. Anyway, I think discussing possible deployment issues and known solutions in

---

From: Zach Shelby <[email-masked]>
Date: Mon, 14 Jun 2010 12:24:33 +0300

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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jun 2010 02:34:01 -0700

> store (and forward) one set of context information.

When multihop prefix and context distribution is used, then
each 6LR needs to be able to forward all the information it receives 
from other routers. Otherwise the multihop distribution mechanism 
doesn't work.
That means tracking prefix and context information per ABRO. Thus the 
quoted text above is required. Anything else would require either 
tossing out the multihop distribution from the spec, or having the 
protocol only be capable to support a single 6LBR (which means that 
routing would have a single point of failure.)

For compression to work the compression context information must be in 
synch (to the degree required by section 7.2 - it takes a while for 
changes to propagate through the network), hence the management of the 
context information that is being distributed needs care. But this is an 
external management problem and not a protocol problem. Of course, out 
of scope, there could be a management protocol to keep the 6LBRs in synch.

We're trying to make this more clear with this text:
8.1.  Multihop Prefix and Context Distribution

    The multihop distribution relies on Router Solicitation messages and
    Router Advertisement (RA) messages sent between routers, and using
    the ABRO version number to control the propagation of the information
    (prefixes and context information) that is being sent in the RAs.

    This multihop distribution mechanism can handle arbitrary information
    from an arbitrary number of 6LBRs.  However, the semantics of the
    context information requires that all the 6LNs use the same
    information, whether they send, forward, or receive compressed
    packets.  Thus the manager of the 6LBRs need to somehow ensure that
    the context information is in synchrony across the 6LBRs.  One way to
    do that is to treat the context and prefix information as originating
    from some logical and virtual source, which in essence means that it
    looks like the information is distributed from a single source.

    If a set of 6LBRs behave as a single one (using mechanisms out of
    scope of this document) so that the prefixes and contexts and ABRO
    version number will be the same from all the 6LBRs, then those 6LBRs
    can pick a single IP address to use in the ABRO option.

Does that make sense?
Should we specify other examples than this "one way"?

   Erik

>>> Behalf
>>> ensure
>>> select