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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 27 May 2005 14:25:18 -0400

Erik:

As I believe Spock said - "there are always possibilities".

But realisticly, do you expect any old client to check for these "other
configuration" parameters and if they got them, what might they do? Drop
the packet? Well, that is what the client would essentially have done
anyway since it got no addresses. So, while a poorly implemented client
might well crash, I can't really see that being likely and it would be
worth it to get that client fixed as quickly as possible since it
doesn't adhere to the "be liberal in what you receive" IETF "rule".

If people are really concerned about this, we can always add a DHCPv6
option to the Solicit that tells the server "I'm a new client and am
able to receive other configuration parameters even if you're not going
to give me any addresses." Thus, the old servers would ignore this
option and new servers would know that it is OK to do this.

Regarding the other issue, why would a stateless only client ever say
"Oh, I'll send Solicit instead of Information-Request"? If they did that
today, they wouldn't get very far.

Sure, if a new client sent Solicits and the old stateless server ignored
them, there would be a problem (as I pointed out in previous
message(s)).

But, I suspect that the magnitude of that problem is small. And, the
sooner we resolve these issues and update the specs, the fewer
implementations will have issues (I know of a bunch of implementations
under development so if we wait much longer ...).

An old client that sends Solicits to a stateless server won't get very
far today anyway, so we can ignore that case. And, if it fails over to
use Information-Request, great.

- Bernie

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Friday, May 27, 2005 1:43 PM
> To: Bernie Volz (volz)
> Cc: Iljitsch van Beijnum; [email-masked]; [email-masked]; 
> Ralph Droms (rdroms)
> Subject: Re: [dhcwg] RE: purpose of m/o bit
> 
> Bernie Volz (volz) wrote:
> > Why?
> > 
> > If we update the DHCPv6 protocol to allow "other 
> configuration" options
> > to be returned in an Advertise for a Solicit, 
> Information-Request/Reply
> > and Solicit/Advertise are then essentially the same in a stateless
> > DHCPv6 environment (though the Solicit does require a 
> client identifier
> > and likely may require a IA_* option).
> > 
> > Note that this will require changes to 3315 and 3736 - 
> since stateless
> > servers will need to respond to Solicits with Advertises.
> 
> Do we know we can change DHCPv6 that way without causing 
> compatibility 
> problems for any existing DHCPv6 clients? I can see such a client not 
> expecting configuration information in the advertise message.
> Or are we assuming that there are no 3315 DHCP clients out there?
> 
> There might also be compatibility issues on the server, since this 
> appears to assume that a 3736-only server will handle Solicit 
> messages, 
> unless the clients have some logic to fallback from using Solicit to 
> using Information-Requests after a few attempts.
> 
>     Erik
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 May 2005 11:39:40 -0700

> option and new servers would know that it is OK to do this.

DHCPv6 is not a full standard.   I don't think it's widely deployed  
at this point.   I would rather take the risk, as you suggest, than  
add an extra protocol to negotiate whether we can do this - it's  
extra logic in the server that will be needed for zero clients two  
years from now - just another piece of unused code that could be  
buggy, because it's never used, and thus could be an avenue of attack  
for some enterprising young script kiddie.

The time to get conservative about breaking clients by sending them  
unexpected responses will come, but it hasn't come yet, IMHO.   I  
haven't heard anything to contradict this - has anyone else?

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 May 2005 13:45:05 -0700

> doesn't adhere to the "be liberal in what you receive" IETF "rule".

If we ignore DHCP client implementations which crash when they receive 
an unexpected option, what is the worst case of a RFC 3315 client in 
this case?
Is it just to ignore the options in the Advertise message and proceed to 
send a Request message?
That wouldn't be a big deal to me.

> today, they wouldn't get very far.

The server compatibility issue isn't about today.

The issue I see if we recommend that clients (which implement both RFC 
3315 and 3736) always send a Solicit (when some bit is set in the RA 
telling it to use DHCP), then such a client will not interoperate with 
currently deployed 3736 DHCP servers.
My understanding is that there is some deployment of 3736 DHCP servers 
(to do prefix delegation and DNS configuration, etc).

