Subject: [dhcwg] Proposed errata for DHCPv6 RFCs

From: Ole Troan <[email-masked]>
Date: Thu, 5 Aug 2010 14:36:47 +0200

Hi,

here is a set of suggested changes to DHCPv6 RFCs. there are 3 sets of independent changes.

1) Allow prefix delegation and address assignment to be done independently in a single DHCP session
2) Clarify authority of a delegated prefix
3) Allow for the use of address of a different scope than link-local in DHCP messages used for stateless DHCP

I was thinking of filing errata as proposed below. comments?

cheers,
Ole

Proposed erratas for the following DHCPv6 RFCs:

RFC3315:
--------------
Purpose: Allow IA_NA/TA and IA_PD to be done in the same DHCP session.

Change: Section 17.1.3:
   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user.

to:

   The client MUST ignore any IAs in an Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user.

RFC3633:
--------------
Purpose: Allow IA_NA/TA and IA_PD to be done in the same DHCP session.

Change Section 11.1:

   The requesting router MUST ignore any Advertise message that includes
   a Status Code option containing the value NoPrefixAvail, with the
   exception that the requesting router MAY display the associated
   status message to the user.

to:

   The requesting router MUST ignore any IA_PDs in an Advertise message that includes
   a Status Code option containing the value NoPrefixAvail, with the
   exception that the requesting router MAY display the associated
   status message to the user.

Purpose: Clarify delegation of authority of prefix:
Change Section 12.1:
   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached, with the following exception: the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.

to:
  Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached.

Add at the bottom of section 7:
When the DR delegates prefixes to a Requesting Router, the Requesting Router has sole authority
for assignment of those prefixes, and the Delegating Router MUST NOT assign any prefixes from that delegated prefix
to any of its own links.

RFC3736:
---------------
Purpose: Allow use of globally scoped addresses as the source address for DHCP packets.

Either new section 5.5 or a new paragraph in section 5:
If the client has been configured with an address of appropriate scope for the DHCPv6 server, and the client has assigned an address of appropriate scope to one of its interfaces, the client MAY send the Information-Request message to the DHCPv6 server address, using its own address as the source.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 5 Aug 2010 17:08:52 +0200 (CEST)

>   prefixes to each of the links to which the associated interfaces are

I still don't like this. I still don't understand the rationale for it and 
I just think it's wrong that the DR should assign prefix to the link where 
it got the PD from.

> for assignment of those prefixes, and the Delegating Router MUST NOT assign any prefixes from that delegated prefix

... especially in conjunction with this. I also oppose the rationale that 
this might be a good idea in mobile networks, having the UE assign 
addresses for links to the PGW/GGSN to use sounds just *bad*. I don't 
understand why someone would ever want to do this.

> If the client has been configured with an address of appropriate scope 
> for the DHCPv6 server, and the client has assigned an address of 
> appropriate scope to one of its interfaces, the client MAY send the 
> Information-Request message to the DHCPv6 server address, using its own 
> address as the source.

So first we do LL to start doing the DHCPv6 interaction via a proxy, and 
then all of a sudden we do something else and start talking to the proxy 
directly? Why? How do I as an ISP authenticate that this message is 
actually correct?

Could you please elaborate on the purpose of this change, I think the "use 
of globally scoped addresses as source for DHCP packets" isn't really a 
"purpose" I understand, I'd like to know more what problem this solves?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 05 Aug 2010 17:25:37 +0200

In your previous mail you wrote:

   3) Allow for the use of address of a different scope than
   link-local in DHCP messages used for stateless DHCP
   
=> the point 3 raises an issue about multicast too.

Regards

[email-masked]

PS: the usual solution for the point 3 is to co-locate a relay with
the client (as there is no constraint on the relay-agent communication).

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Aug 2010 10:32:59 +0200

[moving this to a new thread]

> the client (as there is no constraint on the relay-agent communication).

right, and that's the solution proposed in:
draft-xu-ipv6-ra-dhcp-server-option-01.txt

for stateless DHCP do we really need to deploy a relay infrastructure? we have links which do not support link-local addresses and which do not support multicast.

do you see any issues with relaxing the DHCP client restriction of MUST use link-local address as a source address?
I also wonder why we couldn't relax the limitation that a DHCP server MUST discard messages with a unicast destination address.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Aug 2010 10:36:23 +0200

[created a separate thread for authority of PD change]

> I still don't like this. I still don't understand the rationale for it and I just think it's wrong that the DR should assign prefix to the link where it got the PD from.

this text says no such thing.

> ... especially in conjunction with this. I also oppose the rationale that this might be a good idea in mobile networks, having the UE assign addresses for links to the PGW/GGSN to use sounds just *bad*. I don't understand why someone would ever want to do this.

the _only_ thing this text states is that in prefix delegation, the authority of the prefix is transferred to the requesting router. the requesting router is free to do with the prefix as it likes.

the problem with the existing text was that the restriction was in the wrong place. the restriction is on the DR. the DR isn't allowed to do anything with the prefix that it delegates. isn't that pretty much the opposite of what you think it says?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Aug 2010 10:41:55 +0200

Mikael,

> So first we do LL to start doing the DHCPv6 interaction via a proxy, and then all of a sudden we do something else and start talking to the proxy directly? Why? How do I as an ISP authenticate that this message is actually correct?

no. this is for the stateless DHCPv6 case.

> Could you please elaborate on the purpose of this change, I think the "use of globally scoped addresses as source for DHCP packets" isn't really a "purpose" I understand, I'd like to know more what problem this solves?

