Subject: [6lowpan] Fundamental concerns about 6lowpan ND

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 12 Oct 2009 14:47:15 +0200

Dear WG,
 
I have serious concerns about the 6lowpan ND draft and would like to
have the WG opinion on this. I agree that a few issues arise in lowpan
environments, which are mostly linked to the non transitivity of some
link layers used in lowpans. However, my two major points of concern
are:
- RFC4861 and RFC4862, which are core to IPv6, are being very heavily
redesigned. I believe that the proposal if it is done in 6lowpan MUST be
designed as an optional extension to ND, not a redesign. The charter
states that the draft should propose "optimizations" and "limited
extensions" to ND. It is not the case at the moment. The proxy ND
proposal, the mandatory addressing model proposed, also goes beyond the
scope of the document as spelled out in the charter.
- non transitivity is not a lowpan only issue, hence if adaptations to
ND must be done, it should be in another WG, probably 6man
 
If these two points are not respected, 
- it questions the applicability of IPv6 in smart object networks: the
draft is redesigning roughly 80% of RFC4861 and RFC4862, which are core
to IPv6
- existing IPv6 implementations will be strongly impacted, as a number
of major components will have to become layer 2 dependant:
-- address resolution will have to be disabled
-- DAD will have to be modified
-- NUD will have to be modified
-- prefix discovery will have to be modified
-- autoconf will have to be modified
-- IPv6 addresses will not be configurable if their IID is not based on
the MAC address
-- ... all these changes are 6lowpan dependant, as they do not impact
traditional links. This will raise important interoperability issues.
- new layer 3 protocol designs will become layer 2 dependant. This is
what is currently happenning in the ROLL WG by proposing to use a
different message to transport routing information, depending on the
medium.
 
Moreover, a number of existing deployments show that the issues arised
on lowpan networks as far as ND is concerned are not huge: the
deployments work, and ND as it is has proven to be power consumption
friendly. DAD is the most problematic procedure, that requires work, as
two hop neighbors do not see NS sent for DAD (see at the bottom)
 
In conclusion, I believe the advantages of rebuilding neighbor discovery
for lowpans are by far inferior to those of keeping using the "same IP"
on all medium. If some redesign has to be done, it MUST be done in a
more general fashion, probably in 6man, and in a much lighter way.
 
Best,
Julien
 
DAD issue description:
node A and node C see node B, but not each other. nodes A and B boot,
configure a link local address, perfom traditional DAD. It works. Node C
boots with the same MAC address than A, configures the same IP address,
sends a NS to perform traditional DAD. A does not see the NS hence C
address configuration works. A and C have the same address. B will not
differentiate A and

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Oct 2009 15:01:10 +0200

On Oct 12, 2009, at 14:47, Julien Abeille (jabeille) wrote:

> the issues arised on lowpan networks as far as ND is concerned are  
> not huge

[WG member hat]

Julien,

I'd like to know more about that.

As far as I can see, certain parts of 4861-ND just DO NOT WORK on non- 
transitive networks.
It's really as simple as that.

