Quebro o silencio a que tem estado votado este blog para anunciar que, foi com muito gosto, que aceitei  realizar a terceira apresentação sobre IPv6 ao INETE, (Instituto de Educação Técnica,www.inete.pt).

A apresentação pode ser descarregada em:

http://.office.live.com/0.pdf

Peço P.F. e agradeço os comentários de todos o que assistiram esta apresentação, nos seguintes pontos:

1 - Interesse do tema (1 a 5):

2 - Conteúdo da apresentação (1a 5):

3 - Desempenho do orador ... (1 a 5):

4 - Comentários:

Nos vossos comentários podem, se o desejarem, usar "Nicks" de modo a manterem o anonimato, mas eles são muito importantes para melhorar uma próxima apresentação!

Muito Obrigado!

A apresentação de Dan Wing na Google IPv6 Implementors Conference  [1] sobre o NAT66 despertou-me a curiosidade sobre este mecanismo de tradução de endereços.

Se alguém me perguntasse até há bem pouco tempo atrás sobre o que pensava sobre a implementação de NAT em IPv6 (NAT66) essa pessoa assistiria provavelmente uma reacção quase furiosa. Admito que o meu “relacionamento” com o actual NAT não é nada bom…: Podem consultar um post anterior sobre o assunto. Se o NAT66 alguma vez vier a pretender replicar o que se faz actualmente em IPv4 não terei dúvidas em rejeita-lo frontalmente.

Mas o NAT em IPv6 de que fala Dan Wing e o IETF Draft de M. Wasserman e F. Baker [2] promete ter poucas semelhanças com o NAT44, pelo que, resolvi dar tréguas ao meu “preconceito” e dar o benefício da dúvida a este mecanismo em IPv6 tendo em conta a documentação produzida por estes senhores, e assim apresento um resumo daquilo que eu entendi sobre a proposta actual de funcionamento do NAT66:

1 - O que não pretende fazer:

- Partilhar endereços IP: Nem faz sentido em IPv6, cada máquina tem 64 bits reservados para definir o seu endereço.

- Usar ou alterar portos TCP ou UDP: Não interfere directamente com o L4 pois não existe alteração de portos (PAT), mas…

- Manter uma tabela de ligações por portos ou por máquina. É stateless: A alteração é algorítmica e é sempre a mesma para todos os pacotes: Apenas troca no IP de um prefixo “x” por um prefixo “y” ou “z”e vice-versa.

-Impedir uma ligação directa entre IPs endereços globais (internet) e endereços locais: Não existe interferência na conectividade global “end-to-end”, uma máquina numa rede local está tão directamente contactável do exterior como numa rede IPv6 sem NAT66, mas alguns poderão assumir que o NAT66 fornece a mesma falsa protecção do NAT44. A segurança (em IPv4 ou IPv6) deverá ser assegurada implementando e configurando de forma adequada firewalls,  SOs e aplicações e a não assentar em princípios de “obscuridade” da rede local.

2 - Como funciona:

Exemplo:

              Rede Global: 2A01:666:C73E:/48

              ----------------------------------

                               |

                           ---------

                         |  NAT66  |

                           ---------

                               |

             --------------------------------

               Rede Local: FD01:A33:FACE:/48

No sentido Rede Local --> Rede Global o endereço de origem é reescrito com a troca o prefixo do FD01:A33:FACE:/48 pelo 2A01:666:C73E:/48. No sentido Rede Global --> Rede Local a troca de prefixo é inversa, mas agora no endereço de destino.

Outro cenário interessante:

      Rede Global #1             Rede Global #2

   2001:A:BES7:1/48              2A01:666:C73E:/48

   ------------------------     -------------------------

                 |                         |

            +---------+                +---------+

             NAT66#1                     NAT66#2 

            +---------+                +---------+

                  |                         |

            --------------------------------------

Rede Local:                                       FD01:A33:FACE:/48

Neste cenário poderemos estar a usar dois operadores em simultâneo (para diferentes serviços, ou como securização) ou a fazer load balancing(?). [2]

3 – Argumentos para implementar:

- IPv6 Provider Independent (PI) addresses. Independência do endereçamento IP (e das todas as configurações a ele associadas: ACLs, LOGs, etc) de uma rede face ao endereçamento do ISP (endereçamento global).