take the case where an IPv6 only node is behind a 6rd CE router.
you want the 6rd CE to acquire stateless DHCPv6 options. with todays specification it would have to run a local (as in inside the box) relay which the local client could talk to, to get around the link-local restriction. then it would have to make some assumptions on the use of multicast to get to the DHCP server in the 6rd domain or it would have to be provisioned with the unicast address of the DHCPv6 server.

why couldn't we instead allow the DHCPv6 client on the 6rd CE to talk directly with the DHCPv6 server? (and if we made the requirement that the 6rd BR supported the DHCPv6 server, we could do it without additional provisioning).

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 6 Aug 2010 10:50:56 +0200 (CEST)

On Fri, 6 Aug 2010, Ole Troan wrote:

>> I still don't like this. I still don't understand the rationale for it 
>> and I just think it's wrong that the DR should assign prefix to the 
>> link where it got the PD from.
>

But it removes the prohibition of such a behaviour. Only reason to remove 
it I can see is because the behaviour I described should be permitted, ie 
that must be the reason for the proposed change?

>> ... especially in conjunction with this. I also oppose the rationale 
>> that this might be a good idea in mobile networks, having the UE assign 
> the _only_ thing this text states is that in prefix delegation, the 
> authority of the prefix is transferred to the requesting router. the 
> requesting router is free to do with the prefix as it likes.

Yes?

> the problem with the existing text was that the restriction was in the 
> wrong place. the restriction is on the DR. the DR isn't allowed to do 
> anything with the prefix that it delegates. isn't that pretty much the 
> opposite of what you think it says?

I still don't understand. Didn't you want the DR to be able to use one /64 
out of the prefix?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 6 Aug 2010 10:58:50 +0200 (CEST)

On Fri, 6 Aug 2010, Ole Troan wrote:

> take the case where an IPv6 only node is behind a 6rd CE router. you 
> want the 6rd CE to acquire stateless DHCPv6 options. with todays 
> specification it would have to run a local (as in inside the box) relay 
> which the local client could talk to, to get around the link-local 
> restriction. then it would have to make some assumptions on the use of 
> multicast to get to the DHCP server in the 6rd domain or it would have 
> to be provisioned with the unicast address of the DHCPv6 server.

I don't understand this deployment scenario. I've always thought of 
6to4/6RD as creating a "PD" way of handing IPv6 addresses, so the CE 
router would actually be a router and have full authority and control over 
what addresses are within the /56 or whatever is delegated to it over the 
6RD tunnel, so I've always seen CE router to do routing, have DHCPv6 
server, do RA for SLAAC etc, to handle everything behind it.

> why couldn't we instead allow the DHCPv6 client on the 6rd CE to talk 
> directly with the DHCPv6 server? (and if we made the requirement that 
> the 6rd BR supported the DHCPv6 server, we could do it without 
> additional provisioning).

What is the reason for doing it this way, instead of the "classical" way 
with a "full" CE router implementation or have the CE act DHCPv6 proxy?

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Aug 2010 11:00:13 +0200

Mikael,

> But it removes the prohibition of such a behaviour. Only reason to remove it I can see is because the behaviour I described should be permitted, ie that must be the reason for the proposed change?
> 
> I still don't understand. Didn't you want the DR to be able to use one /64 out of the prefix?

this erratum is only about fixing the mistake in the text. and making it clear that the DR can not use a /64 out of the delegated prefix.

solving the issue of having a single prefix per subscriber requiring a hole in the delegated prefix, will require the new DHCP exclude option or a new encoding of the prefix option.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Aug 2010 11:02:00 +0200

Mikael,

>> take the case where an IPv6 only node is behind a 6rd CE router. you want the 6rd CE to acquire stateless DHCPv6 options. with todays specification it would have to run a local (as in inside the box) relay which the local client could talk to, to get around the link-local restriction. then it would have to make some assumptions on the use of multicast to get to the DHCP server in the 6rd domain or it would have to be provisioned with the unicast address of the DHCPv6 server.
> 
> I don't understand this deployment scenario. I've always thought of 6to4/6RD as creating a "PD" way of handing IPv6 addresses, so the CE router would actually be a router and have full authority and control over what addresses are within the /56 or whatever is delegated to it over the 6RD tunnel, so I've always seen CE router to do routing, have DHCPv6 server, do RA for SLAAC etc, to handle everything behind it.
> 
> What is the reason for doing it this way, instead of the "classical" way with a "full" CE router implementation or have the CE act DHCPv6 proxy?