So you either make 6LoWPANs transitive at huge cost, or you need  
something like 6LoWPAN-ND for those parts.
(Or, you simply ignore that they don't work, which you mostly can for  
DAD; we didn't want to do that.)

Please reread section 1, paragraph 2 of 4861 for its area of  
applicability.

Gruesse, Carsten

PS.: re the charter:
Getting rid of 4861's address resolution by multicast is indeed just  
an optimization.
I happen to believe it is a good one.  We can (and should!) debate that.
I would have argued to simply get rid of DAD as well, but there is the  
issue of counterfeiting.
So we made a limited extension to make DAD work, which it doesn't for  
4861-ND on non-transitive.
etc.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 12 Oct 2009 15:20:44 +0200

Hi Julien, All,
 
I fully agree with you! We definitely do not want different flavor of
IPv6 depending on the underlying medium. 
Ideally I would like to be able to use the IPv6 stack of my PC / router
to talk directly to my 802.15.4 smart-objects...
Anything that breaks this concept is in my opinion not an 'optimization'
or an 'extension'.
 
Best,
Mathilde

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Abeille (jabeille)
Sent: lundi, 12. octobre 2009 14:47
To: 6lowpan
Subject: [6lowpan] Fundamental concerns about 6lowpan ND

Dear WG,

 

Best,
Julien
 
DAD issue description:

---

From: Adam Dunkels <[email-masked]>
Date: Mon, 12 Oct 2009 16:40:51 +0200

Hi Carsten,

these sounds like some serious architectural concerns with IPv6. Should 
these really be dealt with by an adaptation layer that defines how to 
transport IPv6 packets over a particular link layer? I am not too 
accustomed to IETF practices, but isn't there a wg specifically for the 
purpose of forwarding the IPv6 architecture (6man) where issues like 
these should be raised?

Also, one specific question: how would an IPv6 host deal with an 
802.15.4 network interface if the IPv6 adaptation layer would require 
changes to the core of the IPv6 stack to function properly?

Thanks,

/adam

Carsten Bormann wrote:
>> the issues arised on lowpan networks as far as ND is concerned are not 
>> huge
> 
> 
> [WG member hat]
> 
> Julien,
> 
> As far as I can see, certain parts of 4861-ND just DO NOT WORK on 
> non-transitive networks.
> Please reread section 1, paragraph 2 of 4861 for its area of applicability.
> 
> Gruesse, Carsten
> 
> PS.: re the charter:
> Getting rid of 4861's address resolution by multicast is indeed just an 
> optimization.
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
> 

-- 
Adam Dunkels <[email-masked]>, +46707731614
http://twitter.com/adunk | http://www.sics.se/~adam/

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Oct 2009 17:20:29 +0200

I have absolutely no idea why people think 4861-ND is an immutable  
core part of IPv6.

Let me cite from the horse's mouth (RFC 4861, section 1):

    Unless specified otherwise (in a document that covers operating IP
    over a particular link type) this document applies to all link  
types.
    However, because ND uses link-layer multicast for some of its
    services, it is possible that on some link types (e.g., Non- 
Broadcast
    Multi-Access (NBMA) links), alternative protocols or mechanisms to
    implement those services will be specified (in the appropriate
    document covering the operation of IP over a particular link type).

We are doing exactly what 4861 provides for.

Now, if people didn't plan for this in their IPv6 implementations and  
have hardwired 4861, all hope is not lost.
It just means that the "802.15.4 driver" has to do a somewhat special  
form of what could be called "header compression" for those NS/NA  
packets (and certain options in the RAs).
Maybe someone should write up the state machine for that; it's not too  
complicated.

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 12 Oct 2009 17:46:11 +0100

Hello,

I understand the problems with 'redesigning' a core IPv6 protocol. 

However I'm curious about existing implementations that use full IPv6 ND, do
you have details?

I see the 6LoWPAN ND as a 'necessary evil', however I would love to be
proven wrong! 

Regards,

   -Colin

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Julien Abeille (jabeille)
Sent: October 12, 2009 1:47 PM
To: 6lowpan
Subject: [6lowpan] Fundamental concerns about 6lowpan ND

Dear WG,

I have serious concerns about the 6lowpan ND draft and would like to have
the WG opinion on this. I agree that a few issues arise in lowpan
environments, which are mostly linked to the non transitivity of some link
layers used in lowpans. However, my two major points of concern are:

- RFC4861 and RFC4862, which are core to IPv6, are being very heavily
redesigned. I believe that the proposal if it is done in 6lowpan MUST be
designed as an optional extension to ND, not a redesign. The charter states
that the draft should propose "optimizations" and "limited extensions" to
ND. It is not the case at the moment. The proxy ND proposal, the mandatory
addressing model proposed, also goes beyond the scope of the document as
spelled out in the charter.

- non transitivity is not a lowpan only issue, hence if adaptations to ND
must be done, it should be in another WG, probably 6man

- it questions the applicability of IPv6 in smart object networks: the draft
is redesigning roughly 80% of RFC4861 and RFC4862, which are core to IPv6

- existing IPv6 implementations will be strongly impacted, as a number of
major components will have to become layer 2 dependant:

-- IPv6 addresses will not be configurable if their IID is not based on the
MAC address

- new layer 3 protocol designs will become layer 2 dependant. This is what
is currently happenning in the ROLL WG by proposing to use a different
message to transport routing information, depending on the medium.

Moreover, a number of existing deployments show that the issues arised on
lowpan networks as far as ND is concerned are not huge: the deployments
work, and ND as it is has proven to be power consumption friendly. DAD is
the most problematic procedure, that requires work, as two hop neighbors do
not see NS sent for DAD (see at the bottom)

In conclusion, I believe the advantages of rebuilding neighbor discovery for
lowpans are by far inferior to those of keeping using the "same IP" on all
medium. If some redesign has to be done, it MUST be done in a more general
fashion, probably in 6man, and in a much lighter way.

Best,

Julien

DAD issue description:

node A and node C see node B, but not each other. nodes A and B boot,
configure a link local address, perfom traditional DAD. It works. Node C
boots with the same MAC address than A, configures the same IP address,
sends a NS to perform traditional DAD. A does not see the NS hence C address
configuration works. A and C have the same address. B will not differentiate
A and

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 12 Oct 2009 17:50:42 +0100

Hello Adam,

> changes to the core of the IPv6 stack to function properly?

Having a router in between seems sensible to me. You can get uIPv6 somewhere
small, so I don't see having a simple router as a big problem...

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Dunkels
Sent: October 12, 2009 3:41 PM
To: Carsten Bormann
Cc: 6lowpan
Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND

Hi Carsten,

Thanks,

/adam

---

From: Adam Dunkels <[email-masked]>
Date: Mon, 12 Oct 2009 19:02:44 +0200

Hi Colin,

> small, so I don't see having a simple router as a big problem...

It isn't so much about the size or complexity of the software, but of 
the architectural implications. Having an additional IP stack between 
the IP stack and the link layer seems fundamentally backwards.

/adam

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Oct 2009 19:20:38 +0200

Hi Adam

ND operation is a link operation and what it does varies across link
types. Simple as that.

That's hardly surprising. 

- RFC4861 is a form of reactive protocol that is optimized for a certain
environment, namely many nodes, each one being able to see another one
on a link, and a multicast capability. With a different constraint like
few nodes and stricter forwarding/routing plane separation you might
have ended up with a proactive protocol.

- For ND, there are small variations (like omitting address resolution
on certain P2P links) to larger ones (like inverse ND for FR/ATM).
You'll note that RFC 3122 addresses a problem that is closer to 6LoWPAN
because Frame Relay is non transitive. But we could hardly afford MARS
and the multicast infra that goes with it.

- Routing protocols are the same. They are optimized for certain
assumptions. But whereas ND operates on a link with link level
assumptions, routing protocols are optimized for network level
operations, and depending on what you are doing at the  network level at
which you are operating, you have to select OSPF or RIP or OLSR or even
BGP.

Ipv6 is not broken. It is adaptable and extensible. Routing Protocols
and ARP in IPv4 have similar causes and effects, though ND in its
variations is incredibly richer than ARP.

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Dunkels
>Sent: lundi 12 octobre 2009 16:41
>To: Carsten Bormann
>Cc: 6lowpan
not
applicability.
>> Getting rid of 4861's address resolution by multicast is indeed just
an

---

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Oct 2009 21:01:37 +0200

> small, so I don't see having a simple router as a big problem...

I do not think that the issue is the code size itself but a change in  
the architecture, thus
the reasonable question on whether we could find a simpler approach  
compatible with
4861 to handle the case of non transitive links that preserves the  
architecture.

> Behalf

---

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Oct 2009 21:02:40 +0200

All valid concerns and questions.

Copying Bob and Brian to get their input there.

Thanks.

JP.

On Oct 12, 2009, at 2:47 PM, Julien Abeille (jabeille) wrote:

> have the WG opinion on this. I agree that a few issues arise in  
> lowpan environments, which are mostly linked to the non transitivity  
> of some link layers used in lowpans. However, my two major points of  
> concern are:
> - RFC4861 and RFC4862, which are core to IPv6, are being very  
> heavily redesigned. I believe that the proposal if it is done in  
> 6lowpan MUST be designed as an optional extension to ND, not a  
> redesign. The charter states that the draft should propose  
> "optimizations" and "limited extensions" to ND. It is not the case  
> at the moment. The proxy ND proposal, the mandatory addressing model  
> proposed, also goes beyond the scope of the document as spelled out  
> in the charter.
> - non transitivity is not a lowpan only issue, hence if adaptations  
> to ND must be done, it should be in another WG, probably 6man
>
> - it questions the applicability of IPv6 in smart object networks:  
> the draft is redesigning roughly 80% of RFC4861 and RFC4862, which  
> are core to IPv6
> - existing IPv6 implementations will be strongly impacted, as a  
> number of major components will have to become layer 2 dependant:
> -- IPv6 addresses will not be configurable if their IID is not based  
> on the MAC address
> -- ... all these changes are 6lowpan dependant, as they do not  
> impact traditional links. This will raise important interoperability  
> issues.
> - new layer 3 protocol designs will become layer 2 dependant. This  
> is what is currently happenning in the ROLL WG by proposing to use a  
> Moreover, a number of existing deployments show that the issues  
> arised on lowpan networks as far as ND is concerned are not huge:  
> the deployments work, and ND as it is has proven to be power  
> consumption friendly. DAD is the most problematic procedure, that  
> requires work, as two hop neighbors do not see NS sent for DAD (see  
> at the bottom)
>
> In conclusion, I believe the advantages of rebuilding neighbor  
> discovery for lowpans are by far inferior to those of keeping using  
> the "same IP" on all medium. If some redesign has to be done, it  
> MUST be done in a more general fashion, probably in 6man, and in a  
> much lighter way.
>
> Best,
> Julien
>
> DAD issue description:
> node A and node C see node B, but not each other. nodes A and B  
> boot, configure a link local address, perfom traditional DAD. It  
> works. Node C boots with the same MAC address than A, configures the  
> same IP address, sends a NS to perform traditional DAD. A does not  
> see the NS hence C address configuration works. A and C have the  
> same address. B will not differentiate A and

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Oct 2009 21:13:19 +0200

On Oct 12, 2009, at 21:01, JP Vasseur wrote:

> I do not think that the issue is the code size itself but a change  
> in the architecture, thus

6LoWPAN-ND is "compatible with 4861".
(BTW, the "architecture" of IPv6 is in 2460, and we are not optimizing  
that.)

I'd love to learn about a simpler approach for mapping IPv6 to the  
link layer -- 6lowpan has been working on ND optimizations since  
February 2006 (probably longer, that's just the date of Samita/Erik's  
first I-D).
It has been clear from the beginning that 4861 needs massive help,  
either from a mesh-under protocol (which can give us full transitivity  
plus multicast with reasonable delivery probability, both not present  
in 802.15.4 but preconditions for 4861 to work) or from ND  
optimizations.  Since we are not standardizing mesh-under routing, we  
focused on the latter.
Since Dublin, we have pretty much nailed down the technical approach,  
supporting both less expensive mesh-under protocols and route-over.   
That was a year ago.  We had seven working-group drafts since, all  
pretty much the same protocol.

Why are people now suddenly discovering their love with the original  
4861?
Sure it would be nice if that "just worked", but it doesn't.
Do we really need to repeat all the discussions we have had the last  
four years?

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Oct 2009 22:46:09 +0300

Julien,

On Oct 12, 2009, at 15:47 , Julien Abeille (jabeille) wrote:

> - RFC4861 and RFC4862, which are core to IPv6,

This is simply not true. IPv6 is RFC2460. Neighbor Discovery is a one- 
hop link protocol originally defined in RFC4861 and clearly pointing  
out its need for link-specific extensions and in particular non- 
transitive links.

> are being very heavily redesigned. I believe that the proposal if it  
> is done in 6lowpan MUST be designed as an optional extension to ND,  
> not a redesign. The charter states that the draft should propose  

These are also not true. The extended LoWPAN model is optional. There  
is also no mandatory addressing model?

> to ND must be done, it should be in another WG, probably 6man

It is a problem we have in this WG, and a problem that the industry  
needs solved now, not in several years. Networks built around RFC4944  
using route-over routing simply don't work. Non-transivity is also not  
the only problem. Sleeping nodes is another problem which is just as  
serious for RFC4861.

> the draft is redesigning roughly 80% of RFC4861 and RFC4862, which  

They define ND over Ethernet links. They are not core to IPv6.

> number of major components will have to become layer 2 dependant:

Existing IPv6 implementations are on mainly on PCs. You can very  
easily make make any IPv6 stack work with a 6lowpan network interface  
- without any code changes. We have implemented this in several ways.

If you run this under a PC IPv6 stack then you don't change any code.  
If you are referring to modifying the few IPv6 implementations there  
are for 6LoWPAN nodes then there is not a large installation base.

> -- IPv6 addresses will not be configurable if their IID is not based  

This is also not true. Based on your feedback and that of others,  
6lowpan-nd-06 states that in networks where the above is not true,  
then there is a mechanism for performing address resolution on the  
host-router interface. Furthermore, most MACs used with 6LoWPAN have  
fully configurable MAC addresses.

> impact traditional links. This will raise important interoperability  

What interoperability issues. ND is a link protocol. Do you want your  
Ethernet link to talk to your 802.15.4 link directly (now that is  
interoperability!).

> different message to transport routing information, depending on the  

This is a result of trying to piggyback messages on ND, which is a  
link protocol. By the way Julien - you are opposed to doing that - so  
then there is no problem!

> requires work, as two hop neighbors do not see NS sent for DAD (see  

This is totally not true. You have implemented RFC4861 on Contiki. Did  
you try to make that work over multiple hops, with sleeping nodes, in  
a real deployment? It doesn't work. NS/NA fails. DAD fails. NUD fails.  
We have been deploying 6LoWPAN commercially for almost 2 years, and  
can say you need a different solution. Early RFC4944 also mostly badly  
or partially made use of RFC4861 messages to try and make things work.

This working group sat on the problem for 3 years, and this is an  
organic solution as a result of lots of work. By the way, you  
participated in that work.

> MUST be done in a more general fashion, probably in 6man, and in a  

Again, the same IP has nothing to do with RFC4861. And I don't see  
what is "heavy" about 6LoWPAN ND.

If you want to use RFC4861 to build your LoWPANs, go ahead. The rest  
of us that want LoWPANs that actually function can use 6LoWPAN-ND. If  
you want to start general work on ND improvements in addition to this  
then why not. But it is not either-or.

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain  
legally privileged information. If you are not the intended recipient,  
please contact the sender and delete the e-mail from your system  
without producing, distributing or retaining copies thereof.

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 12 Oct 2009 13:01:11 -0700

> 4861 to handle the case of non transitive links that preserves the  

I do agree that we have to be very careful with the architectural  
implications.  For me, it's not about whether or not we require an  
extra router in between or some extra code.  It's more about making  
sure we are OK with the proposed simplifications changing the  
semantics of ND operations defined (explicitly or implicitly) by RFC  
4861.  Some examples that come to mind:

1) Assuming that link-layer addresses can always be computed from  
IIDs.  While this assumption can remove the need for NS/NA for address  
resolution, the implication is that the IIDs are limited to the link- 
layer addresses in use.  802.15.4 radio hardware is typically limited  
to one short and one extended address at a time and that limits the  
number and structure of IIDs that can be assigned at any time.

2) Using NR/NC exchanges to provide NUD.  With the current draft, NR/ 
NC exchanges only maintain reachability information for the link-local  
address of the attachment router.  However, NR/NC exchanges, as  
defined, cannot provide reachability information for global  
addresses.  Additionally, NR/NC messages cannot be used to maintain  
reachability information for neighboring hosts (not routers).

I'm not convinced that these are the only examples that we need to be  
aware of with the existing draft.  I'm also not convinced that enough  
people have weighed in on the examples above to say that such  
implications are OK

--
Jonathan Hui

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Oct 2009 23:09:39 +0300

> 4861.  Some examples that come to mind:

Yep, and this is why people need to read and comment on the draft. I  
like this approach.

> IIDs.  While this assumption can remove the need for NS/NA for  
> address resolution, the implication is that the IIDs are limited to  
> the link-layer addresses in use.  802.15.4 radio hardware is  
> typically limited to one short and one extended address at a time  
> and that limits the number and structure of IIDs that can be  
> assigned at any time.
>

Actually this is not true anymore in nd-06. Based on feedback in  
Stockholm, we relaxed the IID-MAC mapping assumption. If you have a  
LoWPAN that for some reasons assigns an IID that requires address  
resolution, this can be performed on the host-router interface.

> NC exchanges only maintain reachability information for the link- 
> local address of the attachment router.  However, NR/NC exchanges,  
> as defined, cannot provide reachability information for global  

