The IPv6 Transition

I had to reluctantly deploy ipv6 on my home network because of ISP requirements + will to use pihole.

Ipv6 is hard. I had to learn quite a bit to make it work and not only I see no value, but it is significantly more difficult to use dire to the address length.

I think IPv6 is a missed opportunity, it was probably designed by experts that did not take into account the population that will use it (not the one users who do not care, but the layer above them)

What requirement could an ISP impose on you for you to be forced to migrate the intranet to IPv6 (because of PI-hole)?

You could always place a small NAT-enabled router between your ISP's device and your home network.

The only problem I could see would be the lack of a (semi-)static public IPv4 address, which one could solve by renting a VPS.

My ISP is the French "Free". They provide a router that is difficult to swap with my own (it is possible, but it is way easier to switch it to a bypass mode). With this router comes a TV box that requires IPv6 to work.

When I replace DHCP/DNS with Pihole I need to account for that. While this is not a complex setup once you understand IPv6 you still need to learn it.

I work in IT so I tried to get myself to IPv6 several times but never had any reason to do so (despite self-hosting a lot and generally being a nerd). I had to do that this time and my uninformed opinion is that it could have been done so that it is much simpler for advanced users (but not yet networking experts)

I struggled to get IPv6 running on my home network, then had issues with DNS dual stack once I got it going, so I turned it off.

That said, I think the difficulty of IPv6 is in the UI of the home routers that implement it, and a lack of sane defaults.

The ISP should give every SOHO/residential customer a /60. The router of a simple IPv6 should do prefix delegation. The router should default to SLAAC for local IP addresses, and configuring DNS with Router Advertisements. And residential routers can be set up to have an internal DNS server which populates the ".internal" domain with hostnames from the network.

As a network admin, you have to learn new things like the uses of IPv6 multicast, and ND, the lack of ARP, and some other things. Home users shouldn't have to care about that.

>The ISP should give every SOHO/residential customer a /60.

The ISP should give every residence 295 quintillion IPv6 addresses? I know there is an abundance of ipv6 addresses but that seems like a lot of waste.

Even assigning a /96 would provide 4.3 billion ipv6 addresses (which is the same number as all ipv4 addresses in existence)

And since available ipv6 space is basically 4.3 Billion^2, assigning an ipv6 /96 would be like assigning a /32 in ipv4 terms of total ipv6 space utilization.

/64 is needed for SLAAC to work and is basically the default.

Anything larger (usually /56, sometimes even /48) gives the customers a chance to segment their LAN.

Like other person said, /64 is the minimum subnet size. And submitting in ipv6 is best done 4 bits at a time. A /60 is overkill for residents, but because it gives 16 subnets, not because it gives excessive addresses.

That's not how you're supposed to use IPv6. It would just be 64 bits if that was the case. Instead, 99% of the time, it's a 64 bit subnet ID and a 64 bit device ID.

Sorry, but under no circumstances should an ISP router auto route internal computers from the network. Thats just going to expose so many internal services, most consumers wouldn't even know they were running in the first place.

If we are to have a transition to IPv6, and I am very much in favour of this, then by all means make the addresses be globally routable, but force people to select the ports and addresses to be shared in their router. Otherwise we end up with another mess ala "open wifi".

It doesn't need to, IPv6 has unique local addresses which is are non-globally reachable; I recall those had it's own can of worms depending on deployment but it's an option for private, local addresses.

EDIT: I also understood the GP comment to be getting around the problem of long IPv6 addresses and not actually making every machine globally accessible.

I didn't think I suggested an open firewall.

Just as today people have to adjust NAT as kind of an implicit inbound policy, a proper home IPv6 router defaults to drop for inbound traffic.

There's no minimum subnet size.

That's literally the ISP's and router's job: get packets from A to B.

Now, a home router should probably have a stateful firewall that's on by default, but that's a different matter.

/64 acts as a soft limit due to the prevalence of SLAAC. Which is good in a way, since it means ISPs have to give out at least /64, which means you're always able to subnet (although you can't use SLAAC and must use static addresses or DHCP) unlike IPv4 where you have to pay for extra addresses.

So you had to learn IPv6 the same way you learned IPv4. The question is: was it harder ? It seems you wanted to know IPv6 without learning it because you thought it would be the same as IPv4. And yes the Free boxes are hard to work with if you don't want to mess with vlan and still have TV services.

The purpose of SLAAC intends to have many customers in one /64 network though.

The biggest design failure of IPv6 is that it was not designed to be backwards-compatible with IPv4. Technologies with established user bases need to evolve with backwards compatibility if they want to take advantage of existing network effects.

This comment shows up like clockwork.

How does a device with a 32-bit-sized addressing scheme construct an IP packet to a device with an address in a 128-bit-sized addressing scheme?

No, just many devices.

You can DoS your whole subnet by pretending to be a billion devices. In IPv4 you can do it by occupying all the IP addresses. Therefore putting several customers on one network is a bad idea, just like in IPv4.

"Auto routing" is fine, as long as there is a firewall.

Yes, you can't use SLAAC feature, but there's no subnetting limit in IPv6. Any subnet size works.

Writing to you from /72.

The purpose of SLAAC is to make it "easy" for a client to get onto the network without something like a DHCP server tracking addresses. If you set it up, it generally just works.

You're technically correct, but ISPs best practice is to hand out a /64.

Previously it worked by putting the MAC address in the last 64 bits.

Yes, that was before privacy extensions. It hasn't been like that (in most implementations) for a very long time.

It could work like 4 socks requests wrapped in each other like onion. But LAN services wouldn't need to care about long addressing as they don't need to cross network boundary, while letting everything else use new approach, so you could use old stuff without changing anything and there would be no need for new ip6 drivers with new vulnerabilities that are yet to be fixed.

