Skip to main content

DHCPv4-over-DHCPv6 (DHCP 4o6) Transport
RFC 7341

Yes

(Ted Lemon)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)

Note: This ballot was opened for revision 07 and is now closed.

Ted Lemon Former IESG member
Yes
Yes (for -07) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2014-05-26 for -08) Unknown
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.
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2014-06-19) Unknown
Version -09 resolves my questions; thanks for the clarifications!
Brian Haberman Former IESG member
(was Discuss) No Objection
No Objection (2014-05-27) Unknown
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.
Jari Arkko Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-05-27 for -08) Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (2014-05-28 for -08) Unknown
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?
Spencer Dawkins Former IESG member
No Objection
No Objection (2014-05-27 for -08) Unknown
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
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2014-05-27 for -08) Unknown
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.