Good example. If this is really a problem we can look at ways to  
improve that of course. I don't follow you on why they can't provide  
reachability info for global addresses (from Address Options) - but  
let's talk about that separately.

> I'm not convinced that these are the only examples that we need to  
> be aware of with the existing draft.  I'm also not convinced that  
> enough people have weighed in on the examples above to say that such  
> implications are OK

This is exactly what last call is for ;-) Forcing everyone to actually  
read the thing again, and to make constructive comments.

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 12 Oct 2009 13:54:07 -0700

> resolution, this can be performed on the host-router interface.

That's great, but can you explain how a node determines whether or not  
it needs to perform address resolution?  I wasn't able to find how in  
draft-06.

>> 2) Using NR/NC exchanges to provide NUD.  With the current draft,  
>> NR/NC exchanges only maintain reachability information for the link- 

Testing reachability is traditionally done by actually using the  
target address to send messages.  Using the address options only tells  
you that the node *thinks* they are assigned to the interface - it  
does not test that communication
is actually possible when using the target address.

>> enough people have weighed in on the examples above to say that  
>> such implications are OK
>
> This is exactly what last call is for ;-) Forcing everyone to  
> actually read the thing again, and to make constructive comments.

I was trying to encourage people to spend the extra cycles by raising  
some issues I'm aware about, irrespective of whether or not the draft  
is in WGLC.

--
Jonathan Hui

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 12 Oct 2009 15:20:39 -0600

Zach,
  I would prefer not to use the WGLC as a forcing function to get folks to
really read and think about this document.  I hope that this discussion will
cause everyone to re-read the draft and think about the issues that are
being brought up and get this discussed on the list.

I think that these are extremely important issues and concerns raised by
some.  As I have said, I'm not opposed to the ND optimizations.  I would
like to see them as optional optimizations such that if I'm building a very
simple embedded network and I want the smallest least cost seamless solution
then I'm not required to implement these ND optimizations and whiteboards,
but could choose to interact with a completely standard RFC4861 ND router.

For those networks such as ISA100 that have designs/architectures and
requirements for the features of these optimizations then they can and
should use 6lowpan ND.

    geoff

On Mon, Oct 12, 2009 at 2:09 PM, Zach Shelby <[email-masked]> wrote:

>>> I do not think that the issue is the code size itself but a change in the
>>> architecture, thus
>> implications.  For me, it's not about whether or not we require an extra
>> router in between or some extra code.  It's more about making sure we are OK
>> with the proposed simplifications changing the semantics of ND operations
>> defined (explicitly or implicitly) by RFC 4861.  Some examples that come to
>> mind:
>>
>>
> Yep, and this is why people need to read and comment on the draft. I like
> this approach.
>
>  1) Assuming that link-layer addresses can always be computed from IIDs.
>>  While this assumption can remove the need for NS/NA for address resolution,
>> the implication is that the IIDs are limited to the link-layer addresses in
>> use.  802.15.4 radio hardware is typically limited to one short and one
>> extended address at a time and that limits the number and structure of IIDs
>> that can be assigned at any time.
>>
>>
> Actually this is not true anymore in nd-06. Based on feedback in Stockholm,
> we relaxed the IID-MAC mapping assumption. If you have a LoWPAN that for
> some reasons assigns an IID that requires address resolution, this can be
> performed on the host-router interface.
>
>  2) Using NR/NC exchanges to provide NUD.  With the current draft, NR/NC
>> exchanges only maintain reachability information for the link-local address
>> of the attachment router.  However, NR/NC exchanges, as defined, cannot
>> provide reachability information for global addresses.  Additionally, NR/NC
>> messages cannot be used to maintain reachability information for neighboring
>> hosts (not routers).
>>
>>
> Good example. If this is really a problem we can look at ways to improve
> that of course. I don't follow you on why they can't provide reachability
> info for global addresses (from Address Options) - but let's talk about that
> separately.
>
>> aware of with the existing draft.  I'm also not convinced that enough people
>> have weighed in on the examples above to say that such implications are OK
>>
>
> This is exactly what last call is for ;-) Forcing everyone to actually read
> the thing again, and to make constructive comments.
>
> Zach
>
>
>> --
>> Jonathan Hui
>>
> please contact the sender and delete the e-mail from your system without
> producing, distributing or retaining copies thereof.
>
>
>

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 12 Oct 2009 15:30:23 -0600

> (BTW, the "architecture" of IPv6 is in 2460, and we are not optimizing  

Carsten,
  Is this true?  Could I have a 6lowpan node that implemented just
standard 4861 that is one ip hop from the edge router that has
implemented 6lowpan ND and have it get back a standard 4861 RA.

Second could I have node that has implemented 6lowpan ND and have it be
able to interact with a router that implements only RFC4861?

If this is true, then this is excellent news.

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 12 Oct 2009 15:37:54 -0600

Colin,
  I hope that 6lowpan ND is not a "necessary" evil.

I would like to be able to support the scenario where I can plug a
simple device into my PC or my existing router and have the PC or router
be able to provide RA/RS support for my 6lowpan nodes without having to
change any code on the PC or router.

	geoff

On Mon, 2009-10-12 at 17:46 +0100, Colin O'Flynn wrote:
> Hello,
> 
>  
> 
> I understand the problems with ‘redesigning’ a core IPv6 protocol. 
> 
>  
> 
> However I’m curious about existing implementations that use full IPv6
> ND, do you have details?
> 
>  
> 
> I see the 6LoWPAN ND as a ‘necessary evil’, however I would love to be
> proven wrong! 
> 
>  
> 
> Regards,
> 
>  
> 
>    -Colin
> 
>  
> 
> redesigned. I believe that the proposal if it is done in 6lowpan MUST
> be designed as an optional extension to ND, not a redesign. The
> charter states that the draft should propose "optimizations" and
> "limited extensions" to ND. It is not the case at the moment. The
> proxy ND proposal, the mandatory addressing model proposed, also goes
> beyond the scope of the document as spelled out in the charter.
> 
> 
> draft is redesigning roughly 80% of RFC4861 and RFC4862, which are
> core to IPv6
> 
> 
> friendly. DAD is the most problematic procedure, that requires work,
> as two hop neighbors do not see NS sent for DAD (see at the bottom)
> 
> 
>  
> 
> 
> the "same IP" on all medium. If some redesign has to be done, it MUST
> be done in a more general fashion, probably in 6man, and in a much
> lighter way.
> 
> 
>  
> 
> 
> Best,
> 
> 
> Julien
> 
> 
>  
> 
> 
> DAD issue description:
> 
> 
> configure a link local address, perfom traditional DAD. It works. Node
> C boots with the same MAC address than A, configures the same IP
> address, sends a NS to perform traditional DAD. A does not see the NS
> hence C address configuration works. A and C have the same address. B
> will not differentiate A and 
> 
>

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 12 Oct 2009 15:42:53 -0600

> It's really as simple as that.

But with a mesh under or a simple star can't then 4861-ND work.  There
are plenty of scenarios where this is applicable.

	geoff

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Oct 2009 23:52:40 +0200

On Oct 12, 2009, at 23:30, Geoff Mulligan wrote:

> standard 4861

No.
That's not the meaning of "compatible" I meant.

Since 4861 never worked on 6lowpan (with the exception of 1) a two- 
node 6lowpan, or 2) a fully transitive mesh-under with reasonably  
reliable multicast delivery, yadda yadda), there is very little use  
for that kind of compatibility.

I think two-node 6lowpans and fully transitive mesh-unders are not the  
main applications we have in mind.
(Yes, >2-node networks that happen to have full-mesh radio  
connectivity also work, until they no longer happen to have it.  Given  
the vagaries of radio propagation, I don't think that's sound design.)

Even if 4861 worked for more interesting cases, the simplifications of  
6lowpan-ND are a net win for constrained nodes.
The only nodes that need code for both 4861 and 6lowpan-ND are the  
Edge Routers; of course the two protocols are similar enough that most  
of this code will be shared.
The use case of "having my laptop in a 6lowpan" is probably best  
solved by the driver adaptation/translation I described.

Gruesse, Carsten

---

From: Mikko Saarnivala <[email-masked]>
Date: Tue, 13 Oct 2009 01:09:19 +0300

Geoff, All,

Geoff Mulligan wrote:
> Zach,
>   I would prefer not to use the WGLC as a forcing function to get folks 
> to really read and think about this document.  I hope that this 
> discussion will cause everyone to re-read the draft and think about the 
> issues that are being brought up and get this discussed on the list.

I think the words "just get it done" were used by some of the wg meeting 
  attendees during the Stockholm ietf to describe what should be done 
with the nd draft. As all open tickets have been solved already I don't 
see other option than going to WGLC.

> like to see them as optional optimizations such that if I'm building a 
> very simple embedded network and I want the smallest least cost seamless 
> solution then I'm not required to implement these ND optimizations and 
> whiteboards, but could choose to interact with a completely standard 
> RFC4861 ND router.

[general rant on the topic]

I absolutely don't want to see different flavors of 6lowpan. And to be 
honest I feel that implementing 6lowpan-nd on a resource constrained 
node and router (in the access point/gateway sense of the word) is by 
far easier than implementing a really working nd solution on these 
nodes. We've implemented a full 6lowpan stack (including latest nd & hc 
drafts) and a basic edge router (incl. whiteboard etc.) functionality on 
an 8051 with 64k of flash - it's not complicated!

I couldn't agree more with Zach's and Carsten's comments about RFC4861 
being link-specific. And don't get me wrong nd-06 still might have some 
problems as Jonathan pointed out - those problems obviously have to be 
sorted out.

 From a practical experience: using a 6lowpan 802.15.4 interface 
connected to a PC with the v6 stack of the PC _does not_ require any 
changes to the PC v6 stack. A very small amount of extra code on a USB 
dongle itself or a small user-space application will suffice. We know 
for a fact that this is a) simple and b) it works just great so I hope 
that you can understand why I actually don't see any good reason for 
using RFC4861 ND _at all_ in 6lowpan networks.

[/rant]

Cheers,
mikko

-- 
Mikko Saarnivala
CTO
Sensinode Ltd.
Hallituskatu 13-17 D
90100 OULU
FINLAND

tel: +358 10 387 8686
mobile: +358 50 569 6287
email: mikko.saarnivala[a]sensinode.com
home: www.sensinode.com

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 12 Oct 2009 17:44:11 -0600

