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

From: "Bound, Jim" <[email-masked]>
Date: Wed, 1 Jun 2005 08:43:33 -0400

> We need to agree on requirements before we try to engineer solutions.
> Here is what I've heard as requirements:
> 
> 1) Ability to indicate to a host "DHCP is not available on this link",
>    with the expectation that the host won't send any DHCP messages
> 
> 2) Ability for a host to get all desired and available DHCP
>    configuration with a single DHCP message exchange
>    - if a host wants HCB, it sends an HCB request (Solicit) 
> and receives
>      HCB and/or ICB replies
>    - if a host wants ICB, it sends an ICB request 
> (Information-request) 
>      and receives ICB replies
> 

I agree.

> 1 is a requirement in scenarios with limited resources (e.g., 
> wireless), 

add e.g. wireless, admin does not want stateful)  This is important.
Many here beleive that stateful should never be used other than for
configuration.    

> where polling for DHCP is unacceptable.  

2 is a requirement to avoid
> timeout delays or other complexity in getting ICB reply when 
> host would
> prefer HCB reply.

Problem is what controls if addresses are permitted to be requested?  

I liked my layout of the problems better :--)

thanks
/jim
> 
> Comments?
> 
> - Ralph
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 1 Jun 2005 13:15:42 -0400

> Treating RA information that DHCPv6 servers aren't available as a  
> hint and ignoring the hint is an implementation of the ability to do  
> DHCP without having to configure routers.

I agree and I think most agree that the router RA determines if dhc is
to be used at all. Thus that purpose of the "m" bit is valid and useful.

Thus I support that if the router does not set the m bit that the client
MUST not use dhc.

> > This can be accomplished in two ways - have clients only send
> > Information-Request OR allow them to send Solicits and 
> "fix" DHCPv6 to
> > allow only other configuration parameters to be communicated in an
> > Advertise. Of course, the latter has come 
> interoperatability issues  
> > with
> > existing implementations.
> 
> Right.

If the M bit is set then it is up to the dhc client per the dhc server
what the client is permitted to do as dhc client.  This implies to a
network site setting the m bit means giving all dhc control for policy
to the dhc server as to what the client can do or not do.  Which to me
makes sense.

This means we don't need the o bit is my view.  Now as that affects ND
and Addrconf and all I care about for this discussion, not dhc for a
moment, here is my suggestion, if we did reaach consensus we only need
the m bit.

Deprecate the o bit in some proper IETF way, and leave that bit position
for 1 year alone and not resusable for 1 year. This permits ND and
Addrconf code bases to update and simply delete the code base for the o
bit.  How we do that in a "proper" way is important.  Then that bit
would be reusable for the IETF within ND after 1 year.

My first concern is to reduce the pain to ND and addrconf
implementations which is widely deployed. Then dhc can work on the means
to set the policy which is dhc and I think backwards compatibility will
not be painful, if we do this very quickly. Note very quickly like in 3
months.

/jim

---

From: [email-masked]
Date: Wed, 1 Jun 2005 20:43:24 +0100

Mohacsi Janos wrote:
> On Wed, 1 Jun 2005 [email-masked] wrote:
> 
>> [email-masked] wrote:
>>> On Wed, 1 Jun 2005, Ralph Droms wrote:
>>>>   - if a host wants HCB, it sends an HCB request (Solicit) and
>>>>     receives HCB and/or ICB replies
>>> 
>>> It would be even better to keep backward compatibility, i.e., not
>>> require extensions to ICB-only DHCP servers to support Solicits.
>>> Let's face it, those extensions always take time to specify, code
>>> and deploy, the admins will have to wait for new versions, etc.
>> 
>> What admins? Several posts in this thread indicate that there is
>> little if any production deployment of DHCPv6 right now.
>> 
> 
> This not true. There are several systems are using DHCPv6 to
> distribute DNS server information via IPv6. We also use this
> capability for more than one year in production.

Like I said, 'little ... production deployment'.

> Keeping combatibility to some extent, is always a golden rule

Agreed, but this case may be an exception to prove the rule.

 -- Mat

---

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

> It would be really nice and handy to initiate either stateless or
> stateful DHCPv6 with the same message. If so, we wouldn't need
> the M/O bits anymore. In this case the client would simply initiate
> a(n Information) Request message and would get all the information
> that are available on the link, including an address or not.

So you don't believe that the RA in ND should be the authority to use a
stateful model on an IPv6 link?

/jim

---

From: [email-masked]
Date: Thu, 2 Jun 2005 16:46:56 +0100

> stateful model on an IPv6 link?

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.

 -- Mat

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 3 Jun 2005 00:04:00 -0400

