Um dos principais problemas quando um ISP está planejando fornecer IPv6 serviços é decidir como abordar os clientes. De uma forma genérica, poderíamos dizer que a primeira coisa a fazer para qualquer IPv6 implantação é o plano de endereçamento de rede completo, mesmo antes de obter seu espaço de endereçamento de seu Registro Regional de Internet (RIR), então você acertou desde o início.
No caso de clientes corporativos, geralmente ninguém duvida que eles deveriam receber um / 48 IPv6 GUA (Global Unicast Address) em cada site final e, claro, esses prefixos devem ser persistentes (geralmente chamados de estáticos) para cada cliente.
No caso de clientes residenciais, clientes de pequenos escritórios / escritórios domésticos (SOHO) ou mesmo clientes PME, em IPv4, estamos acostumados a um único endereço público não persistente (freqüentemente chamado de dinâmico). Além disso, por causa de IPv4 esgotamento de endereço, estamos nos movendo em direção a endereços privados na WAN do cliente por meio de Tradução de endereços de rede de grau de operadora (CGN),
Então, qual é a coisa certa a fazer no caso de IPv6 para clientes residenciais e SOHO? Esta é a questão que estamos tentando abordar neste artigo.
Procurar maneiras rápidas e fáceis de fazer seu plano de endereçamento pode ser tentador, mas pode causar consequências inesperadas que podem exigir um novo plano, renumerando seus clientes, adaptando seus sistemas de provisionamento e, por fim, tornando tudo muito mais caro do que se você tivesse feito desde o início.
Portanto, não subestime o valor de investir algum tempo e esforço extra para aprender mais sobre IPv6 e entender como é diferente de IPv4.
1. O que significa persistente versus não persistente?
In IPv4, pelo menos para clientes residenciais ou SOHO, porque normalmente executamos Network Address Translation (NAT) no CPE, há uma percepção de que usar prefixos não persistentes é a abordagem mais fácil.
No entanto, fazer isso com IPv6 é uma coisa muito diferente e pode ter consequências negativas.
Vamos esclarecer primeiro o que queremos dizer com persistente e não persistente, pois pode ser confuso com outra terminologia, como "(não) estável", "dinâmico", "estático", etc. Aqui não nos referimos à tecnologia usada para realmente atribuir os endereços ou prefixos, mas sim tecnologia que “ficará” com o mesmo cliente.
Em geral, clientes residenciais e SOHO são provisionados usando DHCP (ou DHCPv6 para IPv6) Em muitos casos, uma forma muito simples de usar o DHCP é ter um pool de endereços em cada PoP e permitir que o PoP atribua endereços dinamicamente (ou prefixos em IPv6 por meio de DHCPv6-PD - Delegação de prefixo).
Este mecanismo muito simples, se não for vinculado aos clientes, significa que endereços ou prefixos arbitrários são fornecidos a cada cliente quando o CPE se conecta à rede, por um determinado tempo de aluguel. Isso é o que chamamos de atribuição não persistente, porque se o cliente desligar o CPE, após o tempo de locação, ele obterá um endereço diferente (para IPv4) e / ou prefixo (para IPv6) próxima vez.
No entanto, se tornarmos o tempo de locação muito longo, talvez semanas ou meses, em vez de apenas alguns minutos ou dias, o cliente receberá o mesmo endereço ou prefixo. Esta será uma atribuição “persistente”.
Se o DHCP / DHCPv6 estiver vinculado a algum sistema de provisionamento mais sofisticado, que na verdade pode ser tão simples quanto um banco de dados correlacionando clientes específicos a endereços / prefixos específicos, também temos atribuições “persistentes”. Isso pode ser feito, por exemplo, usando um sistema AAA (Autenticação, Autorização e Contabilidade), como Radius ou Diameter, que está muito comumente disponível em qualquer ISP, por razões de segurança e para impedir que clientes e não clientes façam não -utilização autorizada da rede.
2. Prefixos persistentes versus prefixos não persistentes
Pela descrição acima, pode parecer que as atribuições não persistentes são a escolha mais fácil, mas, na verdade, em IPv6 você realmente precisa gerenciar os endereços por meio de um sistema IPAM (IP Address Management). Tentando usar ferramentas simples, como costumamos fazer em IPv4, como uma planilha ou processador de texto, não funcionará devido ao tamanho do IPv6 espaço de endereçamento.
A vantagem é que esses sistemas IPAM geralmente vêm com funcionalidades como DHCP / DHCPv6 / DHCPv6-PD e DNS. Portanto, eles podem assumir a atribuição de prefixo aos clientes para cada PoP de forma que, no final, fique ainda mais simples do que ter um pool para cada PoP e permitir que endereços arbitrários sejam atribuídos a cada cliente à medida que eles se conectam. Com isso, você ganha mais controle sobre os parâmetros de sua rede.
Há uma vantagem adicional de usar prefixos persistentes, tanto do lado do usuário quanto do ISP. Ter os mesmos endereços significa que o ISP pode oferecer novos serviços aos clientes, e eles não precisam ter sistemas complexos para correlacionar esses serviços a endereços de “mudança” dentro da rede do cliente. Além disso, os usuários podem criar seus próprios serviços sem quaisquer restrições.
Assim, por exemplo, o ISP pode oferecer serviço DNS avançado para dispositivos de usuário, como camera1.username.ispname.com ou main-door.username.ispname.com, etc. Ou pode implantar serviços VPN dentro da rede. Além disso, prefixos persistentes podem ser um incentivo para que os clientes permaneçam com seus ISP. Todos esses aspectos podem trazer receitas adicionais.
Há uma consideração final: você vai fazer algo diferente, em termos de persistência, para clientes corporativos em comparação com outros tipos de clientes? Você tem redes ou sistemas de provisionamento diferenciados? Não acho que faça muito sentido ter prefixos não persistentes para residencial / SOHO / PMEs e persistentes para clientes corporativos.
Em qualquer caso, sugiro fortemente oferecer persistentes IPv6 prefixos.
Se você ainda não está convencido, vamos dar uma olhada nos problemas causados por prefixos não persistentes, por exemplo, quando se trata de falhas de rede, falta de energia ou situações semelhantes.
Vamos supor um cliente provisionado no primeiro estágio com o prefixo 2001: db8: 1111 :: / 48. Seus dispositivos estão usando, para nosso exemplo, o primeiro free / 64 (2001: db8: 1111 :: 1/64). Tudo está bem até que haja uma queda de energia. O CPE inicializa novamente quando a energia é recuperada, e porque o ISP está usando um prefixo não persistente, um novo prefixo é atribuído (2001: db8: 2222 :: / 48), então agora o CPE está anunciando 2001: db8: 2222 :: 1/64.
Porém, os dispositivos que possuem bateria (laptops, tablets, smartphones) ainda possuem o prefixo anterior, então agora eles possuem dois prefixos diferentes (2001: db8: 1111 :: 1/64 e 2001: db8: 2222 :: 1/64) . Esses dispositivos tentarão continuar usando o mais antigo e não funcionarão, pois o ISP não está mais roteando o primeiro prefixo para esse cliente. Basta pensar: se outra falha de rede ou falta de energia acontecer agora. Os dispositivos podem ter três ou mais prefixos. E o usuário acabará ligando para o help-desk do ISP para solucionar problemas, porque a rede não está funcionando.
Além disso, grandes provedores de conteúdo estão medindo “IPv6 estar quebrado". A situação descrita acima aumentará a taxa de falha de sua rede, então eles deixarão de servir registros AAAA para aquela rede e seu tráfego voltará para IPv4. Se você estiver usando CGN, significa uso extra de CGN, resultando em custos extras, atrasos extras e assim por diante.
Além disso, se você usar prefixos persistentes, há outra vantagem, porque significa que cada cliente sempre tem o mesmo prefixo, o que significa que você não precisa registrar essas conexões para interceptação legal, pois tudo é estático - "cada mesmo prefixo personalizado" , reduzindo seus custos e até mesmo simplificando a solução de problemas em caso de falhas.
Claro, quando sugerimos atribuir prefixos persistentes, não estamos considerando “portabilidade”. Se um usuário residencial / SOHO se mudar de um local para outro, ele precisará desligar sua rede e movê-la para a nova casa, solicitar uma nova configuração de conectividade com a Internet, etc. Portanto, eles não devem esperar (a menos que seja a mesma edifício ou bairro), que terão o mesmo prefixo - a menos que você queira oferecer isso como um serviço extra.
Pode haver um caso especial para clientes com preocupações de privacidade: se eles considerarem o prefixo (não o endereço) como dados pessoais, o cliente pode ter o direito de obtê-lo alterado de tempos em tempos. No IPv6 isso não deve ser um problema significativo, porque os sistemas operacionais usam endereços de privacidade para evitar o rastreamento de usuários e, além disso, as tecnologias modernas de rastreamento dependem de muitos outros parâmetros obtidos do navegador, aplicativos, etc.
No entanto, isso pode ser resolvido permitindo que os usuários escolham um prefixo não persistente em sua interface de gerenciamento de conexão com a Internet.
3. Numerando o link WAN
Existem várias possibilidades para numerar o link que interconecta a rede ISP e o CPE do cliente (o link WAN). Vamos descrever cada um e entender os prós e os contras.
3.1. Um prefixo / 64 do IPv6 prefixo atribuído ao cliente
Isso está sendo usado por vários ISPs e foi descrito em um Documento IETF (Diretrizes para numeração IPv6 Links Ponto a Ponto e Facilitação dos Planos de Endereçamento). Isso significa que, por exemplo, se você atribuir um / 48 ao cliente, o primeiro / 64 será usado para o link WAN e está sendo usado em redes celulares. As vantagens são muitas, pois simplifica o roteamento e o gerenciamento, mas só funciona se o CPE estiver de acordo com a RFC6603 (opção de exclusão de prefixo para delegação de prefixo baseada em DHCPv6). No entanto, porque a maioria das IPv6 Os CPEs devem seguir RFC7084 (Requisitos Básicos para IPv6 Customer Edge Routers), que já recomenda o suporte a RFC6603, espera-se que CPEs modernos funcionem nesta situação.
3.2. A / 64 prefixo de um dedicado IPv6 pool para prefixos WAN
Esta é provavelmente a escolha mais comum e, de fato, mais próxima do que costuma ser feito para IPv4. Significa ter um pool totalmente separado de IPv6 prefixos para os links WAN, portanto, neste caso, não há correlação entre o prefixo do cliente e aquele usado no link WAN. Um pool dedicado tem a vantagem de poder aplicar políticas de segurança explicitamente a esses pools; no entanto, deve-se observar que isso só é verdade se todos os clientes tiverem um CPE em sua extremidade, pois, caso contrário, prejudicará os usuários sem um CPE.
3.3. Não numerado
Em vez de usar um GUA, o link usa IPv6 endereços locais de link. Nesse caso, o CPE pode não funcionar e ficar sem numeração porque pode não conseguir solicitar um prefixo usando DHCPv6-PD. Isso também falhará se, em vez de um CPE, for usado um sistema operacional que não ofereça suporte a DHCPv6-PD. Pode parecer mais fácil de implementar do que as outras opções descritas aqui, mas como os endereços locais de link não são visíveis em ferramentas como traceroute, torna a solução de problemas mais complexa.
3.4. ULA
Numerando o link WAN com IPv6 ULAs (endereços unicast locais exclusivos) são fortemente desencorajados, pois podem causar uma série de problemas. Por exemplo, se o CPE precisar enviar ICMPv6 para um host fora da rede ISP, o pacote terá um endereço de origem ULA e não atravessará o roteador upstream do ISP, interrompendo assim o PMTUD (Path MTU Discovery), e o IPv6 conexão se o MTU não for o mesmo em todo o caminho. Novamente, isso pode dificultar a solução de problemas.
Há mais um problema relacionado ao link WAN, que se refere à escolha do comprimento do prefixo do link WAN. Alguns ISPs usam apenas o padrão / 64, como padrão IPv6 tamanho da sub-rede (já que o link WAN é mais uma sub-rede). RFC6164 sugere o uso de / 127, mas outros ISPs usam / 126 ou / 112, entre outras opções.
No entanto, deve-se notar que alguns hardwares têm limitações para prefixos maiores que / 64, e alguns podem nem mesmo permitir o uso de qualquer outro que não seja / 64. Usar um / 64 é à prova de futuro e tem a vantagem de permitir um link ponto a ponto; ter dispositivos adicionais, como pontes gerenciadas, solução de problemas ou dispositivos de monitoramento; ou mesmo alta disponibilidade por meio de VRRPv3, etc.
Por último, mas não menos importante, se você decidir usar / 127, deve considerar a alocação do / 64 completo, mesmo se usar um / 127, para evitar o ataque de exaustão da descoberta de vizinho (RFC6583).
Observe que a discussão sobre "persistência" nas primeiras seções deste documento é relevante apenas para o IPv6 prefixos atribuídos ao cliente para uso dentro de sua rede, e não o prefixo usado para o link WAN, que pode ser “não persistente”. No entanto, normalmente, a maioria dos ISPs também o torna persistente e é gerenciado automaticamente pelo sistema de provisionamento.
4. Opções de tamanho do prefixo de atribuição do cliente
Como ponto de partida, precisamos nos lembrar das três regras de ouro que precisam ser consideradas com IPv6:
- O tamanho da sub-rede padrão é / 64.
- Os clientes devem ser capazes de criar sub-redes em suas redes, o que significa que eles precisam ser atribuídos a nx / 64 (então um único / 64 NUNCA é uma escolha válida).
- Para manter os planos de endereçamento utilizáveis e compreensíveis e para alinhar com as delegações de zona reversa DNS, o tamanho do prefixo atribuído ao cliente deve ser alinhado com um limite de nibble (4 bits).
As políticas do RIRs, em todas as cinco regiões, permitem atribuir um / 48 a cada site final, e é claro que globalmente é uma prática bem compreendida e muito comum atribuir um / 48 a cada site final corporativo.
Além disso, um novo Trabalho IETF, "Único IPv6 Prefix Per Host ”, mostra a necessidade de múltiplos / 64 em cada end-site e provavelmente muito mais do que assumimos até agora, à medida que se torna cada vez mais frequente, mesmo no caso de uso residencial, ter dispositivos que funcionam várias máquinas virtuais. Isso significa que pode ser um requisito isolar essas VMs diferentes em sub-redes diferentes (portanto, / 64s diferentes). Isso acontece da mesma forma com novos protocolos como o Homenet, que usa um / 48 do ISP e então subatribui / 56 para roteadores downstream.
Por fim, está claro que em muitos países os clientes corporativos (pelo menos PMEs e SOHO) obtêm os mesmos links, porque as capacidades de banda larga estão aumentando rapidamente para todos os tipos de clientes. A única diferenciação possível são os SLAs e podem ser vários públicos IPv4 endereços. Portanto, precisamos considerar que as diferenciações de serviço / marketing / vendas mais antigas pelo número de endereços não são mais significativas com IPv6.
Considerando o acima, aqui estão as opções de tamanhos de atribuição aos clientes:
4.1. A / 48 para todos os clientes
Esta é minha recomendação, pois permite um plano de endereçamento muito simples e direto e, portanto, reduz o risco de cometer erros. Também tem a vantagem de que, se os clientes precisarem usar ULAs, ou se tiverem usado mecanismos de transição anteriormente, os tamanhos de prefixo coincidem e eles não precisam ter planos de endereçamento interno diferentes, pois são mapeados diretamente em cada prefixo diferente.
4.2. A / 48 para corporativo e a / 56 para residencial
É possível considerar a recomendação anterior apenas para clientes corporativos de alto padrão e então usar um / 56 para o resto, mas como explicado antes, este tipo de diferenciação de marketing / serviço não faz mais sentido em IPv6. Em um futuro próximo, isso significará que você será forçado a refazer seu plano de endereçamento e renumerar seus clientes, o que tem um custo. Se você não tiver espaço de endereço suficiente para atribuir um / 48 a todos os seus clientes, você pode voltar para o seu RIR e pedir mais, justificando com o plano de endereçamento completo. Como alternativa, você pode reservar um / 48 para cada cliente, mas na verdade atribuir a eles apenas um / 56, então, em vez de renumerar no futuro, você apenas aumentará o tamanho do prefixo.
4.3. Prefixos maiores que / 56
Esta é definitivamente a pior coisa que você pode fazer, por isso devo fortemente desaconselhar. Não há razão válida para atribuir prefixos mais longos do que / 56 a qualquer cliente.
Há um caso especial, fora do escopo deste documento, para um único / 64, única exceção possível às regras acima descritas, que são as redes celulares. Nessas redes, a cada contexto PDP de um smartphone ou dispositivo semelhante é atribuído um único / 64. No entanto, eles também podem usar DHCPv6-PD para solicitar prefixos mais curtos, como acontece no caso de modems / roteadores 3G / LTE, que muitas vezes são usados para fornecer banda larga em áreas onde nenhuma outra tecnologia oferece cobertura.
5. Conclusões
Fazer escolhas erradas ao projetar seu IPv6 A rede mais cedo ou mais tarde terá implicações negativas em sua implantação e exigirá mais esforços, como renumeração quando a rede já estiver em operação. A tentação de adotar abordagens “fáceis” para uma implantação mais rápida deve, portanto, ser resistida.
Como um conjunto genérico de recomendações, você deve considerar o seguinte:
5.1 IPv6 não é o mesmo que IPv4. em IPv6, você atribui um prefixo curto a cada site final, para que eles possam ter quantas sub-redes (/ 64s) forem necessárias. Você não deve se preocupar em exaurir o IPv6 endereçando espaço, e você deve pensar grande ao planejar requisitos futuros. Se precisar de mais espaço, você pode voltar para o seu RIR e, desde que seu plano de endereçamento justifique a necessidade, você pode obter mais IPv6 Endereços.
5.2 é fortemente desencorajado para atribuir prefixos maiores que / 56, então suas escolhas são:
- Minha recomendação e se você quiser um plano de endereçamento simples, atribua um / 48 para cada cliente. Isso funcionará muito bem para clientes vindos de outros ISPs, aqueles que têm seu próprio ULA ou têm usado mecanismos de transição. Isso também será mais fácil quando você tiver um mix de clientes usando a mesma infraestrutura, sejam eles clientes residenciais, PMEs ou mesmo grandes empresas.
- Diferencie os tipos de clientes, mesmo que isso aumente a complexidade de sua rede e a de seus clientes. Ofereça um / 48 para clientes empresariais e um / 56 para clientes residenciais. Conforme explicado, isso não é à prova de futuro e alguns novos protocolos não funcionarão, portanto, considere isso com cuidado, pois pode significar que mais cedo ou mais tarde você precisará refazer o plano e renumerar.
- Um acordo poderia ser reservar um / 48 para clientes residenciais, mas na verdade apenas atribuir-lhes o primeiro / 56.
5.3 Há um caso específico para telefones celulares, que devem ser atribuídos a um único / 64 para cada contexto PDP, mas isso está fora do escopo deste documento.
5.4 A fim de facilitar a solução de problemas e ter uma rede preparada para o futuro, você deve considerar numerar os links WAN usando GUAs (endereços globais de unicast), usando o primeiro prefixo / 64 do pool de clientes ou um / 64 de um pool dedicado de IPv6 prefixos. Se você decidir usar um / 127 para cada link ponto a ponto, é aconselhável alocar um / 64 para cada link e apenas usar um / 127 de fora dele.
5.5 Prefixos não persistentes são considerados prejudiciais em IPv6 como você não pode evitar problemas que podem ser causados por simples cortes de energia do cliente, atribuir prefixos persistentes é uma abordagem mais segura e simples. Além disso, isso evita a necessidade de registros dispendiosos, aumenta suas chances de oferecer novos negócios aos clientes e diminui a rotatividade de clientes.
Este artigo é parcialmente baseado no trabalho realizado no RIPE BCOP WG (Melhor Prática Operacional Atual para Operadores: IPv6 atribuição de prefixo para clientes finais - persistente vs não persistente e que tamanho escolher). Para o documento completo, veja MADURO BCOP WG.
Jordi Palet Martínez trabalha com informática, redes e tecnologia desde os 8 anos. Nos últimos 18 anos, ele foi CEO / CTO da “The IPv6 Company ”, onde dedicou a maior parte de seu tempo a IPv6 P&D, padronização, treinamento e consultoria.