a simple star is not not two-node 6lowpan.  I have a seen and used a
simple star lowpan that was able to cover an entire house (10+ nodes)
and 4861 would have worked just fine here.

I don't know what you have in mind, but as I have said over and over I
do have in mind multi-mode star networks and mesh under networks (this
was my original conception of 6lowpan) that would work just fine with
4861.

It is not fine to say, oh just add code to the edge router.  In the
applications that I'm building (home controls, environmental
monitoring, ...) cost is important and extra code costs.

If there is a way such that there is interoperability then wonderful.

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 12 Oct 2009 17:47:04 -0600

> problems as Jonathan pointed out - those problems obviously have to

So if there are still problems we shouldn't use a WGLC to sort them out.

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 12 Oct 2009 17:48:48 -0600

> using RFC4861 ND _at all_ in 6lowpan networks.

And from practical experience I do see a use for 4861 in 6lowpan
networks.

	geoff

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Oct 2009 07:43:59 +0200

> and 4861 would have worked just fine here.

If "simple star" means that every node can only reach a hub node and  
v.v., then 4861 does not "work".

If "simple star" means everyone can reach everyone (radio full mesh  
connectivity in the n*(n-1) sense without needing a mesh routing  
protocol), then 4861 works fine, until there is an impairment between  
two nodes.

If "simple star" means the hub relays all packets that need to reach  
other nodes (e.g., using the 6lowpan mesh header), then yes, 4861  
works.  Still, 6lowpan-nd would reduce the burden on all nodes  
involved (code size, multicast traffic), except for the quite small  
increase in code size on the edge router (hub, I presume).

The engineering tradeoffs are seriously arguing against burdening  
constrained nodes with 4861.  We can't have it both ways: allow  
"flexibility" (by letting nodes choose between 4861 and 6lowpan-nd)  
and interoperability.  Since 4861 breaks down as soon as the lowpan  
starts to get a little more complicated, it is a bad decision to  
retain 4861 just out of nostalgia.

This whole discussion only makes sense if you somehow believe 4861 to  
be simpler than 6lowpan-nd.  Not so.

Discarding the 4861 option for intra-lowpan use is not a "problem", it  
is a welcome reduction in complexity.

It all comes down to a lesson some of us have learned the hard way:  
options create complexity, interoperability problems, and considerable  
cost.  Avoid options at all cost!

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Tue, 13 Oct 2009 10:38:13 +0300

> for that kind of compatibility.

It also works for the 2-node case only if those nodes are on all the  
time. Sleeping nodes are a big problem also for a simple mesh-under  
network. It basically looks like non-transivity.

ND is a link protocol, you need to run the same protocol on all  
interfaces of the same link. If you really want to deploy a simple  
LoWPAN with RFC4861 you can do that. Just make sure you run RFC4861 on  
all interfaces. I'm not convinced of the value of even requiring that  
they are mixed.

> I think two-node 6lowpans and fully transitive mesh-unders are not  
> the main applications we have in mind.
> connectivity also work, until they no longer happen to have it.   
> Given the vagaries of radio propagation, I don't think that's sound  
> design.)
>
> Even if 4861 worked for more interesting cases, the simplifications  
> of 6lowpan-ND are a net win for constrained nodes.
> Edge Routers; of course the two protocols are similar enough that  
> most of this code will be shared.

It is already possible to plug a simple device into a PC today and it  
works with a standard IPv6 stack. Over the air we of course speak  
6LoWPAN-ND. But to the IPv6 stack it is transparent. This I don't see  
as an issue.

- Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Oct 2009 11:01:59 +0200

In perfect agreement with you and Zach's answer.

If I might comment on

>reachability information for neighboring hosts (not routers).

This is a conscious decision. 

If we take an 802.11 ad hoc network as an example of a LoWPAN. In this
network, RFC4861 is clearly broken but 6LoWPAN ND, complemented with a
routing protocol such as RPL, would do a perfect job.

Now, if you add an access point and use infra mode, then the nodes start
registering to the AP and the AP relays the packets between 2 nodes.

If you look at it, the router operation generalizes at L3 the L2
operation of infrastructure mode: 
* Nodes register to their router and use that router to forward to other
nodes. 
* In route over mode, we have a routing protocol within the subnet that
enables topologies that are way more complex and dynamic than a BSS or
an ESS. 
* And Multicast can be supported though it is not needed for ND itself
(too costly).
* The registration via an edge router is akin to an association in that
it defines a set of nodes. The edge router proxies ND in a way that
reminds of the transparent bridge operation in an AP.

Same causes, same effects, just larger and wider since we place the
operation at L3.

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Hui
>Sent: lundi 12 octobre 2009 22:01
>To: JP Vasseur (jvasseur)
>Cc: 'Carsten Bormann'; '6lowpan'

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Oct 2009 13:55:18 +0200

Hi Jonathan

>it needs to perform address resolution?  I wasn't able to find how in

A good thing to clarify for sure;

I do not remember that we have left anything on target address
resolution.

In route over, the only address(es) that the node uses at the moment is
that of its router(s). The address is found in the RA source MAC and the
neighbor relationship is maintain using NR/NC messages. The draft does
not attempt to shortcut for P2P - then again the model is very similar
to 802.11 infra mode. There's discussion at RPL about line of sight P2P,
though, and it appears that we could add something like multicast
NA(override) when the address is obtained (and renewed). 

In mesh under, there used to be some text inherited from the backbone
router draft about using the edge router for address resolution. The
edge router would be answering with either its own address if the target
is to be reached over the backbone of the address of the node if the
target is to be reached over the mesh. But the backbone router draft was
really minded 802.15.4 and mesh under. This service cannot be
generalized to all sorts of NBMA/P2MP where the edge router cannot be
assumed to know whether the node can see its destination at L2 and if so
at which address. 

Considering how little assumptions we can safely make about mesh under
in general, we dropped resolution and redirection, and stayed on common
grounds with route over, that is reachability via the routers. If a
given media offers more direct routes and L2 triggers like an (I-)LMI
status indicating a Virtual Circuit up/down, then an existing technique
such as inverse ND can be used on top of 6LoWPAN ND to resolve those.

>is actually possible when using the target address.

Good thing to clarify as well:

Address resolution is not used/needed/required when there is a router
between a node and its target. ICMP unreachable is your friend there.
Since the draft always goes through the router, only the router needs
actual (un)reachability testing.
The draft uses NR/NC messages to cover the node to router hop and ICMP
unreachable for all other destinations.

Then again, some mesh under networks might provide additional P2P
connectivity, and then again, there's existing ND operation such as
RFC3122 that can be used there. No re-inventing the wheel, no sir.

>some issues I'm aware about, irrespective of whether or not the draft

What seems left somewhat open from your mail is:

1) whether a node c/should mcast NA(OverRide) for line of sight P2P. I'd
be OK to allow that?

2) whether NR/NC messages do an appropriate job for NUD. At the moment
they are simply periodic. 
   Is that enough? Personally I think so.

Cheers,

Pascal

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 13 Oct 2009 15:23:19 +0200

Hi Colin,
 
any stack that passes IPv6 ready tests does, i know two of these, one
being Contiki/uipv6.
 
Best,
Julien

	From: Colin O'Flynn [mailto:[email-masked]] 
	Sent: lundi 12 octobre 2009 18:46
	To: Julien Abeille (jabeille); '6lowpan'
	Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND

	Hello,

	I understand the problems with 'redesigning' a core IPv6
protocol. 

	However I'm curious about existing implementations that use full
IPv6 ND, do you have details?

	I see the 6LoWPAN ND as a 'necessary evil', however I would love
to be proven wrong! 

	Regards,

	   -Colin

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Abeille (jabeille)
	Sent: October 12, 2009 1:47 PM
	To: 6lowpan
	Subject: [6lowpan] Fundamental concerns about 6lowpan ND

	Dear WG,

	I have serious concerns about the 6lowpan ND draft and would
like to have the WG opinion on this. I agree that a few issues arise in
lowpan environments, which are mostly linked to the non transitivity of
some link layers used in lowpans. However, my two major points of
concern are:

	- RFC4861 and RFC4862, which are core to IPv6, are being very
heavily redesigned. I believe that the proposal if it is done in 6lowpan
MUST be designed as an optional extension to ND, not a redesign. The
charter states that the draft should propose "optimizations" and
"limited extensions" to ND. It is not the case at the moment. The proxy
ND proposal, the mandatory addressing model proposed, also goes beyond
the scope of the document as spelled out in the charter.

	- non transitivity is not a lowpan only issue, hence if
adaptations to ND must be done, it should be in another WG, probably
6man

	- it questions the applicability of IPv6 in smart object
networks: the draft is redesigning roughly 80% of RFC4861 and RFC4862,
which are core to IPv6

	-- IPv6 addresses will not be configurable if their IID is not
based on the MAC address

	- new layer 3 protocol designs will become layer 2 dependant.
This is what is currently happenning in the ROLL WG by proposing to use
a different message to transport routing information, depending on the
medium.

arised on lowpan networks as far as ND is concerned are not huge: the

	In conclusion, I believe the advantages of rebuilding neighbor
discovery for lowpans are by far inferior to those of keeping using the
"same IP" on all medium. If some redesign has to be done, it MUST be
done in a more general fashion, probably in 6man, and in a much lighter
way.

	Best,

	Julien

	DAD issue description:

	node A and node C see node B, but not each other. nodes A and B
boot, configure a link local address, perfom traditional DAD. It works.
Node C boots with the same MAC address than A, configures the same IP
address, sends a NS to perform traditional DAD. A does not see the NS
hence C address configuration works. A and C have the same address. B
will not differentiate A and

---

From: Adam Dunkels <[email-masked]>
Date: Tue, 13 Oct 2009 15:36:12 +0200

> any stack that passes IPv6 ready tests does, i know two of these, one 

And Arch Rock.

/adam

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 13 Oct 2009 14:50:49 +0100

Yes, but is Contiki a usable implementation for what we want to do?

How well does sleeping or mesh routing work for instance? That is what I
mean by an implementation that uses full ND6 - someone doing mesh + sleeping
+ RFC4861/2.

Regards,

  -Colin

From: Julien Abeille (jabeille) [mailto:[email-masked]] 
Sent: October 13, 2009 2:23 PM
To: Colin O'Flynn; 6lowpan
Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND

Hi Colin,

any stack that passes IPv6 ready tests does, i know two of these, one being
Contiki/uipv6.

Best,

Julien

  _____  

Hello,

