Rede IP II: Melhores Práticas de Migração de Rede IPv4 para IPv6

Rede IP II: Melhores Práticas de Migração de Rede IPv4 para IPv6 Com o crescimento de aplicações como Ponto a Ponto e videoconferência, e com a necessidade de computadores sempre conectados e disponíveis, o novo protocolo IPv6 fará a substituição gradual do atual IPv4 que, num futuro próximo, se tornará inviável por escassez de endereços. Esta série de tutoriais tem como finalidade servir de referência ao processo de migração da tecnologia IPv4 para IPv6 de uma rede local gerenciada, de tamanho médio ou grande, e aos problemas relacionados à mesma. Configura-se, portanto, como conjunto de documentos para subsidiar as ações de um administrador de rede. O protocolo IPv6 não só aumenta a quantidade de endereços como também possui diversos benefícios sobre o IPv4, sendo esses descritos neste documento. A abordagem adotada neste trabalho trata, especificamente, da implantação em uma rede com serviços comumente utilizados, mostrando de forma prática e com análises a sua migração. Os tutoriais foram preparados a partir do trabalho de graduação Melhores Práticas de Migração de uma Rede IPv4 para IPv6, elaborado pelos autores, e apresentado ao Curso de Engenharia Elétrica com ênfase em Telecomunicações do Instituto de Educação Superior de Brasília como requisito parcial à obtenção do título de Engenheiro Elétrico. Foi orientador do trabalho o Prof. Eduardo Wolski. Este tutorial parte II apresenta os 8 cenários previstos para os testes realizados no laboratório e as configurações adotadas, os resultados dos testes realizados e, por fim, as melhores práticas para que a migração seja feita de forma estável, segura e eficiente. Alexandre José Camilo Gomes.. Email: alexjcgdf@gmail.com 1

Carlos Botelho da Trindade.. Categoria: Banda Larga Nível: Introdutório Enfoque: Técnico Duração: 20 minutos Publicado em: 13/02/2012 2