And you get no privacy if /64 prefix is a stable identifier of one customer.

This doesn't seem like an IPv6-specific issue. For most broadband customers, your external IPv4 address is also generally stable. Mine hasn't changed in years.

I think this misses the point. An IPv4-only home network has a lot of benefits, simplifying whatever you to in it which relies on IP addresses which you'll have to handle manually in code and databases.

His scenario is really a PITA, where he's basically forced to migrate to IPv6 only because of IPTV. There might have been a solution by creating an IPv6-only VLAN just for the TV, while keeping the rest at legacy, but it's not really trivial.

IPTV with Deutsche Telekom is also a pain, because they feed it in a separate VLAN and the routers and switches need to handle IGMP messages properly (IGMP proxy, IGMP snooping).

I think the main difference is that when I learned IPv4, pure-v4 was sufficient. Today, you can't run a pure-v6 network; you have to deal with both. The closest you can get is NAT64, which 1. doesn't always work, and 2. is still annoying to manage. (Which sucks, because doing just v6 would be nice)

I also appreciated how much the linked article is adamant that IPv6 is what you get when all you do is increase the addressing size. There were wilder alternatives discussed that broke more things or took a more progressive stance. Part of the "there's no compelling 'use case' for IPv6" is that it really doesn't do anything new or exciting, it just increased the address size, and then dealt with the consequences (including "lack of backward compatibility", that was always going to be a consequence of increasing the address size).

There have been tunneling protocols and systems for IPv6 since nearly the beginning of IPv6. The ability to tunnel it hasn't solved all the "backwards compatibility" complaints for IPv6.

Same for network address translation, both NAT46 and NAT64 standards have existed for a while now and that also hasn't solved the "backwards compatibility" complaints for IPv6.

But no v4 devices support this "four socks requests wrapped like an onion" thing you're proposing, so how would they work with it?

Socks goes on application layer, hardware sees it as normal tcp/ip4.

Presumably NAT46 still requires most things like middle boxes to upgrade to ipv6, and also somehow needs to squeeze ipv6 addresses into ipv4 addresses, which is only a temporary solution at best.

If addressing is two layer, e.g. NAT is 1.1.1.1 and everything behind it is in 10.0.0.0/8 network (cloudflare could use this scheme while having only one top level address), then you can use existing socks support without any new hardware or software.

My understanding is NAT46 is very nearly the same as NAT44 ("traditional NAT" between IPv4 and IPv4), using tricks like (but sometimes different from) SOCKS and UPnP and fake port numbers to accept incoming connections for one (or more) IPv4 addresses to pretend to be/delegate to some number of IPv6 consumers behind it. It doesn't solve general routing of any IPv6 address, just specific addresses routing via an IPv4 proxy.

To my understanding, the difference between NAT44 and NAT46 is really hard to spot in practice and somewhat "just" a distinction of whether or not the NAT in question thinks of its IPv6 subnet or IPv4 subnet as "primary". I've heard some major consumer-side routers quietly upgraded to NAT46 as "primary" because it does lend itself to better consumer experiences. Also I've heard some CGNAT (Carrier Grade NAT) is easier to build when considered as NAT46 than NAT44 (as awful as CGNAT is as a general thing).

NAT46 is absolutely a standard designed to be a temporary solution. It's just about the exact same ugly temporary solution as NAT44. (Or at least as NAT44 was supposed to be. The continued confusion of NAT44 as a security measure will probably keep NAT44 still in use long after its problem disappears and its temporary transition window has expired.)

(NAT64 is the interesting one that may not be as temporary as networks move to IPv6-only single stacks. Some cell carriers have already moved in that direction.)

Applications don't support it either, and if the hardware is seeing normal v4 then you're limited to sending to v4 destinations. How is this helping?

It would help everything else, applications are not the only part of the network (and many already support socks), there are middle boxes, DHCP, NAT, firewalls, reverse proxies, LAN services and what not that don't need to be aware of new addressing scheme. Firewalls might benefit from it, but even they would still mostly work, even if with less than perfect precision. And even applications can benefit from simplification due to absence of dual mode sockets and no need for two sockets to listen on 0.0.0.0 and [::].

NAT44 translates only client addresses, leaving server addresses intact, NAT46 has to translate both client and server addresses, which can be taxing if there are more servers than clients behind NAT, which is further exacerbated by server farms as each domain now has several addresses. Well, if clients connect only to facebook and google, that's only two addresses to translate.

I don't think you can use port numbers to disambiguate between servers as clients will connect to port 443 for https.

I’m curious what your home network involves that’s more complicated than simply plugging everything in to one cheap router.

My network is not particularly complicated. It is the ISP router that manages the biber connection (FTTH). So I have to have that specific ISP provided box, which offers me some more or less crappy features (DNS, DHCP, ...).

If I want to use Pihole for DHCP (because it handles internal registration well) and DNS (because if offers filtering) I need to disable DHCP on the ISP router. But since the TV is handled through IPv6 I need to understand it to make sure that that stack is correctly implemented.

Then I have two mesh networks (tailscale and Wireguard as a backup because I manage family networks that are not available from internet) and a docker stack which has its own surprises.

I would love to put a linux box as the egress router and handle everything there (the fiber, DNS, DHCP, etc.) but it is not possible with the provider because the SFP is proprietary (sort of)).

I am really happy to have a relatively stable 1 Gbps fiber connection so I am not complaining - but doing things exactly as I would wish is not always possible.

Many already support SOCKS, but not this 4-layer thing you're suggesting. How can a device, application, whatever that doesn't have support for this use it to handle longer addresses? How can it communicate with a remote node that doesn't have support? How can that remote node communicate back?

If you just want to transport v6 over an existing v4 network there are already approaches to do that in v6.