_stateless_ DHCPv6. how does the 6rd CE know which IPv6 DNS server to give to hosts on the LAN side?
(assuming it doesn't run an IPv6 DNS proxy).

cheers,
Ole

---

From: [email-masked]
Date: Fri, 06 Aug 2010 11:04:45 +0200 (CEST)

> why couldn't we instead allow the DHCPv6 client on the 6rd CE to talk directly with the DHCPv6 server? (and if we made the requirement that the 6rd BR supported the DHCPv6 server, we could do it wi…

Since this (unicast directly from client to server) is well established
practice for the DHCPv4 client renewal case, it would be useful to know
*why* the RFC has been written to disallow this for DHCPv6.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 6 Aug 2010 11:06:52 +0200 (CEST)

> _stateless_ DHCPv6. how does the 6rd CE know which IPv6 DNS server to give to hosts on the LAN side?

Well, I'd imagine that is less of a problem than how it knows what IPv6 
DNS server to use for itself? If it knows that, then it can hand out the 
same one to its lan hosts?

How does it gain the knowledge of what nameserver to use, is that what 
you're solving here, so it can be provisioned with a static DHCPv6 server 
IP for learning DNS etc via, and talk over a 6RD tunnel?

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Aug 2010 11:18:50 +0200

Mikael,

> Well, I'd imagine that is less of a problem than how it knows what IPv6 DNS server to use for itself? If it knows that, then it can hand out the same one to its lan hosts?

sure.

> How does it gain the knowledge of what nameserver to use, is that what you're solving here, so it can be provisioned with a static DHCPv6 server IP for learning DNS etc via, and talk over a 6RD tunnel?

how exactly did you expect that to work?
via a client _and_ relay on the 6rd CE and a pre-provisioned DHCPv6 server address?

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 6 Aug 2010 12:30:06 +0200 (CEST)

On Fri, 6 Aug 2010, Ole Troan wrote:

>> you're solving here, so it can be provisioned with a static DHCPv6 
>> server IP for learning DNS etc via, and talk over a 6RD tunnel?
>

I don't know, that's why I'm asking.

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Aug 2010 12:32:28 +0200

> I don't know, that's why I'm asking.

and my proposed answer is to relax the limitations of source and destination addressing in DHCPv6.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 6 Aug 2010 13:12:39 +0200 (CEST)

On Fri, 6 Aug 2010, Ole Troan wrote:

>>>> How does it gain the knowledge of what nameserver to use, is that 
>>>> what you're solving here, so it can be provisioned with a static 
>>>> DHCPv6 server IP for learning DNS etc via, and talk over a 6RD 
>>>> tunnel?
>>>

But I still don't understand how the proposal you gave solves the problem.

If the UE router doesn't know what DNS server to use, how will the unit 
behind the UE unit know who to ask DHCP for? How will the UE router gain 
this knowledge? By doing stateless DHCPv6 on the RD link with its global 
address and the other end of the 6RD tunnel relays this to the DHCPv6 
server? And because the 6RD tunnel doesn't have LL, this needs to be done 
using global addresses?

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Aug 2010 13:35:44 +0200

Mikael,

> If the UE router doesn't know what DNS server to use, how will the unit behind the UE unit know who to ask DHCP for? How will the UE router gain this knowledge? By doing stateless DHCPv6 on the RD link with its global address and the other end of the 6RD tunnel relays this to the DHCPv6 server? And because the 6RD tunnel doesn't have LL, this needs to be done using global addresses?

not sure what an UE router is, but in DHC/6rd terminology then:

- 6rd CE is a DHCP client the 6rd BR is a DHCP server. the 6rd CE router requests DNS server, and other configuration options from the
  DHCP server using global addresses.
- the 6rd CE is a DHCP server on it's LAN side interface(s) and gives local hosts other configuration information.
  (as described in the CPE router requirements draft).

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 6 Aug 2010 13:49:20 +0200 (CEST)

>  (as described in the CPE router requirements draft).

... and the reason for the relaxation is that 6RD tunneled packets doesn't 
have LL?

I think I got it now.

Perhaps the relaxation should be a bit more specific and only handle the 
case where LL address is not available?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Aug 2010 12:08:39 -0500

Ole:

I think the text in 17.2.2 also requires clarification:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
   code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID.

This "MUST send" is a problem because it does not account for IA_PD (or
any non-address IA) processing at all, and in the case where prefixes
are delegated, a "complete" response to the client should be allowed
(with 'other information' options, etc.).

---

Where did "3) Allow for the use of address of a different scope than
link-local in DHCP messages used for stateless DHCP" this come from? I
don't support this change. We want clients to ALWAYS go through relay
agents (believe me, this causes no end of problems in DHCPv4 because
certain messages are unicast). The only exception is when a DHCP server
has told the client is can unicast using the server-unicast option.

---

I have no opinion on "2) Clarify authority of a delegated prefix".

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Thursday, August 05, 2010 8:37 AM
To: [email-masked] Group
Subject: [dhcwg] Proposed errata for DHCPv6 RFCs

Hi,

here is a set of suggested changes to DHCPv6 RFCs. there are 3 sets of
independent changes.

1) Allow prefix delegation and address assignment to be done
independently in a single DHCP session
2) Clarify authority of a delegated prefix
3) Allow for the use of address of a different scope than link-local in
DHCP messages used for stateless DHCP

cheers,
Ole

RFC3315:
--------------

Change: Section 17.1.3:

to:

   The client MUST ignore any IAs in an Advertise message that includes
a Status
BV>> "any address IAs" or something like that?
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user.

RFC3633:
--------------

Change Section 11.1:

to:

   The requesting router MUST ignore any IA_PDs in an Advertise message
that includes
BV>> "includes" is a bit unclear here, can we use "encapsulates"?
   a Status Code option containing the value NoPrefixAvail, with the
   exception that the requesting router MAY display the associated
   status message to the user.

to:

Add at the bottom of section 7:
When the DR delegates prefixes to a Requesting Router, the Requesting
Router has sole authority
for assignment of those prefixes, and the Delegating Router MUST NOT
assign any prefixes from that delegated prefix
to any of its own links.

RFC3736:
---------------
Purpose: Allow use of globally scoped addresses as the source address
for DHCP packets.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Aug 2010 12:12:36 -0500

Because there are times where the RELAY AGENT information is *CRITICAL*
in determining either "where" the client is or what options it is
supposed to get. We took great pains to fix this in DHCPv6 as it is a
mess in DHCPv4.

I will SHOUT (not hum) against this ... we MUST NOT do this change.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, August 06, 2010 5:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Global scoped addresses for stateless DHCPv6

---