Do we know that there is zero deployment of 3736 servers today?

If we need to handle those, it seems like either
  - the client needs to try a few Solicits first, and if that fails, try
    an Information-Request. (Or try them in parallel??)
  - Have some indication in the RA that only 3736 service is available on
    the network, so that the client can do the Information-Request only.

The second alternative seems simpler to me.

    Erik

---

From: Pekka Savola <[email-masked]>
Date: Sun, 29 May 2005 22:04:39 +0300 (EEST)

On Fri, 27 May 2005, Erik Nordmark wrote:
> The issue I see if we recommend that clients (which implement both RFC 3315 
> and 3736) always send a Solicit (when some bit is set in the RA telling it to 
> use DHCP), then such a client will not interoperate with currently deployed 
> 3736 DHCP servers.
> My understanding is that there is some deployment of 3736 DHCP servers (to do 
> prefix delegation and DNS configuration, etc).
>

FWIW, I strongly believe we need to deal with _both_ stateless-only 
servers *and* clients.

I'd also prefer that we would not need to extend RFC3736 to have to 
include (some) support for handling Solicits.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 30 May 2005 15:46:17 +0200

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.

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

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 30 May 2005 22:48:28 +0200

> Assume you have a stateless server available on a link and M/O bits
> are missing or misconfigured.

Ah, ok, the problem is becoming clear to me.

You see, I've spent the last 10 years of my life configuring routers.  
Routers do what I want them to do. Period. But obviously, if you live  
in an environment where you control the servers, but not the routers,  
a situation where the router _don't_ do what you want them to may not  
be unthinkable, or even academic. It's all a matter of perspective.

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

Very true, and not a great situation. However, I don't think reducing  
functionality elsewhere is the answer.

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

Yes, a solution could be running a server that isn't strictly RFC  
3736-only.

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

If the dhc working group decides that the current stateless DHCPv6  
needs improvement, I think you guys can figure that out on your own.

However, speaking as someone who configures those pesky routers, I  
really want to be able to keep clients from initiating stateful  
DHCPv6, even if the server would only reply with stateless  
information anyway. It's a matter of predictability and debugging.  
(And some things that may or may not matter depending on what  
direction things take in the future.)

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

This is where we disagree. I feel very strongly that it's ESSENTIAL  
that a network administrator has a way to make hosts that aren't  
specially configured to act one way or another NOT do DHCPv6. If we  
assume the M/O bits will be used for this (we can come up with  
something new, of course) that means that if both these bits are set  
to zero, a host without special configuration does NOT do DHCPv6.

I agree that in large networks, it's probably unpleasant to have to  
set up M and O bits properly on every router on every subnet. On the  
other hand, you need to install a DHCP server, or, more likely,  
DHCPv6 relaying, on every subnet anyway, so we shouldn't blow this  
out of proportion either.

But it would be very helpful if routers could set the M and O bits  
automatically depending on some other relevant configuration. For  
instance, assuming that it's always possible to set the bits to a  
specific value manually, the default value could depend on wheter the  
router itself is configured to be a DHCPv6 server, or is configured  
as a DHCPv6 relay. In the latter case, the router could even  
temporarily poll the server and clear the bits if the server is dead.

---

From: Christian Schild <[email-masked]>
Date: Mon, 30 May 2005 14:51:44 +0200

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.

In the current state -- being stateful and stateless DHCPv6 two
independent protocols -- we need the M/O bits as indicators for what
is available on the link and to reduce the message count.

So 
1)we should use M/O as indicators, or 
2)fix RFC3736 to understand Solicit message and then we could drop M/O.

So long,
     Christian

---

From: "Christian Schild (JOIN Project Team)" <[email-masked]>
Date: Mon, 30 May 2005 17:16:12 +0200

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. 

> doesn't intend giving out stateful information (addresses or prefixes).

You don't have to. 

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.

Christian