Fred,

Good questions.  But could cause gigantic rat-hole :--)

> At the risk of covering old ground, one question I had is 
> whether a client must wait to receive an RA before initiating 
> stateless or stateful DHCPv6? Asked another way, can DHCPv6 
> still be used if there are no advertising routers on the link?

To get prefixes yes, and to use them the A bit should be set.  But IPv6
is stateless in the node.  The node creates the link-local and then DAD
on the network.  Though I think shutting DAD off completely in some
environments is now prudent for some users special networks.  

> 
> To an even more speculative question, if we had it all to do 
> over again would it be possible (or desireable) to design 
> things such that DHCPv6 and IPv6 ND messages could be 
> "piggybacked" within a single packet? (This begs the question 
> of whether the DHCPv6 server/relay and IPv6 router entities 
> are co-resident on the same node in the normal case.)

Two questions really.

On piggy-back I don't think so for me.  Stateless is the win for IP from
the efforts for IPv6, and permeates its technical and operational
benefits for networks, DHCP is stateful and means some server function
exists that has state.  I support the model now and the authority plane
of stateless or stateful model via the A bit and then stating to use or
not use stateful.

As far as co-locating the functions that is an implementation choice and
we should not speculate on implementation of that nature between routers
vs. hosts. vs. servers. vs clients, when building a standard on this
topic.  Also can start an anti-trust problem :--).  So I say let the
market decide on that one.  I don't think its a good idea personally
speaking strictly as individual knowing both routers and hosts as IP
stack architecture and their purpose in my view.

I think its pretty simple and backwards compatibility for ND and
addrconf is drop the o bit and keep the m bit see my previous suggestion
on this sent a day or so ago.

thanks
/jim
  
> 
> Fred
> [email-masked]    
> 
> "Bound, Jim" <[email-masked]> wrote:

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 3 Jun 2005 08:57:54 -0400

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-masked]] 
> Sent: Friday, June 03, 2005 2:38 AM
> To: Bound, Jim
> Cc: [email-masked]; [email-masked]
> 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:
> 
> > 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
> 
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 3 Jun 2005 09:06:35 -0400

Mat, 

> Yes, agreed. Going further, maybe A=0 could signal this?

Not bad Mat.  That might actually work. Kudos to your logic parsing
here.  In our fury to make sure we told clients use stateless we added
the M bit.  O bit was an anomaly IMO.  Need to roll this around in my
brain with implementer view it will cause some pain to upgrade the code
base.  And now we are talking about widely deployed code base and
actually shipping products that are being used significantly for some
pretty important deployments. Sure makes life simpler and gets us two
extra bits back.

IPv6 ND and Addrcon base spec implementers what do you think?  Probably
could be done in next OS upgrade not that much code change?

thanks
/jim

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 3 Jun 2005 09:40:46 -0700

Thanks for the response Jim, and not looking to cause ratholes. Not sure on all points, but I agree that we should not be trying to legislate (or anticipate) policies in any mechanisms we specify.

There was also a wording gaffe in the phrase: "one question I had"; the intent was not to satisfy the author's personal curiosity but rather to explore the underlying assumptions for the benefit of the list.

Fred

> From: Bound, Jim [mailto:[email-masked]]
> Sent: Thursday, June 02, 2005 9:04 PM
> To: Templin, Fred L; Christian Schild; [email-masked]; [email-masked]

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 6 Jun 2005 19:59:00 -0400

> Bound, Jim wrote:
> > But it is possible to change the meaning of A=0 to mean use 
> dhc if you have
> > it.
> > 
> > Also multiple prefixes can be provided. 
> > 
> > L and A are orthogonal. If you set L and not A all that was 
> stated is use
> > these for link knowlege but not for autoconfigure.
> 
> But the fact that the A flag appears in every Prefix 
> information option 
> makes defining the semantics of A=0 as "use DHC" quite tricky.
> 
> Suppose the RA contains 2 PIOs:
> 	prefix1, A=1, O=1, R=0
> 	prefix2. A=0, O=0, R=1
> (The R flag was defined in the Mobile IPv6 RFC)
> 
> Should this mean "use DHC" or not?
> 
> What if some future RFC introduces an additional flag in the Prefix 
> information option (as Mobile IPv6 just did); what's the semantics of
> 	A=0, O=0, R=0, New flag=1
> in terms of DHC? Does the semantics change whether or not there are 
> other prefixes included in the RA.
> 
> Thus defining the semantics of the M/O bits in the RA is trivial 
> compared to trying to overload A=0!

Agreed the overload as you state would be very tricky and I agree it is
probably not worth it to pursue.

thanks
/jim

>     Erik