Subject: AW: [6lowpan] 6lowpan-nd version 2

From: "Mayer Karl" <[email-masked]>
Date: Tue, 4 Jul 2006 18:05:56 +0200

Hi Samita,
A few comments and questions about your new version.
- page 4, chapter 3 point 2 you state Neighbor Solicitation but it should be a Router Solicitation, right?

- page 6, chapter 4: you state "The IPv6 router which sits in the boundary of the LowPan is a PAN co-ordinator." Since only one PAN co-ordinator is allowed per LowPan this implies that the LowPan is only connected by one IPv6 router to the outside world. I think it is beneficial and applicable to have more than one IPv6 router (gateway) that connects the LowPan to external networks (e.g. for redundancy, loadsharing, reaching differnet offlink networks, etc.). If you agree you could reword the sentence and state: "One of the IPv6 router which sits in the boundary of the LowPan is the PAN co-ordinator." A second gateway (IPv6 router) may overtake the role of the PAN coordinator in case that one is failing (alternate PAN coordinator) or the PAN coordinator may redirect offlink traffic to a second gateway due to being overloaded.

- page 8, section 5.1: For your statement "[TBD: how can it also find out about the other addresses?  Guess based on the advertised prefixes?]" I would recommend that for each address a node configures it sends a Neighbor Solicitation to the PAN coordinator. This way, the PAN coordinator would get a complete L2-L3 association table of on-link nodes. This would also answer your last bullet point in section 9 and removes the need for your section 6.1.

- page 8, section 5.2: I would not introduce an additional signalling protocol, e.g. among coordinators, to enhance RA processing but would keep periodic RAS and go for your option 2 (use L2 unicast to send RAs). The resulting overhead should be acceptable (setting an appropriate interval is a network designer issue). An additional signalling protocol has also an overhead and complexity, and requires additional processing in coordinators, which are likely to be battery powered as well.
Maybe we could think of a signalling protocol between PAN coordinator and alternate PAN coordinators (e.g. IPv6 routers that provide external connectivity) so that an alternate PAN coordinator can quickly establishes itself as PAN coordinator in case the primary one fails.

Best regards,
Karl

>-----Ursprüngliche Nachricht-----
>Von: Samita Chakrabarti [mailto:[email-masked]] 
>Gesendet: Sonntag, 25. Juni 2006 01:30
>An: [email-masked]
>Betreff: [6lowpan] 6lowpan-nd version 2
>
>Erik and I have updated 
>draft-chakrabarti-6lowpan-ipv6-nd-02.txt and submitted for 
>publication. The new update includes a section on generic 
>application of this draft for non-multicast, non-broadcast 
>network. At the last wg meeting, the request was made for such 
>an update  for the Wimax effort on IPv6.
>
>Two questions to the working group and the chairs:
>
>  1) Should this draft( 6lowpan-ipv6-nd) be published as a WG 
>document ?
>  2) Are we OK with publishing the draft as "IPv6 Neighbor 
>Discovery Optimization
>      for IEEE 802.15.4 and other non-multicast networks" so 
>that it contains
>      specifics on 6lowpan and a generic guideline for other 
>relevant networks?
>
>Comments are welcome.
>
>
>- Samita
>
>_______________________________________________
>6lowpan mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/6lowpan
>

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 5 Jul 2006 17:06:52 +0900

Dear Samita

I went over the draft and gladly find many similarities with 'IPv6
over 802.16' work. For example, an Access Router in PAN (PAN
coordinator) has the complete list of all the (link-local) addresses
on the link' and WiMAX AR (ASN GW) is also an omniscient AR. It seems
that we think along the similar line.

Kindly find my in-line comments.

Sec 3.

>   2.  When the host initializes its network it multicasts one or a few
>       Neighbor Solicitation messages to the all-router IPv6 multicast

Typo. sub/ Neighbor/ Router.

Sec 5.1.

>   The lowpan nodes MUST include a Sender Link-layer Address option in
>   the Router Solicitation, since this then allows the router to unicast
>   a Router Advertisement in response.

The above is possible only after DAD is completed, which results in
delay. How about including 'Tentative Option' instead?

>   Since every host sends a RS when it attaches to the PAN and there is
>   a single router for the PAN (the PAN co-ordinator), this router will
>   observe the arrival of all the IPv6 link local addresses

