[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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
