I haven't worked with IPv6 outside of 4to6 tunneling on my home pc with stuff like GoGoNet. I've read about how it works in a general way. No NAT required (or suggested) and each client uses a public ipv6 address and I understand the continued use of firewalls. From my understanding, without the use of NAT, UAL and getting ARIN to give you own global range, that would mean the ipv6 address on all the systems on your lan would be from a range provided by your isp. What would happen in the case you change your ISP? Would that mean you have to change your whole lan address range?

In a typical ipv4 windows shop I might have a situation like such:

Site1 Lan IPs:
Site2 Lan IPs:
Site1 Public IP: ( - usable)
Site2 Public IP: ( - usable)
Site-to-site VPN via firewalls

Site1:                                 Lan IP,         Public IP:Port
Hardware firewall/router             -,
Windows AD DC server (AD DNS server) -
Windows Exchange (email)             -,
Windows RDS (term server)            -,
Workstations (via DHCP)              -

Hardware firewall/router             -,
Windows AD DC server (AD DNS server) -
Windows IIS (webserver)              -,
Workstations (via DHCP)              -

The servers have statically assigned lan ips, the DNS servers has to and the others are also, since the firewall does port forwarding to servers via ip addresses you type in (vs hostnames).

Now if I wanted to setup this as a ipv6 only environment? Would everything still be the same with statically assigned servers and dhcpv6 to workstations?

But then if I switch to another isp would that mean I need to change the ip address for all the servers? What if I have 100 servers? I guess I can use dhcpv6 on the servers but I haven't seen a biz-class firewall that allowed port forwarding via hostname or internal dns (sonicwall, juniper, cisco, etc) just local ip (atleast for ipv4). And DNS server still need static ips eitherway.

Also wouldn't that mean that during transition of changing lan ipv6 ips, my servers might be sending lan traffic over the internet to my old block since it's no longer local lan? Atleast in a technical terms, I understand it's unlikely someone would use the old block that quickly and that it can be blocked on the firewall.

I sounds like it would be great for everyone to get their own perm assigned ipv6 block but I understand it would make the global routing table unusably large.

Update Based on answers below, I updated the example location above and so this would be the ipv6 equivalent?

Site1 ULA: fd80::192:/64
Site2 ULA: fd80::10:/64
Site1 Public IP: 2000:1112:1301::/48
Site2 Public IP: 2000:2030:4001::/48
Site-to-site VPN via firewalls

Site1:                       Link-Local, ULA,            Public
Hardware firewall/router   - fe80::1,    fd80::ABCD:1,   2000:1112:1301::1
Windows AD DC server (DNS) - fe80::10,   fd80::ABCD:10,  2000:1112:1301::A
Windows Exchange (email)   - fe80::11,   fd80::ABCD:11,  2000:1112:1301::B
Windows RDS (term server)  - fe80::12,   fd80::ABCD:12,  2000:1112:1301::C
Workstations (via DHCP)    - fe80::100+, fd80::ABCD:1xx, 2000:1112:1301::10+

Site2:                       Link-Local, ULA,            Public
Hardware firewall/router   - fe80::1,    fd80::ABCD:2,    2000:2030:4001::1
Windows AD DC server (DNS) - fe80::10,   fd80::ABCD:20,   2000:2030:4001::A
Windows IIS (webserver)    - fe80::11,   fd80::ABCD:21,   2000:2030:4001::B
Workstations (via DHCP)    - fe80::100+, fd80::ABCD:2xx,  2000:2030:4001::10+

Each site own systems would would talk via Link-Local, Site-to-Site would talk with each other ULA (encypted by the VPN) and the world (including services) would talk via Public IPs?

up vote 10 down vote accepted

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).

  • 1
    +1 - The simple fact is though, for a small home network, you will just use the link local addresses fe80::/64 and your ISP assigned IP addresses are fairly irrelevant. For a datacenter though, changing ISPs has always been a big job, so there's little change there as well. – Mark Henderson Jan 14 '12 at 20:09
  • 1
    When using fd00::/8 (ULA) you are supposed to generate a semi-random /48 block of addresses. You can use i.e. sixxs.net/tools/grh/ula to generate a block of ULA addresses with a standards-conformant algorithm. Use the ULA addresses for internal communication (file servers etc) and site-to-site VPN tunnels, and use the public addresses to access the internet. Then you'll only need to renumber truly public services when changing ISPs (like locally hosted websites and the endpoints of the VPN tunnels, but not all the firewall policies to your ULA address space) – Sander Steffann Jan 14 '12 at 21:00
  • ah, ok I didn't think of just multiple ipv6 addresses per host. I updated the example and added my understanding of what a equivalent set for ipv6. Let me know if I'm getting my notation right. Also sounds like VPN setups would be very easy with the firewall just needing to encrypt data in the UAL. Will read up on the NPTv6 stuff also. – Halfdone Jan 15 '12 at 0:00

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.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.