This may not be so. Allow me an example. When a host attaches to a
network, while performing DAD, it may receive an unsolicited
(periodic) RA. Then the host would not send an RS. Also the host may
generate a new (link-local) address while staying at the same link for
the privacy reason. Then it would simply configure a new address
without sending an RS.

How about monitoring the incoming DAD NS to generate the list instead?
That's the approach WiMAX takes right now.

Sec 5.2.

>   Firstly, it might very well be possible to increase the default time
>   significantly as long as the hosts can use some other mechanism to
>   detect when the router (the PAN co-ordinator) disappears.

We also try to increase the maximum of MaxRtrAdvInterval.

Sec 7.

>               Should nodes in LowPan network use duplicate address
>   detection Avoiding duplicate address detection will save broadcast
>   signaling in the PAN-since 802.15.4 does not have multicast
>   capabilities.

I have difficulty understanding the above. Kindly clarify.

Sec 11

>   It is assumed that the node knows the router's IPv6 address on the
>   link.

Usually this is not possible for 802.16/ WiMAX.

>        The node sends a Router Solicitation message directly to the
>   router's link-local address.

In WiMAX, the node sends an RS with all-router multicast destination
address. However, WiMAX specific forwarding mechanism ensures that the
RS is delivered to the AR in unicast.

>                             This RS message MUST carry sender's
>   link-layer address (SLLA) option.

If the RS is sent before completing DAD, it can't carry SLAA. In that
case it may carry Tentative Option.

>                                                               The
>   default periodic interval should be set by the link-layer technology
>   specific requirements.

In WiMAX, it may not be efficient to send RA every 30 mins (current
Max MaxRtrAdvInt) I learned that, in cellular environments, mobile
stations remain idle for the majority of time. (Even it's not
unthinkable to spend more than 90% of time in idling mode
contemplating my own cellular phone usage.) So WiMAX developers are
not happy at the prospect of having to page and awaken 90% of dormant
nodes for every 30 mins.

>                                                This causes the router
>   to both forward the packet to the target and send a Redirect message
>   back to the sender.  The redirect can include the L2 address for the
>   target,

In WiMAX, the router would not send a Redirect message. Usually L2
address is not used for data forwarding inside a link. In WiMAX, an MS
has only an AR, a default router, as its on-link neighbor.

>                                                      The router
>   sends router redirects for the target on-link IP address to the
>   sender node A. The router redirect carries the target link-layer
>   address option.

As I wrote the above, an MS has only its AR as its on-link neighbor in
its Neighbor Cache. So I don't think it's necessary for AR to relay an
address resolution query.

I wish the above helps.

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 7 Jul 2006 15:43:59 -0700

Hi Karl,

Thanks for your input.

My responses are in-line.

> - page 4, chapter 3 point 2 you state Neighbor Solicitation but it should be a Router Solicitation, right?

Yes. Router Solicitation should be more expilicit term.

>
> - page 6, chapter 4: you state "The IPv6 router which sits in the boundary of the LowPan is a PAN co-ordinator." Since only one PAN co-ordinator is allowed per LowPan this implies that the LowPan is only connected by one IPv6 router to the outside world. I think it is beneficial and applicable to have more than one IPv6 router (gateway) that connects the LowPan to external networks (e.g. for redundancy, loadsharing, reaching differnet offlink networks, etc.). If you agree you could reword the sentence and state: "One of the IPv6 router which sits in the boundary of the LowPan is the PAN co-ordinator." A second gateway (IPv6 router) may overtake the role of the PAN coordinator in case that one is failing (alternate PAN coordinator) or the PAN coordinator may redirect offlink traffic to a second >gateway due to being overloaded.

At last IETF, we discussed on the signle point of failure issue of single
 IPv6 router per lowpan.
SInce there is single PAN co-ordinator in a lowpan, we would have to figure out
how it switches the PAN-coordinator functionality  as well. The IPv6
router function
should be a function of PAN-coordinator switch at L2. Once we know about the
PAN-co-ordinator switch and load-balancing we can fix the text or define an
appropriate L3 behavior for that.

>
> - page 8, section 5.1: For your statement "[TBD: how can it also find out about the other addresses?  Guess based on the advertised prefixes?]" I would recommend that for each address a node configures it sends a Neighbor Solicitation to the PAN coordinator. This way, the PAN coordinator would
>get a complete L2-L3 association table of on-link nodes.