From: "MULTACH, JEFF (ATTLABS)" <[email-masked]>
Date: Fri, 6 Aug 2010 13:16:17 -0400

Also, what does "server will not assign any addresses" actually mean?

Does it mean that the DHCP server should, on a solicit, go as far as
seeing if there are enough addresses left in the pool for the request
and do a soft binding?

And unfortunately it sounds like the response NoAddrsAvail is
overloaded/ambiguous in terms of what it means.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernie Volz (volz)
Sent: Friday, August 06, 2010 12:09 PM
To: Ole Troan; [email-masked]
Subject: Re: [dhcwg] Proposed errata for DHCPv6 RFCs

Ole:

---

---

- Bernie

-----Original Message-----

Hi,

cheers,
Ole

RFC3315:
--------------

Change: Section 17.1.3:

to:

RFC3633:
--------------

Change Section 11.1:

to:

to:

RFC3736:
---------------

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Aug 2010 12:24:54 -0500

The Advertise is only a 'hint' as to what the server will do in the
Request/Reply; it is not a guarantee.

Thus, it depends on what the server does.

This 'will not assign any addresses' might be because the client is
administratively not allowed to get addresses (either globally or just
from its current 'connection' point) -- for example, if the client
requested IA_TA's only, perhaps the administrator has disabled this. It
might also mean that the server was unable to actually allocate any
addresses because it is 'out' or has reached some limit (either for the
client or otherwise). It could also mean that there are PD prefixes for
the client, but no address allocation prefixes.

Most servers likely do take the step of attempting to actually allocate
(temporarily, such as for a few minutes) the address for the client so
that when it returns with the Request, the final bindings can occur.

- Bernie

-----Original Message-----

Ole:

---

---

- Bernie

-----Original Message-----

Hi,

cheers,
Ole

RFC3315:
--------------

Change: Section 17.1.3:

to:

RFC3633:
--------------

Change Section 11.1:

to:

to:

RFC3736:
---------------

---

From: Francis Dupont <[email-masked]>
Date: Sat, 07 Aug 2010 19:02:26 +0200

for stateless DHCP do we really need to deploy a relay infrastructure?

=> co-locate != infrastructure

  we have links which do not support link-local addresses and which do
  not support multicast.
   
=> I already made the point about multicast.

   do you see any issues with relaxing the DHCP client restriction of
   MUST use link-local address as a source address?

=> it is not in the model.

   I also wonder why we couldn't relax the limitation that a DHCP
   server MUST discard messages with a unicast destination address.
   
=> same

Again, these two issues are solved when a relay is co-located.
So the real question is between fixing the specs or improving
implementations (*).

Regards

PS (*): as a DHCPv6 part time implementor I can say the idea is not new
and usually is well accepted (but not yet applied directly in the code).

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 09 Aug 2010 09:25:44 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Bernie
> Volz (volz)
> 发送时间: 2010年8月7日 1:13
> 收件人: [email-masked]; [email-masked]
> 抄送: [email-masked]
> 主题: Re: [dhcwg] Global scoped addresses for stateless DHCPv6
> 

In the cases where the RELAY AGENT information is critical but it is not
available in the DHCP information-request messages received by the DHCP
servers, the DHCP servers could either drop these messages or return an
error to the clients. The clients in turn will resort to the DHCP relay
agent. That is to say, the clients now will send the information-request
messages to the DHCP relay agents in multicast.

As an alternative, in those special scenarios where DHCP clients are
required to access DHCP servers through DHCP relay agents, the network
operators could make the proposed RA option for stateless DHCP servers (see
draft-xu-ipv6-ra-dhcp-server-option-01) to convey the IP addresses of DHCP
relay agents, rather than the addresses of DHCP servers. In this way, the
clients are still able to use unicast, rather than multicast, to send the
information-request messages.

Best wishes,
Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 09 Aug 2010 14:47:59 +0800

> messages to the DHCP relay agents in multicast.

It seems that the following status code is the best choice to fill the above
goal:

   UseMulticast    5 Sent by a server to a client to force the
                     client to send messages to the server.
                     using the All_DHCP_Relay_Agents_and_Servers
                     address.

   When the client receives a Reply message with a Status Code option
   with the value UseMulticast, the client records the receipt of the
   message and sends subsequent messages to the server through the
   interface on which the message was received using multicast.  The
   client resends the original message using multicast.

Best wishes,
Xiaohu

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Aug 2010 10:07:23 +0200

Bernie, et al,

[creating a new thread]

> (with 'other information' options, etc.).

we also have this same paragraph in RFC3633:

   If the delegating router will not assign any prefixes to any IA_PDs
   in a subsequent Request from the requesting router, the delegating
   router MUST send an Advertise message to the requesting router that
   includes the IA_PD with no prefixes in the IA_PD and a Status Code
   option in the IA_PD containing status code NoPrefixAvail and a status
   message for the user, a Server Identifier option with the delegating
   router's DUID and a Client Identifier option with the requesting
   router's DUID.

any suggestion to clearer text?

"MUST send ... that  includes _in addition to other IAs and options_ the IA_PD with no prefixes..."

what would the consequence of making the 3315/3633 Advertise equal? i.e put the NoAddrsAvail into the IA option?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Aug 2010 12:52:38 +0200

Bernie,

> I will SHOUT (not hum) against this ... we MUST NOT do this change.

isn't that against the IETF ethics? ;-)

would you be against it even in the case of stateless DHCPv6?
or rather are you open for any scenario where it would be acceptable to have direct client to server communication spanning across more than a single link, without a relay?

