Hi Alex,
Alexandru Petrescu wrote:
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:
OK, please read and comment.
-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.
This is not an assumption made by ND! This is how 6LoWPAN works. This
also does not forbid MAC address assignment by any means, MAC addresses,
both short and long can be configured to the radio chip almost universally.
We are just writing it down here to remind the reader why address
resolution is not necessary. In the next version we can point out that
this is a 6LoWPAN basic assumption, not something ND is forcing.
-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.
6LoWPAN ND is not doing that. RAs advertise prefix context, which is
shared state for compression using draft-6lowpan-hc.
-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.
This is only in an Extended LoWPAN topology - which is optional. If you
don't want to do ND proxy, then just use Simple LoWPANs which use the
model you like better.
-I think the whiteboard concept should be clarified, or I should try to
better understand it.
Yep, we have some good ideas on how to do that for nd-04, please read
and comment specifically if it is still unclear in the text in nd-03.
There is now a whole subsection on whiteboard in Section 7.
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
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
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.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
