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

Question

Eu não trabalhei com o IPv6 fora do tunelamento 4to6 no meu PC em casa com coisas como o GoGoNet. Eu li sobre como funciona de uma maneira geral. Nenhum NAT é necessário (ou sugerido) e cada cliente usa um endereço ipv6 público e eu entendo o uso contínuo de firewalls. Pelo que entendi, sem o uso de NAT, UAL e obtendo o ARIN para fornecer sua própria faixa global, isso significaria que o endereço ipv6 em todos os sistemas na sua rede seria de um intervalo fornecido pelo seu provedor. O que aconteceria no caso de você mudar seu ISP? Isso significaria que você precisa alterar todo o seu intervalo de endereços de lan?

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

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 têm lanches estaticamente atribuídos, os servidores DNS precisam e os outros também, já que o firewall faz o encaminhamento de porta para servidores através de endereços IP que você digita (vs hostnames).

Agora, se eu quisesse configurar isso como um ambiente somente para ipv6? Tudo seria o mesmo com os servidores estaticamente atribuídos e o dhcpv6 nas estações de trabalho?

Mas, se eu mudar para outro isp, isso significaria que eu preciso alterar o endereço IP de todos os servidores? E se eu tiver 100 servidores? Eu acho que posso usar dhcpv6 nos servidores, mas eu não vi um firewall de classe de negócios que permitia o encaminhamento de porta via hostname ou dns interno (sonicwall, zimbro, cisco, etc) apenas ip local (atleast para ipv4). E o servidor DNS ainda precisa de ips estáticos de qualquer maneira.

Além disso, isso não significaria que, durante a transição da alteração de lan ipv6 ips, meus servidores podem estar enviando tráfego de lan pela internet para meu bloco antigo, já que não é mais uma 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.

Eu acho que seria ótimo para todo mundo ter seu próprio ipv6 atribuído perm, mas eu entendo que isso tornaria a tabela de roteamento global inutilmente grande.

Atualizar Com base nas respostas abaixo, atualizei o local do exemplo acima e isso 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+

Cada site próprio sistema iria falar via Link-Local, Site-to-Site iria conversar uns com os outros ULA (encypted pela VPN) e o mundo (incluindo serviços) iria falar via IPs Públicos?

    

Answer 1

Há definitivamente alguns mecanismos para ajudá-lo aqui.

Para tráfego interno da LAN, entre sistemas na sua rede, há endereços locais exclusivos. Pense neles como endereços RFC1918; eles só funcionam na sua rede. Você poderá usar esses endereços para qualquer comunicação dentro de suas bordas de rede; apenas retire algumas redes de fd00::/8 e faça seus roteadores começarem a publicá-las.

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

Agora, isso ainda significa que você está renumerando tudo quando você muda os ISPs (o que você está fazendo agora para nós endereçáveis publicamente, assumindo que você não possui espaço IPv4), só que você não precisa se preocupar com todos da comunicação interna, que pode permanecer no intervalo Local Único.

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

    

Answer 2

Para serviços internos (servidores de terminal, servidores de email internos, impressoras, proxies da Web, etc.), você pode usar endereços locais de sites em um bloco local exclusivo em fd00: / 8. Isso é 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 este modelo de um único / 64. Servidores e serviços usando este esquema de endereçamento seriam imunes a uma mudança no ISP. Você precisará encapsular esses endereços entre sites se os sites estiverem conectados via Internet.

NOTA: Os blocos locais únicos sofrem os mesmos problemas que os blocos de endereços privados IPv4. No entanto, se você randomizar os 40 bits após 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 rastrear clientes por quebra de endereço IP. Se seus roteadores executarem um serviço radvd (Router Advertisement Daemon), seus clientes poderão gerar seu próprio endereço. (Os anúncios do roteador identificam o gateway e podem fornecer uma lista de servidores DNS.) O IPv6 com radvd substitui os serviços básicos do DHCP. Zero config pode ser usado 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ços / 64 diferentes dos usados pelos servidores acessíveis pela Internet.

A DMZ (zona desmilitarizada) é onde seus servidores e serviços acessíveis pela Internet devem residir. Esses endereços provavelmente serão alterados quando o seu ISP for alterado. Estes podem residir dentro de um único / 64, o que tornará a alteração dos endereços mais simples. Como o IPv6 requer suporte a múltiplos endereços, você pode conectar seu novo ISP e realizar a mudança de forma ordenada antes de desconectar a conexão ISP original.

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 sua (s) zona (s) de host. Você poderia usar 0 para o DMZ como eu fiz para o site 2 acima. 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.