Last Call Review of draft-ietf-dhc-v6only-03
review-ietf-dhc-v6only-03-iotdir-lc-thubert-2020-06-23-00

draft-ietf-dhc-v6only-03 IOT-DIR review
_______________________________________

   This document specifies a DHCPv4 option to indicate that a host
   supports an IPv6-only mode and willing to forgo obtaining an IPv4
   address if the network provides IPv6 connectivity. It is very readable
   and provides a clear justification of why the DHCP-based solution is
   well suited to address the problem.



   "
                                             ... IPv6-only mode (either
   because the OS and all applications are IPv6-only capable or because
   the host has some form of 464XLAT [RFC6877] deployed),
   "
   Do we have a good reference of what we mean by the v6-only mode of a host
   - or an interface for that matter ?

   Else it would help to define it before we use it. Note, the terminology
   defines a "IPv6-only capable host" but not the "mode".




   "
   A DHCPv4 client SHOULD allow a device administrator to configure
   IPv6-only preferred mode
   "
   and later
   "
                                 In a typical deployment scenario, a
   network administrator would not configure the DHCPv4 server to return
   the IPv6-only Preferred option unless the network provides NAT64
   service.

   ...

   However it seems unlikely that any new transition technology would
   arise and be widely adopted in any foreseeable future.  Therefore
   adding support for non-existing technologies seems to be suboptimal
   and the proposed mechanism implies that NAT64 is used to facilitate
   connectivity between IPv6 and IPv4.
   "

   I have a hard time with that one. Adding a byte or 2 of flags in the
   IPv6-Only Preferred option to indicate that the network supports NAT64
   and having the host request the address if it needs the service and it's not
   there does not seem to cost a lot and protects the future.