Regards,

   -Colin

Dear WG,

Best,

Julien

DAD issue description:

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 13 Oct 2009 16:05:12 +0200

Arch Rock.
Jonathan, can you give detais?
Best,
Julien

	From: Colin O'Flynn [mailto:[email-masked]] 
	Sent: mardi 13 octobre 2009 15:51
	To: Julien Abeille (jabeille); '6lowpan'
	Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND

	Yes, but is Contiki a usable implementation for what we want to
do?

	How well does sleeping or mesh routing work for instance? That
is what I mean by an implementation that uses full ND6 - someone doing
mesh + sleeping + RFC4861/2.

	Regards,

	  -Colin

	Hi Colin,

	any stack that passes IPv6 ready tests does, i know two of
these, one being Contiki/uipv6.

	Best,

	Julien

		From: Colin O'Flynn [mailto:[email-masked]] 
		Sent: lundi 12 octobre 2009 18:46
		To: Julien Abeille (jabeille); '6lowpan'
		Subject: RE: [6lowpan] Fundamental concerns about
6lowpan ND

		Hello,

		However I'm curious about existing implementations that
use full IPv6 ND, do you have details?

		I see the 6LoWPAN ND as a 'necessary evil', however I
would love to be proven wrong! 

		Regards,

		   -Colin

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Julien Abeille (jabeille)
		Sent: October 12, 2009 1:47 PM
		To: 6lowpan
		Subject: [6lowpan] Fundamental concerns about 6lowpan ND

		Dear WG,

		I have serious concerns about the 6lowpan ND draft and
would like to have the WG opinion on this. I agree that a few issues
arise in lowpan environments, which are mostly linked to the non
transitivity of some link layers used in lowpans. However, my two major
points of concern are:

		- RFC4861 and RFC4862, which are core to IPv6, are being
very heavily redesigned. I believe that the proposal if it is done in
6lowpan MUST be designed as an optional extension to ND, not a redesign.
The charter states that the draft should propose "optimizations" and
"limited extensions" to ND. It is not the case at the moment. The proxy
ND proposal, the mandatory addressing model proposed, also goes beyond
the scope of the document as spelled out in the charter.

		- existing IPv6 implementations will be strongly
impacted, as a number of major components will have to become layer 2
dependant:

		-- IPv6 addresses will not be configurable if their IID
is not based on the MAC address

		-- ... all these changes are 6lowpan dependant, as they
do not impact traditional links. This will raise important
interoperability issues.

		- new layer 3 protocol designs will become layer 2
dependant. This is what is currently happenning in the ROLL WG by
proposing to use a different message to transport routing information,
depending on the medium.

		Moreover, a number of existing deployments show that the
issues arised on lowpan networks as far as ND is concerned are not huge:
the deployments work, and ND as it is has proven to be power consumption
friendly. DAD is the most problematic procedure, that requires work, as
two hop neighbors do not see NS sent for DAD (see at the bottom)

		In conclusion, I believe the advantages of rebuilding
neighbor discovery for lowpans are by far inferior to those of keeping
using the "same IP" on all medium. If some redesign has to be done, it
MUST be done in a more general fashion, probably in 6man, and in a much
lighter way.

		Best,

		Julien

		DAD issue description:

		node A and node C see node B, but not each other. nodes
A and B boot, configure a link local address, perfom traditional DAD. It
works. Node C boots with the same MAC address than A, configures the
same IP address, sends a NS to perform traditional DAD. A does not see
the NS hence C address configuration works. A and C have the same
address. B will not differentiate A and

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 13 Oct 2009 15:34:19 +0100

Hello,

>monitoring, ...) cost is important and extra code costs.

I think the extra code is marginal here. Your usb stick that plugs into your
computer will have lots of extra horsepower [see example at end of e-mail].

And if you were making a 802.15.4 to Ethernet bridge, anything with an
Ethernet MAC built in will have even more SRAM/FLASH available. I'm all for
small code size and less complexity, but to me it seems:

- Your edge router or 802.15.4 to XXX bridge will have spare horsepower as
an artifact of how microcontrollers are priced / what features are included
- Using 6lowpan-ND saves complexity on end nodes, at the possible expense of
a little extra code at edge routers

Since you'll have more end nodes than edge routers, that trade-off seems
worth it to me!

Regards,

  -Colin

USB Microcontroller Pricing Examples:

With an Atmel micro, you might go for something like an AT32UC3B164 - 64K
flash, 16K SRAM, $3.48 in qty 100. That is the cheapest USB micro by Atmel
that would work - anything else would not have enough SRAM to implement a
USB Ethernet interface anyway. It's cheaper than the 8-bit AVRs with USB
interfaces....

If Microchip was your fancy, something like the PIC24FJ32GB002 at $2.70 in
qty 100. It has 8K SRAM and 32K of FLASH.

---

From: Adam Dunkels <[email-masked]>
Date: Tue, 13 Oct 2009 19:15:32 +0200

Colin O'Flynn wrote:
> mean by an implementation that uses full ND6 – someone doing mesh + 
> sleeping + RFC4861/2.

Sleeping in Contiki is done with a duty-cycled radio mechanism where the 
radio is switched off for most of the time and turned on for a few 
milliseconds to check for radio activity. If there is radio activity, 
the radio is kept on to receive the full packet. To send a packet, the 
sender sends a string of strobe packets to wake up the receiver. This 
type of mechanism reduces the power consumption (typically to < 1% of 
the radio transceiver power) without affecting the abstraction provided 
by the link layer: nodes appear to be awake all the time, even if they 
spent most of their time sleeping.

/adam

>  
> 
> Regards,
> 
>  
> 
>   -Colin
> 
>  
> 
>  
> 
> *From:* Julien Abeille (jabeille) [mailto:[email-masked]]
> *Sent:* October 13, 2009 2:23 PM
> *To:* Colin O'Flynn; 6lowpan
> *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND
> 
>  
> 
> Hi Colin,
> 
>  
> 
>     ------------------------------------------------------------------------
> 
>     *From:* Colin O'Flynn [mailto:[email-masked]]
>     *Sent:* lundi 12 octobre 2009 18:46
>     *To:* Julien Abeille (jabeille); '6lowpan'
>     *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND
> 
>     Hello,
> 
>      
> 
>     However I’m curious about existing implementations that use full
>     I see the 6LoWPAN ND as a ‘necessary evil’, however I would love to
>     be proven wrong!
> 
>      
> 
>     Regards,
> 
>      
> 
>        -Colin
> 
>      
> 
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Julien Abeille (jabeille)
>     *Sent:* October 12, 2009 1:47 PM
>     *To:* 6lowpan
>     *Subject:* [6lowpan] Fundamental concerns about 6lowpan ND
> 
>      
> 
>     Dear WG,
> 
>      
> 
> ------------------------------------------------------------------------
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 13 Oct 2009 10:50:14 -0700

Hi Pascal,

> NA(override) when the address is obtained (and renewed).

I'm mostly interested in route-over, so I'll limit my discussion to  
that.  1-hop P2P is something we should support - there are scenarios  
where two nearby nodes may want to communicate without any additional  
infrastructure.

I think a bit of my concern is the lack of clarity in the role that  
6lowpan-nd plays in the router-router interface as well.  For example,  
what is the address resolution mechanism when communicating with next- 
hop nodes - is it NR/NC? NS/NA?  Something specific to the routing  
protocol?

> unreachable for all other destinations.

NR/NC only cover link-local addresses.  As defined, the router can  
only verify reachability to a host using its link-local address.  How  
does it test global addresses?  Does it just trust that the host has  
assigned the address to its interface when sending NR messages to  
renew the binding?

Also, same thing here on whether or not 6lowpan-nd plays any role on  
the router-router interface.  As defined today, clearly it plays some  
role because routers need to perform DAD.  But what about NUD?   
Address resolution?  We discussed how NR/NC messages may be helpful  
for certain routing protocol operations, but do they really replace  
the need for NS/NA?

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 13 Oct 2009 11:30:30 -0700

The Arch Rock stack does implement RFC 4861 in a route-over  
configuration and passes the IPv6 Ready - Phase 2 tests.  We have  
found NUD useful for determining reachability with any neighboring  
node - not just parents in the routing DAG.  We have found SLLAO  
useful for communicating both short and extended versions of the link  
address.

As for particular optimizations in practice, we have changed the  
timing parameters of when/how often to transmit certain messages.   
Also, while the stack does perform DAD when assigning an address to  
the interface, duplicates outside radio range will not be detected.   
This has not a problem because we use lightweight form of DHCP to  
assign unique addresses and have control over the system deployment.   
And while the stack does implement processing for Prefix Information  
Option, Redirect Header, or MTU options, we don't use them in practice.

The cost of link-local multicast, while significant, depends on the  
frequency of utilizing it.  In practice, RA messages dominate the use  
of link-local multicast - we use them for routing and communicating  
short link addresses.  Multicast NS messages are relatively rare due  
to neighbor caches.

Our duty-cycling link protocol is a form of channel-sampling designed  
to support the always-on abstraction.  The details of which can be  
found in Chapter 4 of [1].  We are currently in the drafting stage of  
standardizing this approach in the 802.15.4e task group.

[1] http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-116.pdf

--
Jonathan Hui

On Oct 13, 2009, at 7:05 AM, Julien Abeille (jabeille) wrote:

> How well does sleeping or mesh routing work for instance? That is  
> what I mean by an implementation that uses full ND6 – someone doing  
> any stack that passes IPv6 ready tests does, i know two of these,  
> one being Contiki/uipv6.
>
> Best,
> Julien
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Oct 2009 21:05:50 +0200

> [...] does implement RFC 4861 in a route-over configuration and  
> passes the IPv6 Ready - Phase 2 tests.

Ah, that was an eye-opener about what people mean when they say "4861  
works" -- they get the checkmark!
SCNR.

> We have found NUD useful for determining reachability with any  
> neighboring node - not just parents in the routing DAG.

That is indeed a useful function.
Using ND as a neighborHOOD discovery protocol would argue for  
implementing NS/NA, as is allowed (but not required) for 6lowpan-ND.   
NeighborHOOD discovery typically is a routing function, though, so it  
is hard to discuss this in general terms in the ND spec.  It certainly  
should not be REQUIRED if the routing protocol does not use it (e.g.,  
because it has a different neighborHOOD discovery protocol, or only  
supports host-to-host after a redirect).

> We have found SLLAO useful for communicating both short and extended  
> versions of the link address.

