Re: [Autoconf] Updated ad hoc addressing model document

["Teco Boot" <[e-mail]>]

Hi Zach,

>> That said, I am not sure I understand what the drawbacks you identify
>are. The document takes the "most conservative" approach, i.e. a network
>in which interfaces are configured in accordance to this, should allow
>any operation. The document, as I read it, uses "should", which does not
>prohibit alternatives (with the usual caveat concerning a "should").
>>
>> I believe that if you have no "MANET protocol", but still want L3
>communication between identified interfaces (IP addresses), then you
>would want a mechanism/protocol assigning these addresses? For the
>reasons outlined in that document, those addresses should (to allow any
>operation / any protocol to operate) satisfy the suggested rules in the
>document. If you do deviate from the "should", the usual caveats for a
>"should" apply -- and it might be OK for your deployment?
>
>I agree with this interpretation. The autoconf addressing model doesn't
>prevent you from applying another mechanism in addition to the (really
>minimal) base it provides. At least this is what we are doing in
>6lowpan. The autoconf model provides a way to model these "links with
>undetermined properties" in a pretty clean way (best I have seen so
>far... it is a mind-boggling problem). On top of that we are defining a
>mechanism to bootstrap nodes, configure addresses etc. which works
>without a routing protocol, or with one (e.g. RPL or MANET). This
>doesn't directly apply to your case, just an example.
>
>So to really make such a network work you have options like:
>
>autoconf + manet (all nodes must be routers)
>autoconf + something (no routing)
>autoconf + something + manet (maybe to also support hosts?)
>autoconf + 6lowpan-nd + rpl (typical 6lowpan setup right now)
>
>I guess autoconf as a WG will go on to define "something", or at least
>identify "something(s)" at some point? At least it would be useful to
>help people really apply this model in practice.
 
The first, "autoconf + manet" is not complete. We need L2 address 
resolving. To me, it is obvious to use ND (to stay on IPv6).
This makes the list like this:
autoconf + ND + manet (all nodes must be routers)
                      (maybe to also support hosts?)
autoconf + ND         (no routing)
autoconf + 6lowpan-nd + rpl (typical 6lowpan setup right now)

rpl is member of MANET protocol family, 6lowpan-nd is ND extension.
So the list is:
autoconf + ND* + manet* (all nodes must be routers)
                        (maybe to also support hosts?)
autoconf + ND*          (no routing)

My BRDP autoconf proposal runs on ND. Then, we have:
ND* + manet* (all nodes must be routers)
             (maybe to also support hosts?)
ND*          (no routing)

BRDP is easy to integrate in rpl. I am open for other ideas.
Good to know there are MANET protocols that support attached "satellite"
hosts.
 

Regards, Teco