Can you say more about why the IpAddress type needs align(4)? The current definition as a union is intentionally done that way to match edk2 and the UEFI spec. (Note that the spec briefly describes it under data types in a way that sounds like it's just a [u8; 16] buffer, but it's later fully defined in a kind of hidden spot under EFI_PXE_BASE_CODE_PROTOCOL as a union.) There are two issues with it being a [u8; 16] wrapper:

• The align(4) would prevent it from being used in a repr(packed) type (at least until [RFC] Allow packed types to transitively contain aligned types rust-lang/rfcs#3718 is resolved)
• It could lead to UB. If C code initializes a EFI_IP_ADDRESS via the v4 member, and then we cast that to an IpAddress struct, the last 12 bytes will contain uninitialized data, which is not allowed.

Ah, interesting. I actually wanted to make it a struct and drop the union. If always all bytes are initialized, some things get much easier. But I didn't know the problem with packed wrappers.

Counter idea: we keep the union but make the fields private. Via a public constructor we can ensure that always all bytes are initialized, even for v4 addresses.

What do you think about this?

I think uefi-raw is the wrong place for that abstraction, it should simply match the C API as close as possible and be public. In uefi, we should drop IpAddress and replace with core::net::IpAddr as discussed in #1575.

it should simply match the C API

While I definitely see this as perfectly fine for the majority of the code base, I believe that this may be a valid exception. Preventing undefined bytes here would be a low-hanging fruit.

I don't have a very strong opinion, but a tendency. Let me continue my "experiments" to simplify and improve the network code and then I'd leave some more comments on this.