Alternately, (if we want to avoid NS messages to the PAN co-ord) the PAN co-
ordinator can automatically associate global IPv6-addresses in the L2-L3 table
based on the prefix advertisement. Usually NS to a router happens to its
link-local address, are you saying each node to send NS to the router's
global IPv6 address?

> This would also answer your last bullet point in section 9 and removes the need for your section 6.1.

6.1 redirect messages for address resolution is useful because it
distributes the
load of future messages to the respective nodes.
 Also, since the router advertises off-link
(L=0) in RA, the node sends data directly to the router; this saves cost of NS.
So, I think 6.1 redirect method might be useful for saving messages.

> - page 8, section 5.2: I would not introduce an additional signalling protocol, e.g. among coordinators, to enhance RA processing but would keep periodic RAS and go for your option 2 (use L2 unicas…

Ok.  I understand that you suggest using L2 unicast to send RA to each node.

> Maybe we could think of a signalling protocol between PAN coordinator and alternate PAN coordinators (e.g. IPv6 routers that provide external connectivity) so that an alternate PAN coordinator can quickly establishes itself as PAN
>coordinator in case the primary one fails.

Do you have any idea to switch PAN co-ordinators at L2 layer? If so, we could
link IPv6-router switch along with that.

Regards,
-Samita

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 7 Jul 2006 16:59:42 -0700

HI JinHyeock,

> that we think along the similar line.

Agree.

> Kindly find my in-line comments.

Thanks for your comments.

> Typo. sub/ Neighbor/ Router.

Ok.

> delay. How about including 'Tentative Option' instead?
Are you talking about Optimized DAD? How much time should we be saving?
Will it be worth the extra code ?
This document is only concerned with the base ND changes.

> the privacy reason. Then it would simply configure a new address

In case of LowPan-ND, we are requiring to send unicast RS to the IPv6-router.
We have not decided whether DAD should be mandatory for these devices or not.
Since this draft assumes each node has EUI-64 addresses, DAD may not be
required in theory. But in practice, it may choose to do DAD through
the Ipv6-router.
However, it will not receive unsolicited RA while waiting on DAD, because in
this ND-extension RA will happen (most likely) through unicast L2 messages.
Since both the DAD and RA will be sent by the same Ipv6 router, I'd assume
they will happen in sequence. But due to radio link issues, we cannot guarantee
that one will reach the destination always in sequence. Perhaps, we
need to re-word the above mentioned text to clarify "observe the
arrival..." part of the sentence.

> That's the approach WiMAX takes right now.

Will discuss that. As mentioned above that DAD may not be mandatory.

> We also try to increase the maximum of MaxRtrAdvInterval.

What was the value?  Which draft is it in?

> I have difficulty understanding the above. Kindly clarify.

Sorry, that sentence is problematic. We are missing a punctuation.

It means that DAD means broadcast in 802.15.4 network and should we
skip DAD for 802.15.4 network?

> Usually this is not possible for 802.16/ WiMAX.

How does it know its router address then? Does it know router's
link-layer address to send DAD?

> RS is delivered to the AR in unicast.

Ok. The above line actually meant the same, but it did not specify the
L3 address
 and the destination IP-address should be
multicast address as specified in IPv6, but the link layer sends it to
the L2-unicast
address. So we are in sync.

> case it may carry Tentative Option.

Can you please point me to the Tentative Option document?

> not happy at the prospect of having to page and awaken 90% of dormant

I think Wimax has some other mechanism for sending 'Fast-RA' during
device attachment time and then it sends RS to followup. So it is
perfectly alright
not to have a periodic RA. In that case RA interval is infinity :-)

> has only an AR, a default router, as its on-link neighbor.

Please see section 10 of this draft for application on other technologies.
RFC2461 actually recommends using off-link RA advertisements for
the non-broadcast/non-multicast networks neighbor soliciation. This is
not new in this draft.

> address resolution query.

So, according to your description,  each MS is off-link to the other.
So any packet has to be forwarded to the AR first. It sounds like
the AR needs to have a different IPv6 link and L2 link (for each MS),
such that an IPv6-link consists of multiple MSes.
So, if AR follows IPv6 neighbor discovery it should advertise RA with L=0
and all data packets are forwarded through it like a star topology in 6lowpan.

Thanks for pointing out the differences in Wimax technology. As I mentioned
before, this draft only provides guidelines for other technolgies so that
mimimal change is required to adopt IPv6 ND on other non-broadcast/multicast
networks.

