IPv6 sem nat, mas que tal uma mudança de ISP?

Não trabalhei com IPv6 fora do tunelamento 4to6 no meu PC doméstico com coisas como a GoGoNet. Eu li sobre como isso funciona de uma maneira geral. Não é necessário NAT (ou sugerido) e cada cliente usa um endereço IPv6 público e eu entendo o uso continuado de firewalls. Pelo que entendi, sem o uso de NAT, UAL e a obtenção de ARIN para fornecer uma faixa global própria, isso significaria que o endereço IPv6 em todos os sistemas em sua LAN seria de uma faixa fornecida pelo seu ISP. O que aconteceria se você mudasse seu ISP? Isso significa que você precisa alterar todo o intervalo de endereços de lan?

Em uma típica loja de janelas ipv4, posso ter uma situação como esta:

Site1 Lan IPs: 192.168.1.0/24
Site2 Lan IPs: 10.0.0.0/24
Site1 Public IP: 11.12.13.1/29 (11.12.13.1 - 11.12.13.5 usable)
Site2 Public IP: 20.30.40.1/29 (20.30.40.1 - 20.30.40.5 usable)
Site-to-site VPN via firewalls

Site1:                                 Lan IP,         Public IP:Port
Hardware firewall/router             - 192.168.1.1,    11.12.13.1
Windows AD DC server (AD DNS server) - 192.168.1.10
Windows Exchange (email)             - 192.168.1.11,   11.12.13.2:25+443
Windows RDS (term server)            - 192.168.1.12,   11.12.13.3:3389
Workstations (via DHCP)              - 192.168.1.100+

Site2:
Hardware firewall/router             - 10.0.0.1,       20.30.40.1
Windows AD DC server (AD DNS server) - 10.0.0.10
Windows IIS (webserver)              - 10.0.0.11,      20.30.40.2:80
Workstations (via DHCP)              - 10.0.0.100+

Os servidores possuem LANs atribuídos estaticamente, os servidores DNS precisam e os outros também, já que o firewall faz o encaminhamento de portas para os servidores por meio de endereços IP digitados (vs nomes de host).

Agora, se eu quisesse configurar isso como um ambiente apenas para ipv6? Tudo continuaria igual com os servidores atribuídos estaticamente e o dhcpv6 para as estações de trabalho?

Mas, se eu mudar para outro provedor, isso significa que preciso alterar o endereço IP de todos os servidores? E se eu tiver 100 servidores? Acho que posso usar o dhcpv6 nos servidores, mas não vi um firewall de classe comercial que permitia o encaminhamento de portas via nome do host ou dns interno (sonicwall, juniper, cisco, etc.) apenas o IP local (pelo menos para o ipv4). E o servidor DNS ainda precisa de ips estáticos.

Além disso, isso não significa que, durante a transição da alteração de ips da LAN IPv6, meus servidores podem estar enviando tráfego de LAN pela Internet para o meu bloco antigo, pois não é mais a LAN local? Pelo menos em termos técnicos, eu entendo que é improvável que alguém use o bloco antigo tão rapidamente e que ele possa ser bloqueado no firewall.

Parece que seria ótimo que todos obtivessem seu próprio bloco ipv6 com permissão, mas entendo que isso tornaria a tabela de roteamento global inutilmente grande.

Atualizar Com base nas respostas abaixo, atualizei o local do exemplo acima e, portanto, esse seria o equivalente ao ipv6?

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+

Os sistemas de cada site conversariam via Link-Local, site a site conversariam uns com os outros ULA (codificado pela VPN) e o mundo (incluindo serviços) conversaria por IPs públicos?

Definitivamente, existem alguns mecanismos para ajudá-lo aqui.

Para o tráfego interno da LAN, entre os sistemas da sua rede, há endereços locais exclusivos. Pense neles como endereços RFC1918; eles só funcionarão na sua rede. Você poderá usar esses endereços para qualquer comunicação dentro das fronteiras da sua rede; esculpe algumas redes fd00::/8e faça com que os roteadores comecem a divulgá-las.

Em uma implantação normal, isso significa que todos os nós possuem (pelo menos) três endereços IPv6; um fe80::/64endereço local de link (que só pode conversar com outros nós em seu domínio de broadcast), um fd00::/8endereço local exclusivo (que pode conversar com tudo na sua LAN) e um endereço público.

Agora, isso ainda significa que você está renumerando tudo quando altera os ISPs (o que você está fazendo agora para nós endereçáveis ​​publicamente, assumindo que você não possui espaço IPv4), apenas para não precisar se preocupar com todas as informações internas. comunicação, que pode permanecer na faixa Local Único.

Isso pode cobrir suas preocupações - mas também há a proposta do NPTv6, para a qual existe atualmente uma RFC experimental . Isso permitiria que você traduza os prefixos públicos para os intervalos privados na borda da rede, o que significa que não é necessário renumerar internamente quando você altera os ISPs, e a capacidade de utilizar vários ISPs com endereços atribuídos díspares sem problemas (permanentemente ou durante um período de transição para um provedor) mudança).

Para serviços internos (servidores de terminal, servidores de correio internos, impressoras, proxies da web etc.), você pode usar os endereços locais do site dentro de um bloco local exclusivo em fd00: / 8. Isso foi projetado para ter um bloco / 48 gerado a partir do qual você pode esculpir / 64s para sites individuais. Você pode ter milhares de sites usando esse modelo em um único / 64. Servidores e serviços que usam esse esquema de endereçamento estariam imunes a uma mudança no ISP. Você precisará encapsular esses endereços entre sites, se os sites estiverem conectados via Internet.

NOTA: Blocos locais exclusivos têm os mesmos problemas que os blocos de endereços privados IPv4. No entanto, se você aleatorizar os 40 bits seguintes FD, é altamente improvável que você tenha uma colisão.

As máquinas clientes não precisam de endereços IP consistentes na Internet. Existem opções de privacidade que geram novos endereços periodicamente para fazer o rastreamento de clientes por quebra de endereço IP. Se seus roteadores executam um serviço radvd (Router Advertisement Daemon), seus clientes podem gerar seu próprio endereço. (Os anúncios do roteador identificam o gateway e podem fornecer uma lista de servidores DNS.) O IPv6 radvdsubstitui os serviços DHCP básicos. A configuração zero pode ser usada para permitir a descoberta de muitos serviços que o DHCP seria usado para anunciar. Os endereços das máquinas clientes devem estar em blocos de endereço / 64 diferentes dos usados ​​pelos servidores acessíveis à Internet.

A DMZ (zona des-militarizada) é onde os servidores e serviços acessíveis à Internet devem residir. Esses endereços provavelmente mudarão quando o seu provedor de serviços de Internet mudar. Eles podem residir em um único / 64, o que tornará a alteração dos endereços mais simples. Como o IPv6 requer suporte a vários endereços, você pode conectar seu novo ISP e realizar a troca de maneira ordenada antes de desconectar a conexão original do ISP.

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

Você pode usar qualquer valor que queira discriminar entre a DMZ e as zonas do host. Você pode usar 0 para a DMZ, como fiz no site 2 acima. O seu ISP pode fornecer um bloco menor que um / 48. Os RFCs sugerem que eles podem subdividir um / 64 e alocar / 56s. Isso restringiria o intervalo disponível para alocar / 64s.