- Facilita o multihoming: Existem falhas no suporte ao SAS \ DAS (Source \ Destination Address Selection): Este mecanismo pode alterar o prefixo em função do destino ou ISP que se pretende usar.  Alguns equipamentos não lidam muito bem com vários prefixos na mesma interface, podendo enviar pacotes com um prefixo inválido para um ISP (o que levará à perda do pacote nas regras de segurança do ISP) ou ao regresso do pacote por caminho diferente daquele que foi usado no envio (levando ao eventuais problemas de segurança, jitter, perdas de pacotes, etc.)

- Facilita a resolução de problemas relacionados com “Split-Zone DNS” e aceitação de “Next-hop route selection”

4- Problemas:

- Interfere indirectamente com os mecanismos de correcção de erros do L4. Não existe checksum no cabeçalho IPv6, mas a alteração dos endereços (prefixos) implica a existência de uns mecanismos de acerto do endereço nos últimos 16 bits (49 a 64) dos prefixos, de modo a que o checksum do pacote IP no L4 não seja alterado.

- O ponto anterior implica que o ISP terá de fornecer uma rede \48 ou maior … o que de certo modo significa desperdiçar 16 bits no uso deste mecanismo, bem como reservar para este uso os mesmos 16bits no endereçamento na rede local.

- A alteração do prefixo interfere com o cabeçalho do IP (manipulado pelo AH no IPSec) pelo que pode impedir a encriptação “end-to-end” assim como interfere com aplicações que transportem informação sobre o IP (obrigando ao uso de ALGs).

- Incompatibilidades como o HIP (Host Identity Protocol): Protocolo que pretende atribuir um endereço único global seguro, e que pode ter um importante papel na mobilidade IP ao permitir que o L4 (transporte TCP ou UDP) se abstraia do endereço L3 (IP) (fica entre estas duas camadas). [3]

- Aumento da complexidade de configuração.

5 – Conclusões

O NAT mesmo na sua versão simplificada em IPv6 introduz complexidade, desperdício de endereçamento, incompatibilidades, limitações e ainda penso que ainda existe o risco de uma provável tendência para os saudosistas tentarem implementar um NAT à imagem do que se faz em IPv4. Como diz Dan Wing temos de evitar usar NAT66, mas se não forem introduzidos melhorias em alguns aspectos do IPv6 o seu uso poderá vir a ser necessário

Por aquilo que entendi considero que o NAT66 não é nem uma solução isenta de problemas complexos, nem uma aberração que pretente deturpar os principos da conectividade em IPv6. O seu uso deveria ser evitado, mas se resolver muitos mais problemas do que aqueles que vai criar…talvez possa ser considerado tolerável e exequível em situações pontuais, até porque a limitação do ISP ter de fornecer pelo menos um prefixo \48 vai certamente limitar muito o seu uso.

Fontes

[1] Conferencia Google

- PDF (slides): ipv6implementors/03_Wing_avoiding-nat66.pdf

- Video: http://www.youtube.com

[2] Draft IETF: http://tools.ietf.org/html/draft-mrw-behave-nat66-02

[3] Trabalho de Zhangyi Yuan sobre NAT66: http://www.asiafi.net/meeting/2010/winterschool/asiafi-papers/afiwinter2010_Zhangyi_Yuan.pdf

Resolvi fazer um pequeno "post" sobre o NAT depois de ler um comentário de alguém que perguntava num blog algo do género: Como vai ser garantida a segurança em IPv6  sem  ter um  NAT disponível, sem poder "esconder" as maquinas da rede local?

Actualmente grande maioria dos ataques em redes IP usa como veículos as nossas aplicações, sistemas operativos e sobretudo a nossa ingenuidade ou ganância e não nas camadas 3 e 4  do modelo OSI onde o NAT vs PAT actuam, pelo que a suas funções protectoras (?) por esta via já não são minimamente eficientes.