to explain where I'm coming from. there is a proposal to pass DHCPv6 server addresses in a DHCPV4 option to 6rd CPEs to use. then with a local client talking to a local relay that uses the global address.
putting to the side if a 6rd CPE would need to access a DHCPv6 server or not, I'm just exploring if there are simpler ways of doing DHCPv6 in this case.

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Aug 2010 08:26:32 -0500

I never understood why the Advertise was different from the Reply in how
it returned this information. Perhaps Ralph or others involved in the
RFC 3315 process might recall the reason for this different behavior. I
can speculate it might have been to make it easier for the client to
determine the problem and report the error (especially in the case where
there are multiple IAs).

- Bernie

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, August 09, 2010 4:07 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Use of multiple IAs in DHCPv6 (was: [dhcwg] Proposed errata for
DHCPv6 RFCs)

Bernie, et al,

[creating a new thread]

"MUST send ... that  includes _in addition to other IAs and options_ the
IA_PD with no prefixes..."

what would the consequence of making the 3315/3633 Advertise equal? i.e
put the NoAddrsAvail into the IA option?

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Aug 2010 09:12:44 -0500

If the DHCPv6 server address is configured someone (other than through
DHCPv6), then it I would be OK with it because it is then controlled by
configuration. If the DHCPv6 server address is obtained via DHCPv6, then
only the server-unicast option must control this behavior.

Your errata made no reference to this and that is the reason why I do
not support the errata as worked.

Note: You do need to be extremely careful here as there may be
situations where the client doing DHCPv6 (Information-Request) is in a
different VPN and the only entity that may know that would be the relay
agent. So, please make certain you consider this before assuming that a
the client's address and server's address are usable.

- Bernie

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, August 09, 2010 6:53 AM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] Global scoped addresses for stateless DHCPv6

Bernie,

would you be against it even in the case of stateless DHCPv6?
or rather are you open for any scenario where it would be acceptable to
have direct client to server communication spanning across more than a
single link, without a relay?

to explain where I'm coming from. there is a proposal to pass DHCPv6
server addresses in a DHCPV4 option to 6rd CPEs to use. then with a
local client talking to a local relay that uses the global address.
putting to the side if a 6rd CPE would need to access a DHCPv6 server or
not, I'm just exploring if there are simpler ways of doing DHCPv6 in
this case.

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Aug 2010 09:21:01 -0500

The only problem with this is that there situations where the returned packet might not get to the client (such as if VPNs are involved). See my email just a short time ago to Ole.

- Bernie

-----Original Message-----
From: Xu Xiaohu [mailto:[email-masked]] 
Sent: Monday, August 09, 2010 2:48 AM
To: Bernie Volz (volz); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: re: [dhcwg] Global scoped addresses for stateless DHCPv6

Best wishes,
Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 10 Aug 2010 09:05:07 +0800

Hi Bernie,

> -----邮件原件-----
> 发件人: Bernie Volz (volz) [mailto:[email-masked]]
> 发送时间: 2010年8月9日 22:21
> 收件人: Xu Xiaohu; [email-masked]; [email-masked]
> 抄送: [email-masked]
> 主题: RE: [dhcwg] Global scoped addresses for stateless DHCPv6
> 
> The only problem with this is that there situations where the returned
packet
> might not get to the client (such as if VPNs are involved). See my email
just
> a short time ago to Ole.

As long as the request packet from the client (located in a VPN) can arrive
at the server (located in the Internet), the returned reply packet would be
able to get to the client because there is a VRF-NAT deployed on the PE.
However, if the request is directly forwarded from the client to the server,
the server couldn't know which VPN the client is from since the VPN info
should have been attached by the relay agent on the PE. Is my understanding
correct?

Since there do exist some scenarios where the relay agent is a MUST and some
scenarios where the relay agent is not necessary, I suggest the following
text:

"A stateless DHCP server could accept an Information-request messages it
receives with a unicast destination address. In case that the relay agent
information is critical for the DHCP server, upon the receipt of an
Information-request message with a unicast destination address, the server
discards the Information-request message and responds with a Reply message
containing a Status Code option with the value UseMulticast, a Server
Identifier option containing the server's DUID, the Client Identifier option
from the client message, and no other options".

What's your thought on this?

In addition, the IPv6 router could actually be configured to convey the IP
addresses of DHCP relay agents rather than the addresses of DHCP servers in
the proposed RA option for stateless DHCP servers (see
draft-xu-ipv6-ra-dhcp-server-option-01) in the scenarios where DHCP clients
are required to access DHCP servers through DHCP relay agents. In this way,
the clients could still use unicast, rather than multicast, to send the
information-request messages.

Comments?

Best wishes,
Xiaohu

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Aug 2010 20:47:19 -0500

That's probably close to what might be acceptable. You'd have to get buy in from the rest of the WG.

Though one way (client to server) traffic may be possible where the reverse might not be.

And, why don't you just say that the RA option should not be used in situations where it is not appropriate? Is there something wrong with link local multicast?

- Bernie

-----Original Message-----
From: Xu Xiaohu [mailto:[email-masked]] 
Sent: Monday, August 09, 2010 9:05 PM
To: Bernie Volz (volz); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: re: [dhcwg] Global scoped addresses for stateless DHCPv6

Hi Bernie,

packet
just

Comments?

Best wishes,
Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 10 Aug 2010 10:26:51 +0800

> 发送时间: 2010年8月10日 9:47
> That's probably close to what might be acceptable. You'd have to get buy
in
> from the rest of the WG.
> 
> Though one way (client to server) traffic may be possible where the
reverse
> might not be.

Could you give a concrete example?

