I could set up an entirely ipv6 network on each of my devices and connect it with nat into IPv4, but crucially I want someone typing "ping 1.1.1.1" or opening a udp conenction to 92.42.35.61 port 5210 would just work, and I don't want to add much overhead (and wide deployment of dual stack is adding overhead)
Imagine I have a mid sized ipv4 network comprising say 200 /24 subnets across multiple locations, all on 192.168.x.0/24, with 192.168.0.0/24 reserved for a vpls connecting them together (say ospf point-to-multipoint, other topologies are preferable of course).
Default router to the internet on 192.168.0.1 (internal), which srcnats to a public IP addresses of 12.12.12.0/24, say 1 hide per subnet, advertised out as BGP to a couple of providers via some /30 links from their allocation.
Now say I want to create a new client network.
1) Create a new subnet on 192.168.201.0/24 and put them all behind the new hide 12.12.12.201
I've done this 100+ times already, no problem, but it's rather legacy.
2) Create a new ipv6 network, with a 192.168.0.89/24 address which links to the other networks
I could create a new ipv6 network, and reach servers on 192.168.12.1, or 192.168.51.8, as well as reaching the internet on ipv4. Traffic leaving the network would get srcnatted to 192.168.0.89.
I then have a new http service I need to add, so I create a new ipv6 server network. This is reachable directly from the wifi clients as I have an ipv6 peering between the wifi client router and the ipv6 server router.
For access from ipv4 subnets I can just put a destination nat on 192.168.0.89 port 80 to my new server, so it's reachable from all other ipv4 clients, but also from ipv6 clients directly. the server wouldn't need as it would see the ipv6 connection from the natting router (which maintains the state). I could also add a port forward from the public IPv4 address too.
3) Do both, and have twice the overhead as I have to manage both an IPv4 and IPv6 network.
I'd rather not do that dual stack. After all what's the point in moving to ipv6 if you need to keep ipv4 running. It would be like using IP and IPX on the same network.
My next step would be to add a public Ipv6 address peering. I put in ipv6 routing on my default router.
Now my new server is reachable directly on ipv6 from my client ipv6 network, and the entire ipv6 internet
It's also reachable from my older network on the internal 192.168 address range, and from the ipv4 internet on
I don't have to have a dual stack on every device (including the server), just on 3 routers.
I notice that some of my customers would like to connect via ipv6, so that's fine, I do an ipv6->ipv4 nat on my firewall for legacy services.
With this setup, which doesn't need me to change 20,000 devices on 200 subnets simultaneously, or end up in a situation where I have 20,000 dual stack devices, I can start migrating to ipv6 without losing any existing ipv4 services. Eventually I will be left with just a handful of ipv4 subnets and a couple of routers running an ipv6/v4 natting gateway
Imagine I have a mid sized ipv4 network comprising say 200 /24 subnets across multiple locations, all on 192.168.x.0/24, with 192.168.0.0/24 reserved for a vpls connecting them together (say ospf point-to-multipoint, other topologies are preferable of course).
Default router to the internet on 192.168.0.1 (internal), which srcnats to a public IP addresses of 12.12.12.0/24, say 1 hide per subnet, advertised out as BGP to a couple of providers via some /30 links from their allocation.
Now say I want to create a new client network.
1) Create a new subnet on 192.168.201.0/24 and put them all behind the new hide 12.12.12.201
I've done this 100+ times already, no problem, but it's rather legacy.
2) Create a new ipv6 network, with a 192.168.0.89/24 address which links to the other networks
I could create a new ipv6 network, and reach servers on 192.168.12.1, or 192.168.51.8, as well as reaching the internet on ipv4. Traffic leaving the network would get srcnatted to 192.168.0.89.
I then have a new http service I need to add, so I create a new ipv6 server network. This is reachable directly from the wifi clients as I have an ipv6 peering between the wifi client router and the ipv6 server router.
For access from ipv4 subnets I can just put a destination nat on 192.168.0.89 port 80 to my new server, so it's reachable from all other ipv4 clients, but also from ipv6 clients directly. the server wouldn't need as it would see the ipv6 connection from the natting router (which maintains the state). I could also add a port forward from the public IPv4 address too.
3) Do both, and have twice the overhead as I have to manage both an IPv4 and IPv6 network.
I'd rather not do that dual stack. After all what's the point in moving to ipv6 if you need to keep ipv4 running. It would be like using IP and IPX on the same network.
My next step would be to add a public Ipv6 address peering. I put in ipv6 routing on my default router.
Now my new server is reachable directly on ipv6 from my client ipv6 network, and the entire ipv6 internet
It's also reachable from my older network on the internal 192.168 address range, and from the ipv4 internet on
I don't have to have a dual stack on every device (including the server), just on 3 routers.
I notice that some of my customers would like to connect via ipv6, so that's fine, I do an ipv6->ipv4 nat on my firewall for legacy services.
With this setup, which doesn't need me to change 20,000 devices on 200 subnets simultaneously, or end up in a situation where I have 20,000 dual stack devices, I can start migrating to ipv6 without losing any existing ipv4 services. Eventually I will be left with just a handful of ipv4 subnets and a couple of routers running an ipv6/v4 natting gateway