[dhcwg] Martin Duke's Discuss on draft-ietf-dhc-v6only-05: (with DISCUSS and COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-dhc-v6only-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-v6only/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Not so much an objection, but a question:

What would happen if, in response to a DHCPDISCOVER with the IPv6-only offer,
an attacker spoofed a DHCPOFFER with this option and a V6ONLY_WAIT value of
UINT32_MAX, when in fact there was no NAT64, or v6 capability, at all? Would
the very long timeout amplify existing DoS attacks on DHCP?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This seems like an important stepping stone to v6 adoption, so thanks.

Sec 3.1 In client-generated messages, what is in the "Value field"? I presume
this is one of those "client MUST set to zero and server MUST ignore" cases?

Sec 3.3
"If the client then
   issues a DHCPREQUEST for the address, the server MUST process it per
   [RFC2131], including replying with a DHCPACK for the address if in
   the meantime it has not been committed to another client."

What if it HAS been committed to another client? What then?