> And, why don't you just say that the RA option should not be used in
situations
> where it is not appropriate? Is there something wrong with link local
multicast?

That's OK. 

Best wishes,
Xiaohu

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Aug 2010 21:36:29 -0500

>Could you give a concrete example?

In v4, this example is pretty easy ... the client, as many other clients on different VPNs, has a 10.x address but the server has a "global" address.

- Bernie

-----Original Message-----
From: Xu Xiaohu [mailto:[email-masked]] 
Sent: Monday, August 09, 2010 10:27 PM
To: Bernie Volz (volz); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: re: [dhcwg] Global scoped addresses for stateless DHCPv6

in
reverse

situations
multicast?

That's OK. 

Best wishes,
Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 10 Aug 2010 11:06:45 +0800

> 发送时间: 2010年8月10日 10:36
> In v4, this example is pretty easy ... the client, as many other clients
on
> different VPNs, has a 10.x address but the server has a "global" address.

OK. In the above case, the network operator could choose to not use the RA
option, or still use it but the option is now used to convey the addresses
of the relay agents. Is that acceptable?

Best wishes,
Xiaohu

> > > > > 发件人: [email-masked] [mailto:[email-masked]] 代
表
> > > > Bernie
> > > > > supposed to get. We took great pains to fix this in DHCPv6 as it
is
> a
> > > > operators could make the proposed RA option for stateless DHCP
servers
> > > (see
> > > > draft-xu-ipv6-ra-dhcp-server-option-01) to convey the IP addresses
of
> > DHCP
> > > > relay agents, rather than the addresses of DHCP servers. In this
way,
> > the
> > > > clients are still able to use unicast, rather than multicast, to
send
> > the

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Aug 2010 13:10:19 +0200

A new set of proposed errata for RFC3315/3633.  comments and better text proposals are welcome.

RFC3315:
--------------
Purpose: Allow IA_NA/TA and IA_PD to be done in the same DHCP session.
                  Clarify that the Status Code is contained within the IA option.

Change: Section 17.1.3:

to:

Change: Section 17.2.2:

to:

   If the server will not assign any addresses to an IA in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes the IA containing a Status Code option
   with status code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID. The server SHOULD include other stateful IA options
   (like IA_PD) and other configuration options in the Advertise message.

RFC3633:
--------------

Change Section 11.1:

to:

Change Section 11.2:

to:

   If the delegating router will not assign any prefixes to an IA_PD
   in a subsequent Request from the requesting router, the delegating
   router MUST send an Advertise message to the requesting router that
   includes the IA_PD with no prefixes in the IA_PD and a Status Code
   option in the IA_PD containing status code NoPrefixAvail and a status
   message for the user, a Server Identifier option with the delegating
   router's DUID and a Client Identifier option with the requesting
   router's DUID. The server SHOULD include other stateful IA options
   (like IA_PD) and other configuration options in the Advertise message.

cheers,
Ole

---

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Aug 2010 05:38:07 -0700

Ole - can I get a quick clarification?  Are either or both of the following scenarios considered to be use case(s) for the proposed change? 

1) 6rd CE is configured with global scope address for DHCPv6 server (e.g., through DHCPv4 option); 6rd CE uses unicast with global scope addresses to send Information Request; 6rd CE passes results to DHCPv6 server on LAN interfaces
2) devices attached to the customer LAN are provisioned with global scope address for DHCPv6 server in the SP network (e.g., through RA option); customer devices use unicast with global scope addresses to send Information Request to SP DHCPv6 server

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Aug 2010 05:42:26 -0700

Bernie - can you clarify how "the Advertise was different from the Reply in how it returned this information"?

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Aug 2010 14:51:17 +0200

Ralph,

> Ole - can I get a quick clarification?  Are either or both of the following scenarios considered to be use case(s) for the proposed change? 

ah, you are making the potentially false assumption that it is clear in my own head. ;-)

> 1) 6rd CE is configured with global scope address for DHCPv6 server (e.g., through DHCPv4 option); 6rd CE uses unicast with global scope addresses to send Information Request; 6rd CE passes results…

yes. using the information received for itself and/or passing it to its own DHCP server for the LAN interfaces.
any suggestions for a name for this "passing function"?

> 2) devices attached to the customer LAN are provisioned with global scope address for DHCPv6 server in the SP network (e.g., through RA option); customer devices use unicast with global scope addre…

I envision this so that the CPE is the 'boundary' router for the DHCP administrative domains. where no DHCP traffic goes directly across. but, I'm not sure this case is something we would prohibit. an operational choice I suppose. of course this would have to be restricted to stateless options, as stateful ones would have to include coordination at the CPE. are there also new security implications in doing this?

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 Aug 2010 08:24:10 -0500

Ralph:

Here's the text in 17.2.2. Creation and Transmission of Advertise
Messages:

Here's the text in 18.2.1. Receipt of Request Messages:

   If the server cannot assign any addresses to an IA in the message
   from the client, the server MUST include the IA in the Reply message
   with no addresses in the IA and a Status Code option in the IA
   containing status code NoAddrsAvail.

In addition 18.1.8. Receipt of Reply Messages:

   The client examines the status code in each IA individually.  If the
   status code is NoAddrsAvail, the client has received no usable
   addresses in the IA and may choose to try obtaining addresses for the
   IA from another server.  The client uses addresses and other
   information from any IAs that do not contain a Status Code option
   with the NoAddrsAvail code.  If the client receives no addresses in
   any of the IAs, it may either try another server (perhaps restarting
   the DHCP server discovery process) or use the Information-request
   message to obtain other configuration information only.

