[Ipoverib] comments on draft-ietf-ipoib-dhcp-over-infiniband-10.txt
"Barr Hibbs" <rbhibbs@pacbell.net> Fri, 10 March 2006 18:27 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHmKm-0004Oc-KL; Fri, 10 Mar 2006 13:27:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHmKl-0004OX-Az for ipoverib@ietf.org; Fri, 10 Mar 2006 13:27:27 -0500
Received: from smtp103.sbc.mail.mud.yahoo.com ([68.142.198.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHmKj-0007Vx-Sl for ipoverib@ietf.org; Fri, 10 Mar 2006 13:27:27 -0500
Received: (qmail 56573 invoked from network); 10 Mar 2006 18:27:24 -0000
Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@71.139.191.225 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 10 Mar 2006 18:27:24 -0000
From: Barr Hibbs <rbhibbs@pacbell.net>
To: IP over IB Working Group <ipoverib@ietf.org>
Date: Fri, 10 Mar 2006 10:27:23 -0800
Message-ID: <EJEFKKCLDBINLKODAFMDKEFEIBAA.rbhibbs@pacbell.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: vivk@us.ibm.com
Subject: [Ipoverib] comments on draft-ietf-ipoib-dhcp-over-infiniband-10.txt
X-BeenThere: ipoverib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rbhibbs@pacbell.net
List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipoverib@ietf.org>
List-Help: <mailto:ipoverib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipoverib>, <mailto:ipoverib-request@ietf.org?subject=subscribe>
Errors-To: ipoverib-bounces@ietf.org
I just became aware of this draft, so please forgive the late response. --Barr Section 2.1, "IPoIB specific usage of DHCP message fields" "htype" (hardware address type) MUST be 32 [ARPPARAM] -- a better reference for the hardware address type would be http://www.iana.org/assignments/arp-parameters "hlen" (hardware address length) MUST be 0. -- I strongly disagree: just because the hardware address does not fit in the 'chaddr' field is not a good reason to put the "wrong" value in the length field. "chaddr" (client hardware address) field MUST be zeroed. -- While I understand that the IP over InfiniBand Architecture document specifies that a link-layer address is composed to 4 octets of Queue Pair Number and 16 octets of Global Identifier, is there any value (read: makes the operation of relay agents or other networking components easier or simpler) to inserting the 16-octet GID as the 'chaddr?' My concern is that some devices might treat 0 as an invalid value for 'chaddr.' -- Of course, if the GID were used for 'chaddr' then the value of 'hlen' should be 16, which conflicts with my statement above. I've no simple solution to that conundrum. "client-identifier" option MUST be used in DHCP messages. -- while this is probably the only choice for identifying a client uniquely, there are a few issues with it: (a) host system processes using DHCPINFORM messages to request additional parameters do not use the client identifier option at all. (b) some DHCPv4 servers may be configured to ignore the client identifier option. (c) many DHCPv4 servers use the 'htype' and 'chaddr' fields exclusively, ignoring the client identifier option, when assigning fixed IP addresses to "known" or "registered" clients The "client-identifier" used in DHCP messages MUST conform to [DHC_3315id]. -- this reference should be updated to RFC 4361. -- despite the text in section 6.5 of RFC 4361, a DHCPv4 server should not expect that all client identifiers received from clients will conform to RFC 4361. As a result, the client identifier SHOULD continue to be treated by a DHCPv4 server as an opaque value. Section 2.2, "Use of the BROADCAST flag" A DHCP client on IPoIB MUST set the BROADCAST flag in DHCPDISCOVER and DHCPREQUEST messages (and set "ciaddr" to zero) to ensure that the server (or the relay agent) broadcasts its reply to the client. -- This is not quite correct. The client SHOULD set the BROADCAST flag in DHCPDISCOVER and DHCPREQUEST messages sent from the INIT or SELECTING states if it cannot receive unicast messages before being configured with an IP address. -- Clients restarting with a previously assigned IP address enter the INIT-REBOOT state and while RFC 2131 specifies that they broadcast DHCPREQUEST to the local broadcast address, they SHOULD NOT set the BROADCAST flag: if the server verifies that the requested IP address had been previously assigned to the client and there is time remaining before the lease expires, then the DHCPACK message may be unicast to the client IP address. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib