Feature request: support for /32 DHCP allocations

[XioNoX]

Hi,

Thanks for iPXE, I'm slowly getting familiar with it.

On Linux it's possible to assign a /32 v4 IP to an interface (usually for VMs) with a specific route for outbound traffic. This allows to efficiently use IP space, without having to rely on tricks like proxy ARP.
For example on the VM side I can have inet 10.192.24.3/32 scope global ens13
As well as

# ip route
default via 10.192.24.1 dev ens13 onlink 
10.192.24.1 dev ens13 scope link

Then on the hypervisor side inet 10.192.24.1/32 scope link tap0
and 10.192.24.3 dev tap0 proto static scope link
(Note that the gw IP doesn't have to be from the same prefix as the VM IP)
This works very well.
It's also possible to have ISC-DHCP hand out DHCP offers compatible with that setup, see for example this blogpost.

The problem I'm facing is at the iPXE step. When DHCP offers such IP config to the client, iPXE accepts (see the /32 IP) it but then can't fetch the debian-installer files.

You can find some more of my troubleshooting steps (and DHCP exchange on this task comment.

Please let me know if I'm doing something wrong or if it's indeed a bug/missing feature. Happy to help, but I don't know C enough to send a PR :(

Cheers,

[NiKiZe]

This has been up for discussion before. (But can't find the post)
It is not a bug, limited ability to implement it in small code size.
Is there any RFC that defines this? I would agree that in a perfect world iPXE should have support for /32 on legacy IPv4, on the other hand, is it worth it? Why not use IPv6 with possibly NAT64 and DNS64 instead?

[XioNoX]

Thanks for your quick reply !

I couldn't find any RFC, but this behavior seems to be used widely, at least in VM environments. The previous discussions seems to show that there are interests in this feature.

I can't speak for other use-case, but in ours there is the constraint of the existing provisioning process (for both VMs and bare-metal). All of our infra is dual stacked (we participated to the IPv6 launch day 😃 ), we unfortunately can't get rid of v4 anytime soon. And all the provisioning is done with IPv4 first. Obviously if we had to start it from scratch it would be v6 first, but the unfortunate reality is that especially in the DC, v4 is going to last quite some time...

Note that even with an IPv6 only infra, the same usecase needs to be solved, but I don't know if DHCP handles it the same way during the allocation.
ip -6 route add 2620:0:860:140:10:192:24:3 proto static dev tap0 on the hypervisor
ip -6 addr add 2620:0:860:140:10:192:24:3/128 dev ens13 on the VM
ip -6 route add default via fe80::2022:22ff:fe22:2201 dev ens13 on the VM
Using a /64 raises the same issue than requiring proxy ARP on a routed environment, but this time with NDB 😃
Implementing /128 v6 could maybe be a good middle ground as future proof ? Even though not ideal for us. I don't know the complexity of such features, so I don't want to risk downplaying it.

Thanks ! I hope this helps. Happy to chat over IRC or email if more suitable.

[MalteJ]

+1

I can confirm the problem with IPv6: When the RA does not contain an ICMPv6 prefix information, iPXE should configure with the address from DHCPv6 with a /128 prefix length and add the default route as advertised by the RA. Instead iPXE configures the DHCPv6 assigned IP with a /64 subnet and the default route is not configured.

CC: @mcb30

[wfleurant]

additional information here. case is when iPXE boots off of say, a /24 and then the vlan switches from a /24 network to one handing out /32 networks. from iPXE shell you then run dhcp and you see a /32 network and gateway are installed. so at this point routing does not work.
a hack is to change netmask eg; set net0/netmask 255.255.0.0