18.2.1 doesn't explicitly call out the "will not assign any addresses to
any IAs", but by implication the text says to put the status code option
into the IA.

And, the last sentence in the above section 18.1.8 paragraph, by my
interpretation, seems to confirm that the case of no addresses in any
IAs is not special but related to each IA containing the NoAddrsAvail
Status Code Option. It is interesting here though that it doesn't say
that it may use the 'other configuration' information from the Reply
(and 18.2.1 never states not to provide this information).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms
Sent: Wednesday, August 11, 2010 8:42 AM
To: Bernie Volz (volz)
Cc: DHC Group Working
Subject: Re: [dhcwg] Use of multiple IAs in DHCPv6 (was: Proposed errata
forDHCPv6 RFCs)

Bernie - can you clarify how "the Advertise was different from the Reply
in how it returned this information"?

- Ralph

---

From: Jyrki Soini <[email-masked]>
Date: Wed, 11 Aug 2010 16:46:57 +0300

The proposed errata seems to be reasonable (except a small copy-paste
left over at the end).

>    (like IA_PD) and other configuration options in the Advertise message.

Shouldn't this be: (like IA_NA/TA)?
Now IA_PD not assigned, but other stateful IA options includes IA_PD.

--
Jyrki

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Aug 2010 15:53:03 +0200

Jyrki,

> Now IA_PD not assigned, but other stateful IA options includes IA_PD.

you are absolutely right.
in general it would have been nice to have a general term "IA" to refer to any stateful IA-style option. assuming that we will invent more than just IA_NA,IA_TA and IA_PD. guess that's for a 3315bis.

cheers,
Ole

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 12 Aug 2010 09:28:51 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Ole
> Troan
> 发送时间: 2010年8月11日 20:51
> 收件人: Ralph Droms
> 抄送: DHC Working Group
> > Ole - can I get a quick clarification?  Are either or both of the
following
> scenarios considered to be use case(s) for the proposed change?
> 
> ah, you are making the potentially false assumption that it is clear in my
own
> head. ;-)
> 
> > 1) 6rd CE is configured with global scope address for DHCPv6 server
(e.g.,
> through DHCPv4 option); 6rd CE uses unicast with global scope addresses to
send
> Information Request; 6rd CE passes results to DHCPv6 server on LAN
interfaces
> 
> yes. using the information received for itself and/or passing it to its
own
> DHCP server for the LAN interfaces.

To distinguish this from DHCP relay agent, how about call it DHCP proxy
server?

Of course, the DHCP relay agent is also available in the 6rd scenario. For
example, upon the receipt of a DHCP Information-request message from an IPv6
hosts inside the residential network, the relay agent on the CPE then
forward the DHCPv6 Relay-forward message in unicast to a DHCPv6 server
(e.g., the DHCPv6 addresses are learnt through a DHCPv4 option), with the
source address being a global-scope address of the relay agent.

Best wishes,
Xiaohu  

> > 2) devices attached to the customer LAN are provisioned with global
scope
> address for DHCPv6 server in the SP network (e.g., through RA option);
customer
> devices use unicast with global scope addresses to send Information
Request
> to SP DHCPv6 server
> 
> I envision this so that the CPE is the 'boundary' router for the DHCP
> administrative domains. where no DHCP traffic goes directly across. but,
I'm
> not sure this case is something we would prohibit. an operational choice I
> suppose. of course this would have to be restricted to stateless options,
as
> stateful ones would have to include coordination at the CPE. are there
also
> new security implications in doing this?
> 
> cheers,
> Ole
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Aug 2010 13:18:17 -0400

> If the client has been configured with an address of appropriate scope for the DHCPv6 server, and the client has assigned an address of appropriate scope to one of its interfaces, the client MAY se…

Why do you want this?   This is a very substantial change to the functioning of the DHCP protocol.   If you want this, it would not be an erratum--it would be a new specification.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Aug 2010 13:23:18 -0400

> you want the 6rd CE to acquire stateless DHCPv6 options. with todays specification it would have to run a local (as in inside the box) relay which the local client could talk to, to get around the…

You can't send a packet with a multicast destination through a tunnel?   The objection about having a relay agent in the CPE seems like a red herring--relay agents are not complicated.   I don't see any reason why we can't have one in a CPE device that's already doing 6rd.

> why couldn't we instead allow the DHCPv6 client on the 6rd CE to talk directly with the DHCPv6 server? (and if we made the requirement that the 6rd BR supported the DHCPv6 server, we could do it wi…

If you do this, it has implications beyond your use case.   It breaks every case where we actually want the relay agents to carry network mapping information through to the DHCP server so that the DHCP server can make accurate choices about which options to send back to the client.   So it's really a very major change to the protocol, not just a relaxing of an unnecessary rule.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Aug 2010 13:30:34 -0400

> messages to the DHCP relay agents in multicast.

This completely changes the state machine of the DHCP protocol.

> required to access DHCP servers through DHCP relay agents,

To be clear, these are not "special scenarios."   This is the default case, and it's that way because of operational difficulties we've run into in DHCPv4, which as Bernie says is a complete mess.   David Hankins is hard at work on a draft that attempts to recover some semblance of consistency out of the wreckage, but there's no clean fix.   To say that because it works in DHCPv4, it should be the default behavior in DHCPv6, is like saying that because you can use a blowtorch to trim your fingernails, you should also use it to cut your hair.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Aug 2010 13:35:06 -0400

> to explain where I'm coming from. there is a proposal to pass DHCPv6 server addresses in a DHCPV4 option to 6rd CPEs to use. then with a local client talking to a local relay that uses the global a…

