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

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-dhc-dhcpv4-over-dhcpv6-07-opsdir-lc-baker-2014-05-03

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