Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-12

From: Zach Shelby <[email-masked]>
Date: Tue, 3 Aug 2010 00:53:16 +0300

http://www.ietf.org/id/draft-ietf-6lowpan-nd-12.txt

We have posted a new version of ND optimizations for LLNs. This closes all known tickets as per the WG meeting in Maastricht. In addition to fixing some nits and general editing, the substantive changes are:

      o Version field of ABRO moved after Length for 32-bit alignment of
      the reserved space (#90).

      o Several clarifications were made on router interaction,
      including a new section with router interaction examples (#91).

      o Temporary Neighbor Cache Entry created upon host sending NS+ARO,
      and SLLAO removed from multihop DAD NS/NA messages (#87).

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: August 3, 2010 12:46:30 AM GMT+03:00
> To: [email-masked]
> Cc: [email-masked],[email-masked]
> Subject: New Version Notification for draft-ietf-6lowpan-nd-12 
> 
> 
> A new version of I-D, draft-ietf-6lowpan-nd-12.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-ietf-6lowpan-nd
> Revision:	 12
> Title:		 Neighbor Discovery Optimization for Low-power and Lossy Networks
> Creation_date:	 2010-08-03
> WG ID:		 6lowpan
> Number_of_pages: 50
> 
> Abstract:
> The IETF 6LoWPAN working group defines IPv6 for low-power and lossy
> networks (LLNs) such as IEEE 802.15.4.  This and other similar link
> technologies have limited or no usage of multicast signaling due to
> energy conservation.  In addition, the wireless network may not
> strictly follow traditional concept of IP subnets and IP links.  IPv6
> Neighbor Discovery was not designed for non-transitive wireless
> links.  The traditional IPv6 link concept and heavy use of multicast
> make the protocol inefficient and sometimes impractical in a low
> power and lossy network.  This document describes simple
> optimizations to IPv6 Neighbor Discovery, addressing mechanisms and
> duplicate address detection for 6LoWPAN and similar networks.
> 
> 
> 
> The IETF Secretariat.
> 
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Aug 2010 12:05:32 -0700 (PDT)

Hi Zach,
  Prefix sharing assumption stated in Sec. 1.3 I think creates multi-link subnet 
issues described in RFC 4903 (not referenced in your ID) especially if 
route-over is used. Similar concerns were raised in IETF 78 session.

Of course if mesh-under is used then there is no problem but then there is 
probably not much case for the Roll protocol.

It seems that we have this dilemma of choosing between the two evils.

I suggest that we avoid this problem by assigning a unique prefix for each IPv6 
host and then freely use the roll protocol for route-over and use prefix sharing 
only if mesh-under is used. It is clear that you can not have it both ways.

Regards,

Behcet

----- Original Message ----
> From: Zach Shelby <[email-masked]>
> To: 6lowpan 6lowpan <[email-masked]>
> Sent: Mon, August 2, 2010 4:53:16 PM
> Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-12
> 
> We have posted a new  version of ND optimizations for LLNs. This closes all 
>known tickets as per the  WG meeting in Maastricht. In addition to fixing some 
>nits and general editing,  the substantive changes are:
> 
> > A new version of I-D, draft-ietf-6lowpan-nd-12.txt has been  successfully 
>submitted by Zach Shelby and posted to the IETF repository.
> > 
> _______________________________________________
> 6lowpan  mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 4 Aug 2010 22:56:14 +0300

Hi Behcet,

This is a known feature of a route-over LoWPAN, we have been discussing that already a lot the last two years, and have converged on the current model. This model actually is not a multi-link subnet as such. Instead we have a single non-transitive (radio) link, where exact-match routing is used to overcome the fact that not all interfaces can hear each other at all times. We are referencing the Autoconf addressing model which makes similar assumptions about radio links.

> route-over is used. Similar concerns were raised in IETF 78 session.

This was from a person in the audience not familiar with the 6LoWPAN WG if I remember right.

> only if mesh-under is used. It is clear that you can not have it both ways.

The suggestion you make below simply does not work with 6LoWPAN header compression, nor does it make sense with mobility. You may do that with a formal IPv6 network of course (see the Autoconf WG). 

Zach

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Aug 2010 14:13:04 -0700 (PDT)

> Hi Behcet,
> 
> This is a known feature of a route-over LoWPAN, we have been 
> discussing that already a lot the last two years, and have converged on 
> the  current model. This model actually is not a multi-link subnet as 
> such.

[behcet] I think it is multi-link subnet but a different type.

>  Instead  we have a single non-transitive (radio) link, where exact-match 
>routing is used 
>
>

[behcet] What do you mean by exact-match routing? Why does it make prefix 
sharing OK?

> to overcome the fact that not all interfaces can hear each other at all 
> times.  We are referencing the Autoconf addressing model which 
> makes similar assumptions  about radio links.

[behcet] I read that document. It says IPv6 address configured on this interface 
should be unique within the routing domain. This is also valid with non-shared 
prefixes.

> The suggestion you make below simply does not work with 6LoWPAN  > header 
>compression, nor does it make sense with mobility. 
>

[behcet] I guess you mean if different prefixes are used. Also your concept of 
mobility is different, you don't consider moving to a different network which is 
probably OK for 6LOWPAN nodes.

> You may do that with a  formal IPv6 network of course (see the Autoconf WG). 
> 

Yes.

Regards,

Behcet