The only context in which it makes sense for this option to be used is the case where you have a DHCPv6 relay in the CPE, and you want to configure it to unicast to the DHCPv6 server.   This is permitted by the existing protocol specification.   If you have a DHCPv6 *client* in the CPE, it is required to multicast.   Failing to do so will create problems when the DHCP server tries to figure out where in the network topology the client lives.

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Aug 2010 09:42:36 +0200

Ted,

> If you do this, it has implications beyond your use case.   It breaks every case where we actually want the relay agents to carry network mapping information through to the DHCP server so that the…

I don't quite see that. since in the case of a DHCP client one the CPE routing the message via a local DHCP relay also on the CPE. the source address of the DHCP packet would still be the same global address as if the DHCP client sent it directly.

but I see your point with regards to the existing solution (local client via local relay), and considering that both Bernie and you are strongly against this I'm going to concede defeat. (even without sulking too much. ;-))

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Aug 2010 13:52:27 -0400

> I don't quite see that. since in the case of a DHCP client one the CPE routing the message via a local DHCP relay also on the CPE. the source address of the DHCP packet would still be the same glob…

Right, in this specific case it seems unnecessary.   But in order to allow this case, we would have to write a detailed list of exceptions, and implementors would get it wrong.   Even as written, I've no doubt that we will see broken implementations.

> but I see your point with regards to the existing solution (local client via local relay), and considering that both Bernie and you are strongly against this I'm going to concede defeat. (even with…

Heh!

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 19 Aug 2010 11:25:35 +0800

> -----邮件原件-----
> 发件人: Ted Lemon [mailto:[email-masked]]
> 发送时间: 2010年8月15日 1:31
> 收件人: Xu Xiaohu
> 抄送: 'Bernie Volz (volz)'; [email-masked]; [email-masked];
> [email-masked]

The following is Bernie's recent opinion on the updated usage of unicasting
DHCP information-request messages. Would you explain other reason why you
strongly object this usage than the scenario mentioned by Bernie?
 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> What's your thought on this?

That's probably close to what might be acceptable. You'd have to get buy in
from the rest of the WG.

- Bernie?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> To be clear, these are not "special scenarios."   This is the default
case,
> and it's that way because of operational difficulties we've run into in
DHCPv4,
> which as Bernie says is a complete mess.   David Hankins is hard at work
on

If this was a complete mess in most (default) cases and it is totally
unacceptable, why not propose a change to the current DHCPv4 specification
so as to fix it?

Best wishes,
Xiaohu

> a draft that attempts to recover some semblance of consistency out of the
> wreckage, but there's no clean fix.   To say that because it works in
DHCPv4,
> it should be the default behavior in DHCPv6, is like saying that because
you
> can use a blowtorch to trim your fingernails, you should also use it to
cut
> your hair.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Aug 2010 10:57:59 -0400

> unacceptable, why not propose a change to the current DHCPv4 specification

That's what David is working on.

> strongly object this usage than the scenario mentioned by Bernie?

Bernie's suggestion (If I understand it correctly--maybe Bernie can correct me if I am wrong) requires a change to the DHCP state machine, which would not be backward-compatible.   So we'd have to have a really, really good reason to do it.   It also adds an extra round trip for clients that choose to unicast where multicast is required.

The reason I'm trying to explore other alternatives is that I'm not convinced that we need to make such a major change to the protocol in order to solve your problem.   I agree that you have a problem, and would like to help you solve it.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 19 Aug 2010 11:28:40 -0500

I was strongly opposed to this change.

I thought I could be persuaded that *if* a client has information from
another source that it is allowed to unicast Information-Request
messages, that we COULD look at supporting this. (By another source, I
mean either a Server-Unicast option or some configuration mechanism
outside of DHCPv6. And, this didn't exactly make it into the "proposed"
text, though by implication it is not possible to unicast a packet
unless you have a destination address!)

But, as Ted points out, this is a major change and we do need to proceed
carefully. Especially as RFC 3315, section 15, Message Validation
states:

   A server MUST discard any Solicit, Confirm, Rebind or
   Information-request messages it receives with a unicast destination
   address.

So, this isn't even a situation where unicast is EVER allowed today. (I
had, incorrectly, thought that we allowed unicast if Server-Unicast
option had been previously communicated, but Ted's email caused me to
review the text and also our server's code which strictly enforces
this.)

Personally, if it was up to me, I'd NOT make this change as I don't see
an overwhelming reason to do it. Yes, it might simplify things in a few
situations, but it can also be miss-used and cause more issues
elsewhere. (And, while it simplifies DHCPv6 in this one regard, the
complexity involved in the configuration has to be weighed against it --
both in terms of the implementation time as well as deployment issues.)
A basic relay agent is also very simple to implement; yes, I know that
nothing is as simple as it first seems!

So, I'm back where I started and think this is really a bad idea.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, August 19, 2010 10:58 AM
To: Xu Xiaohu
Cc: Bernie Volz (volz); [email-masked]; [email-masked];
[email-masked]

> strongly object this usage than the scenario mentioned by Bernie?

Bernie's suggestion (If I understand it correctly--maybe Bernie can
correct me if I am wrong) requires a change to the DHCP state machine,
which would not be backward-compatible.   So we'd have to have a really,
really good reason to do it.   It also adds an extra round trip for
clients that choose to unicast where multicast is required.

The reason I'm trying to explore other alternatives is that I'm not
convinced that we need to make such a major change to the protocol in
order to solve your problem.   I agree that you have a problem, and
would like to help you solve it.