Eliminating NAT makes virtual networking much hairier. E.g., my desktop is currently connected to a big enterprise network that keeps track of all devices and will only allocate one IP address per MAC address. That leaves no IPs for any VMs on my desktop to use, so they must go through NAT if they want to communicate with the outside world.

Are you talking about eliminating NAT on IPv4?

IPv6, set up the normal way, does not allocate IPs. Devices can and will have several at once and their VMs can easily get some too.

The enterprise corrupted IPv6 and disabled SLAAC so devices have to use whatever DHCPv6 gives them.

How does that work for android devices? I heard they don't allow dhcp provided addresses?

The Android problem only occurs in an IPv6-only enterprise network which is very rare. Otherwise Android can use IPv4.

Shouldn't the VMs have their own MACs?

If they're not routed directly through the network card but use a virtual switch instead, the network upstream only sees the server MAC. If they're directly hooked into the network card they can have their own MACs, but that approach can make it hard to communicate between host and VM.

Also, multiple MACs does not work with wlan.

Why would it not? There's even a third MAC address field in the 802.11 headers for just that scenario, as far as I remember (i.e. to distinguish between "802.11 source/destination" and "Ethernet-level actual source/destination").

You actually need to use special 4addr/WDS frames with 4 addresses[1]. However no one accepts these by default so it's unusable for a Laptop that you want to connect to random wlan networks.

[1] https://lore.kernel.org/netdev/1258465585.3682.7.camel@johan...

Hm, maybe I'm mixing up something here, but all I can say is that it works like this on my machine: I have a VM running in bridged mode, I'm connected to my home router using Wi-Fi, and I can see the virtual MAC address of the VM on the router management interface.

Possibly this is just at the DHCP level, though, and what the router sees just comes from my host MAC address? A quick packet trace suggests that.

That's definitely a limitation of your network. I don't see how ipv6 can shoulder any responsibility here.

Based on your description, you're using NAT as a means to bypass network restrictions. It's a great hack that will do the trick wonderfully, but if that's the officially proposed solution then the network is not set up for what it's actually used for.

Contrary to popular belief, IPv6 does have NAT, it's just stupid and unnecessary in most use cases. There are even different kinds of NAT; there's the "swap the public prefix with a private one" NAT (useful for shit ISPs that rotate your IPv6 prefix to make you pay extra for a static one, so your addresses don't keep changing), or the IPv4-like "masquerade all traffic when forwarding" one that'll work in your weird enterprise network.

With the latter option, you can set up an IPv6 with DHCPv6 on the upstream and whatever combination of SLAAC or DHCP you want on the VM side, and set up NAT using guides like this (possibly outdated iptables-based) one: https://forums.raspberrypi.com/viewtopic.php?t=298878

On Virtualbox you can set up ipv6 NAT with a few clicks btw.

> Based on your description, you're using NAT as a means to bypass network restrictions.

The threat model on this big enterprise WAN isn't "an authorized user creates a VM on an existing machine", but rather "some rando plugs something in with an Ethernet cable and goes to town on the intranet services". It has a whole web portal where you can log in and register your devices. So it's not like anything's really being bypassed here.

Anyway, I still prefer NAT for VMs over most passthrough schemes, which I've found unreliable even on IPv4 networks. What the outside network doesn't know about can't hurt it.

> The threat model on this big enterprise WAN isn't "an authorized user creates a VM on an existing machine", but rather "some rando plugs something in with an Ethernet cable and goes to town on the intranet services". It has a whole web portal where you can log in and register your devices. So it's not like anything's really being bypassed here.

Isn't that what the MAC filtering is for? I don't see the point of stopping a single registered MAC on a single port from having multiple IPs.

I might be misremembering some of the details (in fact, given that the web portal works, I think it might allow new devices to have local IPs, but bounce all outbound packets until they're registered), but however it works exactly, it does not like passthrough networking on VMs in practice.

(If I had to guess, just letting any machine have a million new IPs for the firewall to track has its own issues, so you'd end up with policies upon policies.)

In any case, sometimes middleboxes just don't behave precisely how we want them to, and that's why I'm skeptical of the typical IPv6 position of "a flat /64 network (or something emulating one) is all you'll ever need".

The firewall shouldn't have to track IPs, just the connections it would be tracking no matter what.

And sure a million IPs could cause problems, but that's not a good reason to set the limit to 1.

> I'm skeptical of the typical IPv6 position of "a flat /64 network (or something emulating one) is all you'll ever need".

That's not the position. You can have as many networks as you want. Connect them with routers like you would on IPv4.

If IT doesn’t want random things plugging into the network? That’s what 802.1x is for

You can do local NAT. Most VM hosts will do it. You just don’t need NAT everywhere anymore.

"Doctor it hurts when I". Keep track of all devices, and alloc a static /64 per (host) MAC.

And even in the face of a supposed malicious network admin like yours, you can still adopt IPv6, and use the IPv6 private network ranges for the VMs, and then do NAT like it's 1983, same as you would have otherwise done with IPv4, except that all other uses cases get easier, while this one use case remains as hard as it was before.

In general, the IPv6 stack is not supported on many smaller mcu. It is not that options like FreeRTOS can't support the stack, but rather the resource constraints pose a challenge.

That being said, most modern SoCs are competitively priced... and will boot Linux just fine for under $5/part. =3

Some of the new IoT protocols build on ipv6 natively.

The resource overhead is minimal for modern mcus. Dropping dhcp and arp can save a lot of resources too. Also I have mcus with more ram than my first pc.

Disabling IPv6 in ESP-IDF can save about 40KiB of flash and 2KiB of RAM. Not enough that I'd do it by default, but I've hit the limit of some of my hobbyist ESP32s to the point where I've disabled modules to cram my code in there.

Disabling IPv4 saves 25KiB of flash and less than a KiB of RAM. If you're down to the last kilobytes, disabling IPv6 makes more sense than disabling IPv4. Both options are choices of last resort, though.

A dual core 240MHz cpu with hardware paged flash and spi ram expansion support is not "small" in my opinion.

However, I am a fan of their price point for hobby projects. Best regards =3

Great question that I don't think the other commentors really answered. Sadly I don't really know "why" either. Second system effect?

Instead of making IPv6 just "IPv4 with 128bit instead of 32bit address space" the designers changed a bunch of things. NDP is new and different than ARP. ICMPv6 is extended and different. MLD instead of IGMP for multicast group membership. DHCP is extended and has a bunch of other alternatives, like SLAAC. IPsec is mandatory now.

All the new IPv6 protocols seem more secure, more powerful, and more efficient. So I guess that is "why". But I bet in an alternative history where backwards compatibility and the upgrade process were prioritized IPv6 would be a lot more widespread.