Subject: [6lowpan] RFC4861 and 6lowpan ND

From: Geoff Mulligan <[email-masked]>
Date: Thu, 17 Sep 2009 00:22:19 -0600

Has anyone determined if a standard RFC4861 end device would be able to
work with a 6lowpan ND edge router, would it be able to get the
necessary commissioning data (prefix, default router, ...)

And the reverse, could a 6lowpan ND end device get commissioned via a
standard RFC4861 ND router?

	geoff

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Sep 2009 07:54:51 +0200

On Sep 17, 2009, at 08:22, Geoff Mulligan wrote:

> work with a 6lowpan ND edge router,

You mean, on the inside?

> would it be able to get the

It won't be able to decode the 6LoWPAN Prefix Information Option,  
which replaces 4861's.
Even if it were, it wouldn't get answers on its NS (no 6LoWPAN-wide  
multicasts!).
Then, since it didn't NR, it probably wouldn't get packets from outside.

> standard RFC4861 ND router?

That depends on whether the implementer spent precious code space to  
be able to parse 4861 prefix information option.
Again, the node will then get stuck on the NR.

Why do you want to mix?

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Fri, 18 Sep 2009 09:53:21 +0300

> standard RFC4861 ND router?

That of course isn't possible with nd-05 (as-is). Making it possible 
would require adding some complexity to LoWPAN nodes... is there a good 
reason for doing that?

Questions:

- Is there a need for an IPv6 node that only implements RFC4861 to 
participate (have a network interface) in a LoWPAN?
- If there is such a need, how should it participate (as a host?, as a 
router?, single-hop only?). Such a participant wouldn't work with 
route-over LoWPANs nor sleeping nodes of course.
- What is the use-case and scenario for such participation?

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: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 18 Sep 2009 13:26:57 +0200

Hi Geoff,
 
As far as I understand:
1 if a standard 4861 node (node A here) joins a lowpan with lowpan ND.
Node B is a node using 6lowpan ND
- DAD will fail (nobody answers to NS)
- Address resolution will fail (same)
- NUD fails (same)
- if the router does not also send standard Prefix Information Option in
Ras (but only 6lowpan information option),
-- prefix discovery fails (incl on-link prefixes)
-- autoconfiguration fails

Regarding node B: 
- If node A does not respect the binding between its L3 and L2 address,
(the assumption that the IPv6 suffix is based on the MAC, for instance
if node A uses DHCP or CGA), node B will not be able to contact node A
- the white board is not authoritative anymore (A does not register),
- hence DAD fails for node B.

2  Now for a node using 6lowpan ND only in a pure 4861 network:
- DAD will fail (the node does not send NS)
- Address resolution will fail (same)
- NUD fails (same)
- prefix discovery, autoconfiguration fails (no 6lowpan Information
Option in RA)
- This node will just not work at all, but will not disturb other nodes.

This might be a real issue.

Best,
Julien 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Geoff Mulligan
> Sent: jeudi 17 septembre 2009 08:22
> To: 6lowpan
> Subject: [6lowpan] RFC4861 and 6lowpan ND
> 
> Has anyone determined if a standard RFC4861 end device would 
> be able to work with a 6lowpan ND edge router, would it be 
> able to get the necessary commissioning data (prefix, default 
> router, ...)
> 
> And the reverse, could a 6lowpan ND end device get 
> commissioned via a standard RFC4861 ND router?
> 
> 	geoff
> 
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Zach Shelby <[email-masked]>
Date: Fri, 18 Sep 2009 14:33:40 +0300

Guys,

Yep, 6lowpan-nd and RFC4861 are not interoperable on the same link as 
6lowpan-nd-05 is written. That has not been a requirement nor an 
assumption so far from the WG. We assume that all LoWPAN nodes run 
6LoWPAN-ND on their LoWPAN interfaces.

We need to answer the questions I posed in an e-mail earlier. Is this 
something that is needed and why? How should it work? And what are the 
real use cases that are useful?

Thanks,
Zach

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 19 Sep 2009 11:57:03 +0200

Hi Geoff:

RFC 4861 is not designed for non transitive links. So applying it on a
LoWPAN is non-standard. 
When networks with new characteristics come up, there's a need for an
IPv6-over-Foo work; Thus the work at 6LoWPAN.
Whatever this WG comes up with, that will be how IPv6 operates on a
LoWPAN. The rest is proprietary experimentation.

At this point, we do not have a requirement for interoperability for
RFC4861 nodes.

If you want to add that requirement and thus impact the spec, then you
need to justify your case:
 
- Can you build a workable solution with RFC 4861? 
- What are the limits/trade offs?
- What use cases do that satisfy?
- Does such a use case really need to Interop with standard 6LoWPAN on a
same link?

Note1: there's no IPv6-over-Foo for 802.11 infra mode because the infra
mode emulates a transit link like Ethernet at L2, and thus RFC 4861
applies. OTOH, 6LoWPAN ND and ROLL will be a perfect match for 802.11
adhoc mode. But then there's no requirement to Interop that with adhoc
mode and it is wise not to collocate adhoc and infra.

Note2: As soon as you go L3, you can interconnect nodes on alien link
layers. That's what IP is all about. Would your use case be satisfied if
the nodes connect via a router?

Pascal
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Geoff Mulligan