IPv6 without nat but what about an isp change?

Solution 1:

There's definitely some mechanisms in place to help you out here.

For internal LAN traffic, between systems on your network, there's Unique Local Addresses. Think of them like RFC1918 addresses; they'll only work within your network. You'll be able to use these addresses for any communication within your network borders; just carve off some nets from fd00::/8 and have your routers start advertising them.

In a normal deployment, this will mean that your nodes all possess (at least) 3 IPv6 addresses; a link-local fe80::/64 address (which can only talk to other nodes on its broadcast domain), a unique local fd00::/8 address (which can talk to everything in your LAN), and a public address.

Now, this still means you're renumbering everything when you change ISPs (which you're doing now anyway for publicly addressable nodes assuming you don't own IPv4 space), just that you don't need to worry about all of the internal communication, which can stay on the Unique Local range.

That might cover your concerns - but there's also the NPTv6 proposal, for which there is currently an experimental RFC. This would allow you to translate the public prefixes to the private ranges at the network edge, meaning no renumbering internally when you change ISPs, and the ability to utilize multiple ISPs with disparate assigned addresses seamlessly (either permanently or during a transition period for a provider change).

Solution 2:

For internal services (terminal servers, internal mail servers, printers, web proxies, etc.) you can use site local addresses within a unique local block under fd00:/8. This is designed to have a /48 block generated from which you can carve out /64s for individual sites. You can have thousands of sites using this model from a single /64. Servers and services using this addressing scheme would be immune from a change in ISP. You will need to tunnel these addresses between sites if the sites are connected via the Internet.

NOTE: Unique local blocks run into the same problems that the IPv4 private addresses blocks have. However, if you randomize the 40 bits following FD, it is highly unlikely you will have a collision.

Client machines do not need consistent IP addresses on the Internet. There are privacy options which will generate new addresses periodically to make tracing clients by IP address break. If your routers run a radvd (Router Advertisement Daemon) service, then your clients can generate their own address. (Router advertisements identify the gateway, and can provide a list of DNS servers.) IPv6 with radvd replaces basic DHCP services. Zero config can be used to allow discovery of many services DHCP would be used to announce. The addresses of client machines should be in different /64 address blocks than your Internet accessible servers use.

The DMZ (De-Militarized Zone) is where your Internet accessible servers and services should reside. These addresses will likely change when your ISP changes. These may reside within a single /64 which will make changing the addresses simpler. As IPv6 requires multiple address support, you can connect your new ISP and perform the changeover in an orderly fashion before disconnecting the original ISP connection.

Unique local block: fd33:ab:de::/48
Site 1:  fd33:ab:de:1::/64
Site 2:  fd33:ab:de:2::/64

Site 1 /48: 2000:1112:1301::/48
Site 1 DMZ: 2000:1112:1301:1:/64    (set on servers)
Site 1 Hosts: 2000:1112:1301:2:/64  (via radv)

Site 2 /48: 2000:2030:4001::/48
Site 2 DMZ: 2000:2030:4001::/64
Site 2 Hosts: 2000:2030:4001:2:/64

You can can use any values you want to discriminate between the DMZ and your host zone(s). You could use 0 for the DMZ as I did for site 2 above. Your ISP may provide a smaller block than a /48. The RFCs suggest that they may subdivide a /64 and allocate /56s. This would restrict the range you have available to allocate /64s.