DHCPv4-over-DHCPv6 (DHCP 4o6) Transport
draft-ietf-dhc-dhcpv4-over-dhcpv6-09

Sections 6 and 7:
It seems odd that "option-code" appears in the legend of the diagrams in each of these sections, but not in the diagrams themselves (e.g., it seems like the first field in each diagram should be "option-code" rather than the code itself).

Section 9:
"When a DHCPv6 relay agent receives a DHCPv4-query message, it may not
   recognize this message.  The unknown message can be forwarded as
   described in [I-D.ietf-dhc-dhcpv6-unknown-msg]."

I'm curious why this behavior of relays is not normatively required. That is, this text seems to leave it up to the relay implementor to decide whether to forward or drop messages with unknown message types, even though forwarding them seems like the preferred behavior.

Section 10:
s/which the server using/which the server is using/ 

s/use "flags" field/use the "flags" field/

Section 11:
Is there another document you can point to that discusses how a host increases its susceptibility to fingerprinting when it gets configured with both v6 and v4 addresses? Seems like that would be a useful reference here.

Version -09 resolves my questions; thanks for the clarifications!

I support Stephen's point on having a better description of the use case.  It will not benefit the DHCPv6 implementer who is coding this, but it would provide the justification for this option.

I support and am following several of  Stephen, Alissa, and Brian's DISCUSSes and comments.  The other comments seem to be encapsulated in those.  I don't think I have anything to add.

I agree with others that the use case for this document is not entirely clear.  Perhaps it would help if you could give an example of how the host would use some of the information in the DHCPv4 payload.  Would it send IPv4 packets directly on the link?  Would it have to use a tunnel?  Is the expectation that the tunnel would be configured somehow via DHCPv6?

Just as a high-order bit, is there any reasonable concern that this new functionality would increase the chances of fragmentation? I'm guessing you're nowhere near a place where that's going to be a problem, but TSV guys ask ...

9.  Relay Agent Behavior

   When a DHCPv6 relay agent receives a DHCPv4-query message, it may not
   recognize this message.  The unknown message can be forwarded as
   described in [I-D.ietf-dhc-dhcpv6-unknown-msg].

I'm slightly confused here. The next paragraph isn't "additionally", is it? Perhaps "If it recognizes the message ..."?

   Additionally, the DHCPv6 relay agent MAY allow the configuration of a
   dedicated DHCPv4 over DHCPv6 specific destination address(es),
   differing from the address(es) of the DHCPv6-only server(s).  To
   implement this function, the relay checks the received DHCPv6 message
   type and forwards according to the following logic:

I have the same question that Brian included in his Discuss: "2. How does the client know to include the 4o6 server address option?  Is it triggered by the failure of DHCPv4 to receive configuration data?  In other words, what bootstraps the insertion of this option?  If it is a failure to receive a DHCPv4 response, shouldn't that be pointed out?"

Finally, I'm watching the conversation on Barry's Discuss, and just to chime in - if the authors could add something like Barry's set of if statements covering just enough of a normal request to result in an IPv4 address being allocated, that would have been helpful to me, but I wouldn't encourage you to go as far as anything like lease refreshes, etc.

So ... do the right thing :D

This was a discuss point. I'm ok if its looked at separately
as a generic leakage/linkage thing, but it'd be good to
look at.

(1) I think you need to note any cases where this
mechanism could lead to new leakage of the mapping
from an old IP address/lease to a new one, when a
client moves network. Shouldn't there be some case
where the client ought not try renew such a lease,
e.g. if the DHCPv6 server is known to be different
from the one used to get the DHCPv4 lease? Or is
that too hard?

--- OLD comments below

- The use-case for this isn't very clear to me from
the text. But that's ok, I assume its clear to
others.

- BOOTP could do with a reference. (Is that RFC951?)
Saying that BOOTP messages "can also be transported"
is pretty ambiguous - do you mean that
clients/servers are supposed to support other BOOTP
messages or not?

- 5.3: I like the MBZ field definition - its succinct
and clear. Be good to see that copied in other specs.

- Section 8, last para: are you saying here that all
clients MUST send a client identifier?  I wasn't
clear. (I assume there's no point in trying to get
this draft to recommend random or more privacy
friendly values in that field?:-) 

- Section 11: I don't get the security implications
of this form of tunnelling - has someone looked at
whether or not any of the many DHCPv4 options might
be problematic when transferred in DHCPv6? If so,
that doesn't come across at all from the security
considerations. And it could be the case that that's
ok, or not. I'm just asking if someone has looked at
that.