[iso1631]

192.168.0.0/24 -> fd00:0::/64

192.168.1.0/24 -> fd00:1::/64

192.168.2.0/24 -> fd00:2::/64

192.168.240.0/24 -> fd00:240::/64

It's not a great idea, but its no harder.

No need to mess around with setting up DHCP, remembering if your router is top or bottom of the subnet, and if you want 500 devices on a single subnet that's no problem.

Now if you still need ipv4 then yes, ipv6 is stupid as you have double the pain for none of the gain, but if you are ip6 only then its far easier.

[SV_BubbleTime]

I doubt any endpoints are entirely ipv6.

So it seems like it helps ISPs and large networks router… but they never had problems with address space running out at the high levels and almost all likely need to support v4 anyhow.

I think it’s been long enough to be honest that ipv6 was a spectacular failure by complicating an already complicated system into something no one actually asked for.

No human said “hey, networking sucks. Please make it much harder at my level!!”.

[toast0]

> I doubt any endpoints are entirely ipv6.

Lte and 5G can be v6 only, usually they also have NAT64 and DNS64 so you can get everywhere, but the less stuff that needs v4, the smaller their nat boxes are.

[tracker1]

I'm largely with you... I would think they'd take the IPv4 block and have a direct/virtual block that just extends it to more addresses... so it could be an IPv4 NAT or IPv6 direct.

like 1.1.1.1/192.168.45.4 ... for a router that understands IPv6, that's the direct route to the sub-network, otherwise it will have to use IPv4, and the subnet route is treated as NAT and otherwise isolated.

To me, that would make more sense... then internal IPv6 might be practically limited to 10. and 102.168. in the nearer term, but adoption would be MUCH simpler in practice, and distribution would mostly already be established, however unfairly, but can then be broken into single addresses and vNext adoption could be that much quicker as a result of piggybacking.

[pbhjpbhj]

>limited to 10. and 102.168

I assume you meant 10.x.x.x and 192.168.x.x -- (and 172.16.x.x?), ie the standard subnets for home router-modems (which are non-routing and so can't be used on the internet).

[tracker1]

Of course... this would transitionally make the ipv6 internal addresses easier to understand in the context of typical migration... you have the public prefix and the public ipv6 addresses of your internal network map cleanly to the internal/nat'd ipv4 ... you could still use any ipv6 internally once most of the internet transitioned.. but it'd be easier to reason with at least... I still don't know WTF/HTF ipv6 addresses are issued, where or how I can centrally control static assignment to a given MAC.

[inigyou]

AFAIK this was one of several things that was tried, but failed for various reasons. It's called "TUBA" - TCP/UDP with Bigger Addresses - adding extra address bits at a layer above IP so that IP remains compatible.

I think one of the main problems with it is that you have to update the whole internet anyway, just like you do with IPv6, so you make the protocol stack stupider for no real benefit.

[ianburrell]

An alternate to IPv6 would have been to store the NAT addresses in IPv4 somehwere. But the IPv4 options are fragile and normal NAT would likely destroy them. It would still require rewriting all of the networking and software. It would have engrained NAT everywhere and made lots of routing problems, like is that your or mine 10. network.

[tracker1]

That's where the public prefix would be the differentiator... you could only access from external directly over IPv6, but it still represents the same device as the NAT ipv4 address.

Difference is it's all public after, it would ease the transition dramatically, and then you can just use whatever you want internally making /32 the minimal assigned block or whatever the prefix size is.

[ianburrell]

Stop saying IPv6 when talking about new protocol. IPv6 already exists and is better than potential IPv4 extension. There was a window twenty years ago for alternative but now IPv6 is usable and can access IPv4 hosts with NAT64. The only reason for IPv4 is inertia.

Routing would be complicated when have to deal with variable length addresses when half the hosts don't know about them and half the routers remove them. It wouldn't make up for rewriting all the software, we know how hard that was with IPv6.

[iso1631]

1:1:1:1::192.168.45.4

That's a perfectly valid IPv6 address and can be set up, if you own 1:1:1:1/32

[tracker1]

Cool... now, what do I need to do to configure say OpnSense to give out my internal IPv4/6 addresses that way... and then what pain do I need to go through to secure my internal devices from externally oriented connection attempts?

The former is somewhat serious a question... I want some devices statically assigned and others dynamically, and I'd love to have them match, so where desired I can directly route to/from external over IPv6.

[iso1631]

The problem with ipc6 is that transparent v4 support

My ISP gives me an ipv6 range of 2001:abc:ab23:: (well something very similar) routed down the pppoe tunnel (which autoestablishes ipv6 with a /128 IP, just like my ipv4 establishes with a /32)

I thus have my ipv6 vlan 2301 as 2001:abc:ab23:2301::/64

The router is at 2001:abc:ab23:2301:: (which is 2001:abc:ab23:2301:0:0:0:0)

My DNS server on that vlan is statically configured as 2001:abc:ab23:2301::53

My phone when I connect gets a slacc address 2001:abc:ab23:2301:so.me:thi.ng

I can't reach my DNS server from the outside world on 2001:abc:ab23:2301::53 because my firewall blocks it, but if I did allow it t would route through just fine

Remember none of this works with v4 though, you'd have to configure your router to do nat46 and nat64. I've never used such a router, but looks like its supported

https://docs.opnsense.org/manual/how-tos/tayga.html

As such if your public IPv4 was 23.45.67.89 address

You'd forward 23.45:67.89 -> 2001:abc:ab23:2301::53

And vice versa.

Now the next issue is multi-homing.

My backup router is ipv4 only, so when 192.168.231.0/24 gets routed out my main ISP as normal, it's hidden behind an IP like 81.187.123.45. If I route traffic out of my backup 5g ISP it gets hidden behind that (it actually gets src-natted to a 10.x range, as it's a 4g ISP, it gets converted to a real public IP later)

