rfc-4390

Dynamic Host Configuration Protocol (DHCP) over InfiniBand

V. Kashyap

date2006-04 streamIETF areaint wgipoib statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc4390 doi10.17487/RFC4390

IP over Infiniband (IPoIB) link-layer address is 20 octets long. This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol (DHCP/BOOTP) message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. [STANDARDS-TRACK]

Extracted elements (10)

design-rationale §1

The IPoIB link-layer address is 20 octets long, which exceeds the 16-octet 'chaddr' field in DHCP/BOOTP messages. This size mismatch makes it impossible for a DHCP server to unicast a reply to a client that has not yet been assigned an IP address, necessitating the use of broadcast replies and a surrogate client identifier.

ip, security

design-rationale §2

To desynchronize the burst of broadcast responses at subnet startup, RFC 2131 recommends that clients wait a random time (1–10 seconds) before initiating server discovery. This same random delay naturally spreads out DHCP server broadcast responses triggered by the mandatory use of the BROADCAST flag over IPoIB.

interoperability-note §2

RFC 1542 discourages broadcast replies in DHCP, but for IPoIB broadcast is a necessity because the server cannot receive the client's link-layer address via 'chaddr'. Implementors MUST override the RFC 1542 guidance in this context.

normative-requirement §2.2 MUST

A DHCP client on IPoIB MUST set the BROADCAST flag in DHCPDISCOVER and DHCPREQUEST messages and set 'ciaddr' to zero, to ensure the server or relay agent broadcasts its reply when the client does not yet have an IP address.

normative-requirement §2.1 MUST

A DHCP client operating over an IPoIB interface MUST include the 'client-identifier' option in all DHCP messages to provide a unique client identifier in lieu of 'chaddr'.

normative-requirement §2.2 MUST NOT

During BOUND, RENEWING, or REBINDING states, the DHCP client MUST NOT set the BROADCAST flag; instead it MUST fill 'ciaddr' with its IP address so the server can unicast DHCPACK, with the link address resolved by ARP.

normative-requirement §2.1 MUST

The 'client identifier' used in DHCP messages over IPoIB MUST conform to RFC 4361 (Node-specific Client Identifiers for DHCPv4), which defines a stable, node-specific identifier format.

protocol-element §2

The 'client-identifier' DHCP option (RFC 2132) carries a type-identifier pair. Over IPoIB, this option replaces 'chaddr' as the unique client identifier; when a hardware address is used, the type field should be an ARP hardware type from the IANA registry.

ip, registry

security-consideration §3

RFC 4390 introduces no new security issues beyond those already described in RFC 2131. All security considerations for standard DHCP apply equally to DHCP over IPoIB.

security, ip

wire-format §2.1

The 'chaddr' field in a DHCP/BOOTP message is 16 octets in length, while the IPoIB link-layer address is 20 octets (per RFC 4391). When used over IPoIB, 'chaddr' MUST be zeroed, 'hlen' MUST be 0, and 'htype' MUST be 32.