Autor: Roque Gagliano, LACNIC.
Resumo:
Este documento dá uma descrição de como implementar IPv6 num Ponto de Troca de Tráfego (pelas suas siglas IXP em inglês e comummente chamados também de NAP). Inclui informação sobre a configuração da matriz de comutação, as opções para o plano de direcionamento e operações gerais de gestão. Os IXPs são basicamente um dispositivo de nível 2 (a matriz de comutação) e em muitos casos a melhor recomendação diz que o tráfego e a gestão IPv6 não devem ser manuseados de forma diferente do que já se faz para IPv4.
Índice:
1- Introdução.
2- Configuração da matriz de comutação.
3- Direcionamento.
4- DNS Reverso.
5- Configuração de servidor de rotas.
6- Serviços internos e externos.
7- Políticas de um NAP sobre IPv6.
8- Multicast IPv6.
9- Agradecimentos.
10- Referências.
1- Introdução
A grande maioria dos Pontos de Troca de Tráfego (IXP) trabalha no nível 2, tornando a adopção de IPv6 uma tarefa simples. Contudo, os IXP normalmente implementam serviços auxiliares como por exemplo estatísticas, servidores de rotas, acesso a informação de rotas, ferramentas de controle sobre tráfego de broadcast que podem ser provocados pela adopção de IPv6. Em muitos casos, a melhor recomendação é não tratar o tráfego e a gestão de IPv6 diferente de IPv4. Este documento dá um guia geral sobre o impacto de IPv6 num IXP novo ou já em funcionamento, de uma forma que pode não se ajustar a uma implementação particular. No final do ano 2008, existe já uma vasta experiência operativa sobre IPv6 em IXP a nível global e muitas das experiências foram reunidas neste documento. O documento assume uma matriz de comutação Ethernet, ainda que possam existir outros dispositivos em funcionamento.
2- Configuração da matriz de comutação
A matriz de comutação é um dispositivo de nível 2 (em geral um switch), pelo que o tráfego IPv6 será comutado da mesma forma que o tráfego IPv4. Todavia, algumas funcionalidades de gestão podem precisar do suporte de IPv6. Estas funcionalidades podem incluir: gestão do equipamento, SNMP e análise de fluxos (flow).
Existem duas configurações típicas para o suporte de IPv6 nas portas de um IXP:
- VLAN pilha dupla: nesta configuração, o tráfego tanto de IPv4 como de IPv6 partilham uma mesma VLAN. Não é preciso configuração extra no switch. Em geral, os participantes do IXP configurarão as suas interfaces também como pilha dupla mas a configuração de portas independentes pode ser uma opção.
- VLAN independente: uma ou várias VLANs IPv6 são configuradas para o transporte do tráfego IPv6. Se os participantes de um IXP já tiverem portas etiquetadas no switch, esta configuração só requer a adição de novas etiquetas na mesma interface. Se os participantes utilizam ligações sem etiquetar, irão necessitar de uma porta separada e específica para a VLAN IPv6.
A configuração "VLAN independente" permite a separação física do tráfego IPv4 e IPv6, simplificando a análise diferencial do tráfego. No entanto, a configuração pode comportar maiores custos de capital (uma vez que possivelmente precisa de novas portas) e operacionais.
Por outro lado, a configuração em pilha dupla permite uma implementação de IPv6 livre de custos de capital, evitando a transformação de portas de acesso em portas etiquetadas. Nesta configuração, a separação do tráfego para a sua análise estatística pode se realizar através de técnicas baseadas em fluxos, em particular separando pelo campo "ethernet type" (0x0800 para IPv4 e 0x86DD para IPv6).
O suporte de pacotes com um MTU gigante deverá ser avaliado. O único requerimento técnico em IPv6 com relação ao MTU é o suporte para um tamanho de pacote maior ou igual a 1280bytes [RFC 2460]. Tamanhos típicos de MTU são: 1500 bytes, 4470bytes ou 9216bytes.
3- Direcionamento
Todos os Registros Regionais de Internet (RIRs) contam com políticas específicas para a atribuição de direções IPv6 independentes do provedor (PI) aos IXPs. Estas atribuições são geralmente de um /48 [RIR_IXP_POLICIES]. Dependendo do país e da região, a atribuição poderá ser realizada por um registro nacional de direções (NIR).
A partir do prefixo /48 atribuído, seguindo as recomendações do RFC 4291 [RFC4291], um prefixo /64 deveria ser atribuído a cada LAN do ponto de troca de tráfego. Um prefixo /48 permite a configuração de 65536 LANs. Prefixos mais longos (/65 a /127), são tecnicamente possíveis utilizando configuração estática de direções, mas deveriam ser em geral evitadas, de forma a manter a compatibilidade com o formato EUI-64 e CGA (Cryptographically Generated Addresses) [RFC3972]. Consideraremos então um prefixo /64 para cada LAN.
A prática usual para atribuição do identificador de interface é realizar uma configuração estática, desactivando a auto-configuração em cada interface. Também é importante que em uma LAN onde todos os nós presentes são routers, será preciso desactivar a funcionalidade de publicação de rotas (ou route advertisement do RFC4861) [RFC4861]. O objetivo é que nenhum router dessa LAN se configure a si mesmo como rota por defeito para o resto da LAN. Um equipamento de supervisão pode ser colocado na LAN para o tráfego às direções de multicast locais do link (ff02::/16), permitindo apenas o tráfego ICMPv6 para o descobrimento de vizinhos (mensagens ICMPv6 Neighbor Solicitation e Neighbor Advertisement).
Quando seleccionando o uso de identificadores de interfaces (IID) estáticos, existindo diferentes opções de como atribuir "inteligentemente" estes 64 bits (ou 16 caracteres hexadecimais). Seguidamente, apresentamos uma lista não exaustiva de mecanismos de selecção dos IID:
- Alguns IXP incluem o número de ASN dos participantes, dentro de cada direção IPv6. O número de ASN decimal é representado através da codificação binária decimal (ou BCD) conseguindo uma leitura mais fácil, conforme o seguinte exemplo:
IXP LAN exemplo: 2001:DB8::/64
ASN: 64496
Direção IPv6: 2001:DB8::6449:6000:0000:0001/64 ou sua representação equivalente 2001:DB8::6:4496:1/64
Por favor, lembre-se de que para o caso de ASNs de 32 bits, é necessário um máximo de 10 caracteres. Ao ter disponíveis 16 caracteres para cada ASN é possível configurar até 2^16 direções IPv6.
- Apesar de a representação BCD ser mais facilmente lida por uma pessoa, alguns IXP preferem o uso da codificação hexadecimal do número de ASN, da seguinte forma:
IXP LAN exemplo: 2001:DB8::/64
ASN: 64496 (DEC) or FBF0 (HEX)
Direção IPv6: 2001:DB8::0000:FBF0:0000:0001/64 ou sua representação equivalente 2001:DB8::FBF0:0:1/64
Os quatro zeros em frente ao ASN (bits 63-96) serão utilizados para os ASNs de 32 bits.
- Se alcança um terceiro esquema para a atribuição de direções IPv6 em forma estática aos participantes relacionando uma porção da sua direção IPv6 com a sua direção IPv4. No seguinte exemplo, os últimos três decimais da direção IPv4 são copiados dos três últimos caracteres IPv6, utilizando a codificação BCD:
IXP LAN exemplo: 2001:DB8::/64
Direção IPv4: 240.0.20.132/23
Direção IPv6: 2001:DB8::132/64
- Um quarto mecanismo pode ser vincular o IID IPv6 com o ID interno do participante no IXP.
A mesma prática utilizada na actualidade pelo IXP com relação à publicação dos seus prefixos IPv4 na DFZ (zona livre de rota por defeito de Internet) também deve ser utilizada para IPv6. Serviços externos (como por exemplo: dns, página web ou servidor ftp) poderão fazer parte do prefixo atribuído ao IXP ou de outro prefixo. Tenha em conta que os prefixos para IXP podem não passar filtros estritos de prefixos ao ser dargo /48, embora se encontrem descritos nas páginas web de registro.
4- Reverso DNS
O administrador do IXP deverá configurar os registros PTR de todas as direções IPv6 atribuídas a participantes na zona reversa "ip6.arpa".
5- Configuração de Servidor de Rotas
Alguns IXPs oferecem o serviço de Servidor de Rotas (ou "route server"), seja para para serviços de gestão (ou "looking glass") como para suportar acordos de Peering Multilateral (MLPA). O suporte a IPv6 precisa ser adicionado aos router utilizados como extremos BGP. O equipamento a utilizar tem que suportar o transporte de tráfego IPv6 e as extensões de BGP Multiprotocolo (MP-BGP) para a família de direções IPv6 (RFC 2545 e RFC 4760).
Uma boa prática é trocar a informação de alcançabilidade IPv6 sobre sessões também estabelecidas sobre IPv6/TCP e independentes das sessões IPv4. Esta configuração permite, caso exista um problema de alcançabilidade com qualquer vizinho IPv6, a sessão cairá, sem afectar a sessão IPv4. Por favor, considere o uso de MD5 (e melhor IPSEC) para autenticar a sessão BGP.
No caso de oferecer o serviço de Looking Glass, o mesmo deverá estar disponível para o seu acesso externo por via de IPv6, seja através de uma página web ou de uma consola terminal.
6- Suporte para serviços internos e externos
Já foram mencionados alguns serviços externos que necessitam de suporte IPv6, como por exemplo gráficas de tráfego, servidores DNS, FTP, Web e Looking Glass. Outros serviços como servidores NTP ou SIP gateways também deverão ser avaliados. Em geral, o comportamento em IPv6 de qualquer serviço que se acede através de IPv4 ou que manipula direções IPv4 deverá ser estudado.
Serviços internos também são importantes quando se estuda a adopção de IPv6 em um IXP. Estes serviços podem não ter interação com tráfego IPv6 mas manipular direções IPv6, como é o caso do sistema de estoque, de análise de logs e estatísticas. Bases de dados e respectivas ferramentas também deverão ser avaliadas para determinar o seu suporte de IPv6.
7- Políticas de um IXP em IPv6
As políticas internas de um IXP (ou regulamento interno) deverão ser revistas para estudar se existe alguma menção ao protocolo IP e determinar se a referência é genérica ou específica para IPv4 ou IPv6. A interpretação actual é que IP se refere ao Protocolo de Internet, independentemente de sua versão ser IPv4 ou IPv6. No caso de contratos e regulamentos de usos, se deverão rever também para alcançar a adequação dos termos IP, IPv4 e IPv6.
Poderão ser necessárias políticas específicas para IPv6 para o controle de ICMPv6 Route Advertisements ou controle do tráfego Multicast local do link ou da ligação de Peering Multilateral (MLPA).
Tal como em IPv4, o êxito do IXP será medido pela quantidade relativa de tráfego através da sua matriz de comutação e de participantes ligados. Para conseguir a incorporação de participantes IPv6, é necessário realizar tarefas de difusão que poderão incluir:
- Anúncio da existência do serviço IPv6 na página de início do IXP e através de um comunicado de imprensa.
- Anúncio da existência do serviço IPv6 mediante o anúncio em listas de correios.
- Incluir na lista de participantes que se anuncia na web do IXP quais os participantes que se encontram ligados em IPv6.
- Incluir informação IPv6 em bases de dados como peeringdb.com ou napla.lacnic.net.
8- Multicast IPv6
Multicast IPv6 não é diferente desde o ponto de vista de um IXP a multicast IPv4. Novamente, um IXP pode decidir utilizar uma VLAN reservada para o tráfego multicast ou trocar o tráfego multicast na mesma VLAN que o tráfego unicast. Como já foi mencionado no documento, o tráfego multicast local ao link pode ser supervisionado para o reduzir apenas ao descobrimento de vizinhos ICMPv6 [RFC4861] e ao protocolo MLD (Multicast Listener Discovery) [RFC 3810].
9 - Agradecimentos
Gostaria de agradecer a colaboração das seguintes pessoas: Martin Levy (Hurricane Electric), Carlos Friaças da FCCN (GIGAPIX), Arien Vijn (AMS-IX), Louis Lee (Equinix) e Bill Woodcock (PCH).
10 - Referências
[RIR_IXP_POLICIES] RIRs Allocations Policies for IXP. NRO Comparison matrix: http://www.nro.net/documents/comp-pol.html#3-4-2.
[RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC3810] L. Costa, Ed, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4861] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