My 4g doesn't support ipv6, and ipv6 is just a toy, but I expect I would use nat66 to map

2001:abc:ab23:2301::53

behind whatever IP range I was given for the backup route. I've not looked into nat66.

The other aspect is changing ISP. I don't plan on doing that, and ipv6 is only a toy protocol, hence I can just use my global address range. I could however use fd00:2301::53 for my internal DNS server (equivalent of 192.168.231.53) and nat66 it at the boundary, hiding fd00:2301:: behind 2001:abc:ab23:2301::

As the hide address is a /64 there's no need for port mapping, my traffic would emerge from 2001:abc:ab23:2301::53

ipv6 proponents talk about advertising half a dozen IPs to your end devices and renumbering them all dynamically and using mdns instead of static IPs. And they wonder why people thing ipv6 is crap.

[inigyou]

Public websites almost always still have ipv4 to serve ipv4-only users who make up half of the American business internet. But note that v6 connectivity is better than v4 in basically every other country and basically every mobile network (which is where most of the users are).

[ianburrell]

The proper way to do ULA is to generate random 40-bit ID. Then your ULA are likely unique. Which means that if you want to connect or merge with another company, the networks are distinct.

IPv4 has a lot of trouble since everyone is using 10/8 space for corporate networks.

[inigyou]

If someone can't remember 192.168 they definitely can't remember their own chosen random 40 bits.

[tracker1]

One thing I don't appreciate... Is the nature of NAT protected my internal/home network before... now, I have to actually configure firewall settings etc. to protect IPv6 issued addresses internally.

I know you can just block inbound non-established connections, but it feels like an extra step and complexity. Not to mention, that I really don't understand how IPs are supposed to be provisioned to devices on IPv6. Is there like a 50-100 page book you can recommend "for dummies" on IPv6, that hopefully contains at least a tiny amount of how to configure a common router and/or linux host.

[tredre3]

> Not to mention, that I really don't understand how IPs are supposed to be provisioned to devices on IPv6.

SLAAC is the only way that works across all IPV6 devices. In that mode, the router advertises the prefix and the device assigns its own address (prefix + its mac address).

DHCPv6 exists but is poorly supported. It sucks for people who like assigning IPs individually from an authoritative place (through static dhcp entries on the router). But people like us are "doing it wrong", you see? We must accept that in this brave new worlds an IP means nothing.

[tracker1]

Which doubly sucks in terms of assigning a DNS name to an IP/PC... and/or opening the assignment to less restricted access... feels just problematic to me.

Again, I don't know any of IPv6 enough to use it really right or wrong.

[inigyou]

If your ISP offers it, you should just try it. If not, do you have a website on a VPS or something? Try making that work with v6. It's really not a scary monster, it's mostly the same thing again but with long addresses, and a few convention changes that come with long addresses.

Examples of convention changes: end devices can each get several addresses for privacy and for being on multiple networks concurrently. SLAAC is stateless because addresses in a /64 are so endless there's no need to keep a central registry of which ones are already used. NAT is rare because it's no longer necessary, even though there is no internet police to stop you from using it (please try to avoid it). P2P is so much easier - applications can be written under the assumption connectivity is end-to-end with firewall hole punching.

[inigyou]

And there's always static configuration, useful for servers.

[inigyou]

Home routers with IPv6 should have this enabled by default, at least by law in Europe, and you can turn it off or add exceptions.