6lowpan-ND does not change RA from 4861, so that is still there.
(Again, NS is optional in 6lowpan-ND.)

> the interface, duplicates outside radio range will not be detected.

In fewer words, DAD does *not* work.

> assign unique addresses and have control over the

I don't think DHCPv6 can do duplicate detection on the EUI-64 (that's  
why it REQUIRES DAD), so your addresses are as unique as your EUI-64s  
are.
(NR/NC is a rather simplified form of DHCP, but adds duplicate  
detection.)

My summary of this discussion:
If we decide we don't need DAD, we can really simplify ND!

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 13 Oct 2009 12:49:39 -0700

On Oct 13, 2009, at 12:05 PM, Carsten Bormann wrote:

> Ah, that was an eye-opener about what people mean when they say  
> "4861 works" -- they get the checkmark!
> SCNR.

For me, the discussion isn't whether or not RFC 4861 works - some of  
the mechanisms it defines clearly does not work in the networks we  
care about.  The discussion is whether or not there are aspects of RFC  
4861 that we should NOT be changing but are.

Another discussion point to raise is the properties of the "binding  
table" vs. the "neighbor cache".  A significant difference is that the  
binding table is no longer a cache in the sense that the attachment  
router MUST maintain state about any host currently attached to it.   
If the binding table is full, a node cannot attach to it.  Is this a  
concern for some?

> implementing NS/NA, as is allowed (but not required) for 6lowpan- 
> ND.  NeighborHOOD discovery typically is a routing function, though,  
> so it is hard to discuss this in general terms in the ND spec.  It  
> certainly should not be REQUIRED if the routing protocol does not  
> use it (e.g., because it has a different neighborHOOD discovery  
> protocol, or only supports host-to-host after a redirect).

NeighborHOOD discovery would also include address resolution.  While  
the draft currently states that NS/NA are "not required", perhaps it  
would be more correct to say that the implementation of processing NS/ 
NA messages is required as per RFC 4861, but that the transmission of  
them is optional.  Or did we really intend to make their  
implementation optional as well?

>> We have found SLLAO useful for communicating both short and  
>> extended versions of the link address.
>

Understood.

> In fewer words, DAD does *not* work.

Exactly.  DAD requires a different mechanism - but are we sure other  
parts of the draft are simply optimizations to RFC 4861?

> I don't think DHCPv6 can do duplicate detection on the EUI-64  
> (that's why it REQUIRES DAD), so your addresses are as unique as  
> your EUI-64s are.

The server doesn't have to assign an address if it doesn't want to.   
The address doesn't have to map to the node's EUI-64 (bad for  
compression, but why people argue for address resolution).  The node  
may change it's EUI-64 (original reason why we thought we didn't need  
address resolution).  Philosophically, I'd prefer to avoid duplicates  
rather than detect them.

> If we decide we don't need DAD, we can really simplify ND!

My words would be: if we don't need DAD, then its really just the  
applicable parts of RFC 4861.

--
Jonathan Hui

---

From: Zach Shelby <[email-masked]>
Date: Wed, 14 Oct 2009 00:35:41 +0300

Jonathan,

