On 30-mei-2005, at 17:16, Christian Schild (JOIN Project Team) wrote:
It would be really nice and handy to initiate either stateless or
stateful DHCPv6 with the same message.
I don't see a use case for this.
Assume you have a stateless server available on a link and M/O bits
are missing or misconfigured.
Ah, ok, the problem is becoming clear to me.
You see, I've spent the last 10 years of my life configuring routers.
Routers do what I want them to do. Period. But obviously, if you live
in an environment where you control the servers, but not the routers,
a situation where the router _don't_ do what you want them to may not
be unthinkable, or even academic. It's all a matter of perspective.
If there is a client that wants to do stateful DHCPv6 it will at first
send a Solicit message. The stateless server has no idea about that
message type and will not reply. Thus the client has to wait and needs
a timeout before it will send out an Information Request to obtain
other
data.
Very true, and not a great situation. However, I don't think reducing
functionality elsewhere is the answer.
If now the server would be able to understand the Solicit Message it
could answer immediately (even with the address missing) and the
client does not have to wait.
Yes, a solution could be running a server that isn't strictly RFC
3736-only.
My suggestion is just to substitute the Information Request with a
Solicit Request (probably including a Rapid Commit and Option Request
option) in RFC3736. This will make it more compatible with RFC3513 and
both, the stateful and the stateless client, will get an answer
immediately, regardless what kind of server is available.
If the dhc working group decides that the current stateless DHCPv6
needs improvement, I think you guys can figure that out on your own.
However, speaking as someone who configures those pesky routers, I
really want to be able to keep clients from initiating stateful
DHCPv6, even if the server would only reply with stateless
information anyway. It's a matter of predictability and debugging.
(And some things that may or may not matter depending on what
direction things take in the future.)
These are perfectly well-behaved bits, they don't bite or soil the
carpet. :-)
Actually, as an administrator, they might be a pain.
As stated before, RA and DHCPv6 are different protocols. So when I
want
the hosts in my network to use DHCPv6 it is not sufficient to set up
up the DHCPv6 server (and configure it properly), I also have to
configure every router to send out an M/O bit. For _every_ subnet
btw (which is currently something >500).
So please don't use them as triggers. Using them as a hint is fine,
but
as stated before, this is close to useless.
A little bit more motivation:
In my mind, if capable, a client will always launch DHCPv6 (at least
once) and will try to get additional information, be it an address or
just some other information. It has to ask for some (DNS e.g.)
information anyway. _Especially_ if you switch networks a lot.
This is where we disagree. I feel very strongly that it's ESSENTIAL
that a network administrator has a way to make hosts that aren't
specially configured to act one way or another NOT do DHCPv6. If we
assume the M/O bits will be used for this (we can come up with
something new, of course) that means that if both these bits are set
to zero, a host without special configuration does NOT do DHCPv6.
I agree that in large networks, it's probably unpleasant to have to
set up M and O bits properly on every router on every subnet. On the
other hand, you need to install a DHCP server, or, more likely,
DHCPv6 relaying, on every subnet anyway, so we shouldn't blow this
out of proportion either.
But it would be very helpful if routers could set the M and O bits
automatically depending on some other relevant configuration. For
instance, assuming that it's always possible to set the bits to a
specific value manually, the default value could depend on wheter the
router itself is configured to be a DHCPv6 server, or is configured
as a DHCPv6 relay. In the latter case, the router could even
temporarily poll the server and clear the bits if the server is dead.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
