Am Montag, den 30.05.2005, 15:46 +0200 schrieb Iljitsch van Beijnum: > On 30-mei-2005, at 14:51, Christian Schild wrote: > > > In my mind RFC3736 is flawed, as it's clients use an > > Information-Request message to initiate communication with a > > DHCPv6 server and not a Solicit message like RFC3513. > > It is _too_ lite. > > What is it that you want to do for which full DHCPv6 is too heavy but > stateless DHCPv6 is too light? > > > 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. 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. 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. > As for the client: > > If a client only asks for configuration information and says it will > do rapid-commit, and the server goes along with this (I'm not sure if > the server can force more information than what the client asked for, > IANADHCPv6Expert), you're basically doing stateless with a Solicit > message. > > On the other hand, if you want to implement a simple client, just > build one that does an Information-Request. > > Server: > > If you know in advance you're only going to receive Information- > Requests, you can implement an RFC 3736 server. > > However, if you don't know this for sure, you'll have to implement a > server that parses the entire DHCPv6 protocol, even if this server > doesn't intend giving out stateful information (addresses or prefixes). You don't have to. 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. > So what we need is a way to make sure clients only (need to) do > Information-Requests in situations where this is appropriate. Then we > can build RFC 3736 light clients. If not, at least the servers and > possibly also the clients need to implement the full stateful protocol. > > Also, as an operator I want to know whether a client is going to > receive addresses over DHCPv6 in advance rather than have to wait for > the client to do the DHCPv6 interaction and see what happened > afterwards. > > > If so, we wouldn't need the M/O bits anymore. > > Is not needing the O bit a goal? > > We need the M bit regardless: trying to talk to a DHCPv6 server that > isn't there wastes time and bandwidth. > > > So > > 1)we should use M/O as indicators, or > > 2)fix RFC3736 to understand Solicit message and then we could drop > > M/O. > > > While it is more work and probably more pain, I'd prefer the latter. > > Why? > > 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. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
