Last Call Review of draft-ietf-dhc-dhcpv4-over-dhcpv6-07
review-ietf-dhc-dhcpv4-over-dhcpv6-07-opsdir-lc-baker-2014-05-03-00

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

I’ll note that on first reading, I questioned the authors on the merits of the
fundamental proposal. In short, if the user needs IPv4 configuration and IPv4
is provided as an overlay on IPv6, why not use the overlay for IPv4
configuration questions? They adequately answered my questions; in short, that
in many cases calls for changes to the IPv4 overlay, and this is operationally
simpler.

Simple is good, even when counterintuitive. To me, the “intuitive” approach
would have been to relay the IPv4 DHCP message to the server in question,
perhaps in a 4o6 tunnel/encapsulation, or to assign option numbers in such a
way that the IPv4 and IPv6 options are readily distinguishable.

An example of the scenario in question is a dual-stacked residential customer
of a broadband IPv6-only ISP. Presume, if you will, that the managed CPE
performs a translation: prefixes in 2001:db8::/n are allocated to the customer,
up to 2^n-1 of those are used as per-LAN subnets within the domain, and the
remaining one is a translation subnet whose IID contains the IPv4 address,
which is itself presumably similarly subnetted. Hosts within the residential
network none-the-less require IPv4 addresses, the IPv4 address of their DNS
server, and other configuration data. The proposal is to carry the DHCP/IPv4
request in toto in a field of a DHCPv6 message, enabling the CPE to “simply"
forward the DHCP request to the server, and disencapsulate the response to
present it to its requestor.

It does, in fact, work.

The one comment I would really make is that the service is described as being
provided by a residential CPE. While that is a common case, I see no reason to
believe that an enterprise network that is in the process of transition might
not be IPv6-only in part and IPv4-only or dual stack in part, and the IPv4 part
might not need to reach its server across the IPv6-only domain. Hence, personal
preference might lead me away from referring to a “CPE” to an “IPv6-only” and
an “IPv4-capable” domain and a router capable of encapsulating the DHCP message
leaving the IPv4-capable domain to the (presumably-IPv6-only) DHCP server. The
result might be largely the same. To be honest, actually responding to this
comment will require some surgery, and I think operators will figure out how to
use this in the enterprise case. If the draft is revised per other IESG/AD
comments, it would be nice to see this change as well. I don’t think it is
required for publication.

If there are no other comments requiring an update, I would call this draft
“Ready”; the necessary information is there. If there is an update, it is
“Ready with issues”, and this is my issue.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail