Hi Jim, Am Donnerstag, den 02.06.2005, 12:23 -0400 schrieb Bound, Jim:
> > So you don't believe that the RA in ND should be the authority to > > use a stateful model on an IPv6 link? Thanks for your question, I think that's a key part of the discussion. I know what you are trying to achieve. As a network admin it is a really desirable goal to be in control of the clients to send DHCPv6 messages or not. This control in fact could be achieved with a proper definition and usage of the M/O bit(s). But: > > stateful/stateless is of no concern to the client, right? so if the > > initiator is always the same, then the question of authority becomes > > moot. > > Let me restate I don't think you parsed my question, which may have been > unclear in hingsight? > > For an IPv6 link the RA informs nodes whether they are permitted to use > stateful, the default preference is stateless, meaning DO NOT USE DHCPv6 > for anything, unless I set a bit that informs you that your permitted to > use stateful on this link. > > This means the client after getting A bit set, and M/O bits not set, and > prefix list it does not execute DHCPv6 client code at all. > > This is what I mean't by authority of RA to the client. > > Do you disagree with that the IPv6 Link uses this model. > > The way most implementations I am aware of work is as follows as hosts: > > If 'A' bit set with prefixes provided, set prefix list/lifetimes to on, > and configure addresses from prefix with EUI. > > THEN check: > > If 'M' or 'O' bit set then call dhcpv6 client thread, or however > engnineer wanted to implement this, ELSE dhcpv6 is not called. This is the ideal scenario, yes. (side note: I think we agree, that a client is allowed to do dhcpv6 in the lack of RAs?) I think this scenario might fail, because: Client (needing addresses and information) and routers (sending RAs) are two different entities with their own set of behaviours and their own set of wishes. In your model you are trying to force the client to do something what the router wants. Fine with me, but I don't believe that suppression of (client) DHCPv6 packets is enforceable. What if the client is not pleased with what he got? E.g.: The client desperately needs an additional information, lets say an NTP server. Maybe because an application needs it. The client may get the idea "ok, I'm not allowed to do DHCPv6, but I really really need that information" so it will launch DHCPv6. NTP is just an example. E.g.: What if the client is not pleased with the address he got. E.g. he only got a ULA prefix via the RA and wants to communicate with the global network. Then the client may probe if there are more and better prefixes available in DHCPv6. This can even get initiated by a user (!). I hope you know what I'm trying to say. The really dangerous part in your model is, that a network administrator may get the impression, that now that DHCPv6 is disable on that link (M=0,O=0), nothing on that link will use it. As shown above, this may not be true, it is not enforceable. And my conclusion to this: If we really want to use the M/O bits, then please make them just hints. A SHOULD is good, a MUST is too strong. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
