Subject: RE: [dhcwg] RE: purpose of m/o bit

From: "Bound, Jim" <[email-masked]>
Date: Thu, 2 Jun 2005 12:23:37 -0400

Mat,

> 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.

thanks
/jim

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Christian Schild <[email-masked]>
Date: Fri, 03 Jun 2005 08:38:12 +0200

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).

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Jun 2005 10:14:08 +0200

> enforceable. What if the client is not pleased with what he got?

Whether something is enforceable is not the point. The IETF can't  
enforce _anything_, that's a given.

What's important is the default behavior. We MUST avoid a situation  
where hosts do DHCPv6 out of the box regardless of the value of the M  
and O bits.