Christian, I can live with a SHOULD (I was using MUST to get folks to respond :--)). I just don't think we can have our cake and eat it too, it is an immature view to try. We also have to realize for any spec implementations will always support what the customer wants in cases of choices over the spec in case of a SHOULD. That makes sense too and the users will cause the correction they want. But, we need to make sure the users "clearly" understand the intent of our IETF work too. The consensus here in the IETF is that statless should be used whereever possible. Note I am not against dhc6 and stateful either I put a part of my IETF lifetime into dhc6 and pushed it all the way back at IETF Danvers 1995. But, I do believe the inherent Steve Deering (Father of IPv6) model of IPv6 permitting stateless behavior is correct view for the evolution of the Internet using IPv6.
I don't think we need the O bit anymore either. Leave that to dhc WG and process. But, we need a way to suggest a large code base transition for dropping the O bit for ND and Addcronf. The if conditionals for the M bit should support this without adding a lot of code to implementations is my view, from talking with some other implementers. Also if we can do this quickly it would be good because of updates to 2461biz and 2462biz. Also I agree with you, when no RA it is a free zone decison client can us dhc. But, I don't support putting that text in ND or addrconf as it opens up discussion not currently there. We are silent on this use case and should remain silent. If we want to open this aspect of link behavior it should be its own IETF spec and work item, approved by IPv6 Chairs and this WG. Reason is there is more to this than just dhc clients. thanks /jim > -----Original Message----- > From: Christian Schild [mailto:[EMAIL PROTECTED] > Sent: Friday, June 03, 2005 2:38 AM > To: Bound, Jim > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: RE: [dhcwg] RE: purpose of m/o bit > > 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 --------------------------------------------------------------------
