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

From: Zach Shelby <[email-masked]>
Date: Mon, 09 Mar 2009 17:48:36 +0200

I have submitted a new version of ND for 6LoWPAN:

http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-02.txt

Changes from -01 include:

- Fixed 16 != 0xff bug (ticket closed)
- Specified use of ULAs in ad-hoc LoWPAN section 9 (ticket closed)
- Terminology cleanup based on Alex's comments
- General editing improvements

Known open issues:

- Specify Trickle in an appendix or just reference it?
- RA information dissemination consistency in more detail in Section 7

I would like to request a presentation slot of 45 minutes from the 
chairs to present the draft in SFO.

- Zach

-------- Original Message --------
Subject: New Version Notification for draft-ietf-6lowpan-nd-02
Date: Mon,  9 Mar 2009 08:36:26 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: 
[email-masked],[email-masked],[email-masked],[email-masked]

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

Filename:	 draft-ietf-6lowpan-nd
Revision:	 02
Title:		 Neighbor Discovery for 6LoWPAN
Creation_date:	 2009-03-09
WG ID:		 6lowpan
Number_of_pages: 46

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 extended multihop
topologies.  However, the use of standard IPv6 Neighbor Discovery
with 6LoWPAN has several problems.  Standard Neighbor Discovery was
not designed for wireless links, and the standard IPv6 link concept
and heavy use of multicast makes it inefficient.  This document
spefies a new ND mechanism allowing for efficient Duplicate Address
Detection over entire LoWPANs.  In addition it specifies context
dissemination for use with router advertisements, claim and defend
addressing, and the support of extended LoWPANs over backbone links.

The IETF Secretariat.

-- 
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: Alexandru Petrescu <[email-masked]>
Date: Mon, 09 Mar 2009 18:06:45 +0100

Hi Zach thank you for the 02 version, I hope I'm reviewing the right one.

Here are some comments.

Generally I must say that I do understand the overall goal, and I fully 
agree with making the LoWPAN a single subnet, with a link-local scope. 
I also agree with many parts of the document, individually.

However, I have difficulty grasping the overall document (and I ack this 
may be due to my new familiarity with the area.)

I'm writing these remarks not with the goal of correcting them, because 
I think it may be too complex to make it coherent.  I'd rather imagine a 
more efficient approach would be to select some parts of the draft and 
make it much shorter.

For example, why describing in detail the mesh-under and route-over 
models?  I understand this draft deals with only one, right?

Also example: is HC a mandatory feature?  If not, then maybe just write 
first the ND-over-802154 document which doesn't use on HC.

>       Code:  0 indicates a message sent directly from the orginating
>          host. 1 indicates that the message has been relayed by a
>          router.
> 
>       Checksum:  The ICMP checksum.

It appears the Code may be changed when relayed - will the checksum 
change too, how?

"RR" - potential clash with many terms such as Return Routability tests 
(rfc3775), "Resource Records" of DNS, Router Renumbering "RR" headers 
rfc2894...

"ER" appears before being clear it's "Edge Router".

