Last Call Review of draft-ietf-dhc-v6only-03

Request Review of draft-ietf-dhc-v6only
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2020-07-02
Requested 2020-06-22
Requested by Éric Vyncke
Authors Lorenzo Colitti, Jen Linkova, Michael Richardson, Tomek Mrugalski
Draft last updated 2020-06-23
Completed reviews Secdir Last Call review of -03 by Russ Housley (diff)
Iotdir Last Call review of -03 by Pascal Thubert (diff)
Opsdir Last Call review of -03 by Sheng Jiang (diff)
Please review this I-D from the IoT point of view.

Your valuable input will be appreciated

Assignment Reviewer Pascal Thubert
State Completed
Review review-ietf-dhc-v6only-03-iotdir-lc-thubert-2020-06-23
Posted at
Reviewed rev. 03 (document currently at 06)
Review result Ready with Issues
Review completed: 2020-06-23


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


   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.