Hi Pascal,
W.r.t. DHCP or not - I agree with you on the semantic difference
between the two, but that is not what I wanted to argue. My point is
that the added cost of having a whiteboard is not much different from
DHCP - it requires an entity somewhere to respond to requests and
maintain state about each node that it has responded to. 6LoWPAN ND
also requires a proxy mechanism for when the whiteboard is not on-
link. The whiteboard can also be a cause of failure - if a node cannot
communicate with the whiteboard, it cannot perform DAD, and cannot
properly join the network.
W.r.t. using the word "stateless", from RFC 4862 we have:
"The IPv6 stateless autoconfiguration mechanism requires no manual
configuration of hosts, minimal (if any) configuration of routers,
and no additional servers."
Also in RFC 4862, we have:
"The stateless mechanism allows a host to generate its own
addresses
using a combination of locally available information and
information
advertised by routers."
The first excerpt identifies the main point of SLAAC - no additional
servers. The second indicates how stateless addresses are formed and
is where I see Zach's argument coming from. In my view, the real
benefits of SLAAC are sorely missed now that we do require additional
servers (whiteboard). Even if a host could configure an address, it
can't do much with it until it receives a confirmation from the
whiteboard. In the traditional world, SLAAC is beneficial because DAD
conveniently doesn't require any servers either - not true in 6LoWPAN
ND.
We have also already stated that the whiteboard assigning short
addresses and future ideas for using SeND will blur the line even more
in that the node no longer builds addresses using information local to
it.
I still think we should drop "stateless" and avoid the confusion.
--
Jonathan Hui
On Jun 12, 2009, at 1:55 AM, Pascal Thubert (pthubert) wrote:
Hi Zach;
At the end of the day, we need to establish states in the network for
the IPv6 address in use.
In that regard we are stateful. And that is how I understand that the
DHCP world means it.
Yet we require minimal to no pre-configuration in the network.
In that we are stateless. And that is how I understand that 4862 means
it.
The core question is whether people will understand better what we are
doing if we qualify it as stateless or stateful based on their more or
less intuitive understanding of the words, or if we'll just create
more
embarrassment for ourselves.
Considering that the term stateful was deemed highly confusing and
removed from RFC 4862, I tend to think that in a fashion stateless is
also confusing and could be removed from our text. But I will not
fight
either way.
Pascal
-----Original Message-----
From: Zach Shelby [mailto:[email protected]]
Sent: vendredi 12 juin 2009 10:30
To: Pascal Thubert (pthubert)
Cc: Ralph Droms (rdroms); [email protected]
Subject: Re: [6lowpan] [Fwd: New Version Notificationfor
draft-ietf-6lowpan-nd-03]
Hi,
Pascal Thubert (pthubert) wrote:
Hi Jonathan:
On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote:
Looks so alike and still is so fundamentally different. Ralph
explained
that in SFO a lot better than I can ever do but that has to do
with
the
model below.
In DHCP, the server owns the address and lends it away. You have
to
get
back to that server to renew the binding. In whiteboard, the nodes
owns
the address and registers it where it wants, or anywhere
(anycast).
When we do SeND, that distinction might blur quite a bit but
still,
the
white board acts on behalf of the node so it does not hold any
master
state (like a pool with LRI etc...) after the node is gone.
Hi Pascal,
If Ralph could reiterate what he said at the WG meeting on the ML,
that would certainly help my understanding of the fundamental
difference between DHCP and whiteboard.
At least in my mental model, the whiteboard is authoritative in
what
nodes can use what address. The node MUST periodically renew the
binding with the whiteboard. The node cannot use that address when
the
binding expires without renewal because the whiteboard could then
allow another node to use that same address. Whether or not we view
the node as "owning" the address is a non-issue for me.
Functionally,
the whiteboard is authoritative and that's not unlike DHCP.
Seems my words failed to convey the message and I hope Ralph will
express that better.
The key in my mind is that the owner is the node, and the whiteboard
is
just an attorney.
Though he is the one who speaks during trial, the attorney can only
say
what his client agreed upon.
And the client might switch attorney at will.
With stateful DHCP, the server plays is like a chess player that
places
and controls its pawns at will.
So the model is reversed.
This is also my understanding.
Also, in various places in the ND draft, we say *stateless* address
autoconfiguration - when in fact this is not the case. The
whiteboard
maintains necessary state for all nodes in the network no matter
how
you spin it. If that state does not exist, is not maintained
properly,
or cannot be reached by the client node, DAD using the whiteboard
will
fail. At the very least, I think we should drop the word
"stateless"
everywhere in the draft.
I think you're very right, that's an excellent point.
I don't agree completely. The node is creating an address using
Stateless Address Autoconfiguration (RFC4862), we are not breaking
that.
So in Section 5.2, where we are forming addresses, this is used
correctly.
The only thing we are changing, is the mechanism to perform DAD.
I agree that the Whiteboard is not stateless, but it also does not
start
with any state, nor does it require configuration from an
administrator.
It is a blank slate..
Stateful in the DHCP acceptance is certainly closer to what we are
doing.
Pascal
--
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