The discussion below is really useful. Aside from do we need to  
perform DAD (yes, we do, but I'll get back to that later) - what I  
hear you saying is that being able to perform functions like NUD and  
AR within your local scope is useful? This really is local neighbor  
discovery as it only gets you one hop. NS/NA doesn't help you with  
neighborHOOD operations (across the whole LoWPAN).

If the link is providing a mechanism to deal with sleeping neighbors  
(you can't always assume that though), then NS/NA would allow you to  
check on those neighbors for NUD. Is NUD really useful just for nodes  
within radio range (maybe a very small subset of the LoWPAN)?  
Separately there needs to be a discussion if AR is needed at all and  
over what scope.

Currently NS/NA is totally optional for nodes to implement. In the  
last couple versions of the draft they had been unused.

Zach

On Oct 13, 2009, at 22:49 , Jonathan Hui wrote:

> care about.  The discussion is whether or not there are aspects of  
> RFC 4861 that we should NOT be changing but are.
>
> table" vs. the "neighbor cache".  A significant difference is that  
> the binding table is no longer a cache in the sense that the  
> attachment router MUST maintain state about any host currently  
> attached to it.  If the binding table is full, a node cannot attach  
> to it.  Is this a concern for some?
>
>> ND.  NeighborHOOD discovery typically is a routing function,  
>> though, so it is hard to discuss this in general terms in the ND  
>> spec.  It certainly should not be REQUIRED if the routing protocol  
>> does not use it (e.g., because it has a different neighborHOOD  
>> discovery protocol, or only supports host-to-host after a redirect).
>
> would be more correct to say that the implementation of processing  
> NS/NA messages is required as per RFC 4861, but that the  
> transmission of them is optional.  Or did we really intend to make  
> their implementation optional as well?
>
>>> Also, while the stack does perform DAD when assigning an address  
>>> to the interface, duplicates outside radio range will not be  
>>> detected.
>>
> may change it's EUI-64 (original reason why we thought we didn't  
> need address resolution).  Philosophically, I'd prefer to avoid  
> duplicates rather than detect them.
>

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 13 Oct 2009 14:55:00 -0700

Hi Zach,

> neighborHOOD operations (across the whole LoWPAN).

I guess we have different definitions of neighborhood.  I was talking  
about 1-hop radio (IP) neighbors.  I typically do not associate nodes  
multiple radio (IP) hops apart as being within the same neighborhood.

> check on those neighbors for NUD. Is NUD really useful just for  
> nodes within radio range (maybe a very small subset of the LoWPAN)?  

NUD is useful for 1-hop neighbors to determine reachability.  AR is  
required unless we assume that the binding table is *not* a cache and  
if communication only occurs with the attachment router or you can  
always compute the link address from the IID.  I've already mentioned  
some limitations in this thread that 6lowpan-nd imposes in using NR/NC  
to replace NUD and AR.

The whole discussion around sleepy nodes is problematic for me as  
well.  The link is either up or down, not sort-of kind-of.  There are  
well-known ways to preserve this abstraction at least for the time  
scales applications require.  Are we really trying to solve the DTN  
problem?

> last couple versions of the draft they had been unused.

Making NS/NA optional to implement is equivalent to saying that NUD  
and AR only occurs in the limited way that 6lowpan-nd allows.  How  
would one that implements NS/NA and one that doesn't interoperate?

--
Jonathan Hui

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 13 Oct 2009 22:56:44 +0100

Hello,

> radio is switched off for most of the time and turned on for a few 

My concern for this sleeping method is very low power nodes. These would be
parasitic nodes for example that can only wake up every few seconds at most.

These super-low power nodes could not listen continuously. Forcing them to
require waking up would basically eliminate them from the picture.

Regards,

  -Colin

-----Original Message-----
From: Adam Dunkels [mailto:[email-masked]] 
Sent: October 13, 2009 6:16 PM
To: Colin O'Flynn
Cc: 'Julien Abeille (jabeille)'; '6lowpan'
Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND

Colin O'Flynn wrote:
> mean by an implementation that uses full ND6 - someone doing mesh + 
> sleeping + RFC4861/2.

/adam

>     I see the 6LoWPAN ND as a 'necessary evil', however I would love to
>     be proven wrong!
> 
>      
> 
>     Regards,
> 
>      
> 
>        -Colin
> 
>      
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 13 Oct 2009 15:04:10 -0700

Hi Colin,

> require waking up would basically eliminate them from the picture.

For these very special devices, I often prefer to view them as  
wireless peripherals rather than IP devices.  They most likely won't  
be able to participate in forwarding/routing functions.  Any bi- 
directional communication tends not to be end-to-end since they want  
to minimize round-trip time.

--
Jonathan Hui

---

From: Zach Shelby <[email-masked]>
Date: Wed, 14 Oct 2009 01:04:45 +0300

I agree with Colin here. Duty-cycled techniques are nice, but by no  
means something we can assume for all applications or as a given for  
all links. So let's not ignore sleeping nodes completely based on this  
assumption. There may also be embedded device design reasons for  
turning devices completely off for periods of time that may have  
nothing to do with communications.

I do agree that sleeping nodes need some kind of synchronization with  
their router if that is also sleeping. But if this is asynchronous or  
synchronous for only part of the LoWPAN, it again doesn't help for  
LoWPAN-wide operations. 802.15.5 does include some synchronization  
techniques.

Zach

On Oct 14, 2009, at 0:56 , Colin O'Flynn wrote:

>> what I
>> to
>> like to
>> adaptations
>> based

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Zach Shelby <[email-masked]>
Date: Wed, 14 Oct 2009 01:15:30 +0300

On Oct 14, 2009, at 0:55 , Jonathan Hui wrote:

>> hear you saying is that being able to perform functions like NUD  
>> and AR within your local scope is useful? This really is local  
>> neighbor discovery as it only gets you one hop. NS/NA doesn't help  
>> you with neighborHOOD operations (across the whole LoWPAN).
>
> I guess we have different definitions of neighborhood.  I was  
> talking about 1-hop radio (IP) neighbors.  I typically do not  
> associate nodes multiple radio (IP) hops apart as being within the  
> same neighborhood.
>

OK, now I got you. Neighborhood is local scope and the LoWPAN is the  
whole link in 6lowpan-nd terminology.

>> If the link is providing a mechanism to deal with sleeping  
>> neighbors (you can't always assume that though), then NS/NA would  
>> allow you to check on those neighbors for NUD. Is NUD really useful  
>> just for nodes within radio range (maybe a very small subset of the  
>> LoWPAN)? Separately there needs to be a discussion if AR is needed  
>> at all and over what scope.
>
> required unless we assume that the binding table is *not* a cache  
> and if communication only occurs with the attachment router or you  
> can always compute the link address from the IID.  I've already  
> mentioned some limitations in this thread that 6lowpan-nd imposes in  
> using NR/NC to replace NUD and AR.
>

Right, those limitations were known when we added the ability to use  
NR/NC information for that. I can understand the usefulness of NUD in  
local scope.

It is a more fundamental question if we need AR at all, and how useful  
AR for only local nodes is? The whole point of 6LoWPAN is header  
compression. If you then assign IP addresses that can't be compressed  
- why bother using 6LoWPAN in the first place? In your implementation  
you make the same assumption, AR is not needed. We do the same. I am  
waiting to hear of a case where AR is actually needed and why?

> well.  The link is either up or down, not sort-of kind-of.  There  
> are well-known ways to preserve this abstraction at least for the  
> time scales applications require.  Are we really trying to solve the  
> DTN problem?
>

Yep, that would be awkward. The current text basically says that NS/NA  
is not used nor required. It just doesn't prevent it. So the current  
draft assumes NS/NA is not there (earlier it was optional). That is  
how an ND protocol should work, all nodes on the link implement the  
same protocol.

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 13 Oct 2009 23:27:34 +0100

Hi Jonathan,

I agree with you there - these nodes would *not* be participating in real IP
or mesh forwarding. 

However the ND process needs to function with these nodes. If we rely on
4861, these nodes which are going to miss packets must have a way to defend
their address!

  -Colin

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: October 13, 2009 11:04 PM
To: Colin O'Flynn
Cc: 'Adam Dunkels'; '6lowpan'
Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND

Hi Colin,

--
Jonathan Hui

---

From: Zach Shelby <[email-masked]>
Date: Wed, 14 Oct 2009 09:57:13 +0300

> I agree with you there - these nodes would *not* be participating in  

Right, not all nodes are routers. We do have the concept of a host,  
and it is a useful one also in LoWPANs.

> 4861, these nodes which are going to miss packets must have a way to  

Jonathan is assuming the link provides a service guaranteeing nodes  
within radio range can communicate within some bounded latency using  
duty-cycling or other techniques. This is an assumption you may be  
able to make. But if you do that then routers may need to answer on  
behalf of hosts as those hosts may be sleeping asynchronously to  
eachother if the router is e.g. powered.

It is safe to assume that there is synchronization on the host-router  
and router-router interfaces - OK. It is not safe to assume  
synchronization between peer hosts attached to the same router. Nor  
between different sections of a LoWPAN. No, we are not trying to solve  
DTN.

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 14 Oct 2009 09:48:52 +0100

Hello,

> But if you do that then routers may need to answer on  

So those arguing for 4861, is doing a proxy NS answer acceptable?

Regards,

  -Colin

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Oct 2009 10:58:59 +0200

> So those arguing for 4861, is doing a proxy NS answer acceptable?

Please see (and contribute to) the other thread about "assumption 1".
(From my point of view, it's a waste of energy, but I wasn't asked  
above :-)

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 14 Oct 2009 14:30:29 +0200

Hi Jonathan:

Good points to clarify :)

>If the binding table is full, a node cannot attach to it.  Is this a

Well actually I think we so improve that situation quite a bit. With
traditional ND cache, if the cache is too small, the router would keep
on flushing entries and doing NS/NA. At worse, there could be one NS/NA
per packet to be transmitted, and that could end up overloading the
router that MUST keep the packet during resolution.

With our ND, we have the capability to say NO like an admission control.
Action point would be to make sure that we have a code in the NC for the
router to tell that its resources are exceeded at that the node should
pick an alternate router.

>implementation optional as well?

In a really constrained node it can be optional. It appears that the use
cases I've seen so far where direct connectivity is really needed comes
from nodes that can actually afford it. The spec does NOT say that a
node that does 6LoWPAN-ND MUST Not do 4861 on top. It may but that's out
of scope for us. And that will provide additional forwarding
perspectives just like using RIP and OSPF on a same router will give
different routes that will require arbitration. 

6LoWPAN-ND as it stands is self sufficient, very economical, but
certainly not optimized for everything.

Cheers, 

Pascal

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 14 Oct 2009 14:57:33 +0200

Hi Brian, 

> From: Brian Haberman [mailto:[email-masked]] 
> Sent: mardi 13 octobre 2009 22:29
> Cc: Julien Abeille (jabeille); [email-masked]; 6lowpan
> Hi JP & 6lowpan WG,
>       I have not done a thorough review of the draft yet, but 
> I did have a brief read to try and understand the approach.  
> I am curious as to why this work is not progressing more 
> along the lines of the IPv6-over-foo type documents that have 
> been published in the past.  Is an 802.15.4 network that much 
> more of an onerous environment for the base IPv6 protocols 
> (modulo some modifications/extensions)?
> 
>       We had similar issues back in the 20th Century with 
> other NBMA-type links.  RFC 2491 was written to capture those 
> interfacing functions needed to allow NDP and such to operate 
> correctly.
> 
>       Is it possible that standard IPv6 nodes could operate 
> on a 6lowpan network as well as a more traditional (e.g., 
> ethernet) one?  If so, this seems like a lot of complexity 
> needed in that device to determine the type of link it is 
> operating on.
> 
This is the point we are trying to raise.
>       I agree that non-transitive links are an issue for more 
> than just
> 802.15.4 networks.  The description given could be applied to 
> 802.11 as well.  Yet, IPv6 over 802.11 works relatively well.
> 
>       It appears that a cross-WG review would be a good idea 
> at this point.  I would like to see some 6MAN contributors 
> comment on this work rather than waiting until a Last Call.
> 
How can we do this?

Thank you,
Julien
> Brian
> JP Vasseur wrote:
> would like to 
> >> of some link layers used in lowpans. However, my two major 
> points of concern are:
> very heavily 
> dependant. This is 
> >> configure a link local address, perfom traditional DAD. It works. 
> >> [email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 14 Oct 2009 15:45:01 +0200

Hi Jonathan:

I'd say that if a host hears a destination's NA(DOA) it should try that
first. 

If the medium has retries and the retries fail, then the packet should
be passed to the router(s) in which ever order the node has them. If the
failure is continuous, the node should be blacklisted with a holddown
timer.

If the medium does not have retries then reachability must be better
asserted. The means that NS/NA provide that are not sufficient for most
LoWPANs/LLNs because RCF 4861 is designed on the assumption that
reachability is boolean whereas it is rather fuzzy in our world.

All things that a RPL router have to do already :)

Pascal

Behalf Of Jonathan Hui
>Sent: mardi 13 octobre 2009 23:55
>To: Zach Shelby
>Cc: Carsten Bormann; 6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Oct 2009 16:30:06 +0200

Brian, Bob,

since JP dragged you in at this stage, let me try to summarize four  
years of discussion in one message (which probably won't work).

6LoWPANs are non-transitive, but are quite different from 20th century  
NBMA links.
We started out in 2006 by trying to modify ("optimize") 4861 to cope.   
That work led nowhere.
At the Dublin IETF, 2008, we finally decided to address the issues in  
a more radical way, and we now have a spec that is close to completion.

Some people came in later and now wonder why we abandoned the "minimum  
change" approach.
Well, we didn't, but the minimum change is a bit different than we  
originally thought.

>> Is an 802.15.4 network that much

802.15.4 networks are wireless.  Most nodes are extremely resource- 
constrained, see RFC 4919 and in particular http://tools.ietf.org/html/draft-ietf-6lowpan-routing-requirements-04 
  for details.

The main difference from 20c NBMAs (apart from the resource issue) is  
that, in a multi-hop wireless network based on low-power nodes, the  
definition of "neighbor" is much more tenuous than in ATM or FR.  So  
we arrived at a somewhat different model of links and address  
assignment.  This model is also motivated by the extremely small frame  
sizes of 802.15.4, which make header compression a core part of the  
architecture.

>> ethernet) one?

Some are, we call these "edge routers" if they actually forward  
packets.  The large majority of nodes (hosts and routers) are 6lowpan- 
only (and these are typically the extremely resource constrained 8  
MHz, 10 kB $.50 SoCs).

>> If so, this seems like a lot of complexity

I don't follow -- a node would know whether one of its interfaces is  
on a LoWPAN or an Ethernet.

More importantly, it is extremely unlikely that a LoWPAN is going to  
be set up for the same applications that we run over Ethernet today (. 
11 is much better for that purpose).

>> 802.11 as well.  Yet, IPv6 over 802.11 works relatively well.

For .11, we are talking about 2-3 orders of magnitude higher bit  
rates, 3 to 6 orders of magnitude more power (electrical), CPU speed,  
and memory per node, much more stable networks held together by  
relatively powerful access points mostly directly connected to even  
more stable Ethernet backbones etc.
To a laptop, an 802.11 network is pretty much an Ethernet, so it's no  
surprise that 4861 works well.

>> comment on this work rather than waiting until a Last Call.

I would love to have a Bar BOF/extended hallway meeting in Hiroshima  
about this.
The 6lowpan WG meeting is currently scheduled at Monday morning; we  
are likely to spend some time on 6lowpan-ND there.
If you think it's worth giving a summary presentation at 6man (Tuesday  
morning), that certainly can also be arranged.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 14 Oct 2009 18:11:37 +0200

Brian, Bob,

Needless to say, I completely agree with Carsten here. 

You might also want to talk to Samita who led the effort for using 4861
and is now a coauthor of the 6LoWPAN ND, and to Erik, of course.

Let me try to give you some additional background:

> ... RFC 2491 was written to capture those interfacing 
> functions needed to allow NDP and such to operate correctly.

RFC 2491 expects a MARS based service to enable a multicast emulation
for ND and present a common face to ND.

So we do something similar with a registrar of sorts, but a lot simpler
and more economical as it is integrated in ND.

>       Is it possible that standard IPv6 nodes could operate on a 
> 6lowpan network as well as a more traditional (e.g.,

Another question is whether that is desirable. There are assumptions
behind classical NDP as described in RFC 4861. The farther you go from
those assumption, the least NDP as its stands applies, and the more
costly the adaptation layer becomes. Classical NDP being optimized for
potentially large transitive networks with a high degree of trust and
few specific destination. It is based on assumptions like:

* reachability is Boolean, yes or no, whereas it is rather fuzzy in our
world. 

* CPU/NIC card time is cheap. Certainly not the case for us. Listening
costs as much battery as sending on most radios.

* links are transitive whereas the connectivity graph in our world is
not, but rather very dynamic and complex

* multicast and medium time are cheap, which is certainly not the case
for us. Yet, we have use case with 10K nodes in a single subnet. And a
node should never be awaken by a packet for which it is neither a router
or an end point.

* Multicast is easy. In NBMA, the air time of a multicast packets is
multiplied by the branches in the tree. When applied to radios,
multicast can become even more complex in that it can interfere with
itself as it gets propagated along the connectivity graph with such
effect as hidden terminal. The overall interference impacts
transmissions inside the graph for a lot longer than the transmission of
a packet.

* storing a packet during a reactive lookup is fine, which is certainly
wrong for a router that can only store one or 2 packets at the same
time. 

* The binding cache can be large enough and cheap to renew. Wrong again
for us, we have critically limited room and cannot afford the NS/NA
churn that results from a cache that's too small for the set of
neighbors. 

As you figure, in the rainbow of ways of doing ND, reactive discovery
using a global flooding and proactive discovery using a centralized
registry appear to be standing at the extremes. And our needs are a lot
better served by the other end.

> ethernet) one?  If so, this seems like a lot of complexity needed in 
> that device to determine the type of link it is operating on.

