Thread (71 messages) flat view 71 messages, 10 authors, 2012-09-04

Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2012-08-12 14:06:27

On Thu, Aug 09, 2012 at 07:06:46AM +0300, Or Gerlitz wrote:
Eric W. Biederman [off-list ref] wrote:
quoted
Or Gerlitz [off-list ref] writes:
quoted
quoted
To put things in place, DHCPv4 is supported with eIPoIB, the DHCP
UDP/IP payload  isn't touched, only need to set the BOOTP broadcast
flag in the dhcp server config file.
quoted
Wrong.  DHCPv4 is broken over eIPoIB. Coming from ethernet
htype == 1 not 32 as required by RFC4390
hlen == 6 not 0 as required by RFC4390
The chaddr field is has 6 bytes of the ethernet mac address not the
required 16 bytes of 0. The client-identifier field is optional over ethernet.
An ethernet DHCPv4 client simply does not generate a dhcp packet that
conforms to RFC4390.

Therefore DHCPv4 over eIPoIB is broken, and a dhcp server or relay
may reasonably look at the DHCP packet and drop it because it is garbage.

You might find a forgiving dhcp server that doesn't drop insane packets
on the floor and tries to make things work.
Under the eIPoIB design, the VM DHCP interaction follows
Ethernet DHCP, and not the IPoIB DHCP (RFC 4390).

The DHCP server has no reason to drop such packets.

DHCP is a L7 (L5 to be precise) construct, I don't see
why that the fact IPoIB DHCP RFC exists, means/mandates
the DHCP server to care on the link layer type.

Or.
For example DHCP server could be configured with
HW address/IP address table.

-- 
MST
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help