E embora também seja possível impedir o acesso directo de um dispositivo à internet em IPv6, o NAT não é um desses mecanismos pois não existe no novo protocolo IP, mas entenda-se: A segurança IP baseada na "obscuridade" proporcionada pelo NAT não é muito eficaz (a menos que também desliguem o cabo Ethernet…), para além disso, outra face da mesma moeda, essa  obscuridade impede uma ligação eficiente e universal entre servidores e clientes, se é que ainda faz sentido fazer este tipo de classificação, pois qualquer um de nós, navegadores do ciber espaço... pode e provavelmente quer ser, um potencial servidor informação na internet (páginas pessoais, ficheiros de vídeo, texto, áudio, fotos, etc.). A internet apenas como um conceito de consumo passivo, como ainda é a rádio e a televisão (embora existam novidades que tendem a mudar este paradigma) está ultrapassado.

Mas o NAT e os IP´s globais (vulgo públicos) dinâmicos… impedem a aplicação universal de um conceito (que não é de todo meu!) de que todos podemos ser simultaneamente servidores e clientes de informação na internet sem recorrer à intermediação de servidores de terceiros, informação que pode estar suportada em qualquer dos nossos terminais; PCs, PDAs, TVs, consolas de jogos, torradeiras…

O NAT promove os erros de configuração, aumenta a complexidade e o tempo de despiste de avarias, impede a fácil implementação de  encriptação "end-to-end” e de VPNs, aumenta o processamento dos equipamentos envolvidos e o RTD (“o ping”), dificulta o funcionamento das aplicações, aumenta o consumo de energia (pela necessidade de "acordar" os equipamentos para fazer pollings que mantenham as entradas nas tabelas de NAT activas), etc., etc..

O NAT é um problema provocado pela ânsia de tentar resolver a escassez de IP sem ter implementar IPv6, mas não resolveu isso definitivamente… apenas adiou um problema criando outro! Nesta data (15 de Abril de 2010) existe apenas 7% do endereçamento IPv4 originalmente disponível na IANA e infelizmente o adiamento do problema não foi aproveitado para implementar IPv6 e o NAT passou ser um infeliz mecanismo que é agora quase um característica indissociável do próprio IPv4, tanto que alguns tem dificuldade em imaginar um IP sem ele!

Mas não se enganem: O NAT já não é uma solução, é um problema!

Vejam este video sobre uma aplicação práctica sobre  IPv6 impossivel de conseguir em IPv4 devido ao NAT (especialmente depois minuto 3,5):

Foi com todo o gosto que aceitei fazer mais uma apresentação sobre IPv6 ao INETE (Instituto de Educação Técnica,www.inete.pt)

A apresentação pode ser descarregada em:

http://cid-adcecbf51712bc66.skydrive.live.com/browse.aspx/IPv6/Apresenta%C3%A7%C3%B5es%20INETE

Agradeço os vossos comentários \ classificação neste "post" sobre esta apresentação:

1 - Interesse do tema (1 a 5):

2 - Conteúdo da apresentação (1a 5):

3 - Desempenho do orador ... (1 a 5):

4 - Comentários:

Os vossos comentários (podem usar "Nicks" para manter o anonimato) são muito importantes para melhorar a próxima apresentação! Obrigado!

Se repararem no contador da iNetCore (existe um link na página deste blog) apenas restam (não atribuído) 8% do endereçamento IPv4. O “nervoso miudinho” está a instalar-se dada a perspectiva de falta de IPv4 para o suporte dos produtos de telecomunicações e até os que andaram até há bem pouco tempo “a dormitar“ perguntam a agora como foi possível ninguém os ter acordado mais cedo… acusando os que fizeram alguma coisa de terem andado distraídos!

Também existe quem ainda procure uma justificação para implementar IPv6! Como se o IPv6 fosse, só por si, vendável como produto. Informação para quem ande muito distraído: É apenas um mais protocolo. Mas não é apenas “masturbação tecnológica” (esta frase não é minha e têm direitos de autor…), embora compreenda a necessidade de tentar justificar o investimento com uma perspectiva de retorno do mesmo, o IPv6 pode, se o estudarem bem, ser um veículo de inovação e uma “máquina de fazer dinheiro" ! Mas também vai alterar alguns modelos de negócio...

O acesso internet não surgiu antes de existirem todos os serviços que agora assumimos como indispensáveis? O 3G (e com licenças bem caras) não teve sucesso só depois de desenvolvido o HSPA? (não foi pelas apregoadas  vídeo chamadas!).

Se o IPv6 for implementado “em pânico” e apenas à semelhança do conhecimento existente sobre IPv4 apenas vai tentar resolver o problema da falta de endereçamento IP e nesse cenário muito dificilmente conceitos ou produtos inovadores poderão nos próximos anos vir a sustentar-se no IPv6.

