Subject: Re: [6lowpan] 6LoWPAN-ND - Use of node registration should be optional

From: Erik Nordmark <[email-masked]>
Date: Mon, 01 Mar 2010 00:24:10 -0800

[Sorry for the delayed response]

On 02/15/10 02:14 AM, Zach Shelby wrote:

>> I agree that a registration is required for hosts so that the
>> routing protocol on the routers know which hosts are attached.
>
> The registration is also needed to bootstrap new routers to a LoWPAN.
> After that we can consider their bindings refreshed with e.g. routing
> signaling.

I don't quite see how this is required to bootstrap a routing protocol.
The routers need some mechanism (such as multicast/broadcast) to
initially find out that they are only one hop apart. Once that has been
done they can communicate however the routing protocol wants to communicate.

>>
>> But I don't see any logic in -08 which ensures that an IPv6 address
>> based on the short addresses is unique across the lowpan. The NR/NC
>> is local. Thus with this approach it isn't possible to support
>> short addresses.
>>
>> Perhaps we need a separate mechanism to allocate and/or ensure
>> uniqueness of short addresses?
>
> Correct, this is the aim of the split in a way. The draft currently
> says that address allocation and/or duplicate address detection are
> to be performed by the router after receiving the NR message when
> appropriate.  But those mechanisms are not defined in this draft.

But I don't see how NR/NC helps with duplicate detection at all with 
this approach. (They did help when the NR was relayed to the edge 
router, but with that no longer the case we don't need the complexity of 
a NC AFAICT.)

> Address allocation could be performed using DHCPv6. Another
> alternative will be the Extended LoWPAN draft (to be written), which
> would extend the registration to an Edge Router.

I guess I don't know what that Extended draft would look like. But 
thinking about this it might be that a routing protocol could know all 
the IP addresses that are present in a lowpan, and then the edge router 
could just use this information when doing the extension across a 
backbone network.

It might be that we want to push for such an approach, because it means 
that the hosts and routers inside the 6lowpan do not need to know that 
there is an extension across a backbone.

> The thing I found hard writing the text, was how to define the
> situations when duplicate detection SHOULD or MUST be performed... so
> plenty of comments needed on Section 5.3...

My take is that what you should say is that there is no support for DAD, 
hence the protocol as specified only support EUI-64 derived IPv6 
address. In particular, it doesn't support short addresses.

>> While there isn't a need for any ER as used in earlier versions, we
>> do need some notion of the prefix originating router(s). By this I
>> mean that one or more routers will originate the prefix or prefixes
>> used in the lowpan. In the case of a lowpan attached to a wire it
>> seems natural that the router(s) that attach to the wire would do
>> this. That is the same location as what we previously called edge
>> routers.
>
> Right, I think we should actually keep the ER term for the purpose of
> prefix origination in this draft. So the ER concept now is just a
> router attached to the wire, from which prefixes originate. How does
> that sound?

If the "edge" isn't the important thing, then how about Prefix 
Authoritative Router?

    Erik