{"id":289,"date":"2012-08-02T11:19:50","date_gmt":"2012-08-02T14:19:50","guid":{"rendered":"http:\/\/linuxrs.com.br\/?p=289"},"modified":"2012-08-02T11:19:50","modified_gmt":"2012-08-02T14:19:50","slug":"transicao-para-ipv6","status":"publish","type":"post","link":"https:\/\/blog.clusterweb.com.br\/?p=289","title":{"rendered":"Transi\u00e7\u00e3o para IPV6"},"content":{"rendered":"<h2>Introdu\u00e7\u00e3o<\/h2>\n<p>O IPv4 e o IPv6 n\u00e3o s\u00e3o diretamente compat\u00edveis entre si. O IPv6 n\u00e3o foi projetado para ser uma extens\u00e3o, ou complemento, do IPv4, mas sim, um substituto que resolve o problema do esgotamento de endere\u00e7os. Embora n\u00e3o interoperem, ambos os protocolos podem funcionar simultaneamente nos mesmos equipamentos e com base nisto a transi\u00e7\u00e3o foi pensada para ser feita de forma gradual.<\/p>\n<p>No projeto inicial do IPv6, uma vez que o protocolo estivesse pronto, sua implanta\u00e7\u00e3o come\u00e7aria a ser feita gradualmente na Internet, de forma que funcionasse simultaneamente ao IPv4. A isso chamamos de pilha dupla, ou dual stack. Quando o IPv6 estivesse implantado em todos os dispositivos, o IPv4 deixaria de ser realmente \u00fatil e poderia ser abandonado paulatinamente.<\/p>\n<p>No per\u00edodo de implanta\u00e7\u00e3o do IPv6 haveria necessidade de t\u00e9cnicas auxiliares de transi\u00e7\u00e3o, inicialmente para interconectar ilhas IPv6 em uma Internet majoritariamente IPv4 e, depois de algum tempo, para fazer o contr\u00e1rio.<\/p>\n<p>A transi\u00e7\u00e3o feita desta forma seria muito simples de ser executada tecnicamente. Contudo, por diversas raz\u00f5es, n\u00e3o foi o que aconteceu. Atualmente o IPv6 ainda n\u00e3o est\u00e1 sendo amplamente utilizado na Internet e o esgotamento do IPv4 j\u00e1 se tornou uma realidade. Hoje existe a necessidade de se implantar o IPv6 numa Internet sempre crescente, onde os novos usu\u00e1rios ainda precisam de conectividade IPv4, mas n\u00e3o h\u00e1 mais endere\u00e7os IPv4 livres para atend\u00ea-los. Assim, novas t\u00e9cnicas auxiliares foram e continuam sendo, desenvolvidas para essa nova realidade.<\/p>\n<p><a name=\"transicao-coex\"><\/a><\/p>\n<h2>1. Cen\u00e1rios de coexist\u00eancia de IPv6 e IPv4<\/h2>\n<p>Na transi\u00e7\u00e3o do IPv4 para o IPv6 \u00e9 necess\u00e1ria a coexist\u00eancia e interoperabilidade entre ambos os protocolos e para isso \u00e9 necess\u00e1rio o uso de tecnologias auxiliares, conhecidas como t\u00e9cnicas de transi\u00e7\u00e3o. A necessidade de coexist\u00eancia ocorre em diferentes cen\u00e1rios, cada qual com caracter\u00edsticas e demandas singulares e uma t\u00e9cnica de transi\u00e7\u00e3o isoladamente normalmente n\u00e3o \u00e9 capaz de atender simultaneamente a todos. Assim, o primeiro passo para entender as t\u00e9cnicas de transi\u00e7\u00e3o \u00e9 entender os cen\u00e1rios existentes, as necessidades apresentadas e as dificuldades envolvidas.<\/p>\n<p>A enumera\u00e7\u00e3o dos cen\u00e1rios a seguir \u00e9 uma generaliza\u00e7\u00e3o e extens\u00e3o da enumera\u00e7\u00e3o feita na RFC 6144. Contudo, enquanto esta RFC\u00a0trata\u00a0apenas de cen\u00e1rios utilizados com solu\u00e7\u00f5es de tradu\u00e7\u00e3o, os mesmos s\u00e3o aqui usados para descrever tamb\u00e9m situa\u00e7\u00f5es onde solu\u00e7\u00f5es de tunelamento podem ser aplicadas.<\/p>\n<h3>Cen\u00e1rio 1: Rede IPv6 para Internet IPv4 (R6-I4)<\/h3>\n<p>Devido a falta de entere\u00e7os IPv4 ou outras limita\u00e7\u00f5es t\u00e9cnicas ou econ\u00f4micas a rede cliente possui somente IPv6, mas necessita conectar-se a Internet IPv4.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-01\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-01.png\" alt=\"\" width=\"369\" height=\"153\" \/><br \/>\n<strong>Figura 1: cen\u00e1rio 1<\/strong><\/p>\n<p>Este cen\u00e1rio tamb\u00e9m pode ocorrer em greenfield networks, express\u00e3o em ingl\u00eas usada para se referir a projetos totalmente novos, aos quais n\u00e3o se aplicam as restri\u00e7\u00f5es normalmente encontradas em tecnologias j\u00e1 em uso. Algumas empresas t\u00eam se decidido por criar redes somente IPv6 nesse caso, por motivos de simplicidade, facilidade de ger\u00eancia e outros, mas necessitam ainda acessar servidores de clientes e fornecedores que est\u00e3o na Internet IPv4.<\/p>\n<p>Este cen\u00e1rio possui uma complexidade simples e \u00e9 de f\u00e1cil solu\u00e7\u00e3o, sendo suportado por tanto por t\u00e9cnicas statless quanto stateful, que ser\u00e3o explicadas mais adiante.<\/p>\n<h3>Cen\u00e1rio 2: Internet IPv4 para Rede IPv6 (I4-R6)<\/h3>\n<p>Mesma rede existente no cen\u00e1rio 1, mas que necessita receber conex\u00f5es da Internet IPv4, para o caso, por exemplo, de haver servidores IPv6 na rede, que devem atender solicita\u00e7\u00f5es de clientes na Internet IPv4.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-02\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-02.png\" alt=\"\" width=\"368\" height=\"152\" \/><br \/>\n<strong>Figura 2: cen\u00e1rio 2<\/strong><\/p>\n<p>A invers\u00e3o no sentido de origem da comunica\u00e7\u00e3o torna este cen\u00e1rio muito mais complexo que o cen\u00e1rio 1, pois normalmente n\u00e3o se consegue fazer um mapeamento 1:1 de todos endere\u00e7os IPv6 existentes na rede para endere\u00e7os IPv4 v\u00e1lidos. Esse caso normalmente exige solu\u00e7\u00f5es stateful, mas pode ser tamb\u00e9m atendido por solu\u00e7\u00f5es stateless, desde que suportem conex\u00f5es iniciadas via IPv4 para um subconjunto dos endere\u00e7os IPv6 na rede.<\/p>\n<h3>Cen\u00e1rio 3: Internet IPv6 para Rede IPv4 (I6-R4)<\/h3>\n<p>Este \u00e9 um t\u00edpico cen\u00e1rio onde uma rede legada, onde n\u00e3o \u00e9 poss\u00edvel fazer uma atualiza\u00e7\u00e3o para IPv6, necessita continuar em uso e responder requisi\u00e7\u00f5es da Internet IPv6.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-03\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-03.png\" alt=\"\" width=\"360\" height=\"151\" \/><strong>Figura 3: cen\u00e1rio 3<\/strong><\/p>\n<p>Para este cen\u00e1rio s\u00f3 cabem solu\u00e7\u00f5es stateful, j\u00e1 que a rede IPv4 deve comunicar-se com toda a Internet IPv6.<\/p>\n<h3>Cen\u00e1rio 4: Rede IPv4 para Internet IPv6 (R4-I6)<\/h3>\n<p>Este cen\u00e1rio s\u00f3 deve ser encontrado em est\u00e1gios bem avan\u00e7ados da implementa\u00e7\u00e3o do IPv6, quando a maior parte dos servi\u00e7os na Internet j\u00e1 tiverem migrado para o novo protocolo. T\u00e9cnicas de tradu\u00e7\u00e3o na pr\u00f3pria rede provavelmente n\u00e3o conseguir\u00e3o solucionar esse problema.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-04\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-04.png\" alt=\"\" width=\"360\" height=\"150\" \/><\/p>\n<p><strong>Figura 4: cen\u00e1rio 4<\/strong><\/p>\n<h3>Cen\u00e1rio 5: Rede IPv6 para Rede IPv4 (R6-R4)<\/h3>\n<p>Ambas as redes deste cen\u00e1rio est\u00e3o na mesma organiza\u00e7\u00e3o e os endere\u00e7os IPv6 e IPv4 podem ser p\u00fablicos e v\u00e1lidos na Internet ou privados e v\u00e1lidos somente dentro da organiza\u00e7\u00e3o. Este cen\u00e1rio \u00e9 bastante similar ao cen\u00e1rio 1 e os mesmos tipos de t\u00e9cnicas aplicadas a ele podem ser aplicadas a este.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-05\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-05.png\" alt=\"\" width=\"364\" height=\"150\" \/><\/p>\n<p><strong>Figura 5: cen\u00e1rio 5<\/strong><\/p>\n<h3>Cen\u00e1rio 6: Rede IPv4 para Rede IPv6 (R4-R6)<\/h3>\n<p>De forma an\u00e1loga ao cen\u00e1rio anterior, essa \u00e9 uma situa\u00e7\u00e3o semelhante ao cen\u00e1rio 2, mas com ambas as redes dentro da mesma organiza\u00e7\u00e3o. Os endere\u00e7os IPv6 e IPv4 podem ser p\u00fablicos e v\u00e1lidos na Internet ou privados e v\u00e1lidos somente dentro da organiza\u00e7\u00e3o. Os mesmos tipos de t\u00e9cnicas aplicadas ao cen\u00e1rio 2 podem ser aplicadas a este.<\/p>\n<p><a title=\"transicao-06\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-06.png\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-06\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-06.png\" alt=\"\" width=\"366\" height=\"150\" \/><\/a><br \/>\n<strong><br \/>\nFigura 6: cen\u00e1rio 6<\/strong><\/p>\n<h3>Cen\u00e1rio 7: Internet IPv6 para Internet IPv4 (I6-I4)<\/h3>\n<p>Este cen\u00e1rio, onde qualquer dispositivo na Internet IPv6 pode iniciar uma conex\u00e3o com um dispositivo na Internet IPv4, necessita da t\u00e9cnica de transi\u00e7\u00e3o perfeita, que tamb\u00e9m seria capaz de resolver todos os cen\u00e1rios anteriores, mas infelizmente ela n\u00e3o existe. A grande diferen\u00e7a na quantidade de endere\u00e7os torna, at\u00e9 este momento, uma solu\u00e7\u00e3o para este cen\u00e1rio t\u00e9cnicamente improv\u00e1vel.<\/p>\n<p><a title=\"transicao-07\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-07.png\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-07\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-07.png\" alt=\"\" width=\"363\" height=\"149\" \/><\/a><\/p>\n<p><strong>Figura 7: cen\u00e1rio 7<br \/>\n<\/strong><\/p>\n<h3>Cen\u00e1rio 8: Internet IPv4 para Internet IPv6 (I4-I6)<\/h3>\n<p>Similar ao cen\u00e1rio 7 e com mesma dificuldade t\u00e9cnica de implementa\u00e7\u00e3o.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-08\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-08.png\" alt=\"\" width=\"364\" height=\"148\" \/><strong><br \/>\nFigura 8: cen\u00e1rio 8<\/strong><\/p>\n<h3>Cen\u00e1rio 9: Rede IPv6 para Rede IPv6 bidirecional via Internet IPv4 (R6-I4-R6)<\/h3>\n<p>Este cen\u00e1rio apresenta o caso em que a comunica\u00e7\u00e3o entre duas redes com IPv6 necessita ser feita atrav\u00e9s da Internet IPv4 ou de Rede IPv4. A comunica\u00e7\u00e3o pode ser iniciada por ambas as Redes IPv6.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-09\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-09.png\" alt=\"\" width=\"473\" height=\"106\" \/><strong><br \/>\nFigura 9: cen\u00e1rio 9<\/strong><\/p>\n<h3>Cen\u00e1rio 10: Rede IPv4 para Rede IPv4 bidirecional via Internet IPv6 (R4-I6-R4)<\/h3>\n<p>Este cen\u00e1rio apresenta o caso em que a comunica\u00e7\u00e3o entre duas redes com IPv4 necessita ser transmitida atrav\u00e9s da Internet IPv6 ou de Rede IPv6. A comunica\u00e7\u00e3o pode ser iniciada por ambas as Redes IPv4.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-10\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-10.png\" alt=\"\" width=\"473\" height=\"107\" \/><\/p>\n<p><strong>Figura 10: cen\u00e1rio 10<\/strong><\/p>\n<p>No in\u00edcio da explica\u00e7\u00e3o de cada t\u00e9cnica de transi\u00e7\u00e3o, no decorrer deste texto, haver\u00e1 um quadro informativo para identificar quais destes cen\u00e1rios s\u00e3o suportados pela mesma. A seguinte legenda ser\u00e1 utilizada na tabela: Rede IPv4 (R4), Rede IPv6 (R6), Internet IPv4 (I4), Internet IPv6 (I6).<br \/>\n<a name=\"tecnicas-class\"><\/a><\/p>\n<h2>2. Classifica\u00e7\u00e3o das t\u00e9cnicas de transi\u00e7\u00e3o<\/h2>\n<p>Como j\u00e1 foi visto, desde 1983\u00a0a estrutura da Internet \u00e9 baseada no IPv4. Uma troca completa e imediata do protocolo seria invi\u00e1vel devido ao tamanho e \u00e0 propor\u00e7\u00e3o desta rede. Por isso, o IPv6 foi projetado para ser implantado gradualmente.<\/p>\n<p>O per\u00edodo de transi\u00e7\u00e3o e de coexist\u00eancia dos dois protocolos exigiu o desenvolvimento de t\u00e9cnicas auxiliares. O primeiro problema que elas procuravam resolver era como conectar redes IPv6 a outras redes IPv6 por meio de equipamentos ou de uma Internet que s\u00f3 suportassem IPv4. Surgiram ent\u00e3o diversos tipos de t\u00faneis\u00a0IPv6 sobre IPv4 para atender tal necessidade, usando diferentes t\u00e9cnicas, estabelecidos manualmente ou automaticamente. Foram criadas tamb\u00e9m t\u00e9cnicas para permitir que redes IPv6 e IPv4 interoperassem, por meio da tradu\u00e7\u00e3o\u00a0dos pacotes.<\/p>\n<p>Mais recentemente, o problema principal a ser resolvido pela t\u00e9cnicas de transi\u00e7\u00e3o passou a ser a implanta\u00e7\u00e3o do IPv6 num ambiente em que o IPv4 n\u00e3o est\u00e1 mais dispon\u00edvel, mas ainda \u00e9 necess\u00e1rio para os novos usu\u00e1rios da Internet. Foram, e continuam sendo, desenvolvidos ent\u00e3o diversos tipos de t\u00faneis IPv4 sobre IPv6 para, aliados a t\u00e9cnicas de tradu\u00e7\u00e3o, solucionar esse problema.<\/p>\n<p>Pode-se, ent\u00e3o, classificar as t\u00e9cnicas de transi\u00e7\u00e3o segundo sua funcionalidade, em:<\/p>\n<ul>\n<li><strong>Pilha dupla:<\/strong>\u00a0consiste na conviv\u00eancia do IPv4 e do IPv6 nos mesmos equipamentos, de forma nativa, simult\u00e2neamente. Essa t\u00e9cnica \u00e9 a t\u00e9cnica padr\u00e3o escolhida para a transi\u00e7\u00e3o para IPv6 na Internet e deve ser usada sempre que poss\u00edvel.<\/li>\n<li><strong>T\u00faneis:<\/strong>\u00a0Permitem que diferentes redes IPv4 comuniquem-se atrav\u00e9s de uma rede IPv6, ou vice-versa.<\/li>\n<li><strong>Tradu\u00e7\u00e3o:<\/strong>\u00a0Permitem que equipamentos usando IPv6 comuniquem-se com outros que usam IPv4, por meio da convers\u00e3o dos pacotes.<\/li>\n<\/ul>\n<p>Deve-se notar que tanto os t\u00faneis quanto as t\u00e9cnicas de tradu\u00e7\u00e3o podem ser stateful\u00a0ou stateless. T\u00e9cnicas stateful s\u00e3o aquelas em que \u00e9 necess\u00e1rio manter tabelas de estado com informa\u00e7\u00f5es sobre os endere\u00e7os ou pacotes para process\u00e1-los. Nas t\u00e9cnicas stateless n\u00e3o \u00e9 necess\u00e1rio guardar informa\u00e7\u00f5es, cada pacote \u00e9 tratado de forma independente. De forma geral t\u00e9cnicas stateful s\u00e3o mais caras: gastam mais CPU e mem\u00f3ria, por isso n\u00e3o escalam bem. Sempre que poss\u00edvel deve-se dar prefer\u00eancia a t\u00e9cnicas stateless.<\/p>\n<p>H\u00e1 casos em que \u00e9 necess\u00e1ria a comunica\u00e7\u00e3o entre IPv4 e IPv6 para apenas um, ou poucos tipos de aplica\u00e7\u00f5es. Ou ainda, quando \u00e9 usada uma t\u00e9cnica de tradu\u00e7\u00e3o e ela funciona para quase todas as aplica\u00e7\u00f5es, mas falha para algumas poucas, nomeadamente aquelas que carregam endere\u00e7os IP literais no protocolo, na camada de aplica\u00e7\u00e3o. Para esses casos podem ser usados gateways espec\u00edficos, na camada de aplica\u00e7\u00e3o. S\u00e3o chamados de Application Level Gateways, ou ALGs.<\/p>\n<p>Uma grande dificuldade no processo de implanta\u00e7\u00e3o do IPv6 \u00e9 o desenvolvimento de uma variedade enorme de t\u00e9cnicas de transi\u00e7\u00e3o, o que dificulta a escolha do que efetivamente utilizar. A figura 11\u00a0ilustra essa variedade, nomeando diversos tipos de t\u00e9cnicas para t\u00faneis hoje padronizadas, ou em discuss\u00e3o na IETF, e organizando-as segundo sua funcionalidade e m\u00e9todo de funcionamento. Nem todas ser\u00e3o abordadas neste texto.<\/p>\n<p>De forma geral, os crit\u00e9rios que devem ser utilizados na escolha da t\u00e9cnica a ser utilizada, s\u00e3o:<\/p>\n<ul>\n<li>deve-se preferir t\u00e9cnicas que impliquem na utiliza\u00e7\u00e3o de IPv6 nativo pelos usu\u00e1rios finais, de forma que t\u00faneis IPv4 dentro de IPv6 devem ser preferidos em detrimento de t\u00faneis IPv6 sobre IPv4;<\/li>\n<li>deve-se preferir t\u00e9cnicas stateless em detrimento de t\u00e9cnicas statefull;<\/li>\n<li>deve-se evitar t\u00e9cnicas para prolongar o uso do protocolo IPv4, sem a ado\u00e7\u00e3o concomitante do IPv6;<\/li>\n<li>deve-se analisar a adequa\u00e7\u00e3o da t\u00e9cnica \u00e0 topologia da rede onde ser\u00e1 aplicada e<\/li>\n<li>deve-se analisar a maturidade da t\u00e9cnica e as op\u00e7\u00f5es de implanta\u00e7\u00e3o, como por exemplo suporte \u00e0 mesma nos equipamentos de rede e em softwares.<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-11\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-11.png\" alt=\"\" width=\"493\" height=\"346\" \/><\/p>\n<p><strong>Figura 11: classifica\u00e7\u00e3o das t\u00e9cnicas de transi\u00e7\u00e3o<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p>Como uma terceira possibilidade de classifica\u00e7\u00e3o, pode-se dividir as t\u00e9cnicas conforme seus casos de uso:<\/p>\n<ul>\n<li>Fornecer IPv6 e IPv4 para todos os dispositivos: pilha dupla.<\/li>\n<li>Oferecer conectividade IPv6 nativa em conjunto com conectividade IPv4 com compartilhamento e preserva\u00e7\u00e3o de endere\u00e7os: DS-Lite, DS-Lite com A+P, 4rd, NAT64, IVI e 464XLAT.<\/li>\n<li>Transportar IPv6 em uma rede MPLS IPv4: 6PE e 6VPE.<\/li>\n<li>Obter conectividade IPv6, quando o provedor Internet n\u00e3o a oferecer: tunnel broker e t\u00faneis est\u00e1ticos 6over4 ou GRE.<\/li>\n<li>Oferecer conectividade IPv6 para os usu\u00e1rios sobre uma rede de transporte IPv4: 6rd (normalmente usado em provedores) e ISATAP (para redes internas).<\/li>\n<li>Mecanismos para compartilhar endere\u00e7os IPv4, estendendo sua vida: A+P e NAT444.<\/li>\n<\/ul>\n<p><a name=\"tecnicas-pilha2\"><\/a><\/p>\n<h2>3. Pilha Dupla: IPv6 e IPv4 em todos os dispositivos<\/h2>\n<p>Na atual fase de implanta\u00e7\u00e3o do IPv6, n\u00e3o \u00e9 aconselh\u00e1vel ter n\u00f3s com suporte apenas a esta vers\u00e3o do protocolo IP, visto que muitos servi\u00e7os e dispositivos na Internet ainda trabalham somente com IPv4. Como citado anteriormente, manter o IPv4 j\u00e1 existente funcionando de forma est\u00e1vel e implantar o IPv6 nativamente, para que coexistam nos mesmos equipamentos, \u00e9 a forma b\u00e1sica escolhida para a transi\u00e7\u00e3o na Internet. \u00a0Esta t\u00e9cnica \u00e9 conhecida como pilha dupla (Dual Stack ou DS) e deve ser usada sempre que poss\u00edvel.<\/p>\n<p>A utiliza\u00e7\u00e3o deste m\u00e9todo permite que dispositivos e roteadores estejam equipados com pilhas para ambos os protocolos, tendo a capacidade de enviar e receber os dois tipos de pacotes, IPv4 e IPv6. Com isso, um n\u00f3 Pilha Dupla, ou n\u00f3 IPv6\/IPv4, se comportar\u00e1 como um n\u00f3 IPv6 na comunica\u00e7\u00e3o com outro n\u00f3 IPv6 e se comportar\u00e1 como um n\u00f3 IPv4 na comunica\u00e7\u00e3o com outro n\u00f3 IPv4.<\/p>\n<p>Cada n\u00f3 IPv6\/IPv4 \u00e9 configurado com ambos endere\u00e7os, utilizando mecanismos IPv4 (ex. DHCP) para adquirir seu endere\u00e7o IPv4 e mecanismos IPv6 (ex. configura\u00e7\u00e3o manual, autoconfigura\u00e7\u00e3o stateless e\/ou DHCPv6) para adquirir seu endere\u00e7o IPv6.<\/p>\n<p>Este m\u00e9todo de transi\u00e7\u00e3o permita uma implanta\u00e7\u00e3o gradual, com a configura\u00e7\u00e3o de \u00a0pequenas se\u00e7\u00f5es do ambiente de rede de cada vez. Al\u00e9m disso, caso no futuro o IPv4 n\u00e3o seja mais usado, basta simplesmente desabilitar a pilha IPv4 em cada n\u00f3.<\/p>\n<p>O funcionamento da pilha dupla est\u00e1 ilustrado na figura 12.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-12\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-12.png\" alt=\"\" width=\"218\" height=\"255\" \/><\/p>\n<p>&nbsp;<\/p>\n<p><strong>Figura 12: funcionamento da pilha dupla<\/strong><\/p>\n<p>Alguns aspectos referentes \u00e0 infra-estrutura da rede devem ser considerados ao se implementar a t\u00e9cnica de pilha dupla: a estrutura\u00e7\u00e3o do servi\u00e7o de DNS e a configura\u00e7\u00e3o dos protocolos de roteamento e de firewalls.<\/p>\n<p>Em rela\u00e7\u00e3o ao DNS, \u00e9 preciso configurar os novos endere\u00e7os IPv6, usando registros do tipo AAAA (quad-A), que armazenam seus endere\u00e7os. Para mais detalhes sobre o suporte do DNS ao IPv6, consulte a RFC 3596. Responder os endere\u00e7os IPv6 (registros AAAA) quando dispon\u00edveis para um determinado nome de dom\u00ednio \u00e9 o comportamento padr\u00e3o do servidor DNS, mesmo que ele opere apenas com IPv4. O protocolo por meio do qual \u00e9 feita a consulta n\u00e3o interfere na resposta. Ao receber endere\u00e7os IPv6 e IPv4 como resposta a uma consulta no DNS a aplica\u00e7\u00e3o decide qual protocolo usar. Normalmente a prefer\u00eancia \u00e9 pelo protocolo IPv6 e, em caso de falha, tenta-se o IPv4. Mais recentemente t\u00eam sido experimentadas t\u00e9cnicas que implicam em tentativas simult\u00e2neas de conex\u00e3o IPv6 e IPv4 e optam pela que for mais r\u00e1pida (draft-ietf-v6ops-happy-eyeballs-07).<br \/>\nEm uma rede com pilha dupla, a configura\u00e7\u00e3o do roteamento IPv6 normalmente \u00e9 independente da configura\u00e7\u00e3o do roteamento IPv4. Isto implica no fato de que, se antes de implementar-se o IPv6 a rede utilizava apenas o protocolo de roteamento interno OSPFv2 (com suporte apenas ao IPv4), ser\u00e1 necess\u00e1rio migrar para um protocolo de roteamento que suporte tanto IPv6 quanto IPv4 (como ISIS por exemplo) ou for\u00e7ar a execu\u00e7\u00e3o do OSPFv3 paralelamente ao OSPFv2.<\/p>\n<p>A forma como \u00e9 feita a filtragem dos pacotes que trafegam na rede pode depender da plataforma que se estiver utilizando. Em um ambiente Linux, por exemplo, os filtros de pacotes s\u00e3o totalmente independentes uns dos outros, de modo que o iptables filtra apenas pacotes IPv4 e o ip6tables apenas IPv6, n\u00e3o compartilhando nenhuma configura\u00e7\u00e3o. No FreeBSD, as regras s\u00e3o aplicadas a ambos os protocolos no mesmo arquivo de configura\u00e7\u00e3o. Entretanto a regra pode ser aplicada simult\u00e2neamente aos dois protocolos ou a somente um. Para aplicar a somente um deles basta utilizar inet ou inet6 dependendo do protocolo \u00e0 qual as regras devem ser aplicadas.\u00a0De uma forma ou de outra, novas regras ter\u00e3o de ser configuradas no firewall ao implantar-se o IPv6.<\/p>\n<p>\u00c9 importante refor\u00e7ar que configura\u00e7\u00f5es independentes para IPv4 e IPv6 s\u00e3o necess\u00e1rias para diversos aspectos da rede, entre eles:<\/p>\n<ul>\n<li>Informa\u00e7\u00f5es nos servidores DNS autoritativos;<\/li>\n<\/ul>\n<ul>\n<li>Protocolos de roteamento;<\/li>\n<li>Firewalls;<\/li>\n<li>Gerenciamento das redes.<\/li>\n<\/ul>\n<p>Utilizar pilha dupla pode n\u00e3o ser poss\u00edvel em todas as ocasi\u00f5es. Por exemplo, quando n\u00e3o h\u00e1 mais IPv4 dispon\u00edveis e o provedor precisa atender a usu\u00e1rios novos com IPv6 e IPv4. Para redes corporativas que j\u00e1 utilizam NAT isso n\u00e3o \u00e9 um impendimento: o IPv6 nativo pode ser utilizado em conjunto com o IPv4 compartilhado. Outra situa\u00e7\u00e3o que dificulta a implanta\u00e7\u00e3o do IPv6 usando pilha dupla \u00e9 a exist\u00eancia de equipamentos que n\u00e3o o suportam e que n\u00e3o podem ser facilmente substitu\u00eddos. Para contornar essas situa\u00e7\u00f5es existem diversas t\u00e9cnicas dispon\u00edveis, algumas das quais ser\u00e3o abordadas nas pr\u00f3ximas sess\u00f5es.<br \/>\n<a name=\"tecnicas-6o4\"><\/a><\/p>\n<h2>4. T\u00faneis 6over4 (IPv6-over-IPv4)<\/h2>\n<table>\n<tbody>\n<tr>\n<td><strong>Cen\u00e1rio<\/strong><\/td>\n<td><strong>R6-I4<\/strong><\/td>\n<td><strong>I4-R6<\/strong><\/td>\n<td><strong>I6-R4<\/strong><\/td>\n<td><strong>R4-I6<\/strong><\/td>\n<td><strong>R6-R4<\/strong><\/td>\n<td><strong>R4-R6<\/strong><\/td>\n<td><strong>I6-I4<\/strong><\/td>\n<td><strong>I4-I6<\/strong><\/td>\n<td><strong>R6-I4-R6<\/strong><\/td>\n<td><strong>R4-I6-R4<\/strong><\/td>\n<\/tr>\n<tr>\n<td><strong>Suporta<\/strong><\/td>\n<td><strong>N\u00e3o<\/strong><\/td>\n<td><strong>N\u00e3o<\/strong><\/td>\n<td><strong>N\u00e3o<\/strong><\/td>\n<td><strong>N\u00e3o<\/strong><\/td>\n<td><strong>N\u00e3o<\/strong><\/td>\n<td><strong>N\u00e3o<\/strong><\/td>\n<td><strong>N\u00e3o<\/strong><\/td>\n<td><strong>N\u00e3o<\/strong><\/td>\n<td><strong>Sim<\/strong><\/td>\n<td><strong>N\u00e3o<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Quando a utiliza\u00e7\u00e3o de pilha dupla n\u00e3o \u00e9 poss\u00edvel, umas das alternativas a ser considerada \u00e9 a utiliza\u00e7\u00e3o de t\u00faneis. As t\u00e9cnicas de tunelamento fazem o encapsulamento de pacotes IPv6 em pacotes IPv4. Este encapsulamento \u00e9 conhecido como 6in4 ou IPv6-in-IPv4 (RFC 4213). Ele consiste em colocar o pacote IPv6 dentro de um pacote IPv4, adequar os endere\u00e7os de origem e destino para o IPv4 e colocar no cabe\u00e7alho o tipo 41 (29 em hexadecimal). Esse tipo de encapsulamento \u00e9 conhecido por 6in4, \u00a0ou como \u201cprotocolo 41\u201d. Quando o destino receber o pacote com tipo 41 ele ir\u00e1 remover o cabe\u00e7alho IPv4 e tratar o pacote como IPv6. A figura 13 ilustra esse comportamento.<\/p>\n<p>Tamb\u00e9m \u00e9 poss\u00edvel, de forma an\u00e1loga, encapsular pacotes IPv4 em pacotes IPv6, t\u00e9cnica conhecida como 4in6. Algumas das t\u00e9cnicas de transi\u00e7\u00e3o estudadas mais \u00e0 frente fazem isso.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-13\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-13.png\" alt=\"\" width=\"464\" height=\"253\" \/><br \/>\n<strong><br \/>\nFigura 13: funcionamento 6in4<\/strong><\/p>\n<p>Uma das formas de utilizar-se t\u00faneis \u00e9 criando-os manualmente. A t\u00e9cnica 6over4 (RFC 4213) utiliza um t\u00fanel manual estabelecido entre dois n\u00f3s IPv4 para enviar o tr\u00e1fego IPv6. Todo o tr\u00e1fego IPv6 a ser enviado \u00e9 encapsulado em IPv4 usando 6in4, explicado anteriormente. A configura\u00e7\u00e3o manual consiste em definir quais ser\u00e3o os IPs v4 de origem e destino que ser\u00e3o utilizados em cada ponta do t\u00fanel. Ao ser recebido pelo n\u00f3 destino, o pacote IPv6 \u00e9 desencapsulado e tratado adequadamente.<\/p>\n<p>Esse tipo de t\u00fanel pode ser utilizado para contornar um equipamento ou enlace sem suporte a IPv6 numa rede, ou para criar t\u00faneis est\u00e1ticos entre duas redes IPv6 atrav\u00e9s da Internet IPv4.<\/p>\n<p>\u00c9 importante entender a diferen\u00e7a entre 6over4 e 6in4. O\u00a0t\u00fanel 6over4 \u00e9 um t\u00fanel estabelecido manualmente que tem o objetivo de permitir conex\u00e3o IPv6 entre dois n\u00f3s de rede conectados por uma rede via IPv4. Ele usa o encapsulamento 6in4. J\u00e1 o encapsulamento 6in4, com a utiliza\u00e7\u00e3o do tipo 41, pode ser utilizado tamb\u00e9m em outras t\u00e9cnicas de transi\u00e7\u00e3o que transportam pacotes IPv6 em redes IPv4, como poder\u00e1 ser observado ao longo deste texto.<\/p>\n<p>Criar um t\u00fanel 6over4 \u00e9 bastante f\u00e1cil. A seguir ser\u00e3o mostrados exemplos de como fazer esta implementa\u00e7\u00e3o no Linux e com roteadores Cisco. A topologia da implementa\u00e7\u00e3o em Linux \u00e9:<br \/>\n<img loading=\"lazy\" decoding=\"async\" title=\"transicao-14\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-14.png\" alt=\"\" width=\"430\" height=\"242\" \/><\/p>\n<p><strong>Figura 14: t\u00fanel manual 6over4 entre dois dispositivos<\/strong><\/p>\n<p>Os computadores Host A\u00a0e Host B\u00a0s\u00e3o computadores Linux e os roteadores simplesmente representam uma rede somente IPv4 ou a Internet IPv4. Os computadores devem ser configurados com os seguintes passos:<\/p>\n<p>No Host A, basta digitar os comandos:<\/p>\n<div><code><br \/>\nip tunnel add toHostB mode sit ttl 64 remote 192.0.2.130 local 192.0.2.2<\/code>ip link set dev toHostB upip -6 route add <code>2001:db8::b0ca dev toHostB<\/code><\/div>\n<p>De forma an\u00e1loga, no Host B:<\/p>\n<div>\n<p><code>ip tunnel add toHostA mode sit ttl 64 remote 192.0.2.2 local 192.0.2.130 ip link set dev toHostA up<br \/>\nip -6 route add 2001:db8::ba1a dev toHostA<\/code><\/p>\n<\/div>\n<p>Para verificar o correto funcionamento pode-se utilizar o comando ping6 antes e depois de fazer as configura\u00e7\u00f5es. Ser\u00e1 poss\u00edvel notar que as duas m\u00e1quinas passaram a comunicar-se via IPv6.<\/p>\n<p>Para o exemplo de configura\u00e7\u00e3o em roteadores Cisco de t\u00faneis 6over4 a topologia ser\u00e1:<br \/>\n<img loading=\"lazy\" decoding=\"async\" title=\"transicao-15\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-15.png\" alt=\"\" width=\"473\" height=\"210\" \/><\/p>\n<p><strong>Figura 15: t\u00fanel manual 6over4 entre dois roteadores<\/strong><\/p>\n<p>Para a configura\u00e7\u00e3o do t\u00fanel somente \u00e9 necess\u00e1ria a configura\u00e7\u00e3o do Roteador A e do Roteador B.<\/p>\n<p>No Roteador A:<\/p>\n<div>\n<p><code>configure terminal<br \/>\ninterface Tunnel10<br \/>\nipv6 address 2001:db8:100::1\/64<br \/>\ntunnel source 198.51.100.5<br \/>\ntunnel destination 203.0.113.198<br \/>\ntunnel mode ipv6ip<br \/>\nend<br \/>\n<\/code><\/p>\n<\/div>\n<p>Ainda no Roteador A, \u00e9 necess\u00e1rio ativar o roteamento IPv6 e criar uma rota para a rede do Roteador B, apontando para o T\u00fanel\u00a06over4:<\/p>\n<div>\n<p><code>ipv6 unicast-routing<br \/>\nipv6 route 2001:db8:20::\/64 2001:db8:100::2<\/code><\/p>\n<\/div>\n<p>De forma an\u00e1loga, no Roteador B:<\/p>\n<div><code><br \/>\nconfigure terminal<\/code>interface Tunnel20ipv6 address 2001:db8:100::2\/64<br \/>\ntunnel source 203.0.113.198<br \/>\ntunnel destination 198.51.100.5<br \/>\ntunnel mode ipv6ip<br \/>\nendipv6 unicast-routing<br \/>\nipv6 route 2001:db8:10::\/64 2001:db8:100::1<\/div>\n<p>Mais uma vez, \u00e9 poss\u00edvel testar a configura\u00e7\u00e3o utilizando o ping para IPv6.<br \/>\n<a name=\"tecnicas-gre\"><\/a><\/p>\n<h2>5. T\u00faneis GRE<\/h2>\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Outra op\u00e7\u00e3o de t\u00fanel est\u00e1tico para o tranporte de IPv6 em redes IPv4 \u00e9 o GRE (Generic Routing Encapsulation \u2013 RFC 2784). Ele \u00e9 um t\u00fanel est\u00e1tico entre dois n\u00f3s originalmente desenvolvido pela Cisco com a finalidade de encapsular v\u00e1rios tipos diferentes de protocolos, como por exemplo IPv6 e ISIS (a lista completa dos protocolos suportados pode ser encontrada em <a href=\"http:\/\/www.iana.org\/assignments\/ethernet-numbers\">http:\/\/www.iana.org\/assignments\/ethernet-numbers<\/a>). Este tipo de encapsulamento \u00e9 suportado na maioria do sistemas operacionais e roteadores e possibilita a cria\u00e7\u00e3o de um link ponto a ponto. Assim como o 6over4 sua configura\u00e7\u00e3o \u00e9 manual, de modo que pode gerar um esfor\u00e7o na sua manuten\u00e7\u00e3o e gerenciamento proporcional \u00e0 quantidade de t\u00faneis.<\/p>\n<p>O pacote com cabe\u00e7alho \u00e9 explicado na figura a seguir:<\/p>\n<p><a title=\"transicao-16\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-16.png\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-16\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-16.png\" alt=\"\" width=\"393\" height=\"321\" \/><\/a><br \/>\n<strong><br \/>\nFigura 16: pacote com cabe\u00e7alho GRE<br \/>\n<\/strong><\/p>\n<p>O funcionamento deste tipo de t\u00fanel \u00e9 muito simples: consiste em pegar os pacotes originais, adicionar o cabe\u00e7alho GRE e o cabe\u00e7alho IPv4 e enviar ao IP de destino. Quando o pacote encapsulado chegar na outra ponta do t\u00fanel (IP de destino) remove-se dele os cabe\u00e7alhos IPv4 e GRE, restando apenas o pacote original, que \u00e9 encaminhado normalmente ao destinat\u00e1rio.<\/p>\n<p>A configura\u00e7\u00e3o dos t\u00faneis GRE \u00e9 muito semelhante \u00e0quela feita para o 6over4. No exemplo dado para roteadores Cisco, no item 4, basta trocar:<\/p>\n<div><code>tunnel mode ipv6ip<\/code><\/div>\n<p>por<\/p>\n<div><code>tunnel mode gre<\/code><\/div>\n<p><a name=\"tecnicas-broker\"><\/a><\/p>\n<h2>6. Tunnel Broker<\/h2>\n<table>\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Descrita na RFC 3053, essa t\u00e9cnica permite que dispositivos isolados, ou toda uma rede IPv4, obtenham conectividade IPv6 por meio do estabelecimento de um t\u00fanel com um provedor, tornando-se, na pr\u00e1tica, dispositivos, ou uma rede, pilha dupla.<\/p>\n<p>Seu funcionamento \u00e9 bastante simples: primeiramente \u00e9 necess\u00e1rio realizar um cadastro, normalmente via Web, em um provedor que ofere\u00e7a esse servi\u00e7o, chamado, neste contexto, de Tunnel Broker. O provedor realizar\u00e1 de forma autom\u00e1tica, ou semi autom\u00e1tica, a configura\u00e7\u00e3o do seu lado do t\u00fanel e permitir\u00e1 o download de instru\u00e7\u00f5es, ou de um software ou script de configura\u00e7\u00e3o, para configurar o lado do usu\u00e1rio. Os Tunnel Brokers normalmente oferecem blocos fixos IPv6 que variam de \/64 a \/48.<\/p>\n<p>Dentre as op\u00e7\u00f5es existentes, recomenda-se:<\/p>\n<ul>\n<li><a href=\"http:\/\/tunnelbroker.net\/\">http:\/\/tunnelbroker.net\/<\/a>\u00a0&#8211; servi\u00e7o oferecido pela Hurricane Electric, que prov\u00ea t\u00faneis para usu\u00e1rios dom\u00e9sticos ou corporativos, inclusive com a possibilidade de se fechar sess\u00f5es BGP para provimento de tr\u00e2nsito IPv6 via t\u00fanel.<\/li>\n<li><a href=\"http:\/\/www.sixxs.net\/main\/\">http:\/\/www.sixxs.net\/main\/<\/a>\u00a0&#8211; servi\u00e7o oferecido de forma colaborativa por um grande n\u00famero de organiza\u00e7\u00f5es. N\u00e3o \u00e9 poss\u00edvel fechar sess\u00f5es BGP, mas \u00e9 poss\u00edvel obter redes fixas de tamanho \/48 roteadas atrav\u00e9s do t\u00fanel. A Algar Telecom\/CTBC \u00e9 respons\u00e1vel por um dos POPs em que s\u00e3o configurados os t\u00faneis, no Brasil, de forma que para usu\u00e1rios em redes brasileiras os t\u00faneis funcionam com qualidade e velocidade pr\u00f3ximas \u00e0s de conex\u00f5es nativas.<\/li>\n<\/ul>\n<p>Os Tunnel Brokers podem usar tecnologias diversas para prover os t\u00faneis. Podem usar, por exemplo, t\u00faneis 6in4, encapsulamento em UDP, o protocolo AYIYA, que significa Anything in Anything (draft-massar-v6ops-ayiya-02), ou TSP (Tunnel Setup Protocol), definido na RFC 5572.<\/p>\n<p>A utiliza\u00e7\u00e3o de Tunnel Brokers \u00e9 recomendada para usu\u00e1rios dom\u00e9sticos e corporativos que querem testar o IPv6, ou come\u00e7ar um processo de implanta\u00e7\u00e3o em suas redes, mas cujos provedores de acesso ainda n\u00e3o oferecem suporte ao protocolo. Muitos Sistemas Aut\u00f4nomos brasileiros t\u00eam utilizado com sucesso t\u00faneis com a Hurricane Electric para anunciar seus blocos em car\u00e1ter de teste e muitas empresas e usu\u00e1rios dom\u00e9sticos t\u00eam utilizado t\u00faneis SixXS para familiarizar-se com o IPv6.<\/p>\n<p>A implanta\u00e7\u00e3o de um servi\u00e7o de Tunnel Broker em um provedor Internet n\u00e3o \u00e9 trivial, pois n\u00e3o h\u00e1 softwares abertos dispon\u00edveis para a funcionalidade de Servidor Broker.<\/p>\n<p>As figuras abaixo mostram a topologia l\u00f3gica e f\u00edsica do Tunnel Broker.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-17\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-17.png\" alt=\"\" width=\"247\" height=\"207\" \/><\/p>\n<p>1 \u2013 Cliente pilha dupla solicita t\u00fanel (pode ser solicitada autentica\u00e7\u00e3o) via IPv4<br \/>\n2 \u2013 Broker cadastra usu\u00e1rio no Servidor de t\u00fanel<br \/>\n3 \u2013 Broker informa cliente parametros para cria\u00e7\u00e3o do t\u00fanel<br \/>\n4 \u2013 T\u00fanel estabelecido<\/p>\n<p><strong>Figura 17: Topologia l\u00f3gica do Tunnel Broker<\/strong><\/p>\n<p><a title=\"transicao-18\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-18.png\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-18\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-18.png\" alt=\"\" width=\"502\" height=\"240\" \/><\/a><\/p>\n<p><strong>Figura 18: Topologia f\u00edsica do Tunnel Broker<\/strong><\/p>\n<p>O exemplo de implementa\u00e7\u00e3o de Tunnel Broker ser\u00e1 baseado no OpenWRT (openwrt.org). Ele \u00e9 um firmware opensource para roteadores sem fio SOHO (small office \/ home office). Como provedor do t\u00fanel ser\u00e1 utilizada a solu\u00e7\u00e3o da Hurricane Eletric (tunnelbroker.com). Abaixo o passo a passo da instala\u00e7\u00e3o:<\/p>\n<p>1. Criar um usu\u00e1rio em tunnelbroker.com e solicitar um t\u00fanel<br \/>\n2. Instalar os pacotes necess\u00e1rios no OpenWRT:<\/p>\n<div><code>opkg install ip ip6tables kmod-sit kmod-iptunnel6 radvd<\/code><\/div>\n<p>3. Criar o arquivo \/etc\/hotplug.d\/iface\/15-ipv6 com o seguinte c\u00f3digo (ele considera que a conex\u00e3o com o provedor utiliza PPP, se for outro tipo de conex\u00e3o o c\u00f3digo necessita pequenas altera\u00e7\u00f5es):<\/p>\n<div><code><\/code><code>. \/etc\/functions.sh<br \/>\nNAME=ipv6<br \/>\nCOMMAND=\/usr\/sbin\/ip<\/code>[ &#8220;$ACTION&#8221; = &#8220;ifup&#8221; -a &#8220;$INTERFACE&#8221; = &#8220;wan&#8221; -a &#8220;$DEVICE&#8221; = &#8220;ppp0&#8221; ] &amp;&amp; {<\/p>\n<p>[\u00a0-x $COMMAND ] &amp;&amp; {<\/p>\n<p># setup tunnel<\/p>\n<p>logger &#8220;HE-IPv6: starting tunnel&#8230;&#8221;<\/p>\n<p>IPADDR=$(ip -4 addr show dev $DEVICE |<\/p>\n<p>awk &#8216;\/inet \/ {print $2}&#8217; |<br \/>\ncut -d\/ -f1)<br \/>\nusername=&#8221;abcdef1234567890abcdef1234567890&#8243; # MD5 of your username<br \/>\npassword=&#8221;abcdef1234567890abcdef1234567890&#8243; # MD5 of your password<br \/>\ntunnelid=&#8221;69999&#8243; # global tunnel-ID<\/p>\n<p># update tunnel to use dynamic ipv4<br \/>\nwget -q -O \/dev\/null &#8220;http:\/\/ipv4.tunnelbroker.net\/ipv4_end.php?ipv4b=<br \/>\n$IPADDR&amp;pass=$password&amp;user_id=$username&amp;tunnel_id=$tunnelid&#8221;<\/p>\n<p>SERVER_IPv4_ENDPOINT=216.66.80.30 \u00a0# change this IP to your option<br \/>\nCLIENT_IPv6_ENDPOINT=2001:470:1f0a:9999::2\/64 # change this, too<\/p>\n<p># setup tunnel<br \/>\nip tunnel add he-ipv6 mode sit remote $SERVER_IPv4_ENDPOINT local $IPADDR ttl 255<br \/>\nip link set he-ipv6 up<br \/>\nip addr add $CLIENT_IPv6_ENDPOINT dev he-ipv6<br \/>\nip route add ::\/0 dev he-ipv6<br \/>\n} &amp;<br \/>\n}<br \/>\n[ &#8220;$ACTION&#8221; = &#8220;ifdown&#8221; -a &#8220;$INTERFACE&#8221; = &#8220;wan&#8221; -a &#8220;$DEVICE&#8221; = &#8220;ppp0&#8221; ] &amp;&amp; {<br \/>\n[ -x $COMMAND ] &amp;&amp; {<br \/>\n# destroy tunnel<\/p>\n<p>logger &#8220;HE-IPv6: destroying tunnel&#8230;&#8221;<br \/>\nip route del ::\/0 dev he-ipv6<br \/>\nip tunnel del he-ipv6<br \/>\n} &amp;<br \/>\n}<\/p>\n<p><code># You got a routed \/64<\/code><\/p>\n<\/div>\n<p>4. Adicionar um IP para a interface do t\u00fanel:<\/p>\n<div><code><br \/>\nuci set network.lan.ip6addr=2001:470:1f0b:9999::1\/64 <\/code><code>uci commit<\/code><\/p>\n<\/div>\n<p>5. Configurar o firewall do OpenWRT para aceitar pacotes com protocolo 41 vindos da interface WAN<br \/>\n6. Configurar o an\u00fancio da rede IPv6 na LAN, editando o arquivo \/etc\/config\/radvd :<\/p>\n<div>config interfaceoption interface \u00a0 \u00a0 \u00a0 \u00a0\u2019lan\u2019<\/p>\n<p>option AdvSendAdvert \u00a0 \u00a01<\/p>\n<p>option AdvManagedFlag \u00a0 0<\/p>\n<p>option AdvOtherConfigFlag 0<\/p>\n<p>option ignore \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0<\/p>\n<p>&nbsp;<\/p>\n<p>config prefix<\/p>\n<p>option interface \u00a0 \u00a0 \u00a0 \u00a0\u2019lan\u2019<\/p>\n<p># If not specified, a non-link-local prefix of the interface is used<\/p>\n<p>option prefix \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u20192001:470:1f0b:9999::\/64\u2032<\/p>\n<p>option AdvOnLink \u00a0 \u00a0 \u00a0 \u00a01<\/p>\n<p>option AdvAutonomous \u00a0 \u00a01<\/p>\n<p>option AdvRouterAddr \u00a0 \u00a00<\/p>\n<p>option ignore \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 0<\/p>\n<p>&nbsp;<\/p>\n<p>config rdnss<\/p>\n<p>option interface \u00a0 \u00a0 \u00a0 \u00a0\u2019lan\u2019<\/p>\n<p># If not specified, the link-local address of the interface is used<\/p>\n<p>option addr \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u20192001:470:1f0b:9999::\/64\u2032<\/p>\n<p>option ignore \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 1<\/p>\n<\/div>\n<p>Alterar o endere\u00e7o \u201c:9999\u201d para a rota que voc\u00ea utilizou. Salvar o arquivo e executar os comandos para que as altera\u00e7\u00f5es sejam aplicadas:<\/p>\n<p>&nbsp;<\/p>\n<div><code>\/etc\/init.d\/radvd enable <\/code><code>\/etc\/init.d\/radvd start<\/code><\/p>\n<\/div>\n<p>7. A configura\u00e7\u00e3o est\u00e1 completa. Reiniciar o roteador e testar o t\u00fanel. Pode-se executar o ping6 diretamente no roteador e funcionando corretamente execut\u00e1-lo a partir de um computador na LAN:<\/p>\n<div><code><br \/>\nping6 ipv6.google.com<br \/>\n<\/code><\/div>\n<p>Em caso de d\u00favidas, os tutoriais da Hurricane Eletric ou do OpenWRT podem ser consultados em:<\/p>\n<p><a href=\"http:\/\/www.tunnelbroker.net\/forums\/index.php?topic=1016.0\">http:\/\/www.tunnelbroker.net\/forums\/index.php?topic=1016.0<\/a><\/p>\n<p><a href=\"http:\/\/wiki.openwrt.org\/doc\/uci\/network#dynamic.ipv6-in-ipv4.tunnel.he.net.only\">http:\/\/wiki.openwrt.org\/doc\/uci\/network#dynamic.ipv6-in-ipv4.tunnel.he.net.only<\/a><\/p>\n<p>Outro exemplo de confugura\u00e7\u00e3o \u00e9 a utiliza\u00e7\u00e3o de Tunnel Broker no Windows. \u00c9 poss\u00edvel utiliz\u00e1-lo em diversas vers\u00f5es do WIndows (2000, XP, 2008, Vista e 7) desde que o suporte IPv6 seja instalado nas vers\u00f5es que n\u00e3o o suportam nativamente. A configura\u00e7\u00e3o deve ser feita atrav\u00e9s do console usando um usu\u00e1rio com permiss\u00f5es administrativas. As configura\u00e7\u00f5es para estas vers\u00f5es do Windows s\u00e3o:<\/p>\n<div><code><\/code><code><br \/>\n<strong>Explica\u00e7\u00e3o das vari\u00e1veis usadas:<\/strong><\/code>$ipv4a = IPv4 do servidor do t\u00fanel<\/p>\n<p>$ipv4b = IPv4 do usu\u00e1rio do t\u00fanel<\/p>\n<p>$ipv6a = rede \/64 alocada ao lado do servidor do t\u00fanel<\/p>\n<p>$ipv6b = rede \/64 alocada ao lado do usu\u00e1rio do t\u00fanel<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Windows 2000\/XP:<\/strong><\/p>\n<p>ipv6 install<\/p>\n<p>ipv6 rtu ::\/0 2\/::$ipv4a pub<\/p>\n<p>ipv6 adu 2\/$ipv6b<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Windows 2008\/Vista\/7<\/strong><\/p>\n<p>netsh interface ipv6 add v6v4tunnel interface=IP6Tunnel $ipv4b $ipv4a<\/p>\n<p>netsh interface ipv6 add address IP6Tunnel $ipv6b<\/p>\n<p><code>netsh interface ipv6 add route ::\/0 IP6Tunnel $ipv6a<\/code><\/p>\n<\/div>\n<p><a name=\"tecnicas-ds\"><\/a><\/p>\n<h2>7. Dual Stack Lite (DS-Lite)<\/h2>\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Ser\u00e3o analisadas agora algumas t\u00e9cnicas bastante pertinentes ao momento atual da transi\u00e7\u00e3o para o IPv6, num cen\u00e1rio em que n\u00e3o h\u00e1 mais IPv4 dispon\u00edveis, mas a base de usu\u00e1rios do provedor continua a crescer e ainda h\u00e1 muitos servi\u00e7os exclusivamente dispon\u00edveis em IPv4 na Internet. Desta forma, o provedor n\u00e3o pode oferecer exclusivamente conectividade IPv6 ao usu\u00e1rio final, sendo for\u00e7ado a oferecer tamb\u00e9m conectividade IPv4, mas com IPs de alguma forma compartilhados.<\/p>\n<p>A primeira t\u00e9cnica a ser analisada ser\u00e1 o Dual Stack Lite (Pilha dupla simplificada), padronizada na RFC 6333. Ela pode ser aplicada em situa\u00e7\u00f5es em que o provedor j\u00e1 oferece IPv6 nativo para seus usu\u00e1rios. Sua implementa\u00e7\u00e3o necessita de um equipamento denominado AFTR (Address Family Transition Router), que implementa um CGN (Carrier Grade NAT), que \u00e9 um NAT de grande porte, na rede do provedor. Entre o AFTR e o CPE do usu\u00e1rio utiliza-se um t\u00fanel IPv4 sobre IPv6 para transportar o tr\u00e1fego IPv4. No contexto do DS-Lite, o CPE do usu\u00e1rio \u00e9 chamado de B4, abrevia\u00e7\u00e3o para DS-Lite Basic Bridging BroadBand. Nas extremidades desses t\u00faneis s\u00e3o usados endere\u00e7os da faixa 192.0.0.0\/29, especialmente reservada para este fim. Para o CPE do usu\u00e1rio e os demais equipamentos da rede do usu\u00e1rio s\u00e3o utilizados IPs da RFC 1918\u00a0e n\u00e3o h\u00e1 problema se diferentes usu\u00e1rios utilizarem faixas de IPs repetidas, dado que o AFTR identifica os diferentes t\u00faneis com base no IPv6 de origem dos pacotes encapsulados. Na CPE do usu\u00e1rio deve existir um DHCP v4 para a distribui\u00e7\u00e3o dos endere\u00e7os na rede interna. Deve existir tamb\u00e9m um proxy DNS, que permita consultas via IPv4, mas fa\u00e7a essas consultas ao DNS recursivo do provedor via IPv6, evitando tradu\u00e7\u00f5es desnecess\u00e1rias no AFTR.<\/p>\n<p>\u00c9 importante frisar alguns pontos:<\/p>\n<ul>\n<li>O AFTR usa CGN, mas n\u00e3o for\u00e7a o usu\u00e1rio a utilizar duplo NAT. Ou seja, AFTR realiza a fun\u00e7\u00e3o de NAT, de forma concentrada, para cada um dos dispositivos de cada usu\u00e1rio.<\/li>\n<li>O DS-Lite utiliza endere\u00e7os privados na faixa 192.0.0.0\/29 para as extremidades dos t\u00faneis v4 sobre v6, evitando a utiliza\u00e7\u00e3o desnecess\u00e1ria de endere\u00e7os IPv4 na infraestrutura do provedor.<\/li>\n<\/ul>\n<p>A figura 19 mostra um exemplo de topologia.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-19\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-19.png\" alt=\"\" width=\"452\" height=\"206\" \/><br \/>\n<strong><br \/>\nFigura 19: Exemplo topologia DS-Lite<br \/>\n<\/strong><\/p>\n<p>Uma alternativa para implantar o DS-Lite \u00e9 a utiliza\u00e7\u00e3o do software AFTR desenvolvido pelo ISC (Internet Systems Consortium), inicialmente por solicita\u00e7\u00e3o e com financiamento da Comcast, um grande provedor que opera com cabo nos Estados Unidos. O software est\u00e1 dispon\u00edvel no URL <a href=\"http:\/\/www.isc.org\/software\/aftr\">http:\/\/www.isc.org\/software\/aftr<\/a>\u00a0e pode ser utilizado em servidores GNU\/Linux no provedor, permitindo uma implementa\u00e7\u00e3o de baixo custo, robusta e escal\u00e1vel. \u00a0Para o B4 (CPE) podem ser utilizados tamb\u00e9m dispositivos rodando Linux. Em especial, \u00e9 poss\u00edvel utilizar roteadores Linksys WRT54GL e outros compat\u00edveis com o firmware OpenWRT dispon\u00edvel no URL:<\/p>\n<p><a href=\"http:\/\/www.kangaroo.comcast.net\/wiki\/doku.php?id=wrt54gl:wrt54gl\">http:\/\/www.kangaroo.comcast.net\/wiki\/doku.php?id=wrt54gl:wrt54gl<\/a>.<\/p>\n<p>A configura\u00e7\u00e3o desta topologia \u00e9 bastante simples. Para configurar o AFTR, \u00a0basta criar um arquivo chamado aftr-script, contendo:<\/p>\n<div><code><\/code><code>aftr_start() {<\/code>set -x<\/p>\n<p>ip link set tun0 up<\/p>\n<p>ip addr add 192.0.0.1 peer 192.0.0.2 dev tun0<\/p>\n<p>ip route add 203.0.113.1\/32 dev tun0<\/p>\n<p>ip -6 addr add fe80::1 dev tun0<\/p>\n<p>ip -6 route add 2001:db8:c::1\/64 dev tun0<\/p>\n<p>arp -i eth0 -s 203.0.113.131 0a:0b:0c:0d:0e:f0 pub<\/p>\n<p>}<\/p>\n<p>aftr_stop() {<\/p>\n<p>set -x<\/p>\n<p>ip link set tun0 down<\/p>\n<p>}<\/p>\n<p>case \u201c$1\u201d in<\/p>\n<p>start)<\/p>\n<p>aftr_start<\/p>\n<p>;;<\/p>\n<p>stop)<\/p>\n<p>aftr_stop<\/p>\n<p>;;<\/p>\n<p>*)<\/p>\n<p>echo \u201cUsage: $0 start|stop\u201d\u201d<\/p>\n<p>exit 1<\/p>\n<p>;;<\/p>\n<p>esac<\/p>\n<p><code>exit 0<\/code><\/p>\n<\/div>\n<p>E um arquivo de configura\u00e7\u00e3o chamado aftr.conf, contendo:<\/p>\n<div><code><br \/>\ndefault tunnel mss on<\/code>defmtu 1450<\/p>\n<p>address endpoint 2001:db8:c::1<\/p>\n<p>address icmp 203.0.113.1<\/p>\n<p>pool 203.0.113.1<\/p>\n<p>acl6 ::0\/0<\/p>\n<p>&nbsp;<\/p>\n<\/div>\n<p>E ent\u00e3o iniciar o servi\u00e7o.<\/p>\n<p>Para o B4 (CPE), basta criar o t\u00fanel IPv4 sobre IPv6:<\/p>\n<div><code><\/code><code><br \/>\nmodprobe ip6_tunnel<\/code>ip -6 tunnel add dsltun mode ipip6 remote 2001:db8:c::1 local 2001:db8:0:b::1 dev eth1<\/p>\n<p>ip addr add 192.0.0.2 peer 192.0.0.1 dev dsltun<\/p>\n<p>ip link set dev dsltun up<\/p>\n<p>ip route add default dev dsltun<\/p>\n<p><code>\u00a0<\/code><\/p>\n<\/div>\n<p>Al\u00e9m disso, deve-se configurar o DHCPv4 e o proxy DNS no B4.<\/p>\n<p>Esse exemplo de configura\u00e7\u00e3o usa apenas um endere\u00e7o para o pool de NAT, mas poderiam ser utilizados mais. Note que o endere\u00e7o IPv4 da interface f\u00edsica do servidor AFTR n\u00e3o est\u00e1 na mesma rede dos endere\u00e7os usados no pool. O endere\u00e7o IPv6 da extremidade AFTR do t\u00fanel n\u00e3o \u00e9 o endere\u00e7o f\u00edsico da interface, mas outro, numa rede diferente. Os pacotes direcionados para os endere\u00e7os do Pool IPv4 e para o endere\u00e7o IPv6 da extremidade do t\u00fanel s\u00e3o roteados para a interface de t\u00fanel e tratados pelo software AFTR. Por fim, \u00e9 importante notar que os mesmos endere\u00e7os 192.0.0.1 e 192.0.0.2 s\u00e3o usados para m\u00faltiplos clientes e que a detec\u00e7\u00e3o de novos t\u00faneis de clientes \u00e9 feita automaticamente pelo AFTR, com base no endere\u00e7o IPv6 de origem dos mesmos.<\/p>\n<p>Uma varia\u00e7\u00e3o desta t\u00e9cnica, \u00a0que tenta resolver o mesmo problema, \u00e9 a combina\u00e7\u00e3o do DS Lite com o Address Plus Port (A+P) e \u00e9 conhecida como DS Lite A+P. O A+P ser\u00e1 apresentado com mais detalhes no item 17 deste texto. O funcionamento do DS Lite A+P \u00e9 similar ao DS Lite, mas ao inv\u00e9s de ser um endere\u00e7o IPv4 privado, o CPE do usu\u00e1rio recebe um endere\u00e7o IPv4 p\u00fablico. As portas dispon\u00edveis para utiliza\u00e7\u00e3o, contudo, s\u00e3o limitadas, pois este IP p\u00fablico \u00e9 compartilhado com outros n\u00f3s. O CPE deve ent\u00e3o realizar a fun\u00e7\u00e3o de tradu\u00e7\u00e3o de endere\u00e7os (NAT), oferecendo IPs privados (RFC 1918) para os demais n\u00f3s na rede, mas obedecendo \u00e0 restri\u00e7\u00e3o das portas imposta pelo A+P na tradu\u00e7\u00e3o.<\/p>\n<p>Com a utiliza\u00e7\u00e3o do DS-Lite com A+P, a escalabilidade \u00e9 melhor, dado que o NAT \u00e9 feito de forma distribuida, nos CPEs. O usu\u00e1rio pode tamb\u00e9m realizar o mapeamento de portas no NAT e receber conex\u00f5es entrantes, numa situa\u00e7\u00e3o muito pr\u00f3xima a que existiria sem o compartilhamento de endere\u00e7os.<\/p>\n<p>O DS Lite com A+P \u00e9 ilustrado na figura a<sup><a name=\"cmnt_ref1\"><\/a>[a]<\/sup>\u00a0seguir. Na figura, o CPE recebe o endere\u00e7o IPv4 restrito das portas 1024 a 2047, \u00e0 guisa de exemplo, mas tanto as portas dispon\u00edveis, quanto a quantidade das mesmas, poderiam ser outras.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-20\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-20.png\" alt=\"\" width=\"452\" height=\"206\" \/><\/p>\n<p><strong>Figura 20: Exemplo topologia DS-Lite com A+P<\/strong><br \/>\nDeve-se notar que o DS-Lite e o DS-Lite com A+P usam IPv4 sobre IPv6, mas utilizam-se de t\u00e9cnicas stateful para o compartilhamento dos endere\u00e7os IPv4.<\/p>\n<p><a name=\"tecnicas-ivis\"><\/a><\/p>\n<h2>8. IVI, dIVI e dIVI-pd<\/h2>\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>Sim<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>No item anterior foi apresentado o DS-Lite, que era \u00fatil para utiliza\u00e7\u00e3o no provedor, num cen\u00e1rio em que n\u00e3o h\u00e1 mais endere\u00e7os IPv4 dispon\u00edveis, mas onde sua base de usu\u00e1rios continua a crescer. Desta forma, o provedor n\u00e3o pode oferecer exclusivamente conectividade IPv6 ao usu\u00e1rio final, sendo for\u00e7ado a oferecer tamb\u00e9m conectividade IPv4, mas com IPs de alguma forma compartilhados.<\/p>\n<p>O dIVI (draft-xli-behave-divi-04)\u00a0e o dIVI-pd (draft-xli-behave-divi-pd-01) s\u00e3o alternativas\u00a0de solu\u00e7\u00e3o para o mesmo problema, mas t\u00eam a vantagem de usar t\u00e9cnicas stateless baseadas numa dupla tradu\u00e7\u00e3o de pacotes, diferentemente\u00a0do DS-Lite, que \u00e9 stateful e baseado em tunelamento. Estes m\u00e9todos de tradu\u00e7\u00e3o stateless s\u00e3o capazes de manter\u00a0a transpar\u00eancia fim a fim do endere\u00e7o IP, n\u00e3o necessitando de t\u00e9cnicas auxiliares como DNS64 (tradu\u00e7\u00e3o de DNS) ou ALG (gateways para aplica\u00e7\u00f5es espec\u00edficas). Ambos os protocolos usam compartilhamento de IPs v4 com restri\u00e7\u00e3o de portas, de forma an\u00e1loga ao A+P, discutido no item 17.<\/p>\n<p>Ambas as solu\u00e7\u00f5es s\u00e3o extens\u00f5es do IVI (RFC6219), cujo nome vem da concatena\u00e7\u00e3o dos numerais romanos IV (4) e VI (6). O IVI \u00e9 um mecanismo de tradu\u00e7\u00e3o stateless 1:1, desenvolvido por pesquisadores da CERNET2, a rede acad\u00eamica chinesa, que \u00e9 somente IPv6. A China optou por criar uma rede acad\u00eamica IPv6 pura, totalmente nova, no lugar de implantar o IPv6 em pilha dupla na rede j\u00e1 existente. Essa estrat\u00e9gia pode parecer estranha atualmente, mas permitiu o desenvolvimento da industria nacional de equipamentos de rede e, em conjunto com incentivos econ\u00f4micos para uso da nova rede, alavancou a implanta\u00e7\u00e3o do IPv6 nas universidades e o desenvolvimento de diversas aplica\u00e7\u00f5es. Em muitas universidades chinesas, na atualidade, o tr\u00e1fego IPv6 \u00e9 maior do que o IPv4<\/p>\n<p>O IVI foi criado inicialmente para permitir que servidores IPv6, ligados \u00e0 CERNET2, pudessem comunicar-se com a Internet IPv4. Para isso um endere\u00e7o IPv4 \u00e9 atribu\u00eddo virtualmente ao dispositivo, utilizando-se um mecanismo de tradu\u00e7\u00e3o de pacotes stateless.<\/p>\n<p>As tr\u00eas solu\u00e7\u00f5es, IVI, dIVI e dIVI-pd s\u00e3o experimentais. Existem relatos de implanta\u00e7\u00e3o e teste realizados na CERNET\/CERNET2 e pela China Telecom. Para o IVI h\u00e1 c\u00f3digo dispon\u00edvel publicamente, na forma de um patch para o kernel do Linux, para o dIVI e o dIVI-pd n\u00e3o h\u00e1 implementa\u00e7\u00f5es p\u00fablicas dispon\u00edveis.<\/p>\n<p>Em primeiro lugar, ser\u00e1 apresentado o funcionamento do\u00a0IVI.<\/p>\n<p>Pode-se entender o conceito do funcionamento do IVI imaginando-se que ele cria um n\u00f3 IPv6 espelho para o IPv4 e um n\u00f3 IPv4 espelho para o IPv6, sendo que um n\u00f3 espelho \u00e9 um endere\u00e7o que simula a presen\u00e7a do dispositivo na rede, mas que na verdade encaminha os pacotes enviados a ele para o dispositivo real atrav\u00e9s da tradu\u00e7\u00e3o stateless. O servidor ou usu\u00e1rio IPv6 nativo na rede atendida pelo IVI, embora n\u00e3o tenha um endere\u00e7o IPv4 atribu\u00eddo a si, \u00e9 visto por um n\u00f3 IPv4 na Internet por meio de seu \u201cendere\u00e7o espelho\u201d e, de forma an\u00e1loga, enxerga um n\u00f3 IPv4 qualquer na Internet por meio de seu \u201cendere\u00e7o IPv6 espelho\u201d.<\/p>\n<p>A figura abaixo demonstra o conceito.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-21\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-21.png\" alt=\"\" width=\"485\" height=\"206\" \/><\/p>\n<p><strong>Figura 21: Explica\u00e7\u00e3o conceitual do IVI<\/strong><\/p>\n<p>O provedor, para implantar o IVI, escolhe um subconjunto de seu bloco IPv4, que ser\u00e1 usado para formar endere\u00e7os IPv6, a fim de atender os servidores, ou usu\u00e1rios somente IPv6, que se comunicar\u00e3o com a Internet IPv4 por meio do IVI. Os endere\u00e7os s\u00e3o mapeados conforme a figura a seguir.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-22\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-22.png\" alt=\"\" width=\"280\" height=\"194\" \/><\/p>\n<p><strong>Figura 22: Mapeamento de endere\u00e7os IPv6 em IPv4 e vice-versa<\/strong><\/p>\n<p>Por exemplo, um provedor cujo bloco IPv6 \u00e9 2001:db8::\/32 e cujo bloco IPv4 \u00e9 192.61.100.0\/24 pode escolher o prefixo IPv6 2001:db8:ff00::\/40 e o bloco IPv4 192.51.100.0\/26 para formar os endere\u00e7os IVI. Os endere\u00e7os IPv4 s\u00e3o mapeados para IPv6, ent\u00e3o, da seguinte forma:<\/p>\n<div>\n<p>192.51.100.1 &#8211; 2001:db8:ffc0:3364:0100::0192.51.100.2 &#8211; 2001:db8:ffc0:3364:0200::0(&#8230;)<\/p>\n<p>192.51.100.62 &#8211; 2001:db8:ffc0:3364:3e00::0<\/p>\n<\/div>\n<p>Na implementa\u00e7\u00e3o feita pela CERNET o prefixo \u00e9 um \/40 e os bits de 32 a 39 s\u00e3o todos 1, para identificar o endere\u00e7o IVI. Os bits 40 a 71 abrigam o endere\u00e7o v\u00e1lido IPv4, representado no formato hexadecimal. Nesse formato, um IPv4 \/24 \u00e9 mapeado para um IPv6 \/64 e um IPv4 \/32 \u00e9 mapeado para um IPv6 \/72, mas o sufixo usado \u00e9 sempre composto por zeros, de forma que apenas um endere\u00e7o IPv6 \u00e9, na pr\u00e1tica, mapeado para um endere\u00e7o IPv4.<\/p>\n<p>Note que o IVI n\u00e3o \u00e9 uma solu\u00e7\u00e3o para o esgotamento do IPv4. Para seu funcionamento \u00e9 necess\u00e1rio separar um conjunto de endere\u00e7os IPv4 v\u00e1lidos, do bloco dispon\u00edvel no provedor, e mape\u00e1-lo para um conjunto de endere\u00e7os IPv6 globais. A tradu\u00e7\u00e3o no IVI \u00e9 feita de forma stateless, o que \u00e9 simples de implementar e escala bem. Note tamb\u00e9m que o IVI precisa funcionar em conjunto com o DNS64, caso seja necess\u00e1rio resolver os nomes de dispositivos IPv4. Veja ainda que os m\u00e9todos de tradu\u00e7\u00e3o como IVI e NAT64 n\u00e3o funcionam com aplica\u00e7\u00f5es que carregam os endere\u00e7os IP na camada de aplica\u00e7\u00e3o, sendo necess\u00e1ria a utiliza\u00e7\u00e3o de ALGs (Application Layer Gateways) nesses casos. Por fim, \u00e9 importante observar que o IVI oferece conectividade fim a fim, seja IPv4 ou IPv6, para os dispositivos atendidos.<\/p>\n<p><a title=\"transicao-23\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-23.png\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-23\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-23.png\" alt=\"\" width=\"457\" height=\"165\" \/><\/a><\/p>\n<p><strong>Figura 23: Tradu\u00e7\u00e3o de endere\u00e7os no IVI<\/strong><\/p>\n<p>As regras aplicadas na tradu\u00e7\u00e3o do cabe\u00e7alho dos pacotes est\u00e3o especificadas na RFC 6145\u00a0e s\u00e3o mostradas a seguir:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-24\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-24.png\" alt=\"\" width=\"444\" height=\"353\" \/><\/p>\n<p><strong>Figura 24: Convers\u00e3o de cabe\u00e7alhos IPv4 para IPv6<\/strong><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-25\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-25.png\" alt=\"\" width=\"441\" height=\"278\" \/><\/p>\n<p><strong>Figura 25: Convers\u00e3o de cabe\u00e7alhos IPv6 para IPv4<\/strong><\/p>\n<p>O caso de aplica\u00e7\u00e3o mais comum para o IVI \u00e9 oferecer visibilidade IPv4 para servidores somente IPv6 dentro de uma determinada rede, mas ele poderia ser utilizado tamb\u00e9m para usu\u00e1rios, com a mesma finalidade, desde que haja uma quantidade suficiente de endere\u00e7os IPv4 dispon\u00edveis. Os dispositivos que utilizarem o IVI devem usar endere\u00e7amento manual ou DHCPv6, pois o endere\u00e7o precisa seguir um padr\u00e3o espec\u00edfico que n\u00e3o pode ser obtido pela autoconficura\u00e7\u00e3o IPv6.<\/p>\n<p>O IVI ainda n\u00e3o est\u00e1 largamente implementado e atualmente a \u00fanica maneira de test\u00e1-lo \u00e9 atrav\u00e9s do Linux. Para usar o IVI \u00e9 necess\u00e1rio aplicar um patch ao kernel do Linux, este patch est\u00e1 dispon\u00edvel em:\u00a0<a href=\"http:\/\/www.ivi2.org\/IVI\/\">http:\/\/www.ivi2.org\/IVI\/<\/a>.<\/p>\n<p>Ap\u00f3s aplicar o patch \u00e9 necess\u00e1rio habilitar a op\u00e7\u00e3o IVI e o protocolo IPv6 deve ser adicionado no modo \u201cbuilt in\u201d e n\u00e3o como m\u00f3dulo. No menuconfig do kernel estas op\u00e7\u00f5es est\u00e3o em:<\/p>\n<div><code><br \/>\nNetworking \u2192<br \/>\nNetworking Options \u2192<br \/>\n[*] IVI(test only)<br \/>\n&lt;*&gt; The IPv6 protocol<\/code><\/div>\n<p>Deve-se ent\u00e3o compilar e instalar o kernel, \u00a0e executar o script de configura\u00e7\u00e3o abaixo, fazendo as modifica\u00e7\u00f5es de endere\u00e7o necess\u00e1rias para a rede onde a t\u00e9cnica ser\u00e1 aplicada:<\/p>\n<div><code><\/code><code><br \/>\n#!\/bin\/bash<br \/>\n# habilite o redirecionamento (forwarding)<br \/>\necho 1 &gt; \/proc\/sys\/net\/ipv6\/conf\/all\/forwarding<br \/>\necho 1 &gt; \/proc\/sys\/net\/ipv4\/conf\/all\/forwarding<\/code># configure rota para IVI6 = 2001:0db8:ffc0:3364::\/70,<br \/>\n# \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 IVI4 = 192.51.100.0\/26<\/p>\n<p># configure rota IPv6, sempre configurar rotas explicitas para as<\/p>\n<p># redes mapeadas, nao usar rotas default<\/p>\n<p>route add -A inet6 2001:0db8:ffc0:3364::\/70 gw 2001:db8::1 dev eth0<\/p>\n<p># configure mapeamento para \u00a0 \u00a0 \u00a0source-PF = 2001:db8::\/48<br \/>\n# configure mapeamento para destination-PF = 2001:db8::\/48<\/p>\n<p># para cada mapeamento, um pseudo-endere\u00e7o \u00fanico (10.0.0.x\/8) deve ser configurado<br \/>\nip addr add 10.0.0.1\/8 dev eth0<\/p>\n<p># Mapeamento IPv4-to-IPv6, m\u00faltiplos mapeamentos podem ser feitos via m\u00faltiplos<\/p>\n<p># comandos:<\/p>\n<p># mroute IVI4-network IVI4-mask pseudo-address interface source-PF destination-PF<br \/>\nmroute 192.51.100.0 255.255.255.192 10.0.0.1 eth0 2001:db8:: 2001:db8::<\/p>\n<p><code># Mapeamento IPv6-to-IPv4<br \/>\n# mroute6 destination-PF destination-PF-pref-len<br \/>\nmroute6 2001:db8:ff00:: 40<\/code><\/p>\n<\/div>\n<p>Uma vez apresentado o IVI, pode-se entender o funcionamento do dIVI e do dIVI-pd. Ambas as t\u00e9cnicas utilizam tradu\u00e7\u00e3o dupla e compartilhamento de endere\u00e7os IPv4, com restri\u00e7\u00e3o de portas. Dessa forma, os n\u00f3s atendidos por elas usam pilha dupla, tendo IPv6 nativo para a comunica\u00e7\u00e3o com a Internet IPv6 e um IPv4 compartilhado. Com o dIVI e o dIVI-pd a comunica\u00e7\u00e3o fim a fim \u00e9 poss\u00edvel, tanto com o uso de IPv4, como com o uso de IPv6, guardando-se a restri\u00e7\u00e3o de que apenas um subconjunto do total de portas est\u00e1 dispon\u00edvel para um determinado dispositivo no IPv4. N\u00e3o \u00e9 necess\u00e1rio o uso de NAT64 e nem de ALG.<\/p>\n<p>A figura 26 representa tanto o funcionamento do dIVI, quanto do dIVI-pd.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-26\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-26.png\" alt=\"\" width=\"410\" height=\"241\" \/><\/p>\n<p><strong>Figura 26: Topologia da rede com a utiliza\u00e7\u00e3o do dIVI e dIVI-pd<\/strong><\/p>\n<p>A seguir o funcionamento do dIVI\u00a0ser\u00e1 apresentado com maior n\u00edvel de detalhamento.<\/p>\n<p>No dIVI os endere\u00e7os IPv4 s\u00e3o mapeados em IPv6 usando um formato definido no draft-bcx-behave-address-fmt-extension, que \u00e9 uma extens\u00e3o da RFC 6052. \u00a0Nesse formato, que pode usar prefixos IPv6 com diferentes tamanhos, \u00e9 poss\u00edvel carregar o endere\u00e7o IPv4 que est\u00e1 sendo compartilhado e tamb\u00e9m informa\u00e7\u00f5es que identificam quais s\u00e3o as faixas de portas que podem ser utilizadas pelo n\u00f3: o PSID que \u00e9 uma esp\u00e9cie de identificador da CPE e o Q, que indica qual a taxa de compartilhamento de endere\u00e7os. Com essas informa\u00e7\u00f5es um algoritmo muito simples na CPE identifica quais portas podem e quais n\u00e3o podem ser usadas. De forma an\u00e1loga, o tradutor IVI N:1 na rede do provedor traduz o IPv4 de destino para o endere\u00e7o IPv6 correspondente, baseando-se tanto no endere\u00e7o, quanto na porta. Os bits de 64 a 71, representados por \u201cu\u201d, devem possuir valor zero. Eles s\u00e3o reservados para compatibilidade com o formato de identifica\u00e7\u00e3o de dispositivo na arquitetura de endere\u00e7amento IPv6, de acordo com a RFC 4291.<\/p>\n<p><a title=\"transicao-27\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-27.jpg\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-27\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-27-1024x312.jpg\" alt=\"\" width=\"491\" height=\"150\" \/><\/a><\/p>\n<p><strong>Figura 27: Endere\u00e7amento IPv6 traduzido do IPv4 pelo dIVI<\/strong><\/p>\n<p>Na CPE pode haver dois tipos de tradu\u00e7\u00e3o. Pode ser feita uma tradu\u00e7\u00e3o totalmente stateless, mas, nesse caso, o n\u00f3 deve conhecer a priori a restri\u00e7\u00e3o das portas e enviar os pacotes j\u00e1 obedecendo a isso. Outra possibilidade \u00e9 a tradu\u00e7\u00e3o na CPE ser parcialmente statefull, de forma que o n\u00f3 n\u00e3o precise obedecer a qualquer restri\u00e7\u00e3o quanto \u00e0 porta de origem. Nesse segundo caso, a CPE deve fazer a tradu\u00e7\u00e3o das portas e manter o estado dessa tradu\u00e7\u00e3o.<\/p>\n<p>Note-se que no dIVI apenas um endere\u00e7o IPv4 e um endere\u00e7o IPv6 s\u00e3o atribu\u00eddos ao dispositivo. Um caso de uso esperado para essa t\u00e9cnica \u00e9 o uso para dispositivos m\u00f3veis, em redes 3G ou 4G. O sistema operacional do dispositivo poderia suportar as fun\u00e7\u00f5es da CPE dIVI, ou seja, tradu\u00e7\u00e3o 1:1 de IPv4 para IPv6 e mapeamento de portas, de forma que, funcionando como um n\u00f3 somente IPv6 na realidade, ainda assim pudesse oferecer uma API pilha dupla para as aplica\u00e7\u00f5es.<\/p>\n<p>Uma vez detalhado o funcionamento do dIVI, pode-se agora apresentar com mais detalhes o funcionamento do dIVI-pd.<\/p>\n<p>O dIVI e o dIVI-pd s\u00e3o, de fato, muito parecidos. O dIVI-pd permite que seja designado um prefixo IPv6 para o dispositivo, no lugar de um \u00fanico endere\u00e7o. Dessa forma \u00e9 poss\u00edvel utilizar a autoconfigura\u00e7\u00e3o stateless, ou ainda endere\u00e7ar toda uma rede com diversos n\u00f3s. \u00c9 importante observar que apenas um endere\u00e7o IPv4 continua sendo atribu\u00eddo para cada CPE no dIVI-pd, de forma que se for necess\u00e1rio atribuir endere\u00e7os IPv4 para mais de um n\u00f3, a CPE dever\u00e1 faz\u00ea-lo utilizando NAT44 e endere\u00e7os privados, da RFC 1918.<\/p>\n<p>O dIVI-pd tamb\u00e9m utiliza os endere\u00e7os no formato definido pela RFC 6052, com o prefixo de comprimento \/64 e dois tipos de extens\u00f5es, o CPE index, como parte do prefixo e o sufixo no mesmo formato utilizado pelo dIVI.<\/p>\n<p><a title=\"transicao-28\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-28.jpg\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-28\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-28-1024x222.jpg\" alt=\"\" width=\"430\" height=\"93\" \/><\/a><strong>Figura 28: Endere\u00e7amento IPv6 traduzido do IPv4 pelo dIVI-pd<\/strong><\/p>\n<p>Note que para os usu\u00e1rios \u00e9 poss\u00edvel atribuir prefixos \/64, ou mais curtos, como \/60 ou \/56. Isso determina o valor de m (preenchimento com zeros). Note ainda que o fato do formato de sufixo ser o mesmo utilizado pelo dIVI permite a constru\u00e7\u00e3o de CPEs compat\u00edveis com as duas t\u00e9cnicas.<\/p>\n<p>O dIVI e o dIVI-pd\u00a0s\u00e3o realmente \u00f3timas solu\u00e7\u00f5es, tendo caracter\u00edsticas praticamente ideais para uso por provedores de acesso, por isso seu desenvolvimento e padroniza\u00e7\u00e3o devem ser acompanhados com muita aten\u00e7\u00e3o:<\/p>\n<ul>\n<li>operam com base em redes somente IPv6, que \u00e9 para onde caminha a Internet;<\/li>\n<li>utilizam tradu\u00e7\u00f5es stateless, que s\u00e3o simples de implementar e baratas do ponto de vista computacional, permitindo boa escalabilidade;<\/li>\n<li>permitem conex\u00f5es em ambos os sentidos, mantendo a conectividade de fim a fim;<\/li>\n<li>n\u00e3o necessitam de ALG ou DNS64;<\/li>\n<li>quando necess\u00e1rio o uso de t\u00e9cnicas statefull, para tradu\u00e7\u00e3o de portas, isso \u00e9 feito no lado do usu\u00e1rio, mantendo o princ\u00edpio de que a complexidade na Internet deve estar na extremidades e n\u00e3o pr\u00f3xima ao core da rede;<\/li>\n<li>a tradu\u00e7\u00e3o implementada no provedor, de IPv6 para IPv4, N:1, pode ser usada de forma isolada, em conjunto com DNS64 e eventualmente ALGs, para clientes soemte IPv6; CPEs com suporte \u00e0 tradu\u00e7\u00e3o no sentido inverso poderiam ser implementados apenas para os clientes para os quais esse m\u00e9todo n\u00e3o for suficiente e que realmente necessitarem de endere\u00e7os IPv4 nos dispositivos.<\/li>\n<\/ul>\n<p><a name=\"tecnicas-64\"><\/a><\/p>\n<h2>9. NAT64 e DNS64<\/h2>\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Uma outra t\u00e9cnica de tradu\u00e7\u00e3o aplic\u00e1vel em situa\u00e7\u00f5es similares as do IVI, dIVI e dIVI-pd, ou seja, para n\u00f3s somente IPv6 acessarem a Internet IPv4 \u00e9 o NAT64 (RFC 6146). O NAT64 \u00e9 uma t\u00e9cnica stateful de tradu\u00e7\u00e3o de pacotes IPv6 em IPv4. Ele necessita de uma t\u00e9cnica auxiliar para a convers\u00e3o do DNS, chamada de DNS64 (RFC 6147). S\u00e3o sistemas distintos, mas que trabalham em conjunto para permitir a comunica\u00e7\u00e3o entre as redes IPv6 e IPv4.<\/p>\n<p>O NAT64 necessita fazer a tradu\u00e7\u00e3o de endere\u00e7os IPv4 em IPv6, esta tradu\u00e7\u00e3o \u00e9 feita conforme ilustrado na figura 27. O processo \u00e9 definido em detalhes na RFC 6052:<\/p>\n<p><a title=\"transicao-29\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-29.jpg\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-29\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-29-1024x138.jpg\" alt=\"\" width=\"491\" height=\"66\" \/><\/a><br \/>\n<strong><br \/>\nFigura 29: Endere\u00e7amento IPv6 traduzido do IPv4 pelo NAT64<\/strong><\/p>\n<p>Os bits 64 a 71 s\u00e3o reservados para a compatibilidade de identifica\u00e7\u00e3o de host\u00a0conforme a RFC 4291\u00a0e devem ser zeros.<\/p>\n<p>O prefixo IPv6 pode ser escolhido pela operadora, mas \u00e9 recomendada a utiliza\u00e7\u00e3o do prefixo 64:ff9b::\/96,\u00a0reservado especificamente para a utiliza\u00e7\u00e3o em algoritmos de mapeamento de endere\u00e7os IPv4 em IPv6. Por exemplo, o IPv4 203.0.113.1 seria convertido para o endere\u00e7o IPv6 64:ff9b::203.0.113.1.<\/p>\n<p>J\u00e1 a tradu\u00e7\u00e3o do cabe\u00e7alho IPv6 em cabe\u00e7alho IPv4 e vice-versa \u00e9 feita da mesma maneira que no IVI, j\u00e1 estudado anteriormente. O processo est\u00e1 ilustrado nas figuras 24 e 25 e \u00e9 especificado em detalhes na RFC 6145.<\/p>\n<p>O funcionamento do NAT64 \u00e9 ilustrado no diagrama de sequ\u00eancia e na topologia das figuras 28 e 29, a seguir:<\/p>\n<p><a title=\"transicao-30\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-30.png\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-30\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-30.png\" alt=\"\" width=\"495\" height=\"389\" \/><\/a><br \/>\n<img loading=\"lazy\" decoding=\"async\" src=\"file:\/\/\/home\/tuany\/Downloads\/IPv6%20-%20Te%CC%81cnicas%20de%20Transic%CC%A7a%CC%83o%20-%20rev.2012.04.10-01\/images\/image05.png\" alt=\"\" width=\"558\" height=\"438\" \/><\/p>\n<p><strong>Figura 30: Diagrama de sequ\u00eancia do NAT64 \/ DNS64<\/strong><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-31\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-31.png\" alt=\"\" width=\"406\" height=\"163\" \/><br \/>\n<strong><br \/>\nFigura 31: Topologia de rede do NAT64 \/ DNS64<\/strong><\/p>\n<p>O NAT64 possui implementa\u00e7\u00f5es para Linux, Windows, grandes roteadores (Cisco e Juniper) e roteadores dom\u00e9sticos baseados em Linux. Como exemplo ser\u00e3o apresentadas a seguir configura\u00e7\u00f5es para Linux e Cisco.<\/p>\n<p>H\u00e1 v\u00e1rias op\u00e7\u00f5es de implementa\u00e7\u00e3o do NAT64 no Linux, uma delas \u00e9 a desenvolvida pelo projeto Ecdysis (<a href=\"http:\/\/ecdysis.viagenie.ca\">http:\/\/ecdysis.viagenie.ca<\/a>),\u00a0que tamb\u00e9m pode ser utilizada em sistemas operacionais *BSD. Apesar da necessidade de instalar um m\u00f3dulo ao kernel do Linux, sua instala\u00e7\u00e3o \u00e9 bastante simples. O arquivo fonte deve ser baixado em <a href=\"http:\/\/ecdysis.viagenie.ca\/download\/ecdysis-nf-nat64-20101117.tar.gz\">http:\/\/ecdysis.viagenie.ca\/download\/ecdysis-nf-nat64-20101117.tar.gz<\/a>\u00a0e descompactado em uma pasta adequada, na sequ\u00eancia os seguintes comandos devem ser executados como root:<\/p>\n<p>1. Ap\u00f3s o download, compile o m\u00f3dulo do kernel:<\/p>\n<div><code>make &amp;&amp; make install<\/code><\/div>\n<p>2. No arquivo nat64-config.sh comente as seguintes linhas:<\/p>\n<div><code><\/code><code># Load the nf_nat64 module<\/code>#modprobe -r nf_nat64<\/p>\n<p>#modprobe nf_nat64 nat64_ipv4_addr=$IPV4_ADDR nat64_prefix_addr=$PREFIX_ADDR nat64_prefix_len=$PREFIX_LEN<\/p>\n<p><code>\u00a0<\/code><\/p>\n<\/div>\n<p>3. Habilite o m\u00f3dulo do kernel:<\/p>\n<p>&nbsp;<\/p>\n<div><code><br \/>\ninsmod nf_nat64.ko nat64_ipv4_addr=$IPV4_ADDR nat64_prefix_addr=$PREFIX_ADDR nat64_prefix_len=$PREFIX_LEN<br \/>\n<\/code><\/div>\n<p>&nbsp;<\/p>\n<p>Os par\u00e2metros usados acima s\u00e3o os seguintes:<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><code>$IPV4_ADDR<\/code> = Endere\u00e7o IPv4 da interface conectada \u00e0 Internet<\/li>\n<li><code>$PREFIX_ADDR<\/code> = 64:ff9b::<\/li>\n<li><code>$PREFIX_LEN<\/code> = 96<\/li>\n<\/ul>\n<p>4. Verifique, atrav\u00e9s do comando lsmod, se o m\u00f3dulo foi lido corretamente. A sa\u00edda do comanda deve ser algo parecido com:<\/p>\n<div><code><br \/>\nModule \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0Size \u00a0Used by<br \/>\nnf_nat64 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 14542 \u00a00<br \/>\n<\/code><\/div>\n<p>5. Rode o arquivo de configura\u00e7\u00e3o:<\/p>\n<div><code><br \/>\n.\/nat64-config.sh $IPV4_ADDR<\/code><\/div>\n<p>6. Verifique se a interface NAT64 est\u00e1 \u201cup\u201d, atrav\u00e9s do comando ip link.<br \/>\n7. Pode-se testar a conectividade via NAT64 atrav\u00e9s do comando<\/p>\n<div><code><br \/>\nping6 64:ff9b::200.160.4.22<br \/>\n<\/code><\/div>\n<p>Para fazer a configura\u00e7\u00e3o do NAT64 em roteadores Cisco os comandos s\u00e3o:<\/p>\n<div><code><\/code><code>Router&gt; enable<\/code>Router# configure terminal<\/p>\n<p>Router(config)# ipv6 unicast-routing<\/p>\n<p>Router(config)# interface giabitethernet0\/0\/0<\/p>\n<p>Router(config-if)# description interface towards ipv4 side<\/p>\n<p>Router(config-if)# ipv6 enable<\/p>\n<p>Router(config-if)# ipv6 address 64:ff9b::\/96<\/p>\n<p>Router(config-if)# nat64 enable<\/p>\n<p>Router(config-if)# exit<\/p>\n<p>Router(config)# interface giabitethernet1\/2\/0<\/p>\n<p>Router(config-if)# description interface towards ipv6 side<\/p>\n<p>Router(config-if)# ip address 192.0.2.0 255.255.255.0<\/p>\n<p>Router(config-if)# nat64 enable<\/p>\n<p>Router(config-if)# exit<\/p>\n<p>Router(config)# nat64 prefix stateless 64:ff9b::\/96<\/p>\n<p>Router(config)# nat64 route 192.0.2.0\/24 gigabitethernet0\/0\/1<\/p>\n<p>Router# end<\/p>\n<p><code>\u00a0<\/code><\/p>\n<\/div>\n<p>Outra op\u00e7\u00e3o para Linux \u00e9 o projeto Linux NAT64, dispon\u00edvel em:<\/p>\n<p><a href=\"http:\/\/sourceforge.net\/projects\/linuxnat64\/\">http:\/\/sourceforge.net\/projects\/linuxnat64\/<\/a>.<\/p>\n<p>Um exemplo de configura\u00e7\u00e3o do NAT64 para roteadores Juniper est\u00e1 dispon\u00edvel em:<\/p>\n<p><a href=\"http:\/\/www.juniper.net\/techpubs\/en_US\/junos10.4\/information-products\/topic-collections\/nce\/nat64-ipv6-ipv4-depletion\/configuring-nat64-ipv6-ipv4-depletion.pdf\">http:\/\/www.juniper.net\/techpubs\/en_US\/junos10.4\/information-products\/topic-collections\/nce\/nat64-ipv6-ipv4-depletion\/configuring-nat64-ipv6-ipv4-depletion.pdf<\/a>;<\/p>\n<p>Para o DNS64 as principais op\u00e7\u00f5es s\u00e3o o Bind (<a href=\"http:\/\/www.isc.org\/software\/bind\">http:\/\/www.isc.org\/software\/bind<\/a>), que possui vers\u00f5es para Linux e Windows, ou o Totd (<a href=\"http:\/\/www.dillema.net\/software\/totd.html\">http:\/\/www.dillema.net\/software\/totd.html<\/a>), com vers\u00f5es para Linux e FreeBSD. Por ser mais atual e amplamente usado, o exemplo de configura\u00e7\u00e3o ser\u00e1 baseado no Bind. Ap\u00f3s a instala\u00e7\u00e3o do Bind, as seguintes linhas devem ser adicionadas ao arquivo de configura\u00e7\u00e3o :<\/p>\n<div><code><\/code><code><br \/>\noptions {<\/code>dns64 64:ff9b::\/96 {<\/p>\n<p>clients {any;};<\/p>\n<p>mapped {any;};<\/p>\n<p>suffix ::;<\/p>\n<p>recursive-only yes;<\/p>\n<p>break-dnssec yes;<\/p>\n<p><code>};<\/code><\/p>\n<\/div>\n<p>Depois, basta reiniciar o Bind para que a altera\u00e7\u00e3o tenha efeito.<\/p>\n<p>\u00c9 interessante notar que o DNS64 pode apresentar problemas em sua intera\u00e7\u00e3o com o DNSSEC. Um validador DNSSEC que n\u00e3o saiba lidar com o DNS64 pode rejeitar todos os dados que v\u00eam deste, como se n\u00e3o fossem v\u00e1lidos. A RFC 6147, onde o DNS64 \u00e9 definido, especifica formas de contornar o problema.<br \/>\n<a name=\"tecnicas-xlat\"><\/a><\/p>\n<h2>10. 464XLAT<\/h2>\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>O 464XLAT (draft-ietf-v6ops-464xlat-01) \u00e9 uma solu\u00e7\u00e3o similar ao dIVI e ao dIVI-pd, que utiliza dupla tradu\u00e7\u00e3o de IPv4 para IPv6, a fim de oferecer um IPv4 compartilhado para usu\u00e1rios IPv6 nativos. Esta t\u00e9cnica usa uma tradu\u00e7\u00e3o staless e outra stateful. O tradutor stateless \u00e9 chamado de CLAT (customer side translator) e faz uma tradu\u00e7\u00e3o 1:1, ou seja, cada IPv4 possui um IPv6 correspondente. O tradutor stateful \u00e9 o PLAT (provider side translator) e faz uma tradu\u00e7\u00e3o 1:N, onde v\u00e1rios IPv6 globais s\u00e3o representados por um IPv4 global para falar com a Internet IPv4.<\/p>\n<p>O funcionamento do 464XLAT \u00e9 ilustrado nas figuras a seguir:<\/p>\n<p><a title=\"transicao-32\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-32.png\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-32\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-32.png\" alt=\"\" width=\"448\" height=\"284\" \/><\/a><br \/>\n<strong><br \/>\nFigura 32: Diagrama de sequ\u00eancia do 464XLAT<\/strong><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-33\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-33.png\" alt=\"\" width=\"465\" height=\"143\" \/><\/p>\n<p><strong>Figura 33: Topologia de rede do 464XLAT<\/strong><\/p>\n<p>\u00c9 recomendado que haja um cache DNS implementado no CLAT, capaz de responder as solicita\u00e7\u00f5es dos clientes IPv4, fazendo as perguntas ao servidor DNS recursivo do provedor por meio do protocolo IPv6, evitando assim tradu\u00e7\u00f5es desnecess\u00e1rias para esse fim.<\/p>\n<p>O uso da tradu\u00e7\u00e3o stateless na extremidade do usu\u00e1rio e stateful no provedor n\u00e3o \u00e9 a melhor escolha, se levarmos em considera\u00e7\u00e3o os princ\u00edpios b\u00e1sicos de projeto da Internet. O inverso, como feito no dIVI, ou dIVI-pd, \u00e9 mais recomend\u00e1vel. Contudo, o 464XLAT n\u00e3o \u00e9 realmente uma t\u00e9cnica nova, projetada do zero, mas sim uma aplica\u00e7\u00e3o inovadora de duas t\u00e9cnicas j\u00e1 padronizadas e relativamente maduras.<\/p>\n<p>O CLAT \u00e9 uma tradu\u00e7\u00e3o stateless baseada na RFC 6145\u00a0e funciona de maneira semelhante ao IVI, mas utiliza IPv4 privado e n\u00e3o p\u00fablico. A forma como o endere\u00e7o IPv4 \u00e9 inclu\u00eddo no endere\u00e7o IPv6 tamb\u00e9m \u00e9 um pouco diferente. A regra de tradu\u00e7\u00e3o \u00e9:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-34\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-34-1024x138.jpg\" alt=\"\" width=\"491\" height=\"66\" \/><\/p>\n<p><strong>Figura 34: Endere\u00e7o IPv6 traduzido do IPv4 pelo 464XLAT<\/strong><\/p>\n<p>Este prefixo XLAT de 96 bits \u00e9 \u00fanico por cliente e \u00e9 atribu\u00eddo a este pelo provedor do servi\u00e7o. Como o prefixo utilizado \u00e9 um \/96 a autoconfigura\u00e7\u00e3o stateless n\u00e3o \u00e9 poss\u00edvel e \u00e9 necess\u00e1rio a utiliza\u00e7\u00e3o de DHCPv6 para a atribui\u00e7\u00e3o de endere\u00e7os. O CLAT pode ser implementado no CPE ou em celulares. Para a implementa\u00e7\u00e3o em celulares existe um projeto dispon\u00edvel para Android em <a href=\"http:\/\/code.google.com\/p\/android-clat\/\">http:\/\/code.google.com\/p\/android-clat\/<\/a>. Para a implementa\u00e7\u00e3o em CPE pode-se utilizar o \u00a0IVI (<a href=\"http:\/\/www.ivi2.org\/IVI\/\">http:\/\/www.ivi2.org\/IVI\/<\/a>), com as configura\u00e7\u00f5es adequadas.<\/p>\n<p>J\u00e1 o PLAT \u00e9 um NAT64 (RFC 6146)\u00a0que converte o endere\u00e7o IPv6 em um dos endere\u00e7os IPv4 dispon\u00edveis no banco de endere\u00e7os do provedor, para fazer a sua implementa\u00e7\u00e3o, basta seguir as recomenda\u00e7\u00f5es feitas na se\u00e7\u00e3o anterior.<\/p>\n<p>Testes foram realizados por pelo provedor estadunidense T-Mobile e o pelo Ponto de Troca de Tr\u00e1fego japon\u00eas JPIX, em conjunto com seus participantes. Sua implementa\u00e7\u00e3o em larga escala est\u00e1 sendo considerada. Os softwares ou implementa\u00e7\u00f5es do CLAT e XLAT n\u00e3o s\u00e3o vinculadas e diferentes vers\u00f5es de um ou do outro podem ser utilizadas para obter o sistema desejado.<\/p>\n<p>Embora n\u00e3o seja a solu\u00e7\u00e3o ideal, do ponto de vista t\u00e9cnico, \u00e9 uma solu\u00e7\u00e3o que poder\u00e1 ser usada em larga escala em breve, pois j\u00e1 existem implementa\u00e7\u00f5es funcionais de seus componentes b\u00e1sicos. \u00a0Outro ponto a considerar \u00e9 que o 464XLAT pode funcionar em conjunto com NAT64, j\u00e1 que o PLAT \u00e9 um NAT64. Basta acrescentar o DNS64 ao sistema. Usu\u00e1rios podem ser somente IPv6 e usar o NAT64\/DNS64 e migrar para a utiliza\u00e7\u00e3o do 464XLAT, acrescentando um CPE que execute a fun\u00e7\u00e3o de CLAT, caso haja, por exemplo, aplica\u00e7\u00f5es que n\u00e3o funcionem com o NAT64.<br \/>\n<a name=\"tecnicas-4rd\"><\/a><\/p>\n<h2>11. 4rd<\/h2>\n<table>\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>Sim<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>O 4rd \u00e9 uma solu\u00e7\u00e3o similar ao DS-Lite, no sentido de que usa t\u00faneis 4in6 para fornecer IPs vers\u00e3o 4 compartilhados para usu\u00e1rios que j\u00e1 t\u00eam IPv6 nativo. Mas, de forma an\u00e1loga \u00e0s t\u00e9cnicas de tradu\u00e7\u00e3o dIVI e 464XLAT, o 4rd \u00e9 stateless e usa compartilhamento de IPs com restri\u00e7\u00e3o de portas.<\/p>\n<p>A t\u00e9cnica foi desenvolvida com base no 6rd, que ser\u00e1 estudado mais \u00e0 frente, e est\u00e1 em processo de padroniza\u00e7\u00e3o, definida atualmente no draft-despres-intarea-4rd-01. Existe uma implementa\u00e7\u00e3o p\u00fablica que funciona no vyatta e pode ser encontrada no seguinte URL: <a href=\"http:\/\/bougaidenpa.org\/masakazu\/archives\/176.\">http:\/\/bougaidenpa.org\/masakazu\/archives\/176.<\/a>\u00a0Produtos da linha SEIL do provedor japon\u00eas IIJ tamb\u00e9m implementam o protocolo.<\/p>\n<p>A figura a seguir ilustra uma situa\u00e7\u00e3o t\u00edpica de uso do 4rd.<\/p>\n<p><a title=\"transicao-35\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-35.png\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-35\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-35-1024x460.png\" alt=\"\" width=\"491\" height=\"221\" \/><\/a><\/p>\n<p><strong>Figura 35: 4rd<\/strong><\/p>\n<p>\u00c9 importante considerar que o 4rd, al\u00e9m de distribuir IPs vers\u00e3o 4 compartilhados com A+P, pode tamb\u00e9m distribuir IPs v\u00e1lidos sem restri\u00e7\u00e3o de portas, para cada CPE, al\u00e9m de subredes IPv4.<\/p>\n<p>A figura abaixo representa a forma como os endere\u00e7os IPv4 e IPv6 s\u00e3o mapeados 1:1, para o caso em que os endere\u00e7os IPv4 s\u00e3o compartilhados com A+P. Perceba que o mapeamento \u00e9 stateless:<\/p>\n<p><a title=\"transicao-36\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-36.png\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-36\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-36-1024x233.png\" alt=\"\" width=\"491\" height=\"112\" \/><\/a><\/p>\n<p><strong>Figura 36: Tradu\u00e7\u00e3o de endere\u00e7os feita pelo 4rd<\/strong><\/p>\n<p>Para o mapeamento das portas, regras simples foram estabelecidas. As portas baixas, de 0 a 4096, nunca s\u00e3o designadas a um cliente. O tamanho do port-set-ID pode ir de 1 a 15 bits. Os clientes podem receber de 1 a 4 blocos diferentes de portas, de tamanhos variados, conforme o tamanho do port-set-ID. Os 16 bits de cada porta dispon\u00edvel s\u00e3o definidos da seguinte forma:<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>1o. bloco: \u00a0 0001 + port-set-ID (n=1 a 12 bits) + sufixo (que varia de 0 a 12-n)<\/li>\n<li>2o. bloco: \u00a0 001 + port-set-ID (n=1 a 13 bits) + sufixo (que varia de 0 a 13-n)<\/li>\n<li>3o. bloco: \u00a0 01 + port-set-ID (n=1 a 14 bits) + sufixo (que varia de 0 a 14-n)<\/li>\n<li>4o. bloco: \u00a0 1 + port-set-ID (n=1 a 15 bits) + sufixo (que varia de 0 a 15-n)<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>Note que se o port-set-ID tiver 15 bits, apenas um bloco estar\u00e1 dispon\u00edvel, se tiver 14 bits, 2 blocos, se tiver 13 bits, 3 blocos, e se tiver de 1 a 12 bits, 4 blocos de portas estar\u00e3o dispon\u00edveis.<\/p>\n<p>A tabela a seguir mostra a quantidade de CPEs poss\u00edvel para cada escolha, assim como a quantidade de portas dispon\u00edveis para cada uma, para um mesmo IPv4 compartilhado.<\/p>\n<table>\n<tbody>\n<tr>\n<td>tamanho doport set (bits)<\/td>\n<td>qtd de ID&#8217;s(CPEs)<\/td>\n<td>Head=00011o. bloco<\/td>\n<td>Head=0012o. bloco<\/td>\n<td>Head=013o. bloco<\/td>\n<td>Head=14o. bloco<\/td>\n<td>totalde portas<\/td>\n<td>portasn\u00e3o utilizadas<\/td>\n<\/tr>\n<tr>\n<td>1<\/td>\n<td>2<\/td>\n<td>2048<\/td>\n<td>4096<\/td>\n<td>8192<\/td>\n<td>16384<\/td>\n<td>30720<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>2<\/td>\n<td>4<\/td>\n<td>1024<\/td>\n<td>2048<\/td>\n<td>4096<\/td>\n<td>8192<\/td>\n<td>15360<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>3<\/td>\n<td>8<\/td>\n<td>512<\/td>\n<td>1024<\/td>\n<td>2048<\/td>\n<td>4096<\/td>\n<td>7680<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>4<\/td>\n<td>16<\/td>\n<td>256<\/td>\n<td>512<\/td>\n<td>1024<\/td>\n<td>2048<\/td>\n<td>3840<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>5<\/td>\n<td>32<\/td>\n<td>128<\/td>\n<td>256<\/td>\n<td>512<\/td>\n<td>1024<\/td>\n<td>1920<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>6<\/td>\n<td>64<\/td>\n<td>64<\/td>\n<td>128<\/td>\n<td>256<\/td>\n<td>512<\/td>\n<td>960<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>7<\/td>\n<td>128<\/td>\n<td>32<\/td>\n<td>64<\/td>\n<td>128<\/td>\n<td>256<\/td>\n<td>480<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>8<\/td>\n<td>256<\/td>\n<td>16<\/td>\n<td>32<\/td>\n<td>64<\/td>\n<td>128<\/td>\n<td>240<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>9<\/td>\n<td>512<\/td>\n<td>8<\/td>\n<td>16<\/td>\n<td>32<\/td>\n<td>64<\/td>\n<td>120<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>10<\/td>\n<td>1024<\/td>\n<td>4<\/td>\n<td>8<\/td>\n<td>16<\/td>\n<td>32<\/td>\n<td>60<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>11<\/td>\n<td>2048<\/td>\n<td>2<\/td>\n<td>4<\/td>\n<td>8<\/td>\n<td>16<\/td>\n<td>30<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>12<\/td>\n<td>4096<\/td>\n<td>1<\/td>\n<td>2<\/td>\n<td>4<\/td>\n<td>8<\/td>\n<td>15<\/td>\n<td>4096<\/td>\n<\/tr>\n<tr>\n<td>13<\/td>\n<td>8192<\/td>\n<td>&#8211;<\/td>\n<td>1<\/td>\n<td>2<\/td>\n<td>4<\/td>\n<td>7<\/td>\n<td>8192<\/td>\n<\/tr>\n<tr>\n<td>14<\/td>\n<td>16384<\/td>\n<td>&#8211;<\/td>\n<td>&#8211;<\/td>\n<td>1<\/td>\n<td>2<\/td>\n<td>3<\/td>\n<td>16384<\/td>\n<\/tr>\n<tr>\n<td>15<\/td>\n<td>32768<\/td>\n<td>&#8211;<\/td>\n<td>&#8211;<\/td>\n<td>&#8211;<\/td>\n<td>1<\/td>\n<td>1<\/td>\n<td>32768<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Figura 37: Modos de compartilhamento de portas<\/p>\n<p>A configura\u00e7\u00e3o dos CPEs pode ser feita manualmente, mas a proposta tamb\u00e9m define \u00a0uma op\u00e7\u00e3o de configura\u00e7\u00e3o via DHCPv6, que pode ser utilizada.<\/p>\n<p>Assim como as t\u00e9cnicas dIVI e dIVI-pd, a t\u00e9cnica 4rd tem caracter\u00edsticas praticamente ideais para uso por provedores de acesso, por isso seu desenvolvimento e padroniza\u00e7\u00e3o devem ser acompanhados com muita aten\u00e7\u00e3o:<\/p>\n<ul>\n<li>opera com base em redes somente IPv6, que \u00e9 para onde caminha a Internet;<\/li>\n<li>utiliza tradu\u00e7\u00f5es stateless, que s\u00e3o simples de implementar e baratas do ponto de vista computacional, permitindo boa escalabilidade;<\/li>\n<li>permitem conex\u00f5es em ambos os sentidos, mantendo a conectividade de fim a fim;<\/li>\n<li>quando necess\u00e1rio o uso de t\u00e9cnicas statefull, para restri\u00e7\u00e3o de portas e compartilhamento via NAT44, isso \u00e9 feito no lado do usu\u00e1rio, mantendo o princ\u00edpio de que a complexidade na Internet deve estar na extremidades e n\u00e3o pr\u00f3xima ao core da rede;<\/li>\n<\/ul>\n<p><a name=\"tecnicas-6pe\"><\/a><\/p>\n<h2>12. 6PE e 6VPE<\/h2>\n<table>\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Roteamento atrav\u00e9s de MPLS tem sido largamente utilizado nas redes dos grandes provedores de conectividade Internet. Entretanto, grande parte destes equipamentos j\u00e1 instalados n\u00e3o possuem suporte a IPv6. Dado o alto custo destes equipamentos, pode existir a necessidade de mant\u00ea-los em opera\u00e7\u00e3o. No intuito de resolver este problema pode-se utilizar as t\u00e9cnicas apresentadas neste t\u00f3pico.<\/p>\n<p>As t\u00e9cnicas em quest\u00e3o s\u00e3o o 6PE e o 6VPE, definidas, respectivamente, nas RFCs 4798 e 4659,\u00a0que permitem que redes IPv6 estabele\u00e7am a comunica\u00e7\u00e3o por meio de um core MPLS IPv4, usando LSPs (Label Switch Paths). Sua implementa\u00e7\u00e3o utiliza MBGP \u00a0(Multiprotocol BGP) sobre IPv4 para se trocar rotas IPv6 e necessita que os PEs (Rot. Borda) sejam Pilha Dupla. Atrav\u00e9s do MBGP os roteadores de borda recebem as rotas IPv6 mas aplicam MPLS IPv4 sobre os pacotes para realizar o roteamento. Quando o pacote chegar \u00e0 rede IPv6 de destino, o cabe\u00e7alho MPLS \u00e9 removido e o pacote \u00e9 encaminhado normalmente atrav\u00e9s do IPv6.<\/p>\n<p>A diferen\u00e7a entre o 6PE e o 6VPE \u00e9 que no primeiro caso, os roteadores mant\u00e9m apenas uma tabela global de roteamento, de forma que o 6PE \u00e9 mais indicado para provimento de conectividade Internet. J\u00e1 os roteadores 6VPE s\u00e3o capazes de manter v\u00e1rias tabelas de roteamento separadas logicamente, de forma que a t\u00e9cnica \u00e9 apropriada para prover servi\u00e7os de redes privadas (VPNs).<\/p>\n<p>A seguir o diagrama que explica o funcionamento do 6PE.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-38\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-38.png\" alt=\"\" width=\"421\" height=\"118\" \/><br \/>\n<strong><br \/>\nFigura 38: Topologia de rede 6PE<\/strong><\/p>\n<p><a name=\"tecnicas-6rd\"><\/a><\/p>\n<h2>13. 6rd<\/h2>\n<table>\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>O 6rd tem o objetivo de permitir ao usu\u00e1rio final ter conex\u00e3o com as redes IPv6 apesar da rede da operadora continuar funcionando em IPv4. Este tipo de t\u00e9cnica, assim como o 6PE\/6VPE, permite que os provedores utilizem a infraestrutura IPv4 j\u00e1 existente para fazer uma implanta\u00e7\u00e3o r\u00e1pida do IPv6.<\/p>\n<p>O 6rd (RFC5569) \u00e9 uma extens\u00e3o da t\u00e9cnica 6to4, que est\u00e1 em desuso e ser\u00e1 melhor explicada item seguinte. O 6rd resolve algumas das limita\u00e7\u00f5es t\u00e9cnicas do 6to4, como por exemplo sua assimetria e a falta de controle sobre os relays utilizados, permitindo sua utiliza\u00e7\u00e3o em larga escala.<\/p>\n<p>Para entender o funcionamento do 6rd pode-se observar a figura 39, que ilustra a topologia t\u00edpica de uso.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-39\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-39.png\" alt=\"\" width=\"471\" height=\"246\" \/><\/p>\n<p><strong>Figura 39: Topologia de rede 6rd<br \/>\n<\/strong><\/p>\n<p>Analisando a figura, \u00e9 poss\u00edvel notar que o 6rd depende basicamente de dois componentes:<\/p>\n<ul>\n<li>CPE 6rd:\u00a0instalado como interface entre a rede da operadora e do usu\u00e1rio;<\/li>\n<li>Relay 6rd:\u00a0instalado na interface entre a rede IPv4 da operadora e a Internet IPv6.<\/li>\n<\/ul>\n<p>O CPE 6rd \u00e9 um CPE tradicional (xDSL modem, cable modem, 3G modem etc), cujo software foi modificado para permitir o uso do 6rd. A necessidade dessa modifica\u00e7\u00e3o dificulta a implementa\u00e7\u00e3o da t\u00e9cnica, uma vez que requer a substitui\u00e7\u00e3o, l\u00f3gica ou f\u00edsica, de equipamentos em campo. Tal modifica\u00e7\u00e3o nos CPEs normalmente \u00e9 vi\u00e1vel nos casos em que o provedor gerencia remotamente o equipamento, sendo capaz de fazer upgrades em seu firmware.<\/p>\n<p>O 6rd relay \u00e9 um equipamento que vai encapsular e desencapsular pacotes para trafegarem corretamente nas redes IPv4 e IPv6.<\/p>\n<p>O CPE 6rd atribui ao usu\u00e1rio um endere\u00e7o IPv4, como um CPE normal. Entretanto um endere\u00e7o IPv6 tamb\u00e9m \u00e9 atribu\u00eddo ao usu\u00e1rio. Este endere\u00e7o IPv6 \u00e9 um endere\u00e7o IPv6 p\u00fablico v\u00e1lido, mas \u00e9 constru\u00eddo de maneira espec\u00edfica para que o relay 6rd identifique-o como um endere\u00e7o 6rd. O endere\u00e7o IPv6 atribu\u00eddo \u00e9 constitu\u00eddo da seguinte forma:<\/p>\n<p><a title=\"transicao-40\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-40.jpg\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-40\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-40-1024x204.jpg\" alt=\"\" width=\"491\" height=\"98\" \/><\/a><br \/>\n<strong><br \/>\nFigura 40: Tradu\u00e7\u00e3o de endere\u00e7o IPv4 para IPv6 no 6rd<\/strong><\/p>\n<p>No 6rd o tamanho n\u00a0do prefixo e o tamanho o\u00a0do endere\u00e7o IPv4, que formam o prefixo delegado 6rd, s\u00e3o escolhas do provedor de acesso. Para permitir que a autoconfigura\u00e7\u00e3o de endere\u00e7o stateless funcione \u00e9 necess\u00e1rio que o tamanho deste prefixo n\u00a0+ o\u00a0seja menor que 64 bits. O ID subrede de tamanho m\u00a0pode ser definido pela operadora, mas \u00e9 mais prov\u00e1vel que a operadora deixe a defini\u00e7\u00e3o do valor e tamanho do campo para o usu\u00e1rio final adequar \u00e0s necessidade de sua rede.<\/p>\n<p>Normalmente utiliza-se n=32, o=32 e m=0. Pode-se, contudo, aumentar o n\u00famero de bits utilizados por n\u00a0para al\u00e9m de 32, for\u00e7ando o endere\u00e7o IPv4 a utilizar parte dos 64 bits menos significativos, o que impede o funcionamento da autoconfigura\u00e7\u00e3o stateless. Para evitar que isto ocorra, o endere\u00e7o IPv4 pode ocupar menos de 32 bits. Tal configura\u00e7\u00e3o \u00e9 poss\u00edvel se os endere\u00e7os IPv4 fizerem parte de uma mesma rede, pois pode-se omitir o prefixo da mesma. Por exemplo, se todos os endere\u00e7os IPv4 forem da rede 198.51.0.0\/16, os 16 bits que representam os n\u00fameros 198 e 51 podem ser omitidos e a representa\u00e7\u00e3o do endere\u00e7o IPv4 necessitar\u00e1 somente de 16 bits, ao inv\u00e9s dos 32 bits necess\u00e1rios para representar o endere\u00e7o completo.<\/p>\n<p>O 6rd \u00e9 uma t\u00e9cnica funcional cuja a implementa\u00e7\u00e3o em massa foi testada com sucesso no provedor franc\u00eas Free. Entretanto, a t\u00e9cnica n\u00e3o tem sido adotada por outros, principalmente pela necessidade de atualiza\u00e7\u00e3o do software ou de substitui\u00e7\u00e3o dos CPEs.<\/p>\n<p>Para configurar o CPE e o roteador de borda com Linux \u00e9 necess\u00e1rio no m\u00ednimo o kernel m\u00ednimo 2.6.33 e as configura\u00e7\u00f5es para isto s\u00e3o:<\/p>\n<p>Roteador relay 6rd:<\/p>\n<div>ip tunnel add paraDentro mode sit local 203.0.113.1 ttl 64ip tunnel 6rd dev paraDentro 6rd-prefix 2001:db8::\/32<\/p>\n<p>ip link set paraDentro up<\/p>\n<p>ip -6 route add 2001:db8:cb00:7101::\/64 dev paraDentro<\/p>\n<p>ip -6 route add 2001:db8::\/32 dev paraDentro<\/p>\n<p>ip -6 route add 2000::\/3 dev eth1<\/p>\n<\/div>\n<p>Roteador CPE 6rd:<\/p>\n<div><code><\/code><code>ip -6 addr add 2001:db8:cb00:7182::\/64 dev eth0<\/code>ip tunnel add paraFora mode sit local 203.0.113.130 ttl 64<\/p>\n<p>ip tunnel 6rd dev paraFora 6rd-prefix 2001:db8::\/32<\/p>\n<p>ip link set paraFora up<\/p>\n<p>ip -6 addr add 2001:db8:cb00:7182::1\/128 dev paraFora<\/p>\n<p>ip -6 route add ::\/96 dev paraFora<\/p>\n<p>ip -6 route add 2000::\/3 via ::203.0.113.1<\/p>\n<p><code>Configurando o 6rd com equipamentos Cisco os comandos seriam:<\/code><\/p>\n<\/div>\n<p>Roteador relay 6rd:<\/p>\n<div>ipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0<br \/>\ninterface Loopback0<br \/>\nip address 203.0.113.1 255.255.255.0<br \/>\n!<br \/>\ninterface Tunnel0<br \/>\ntunnel source Loopback0<br \/>\ntunnel mode ipv6ip 6rd<br \/>\ntunnel 6rd ipv4 prefix-len 8<br \/>\ntunnel 6rd prefix 2001:db8::\/32<br \/>\nipv6 address DELEGATED_PREFIX::\/128 anycast<br \/>\n!<br \/>\nipv6 route 2001:db8::\/32 Tunnel0<br \/>\nipv6 route 2001:db8:cb00:7101::\/64 Null0<\/div>\n<p>Roteador CPE 6rd:<\/p>\n<div><code><br \/>\nipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0<br \/>\ninterface Dialer0<br \/>\nip address dhcp \u00a0! (203.0.113.130)<br \/>\n!<br \/>\ninterface Tunnel0<br \/>\ntunnel source Dialer0<br \/>\ntunnel mode ipv6ip 6rd<br \/>\ntunnel 6rd ipv4 prefix-len 8<br \/>\ntunnel 6rd prefix 2001:db8::\/32<br \/>\ntunnel 6rd br 203.0.113.1<br \/>\nipv6 address DELEGATED_PREFIX ::\/128 anycast<br \/>\n!<br \/>\ninterface Ethernet0<br \/>\nipv6 address DELEGATED_PREFIX ::\/64 eui-64<br \/>\n!<br \/>\nipv6 route 2001:db8::\/32 Tunnel0<br \/>\nipv6 route ::\/0 Tunnel0 \u00a02001:db8:cb00:7101::<br \/>\nipv6 route 2001:db8:cb00:7182::\/64 Null0<br \/>\n<\/code><\/div>\n<p>J\u00e1 para fazer esta configura\u00e7\u00e3o em roteadores Juniper \u00e9 poss\u00edvel encrontrar um exemplo em:<\/p>\n<p><a href=\"http:\/\/www.juniper.net\/us\/en\/local\/pdf\/implementation-guides\/8010078-en.pdf\">http:\/\/www.juniper.net\/us\/en\/local\/pdf\/implementation-guides\/8010078-en.pdf<\/a><\/p>\n<p>\u00c9 importante deixar claro que o 6rd n\u00e3o \u00e9 uma t\u00e9cnica para ser usada em novos usu\u00e1rios Internet, mas sim para os usu\u00e1rios j\u00e1 existentes, de forma a conseguir uma implanta\u00e7\u00e3o muito r\u00e1pida do IPv6. O 6rd funciona com base numa rede IPv4 e n\u00e3o resolve o problema da escassez de endere\u00e7os. T\u00e9cnicas escolhidas para novos usu\u00e1rios Internet devem preferencialmente basear-se em redes IPv6 e, quando necess\u00e1rio, preservar endere\u00e7os IPv4, compartilhando-os.<br \/>\n<a name=\"tecnicas-6to4\"><\/a><\/p>\n<h2>14. 6to4<\/h2>\n<table>\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>O 6to4 (RFC 3056) \u00e9 umas das t\u00e9cnicas de transi\u00e7\u00e3o mais antigas em uso e \u00e9 a t\u00e9cnica que inspirou a cria\u00e7\u00e3o do 6rd. Sua concep\u00e7\u00e3o era simples e muito interessante: com ajuda de relays pilha dupla distribu\u00eddos na Internet, abertos, instalado de forma colaborativa por diversas redes, qualquer rede IPv4 poderia obter conectividade IPv6, atrav\u00e9s de t\u00faneis 6in4 autom\u00e1ticos.<\/p>\n<p>Por meio do 6to4 qualquer computador com um IPv4 v\u00e1lido poderia funcionar como uma extremidade de um conjunto de t\u00faneis autom\u00e1ticos e prover todo um bloco IPv6 \/48 para ser distribu\u00eddo e usado em uma rede.<\/p>\n<p>A t\u00e9cnica funcionou parcialmente e ainda \u00e9 usada na Internet, mas apresenta diversos problemas. De fato, talvez tenha trazido mais problemas para a implanta\u00e7\u00e3o do IPv6 de forma geral, do que ajudado.<\/p>\n<p>O 6to4 \u00e9 composto dos seguintes elementos:<\/p>\n<ul>\n<li>Relay 6to4: roteador com suporte ao 6to4 e que possui conex\u00e3o nativa IPv4 e IPv6. Ele funciona como a extremidade dos t\u00faneis autom\u00e1ticos para os Roteadores 6to4 que precisam se comunicar com a Internet IPv6. Os relays 6to4 usam o endere\u00e7o anycast IPv4 192.88.99.1 e anunciam rotas para 2002::\/16 atrav\u00e9s deles, para a Internet.<\/li>\n<li>Roteador 6to4:\u00a0roteador que suporta 6to4 que fica na extremidade de uma rede IPv4 e \u00e9 respons\u00e1vel por trazer conectividade IPv6 para esta rede, por meio dos t\u00faneis 6to4. \u00a0No caso dos acessos \u00e0 Internet IPv6, ele direcionar\u00e1 o tr\u00e1fego at\u00e9 o Relay Router mais pr\u00f3ximo, que encaminhar\u00e1 o pacote ao seu destino. Para acesso a outras redes 6to4, os t\u00faneis s\u00e3o fechados diretamente com outros Roteadores 6to4.<\/li>\n<li>Cliente 6to4:\u00a0equipamento de rede ou computador que usa endere\u00e7os IPv6 fornecidos pelo t\u00fanel 6to4. O cliente 6to4 \u00e9 um cliente pilha dupla convencional, normalmente numa rede dom\u00e9stica ou corporativa, que pode usar IPv4 nativo ou compartilhado. O cliente n\u00e3o diferencia um endere\u00e7o IPv6 obtido via 6to4, de um endere\u00e7o IPv6 nativo.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>As fun\u00e7\u00f5es de Roteador e Cliente 6to4 podem estar presentes no mesmo equipamento. Um desktop convencional, por exemplo, usando Windows Vista, atua de forma autom\u00e1tica como Roteador 6to4, desde que tenha um endere\u00e7o IPv4 v\u00e1lido dispon\u00edvel.<\/p>\n<p>O endere\u00e7amento 6to4, conforme defini\u00e7\u00e3o da IANA, utiliza o prefixo de endere\u00e7o global 2002:wwxx:yyzz::\/48, onde wwxx:yyzz \u00e9 o endere\u00e7o IPv4 p\u00fablico do cliente convertido para hexadecimal. O exemplo a seguir mostra como fazer a convers\u00e3o de endere\u00e7os:<\/p>\n<p>Endere\u00e7o IPv4: 200.192.180.002.<\/p>\n<p>200=C8<br \/>\n192=C0<br \/>\n180=B4<br \/>\n002=02<br \/>\nCom isso, o bloco IPv6 correspondente, via 6to4, \u00e9 2002:C8C0:B402::\/48.<\/p>\n<p>A figura e tabela abaixo demonstram o fluxo dos pacotes em uma rede 6to4. \u00c9 importante notar que n\u00e3o existe a necessidade de os pacotes irem e voltarem pelo mesmo relay 6to4. As etapas 1, 3, 4 e 6 utilizam pacotes IPv6 e as etapas 2 e 5 utilizam pacotes IPv6 encapsulados em IPv4 atrav\u00e9s do protocolo 41.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-41-a\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-41-a.png\" alt=\"\" width=\"474\" height=\"146\" \/><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-41-b\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-41-b.png\" alt=\"\" width=\"464\" height=\"152\" \/><\/p>\n<p><small>1\u00a0De acordo com a tabela de roteamento, o pacote \u00e9 enviado atrav\u00e9s da rede local IPv6 para o roteador R1 utilizando a rota ::\/0;<\/small><\/p>\n<p>2\u00a0O pacote IPv6 \u00e9 recebido por R1 atrav\u00e9s da interface LAN, que verifica sua tabela de roteamento e descobre que deve enviar o pacote para a interface virtual 6to4 (rota para a rede 2002::\/16). Nesta interface o pacote IPv6 \u00e9 encapsulado em um pacote IPv4 (protocolo tipo 41) e enviado ao Relay RL1 ou RL2 (O Relay 6to4 pode ser definido manualmente no roteador 6to4 ou ent\u00e3o automaticamente atrav\u00e9s da utiliza\u00e7\u00e3o do endere\u00e7o anycast 192.88.99.1). Vamos supor que o pacote foi enviado para o Relay RL1;<\/p>\n<p>3\u00a0RL1 recebe o pacote 6to4 atrav\u00e9s de sua interface IPv4, v\u00ea que o pacote utiliza o protocolo 41 e o encaminha para a interface virtual. Esta desencapsula o pacote IPv6 e verifica na sua tabela de roteamento que deve envi\u00e1-lo pela interface LAN atrav\u00e9s do roteador R3, que simplesmente repassa o pacote IPv6 ao servidor S2;<\/p>\n<p>4\u00a0S2 responde com o envio de outro pacote IPv6 com destino ao Cliente C2 utilizando a sua rota padr\u00e3o, que aponta para o roteador R3. R3 recebe o pacote e, atrav\u00e9s da rota recebida via BGP, sabe que deve envi\u00e1-lo para o relay mais pr\u00f3ximo, que \u00e9 RL2;<\/p>\n<p>5\u00a0RL2 recebe o pacote IPv6 e verifica que o destino \u00e9 a rede 6to4 (2002::\/16). Deste modo, de acordo com sua tabela de roteamento, ele encaminha o pacote para a interface virtual 6to4, que o empacota em um pacote IPv4 (protocolo 41) e o envia ao endere\u00e7o IPv4 impl\u00edcito no endere\u00e7o IPv6 do destinat\u00e1rio do pacote;<\/p>\n<p><small>6\u00a0O roteador R1 recebe o pacote atrav\u00e9s de seu endere\u00e7o IPv4, verifica que o pacote est\u00e1 utilizando o protocolo 41 e o encaminha \u00e0 interface virtual 6to4. Esta o desencapsula e verifica o endere\u00e7o de destino. De acordo com sua tabela de roteamento e o endere\u00e7o de destino, o pacote IPv6 \u00e9 enviado atrav\u00e9s da sua interface LAN para o Cliente 6to4 C2.<\/small><\/p>\n<p><strong>Figura 41: Topologia e funcionamento do t\u00fanel 6to4<\/strong><\/p>\n<p>Dentre os problemas que afetam o 6to4, pode-se citar problemas de qualidade com relays p\u00fablicos e problemas de seguran\u00e7a. Alie-se a isso o fato de que diversos sistemas operacionais suportam t\u00faneis 6to4 de forma autom\u00e1tica, entre eles o Windows XP, o Windows Vista e o Windows 7. \u00a0O fato dos sistemas operacionais ativarem os t\u00faneis 6to4 sem interven\u00e7\u00e3o ou conhecimento dos usu\u00e1rios traz algumas consequ\u00eancias s\u00e9rias. Uma delas \u00e9 que firewalls ou outras medidas de seguran\u00e7a em redes corporativas podem ser inadvertidamente contornadas. Outra, \u00e9 que, via t\u00fanel, os pacotes podem seguir caminhos mais longos, trazendo uma experi\u00eancia pior para o usu\u00e1rio, em compara\u00e7\u00e3o \u00e0quela que ele teria se estivesse simplesmente usando IPv4. Um agravante \u00e9 que n\u00e3o h\u00e1 relays p\u00fablicos 6to4 no Brasil, ocasionando a ida do pacote para localidades distantes como Am\u00e9rica do Norte ou Europa, mesmo que a origem e o destino estejam no pa\u00eds.<\/p>\n<p>Provedores de conte\u00fados e servi\u00e7os na Internet podem sofrer com a quest\u00e3o, pois ao implantar o IPv6 em um servidor Web, por exemplo, usu\u00e1rios que antes acessavam-no bem via IPv4, podem passar a faz\u00ea-lo de forma lenta e inst\u00e1vel, via IPv6 obtido automaticamente por meio de um t\u00fanel autom\u00e1tico 6to4. Isso j\u00e1 foi motivo para adiamento da implanta\u00e7\u00e3o do IPv6, mas atualiza\u00e7\u00f5es dos sistemas operacionais t\u00eam mudado seu comportamento e o n\u00famero de usu\u00e1rios potencialmente afetados diminuiu para patamares muito pequenos e aceit\u00e1veis.<\/p>\n<p>Ainda assim, \u00e9 recomend\u00e1vel agir para mitigar esse problema, principalmente porque existe uma medida bastante simples e efetiva, que pode ser utilizada. Deve-se lembrar que o caminho de ida do 6to4 pode ser diferente do caminho de volta. Isto permite que um relay 6to4 seja criado em um servidor Web, ou em uma rede, com o objetivo de responder as requisi\u00e7\u00f5es recebidas via 6to4. O relay n\u00e3o deve ser p\u00fablico, apenas servir\u00e1 para responder \u00e0s requisi\u00e7\u00f5es dirigidas ao servi\u00e7o advindas de clientes 6to4. A implementa\u00e7\u00e3o deste relay n\u00e3o ir\u00e1 reduzir o tempo gasto para receber pacotes 6to4, mas garante que os pacotes 6to4 de resposta saiam da rede com destino ao originador da requisi\u00e7\u00e3o, j\u00e1 encapsulados em IPv4 e isto dar\u00e1 a vantagem do tempo de resposta ser consideravelmente reduzido, j\u00e1 que n\u00e3o ser\u00e1 necess\u00e1rio o pacote ir at\u00e9 o relay localizado no exterior. Esta redu\u00e7\u00e3o pode melhorar bastante a experi\u00eancia de acesso de um usu\u00e1rio que utilize 6to4 para acessar um servi\u00e7o qualquer.<\/p>\n<p>Para implementar este relay \u00e9 necess\u00e1rio que os roteadores de borda da rede permitam a sa\u00edda de pacotes com IP de origem 192.88.99.1. Provavelmente isto estar\u00e1 bloqueado por padr\u00e3o na rede j\u00e1 que este IP n\u00e3o faz parte do bloco a ela designado. \u00c9 preciso verificar tamb\u00e9m se o provedor de upstream n\u00e3o est\u00e1 filtrando tamb\u00e9m esse endere\u00e7o. Normalmente se a rede em quest\u00e3o for um AS, com bloco pr\u00f3prio, o upstream n\u00e3o ter\u00e1 filtros antispoofing. Caso contr\u00e1rio, ter\u00e1. Com a libera\u00e7\u00e3o do endere\u00e7o, basta configurar o pr\u00f3prio servidor Web, ou um outro elemento na rede, para fazer o encapsulamento das respostas usando 6to4. No Linux a configura\u00e7\u00e3o para isto \u00e9:<\/p>\n<div><code><\/code><code><br \/>\nip tunnel add tunel6to4 mode sit ttl 64 remote any local 192.88.99.1<\/code>ip link set dev tunel6to4 up<\/p>\n<p>ip addr add 192.88.99.1\/24 dev lo<\/p>\n<p>ip -6 addr add 2002:c058:6301::\/16 dev tunel6to4<\/p>\n<p>ip link set lo up<\/p>\n<p><code>\u00a0<\/code><\/p>\n<\/div>\n<p>Para redes corporativas, \u00e9 recomend\u00e1vel bloquear o protocolo 41 para evitar a utiliza\u00e7\u00e3o de t\u00faneis autom\u00e1ticos IPv4 pelos usu\u00e1rios. \u00c9 poss\u00edvel tamb\u00e9m desabilitar essa fun\u00e7\u00e3o no Windows. Para isso deve ser criada e configurada uma chave de registro, do tipo DWORD:<\/p>\n<div>HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\tcpip6\\Parameters\\DisabledComponents<\/div>\n<p>Ao fazer isso, a chave ser\u00e1 criada com o valor 0x00. O bit 1 (do menos significativo para o mais significativo) deve ser mudado para 1, para desabilitar o 6to4. Ou seja, o valor da chave deve passar a ser 0x01. A fun\u00e7\u00e3o de todos os bits \u00e9 descrita a seguir. Note que 0 \u00e9 o valor padr\u00e3o e significa que a fun\u00e7\u00e3o est\u00e1 ativa, 1 desativa a fun\u00e7\u00e3o:<\/p>\n<p>bit 0:\u00a0todos os t\u00faneis IPv6, incluindo ISATAP, 6to4 e Teredo;<br \/>\nbit 1:\u00a06to4<br \/>\nbit 2: ISATAP<br \/>\nbit 3:\u00a0Teredo<br \/>\nbit 4:\u00a0interfaces IPv6 reais<br \/>\nbit 5:\u00a0prefer\u00eancia por IPv4 e n\u00e3o IPv6<\/p>\n<p>O 6to4 \u00e9, ent\u00e3o, um protocolo com hist\u00f3rico importante, mas cujo uso deve ser evitado atualmente. Deve-se desativ\u00e1-lo em redes corporativas e bloque\u00e1-lo nos firewalls. Contudo, para redes pilha dupla que t\u00eam servi\u00e7os IPv6 p\u00fablicos na Internet, principalmente servidores Web, \u00e9 recomendada a instala\u00e7\u00e3o de um relay 6to4 para responder a solicita\u00e7\u00f5es de usu\u00e1rios externos usando essa tecnologia, mitigando parte dos problemas trazidos pela mesma.<br \/>\n<a name=\"tecnicas-teredo\"><\/a><\/p>\n<h2>15. Teredo<\/h2>\n<table>\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>A t\u00e9cnica de tunelamento autom\u00e1tica Teredo, criada pela Microsoft e definida na RFC 4380, permite que n\u00f3s localizados atr\u00e1s de Network Address Translations (NAT), obtenham conectividade IPv6 utilizando tunelamento em IPv4, usando o protocolo UDP.<\/p>\n<p>Sua utiliza\u00e7\u00e3o n\u00e3o \u00e9 recomendada, dado que n\u00e3o \u00e9 muito eficiente, tem alta taxa de falhas e algumas considera\u00e7\u00f5es de seguran\u00e7a. Contudo, \u00e9 importante conhec\u00ea-la bem, j\u00e1 que est\u00e1 implementada e \u00e9 utilizada de forma autom\u00e1tica em algumas vers\u00f5es do Windows. A utiliza\u00e7\u00e3o de t\u00faneis autom\u00e1ticos implica que, mesmo a rede n\u00e3o tendo IPv6 implantado, usu\u00e1rios podem ter endere\u00e7os IPv6 em seus dispositivos, inclusive com capacidade para receber conex\u00f5es entrantes, contornando mecanismos e regras de seguran\u00e7a existentes no ambiente.<\/p>\n<p>Existem dois elementos importantes no Teredo, o Servidor Teredo e o Relay Teredo. A conex\u00e3o \u00e9 realizada atrav\u00e9s de um Servidor Teredo, que a inicia ap\u00f3s determinar o tipo de NAT usado na rede do cliente. Em seguida, caso o n\u00f3 destino possua IPv6 nativo, um Relay Teredo \u00e9 utilizado para criar uma interface entre o cliente e o n\u00f3 destino. O Relay utilizado ser\u00e1 sempre o que estiver mais pr\u00f3ximo do n\u00f3 destino e n\u00e3o o mais pr\u00f3ximo do cliente.<\/p>\n<p>Os Servidores Teredo utilizam a porta UDP 3544\u00a0para comunicar-se com os dispositivos. Bloquear pacotes IPv4 enviados de uma rede para a Internet nessa porta e na dire\u00e7\u00e3o inversa, \u00e9 uma forma efetiva para evitar a utiliza\u00e7\u00e3o indesejada, muitas vezes involunt\u00e1ria, desse tipo de t\u00faneis.<\/p>\n<p>Por padr\u00e3o, os Windows 7 e Vista j\u00e1 trazem o Teredo instalado e ativado por padr\u00e3o, enquanto que no Windows XP, 2003 e 2008, ele vem apenas instalado. Quanto ao FreeBSD e ao Linux, ele n\u00e3o vem instalado. Caso seu uso seja desejado \u00e9 poss\u00edvel utilizar um software chamado miredo.<\/p>\n<p>Para iniciar o t\u00fanel, existe uma comunica\u00e7\u00e3o entre o cliente e o Servidor Teredo com a finalidade de identificar o tipo de NAT usado na rede. Para isso s\u00e3o usados dois IPs vers\u00e3o 4 no servidor. O Teredo \u00e9 capaz de funcionar com NAT do tipo Cone, tamb\u00e9m chamado de NAT Est\u00e1tico e NAT Cone Restrito, tamb\u00e9m chamado de NAT Din\u00e2mico, mas n\u00e3o funciona com NAT Sim\u00e9trico.\u00a0Foge ao escopo deste texto explicar o funcionamento de cada tipo de NAT.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-42\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-42.png\" alt=\"\" width=\"510\" height=\"263\" \/><br \/>\n<strong><br \/>\nFigura 42: Defini\u00e7\u00e3o do tipo de t\u00fanel Teredo<\/strong><\/p>\n<p>Uma vez identificado o tipo de NAT, o cliente constr\u00f3i seu endere\u00e7o IPv6, conforme a figura a seguir:<\/p>\n<p><a title=\"transicao-43\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-43.jpg\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-43\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-43-1024x140.jpg\" alt=\"\" width=\"491\" height=\"67\" \/><\/a><br \/>\n<strong><br \/>\nFigura 43: Tradu\u00e7\u00e3o de endere\u00e7o IPv4 para IPv6 no Teredo<br \/>\n<\/strong><\/p>\n<p>O prefixo \u00e9 sempre 2001:0000::\/32. As Flags servem para identificar o tipo de NAT.<\/p>\n<p>A figura a seguir representa o estabelecimento do t\u00fanel Teredo na situa\u00e7\u00e3o mais complexa poss\u00edvel, quando o cliente est\u00e1 numa rede com NAT Cone Restrito. Note que no estabelecimento do t\u00fanel, os primeiros pacotes fluem atrav\u00e9s do Servidor Teredo. Uma vez estabelecido o t\u00fanel, toda a comunica\u00e7\u00e3o \u00e9 feita atrav\u00e9s do Relay, bidirecionalmente.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-44\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-44.png\" alt=\"\" width=\"500\" height=\"142\" \/><\/p>\n<p><strong>Figura 44: Estabelecimento de t\u00fanel Teredo<\/strong><\/p>\n<p>Al\u00e9m de bloquear a porta UDP 3544, para evitar a cria\u00e7\u00e3o de t\u00faneis Teredo, estes podem ser desabilitados no pr\u00f3prio Windows. Para isso deve ser criada e configurada uma chave de registro, do tipo DWORD:<\/p>\n<p><code><br \/>\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\tcpip6\\Parameters\\DisabledComponents<br \/>\n<\/code><\/p>\n<p>Ao fazer isso, a chave ser\u00e1 criada com o valor 0x00. O bit 2 (do menos significativo para o mais significativo) deve ser mudado para 1, para desabilitar o Teredo. Ou seja, o valor da chave deve passar a ser 0x02. A fun\u00e7\u00e3o de todos os bits \u00e9 descrita a seguir. Note que 0 \u00e9 o valor padr\u00e3o e significa que a fun\u00e7\u00e3o est\u00e1 ativa, 1 desativa a fun\u00e7\u00e3o:<\/p>\n<p><strong>bit 0:<\/strong>\u00a0todos os t\u00faneis IPv6, incluindo ISATAP, 6to4 e Teredo;<br \/>\n<strong>bit 1:<\/strong>\u00a06to4<br \/>\n<strong>bit 2: <\/strong>ISATAP<br \/>\n<strong>bit 3:<\/strong>\u00a0Teredo<br \/>\n<strong>bit 4:<\/strong>\u00a0interfaces IPv6 reais<br \/>\n<strong>bit 5:<\/strong>\u00a0prefer\u00eancia por IPv4 e n\u00e3o IPv6<\/p>\n<p>Assim como o 6to4, o Teredo possui quest\u00f5es de seguran\u00e7a. Atrav\u00e9s do encapsulamento ele pode permitir que tr\u00e1fego que seria bloqueado em IPv4 consiga chegar ao destino. Ele vem instalado e habilitado por padr\u00e3o no Windows. Recomenda-se que seja desabilitado em redes corporativas<br \/>\n<a name=\"tecnicas-isatap\"><\/a><\/p>\n<h2>16. ISATAP<\/h2>\n<table>\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>Sim<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>ISATAP (sigla para Intra-Site Automatic Tunnel Addressing Protocol) \u00e9 uma t\u00e9cnica de tunelamento que liga dispositivos a roteadores. Sua utiliza\u00e7\u00e3o ocorre dentro das organiza\u00e7\u00f5es, pois n\u00e3o h\u00e1 um servi\u00e7o p\u00fablico de ISATAP. \u00c9 poss\u00edvel utilizar a t\u00e9cnica quando a organiza\u00e7\u00e3o tem IPv6 na extremidade de sua rede, fornecido por seu provedor, mas sua infraestrutura interna, ou parte dela, n\u00e3o suporta o protocolo.<\/p>\n<p>A figura abaixo demonstra o conceito do ISATAP.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-45\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-45.png\" alt=\"\" width=\"440\" height=\"184\" \/><\/p>\n<p><strong>Figura 45: Topologia de rede ISATAP<\/strong><\/p>\n<p>Esta t\u00e9cnica, definida na RFC 5214, \u00e9 baseada em t\u00faneis IPv6 criados automaticamente dentro da rede IPv4 e em endere\u00e7os IPv6 associados aos clientes de acordo com o prefixo especificado no roteador ISATAP e no IPv4 do cliente. Para a cria\u00e7\u00e3o destes t\u00faneis, s\u00e3o utilizadas as especifica\u00e7\u00f5es da se\u00e7\u00e3o 3 da RFC 4213, que trata do tunelamento atrav\u00e9s do protocolo IPv4 tipo 41 ou 6in4.<\/p>\n<p>Os endere\u00e7os IPv4 dos clientes e roteadores s\u00e3o utilizados como parte dos endere\u00e7os ISATAP, permitindo a um n\u00f3 determinar facilmente os pontos de entrada e sa\u00edda dos t\u00faneis IPv6, sem utilizar nenhum protocolo ou recurso auxiliar.<\/p>\n<p>O formato do endere\u00e7o ISATAP segue o seguinte padr\u00e3o:<\/p>\n<p><a title=\"transicao-46\" href=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-46.jpg\" rel=\"gallery-24\"><img loading=\"lazy\" decoding=\"async\" title=\"transicao-46\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-46-1024x138.jpg\" alt=\"\" width=\"491\" height=\"66\" \/><\/a><\/p>\n<p><strong>Figura 46: Tradu\u00e7\u00e3o de endere\u00e7o IPv4 para IPv6 no ISATAP<\/strong><\/p>\n<ul>\n<li>Prefixo unicast : \u00c9 qualquer prefixo unicast v\u00e1lido em IPv6, que pode ser link-local (FE80::\/64) ou global. Normalmente utiliza-se uma rede \/64 obtida a partir do prefixo global fornecido pelo provedor Internet para uso na rede.<\/li>\n<li>ID IPv4 p\u00fablico ou privado: Se o endere\u00e7o IPv4 for p\u00fablico, este campo deve ter o valor &#8220;200&#8221;. Se for privado (192.168.0.0\/16, 172.16.0.0\/12 e 10.0.0.0\/8), o valor do campo ser\u00e1 zero;<\/li>\n<li>ID ISATAP: Sempre tem o valor 5EFE;<\/li>\n<li>Endere\u00e7o IPv4: \u00c9 o IPv4 do cliente ou roteador em formato IPv4;<\/li>\n<\/ul>\n<p>O ISATAP \u00e9 suportado pela maior parte dos sistemas operacionais e roteadores e \u00e9 de f\u00e1cil implanta\u00e7\u00e3o.<br \/>\n<a name=\"tecnicas-ap\"><\/a><\/p>\n<h2>17. A+P<\/h2>\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Os mecanismos A+P e NAT444, que ser\u00e3o explicados a seguir, n\u00e3o ajudam diretamente na transi\u00e7\u00e3o de IPv4 para IPv6, mas t\u00eam sido usados na tentativa de prolongar a vida \u00fatil do IPv4.<\/p>\n<p>Esses mecanismos podem ser usados, contudo, em conjunto com a implanta\u00e7\u00e3o nativa do IPv6, a fim de garantir conectividade IPv4 para os usu\u00e1rios, numa Internet em transi\u00e7\u00e3o, onde muitos dos servi\u00e7os dispon\u00edveis ainda s\u00e3o somente IPv4.<\/p>\n<p>A t\u00e9cnica Address Plus Port (A+P), que significa endere\u00e7o mais porta, est\u00e1 definida na RFC 6346\u00a0e compartilha o mesmo endere\u00e7o p\u00fablico com mais de um usu\u00e1rio, simultaneamente. Para isto ser poss\u00edvel \u00e9 necess\u00e1ria uma limita\u00e7\u00e3o das portas que estar\u00e3o dispon\u00edveis para cada um. \u00c9 poss\u00edvel fazer a atribui\u00e7\u00e3o dos endere\u00e7os e portas para os diferentes usu\u00e1rios de forma stateless.<\/p>\n<p>O mesmo IPv4 v\u00e1lido \u00e9 compartilhado entre diversos usu\u00e1rios diferentes. \u00a0A CPE \u00e9 respons\u00e1vel por fazer um NAT na rede do usu\u00e1rio, de forma a atender os dispositivos nela presentes com IPs privados, da RFC 1918, e obedecer a restri\u00e7\u00e3o de portas ao fazer a tradu\u00e7\u00e3o. No caso da implanta\u00e7\u00e3o em redes com dispositivos m\u00f3veis, como smartphones, estes devem ser atualizados e estar cientes da restri\u00e7\u00e3o de portas.<\/p>\n<p>Esta t\u00e9cnica provavelmente n\u00e3o seria notada por usu\u00e1rios dom\u00e9sticos comuns, pois estes continuariam com IPs v\u00e1lidos e t\u00e9cnicas atuais como STUN ou uPnP para permitir conectividade fim a fim, em conjunto com o NAT na rede do usu\u00e1rio, continuariam funcionando.<\/p>\n<p>A restri\u00e7\u00e3o de portas n\u00e3o \u00e9, contudo, adequada para servi\u00e7os corporativos, pois n\u00e3o permitira o uso de servidores em portas padronizadas. O problema pode ser agravado se as portas forem atribu\u00eddas de forma din\u00e2mica.<\/p>\n<p>A figura abaixo demonstra o funcionamento do A+P.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-47\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-47.png\" alt=\"\" width=\"455\" height=\"333\" \/><br \/>\n<img loading=\"lazy\" decoding=\"async\" src=\"file:\/\/\/home\/tuany\/Downloads\/IPv6%20-%20Te%CC%81cnicas%20de%20Transic%CC%A7a%CC%83o%20-%20rev.2012.04.10-01\/images\/image45.png\" alt=\"\" width=\"455\" height=\"333\" \/><\/p>\n<p>Figura 47: Topologia de rede A+P<\/p>\n<p>Exemplos pr\u00e1ticos da utiliza\u00e7\u00e3o do A+P j\u00e1 foram dados, nos itens que trataram do DS-Lite com A+P, dIVI e dIVI-pd.<\/p>\n<p>A utiliza\u00e7\u00e3o de A+P, se poss\u00edvel, geralmente \u00e9 prefer\u00edvel \u00e0 utiliza\u00e7\u00e3o do NAT444, estudado no item seguinte. \u00c9 importante lembrar que a utiliza\u00e7\u00e3o dessas t\u00e9cnicas deve ser sempre acompanhada da implanta\u00e7\u00e3o do IPv6.<br \/>\n<a name=\"tecnicas-nat444\"><\/a><\/p>\n<h2>18. NAT444<\/h2>\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td>Cen\u00e1rio<\/td>\n<td>R6-I4<\/td>\n<td>I4-R6<\/td>\n<td>I6-R4<\/td>\n<td>R4-I6<\/td>\n<td>R6-R4<\/td>\n<td>R4-R6<\/td>\n<td>I6-I4<\/td>\n<td>I4-I6<\/td>\n<td>R6-I4-R6<\/td>\n<td>R4-I6-R4<\/td>\n<\/tr>\n<tr>\n<td>Suporta<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<td>N\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Assim como o A+P, o NAT444 tem sido usado na tentativa de prolongar a vida \u00fatil do IPv4 na Internet. Este mecanismo fere o princ\u00edpio de comunica\u00e7\u00e3o fim a fim da Internet e seu uso deve ser evitado ao m\u00e1ximo. Alternativas que levem as redes na dire\u00e7\u00e3o de redes somente IPv6 s\u00e3o prefer\u00edveis, assim como alternativas que usem m\u00e9todos stateless e que mantenham a complexidade nas extremidades da rede.<\/p>\n<p>Se usado, o NAT444 deve acompanhar a implanta\u00e7\u00e3o do IPv6 nativo para os usu\u00e1rios. N\u00e3o deve ser usado isoladamente.<\/p>\n<p>O NAT444 \u00e9 descrito no em draft-shirasaki-nat444-05\u00a0e tamb\u00e9m \u00e9 conhecido como LSN (Large Scale NAT) ou CGN (Carrier Grade NAT). Este mecanismo atribui um IPv4 privado para cada um dos usu\u00e1rios de um ISP, de forma semelhante ao que j\u00e1 \u00e9 normalmente feito em redes dom\u00e9sticas e em diversas redes corporativas. Ou seja, os usu\u00e1rios conviver\u00e3o, nesse caso, com duas camadas de NAT.<\/p>\n<p>A utiliza\u00e7\u00e3o desta t\u00e9cnica resolveria, de forma provis\u00f3ria, o problema da falta de endere\u00e7os IPv4, j\u00e1 que eles seriam largamente reutilizados, mas o custo seria comprometer as conex\u00f5es fim a fim e possivelmente a \u201cquebra\u201d de diversas aplica\u00e7\u00f5es hoje existentes.<\/p>\n<p>Pode-se argumentar que o NAT j\u00e1 \u00e9 usado normalmente e que n\u00e3o h\u00e1 preju\u00edzo na utiliza\u00e7\u00e3o da Internet por conta disso. Isso n\u00e3o \u00e9 verdade. O NAT, na rede dos usu\u00e1rios, por si s\u00f3, j\u00e1 \u00e9 prejudicial, embora tenha desempenhado um importante papel nos \u00faltimos anos para a conserva\u00e7\u00e3o dos endere\u00e7os IPv4 na Internet. T\u00e9cnicas como servidores STUN, uPnP e outras foram desenvolvidas para restaurar, parcialmente, a comunica\u00e7\u00e3o fim a fim perdida com uma camada apenas de NAT. Com o uso de NAT444 elas deixar\u00e3o de funcionar.<\/p>\n<p>Outro ponto a considerar \u00e9 que essa t\u00e9cnica \u00e9 cara, exigindo equipamentos com grande poder de processamento. Investimentos altos tendem a ser politicamente conservados dentro de grandes corpora\u00e7\u00f5es, o que pode levar a um atraso na ado\u00e7\u00e3o do IPv6.<\/p>\n<p>Um ponto a considerar, do ponto de vista estritamente t\u00e9cnico, \u00e9 a escolha do bloco de IPs a ser usado no NAT. Como o uso dos blocos da RFC1918 \u00e9 comum nas redes dos usu\u00e1rios, qualquer bloco escolhido dentre os dispon\u00edveis pelo provedor fatalmente colidir\u00e1 com o bloco de algum de seus clientes. Existe uma proposta em estudo para a reserva de um novo bloco, exclusivo para a utiliza\u00e7\u00e3o em situa\u00e7\u00f5es onde houver duplo NAT. O ARIN prontificou-se a ceder o bloco em quest\u00e3o e a proposta est\u00e1 sendo analisada pelo IETF: draft-weil-shared-transition-space-request-15.<\/p>\n<p>Devido ao rapido esgotamento do IPv4, podem existir situa\u00e7\u00f5es em que essa t\u00e9cnica ter\u00e1 de ser utilizada. Seu uso muitas vezes \u00e9 incentivado por fabricantes de equipamentos, talvez devido ao alto custo dos equipamentos necess\u00e1rios para sua implementa\u00e7\u00e3o.<\/p>\n<p>A figura abaixo exemplifica o funcionamento das redes hoje e como ficar\u00e1 o funcionamento da rede com a utiliza\u00e7\u00e3o do NAT444.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" title=\"transicao-48\" src=\"http:\/\/www.ipv6.br\/wordpress\/wp-content\/uploads\/2012\/05\/transicao-48.png\" alt=\"\" width=\"465\" height=\"218\" \/><\/p>\n<p><strong>Figura 48: Topologia de rede NAT444<\/strong><\/p>\n<p><a name=\"tecnicas-consideracoes\"><\/a><\/p>\n<h2>19. Considera\u00e7\u00f5es Finais<\/h2>\n<p>A utiliza\u00e7\u00e3o de pilha dupla IPv4 e IPv6 na Internet foi imaginada com a t\u00e9cnica padr\u00e3o para uma transi\u00e7\u00e3o sem solu\u00e7\u00e3o de continuidade na migra\u00e7\u00e3o para o IPv6. A pilha dupla parece ser, ainda hoje, a melhor escolha para provedores e redes corporativas, desde que n\u00e3o haja falta de endere\u00e7os IPv4 v\u00e1lidos e, consequentemente, for poss\u00edvel utiliz\u00e1-la.<\/p>\n<p>O r\u00e1pido esgotamento dos endere\u00e7os IPv4, a exist\u00eancia de equipamentos legados onde n\u00e3o \u00e9 poss\u00edvel utilizar IPv6 e a presen\u00e7a de equipamentos somente IPv6, por falta de IPs v4 livres, criaram a demanda por outras t\u00e9cnicas de transi\u00e7\u00e3o. As principais foram apresentadas ao longo deste texto.<\/p>\n<p>Deve-se considerar, ao escolher a t\u00e9cnica a ser usada em uma rede espec\u00edfica, que a Internet caminha para utilizar o IPv6. N\u00e3o h\u00e1 d\u00favida de que no futuro a Internet utilizar\u00e1 majoritariamente IPv6 e, possivelmente, somente IPv6. Aqueles que trabalham com redes h\u00e1 pelo menos pouco mais de uma d\u00e9cada viveram outras transi\u00e7\u00f5es similares, como por exemplo, quando, em redes corporativas era comum o uso de IPX\/SPX, Netbios, Appletalk e IP concomitantemente. A converg\u00eancia tecnol\u00f3gica \u00e9 um processo natural. Ela facilita o gerenciamento das redes, a interoperabilidade, o desenvolvimento de novas aplica\u00e7\u00f5es e servi\u00e7os, reduzindo custos, de forma geral.<\/p>\n<p>Com isso em mente, os provedores devem planejar-se para atender, daqui a pouco tempo, seus novos usu\u00e1rios exclusivamente com redes IPv6, de forma nativa. Devem oferecer paliativamente a eles um IPv4 v\u00e1lido, se houver dispon\u00edvel, ou compartilhado, se necess\u00e1rio. Isso deve ser feito enquanto houver uma quantidade relevante de dispositivos na Internet que n\u00e3o tenham implantado IPv6. Pode-se fazer isso com aux\u00edlio de t\u00e9cnicas de transi\u00e7\u00e3o baseadas em \u00a0t\u00faneis, ou tradu\u00e7\u00e3o, usando a rede que ser\u00e1 exclusivamente IPv6.<\/p>\n<p>H\u00e1 muitas t\u00e9cnicas dispon\u00edveis. Algumas delas j\u00e1 relativamente maduras e outras em processo de desenvolvimento e padroniza\u00e7\u00e3o. A IETF \u00e9 uma organiza\u00e7\u00e3o aberta, na qual colaboram provedores Internet, fabricantes de equipamentos, universidades e outros interessados. Ela tem sido muito \u00e1gil nesse processo, dada a urg\u00eancia criada pela necessidade. \u00c9 importante avaliar cuidadosamente, ent\u00e3o, se \u00e9 preciso investir agora em equipamentos que suportam uma determinada t\u00e9cnica, para serem usados daqui a um ou dois anos, ou se \u00e9 melhor esperar algum tempo at\u00e9 que tecnologias melhores e mais baratas, do ponto de vista financeiro e computacional, estejam mais maduras. N\u00e3o \u00e9 um problema para o qual se possa recomendar solu\u00e7\u00f5es em uma dire\u00e7\u00e3o, ou outra, genericamente. Cada operador ou usu\u00e1rio na Internet deve analisar sua situa\u00e7\u00e3o espec\u00edfica e escolher dentre as v\u00e1rias op\u00e7\u00f5es poss\u00edveis, a melhor para seu caso.<\/p>\n<p>Um dos pontos a considerar na escolha das t\u00e9cnicas de transi\u00e7\u00e3o a serem utilizadas \u00e9 se elas s\u00e3o stateless ou stateful. T\u00e9cnicas stateless s\u00e3o prefer\u00edveis, dado que escalam melhor e s\u00e3o mais baratas. Se necess\u00e1rio usar t\u00e9cnicas stateful, \u00e9 prefer\u00edvel que estejam implantadas nos equipamentos dos usu\u00e1rios e n\u00e3o no provedor.<\/p>\n<p>De forma geral, tanto as t\u00e9cnicas de tradu\u00e7\u00e3o quanto as de t\u00faneis for\u00e7am a redu\u00e7\u00e3o do MTU no escopo em que s\u00e3o usados na rede. Embora o presente texto n\u00e3o tenha abordado essa quest\u00e3o, todas elas apresentam mecanismos para contornar esse problema. Contudo, as t\u00e9cnicas baseadas em tradu\u00e7\u00e3o aparentemente oferecem alguma vantagem, pois n\u00e3o encapsulam o pacote novamente, apenas traduzem e trocam os cabe\u00e7alhos na camada IP, o que poderia ser interpretado, grosso modo, como um t\u00fanel com compacta\u00e7\u00e3o do cabe\u00e7alho.<\/p>\n<p>O NAT444 \u00e9 uma t\u00e9cnica a ser evitada. Seu uso n\u00e3o leva a rede do provedor em dire\u00e7\u00e3o ao IPv6, acarreta altos custos financeiros e dificuldades t\u00e9cnicas para os usu\u00e1rios da Internet. O NAT444 fere o princ\u00edpio da conex\u00e3o fim a fim, que foi essencial para o desenvolvimento da Internet nos moldes em que a conhecemos atualmente e \u00e9 uma das bases que a fazem ser um ambiente prop\u00edcio \u00e0 inova\u00e7\u00e3o, novas id\u00e9ias, aplica\u00e7\u00f5es, servi\u00e7os e neg\u00f3cios. O compartilhamento de IPs com restri\u00e7\u00e3o de portas (A+P) e NAT44 s\u00e3o solu\u00e7\u00f5es prefer\u00edveis, adotadas em conjunto com t\u00faneis ou dupla tradu\u00e7\u00e3o sobre redes nativas IPv6. NAT 64 em conjunto com DNS 64 e possivelmente ALGs tamb\u00e9m \u00e9 uma solu\u00e7\u00e3o prefer\u00edvel ao NAT444.<\/p>\n<p>Para redes corporativas j\u00e1 existentes, o caminho mais indicado hoje \u00e9 a implanta\u00e7\u00e3o do IPv6 de forma gradual, em pilha dupla. Isso deve ser feito de forma urgente nos servidores expostos na Internet, como os servidores Web e de emails e de forma paulatina para os usu\u00e1rios e outros servi\u00e7os. Ainda h\u00e1 problemas com aplica\u00e7\u00f5es utilizadas no dia a dia em rela\u00e7\u00e3o ao suporte ao IPv6, por isso redes somente IPv6 ainda n\u00e3o podem ser recomendadas de forma gen\u00e9rica. Essa situa\u00e7\u00e3o, no entanto, vem avan\u00e7ando rapidamente. \u00c9 poss\u00edvel vislumbrar, j\u00e1 hoje, situa\u00e7\u00f5es em que os benef\u00edcios trazidos pela facilidade de gerenciar uma rede com apenas um protocolo e endere\u00e7os suficientes para todos os dispositivos, sem a necessidade de tradu\u00e7\u00f5es, suplantem os problemas advindos da falta de suporte ao IPv6 em algumas aplica\u00e7\u00f5es. Pode ser que o futuro em que ser\u00e1 vantajoso para as redes corporativas trabalhar apenas com IPv6, com aux\u00edlio de t\u00e9cnicas de transi\u00e7\u00e3o para a comunica\u00e7\u00e3o com a Internet IPv4, n\u00e3o esteja muito distante.<\/p>\n<p>Finalmente, deve-se considerar que todas as formas de compartilhamento do IPv4 para usu\u00e1rios geram dificuldades no processo de sua identifica\u00e7\u00e3o \u00e0 partir de a\u00e7\u00f5es executadas na Internet, caso isso seja necess\u00e1rio. Hoje os provedores Internet normalmente guardam registros, logs, que associam, univocamente, um usu\u00e1rio a um IPv4, dentro de um determinado per\u00edodo de tempo. \u00c9 comum que em investiga\u00e7\u00f5es criminais esses logs sejam requisitados, por meio de ordens judiciais, que trazem como dados o IP do usu\u00e1rio e o momento de acesso a um determinado site ou servi\u00e7o na rede. Com o compartilhamento de IPs n\u00e3o haver\u00e1 apenas um usu\u00e1rio associado a um IP num dado momento, mas sim diversos. Podem ser alguns poucos, dezenas, ou mesmo centenas. Esse ser\u00e1 um problema tempor\u00e1rio, resolvido facilmente com a migra\u00e7\u00e3o dos principais servi\u00e7os na Internet, como portais de conte\u00fado, de com\u00e9rcio eletr\u00f4nico, servi\u00e7os banc\u00e1rios ou de governo, para IPv6. Paliativamente, no contexto do compartilhamento do IPv4, pode-se propiciar uma possibilidade melhor de identifica\u00e7\u00e3o, dependendo da t\u00e9cnica utilizada, se como informa\u00e7\u00e3o for obtido n\u00e3o apenas o IP, mas tamb\u00e9m a porta de origem, \u00e0 partir da qual a conex\u00e3o foi realizada. Dessa forma, para aqueles servi\u00e7os na Internet que hoje j\u00e1 guardam logs dos IPs de origem dos usu\u00e1rios, como bancos e servi\u00e7os de com\u00e9rcio eletr\u00f4nico, \u00e9 recomendado que passem tamb\u00e9m a guardar as portas de origem, al\u00e9m de implantarem de forma urgente o IPv6.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introdu\u00e7\u00e3o O IPv4 e o IPv6 n\u00e3o s\u00e3o diretamente compat\u00edveis entre si. O IPv6 n\u00e3o foi projetado para ser uma extens\u00e3o, ou complemento, do IPv4, mas sim, um substituto que resolve o problema do esgotamento de endere\u00e7os. Embora n\u00e3o interoperem, ambos os protocolos podem funcionar simultaneamente nos mesmos equipamentos e com base nisto a transi\u00e7\u00e3o [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1,68],"tags":[142,143],"class_list":["post-289","post","type-post","status-publish","format-standard","hentry","category-viazap","category-redes-2","tag-ipv4","tag-ipv6"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/289","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=289"}],"version-history":[{"count":2,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/289\/revisions"}],"predecessor-version":[{"id":291,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/289\/revisions\/291"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=289"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=289"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=289"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}