Regards,
-Samita

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 10 Jul 2006 15:21:35 +0100

Dear Samita

Thanks for your clarification.

> Are you talking about Optimized DAD?

yes.

> How much time should we be saving?

1 sec by default.

> Will it be worth the extra code ?

It depends. :-)

> This document is only concerned with the base ND changes.

I see.

> arrival..." part of the sentence.

ok.

> Will discuss that. As mentioned above that DAD may not be mandatory.

ok.

> skip DAD for 802.15.4 network?

ok.

> Can you please point me to the Tentative Option document?

http://www.ietf.org/internet-drafts/draft-ietf-dna-tentative-00.txt

Take notice that the draft is planned to be merged into a single DNA draft.

> the non-broadcast/non-multicast networks neighbor soliciation. This is

I see.

> and all data packets are forwarded through it like a star topology in 6lowpan.

yes.

> mimimal change is required to adopt IPv6 ND on other non-broadcast/multicast

I see.

Best Regards

JinHyeock

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 10 Jul 2006 15:23:45 +0100

> What was the value?  Which draft is it in?

roughly 6 hours. We try to reflect that in 2461bis.

Best Regards

JinHyeock

---

From: "Mayer Karl" <[email-masked]>
Date: Mon, 10 Jul 2006 16:49:17 +0200

Hi Samita,
Thanks for your quick response. See comments inline...

>> - page 6, chapter 4: you state "The IPv6 router which sits 
>in the boundary of the LowPan is a PAN co-ordinator." Since 
>only one PAN co-ordinator is allowed per LowPan this implies 
>that the LowPan is only connected by one IPv6 router to the 
>outside world. I think it is beneficial and applicable to have 
>more than one IPv6 router (gateway) that connects the LowPan 
>to external networks (e.g. for redundancy, loadsharing, 
>reaching differnet offlink networks, etc.). If you agree you 
>could reword the sentence and state: "One of the IPv6 router 
>which sits in the boundary of the LowPan is the PAN 
>co-ordinator." A second gateway (IPv6 router) may overtake the 
>role of the PAN coordinator in case that one is failing 
>(alternate PAN coordinator) or the PAN coordinator may 
>redirect offlink traffic to a second >gateway due to being overloaded.
>
>SInce there is single PAN co-ordinator in a lowpan, we would 
>have to figure out how it switches the PAN-coordinator 
>functionality  as well. The IPv6 router function should be a 
>function of PAN-coordinator switch at L2. Once we know about 
>the PAN-co-ordinator switch and load-balancing we can fix the 
>text or define an appropriate L3 behavior for that.
>
>>
>> - page 8, section 5.1: For your statement "[TBD: how can it 
>also find 
>>out about the other addresses?  Guess based on the advertised 
>prefixes?]" I would recommend that for each address a node 
>configures it sends a Neighbor Solicitation to the PAN 
>coordinator. This way, the PAN coordinator would get a 
>complete L2-L3 association table of on-link nodes.
>
>Alternately, (if we want to avoid NS messages to the PAN 
>co-ord) the PAN co- ordinator can automatically associate 
>global IPv6-addresses in the L2-L3 table based on the prefix 
>advertisement. Usually NS to a router happens to its 
>link-local address, are you saying each node to send NS to the 
>router's global IPv6 address?

So you would conclude from the EUI-64 identifier of the link-local address (received in the RS) also the non-link-local addresses, right? This is only possible in case *all* IP addresses are constructed by concatenating the respective prefix with the EUI-64 identifier. However, draft-ietf-6lowpan-format-03 leaves flexibility in the constructing of non-link-local IP addresses so I am not sure whether we can rely on this (or at least we have to make this an requirement). 
Therefore my proposal was to send for each configured IPv6 address an NS message to the PAN coordinator with the respective IPv6 address as source address and the Source Link Layer Address option. The destination address could be any of the router's IPv6 addresses, the link-local address as well.

>
>> This would also answer your last bullet point in section 9 
>and removes the need for your section 6.1.
>
>6.1 redirect messages for address resolution is useful because 
>it distributes the load of future messages to the respective nodes.

Now I got your point. 

