At the bottom of this email there is request for more feedback on this
topic.
I haven't checked the latest version of the draft. I have already
expressed the following about 6LoWPAN ND related to this discussion:
-I think it is not good the 6LoWPAN ND draft assumes it safe to convert
a MAC address to an IPv6 address. This effectively forbids the
manual assignment of addresses on nodes, and DHCP too.
-I think it is not good for 6LoWPAN ND to assign full /128 addresses
with the RA (i.e. an RA forces the receiver to configure the address
contained in that RA). DHCP does so already, why not using it.
-I think it is not good to have a single subnet span both the
egressinterface of ER _and_ the LoWPAN - these should be two different
subnets.
-I think the whiteboard concept should be clarified, or I should try to
better understand it.
Alex
Jonathan Hui a écrit :
Hi Zach,
On Jun 10, 2009, at 8:53 AM, Zach Shelby wrote:
The whiteboard can also be used for NUD across the whole LoWPAN, you
are correct that DAD is the main purpose. The whiteboard also enables
extended LoWPAN topologies (which is where the idea originally comes
from, the BbR draft from Pascal). Furthermore the whiteboard gives an
ER some valuable information about which IPv6 addresses are in the
LoWPAN for filtering, management etc.
I don't see the whiteboard as a good substitute for NUD - the whiteboard
knows it has heard from a node, but doesn't know that it can actually
communicate with that node. Using the whiteboard for NUD also assumes
that you mesh through the whiteboard. Note that using the whiteboard for
NUD is only really useful in mesh-under networks. For route over, NUD
using the whiteboard doesn't make any sense to me.
ND proxy is the real mechanism that enables extended LoWPAN topologies.
But again, a number of mechanisms in the BbR draft were intended for
mesh-under networks. In a route-over network, the whiteboard isn't
necessary to maintain routes.
Right. Just brought up the implementation aspect as an example, I
remember Richard asked about that.
There is no state in a whiteboard that a network administrator would
be involved with. It is unlike DHCP, but more like a MIPv6 binding.
There are no addresses being doled out. Nodes register a binding with
the ER. The address generation function is stateless - requiring no
administration. A node could (and may very well) generate its own
address and register it with the same result (possibly needing more
NR/NC exchanges).
I guess we have different view points on this. In my mind, the
whiteboard is very similar to DHCP. The whiteboard is telling a node
whether or not it is OK to use an address, that is logically the same as
assigning the node that address. The whiteboard may assign a 16-bit
short address, for use with an IP address - that is exactly the same as
assigning the node that address.
Agreed that we would not want a new component in the network, ERs
already exist, and they will already implement ND on their 6lowpan
interfaces. You would not install a "Whiteboard Server" somewhere in
your network, it comes built-into the 6lowpan interface driver on an
ER for example. Humans would not be in the loop here.
The vast majority of DHCP servers in use today don't require any real
network administration either. How many consumers really change the DHCP
settings on their $50 linksys router? But when something does go wrong
(e.g. dhcp server does not properly hand out addresses), those consumers
are left to wonder. The whiteboard (DHCP server) is another component in
the network, whether or not it is co-located on the ER (linksys router).
So apart from a generic discussion about whiteboards - how about we
concentrate on technical details. As a WG we really need to check that
all the fine details here work - and if not suggest a way to
fix/improve them. We would like to submit -04 before the Stockholm
cutoff.
Agreed. We should get as much feedback as we can.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