Por outro lado temos exemplo da Free em França: Não se limitou a constatar dificuldades. Foi pioneira, criou as suas próprias soluções (ajudou a desenvolver a sua solução de "Home Gateway" e alguns conceitos). Não se limitou esperar pela incorporação de tecnologia “pré-cozinhada” de parceiros (que tarda em aparecer). As suas soluções, já com dois anos de experiência, estão a transformar-se em soluções padrão (o 6rd no RFC 5569) para os outros operadores de bem maiores dimensões e com muitos mais recursos! Consequências: Obteve o reconhecimento tecnológico (de clientes, de parceiros e até concorrentes), conquistou de nichos de mercado e uma projecção mundial muitas vezes superior ao seu real peso no mercado de telecomunicações, embora já conte com 4,5 milhões de clientes, 24% do mercado ADSL em França e um 25% aumento das receitas em 2009 (http://www.iliad.fr/en/) . Um exemplo para todos nós.

O 6Rd não é uma solução que me agrade a 100%, continuo a acreditar que  seria preferível e possível implementar Dual Stack (talvez associado ao aparentemente inevitável e muito abominável NAT444), mas pode ser uma solução para quem ainda tem um core longe de ser “IPv6 ready”, sofre com a persistente inexistência de equipamento residencial (“home gateways”) com suporte IPv6  mas está disponivel para  avançar com soluções próprias (implica investimento em "Border Gateways 6rd!).

Ainda sobre o IPv6 Fixo ,uma ideia fixa minha… da Free e de muitos outros. 

A 7 Maio de 2009 perguntei por email à Free: “And I have a doubt: Do you provide static or dynamic IPv6 to our clients in our basic DSL internet service?”

No dia seguinte e sem me conhecer, Alexandre C. respondeu-me: “Every customer is hosting our CPE, on the CPE we are running opensource radvd daemon. This radvd then is assigning IPv6 address. So for the same MAC address IPv6 will be the same each time. On the other hand we are providing a subnet range to our customer so that he can use whatever he want in here.”

www.free.fr/adsl/pages/internet/connexion/adresse-ip-fixe.html#/adresse-ip-en-protocole-ipv6

A generosidade é outra marca que distingue quem estando num patamar mais elevado, não teme partilhar informação, pois sabe que o caminho da inovação não tem muitos atalhos. Mas reparem: Optaram pelo IPv6 fixo! Eu penso que isso vai fazer toda a diferença! Os consumidores não devem aceitar nada menos , seria uma verdadeiro  salto "quântico" nas  possibilidades de conectividade IP para particulares e empresas.

O conceito de “quasi fix” (prefixo para a LAN fixo mas um prefixo WAN ocasionalmente variável) do piloto da Magyar Telekom também serve (muito bem):

“The IPv6 address is allocated by the provider in a quasi fixed way to the device initiating the IPv6 PPPoE connectivity. This means that the IPv6 address is planned to remain unchanged for the duration of the pilot period.” http://www.telekom.hu/ipv6_networks/about_the_ipv6_pilot/information

O Antonio Moreiras (entre outros) da nic.br (http://www.ipv6.br/)

(equivalente à nossa FCCN no Brasil) também me respondeu à hipótese em dar IPv6 dinâmico: “Pessoalmente acho descabida, mesmo absurda, a possibilidade que você levantou. Há algum exemplo assim em ISPs portugueses?”  Não respondi... mas autorizou-me a cita-lo e remeteu-me para o link: http://www.ipv6.br/IPV6/MenuIPV6FAQ#O_que_eu_ganho_com_o_IPv6

Fica o recado!

P.S. Deixo aqui um link para poderem descarregar um pequeno documento meu sobre o funcionamento do 6rd e do NAT444:

http://cid-adcecbf51712bc66.skydrive.live.com/browse.aspx/IPv6/6rd

 Respondendo à questão do H.  Ferreira  do INETE enviada para o email ipv6@sapo.pt:

Quais são as técnicas de transição usadas e vantagens e desvantagens das mesmas ?

Existem  muitos mecanismos de transição,  deixo apenas algumas notas sobre  aqueles que já experimentei:

- Dual Stack - O desejável, com desempenho semelhante ao IPv4, mas infelizmente não está ao alcance de todos pois depende primeiramente da capacidade IPv6 do ISP e dos equipamentos de rede usados.

- 6to4 -"Túnel inteligente" bastante rápido, o meu 2º preferido e o que uso habitualmente, eficiente, principalmente se for aplicado num router, embora também possa terminar num PC(descobri isso há pouco tempo…): mas tem de estar instalado numa interface com IP publico IPv4.

- Túnel manual - Eficiente mas de aplicação muito limitada, pode servir para interligar pontos IPv6 através de redes IPv4.

- Teredo - Instável (na minha experiencia), mais lento que os anteriores e não funciona com todos tipos de NAT, pelo que pode não ser possível usa-lo em todas as redes.

- Tunnel Broker - Fácil de usar, mas é necessário instalar uma aplicação e é pouco eficiente: lento (elevado RTD) e muita pouca LB disponível (depende do servidor usado).

- NAT-PT (Este não experimentei), consiste na tradução directa de endereçamento IPv4 em IPv6 e vice-versa: Penso que dever ser evitado e usado como ultimo recurso!)   

Espero ter ajudado a responder à pergunta do H. Ferreira, se alguém tiver uma experiência diferente, agradeço os seus comentários neste blog.   

P.S. Fiz alguns testes com alguns destes túneis no âmbito de um projecto do ISEL, o relatório contem mais pormenores  e uma tabela comparativa,  pode ser descarregado em:cid-adcecbf51712bc66.skydrive.live.com/browse.aspx/IPv6

É com todo o gosto que aceitei fazer uma apresentação sobre IPv6 para o INETE (Instituto de Educação Técnica,www.inete.pt) no próximo dia 11 de Março

A  apresentação (versão 3) pode ser descarregada em: cid-adcecbf51712bc66.skydrive.live.com/browse.aspx/IPv6

Podem também colocar duvidas pelo email: ipv6@sapo.pt

Como tinha indicado no último post é possível acrescentar servidores DNS em IPv6 ao XP (SP3) recorrendo ao CLI do DOS (consultar o comando no ultimo post), pois este SO não reconheceu o DHCPv6 do meu router (o Windows 7 reconheceu), e correndo o clássico comando ipconfig/all obtêm-se algo do género:  

Mas no suporte ao IPv6 nem tudo o que parece é!

Alertado por alguns dos meus contactos decidi, confirmar se de facto o XP faria queries a servidores DNS em IPv6. 

Assim garantindo que nenhum DNS em IPv4 estivesse presente na configuração do PC, constatei que o Windows XP pura e simplesmente não faz nenhum pedido de resolução de nome! Nem tenta! (monitorizei com um sniffer), o que bate certo com o facto do nslookup não reconhecer nenhum servidor (na falta de um em IPv4).

Ou seja: Existe o comando; O comando é reconhecido; Surge na configuração da interface do PC; Mas não serve para nada porque o SO não o usa!

Um eng.º de uma instituição ligada a "estas coisas", afirma que, isto não é muito importante, dado que a transição para o IPv6 deverá ser acautelada em "dual stack" e portanto a querie poderá ser feita a um servidor DNS em IPv4, que dará resposta sobre a tradução de um nome em IPv6 (AAAA)...como já aconteçe. Concordo plenamente.

Mas isto implica que a transição tem de ser efectuada atempadamente. Antes que acabar o endereço IPv4 publico disponivel, ou a consulta ao servidor DNS terá de ser desencadeada com um endeço privado... até que estes e  outros "bugs", muitos estranhos, sejam resolvidos.   

P.S. O Windows7 (tal como o Vista) parece poder fazer queries em DNS em IPv6, mas infelizmente os servidores que experimentei ( o 2001:8a0:10:201::2 e o 2001:690:2200:9a01::9) não responderam à querie... Apesar de confirmar que os servidores estão "vivos" fazendo um telnet ao porto 53:

Este fim-de-semana resolvi testar o Windows7 (a ultima versão beta). É claro que um dos pontos que mais me interessava era perceber se existiriam evoluções no suporte IPv6 relativamente ao XP (penso que muitos utilizadores do XP irão passar  para este SO sem passar pelo mal amado Vista). De facto existem evoluções no suporte IPv6 (mas que já estavam disponíveis no Vista), tais como:

- Suporte GUI para configuração dos parâmetros IPv6 das interfaces de rede (no XP é tudo via NDP ou CLI no DOS): IPv6, n.º Bits do prefixo, gateway, DNS…

- Este SO reconheceu o servidor DHCPv6 a correr no meu router (permitindo receber o IP de um DNS IPv6, como o 2001:8a0:10:201::2). O XP não o reconheceu, assim só é possível acrescentar-lhe um DNS IPv6 manualmente, no DOS. Exemplo:

netsh interface ipv6 add dns "Local Area Connection" 2001:8A0:10:201::2 

Nota: "Local Area Connection" corresponde ao nome da interface Eth, mas pode ser outro

No entanto é decepcionante perceber que aplicações como o Remote Desktop ou o Map Network Drive ainda não suportam IPv6!*

Já no telnet e no Hyper Terminal o problema não se coloca., pois a MS retirou estas aplicações do SO ...,mas existem outras soluções.

Lembro que foi testada (confesso que superficialmente) apenas uma versão beta do Windows 7, espero que até ao seu lançamento estas lacunas chegam corrigidas, pois este será, muito provavelmente, o SO mais usado quando a necessidade de transição para o IPv6 for inevitável.     

Estas  lacunas vem reforçar a percepção que tenho: O efectivo total suporte ao IPv6 está muito atrasado. Os fornecedores de hardware, software e ISP´s terão muito, muito trabalho até poderem fornecer soluções sem limitações (e seguras!) que nos possam permitir prescindir do endereçamento IPv4 e lançar inovadoras soluções sobre IPv6. E esse objectivo não será facilmente atingido até 2011 recorrendo a engenheiros a trabalhar em IPv6 em “part-time”. Espero que o anúncio da “morte” do IPv4 esteja a ser muito exagerado…  

*NOTA: Ver comentários a este post...    

Não tive infelizmente reacções a eventuais resultados com o túnel Teredo. Mas posso assegurar que será bem mais gratificante a experiência de acesso ao mundo IPv6 com um túnel 6to4.

Infelizmente só poderei ajudar com a minha experiência quem tiver a sorte de também ter um router de acesso à Internet da Cisco e de preferência  que tenha como ISP um cujo endereço IPv4 anycast (192.88.99.1) aponte para um relay router da FCCN, o que poderá ser facilmente comprovado com um simples traceroute:

 1     8 ms     2 ms     2 ms 10.99.99.1

 2     *        *        *     Request timed out.

 3    12 ms     9 ms     9 ms dial-b1-174-62.telepac.pt [194.65.174.62]

 4    11 ms     9 ms     9 ms te-1-1.lcatrt1.telepac.net [213.13.135.174]

 5    12 ms    14 ms     9 ms FCCN.AS1930.gigapix.pt [193.136.250.10]

 6    11 ms    10 ms     9 ms 192.88.99.1

Segue link para o documento sobre os pormenores de implementação deste túnel:  cid-adcecbf51712bc66.skydrive.live.com/browse.aspx/IPv6

Fico a aguardar pelos vossos comentários...

Só agora testei o Teredo, e foi mais fácil do que pensava.

Para quem não souber, trata.-se de uma engenhosa   forma (mas com alguns perigos) de se ter acesso IPv6 com um tunel disponivel  no Windows.

Assim aconselho a todos que tenham o mínimo de curiosidade sobre o IPv6 da experimentar os seguintes comandos na consola de comandos DOS (em Windows XP):

I - Instalar o IPv6: >netsh int ipv6 install

 >netsh int ipv6 set teredo client teredo.autotrans.consulintel.com

"State"  terá de se apresentar como: “qualified” 

ping ipv6.google.com
ping ipv6.whatismyv6.com

Se ainda não conseguirem navegar em Sites IPv6 consultem o meu post: “Alteração da "Prefix Policy" 

Para mais informação consultar o meu documento sobre o assunto em:

 cid-adcecbf51712bc66.skydrive.live.com/browse.aspx/IPv6

Fico a aguardar os vossos comentários sobre as vossas experiências !

[jalmeida.broker.freenet6.net]/xmascard1201c.jpg

P.S.

É suposto surgir em cima uma  imagem de um postal de Natal antigo, mas só para quem tiver acesso global IPv6 !

Isto é, se o meu "servidor" web estiver ligado...

Bem-Vindos ao meu site em IPv6! 

[jalmeida.broker.freenet6.net]/Router AcessoNet.doc
(configuração parcial do meu router ADSL Cisco para 
um tunel IPv6 6to4)

Se já tiverem acesso a IPV6 podem constatar que consegui fazer correr o apache em Windows XP no link indicado. Um pequeno passo para o IPv6... mas uma tarefa nada fácil de alcançar para mim (consultar o ultimo post).

Seguem-se os passos que dei  (depois de garantido o acesso IPv6) para correr o servidor Apache em Windows XP (SP3):

1- Fazer o download e instalar a ultima versão do apache para XP em:

httpd.apache.org/download.cgi

2 -Fazer o download do ficheiro:   httpd-2.2.11-ssl-ipv6-x86.zip  em: http://www.apachehaus.com/cgi-bin/dlmanage.pl

3 - Copiar todos os ficheiros  contidos neste último arquivo  para as directorias de instalação do primeiro, excepto os das directorias:  /conf e /htdocs (para manter as configurações).
 

O facto de ter uma página Web activa em IPv6, abre a porta a mais um passo na interessante iniciativa que é  certificação em IPv6 da HE em: ipv6.he.net/certification/

Como indiquei num post anterior se quiserem ajuda para aceder ao meu site em IPv6 é só pedir...

Consegui colocar um servidor FTP em IPv6 com o Xlight FTP Server 2.8. Irá ficar "online" durante uns dias e pode ser testado em:

[jalmeida.broker.freenet6.net]/

(é necessário ter acesso IPv6 Global !!!. De outra forma não responde)

Este IPv6 e  este dominio também se podem  "pingar".

N:\>ping jalmeida.broker.freenet6.net.
Reply from 2001:5c0:8fff:fffe::cf6b: time=353ms....
    Minimum = 348ms, Maximum = 355ms, Average = 352ms

Mas não consegui colocar o Apache 2.2.10 (não encontrei outro  software) a funcionar como WEB SERVER em IPv6 no Windows XP SP2 (em IPv4 não tive problemas de maior).

A questão que coloco e a ajuda que peço é a seguinte:

 -Já alguém conseguiu?

 -Se sim, pode p.f. indicar que programa usou?

Decidi editar  este simples post , na sequência de uma necessidade recente de   alterar a "Prefix Policy" do WIn XP (depois de uma re-instalação do SO) para conseguir navegar em IPv6.

Deixo a "receita", se alguém estiver interessado na explicação, p.f. ,que se manifeste...:

N:\>netsh
netsh>interface
netsh interface>ipv6

\\ "Prefix Policy" por defeito:
netsh interface ipv6>sh prefixpolicy
Querying active state...
Precedence  Label  Prefix
----------  -----  --------------------------------
         5      5  2001::/32
        10      4  ::ffff:0:0/96
        20      3  ::/96
        30      2  2002::/16
        40      1  ::/0
        50      0  ::1/128

\\Comandos para a alterar:
netsh interface ipv6>set prefixpolicy ::ffff:0:0/96 10 4
Ok.
netsh interface ipv6>set prefixpolicy ::/96 20 3
Ok.
netsh interface ipv6>set prefixpolicy 2002::/16 30 1
Ok.
netsh interface ipv6>set prefixpolicy ::/0 40 1
Ok.
netsh interface ipv6>set prefixpolicy ::1/128 50 0
Ok.
\\"Prefix Policy" alterada.
netsh interface ipv6>sh prefixpolicy
Querying active state...
Precedence  Label  Prefix
----------  -----  --------------------------------
        50      0  ::1/128
        40      1  ::/0
        30      1  2002::/16
        20      3  ::/96
        10      4  ::ffff:0:0/96

\\Confirmação da conectividade IPv6.

N:\>ping6 ipv6.google.com

Pinging ipv6.l.google.com [2001:4860:0:1001::68]

from 2002:55f1:1cd7:1:21d7:d755:a907:25a2 with 32 bytes of data:

Reply from 2001:4860:0:1001::68: bytes=32 time=96ms

Reply from 2001:4860:0:1001::68: bytes=32 time=90ms

Reply from 2001:4860:0:1001::68: bytes=32 time=84ms

Reply from 2001:4860:0:1001::68: bytes=32 time=92ms

Ping statistics for 2001:4860:0:1001::68:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 84ms, Maximum = 96ms, Average = 90ms

Os fabricantes gostam muito de anunciar o suporte ao IPv6 (parece que garante algum prestigio...) assim como qualquer técnico de redes gosta de dizer que sabe umas coisas sobre IPv6 (mesmo que apenas tenha lido uns “sound bites” sobre o assunto na internet ou numa apresentação).

Assim alguns  dão suporte de fachada ao IPv6, mas depois esquecem-se das mais elementares características que garantem a sua real implementação. E aquelas que levam a falhas de segurança são mais graves.

Lembram-se da suposta maior segurança do IPv6?

- Pois eu acho que demasiada gente acredita nisso sem pestanejar...

Mas se os buracos nos equipamentos e SO, começarem a dar problemas então poderão abalar (injustamente) a credibilidade deste protocolo... 

Ainda não tive, infelizmente, a oportunidade de testar um FW ("a  sério") em IPv6. Espero que estejam melhor preparados  do que alguns dos routers e SO.

E é normal que exista um caminho a percorrer até que todas  as falhas sejam detectadas e corrigidas, até porque o paradigma da segurança deve ser totalmente reequacionado em IPv6, mas se os decisores continuarem a "dormir" (“fat and happy”…) e a implementação do IPv6 acabar por ocorrer "à pressa", então penso que, provavelmente, não vai existir tempo para reequacionar nada e os falsos pressupostos e pretensos conhecimentos poderão impelir os responsáveis e os  técnicos das TI´s a tomar decisões que para além de não permitirem tirar partido das potencias vantagens económicas do novo protocolo, ainda podem colocar em risco a segurança das nossas vidinhas... 

O que pensam sobre isto ?

Caí no erro de andar um dia destes a limpar umas coisas na configuração do meu router, e por engano tirei a seguinte linha de configuração: 

ipv6 route ::/0 2002:C058:6301:

Nos logs  do Cisco resultante de uma  ACL IPv6 do tipo: permit ipv6 any any log 

aplicada na  saída da interface virtual do túnel 6to4 (Tunnel64) ainda verifiquei que o meu PC\browser estava  a enviar pacotes para  o router:

Nov 15 00:10:09.462: %IPV6-6-ACCESSLOGP: list Net->RedeInterna/30 permitted tcp 2002:51C1:27EF:1:21D:60FF:FEBA:266(1084) -> 2001:4810::110(80), 2 packets
Nov 15 00:10:09.466: %IPV6-6-ACCESSLOGP: list Net->RedeInterna/30 permitted tcp 2002:51C1:27EF:1:21D:60FF:FEBA:266(1100) -> 2001:4860:0:1001::68(80), 1 packet

Mas não tinha resposta destes sites IPv6...

Reparei que faltava uma rota de saída para o tráfego e acrescentei a linha:

ipv6 route ::/0 Tunnel64

Mas nada! Já não conseguia navegar em sites IPv6 !

Só o conjunto destas duas rotas permite ter acesso IPv6 por este tipo de túnel:

ipv6 route 2002::/16 Tunnel64
ipv6 route ::/0 2002:C058:6301::

Alguém quer tentar explicar ?

Fiz o upload do relatório principal e de um anexo do meu projecto do ISEL.

Se alguém tiver interessado poderei considerar a hipótese de fazer o "upload" de outros anexos. Espero que seja útil. Os links estão indicados na lista de links "Trabalho sobre IPv6"

http://penrose.uk6x.com:

O objectivo deste blog é:

 - Partilhar alguns dos conhecimentos que adquiri sobre IPv6 no âmbito de um projecto que realizei sobre o tema da cadeira de projecto da licenciatura em Eng.º de Engenharia de Electrónica, Telecomunicações e Computadores do ISEL (Instituto Politécnico de Lisboa).

- Estabelecer contactos com outros engenheiros ou técnicos interessados  no IPv6  de modo  a partilhar  experiencias que possam ser mutuamente benéficas.

José de Almeida

P.S.:Eis um fantástico video gravado  numa reunião do nosso RIR: a  RIPE  (Réseaux IP Européens)