[Autoconf] Comments on adhoc-addr-model-00

[Zach Shelby <[e-mail]>]

Hi,

Over in the 6lowpan WG we are defining a technique for optimizing the host-router (node-router) interface, called 6lowpan-nd. Working on this problem for a couple years, and starting with RFC4861 terminology, it turns out that we came to a very similar conclusion to the autoconf WG. However, in 6lowpan we are routing protocol agnostic and we deal with hosts and routers.

The link technologies we use in 6lowpan exhibit the characteristics defined (very nicely!) in draft-baccelli-multi-hop-wireless-communications-03. Although we don't always have multi-hop, even then many of the same characteristics occur.

The current version of ietf-6lowpan-nd-07 goes to all the trouble of defining mostly the same things you have (with much more text...). In Hiroshima we got a kick (thanks Dave!) to explore the use of draft-ietf-autoconf-adhoc-addr-model to simplify our own document and to unite the models across WGs. 

Here are my comments/thoughts on the addr-model-00 document from the 6lowpan perspective:

1. Make the document MANET agnostic. This can just as well be referenced by ROLL and 6LoWPAN work e.g. I only find MANET referenced in the intro (can be extended with other examples) and in the last paragraph of 6.2. Both are easily fixed.

2. I like the "link of undetermined properties"... however you might want to point to a document like draft-baccelli-multi-hop-wireless-communications to point out why links end up like that. RFC4861 also explains that a link might be non-transitive, so that could also be referenced. 

3. You have two open issues in Appendix A. To me both of these are OK already. The link model is fine (see 2). If globally unique addresses are needed, leave that to some other mechanism. This is what 6lowpan-nd does for a 6lowpan network.

4. In 6lowpan we would use the "when more specific assumptions can be made about connectivity" clause, as we always assign a single (global or ULA) prefix across the whole 6lowpan network. So the "MAY be configured with the same prefix" in Section 4 would be applied. In 6lowpan-nd we are able to make an assumption about connectivity between node-router pairs thanks to our mechanism defined. So please do keep this clause, it is very useful ;-)

5. We consider link-local addresses in the same way, this is OK.

6.  The second bullet point of Section 6.2 needs some expansion not to be misunderstood. In addition to the existing sentence, also add text like: ", unless an assumption can be made about connectivity in which case the prefix may be /64." The point being that if you can assume connectivity with a router (who somehow advertises a prefix), you may be able to autoconfigure an address using a shared prefix. This is what we do in 6lowpan.

So in my opinion, with the very small changes above (1. and 6.), this document would be very useful for our work. 

Thanks,
Zach 

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]

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.