>>
>> - page 8, section 5.2: I would not introduce an additional 
>signalling protocol, e.g. among coordinators, to enhance RA 
>processing but would keep periodic RAS and go for your option 
>2 (use L2 unicast to send RAs). The resulting overhead should 
>be acceptable (setting an appropriate interval is a network 
>designer issue). An additional signalling protocol has also an 
>overhead and complexity, and requires additional processing in 
>coordinators, which are likely to be battery powered as well.
>
>> Maybe we could think of a signalling protocol between PAN 
>coordinator 
>>and alternate PAN coordinators (e.g. IPv6 routers that 
>provide external connectivity) so that an alternate PAN 
>coordinator can quickly establishes itself as PAN coordinator 
>in case the primary one fails.
>
>Do you have any idea to switch PAN co-ordinators at L2 layer? 
>If so, we could link IPv6-router switch along with that.

Not much about this is written in the IEEE 802.15.4-2003 standard and I have no access to the IEEE 802.15.4b-2003 standard (and I don't think they solve this issue there). I assume 802.15.4 leaves it up to higher layers (e.g. to the 6lowpan layer) to deal with PAN coordinator selection. When sending an Association Request message, a node can signal its wilingness to be an alternate PAN coordinator via a respective flag. Similar to other failover mechanisms, a PAN coordinator receiving such a message with the flag set could subsequently send periodically an alive message just to his alternate PAN coordinators. In case an alternate PAN coordinator does not receive an alive message anymore it could perform an election process among all alternate PAN coordinators and become the PAN coordinator. Clearly, there are open issues and these are just first thoughts.

Best regards,
Karl

>application 
>> >of this draft for non-multicast, non-broadcast network. At the last 
>> >wg meeting, the request was made for such an update  for the Wimax 
>> >effort on IPv6.
>> >
>Discovery 
>> >Optimization
>> >      for IEEE 802.15.4 and other non-multicast networks" 
>so that it 
>> >contains
>> >      specifics on 6lowpan and a generic guideline for 
>other relevant 
>> >networks?
>> >
>> >Comments are welcome.
>> >
>> >
>> >- Samita
>> >

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 10 Jul 2006 16:25:12 -0700

Hi Julien,

Thanks for the pointer. Please see my comments below.

On 6/27/06, Julien Laganier <[email-masked]> wrote:
>> Thus the idea is that 16ng-ND draft can update its text based on
> > the information in the general applicability section of the
> > 6lowpan-ND draft.
>
> Until today I was unaware of existence of Relay-DAD in 6lowpan and
> 16ng (silly me ;-)
>
> As I mentionned already on the 16ng mailing list today:
> <http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20060626/000165.html>
>
> In a draft I co-author (available there until it shows up in ID rep:
> (<http://julien.laganier.free.fr/draft-ietf-netlmm-mn-ar-if-01.txt)
> we also define Relay-DAD to support SEND (otherwise we could just have
> proxied ND.)
>
> Hence, I thought I should also ask to this mailing list opinions on
> usefulness of a standalone document defining Relay-DAD?

I don't know how much security work will be part of 6lowpan charter.
This draft may be more applicable for the 16ng architecture at this point.
Don't know whether 6lowpan will adopt a very simple security scheme
( i,e shared group key) and perform all operation on it or add more
complicated scheme, due to its limitation on power and low processing
capability. draft-daniel-6lowpan-security-analysis-01.txt is starting to
define the 6lowpan threat model.

Thanks,
-Samita

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 10 Jul 2006 17:01:20 -0700

Hello Karl,

On 7/10/06, Mayer Karl <[email-masked]> wrote:
>
> So you would conclude from the EUI-64 identifier of the link-local address (received in the RS) also the non-link-local addresses, right?

Yes.

> This is only possible in case *all* IP addresses are constructed by concatenating the respective prefix with the EUI-64 identifier. However, draft-ietf-6lowpan-format-03 leaves flexibility in the constructing of non-link-local IP addresses so I am not sure whether we can rely on this (or at least we have to make this an requirement).

I see your point.

> Therefore my proposal was to send for each configured IPv6 address an NS message to the PAN coordinator with the respective IPv6 address as source address and the Source Link Layer Address option.…

I got the idea. Will discuss with you further, before next revision of
the draft.

> Not much about this is written in the IEEE 802.15.4-2003 standard and I have no access to the IEEE 802.15.4b-2003 standard (and I don't think they solve this issue there). I assume 802.15.4 leaves…

OK.  Thanks for explaining.

Regards,
-Samita