Sometimes text may have been written in a hurry ("existing applications 
do not exist".)

"6LOWPAN_ER anycast address" - is it a new anycast ID?  I like the idea 
anyways.

> In a LoWPAN, setting the hop-limit to 1 limits a packet to the link,

I agree.  But then I can't understand other places which say 'multihop'. 
  If all nodes are neighbors then there's no multihop.  Or is 'multihop' 
a 'link-layer multihop' and not an 'IP multi-hop'?

>    LoWPAN Subnet
> 
>       A subnet including a LoWPAN or an Extended LoWPAN, together with
>       the backbone link with the same subnet prefix and prefix length.

I disagree with this picture.  This effectively makes the ER to be a 
bridge, not a Router ("Edge Router").

I believe it is possible and better to have the LoWPAN have a prefix 
like 2001:db8::/64 and the 'backbone' network to have prefix different 
at the fourth leftmost bit (different from 2001:db8::/64) - completely 
different.

> If a valid prefix is available from an RA ('A' flag is set), then a 
> global unicast address is derived using SAA.

Is SAA SLAAC?  I guess so, just it could be mentioned.

>   This specification includes a method for requesting a unique address
>    from the edge router by setting the 'A' flag in an Address Option
>    during registration.

It's not clear while reading whether this unique address is an IP 
address or a 16bit short link-layer address.  At some point I'm tempted 
to believe it's an IPv6 128bit address, because it says it does DAD on 
it, but at the same time DAD is done on IP addresses for link-layer 
addresses.

It would be good to clarify whether this unique address assigned by ER 
is an IPv6 address? or a 16bit short address out of which the node forms 
a 128bit address using the rules in rfc4944.  If the former then DHCPv6 
applies better.  If the latter then this shouldn't be done with ICMPv6 
messages (as the draft proposes), but with link-layer messages (like 
LCP, or similar).

 > 6.2 Registration process
[...]
 > The source address [of RR] is the link local address of the node.

And is it the unspecified IP address when the link-local address hasn't 
yet been decided? (A-bit 1 and 0 length).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 10 Mar 2009 11:10:13 +0100

Following up on my own comment...

"RR" could stand for too many things, among others the Requesting Router 
of DHCPv6 Prefix Delegation, which I find pertinent in this space.

Alexandru Petrescu a écrit :
[...]

Alex

---

From: Zach Shelby <[email-masked]>
Date: Tue, 10 Mar 2009 12:18:15 +0200

Hi,

Easy to fix, do you have suggestions for a better abbreviation?

Router Registration (RReg) and Router Confirmation (RCon) for example?

- Zach

Alexandru Petrescu wrote:
>> "RR" - potential clash with many terms such as Return Routability 
>> tests (rfc3775), "Resource Records" of DNS, Router Renumbering "RR" 
>> headers rfc2894...
> 
> Alex
> 
> 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 10 Mar 2009 11:23:23 +0100

> Router Registration (RReg) and Router Confirmation (RCon) for example?

RReg could fly maybe.  Hmm... RegReq of MIP4 approaches it too.

Registration Message?  Capitalized, and abbreviated as RM.

(Router Confirmation doesn't sound great either, because it's more
  of a Confirmation of the Request, not of the Router).

Alex

>> "RR" could stand for too many things, among others the Requesting 
>> Router of DHCPv6 Prefix Delegation, which I find pertinent in this space.
>>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 10 Mar 2009 16:33:00 +0200

Hi,

OK, I suggest that the authors and WG brain-storms this in SFO and then 
we'll come up with a solution for -03.

Thanks for the ideas, at least for me Registration Message (RM) and 
Registration Conformation (RC) could work.

- Zach

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

---

From: Zach Shelby <[email-masked]>
Date: Wed, 11 Mar 2009 18:31:47 +0200

Hi Alex,

Thanks again for the comments, below are main responses. The authors 
will work on these in SFO and integrate all we can in -03.

Alexandru Petrescu wrote:
> agree with making the LoWPAN a single subnet, with a link-local scope. I 
> also agree with many parts of the document, individually.
> 

I agree some sections could be shorter. Right now I only see that the 
LoWPAN ER Operations section could be compressed. See below regarding 
the intro.

> models?  I understand this draft deals with only one, right?

ND for 6LoWPAN definitely supports both mesh under and route over! This 
is the reason why both are covered, and why we explain the difference. 
In practice the only difference is that there are no LoWPAN Routers. 
Host and Edge Router operations are the same.

As the WG does not have an architecture document, and things have 
changed quite much since RFC4944, we need to cover quite a lot of 
architecture and terminology here. If there would be a separate 
architecture document, then those things could be removed from this draft.

We'll try to make it more concise and understandable. I agree it needs 
to be easy to grasp to 6lowpan newcomers.

> first the ND-over-802154 document which doesn't use on HC.

This draft works with both RFC4944 and draft-ietf-6lowpan-hc. I don't 
see the point of ND without IPv6.

> It appears the Code may be changed when relayed - will the checksum 

Yes, good point. This will be corrected.

> "6LOWPAN_ER anycast address" - is it a new anycast ID?  I like the idea 

Yes it is, see the IANA consideration sections, we are requesting a new 
anycast for this.

> a 'link-layer multihop' and not an 'IP multi-hop'?

We explicitly support both mesh under and route over! In route over 
LoWPANs we do have IP multihop and the LoWPAN is made up of a set of 
NBMA links.

> bridge, not a Router ("Edge Router").

This uses a similar model to Proxy ND, so nothing new. It is not a 
bridge, and does IP routing.

> at the fourth leftmost bit (different from 2001:db8::/64) - completely 

In the LoWPAN model it is like this. Extended LoWPANs share the same 
prefix with their backbone link.

> Is SAA SLAAC?  I guess so, just it could be mentioned.

Yes.

> it, but at the same time DAD is done on IP addresses for link-layer 

It is a unique IPv6 address. Because of the IID to link-layer address 
direct mapping in 6lowpan, in reality it means that it is both. As the 
IID is used as a MAC address, it must be unique throughout the LoWPAN. 
By performing DAD on the IPv6 address, and the prefix is the same 
throughout the LoWPAN, we in fact are checking that the IID is unique.

> messages (as the draft proposes), but with link-layer messages (like 

It is an IPv6 address, but it is not assigned, and has no state. It ties 
in very closely with DAD and SLAAC. We see this to be a very suitable ND 
operation, which of course makes use of ICMPv6. As I mentioned earlier, 
this generation could easily be done by the node itself at the expense 
of more packet exchanges = energy.

> yet been decided? (A-bit 1 and 0 length).

The draft defines that nodes perform SLAAC and use the addresses as 
optimistic during the registration phase, so OK. All nodes do have a 
link-layer address by default - it is typically a 64-bit EUI-64. The 
reason why some networks MAY also assign short addresses is a huge 
savings in header sizes...

Zach

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Mar 2009 01:13:52 +0100

For this RR term...

This is what happens when people try to integrate things.  For example 
say my 6lowpan node also runs MIP6 and does RR, is this RR or RR?

This is conversational stuff.  Specificational stuff could do anything else.

Alex

---

From: Zach Shelby <[email-masked]>
Date: Tue, 24 Mar 2009 02:16:51 +0200

Hi,

> say my 6lowpan node also runs MIP6 and does RR, is this RR or RR?

Unlikely that a 6lowpan node would do MIPv6, however an ER very well 
might so I see your point.

Registration Message (RM) could very well be a solution as we discussed 
below. Other opinions ideas on this?

- Zach

>> OK, I suggest that the authors and WG brain-storms this in SFO and 
>> then we'll come up with a solution for -03.
>>
>>>>>> tests (rfc3775), "Resource Records" of DNS, Router Renumbering 
>>>>>> "RR" headers rfc2894...
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Mar 2009 01:28:35 +0100

> might so I see your point.

I heard it doing TCP... which is a heavier implementation.

Alex

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Wed, 25 Mar 2009 08:59:53 +0900

Zach,

RM may be confused with Routing Message.
It's short and good, but I think RReg or RegMsg is more clear in
delivering the meaning.
It's just my quick thought.

-eunah

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Mar 2009 17:30:57 -0700

> is this RR or RR

Receive Ready?
Route Request?
Resource Record?
Receiver Report?

It's little use to avoid *other protocols'* two-letter abbrevs.
I'd stick with RR.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Wed, 25 Mar 2009 02:54:41 +0200

Hi,

We had a meeting today about this with all the authors. Based on the 
feedback from the wg meeting, we will stick with Router Registration 
(RR) as it is in -02. If we later start to form a consensus that this is 
a problem, then let's take a look at it again after -03.

- Zach

Carsten Bormann wrote:
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

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