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

From: Zach Shelby <[email-masked]>
Date: Tue, 22 Sep 2009 00:21:54 +0300

A new version of 6lowpan-nd is now available. I fixed a few bugs that 
Carsten found and improved the terminology with Joakim's feedback. Still 
shooting at nd-07 before the Hiroshima cutoff, so keep the comments coming.

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

    Changes from -05 to -06:

       o Fixed the Prf codes (#52).

       o Corrected the OIIO TID field to 8-bits.  Changed the Nonce/OII
       order in both the OIIO and the NR/NC. (#53)

       o Corrected an error in Table 1 (#54).

       o Fixed asymmetric and a misplaced transient in the 6lowpan
       terminology section.

       o Added Updates RFC4861 to header

Zach

-------- Original Message --------
Subject: New Version Notification for draft-ietf-6lowpan-nd-06
Date: Mon, 21 Sep 2009 14:15:52 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: 
[email-masked],[email-masked],[email-masked],[email-masked],[email-masked]

A new version of I-D, draft-ietf-6lowpan-nd-06.txt has been successfuly 
submitted by Zach Shelby and posted to the IETF repository.

Filename:	 draft-ietf-6lowpan-nd
Revision:	 06
Title:		 6LoWPAN Neighbor Discovery
Creation_date:	 2009-09-22
WG ID:		 6lowpan
Number_of_pages: 61

Abstract:
This document specifies Neighbor Discovery optimized for 6LoWPAN.
The 6LoWPAN format allows IPv6 to be used over energy and bandwidth
constrained wireless networks often making use of multihop
topologies.  However, the use of standard IPv6 Neighbor Discovery
with 6LoWPAN has several problems.  Standard Neighbor Discovery was
not designed for non-transitive wireless links, and the standard IPv6
link concept and heavy use of multicast makes it unpractical.  This
document specifies a new ND mechanism allowing for the efficient
detection of duplicate addresses over entire LoWPANs, which also
optimizes other ND operations.  In addition, context dissemination,
claim and defend address generation, and the support of Extended
LoWPANs over Backbone Links are specified.

The IETF Secretariat.

-- 
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: Zach Shelby <[email-masked]>
Date: Tue, 22 Sep 2009 09:55:59 +0300

>       o Added Updates RFC4861 to header

NOTE: This should of course be "Updates RFC4944". Will be fixed in nd-07.

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Sep 2009 09:09:07 +0200

> NOTE: This should of course be "Updates RFC4944". Will be fixed in  

This was somewhat terse; let me supply some detail here.

RFC 4861 is the standard ND protocol for IPv6.  We are not changing  
that.

In its section 1, RFC 4861 explains its domain of applicability.
In particular, it says:

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

So 4861 essentially says that the IP-over-X protocol has to say when  
4861 does not apply unchanged.
In other words, we have to update 4944 for 6LoWPAN-ND to take effect.

This is why 6LoWPAN-ND updates 4944.

ND-07 could add some language to this effect.

It could also explain that 6LoWPAN-ND is only fulfilling part of this  
toned down "expectation" from RFC 4861:

    The services described in this document [i.e., RFC4861] that are  
not directly
    dependent on multicast, such as Redirects, Next-hop determination,
    Neighbor Unreachability Detection, etc., are expected to be provided
    as specified in this document.

The reasons for deviation from this expectation are good, but it would  
help to make explicit that the expectation is not met here.

Gruesse, Carsten

---

From: Dominik Kaspar <[email-masked]>
Date: Wed, 30 Sep 2009 16:07:22 +0800

Hi Zach,

The ND documents states this definition:

LoWPAN Router
      A LoWPAN node that forwards datagrams between arbitrary source-
      destination pairs using a single 6LoWPAN interface performing IP
      routing on that interface.

Is it important to emphasize the use of "a single interface"? I'm
curious why this was specified here (or why it was not added to the
analogous definition of a LoWPAN Mesh Node).

Are there LoWPAN nodes with more than one interface? If yes, can it be
ruled out that they are routers? If no, shouldn't the number of
interfaces be left open?

Dominik

On Tue, Sep 22, 2009 at 5:21 AM, Zach Shelby <[email-masked]> wrote:
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>