The 2 modes are not mutually exclusive. I'd say that 6LoWPAN-ND is
sufficient for a LoWPAN node, but that additional means such as RFC 3122
or RFC 4861 will provide other information and allow bypassing the
router when that's affordable.

Interestingly, the 6LoWPAN-ND method could be used in conjunction to
4861 on Ethernet as well, for the purpose of such operations as Source
Address Validation. There are things that the current work at SAVI
cannot do, for instance serving properly a multiply homed host that uses
an address from another interface. 

>> ...  Yet, IPv6 over 802.11 works relatively well.

Certainly not on flat 802.11 (aka adhoc mode).

RFC 4861 works on 802.11 infrastructure mode. Infra mode that is an
adaptation layer that that emulates Ethernet and does not exist in other
media that we serve- which include 802.11 adhoc mode, in particular Low
Power WI-FI though 802.15.4 dominates at this very moment. 

Interestingly, 6LoWPAN ND can very well be seen as an L3 generalization
of 802.11 infrastructure mode BSS (the edge router is a L3 access point
of sorts) and ESS (edge router proxy ND whereas APs proxy transparent
bridging), and coupled with RPL you can get a L3 generalization of
802.11S.

My conclusion:

Yes, we are definitely interested in bringing our NDP extension to a
larger audience because:

- a whole industry is waiting for us; that industry can hardly accept a
solution that would be constrained to a single type of interface
- we need a good story on how ND and (ROLL) RPL work together. That
story might be a lot different if this ND extension is adopted
- Classical NDP is reactive. It just makes sense to complement it with a
proactive option for cases where that applies better.
- The ND extension that we propose can actually cohabit and enable
interesting options on all sorts of media, though coming from the other
end of the rainbow, it is probably more adapted to NBMA than it is to
transit.

But we need you to consider the proposal in a very open minded way as
opposed to try to place 4861 there at all costs, that we already
determined that we could not afford. 

Cheers,

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carsten Bormann
>Sent: mercredi 14 octobre 2009 16:30
>To: Brian Haberman; [email-masked]
>Cc: 6lowpan
>constrained, see RFC 4919 and in particular
http://tools.ietf.org/html/draft-ietf-6lowpan-routing-
>requirements-04

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 14 Oct 2009 19:15:55 +0200

Hi Pascal, Brian,

A few comments below:

> ... RFC 2491 was written to capture those interfacing functions needed

> to allow NDP and such to operate correctly.

[Pascal] RFC 2491 expects a MARS based service to enable a multicast
emulation for ND and present a common face to ND.
So we do something similar with a registrar of sorts, but a lot simpler
and more economical as it is integrated in ND.

[Mathilde] This does not sound similar to me. In one case you emulate
multicast below ND; ND remains unchanged. In the other you redefine ND.

> 6lowpan network as well as a more traditional (e.g., ethernet) one? 

[Pascal] Another question is whether that is desirable. There are
assumptions behind classical NDP as described in RFC 4861. The farther
you go from those assumption, the least NDP as its stands applies, and
the more costly the adaptation layer becomes. Classical NDP being
optimized for potentially large transitive networks with a high degree
of trust and few specific destination. It is based on assumptions
like...

[Mathilde] What about a router with two interfaces, one Ethernet and one
802.15.4. With the current proposal this router will need two
implementation of ND, 4861 on the Ethernet interface and 6lowpan-ND on
the other. 
An important implication is that we need to modify the OS (where ND is
implemented) of exiting computers / routers / etc to allow them to use a
802.15.4 interface.

>> ...  Yet, IPv6 over 802.11 works relatively well.

[Pascal] Certainly not on flat 802.11 (aka adhoc mode)...

[Mathilde] So is there a strong push from 802.11 vendors to redefine ND?
I didn't hear anything on this list.

[Pascal] My conclusion:

[Mathilde] If a 'larger audience' is needed, I definitely think that
this work should not be done in 6lowpan as it is clearly focusing on
802.15.4 and I'm not sure the whole industry is aware of the effort. 

Best,
Mathilde

---

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 14 Oct 2009 18:38:31 +0100

Hello,

> implemented) of exiting computers / routers / etc to allow them to use a

Is there no reason a small shim can't be put in-between the existing
implementation and the 802.15.4 side?

By this I mean basically doing the proxy-ND we have talked about before.
Hence if a NS is supposed to be sent over the air, it can internally decide
if the device exists or not on the lowpan.

I haven't followed all the discussions of past - so I suspect this may have
already been addressed! But a quick description or link to this would be
greatly appreciated.

Warm Regards,

   -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mathilde Durvy (mdurvy)
Sent: October 14, 2009 6:16 PM
To: Pascal Thubert (pthubert); Carsten Bormann; Brian Haberman;
[email-masked]
Cc: 6lowpan; Samita Chakrabarti
Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND

Hi Pascal, Brian,

A few comments below:

....truncated for space reasons....

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Oct 2009 20:20:03 +0200

> implementation of ND, 4861 on the Ethernet interface and 6lowpan-ND on

As with any node that has interfaces into 4861-supported networks as  
well as into networks not supported by 4861.
(Actually, such a Ethernet-to-LoWPAN router will in addition also need  
to implement the edge router function of 6lowpan-ND, which intra- 
LoWPAN nodes don't need to do -- we are trying to simplify the latter,  
in preference to the [relatively!] powerful Ethernet devices.)

> implemented) of exiting computers / routers / etc to allow them to  

As has been mentioned a couple of times, 6lowpan-ND can be (and has  
been) implemented as an adaptation layer, satisfying any ND layer that  
cannot be mapped out of the OS architecture and keeping it ignorant of  
the actual nature of the link; since 6lowpan-ND only modifies/replaces  
a couple of 4861's messages, that's almost a bit like header  
compression.

I'll now stop repeating all this over and over, because it has been  
mentioned often enough on the mailing list.
I still don't understand why we had to go through seven iterations of  
the adopted WG draft before anyone noticed that, yes, we have a  
version of ND that has been optimized for 6lowpan and is therefore no  
longer the same as 4861.

Gruesse, Carsten

---

From: Geoff Mulligan <[email-masked]>
Date: Tue, 13 Oct 2009 16:40:31 -0600

> 4861, these nodes which are going to miss packets must have a way to defend

I'm not sure why they need to defend an address.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Oct 2009 22:55:01 +0200

> I'm not sure why they need to defend an address.

Well, the short answer is that it wouldn't be 4861 any more if they  
didn't.

But I'm getting ahead of myself -- the "does anybody really need DAD"  
thread is only scheduled for Friday :-)
Let's talk about NUD now (in the other thread).

Gruesse, Carsten

---

From: Brian Haberman <[email-masked]>
Date: Tue, 13 Oct 2009 16:29:05 -0400

Hi JP & 6lowpan WG,
      I have not done a thorough review of the draft yet, but I did have 
a brief read to try and understand the approach.  I am curious as to why 
this work is not progressing more along the lines of the IPv6-over-foo 
type documents that have been published in the past.  Is an 802.15.4 
network that much more of an onerous environment for the base IPv6 
protocols (modulo some modifications/extensions)?

      We had similar issues back in the 20th Century with other 
NBMA-type links.  RFC 2491 was written to capture those interfacing 
functions needed to allow NDP and such to operate correctly.

      Is it possible that standard IPv6 nodes could operate on a 6lowpan 
network as well as a more traditional (e.g., ethernet) one?  If so, this 
seems like a lot of complexity needed in that device to determine the 
type of link it is operating on.

      I agree that non-transitive links are an issue for more than just 
802.15.4 networks.  The description given could be applied to 802.11 as 
well.  Yet, IPv6 over 802.11 works relatively well.

      It appears that a cross-WG review would be a good idea at this 
point.  I would like to see some 6MAN contributors comment on this work 
rather than waiting until a Last Call.

Regards,
Brian

JP Vasseur wrote:
>> link layers used in lowpans. However, my two major points of concern are:

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Oct 2009 08:22:45 +0200

> Hi JP & 6lowpan WG,

Ah, the fun of postings stuck in the non-subscriber queue.

See my reply from yesterday 1430 UTC.

Gruesse, Carsten

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 15 Oct 2009 09:24:43 +0200

Hi Carsten,

Thanks for your reply.  A small additional comment, and then I guess we
can close this topic :-)

[Carsten] As has been mentioned a couple of times, 6lowpan-ND can be
(and has
been) implemented as an adaptation layer, satisfying any ND layer that
cannot be mapped out of the OS architecture and keeping it ignorant of
the actual nature of the link; since 6lowpan-ND only modifies/replaces a
couple of 4861's messages, that's almost a bit like header compression.

[Mathilde] I guess for me an adaptation layer should not intercept
messages or generate new messages. This is why I think the philosophy of
header compression and 6lowpan-ND is very different.

Best,
Mathilde

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Oct 2009 09:37:02 +0200

> header compression and 6lowpan-ND is very different.

I can assure you that ROHC implementations intercept and generate new  
messages all the time...

But yes, I was stretching it a little.
I still think the analogy leads to useful insights.

Gruesse, Carsten

---

From: Brian Haberman <[email-masked]>
Date: Fri, 16 Oct 2009 13:20:44 -0400

>> comment on this work rather than waiting until a Last Call.

Informally, the 6lowpan chairs can send a request to the 6man mailing 
list asking for input/review at any time.  If there is a 6lowpan Last 
Call in the near future, that announcement could be sent to the 6man 
mailing list with a request for input.

Regards,
Brian

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 18 Oct 2009 15:36:19 +0200

On Oct 16, 2009, at 19:20, Brian Haberman wrote:

> Informally, the 6lowpan chairs can send a request to the 6man  
> mailing list asking for input/review at any time.

Sure.  I believe the recent mailing list discussion will lead to a re- 
spin with some clarifications.
That version might be a good basis for such a review.

Is it at all possible to get a slot at 6man in Hiroshima to stir the  
pot?
(Unfortunately, that meeting is overlapping ROLL, which is dear to the  
hearts of 6lowpanners, but we will cope.)

Gruesse, Carsten