[dhcwg] AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6
Ted Lemon <mellon@fugue.com> Fri, 11 April 2014 15:30 UTC
Return-Path: <mellon@fugue.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD95B1A06E7 for <dhcwg@ietfa.amsl.com>; Fri, 11 Apr 2014 08:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.527
X-Spam-Level:
X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7DmyCw6fdAk for <dhcwg@ietfa.amsl.com>; Fri, 11 Apr 2014 08:30:04 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 11D5E1A069B for <dhcwg@ietf.org>; Fri, 11 Apr 2014 08:30:04 -0700 (PDT)
Received: from [IPv6:2001:470:88a3::b8bd:1281:669e:a254] (unknown [IPv6:2001:470:88a3:0:b8bd:1281:669e:a254]) by toccata.fugue.com (Postfix) with ESMTPSA id B915D2380CB4; Fri, 11 Apr 2014 11:30:00 -0400 (EDT)
From: Ted Lemon <mellon@fugue.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Apr 2014 11:29:58 -0400
Message-Id: <B36DAF7C-EDA6-427E-B918-FB8F4D3ED6F5@fugue.com>
To: draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/MNLPN-iOoEJ01WMR19Lps8k-NKQ
Cc: DHC WG <dhcwg@ietf.org>
Subject: [dhcwg] AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Apr 2014 15:30:07 -0000
Page 4, paragraph 3: OLD: DHCP clients may be running on CPE devices, end hosts or any other device that supports the DHCP client function. At the time of writing, DHCP clients on CPE devices are comparatively easier to modify than those implemented on end hosts. As a result, this document uses the CPE as an example for describing the mechanism. This does not preclude any end-host, or other device requiring IPv4 configuration, from implementing DHCPv4 over DHCPv6 in the future. NEW: DHCP clients may be running on CPE devices, end hosts or any other device that supports the DHCP client function. This document uses the CPE as an example for describing the mechanism. This does not preclude any end-host, or other device requiring IPv4 configuration, from implementing DHCPv4 over DHCPv6 in the future. The assertion that CPE devices are easier than hosts isn't precisely true, although I understand what you mean. In any case, it's not necessary to say this, and it's likely to get a DISCUSS, so why not just take it out? :) In section 7: A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST message to either a broadcast or unicast address depending on its state. For example, a client in the RENEWING state uses a unicast address to contact the DHCPv4 server to renew its lease. A client in the REBINDING state uses a broadcast address. If there is a DHCPv4 relay agent in the middle, a client in the RENEWING state may send a DHCPREQUEST message to the unicast address of the relay agent. In such a case, the server is unable to determine whether the client sent the message to a unicast or broadcast address and thus the server may be unable to correctly determine the client's state. [RFC5010] introduced the "Flags Suboption" that relay agents add to relayed messages to indicate whether broadcast or unicast was used by the client. You say that the client unicasts to the relay agent in the RENEWING state, but it actually unicasts to the DHCP server. Last paragraph on page 9: The server MAY include the 4o6 Server Address option in its response to the client. If the client receives this option, it MUST enable the DHCPv4-over-DHCPv6 function. The client MUST NOT enable the DHCPv4-over-DHCPv6 function if the server does not include the 4o6 I think you should say "If the client receives this option, it enables the DHCPv4-over-DHCPv6 function." I don't think you need a MUST there. The MUST NOT is necessary, however. Same paragraph, top of page 10: Server Address option in its response. If the client does not receive this option and DHCPv4 over DHCPv6 is already enabled, the client MUST disable the DHCPv4-over-DHCPv6 function. This is underspecified—a client may be talking to more than one DHCPv6 server, and may have more than one DHCPv6-derived configuration active at the same time. I think you need something like this: Server Address option in its response. If the DHCPv6 configuration that contained the 4o6 Server Address option subsequently expires, the client MUST disable the DHCPv4-over-DHCPv6 function. If, when the DHCPv6 configuration that contained the 4o6 Server Address option is renewed, the renewed configuration does not contain a 4o6 Server Address option, the client MUST disable the DHCPv4-over-DHCPv6 function. It is possible in a multi-homed configuration for there to be more than one DHCPv6 configuration active at the same time that contains a 4o6 Server Address option. In this case, the configurations are treated as being independent, so that when any such configuration is active, a DHCPv4-over-DHCPv6 function may be enabled for that configuration. An implementation may also treat such configurations as being exclusive, such that only one is kept active at a time. In this case, the client keeps the same configuration active continuously as long as it is valid. If that configuration becomes invalid but one or more other configurations remain valid, the client activates one of the remaining valid configurations. Which strategy to follow is dependent on the implementation: keeping multiple configurations active at the same time may provide useful redundancy in some applications, but may be needlessly complex in other cases. Please let me know what you think. I would like to last-call this document once we've addressed the above issues.