Rede IP II: Introdução Em 1969, a ARPANET foi criada com a intenção de interligar centros de pesquisa nos Estados Unidos e foi o grande marco para o avanço das redes de telecomunicações, culminando na criação do que hoje é conhecido como Internet e na utilização extensiva do IPv4. O IPv4 suportou a interligação entre redes em nível global, tendo a Internet atingido a dimensão que hoje se conhece. Devido ao recente crescimento exponencial da Internet e seus usuários e equipamentos on-line e do surgimento da Web2.0, o IPv4 não será mais capaz de suprir esse potencial aumento do número de utilizadores ou das necessidades geográficas da expansão da Internet. Segundo a Internet Assigned Numbers Authority (IANA), restam cerca de 11% de endereços IPv4 disponíveis no mundo (fonte: http://www.inetcore.com/project/ipv4ec/index_pt.html). O tempo de vida do IPv4 vem se estendendo pelo uso de técnicas paliativas para a reutilização de endereços, tais como o Network Address Translation (NAT), Classless Interdomain Routing (CIDR), e atribuições de endereços de forma temporária com o serviço Dynamic Host Configuration Protocol (DHCP). Essas técnicas surgiram para aumentar o espaço de endereçamento e satisfazer o tradicional modelo cliente/servidor, mas não cumprem os requisitos da verdadeira mobilidade entre rede e utilizador, assim como o novo modelo emergente de serviços voltados ao Peer to Peer (P2P), onde todos passam a serem clientes e servidores em determinado nível de serviço. Às aplicações têm sido fornecidas maiores larguras de banda, e delas é demandada melhor desempenho. A necessidade de ambientes sempre disponíveis proíbe estas técnicas de conversão e de alocação temporária de endereços IP, feitas hoje pelo DHCP. Além disso, o plug and play requerido pelas aplicações aumentam, significativamente, o requisito do protocolo, de forma a facilitar a utilização dos equipamentos. Milhões de novos dispositivos tecnológicos não serão capazes de obter endereços IPv4 globais, e isso é inapropriado para os novos serviços emergentes. O IPv4 chegará, brevemente, à fase em que tem de ser feita a escolha entre novas capacidades ou uma rede maior, mas não as duas. Por outras palavras, faz-se necessário um novo protocolo para fornecer características novas e melhoradas, além de resolver o problema da escassez de endereços IP. Esse novo protocolo é o IPv6. O IP versão 6, ou na sua forma abreviada IPv6, é a nova versão do protocolo de Internet para substituir o atual IPv4. Apesar da escassez do espaço de endereçamento IPv4 ter sido a razão principal para o desenvolvimento de um novo protocolo, os arquitetos do IPv6 adicionaram novas características em um conjunto de aperfeiçoamentos críticos do IPv4. Neste trabalho serão apresentados os vários aspectos do protocolo, incluindo endereçamento, autoconfiguração e coexistência entre IPv4 e IPv6. Considerando o cenário apresentado, este trabalho tem como escopo a elaboração e verificação, por meio de estudo, observação, implantação e testes, de regras de melhores práticas para uma migração de uma rede IPv4 para uma rede mista (IPv4/IPv6) e, futuramente, IPv6 pura, minimizando os impactos e falhas de segurança, considerando os serviços mais comumente usados em uma rede, assim como a interação com equipamentos legados IPv4 puros. O objetivo geral do trabalho é, portanto, elaborar e verificar regras de melhores práticas na migração de uma rede IPv4 para IPv6, tanto na questão executiva, quanto na questão de segurança, considerando que será necessário que se tenha um ambiente de convivência entre as duas versões do protocolo. Os objetivos específicos são os seguintes: Estudar a arquitetura do IPv6 e suas diferenças em relação ao IPv4; Estudar as formas de interação de coexistência entre as duas tecnologias; Estudar quais são os serviços que sofrem alterações com a migração; 3

Implementar, em laboratório, os serviços que interagem, diretamente, com endereçamento da camada de redes: DNS, DHCP; Avaliar o impacto da migração na segurança da rede; Avaliar o impacto da migração no desempenho da rede; Levantar requisitos importantes para as mudanças em um projeto de migração; Elaborar um documento para auxiliar uma migração de forma estável e segura, tendo como público-alvo os administradores de redes. Tutoriais O tutorial para I apresentou um histórico da evolução do protocolo IPv6, comparando com o protocolo IPv4, de utilização atual, demonstrando as características do novo protocolo, como a nova formação do endereçamento, mudança do cabeçalho, dos serviços básicos, aumento da segurança e a coexistência entre os dois protocolos. Foram vistos, também, os processos de uma migração, mecanismos de interoperação e tradução, desempenho e problemas conhecidos da migração. Este tutorial parte II apresenta os 8 cenários previstos para os testes realizados no laboratório e as configurações adotadas, os resultados dos testes realizados e, por fim, as melhores práticas para que a migração seja feita de forma estável, segura e eficiente. 4

Rede IP II: Configurações do Ambiente de Teste Os cenários que impulsionam a migração de IPv4 para IPv6 serão descritos a seguir, assim como as configurações realizadas nos ativos do laboratório para execução dos testes e será considerada a implantação dos serviços relevantes à migração. Cenários Os cenários e os desenvolvimentos propostos a seguir consideram os seguintes aspectos: Os interessados neles são os administradores de rede do cliente e a operadora de Telecom; A abrangência interna (LAN) é de inteira responsabilidade do administrador de rede do cliente; A abrangência do Link Dedicado, roteadores do backbone e a interface externa do roteador CPE são de inteira responsabilidade da operadora de Telecom; Toda a parte de tratamento dos dados assim como a tradução dos endereços nas duas versões no backbone da operadora não fará parte do escopo do trabalho; O túnel Broker (exemplo: Freenet), que é utilizado para acesso externo e que suporta o Link IPv6 do cliente, é de responsabilidade de terceiros, já que não temos influências em seu funcionamento; As configurações dos SO s e equipamentos estão delimitadas à interface interna do CPE; Todos os cenários são considerados como etapas de um processo maior, que tem por objetivo migrar todos os hosts IPv4 para uma rede IPv6 pura. A tabela a seguir representa as possíveis variações dos cenários em relação ao domínio do administrador de rede (ADM) e da operadora de Telecom (OP). As siglas v6, v4 e v4v6 significam as interações utilizadas e significam, respectivamente, IPv6, IPv4 e dual-stack IPv4/IPv6. Os números na tabela denotam o número do cenário. Tabela 1: Cenários para implantação de redes ADM V4 ADM V4V6 ADM V6 OP v4 0 3 6 OP v4v6 1 4 7 OP v6 2 5 8 O seguinte ambiente foi montado em laboratório para os testes dos cenários apresentados. As configurações dos ativos foram alteradas para se encaixarem em cada tipo de cenário e serão descritas em cada caso, respectivamente. 5

Figura 1: Ambiente de Laboratório O ambiente montado no laboratório possui os seguintes equipamentos sistemas operacionais: Tabela 2: Configuração dos ativos NOME DO ATIVO OS VERSÃO IPV4 IPV6 FINALIDADE Gandalf Linux 2.6.26 SIM SIM Roteador/Servidor/Firewall Legolas ix Embedded Dlink XXXX SIM NÃO* Access-Point Pippin ---------- -------- ----- ------- HUB Aragorn ix Embedded 3Com SIM SIM SWITCH - GERENCIAVEL Gimli ix Embedded HP SIM NÃO Impressora de rede Frodo Linux 2.6 SIM SIM Desktop Sam Linux 2.4 SIM SIM Desktop Arwen Linux 2.6 SIM SIM Desktop/Sniffer Faramir Windows Vista SIM SIM Desktop Isildur Windows XP SP3 SIM SIM** Desktop * Para suporte ao protocolo IPv6 é necessário upgrade de firmware do fabricante. **Suporte parcial a serviços IPv6 (Não suporta DHCPv6). Cenário 0 Administrador utiliza IPv4 e a operadora fornece IPv4. 6

Este é um cenário mais utilizado hoje em dia, e mostra exatamente, a situação que precede o início de uma migração. Este cenário considera que o administrador utiliza, em sua rede, IPv4, e a operadora fornece também IPv4, sendo a solução mais utilizada no funcionamento das redes e do backbone das operadoras. Por decisão do administrador, configura-se a utilização de um túnel Broker para ter acesso à rede IPv6 e, assim, prover acesso à rede IPv6 para sua LAN, através de um tradutor (4to6) configurado em seu CPE (Cliente Provider Equipament). Sua configuração, neste caso, está baseada somente no CPE. Cenário 1 Figura 2: Cenário 0 Rede Interna e operadora IPv4 - túnel Broker IPv6 Administrador utiliza IPv4 e a operadora fornecerá IPv4 e IPv6 (dual-stack). Neste cenário, o ADM continua operando com sua rede v4 pura e a operadora passa a fornecer v6 e v4, tendo que configurar um tradutor no CPE, para que ele possa ter comunicação com as redes IPv6, tendo como origem as máquinas internas IPv4, fazendo a tradução (4to6), de IPv4 para IPv6. O administrador, neste caso, não fará nenhuma alteração em sua rede, mas terá acesso aos sites/serviços IPv6 puros através da configuração (dual-stack) feita em seu CPE pela operadora de Telecom. Cenário 2 Figura 3: Cenário 1 Rede Interna IPv4 e operadora IPv4 e IPv6 (dual-stack) Administrador só utilizará IPv4 mas a operadora só poderá fornecer IPv6. Neste cenário, a operadora fornecerá para o cliente somente endereçamentos IPv6 e deverá configurar, na interface externa do CPE, um tradutor (4to6) para a rede IPv4 do cliente. A operadora terá, também, a 7

responsabilidade de fazer o tunelamento (6to4), caso o cliente deseje algum site/serviços que seja IPv4 puro, e este seja externo ao backbone da operadora. Neste caso será necessária a funcionalidade de um Broker dentro da operadora de Telecom. Entretanto, consideramos que este é um cenário futurista onde o link disponibilizado pela operadora fornecerá apenas IPv6 puro, já que o processo de migração será gradativo e ainda existirão diversos sites/serviços com acessos apenas em IPv4. Figura 4: Cenário 2 Rede Interna IPv4 e operadora IPv6 Cenário 3 Administrador inicia migração de sua rede IPv4 para IPv6 utilizando-se do recurso de dual-stack e a operadora ainda fornece somente IPv4. Neste caso, a configuração de dual-stack da rede interna é de inteira responsabilidade do administrador de rede. Ele também será o responsável pela configuração das rotas e contas para a utilização do túnel Broker IPv6, já que a operadora fornecerá apenas endereços IPv4, e sua responsabilidade se limita às rotas e configurações IPv4. Para acesso aos sites IPv6, os hosts internos que possuírem dual-stack configurados sairão pela rota obtida com o túnel Broker, e poderão ter acessos aos sites IPv6 puros, assim como aos sites IPv4 puros. Os hosts internos que são IPv4 puros só conseguirão acesso à rede IPv6 se o administrador configurar um tunelamento no CPE para esses hosts. Esse cenário é montado por iniciativa tão somente do administrador, visando preparar sua rede para o futuro, quando a operadora passará a fornecer endereços IPv6, porém, nestas circunstâncias, a configuração será transparente para a operadora de Telecom. Figura 5: Cenário 3 Rede Interna IPv4 e IPv6 (dual-stack) e operadora IPv4 8

Cenário 4 Administrador utiliza IPv6 e IPv4 em dual-stack enquanto a operadora fornece IPv4 e IPv6 também em dual-stack. Neste cenário, tanto o Administrador quanto a operadora utilizam dual-stack IPv4/IPv6 em suas redes. A responsabilidade de migração, neste caso, é igualmente dividida entre as duas partes, e ela acontece sem a necessidade da utilização de tradutores (4to6 ou 6to4), pois tanto a rede LAN quanto o CPE terão os dois endereçamentos. Essa abordagem será a mais comum em uma transição conjunta, já que os sites redes IPv4 continuarão a existir por um longo período e serão criadas novas rede IPv6. Cenário 5 Figura 6: Cenário 4 Rede Interna e operadora IPv4 e IPv6 (dual-stack) Administrador utiliza IPv6 e IPv4 em dual-stack enquanto a operadora fornece somente IPv6. Neste cenário, a operadora fornecerá para o cliente somente endereçamentos IPv6, e deverá configurar na interface externa do CPE um tradutor (4to6) para a rede IPv4 do cliente. O administrador migrará sua rede e fará uso da funcionalidade dual-stack. A operadora terá a responsabilidade de fazer a tradução (6to4), caso o cliente necessite acessar sites/serviços que sejam IPv4 puro, e esteja externo ao backbone da operadora, sendo necessária a utilização de um Broker dentro da operadora de Telecom. Este, no entanto, é também um cenário futurista, em que o backbone da operadora opere apenas com IPv6 puro. Figura 7: Cenário 5 Rede Interna IPv4 e IPv6 (dual-stack) e operadora IPv6 Cenário 6 Administrador utiliza somente IPv6 em sua rede e a operadora fornece somente IPv4. Neste cenário, a configuração IPv6 da rede interna é de inteira responsabilidade do Administrador. Ele 9

também é responsável pela configuração das rotas e contas para a utilização do Broker IPv6, já que a operadora fornecerá apenas endereçamentos IPv4 e sua responsabilidade se limita às rotas e configurações IPv4. Para acesso aos sites/serviços IPv6 os hosts internos sairão pela rota obtida com o túnel Broker e poderão ter acessos aos sites IPv6 puros, assim como a redes IPv4, através de um tradutor (6to4) configurado no CPE pelo Administrador. Esse cenário é montado por iniciativa tão somente do Administrador sendo transparente para a operadora de Telecom. Cenário 7 Figura 8: Cenário 6 Rede Interna IPv6 e operadora IPv4 Administrador utiliza somente IPv6 em sua rede e a operadora fornece IPv6 e IPv4 em dual-stack. Neste cenário, a operadora fornecerá para o cliente somente o IPv6 e deverá configurar, na interface externa do CPE, um tradutor (6to4) para acessos às redes IPv4 externas ao backbone. O Administrador migrará sua rede para IPv6 puro. A operadora terá, também, a responsabilidade de fazer a tradução (6to4), caso o cliente esteja tentando acessar algum site que seja IPv4 puro e seja externo ao backbone da operadora. Um Broker deverá funcionar dentro da operadora de Telecom. Cenário 8 Figura 9: Rede Interna IPv6 e operadora IPv4 e IPv6 (dual-stack) Administrador utiliza somente IPv6 em sua rede e a operadora fornece somente IPv6. Neste cenário, tanto o Administrador quanto a operadora utilizam IPv6 em suas redes. A responsabilidade de migração, neste caso, é igualmente dividida entre as duas partes. A operadora terá a responsabilidade de fazer a tradução (6to4), caso o cliente necessite acessar algum site/serviço que seja IPv4 puro e seja externo ao backbone da operadora. Um Broker deverá funcionar dentro da operadora de Telecom. Este, no entanto, é também um cenário futurista, em que o backbone da operadora opera apenas com IPv6 puro. 10

Configurações Realizadas Figura 10: Cenário 8 Rede Interna e operadora IPv6 Foram efetuadas configurações nos equipamentos do laboratório, considerando o layout físico apresentado na topologia da figura 1 e os layout s lógicos apresentados, referentes aos possíveis cenários descritos acima. Para que todos estes cenários fossem devidamente testados, as configurações feitas tiveram o intuito de facilitar a diferenciação de um cenário para outro, para isso bastando apenas retirar ou inserir alguns dos equipamentos, de forma a simular os diferentes aspectos de cada cenário. No laboratório, o servidor DNS, DHCPv4, DHCPv6, cliente Broker, Firewall (IPv4 e IPv6) e Gateway NAT estão agrupados na mesma máquina, que chamamos de Roteador de Borda. Nesta seção, será detalhada somente a configuração desta máquina, por ser o equipamento de maior importância e relevância nos testes de migração realizados nos laboratórios. Para a rede interna, chamada de LAN do laboratório, a técnica adotada de interação entre as duas versões de IP foi o do dual-stack (configurado somente nos equipamentos que a suportam). Para a saída WAN, interface externa do roteador de borda, foi adotada a saída pública IPv4 com apenas um endereço IP e o Broker IPv6 com um prefixo /48. A técnica utilizada na parte WAN, apesar de se utilizar o Broker, pode ser considerada também como de dual-stack, pois, apesar de se utilizar um túnel para alcançar a Internet IPv6, para o roteador de borda é como se ele possuísse também as duas versões de IP em sua pilha. Roteador de Borda Sistema Operacional utilizado e sua distribuição O roteador de borda foi configurado em uma máquina com sistema operacional LINUX da distribuição Gentoo (www.gentoo.org). O Gentoo é uma distribuição Linux muito utilizada para servidores dedicados, por ser uma distribuição completamente moldada ao hardware utilizado. Todo o sistema operacional e programas podem ser instalados a partir dos fontes e as opções referentes aos mesmos podem ser habilitadas ou não a critério da necessidade do administrador do sistema. O Gentoo utiliza um sistema de árvore, atualizado online, conhecido como Portage, com a finalidade de buscar o código-fonte dos programas e suas dependências, habilitar ou desabilitar parâmetros e diversas outras opções e, então, fazer a sua instalação no sistema operacional. Tudo isso é feito de forma automática e transparente e, com isso, os programas e o próprio sistema operacional se tornam mais secos e limpos, diminuindo a opção de suporte às características desnecessárias e aumentando, assim, a disponibilidade, a escalabilidade e a robustez do sistema como um todo. O Portage possui uma classificação para determinar a estabilidade do programa referente, conjuntamente com a arquitetura do processador do sistema. A arquitetura utilizada no laboratório é para processadores padrão x86, apesar de suportar diversos padrões de arquitetura como o x64, 11

ppc, hppa, entre outros. Os parâmetros de arquitetura observados no Portage para os programas é o x86 para programas estáveis, e ~x86 para programas que ainda não foram considerados estáveis pela comunidade desenvolvedora do GENTOO. Configuração do Roteador de Borda O roteador de borda deverá possuir, ao final, as configurações como demonstrada na figura abaixo e, para tanto, as configurações do sistema operacional, assim como dos serviços, serão mostradas neste tópico. Figura 11: Roteador de borda A figura acima representa o roteador de borda e suas interfaces de rede em suas respectivas zonas de atuação. A interface eth1 juntamente com a interface virtual associada sit1 estão na zona LAN da máquina, ou seja, são as interfaces ligadas diretamente com a rede local do laboratório. Repare que a interface eth1 possui o sistema de pilha-dupla. A interface virtual sit1, apesar de estar associada à eth1, é considerada pelo sistema como uma interface independente. Esta interface é criada pelo script do Broker e mais informações sobre seu funcionamento serão dadas mais a frente. A interface de loopback está associada à zona interna do roteador, e se refere aos serviços internos do próprio sistema. Repare que a interface de loopback possui, também, dual-stack. A interface eth0 está associada à zona WAN. Esta interface está ligada à operadora de Telecom e possui um IPv4 público. O endereço IPv6 existente na interface é somente o endereço criado pelo sistema, automaticamente, com o endereço MAC da interface eth0. 12

Para ter as configurações e os recursos necessários para se montar o layout lógico do roteador de borda como o da figura 11, primeiramente, foi sincronizada a árvore de fontes dos programas da distribuição Gentoo. Sincronia da árvore do Portage Emerge Sync A sincronia da árvore do Portage pode ser feita diariamente, caso se queira, pois as versões estáveis dos softwares são atualizadas constantemente, sendo que as versões instaladas no servidor para a implementação do laboratório têm data de 07 de agosto de 2008, e o arquivo obtido através do comando de sincronia da árvore do Portage é portage-20089807.tar.bz2. Ocorre, então, que os programas utilizados na montagem do roteador de borda no laboratório foram configurados com as suas versões como as colocadas nos itens de configuração a seguir. Deve ser observado, também, que os arquivos de configurações são relacionados as suas respectivas versões, e os arquivos de configuração podem sofrer alterações no decorrer da mudança das versões. Outro fato a ser observado é referente à estabilidade da versão disponível no Portage. As versões instaladas no laboratório são as versões mais recentes e consideradas estáveis dos aplicativos. Obviamente, existem versões mais recentes no Portage, porém não são consideradas estáveis e podem existir softwares, como o DHCPv6, que não possuem versões consideradas estáveis e, neste caso, foram instaladas as versões mais atuais disponíveis. Finalizada a sincronia da árvore, alguns serviços (softwares) foram instalados com o seguinte comando: # USE= IPv6 emerge vanilla-sources udhcp radvd bind dhcpv6 freenet6 shorewall iptables Note que, no comando acima o parâmetro USE= IPv6 serve para adicionar suporte ao IPv6, caso existente, na compilação dos fontes dos programas a serem instalados. A partir de então, os softwares instalados, que possuírem suporte à IPv6, estarão com o mesmo habilitado. Os programas instalados com o comando acima serão descritos a seguir, junto com o seu versionamento, utilidade e configurações: Programas Instalados Kernel sys-kernel/vanilla-sources-2.6.20 - Versão 2.6.20 x86 O kernel vanilla é o kernel puro, como o encontrado no site de desenvolvimento do kernel (www.kernel.org), sem qualquer patch ou modificações, muito comuns nos kernel das distribuições Linux. A forma de se compilar um kernel não será tratado por não fazer parte do escopo deste trabalho. Note que, apesar da opção IPv6 fornecida no comando de instalação, habilitar suporte ao IPv6, no caso do kernel, esse suporte deve ser atribuído e compilado manualmente. DHCPv4 net-misc/udhcp-0.9.8-r3 x86 O UDHCP é um servidor simples de DHCPv4, em sua implementação. Basta somente indicar a interface de 13

rede no qual o serviço DHCP vai ficar ouvindo as requisições e o pool de endereços que serão disponibilizados para os clientes DHCP. No laboratório foi utilizado o pool 192.168.0.20-254/24, o servidor DNS foi configurado como 192.168.0.1 (o próprio firewall), e o gateway padrão foi configurado como 192.168.0.1. A figura abaixo mostra as partes do arquivo de configuração udhcp.conf que contêm essas configurações. Router Advertisement Daemon net-misc/ radvd-1.1 x86 Figura 12: Configuração UDHCP O RADVd é o daemon responsável pelo serviço de RA emitido pelo roteador de borda para os clientes IPv6 da rede interna. Não é necessária sua configuração direta, já que todos os parâmetros colocados no arquivo gw6c-rtadvd.conf, que substitui o arquivo padrão de configuração do RADVd, o radvd.conf, são criados, e suas configurações são inseridas, automaticamente, pelo programa do túnel Broker, o Freenet6, como mostrado na figura 13. Figura 13: Configuração Gateway6 Note que o prefixo 2001:05c0:1105:0900::/64 foi inserido pelo cliente do túnel Broker ao arquivo de configuração, de forma que o RA enviado aos clientes IPv6 da rede sempre possuam o prefixo fornecido pelo Broker. Apesar da configuração do arquivo do RADVd ser feita pelo cliente do Broker, a responsabilidade do envio do prefixo correspondente, além dos parâmetros de configuração automática de IP (Stateless ou Statefull) é de responsabilidade do RADVd. Para que os clientes IPv6 da rede buscassem algumas configurações do DHCPv6 (no caso, a única configuração imprescindível é o endereço do Servidor DNS), foram feitas configurações no cliente do Túnel Broker e que serão descritas no tópico a seguir. Sua inicialização é feita, automaticamente, pelo script linux.sh executado pelo cliente Freenet6. Túnel Broker (freenet6) net-misc/ freenet6-5.1 x86 14

O Freenet6 é um cliente para o Tunnel Broker da organização Go6 chamado Freenet6 (http://go6.net /4105/freenet.asp). O Freenet6 é um Broker para a Internet IPv6, utilizando a tecnologia de tunelamento descrita no tutorial parte I. Diferentemente da maioria dos túneis Broker s gratuitos disponíveis, o Freenet6 utiliza um modelo cliente/servidor para a autenticação e manutenção do túnel, ao invés de páginas WEB de autenticação. Uma conta (usuário e senha) é necessária ser criada no site do Broker de forma gratuita, e os parâmetros passados pelo site devem ser colocados no cliente Freenet6, instalados no Roteador de borda da rede. A instalação do programa Freenet6 fornece dois arquivos importantes para a configuração do cliente do túnel e, por consequência, do RADVd. Os arquivos são: Gw6c.conf arquivo no qual as configurações do comportamento e parâmetros de funcionamento do cliente do túnel Broker são configuradas, como, por exemplo, a verbosidade do arquivo de log e sua localização, o usuário e senha da conta com o Broker, a configuração do keepalive da conexão, e diversos outros parâmetros. Linux.sh o arquivo linux.sh é encontrado na pasta /etc/freenet6/templates/ e se refere aos parâmetros do RADVd e de sua inicialização efetuado pelo cliente Freenet6, após a sua autenticação e o fechamento do túnel com o Broker. Este arquivo é de suma importância apesar de não se falar muito a respeito do mesmo nos sites de referência, devendo-se adicionar uma linha ao arquivo, para que o RA emitido pelo Roteador de borda possua a flag do DHCPv6 habilitada, permitindo, assim, que os clientes IPv6 da rede interna procurem mais configurações de rede (no caso, o endereço do servidor DNS) junto ao DHCPv6. Figura 14: Configuração RADVd Com a inserção da opção AdvOtherConfigFlag, acima mostrada, os pacotes RA emitidos pelo RADVd passaram a ter a flag de configuração pelo DHCPv6, como mostrado nas figuras abaixo, referentes à captura dos pacotes RA pelo sniffer. 15

Figura 15: Indicação do pacote RA desabilitado A figura acima mostra a flag desabilitada e, abaixo, a diferença quando se é adicionada a linha de configuração para a habilitação da flag: Figura 16: Indicação do pacote RA habilitado O serviço de túnel então é inicializado através do comando: # /./etc/ini.d/gw6c start Na tela de Log do RADVd (figura 17) é mostrada a inicialização do túnel, assim como a criação das rotas, utilizando-se o prefixo obtido pelo Broker: 16

Figura 17: Inicialização do túnel Broker Uma observação importante sobre a figura acima é a habilitação do roteamento no IPv6. Este roteamento é totalmente independente do IPv4 que, no caso, já estava previamente habilitado, caracterizando a independência das duas pilhas, ou seja, as regras e procedimentos criados para o IPv4 são completamente separados das regras e procedimentos para o IPv6. Efetuada, então, a inicialização do túnel, a tabela de endereçamento IP dada pelo comando ifconfig será mostrada a seguir, porém ela estará dividida de forma a um melhor entendimento e explanação: Figura 18: Configuração da interface Eth0 rede WAN Executado o comando ifconfig, a primeira interface mostrada é a eth0. Como visto no layout do Firewall, é a interface de rede WAN e a que recebe um endereço IPv4 público da operadora. Como o kernel compilado possui suporte à IPv6, a interface é também inicializada com um IPv6 montado pelo próprio sistema, através do prefixo escopo link local (que não é roteável) FE80::2, e, no resto, do endereço MAC da interface de rede. Note que, depois de um endereço IPv6, vem sempre uma referência ao escopo a que ele pertence que, no caso acima, é Link, ou seja, é um endereço de rede local. A figura 19 mostra a parte da interface eth1. Essa é a interface interna (LAN) do firewall, e é nessa interface que o túnel junto ao Broker é associado. É nessa interface, também, que o RADVd (gerador de RA s) emite os pacotes referentes ao endereço IPv6 recebido pelo Broker. O primeiro endereço que aparece na interface eth1 é o IPv4 192.168.0.1/24. Esse endereço faz parte da pilha dupla IPv4/IPv6 dessa máquina. O segundo endereço é um IPv6. Esse é o endereço recebido pelo Broker e totalmente construído pelo mesmo (não tem nenhuma parte do endereço MAC da interface). Os próximos 3 endereços que aparecem na figura são endereços IPv6, inseridos de forma manual para a interface. Esses endereços são necessários para o Windows XP, que não possui suporte ao DHCPv6, e assume, automaticamente, esses endereços como sendo o do DNS da rede. O ultimo endereço é o link local, montado com o prefixo fe80::2 e o MAC da interface de rede. 17

Figura 19: Configuração da interface eth1 A figura abaixo referencia a interface virtual SIT1. Essa interface virtual é criada no sistema operacional pelo script linux.sh e é associada, virtualmente, à interface física eth1. Na linha destinada ao tipo de encapsulamento, a tela mostra IPv6-in-IPv4 que, neste caso, é exatamente o encapsulamento no protocolo 41 para o tunelamento utilizado pelo Broker. Essa interface recebe um IPv6 de Escopo Global com máscara 128, ou seja, este IP é recebido pela interface do Broker, e não faz qualquer modificação no mesmo. Este IP serve somente para indicar o ponto-a-ponto do túnel IPv6. Figura 20: Configuração da interface SIT1 A figura a seguir mostra a última interface, que é a de loopback. A única observação é a existência do endereço de loopback, tanto em IPv4 como em IPv6 (condizente com a usada no dual-stack). Figura 21: Configuração da interface Loopback Para testar o funcionamento do túnel foi utilizado o comando Ping6 (versão IPv6 do comando ping) e foi tentado mandar pacotes ICMPv6 para o site (www.kame.net), que é um site conhecidamente IPv6: Figura 22: Teste de ping versão 6 Repare na figura que o endereço (www.kame.net) é resolvido em IPv6, mesmo este site tendo um endereço correspondente em IPv4. Outro ponto a se observar é o tempo de latência de resposta do pacote ICMPv6 que, no exemplo acima, é consideravelmente alto. Esses valores são obtidos devido ao uso do Broker para atingir a internet IPv6 e, sendo assim, o pacote viaja por diversas redes até chegar ao seu destino. Possivelmente, se a operadora em questão possuísse seu próprio Broker, os valores de desempenho do tráfego seriam bem melhores. Como não se dispõe de um provedor com um Broker, não é possível realizar sua comparação. 18

Figura 23: Tabela de roteamento do servidor IPv4 Verificou-se, então, que o comando route mostra, exclusivamente, a saída somente da tabela de roteamento da pilha IPv4, pois não faz referência alguma à interface SIT1, além dos endereços e rotas IPv6. Para tanto, o comando que deve ser executado para se ver todas as rotas do sistema, ao invés do route, sendo elas IPv4 ou IPv6, é o routel. A figura, a seguir, mostra a rota default para a internet IPv4 (exatamente como a saída o comando route (figura 23), no campo destacado como 1 : Figura 24: Roteamento default Eth0 Porém, em continuação, na saída do comando routel, são obtidas, também, as seguintes informações: Figura 25: Roteamento comando routel O endereço IPv6 associado à interface Sit1 e à interface eth1 no campo 1. A adição da rota de saída padrão para a rede IPv6 pela interface sit1 como mostrada nos campos 2 e 3. DNS (BIND9) net-dns/bind-9.4.3_p2 x86 O Berkeley Internet Name Domain - Name Server (BIND) desenvolvido e mantido pela Internet Systems Consortium (ISC) é o servidor DNS disponibilizado, gratuitamente, bastante utilizado na Internet, por sua estabilidade e robustez. O serviço de DNS é de suma importância para a migração e funcionamento da rede IPv6, uma vez que os endereçamentos se tornarão praticamente inviáveis de serem administrados, em sua forma numérica, no modelo IPv6. O BIND, para funcionar com o IPv6, deve ser compilado com suporte a IPv6. Devem ser configuradas, separadamente, as zonas IPv6 e IPv4 para a utilização pelo DNS, assim como os arquivos de resolução reversa. Depois de configurado, basta inicializar o serviço de DNS com o comando: 19

# /./etc/ini.d/named start As sinalizações na tela a seguir mostram, no arquivo de log do named, que o servidor DNS está ouvindo requisições DNS nas interfaces IPv6, porém não faz distinção de qual interface IPv6, como é mostrado para os endereços IPv4: DHCPv6 net-misc/dhcpv6-1.0.20 ~x86 Figura 26: Arquivo de log do named O DHCPv6 é um servidor DHCP para IPv6, porém nenhuma versão dele disponível no momento da instalação era considerada estável pelo Portage, ou seja, todos os pacotes dos fontes estavam marcados com a flag ~x86. As configurações feitas no DHCPv6 são mínimas e, apesar de ser colocada referência do pool de endereços e do prefixo (fornecido pelo Broker), no laboratório, não gerencia os endereços dos hosts (configuração adotada), cabendo somente enviar para os clientes que o requisitarem (que tiverem suporte ao DHCPv6 / IPv6 Ready Fase 2), o endereço do DNS. Repare que, mesmo assim, foi necessário configurar um pool de endereços para o funcionamento do serviço, pois, sem essa configuração, o servidor não aceita ser inicializado. A figura 27 mostra os campos configurados no arquivo dhcp6s.conf (arquivo referente ao servidor DHCPv6): 20