Manifesto Internet

Reproduzido de: http://palazzo.pro.br/cronicas/031.htm 1. A Internet é diferente. Ela produz diferentes esferas de público, diferentes termos de troca e diferentes habilidades culturais. Os media têm de adaptar os seus métodos de trabalho à realidade tecnológica atual, em vez de a ignorarem ou desafiarem. É o seu dever desenvolverem a melhor forma possível de jornalismo, com base na tecnologia disponível. Isto inclui novos produtos e métodos jornalísticos. 2. A Internet é um império dos media tamanho de bolso. A Net reorganiza as estruturas dos media já existentes ao transcender os seus limites anteriores e oligopólios. A publicação e disseminação de conteúdos mediáticos já não estão ligados a investimentos avultados. A concepção própria do jornalismo está, felizmente, a ser esvaziada da sua função de guardiã. Tudo o que resta é a qualidade jornalística através da qual o jornalismo em si se distingue de uma mera publicação. 3. A Internet é a nossa sociedade é a Internet. As plataformas com base na Net, como as redes sociais, Wikipedia ou o Youtube tornaram-se numa parte da vida diária para a maioria das pessoas no mundo ocidental. São tão acessíveis como o telefone ou a televisão. Se as empresas de comunicação social querem continuar a existir, têm de perceber a vida e o mundo dos utilizadores de hoje e têm de se render às suas formas de comunicação. Isto inclui as formas básicas da comunicação social: ouvir e responder, também conhecido por diálogo. 4. A liberdade da Internet é inviolável. A arquitetura aberta da Internet constitui a lei básica das Tecnologias da Informação, de uma sociedade que comunica de forma digital e, consequentemente, do jornalismo. Pode não ser alterada em nome da proteção especial de interesses comerciais ou políticos, muitas vezes escondidos sob a falsa pretensão do interesse público. Independentemente da forma como se faz, bloquear o acesso à Internet põe ameaça a livre circulação de informação e corrompe o nosso direito fundamental de obter informação com algum nível de independência. 5. A Internet é a vitória da informação. Devido a tecnologia inadequada, as empresas de comunicação social, os centros de investigação, as instituições públicas ou outras organizações é que compilavam e classificavam, até agora, a informação mundial. Hoje, qualquer cidadão pode definir o seu próprio filtro noticioso, enquanto os motores de busca mergulham em tesouros de informação de uma magnitude nunca vista. Os indivíduos podem agora informar-se melhor do que nunca. 6. A Internet melhora o jornalismo. Através da Internet, o jornalismo pode cumprir o sei papel socio-educativo de uma nova forma. Isto inclui a apresentação de informação como algo em constante mudança, num processo contínuo; o preço da inalterabilidade dos media impressos é um benefício. Aqueles que querem sobreviver neste novo mundo da informação precisam de um novo idealismo, novas ideias jornalísticas e de um sentido de prazer na exploração deste novo potencial. 7. A Net requer gestão de redes. Links são ligações. Conhecemo-nos uns aos outros por ligações. Aqueles que não os utilizam excluem-se do discurso social. Isto também é válido para as páginas da Internet das empresas de comunicação social tradicionais. 8. Links recompensam,citações enfeitam. Os motores de busca e os agregadores facilitam o jornalismo de qualidade: impulsionam a busca de conteúdos notáveis a longo prazo e são também parte integrante da nova esfera pública em rede. As referências através de links e citações – especialmente as que são feitas sem autorização ou remuneração do autor – possibilitam, em primeiro lugar, a própria cultura do discurso social em rede. São susceptíveis de serem protegidas com todos os meios. 9. A Internet é um novo palco para o discurso político. A Democracia prospera com a participação e a liberdade de informação. Transferir a discussão política do meio tradicional para a Internet e alargar este debate, ao envolver activamente a participação do público, é uma das novas tarefas do jornalismo. 10. Hoje,liberdade de imprensa significa liberdade de opinião. O Art. 5º da Constituição alemã não contempla direitos protecionistas para profissões ou modelos de negócio tecnicamente tradicionais. A Internet ultrapassa as barreiras tecnológicas entre o amador e o profissional. É por isto que o privilégio da liberdade de imprensa se deve aplicar a todos os que contribuam para a concretização das tarefas jornalísticas. Em termos qualitativos não deve ser distinguido o jornalismo pago do que não é pago, mas sim entre o bom e o mau jornalismo. 11. Mais é mais – não existe algo como demasiada informação. Era uma vez, instituições como a Igreja davam prioridade ao poder sobre o conhecimento individual e avisaram que iria surgir um fluxo de informação transbordante quando foi inventada a imprensa. Por outro lado existiam os panfletários, enciclopedistas e jornalistas que provavam que mais informação leva a mais liberdade, ambas para o indivíduo como para a sociedade enquanto um todo. Até aos dias de hoje, nada mudou a este respeito. 12. A Tradição não é um modelo de negócio. Pode-se ganhar dinheiro na Internet com conteúdos jornalísticos. Já existem muitos exemplos destes, hoje. Mas, porque a Internet é selvaticamente competitiva, os modelos de negócio têm de ser adaptados à estrutura da Net. Ninguém deve tentar esquivar-se desta adaptação essencial através da criação de políticas para preservar o status quo. O jornalismo precisa de competição livre para as melhores soluções de refinanciamento na Internet, a par de coragem para investir numa implementação multifacetada destas soluções. 13. Os direitos de autor são um dever cívico na Internet. Os direitos de autor são o fundamento da organização da informação na Internet. Os direitos do autor sobre o tipo e espectro de divulgação dos conteúdos são também válidos para a Net. Ao mesmo tempo, os direitos de autor não podem ser utilizados de forma abusiva enquanto alavanca para salvaguardar mecanismos de distribuição obsoletos e para excluír novos modelos de distribuição ou esquemas de licenciamento. Ser proprietário implica obrigações. 14. A Internet tem muitas unidades monetárias. Os serviços jornalísticos online financiados através de publicidade oferecem conteúdo em troca de um efeito de encomenda. O tempo de um leitor, telespectador ou ouvinte é valioso. Na indústria do jornalismo esta correlação foi sempre um dos princípios fundamentais do financiamento. Outras formas de refinanciar, jornalisticamente justificáveis, têm de ser criadas e testadas. 15. O que está na Net fica na Net. A Internet está a elevar o jornalismo para um novo nível qualitativo. Na Internet, o texto, o som e as imagens não têm de continuar a ser temporários. Permanecem acessíveis, ao mesmo tempo que constroem um arquivo da história contemporânea. O jornalismo tem de ter em conta o desenvolvimento da informação, a sua interpretação e os seus erros, isto é, tem de admitir os erros e corrigi-los de forma transparente. 16. A qualidade permanece como a mais importante das qualidades. A Internet exibe grandes quantidades de conteúdos homogéneos. Só aqueles que se destacam, que são credíveis e excepcionais é que vão ganhar seguidores constantes a longo prazo. As exigências dos utilizadores aumentaram. O jornalismo tem de as satisfazer e continuar a seguir os princípios que elas frequentemente formulam. 17. Tudo para todos. A Internet constitui uma infraestrutura para uma mudança social, superior à dos meios de comunicação de massa do Séc.XX: Quando tem uma dúvida, a “Geração Wikipédia” tem capacidade para dar valor à credibilidade da fonte, é capaz de seguir a notícia até à sua fonte original, pesquisá-la, verificá-la e avaliá-la – sozinha ou como parte de um esforço conjunto. Os jornalistas que ignoram isto e que não querem respeitar estas capacidades não são levados a sério por estes utilizadores da Internet. E com razão. A Internet possibilita a comunicação direta com aqueles que eram conhecidos como receptores – leitores, ouvintes e espectadores – e permite tirar partido dos seus conhecimentos. Não são os jornalistas que sabem tudo que são procurados, mas sim aqueles que comunicam e investigam.   Internet, 08.09.2009 Markus Kedahl Mercedes Bunz Julius Endert Johnny Haeusler Thomas Knüwer Sascha Lobo Robin Meyer-Lucht Wolfgang Michal Stefan Niggemeier Kathrin Passig Janko Röttgers Peter Schink Mario Sixtus Peter Stawowy Fiete Stegers Versão para a língua portuguesa porPedro Teichgräber e Paulo Querido

Idéias sobre o que fazer com um bloco /32 do IPv6 – II

Continuação daqui …

Estamos falando sobre endereços IPv6. Nada complicado, mas devemos analisar o conjunto. Por isso, iremos falar sobre cada um dos tipos, em particular exibindo a mais extensa referência possível. As principais referências são as RFCs e, conforme falamos rapidamente, é importante garantir que a RFC que está lendo ou estudando seja uma RFC válida e atualizada. Repetindo, o melhor lugar para isso é o RFC Index, [1].

No IANA estão as melhores referências para começar (aqui). Em [2] está a política de alocação do IPv6 pelo mundo afora, através dos RIRs, NIRs e LIRs e, a respectiva descrição do papel de cada um destes atores, em tal alocação. Logo a seguir, podemos ver em [3], a definição do espaço de endereçamento global do IPv6, reproduzido na tabela abaixo:

Prefixo IPv6	Alocação	Referência
0000::/8	Reservado pelo IETF	[RFC4291]
0200::/7	Reservado pelo IETF	[RFC4048]
0400::/6	Reservado pelo IETF	[RFC4291]
0800::/5	Reservado pelo IETF	[RFC4291]
1000::/4	Reservado pelo IETF	[RFC4291]
2000::/3	Unicast Global	[RFC4291]
4000::/3	Reservado pelo IETF	[RFC4291]
6000::/3	Reservado pelo IETF	[RFC4291]
8000::/3	Reservado pelo IETF	[RFC4291]
A000::/3	Reservado pelo IETF	[RFC4291]
C000::/3	Reservado pelo IETF	[RFC4291]
E000::/4	Reservado pelo IETF	[RFC4291]
F000::/5	Reservado pelo IETF	[RFC4291]
F800::/6	Reservado pelo IETF	[RFC4291]
FC00::/7	Unicast Unique Local	[RFC4193]
FE00::/9	Reservado pelo IETF	[RFC4291]
FE80::/10	Unicast Link Local	[RFC4291]
FEC0::/10	Reservado pelo IETF	[RFC3879]
FF00::/8	Multicast	[RFC4291]

Tabela 1: Espaço de endereçamento IPv6

Por definição, excetuando o prefixo FF00::/8, todo o restante do espaço de endereçamento é Unicast. A tabela acima mostra que somente 3 prefixos foram alocados pelo IANA, além do Multicast: o 2000::/3, o FC00::/7 e o FE80::/10. Há outras exceções importantes:

• O endereço não especificado (::). o endereço de loopback (::1/128) e o IPv4 encapsulado em IPv6 (0:FFF::/32) estão fora do bloco 0000::/8.
• O endereço a ser usado em documentos (2001:DB8::/32 ou, 2001:0DB8::/32), que faz parte do bloco 2000::/3, foi reservado, como veremos mais tarde, de um bloco reservado ao ARIN.

Finalmente, não representado, até agora, o tipo de endereçamento anycast. O anycast é um endereço que pertence ao espaço de endereçamento reservado ao unicast e não é sintaticamente distinguível, portanto. Veja isto na RFC4291, item 2.6 (observe aqui, referências a RFCs que se tornaram obsoletas). Voltaremos ao anycast em outra oportunidade.

Uma ferramenta para nos auxiliar a distinguir os tipos de endereços

Conforme já tinha dito, em http://www.braga.eti.br/ipv6/ipv6.php há uma interessante ferramenta para facilitar a identificação de um endereço IPv6. Por exemplo, se colocarmos 2001:DB8::/32, eis o resultado:

Resultados da análise
IPv6 informado: 2001:db8::/32
Prefixo de rede: 2001:db8:0:0:0:0:0:0
Caracterização do endereço:   
Tipo: Unicast
Escopo: Documentação. Não roteável
RFCs: 3849
Observações: http://www.iana.org/assignments/ipv6-unicast-address-assignments
Em binário:
00100000 00000001 00001101 10111000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Outro exemplo, se colocamos ::, resulta:

Resultados da análise
IPv6 informado: ::
Prefixo de rede: Máscara não informada
Caracterização do endereço:   
Tipo: Unicast
Escopo: Indefinido
RFCs: 4291 (2.5.2)
Observações: Não pode ser atribuido  a nenhum nó. Ignorado por um roteador.
Em binário:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Unicast

Nunca é exagerado, lembrar que:

• Todo o espaço de endereçamento do IPv6 é do tipo unicast, exceto o endereçamento multicast, definido pelo prefixo de rede FF00::/8.
• Da alocação 0000::/3, o endereço indefinido :: e o loopbak, ::/128 foram reservados e definidos.
• Foi reservado o bloco para documentação: 2001:0db8::/32.
• Conforme mostra a Tabela 1, o IANA alocou, inicialmente, o bloco 2000::/3, para o unicast de escopo global.
• O endereçamento anycast faz parte da reserva para o unicast e é indistinguível.
• Duas outras divisões são também unicast: unicast unique Local (FC00::/7) e o Unicast Link Local (FE80::/10). Claro, ambas com escopo local e não roteáveis na Internet. É prudente, meditar sobre osignificado dos dois blocos.

Sigamos em frente no debate sobre o tipo de endereçamento unicast. A principal referência é a [4]. A última atualização do texto foi feita em 13/05/2008 revelando as alocações feitas aos RIRs, até aquela data. Uma alternativa à pesquisa em tais referências é usar o sítio do IPv6 Completo! para descobrir o escopo (e o tipo, também) de um determinado IPv6. Ou a tabela de alocação por inteiro. Muitas vezes, a indentificação do prefixo nos ajuda muito. Por exemplo, vamos pesquisar o bloco reservado para a documentação (2001:0db8::/32 ou 2001:db8::/32), mudando a máscara para /23. Embora sem sentido prático, a mudança da máscara serve para ilustrar a representação do prefixo de rede. Eis o resultado:

Resultados da análise
IPv6 informado: 2001:0db8::/23
Prefixo de rede: 2001:c00:0:0:0:0:0:0
Caracterização do endereço:
Tipo: Unicast  
Escopo: Documentação. Não roteável  
RFCs: 3849  
Observações: http://www.iana.org/assignments/ipv6-unicast-address-assignments
Em binário: 
00100000 00000001 00001101 10111000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Foco no prefixo: 2001:c00:0:0:0:0:0:0. Justifiquemos, olhando os 23 primeiros bits da representação em binário, separada em grupos de 4 bits:

0010 0000 0000 0001 0000 110 => 2001:C... (zeros á esquerda não precisam ser representados)

O prefixo de rede será fundamental para pensarmos da divisão de nosso bloco /32, razão dessa série de artigos. Nossa principal referência, [5], no item 2.5, explica com detalhes a estrutura do unicast.

Referências

[1] RFC Editor, RFC Index.

[2] IANA, Initial Common Regional Internet Registry IPv6 Address Allocation Policy.

[3] IANA, IPv6 Address Space.

[4] IANA, IPv6 Global Unicast Address Assignments.

[5] Hinden, R., Deering, S., IP Version 6 Addressing Architecture, RFC4291, February 2006.

Rápida dica sobre RFCs

RFCs são muito importantes na visão da infraestrutura da Internet. Não é preciso dizer para que servem. A dica, para não perdermos tempo é ir no índice de todas as RFCs, do sítio RFC-Editor, aqui. Procure pela RFC e verifique seu estado, logo à frente de sua citação. Ficará sabendo se ela está obsoleta, por qual RFC foi substituída, se foi atualizada, etc.

Idéias sobre o que fazer com um bloco /32 do IPv6 – I

Prólogo

O acaso favorece a mente preparada.
Louis Pasteur.

Ando observando que depois do IPv6, voltou à moda, binários e hexadecimais, com a intensidade do passado. Há quase 40 anos atrás, quando comecei a tatear em computação, os sistemas binário e hexadecimal, faziam parte da minha mente. Sempre que ensinava em um curso de uso do computador (ou de alguma linguagem, como o Fortran), era mandatório ensinar binário e hexadecimal. Depois, com o passar dos anos, já não era um pré-requisito tão fundamental. Para mostrar aqui, o quanto binário e hexadecimal eram importantes, guglei “assembler do IBM 1130″, meu primeiro computador, na esperança de achar uma listagem qualquer do Assembler do 1130, para exibir aqui. Fiquei alegremente surpreso ao encontrar [3]. O IBM 1130, naturalmente, não era meu, mas era como se fosse meu. Afinal fui a segunda pessoa a ter a chave do CPD da Universidade Federal de Viçosa. Por volta de 1968/1969, o BNDES comprou alguns IBM 1130 e espalhou por algumas instituições (não foram muitas, na época). Por acaso, um deles foi para a UFV, então muito conhecida pela sua especialidade em agronomia. O acaso favoreceu o Prof. Fábio Ribeiro Gomes. Uma mente reconhecidamente privilegiada, que fez com que um daqueles poucos IBM 1130s fosse parar no interior de Minas. No dia da inauguração do equipamento, entrei no CPD (a sala mais “chique” da UFV!) com um punhado de folhas de codificação, contendo um programa em Fortran escrito, para calcular áreas sob curvas de equações de regressão, através do método de Monte Carlo (acho que era o exercício final dos textos de instrução programada da IBM). De lá para cá, não parei mais.

Introdução

À memória dos sete grandes geômetras cristãos ou agnósticos: Descartes, Pascal, Newton, Leibnitz, Euler, Lagrange, Comte, (Allah se compadeça desses infiéis), e à memória do inesquecível matemático, astrônomo e filósofo muçulmano, Buchafar Mohamed Abenmusa Al Kharismi, (Allah o tenha em sua glória!), e também a todos os que estudam, ensinam ou admiram a prodigiosa ciência das grandezas, das formas, dos números, das medidas, das funções, dos movimentos e das forças, eu, el-hadj xerife Ali Iezid Izz-Edim ibn Salim Hank Malba Tahan (crente de Allah e de seu santo profeta Maomé), dedico esta desvaliosa página de lenda e fantasia.
De Bagdá, 19 da Lua de Ramadã de 1321.

Dedicatória feita por Malba Tahan, em seu livro, “O homem que calculava”, [4].

Os NIRs, como o Registro.br estão distribuindo blocos /32 para quem solicita IPv6 (ou para os LIRs), com algumas recomendações vindas dos RIRs (no nosso caso, o LACNIC), afagando as expectativas do ICANN (coordenador central da distribuição de IPs), [5]. Blocos /32, significam nada menos, nada mais do que 79.228.162.514.264.337.593.543.950.336 IPs!. Uma das recomendações é: distribuam blocos /64 para os usuários finais (incluíndo os usuários caseiros)! Algo como 18.446.744.073.709.551.616 (~2⁶⁴) IPs.

É importante fixar, em nossa mente, a dimensão dos números que rondam o IPv6. Por exemplo, compare-os com o espaço de endereçamento de todo o IPv4! Um outro exemplo, mais intuitivo pode-se tirar do “O homem que calculava”. Trata-se do famoso problema do Jogo de Xadrez. O lendário rei Iadava, prometeu ao Lahur Sessa, inventor do jogo de xadrez, uma quantidade de grãos de trigo, obtida pela seguinte sequencia 1 grão para a primeira casa do tabuleiro de xadrez, 2 grãos pela segunda casa, 4 grãos pela terceira casa e, assim sucessivamente até a casa 64 do tabuleiro. A razão dessa promessa, fica à deriva até a leitura do livro [4]. O resultado é o número acima, menos 1. Uma avaliação do resultado, em grãos de trigo, conduzem às seguintes curiosidades:

• Se toda a Terra fosse semeada em grãos de trigo, o rei precisaria de colher durante 450 séculos, para cumprir a promessa.
• Se fôssemos contar os grãos de trigo prometidos, à razão de 5 por segundo (um tempo razoável), um ser humano ou, um robô, trabalhando dia e noite sem parar, levaria 1.170 séculos, para finalizar a contagem.

Nos habituando aos exageros do IPv6, podemos partir para avaliar as alternativas para segmentar um bloco /32. Este primeiro artigo irá se concentrar no entendimento do endereçamento IPv6.

Vale, nesse momento, um pequeno comentário sobre o livro de Simon Singh, em [9]. Simon é um belíssimo escritor e em Big Bang ele reproduz grandezas numéricas (grandes e pequenas), igualmente imensas, pois o livro trata de cosmologia. Mas, Simon, citando o exemplo acima, do Malba Tahan na página 443, deixa pela metade a quantidade de grãos na última casa do tabuleiro e, lamentavelmente, não lembra o autor carioca da fábula que, curiosamente, nunca foi às Arábias.

O espaço de endereçamento do IPv6. Necessidade da mudança de paradigma.

Linhas gerais sobre a alocação de IPv6 pelos IRs podem ser vistas em [5] e diversos outros locais, cuja mais importante referência está em [8]. Uma preocupação constante na literatura, principalmente no início do aparecimento do IPv6 é em relação a agregação, em particular, nas alocações subsequentes. Para permitir a agregação de informações de roteamento e, consequentemente, diminuir a expansão das tabelas de roteamente, a sugestão é distribuir os IPv6s de maneira hieráquica, respeitando a topologia da infraestrutura da rede. Vamos começar olhando na Figura 1, que segue. É uma tabela simples, proposta pelo RIPE NCC, onde a primeira coluna discrimina blocos de IPv6, do /16 ao /56. A segunda e terceira colunas discriminam, respectivamente os blocos /48 e /56 (espera-se, os mais usados na distribuição de quem tem um /32). A última coluna representa os números de bits necessários para atingir os 128 bits do endereçamento. Por exemplo, a primeira linha, representando o bloco /16. Um /16 pode ser subdivididos em 4G redes de blocos /48 e em 1T de redes com blocos /56. Como podemos ver, números incríveis. O que se pode fazer com 1T redes /56?

Figura 1. RIPE NCC IPv6 Chart. Fonte [2].

Dividir para conquistar! Vamos usar essa máxima e, construir uma tabela mais palatável, já que os LIRs recebem blocos /32. A simplificação da Figura 1 está na Figura 2, abaixo. A estrutura é a mesma. Na primeira linha, por exemplo, começa com o bloco /32. Com um /32, podemos obter 65.536 redes com bloco /48. A conta é muito simples: 48-36=16 bits, que nos dá 64K (2¹⁶). São mais de 16 milhões de redes com blocos /56! Blocos /56 implicam em 2⁷². Muito maior, mas muito maior mesmo, do que os grãos do tabuleiro de xadrez! Tá mais para as medias cosmológicas.

Figura 2. Tabela do RIPE NCC reduzida.

Há um outro quadro mais esperto. O Nic.br, tem oferecido cursos presenciais do IPv6 e produzido um material muito bom [10]. Na Figura 1, que segue, um quadro produzido pelo pessoal do Nic.br é, realmente, um Guia didático de Endereçamento IPv6, perfeito! Bits, bytes, binário e hexadecimal se misturam sem, absolutamente, nenhuma complicação. Vamos olhar para esse Guia, com muita atenção!

Figura 3. Guia do Nic.br.

As escolhas de como dividir o bloco /32 são imensas. Alguns parâmetros devem orientar, como exemplo o tamanho das redes que são nossas clientes, as estimativas de desenvolvimento, entre outras. Não menos está a perspectiva da escalabilidade de nossos clientes, também, uma previsão difícil, [11]. Algumas abstrações aqui, outras acolá e o conhecimento do negócio, podem nos ajudar a decidir.

Endereços IPv6

Vamos acompanhar, inicialmente a RFC4291, citada em [12]. Tentaremos qualificar o mecanismo de enderaçamento IPv6, atento aos detalhes que são relevantes nesse texto. De imediato seria interessante conhecer o significado de “nó” no contexto do IPv6. “Nó” é um dispositivo que implementa o IPv6. Um “roteador” é um nó que encaminha pacotes IPv6, não explicitamente endereçados a ele. Finalmente, “host” é um nó que não é um “roteador”. Tais definições estão em [13]. Continuando, há três tipos de endereços IPs, conforme discriminados e caracterizados como segue:

• Unicast: É o identificador de uma única interface de um nó. Um pacote enviado para um endereço unicast é entregue à interface identificada por aquele endereço.
• Anycast: É o identificador de um conjunto de interfaces (geralmente pertencentes a nós diferentes). Um pacote enviado para um endereço anycast é entregue a uma das interfaces identificadas por aquele endereço (a mais próxima, segundo os protocolos de roteamento).
• Multicast: É o identificador de um conjunto de interfaces (tipicamente pertencentes a nós diferentes). Um patote enviado para um endereço multicast é entregue a TODAS as interfaces identificadas por aquele endereço.

Devemos ter em mente as seguintes informações importantes sobre os endereços IPv6:

• Representação textual dos endereços:
  • A representação preferida é x:x:x:x:x:x:x:x, onde “x” são quatro dígitos hexadecimais. Por exemplo:

    CAFE:CA5A:DAD0:F0CA:ABCD:EF01:2345:6789
    2001:0DB8:0:0:8:800:200C:417A
    

  • Pode-se usar :: com o objetivo comprimir grupos de zeros hexadecimais, no meio, à esqueda ou à direita da representação textual, desde que somente seja usado uma única vez. Exemplos:

    2001:DB8:0:0:8:800:200C:417A ~ 2001:DB8::8:800:200C:417A
    FF01:0:0:0:0:0:0:101 ~ FF01::101
    0:0:0:0:0:0:0:1  ~ ::1
    0:0:0:0:0:0:0:0 ~ ::
    

• Pode-se representar um endereço através do tradicional prefixo CIDR ou seja endereço-ipv6/prefixo.
• O tipo do endereço é identicado pelos bits de mais alta ordem. Abaixo uma tabela com tal classificação:

  Tipo de endereço	Prefixo binário	Notação IPv6
  Multicast	11111111	FF00::/8
  Unicast	Todo o resto	Não aplicável
  Anycast	Parte do espaço do Unicast	Não distinguível sintáticamente

• Uma questão que pode ficar confusa é o fato do endereço unicast estar aparecendo como todo o restante do endereçamento, exceto o multicast. Para resolver esse impasse de interpretação, foi definido o escopo de um endereço IPv6. Nesse caso, o tipo de endereço anycast, define um escopo no espaço de endereçamento unicast. E, para fixar a presença dos endereços unicast que são roteáveis na Internet, existe o escopo global, denominado Unicast Global. A referência correta para a especificação dos escopos do unicast é [14] e, constantemente atualizada.
• Tipos especiais de endereços, qualificados pelo escopo, podem ser visualizados na tabela que segue, incluindo sua definição:

  Nome	Notação IPv6	Significado
  Não especificado	::/128	Não deve ser usado para identificar uma interface. Roteadores não roteiam pacotes para este endereço
  Loopback	::1/128	Identifica a interface do host local.
  Link local	FE80::/10	São os endereços privativos. Não roteáveis para a Internet.
  Local único	FC00/7	Usado somente em ambientes desconectados da Internet.
  Mapeamento IPv4	::FFFF:0:0/96	Usado nos mecanismos de transição
  Tunelamento Teredo	2001::/32	Tecnologia de transição. É um mecanismo de atribuição de endereço IPv6 sob IPv4.
  Endereçamento 6to4	2002::/16	Será usado no período de transição no 6to4
  ORCHID	2001:10::/28	Não roteável. Usado para CHI (Criptographic Hash Identifiers).

Embora pareça um pouco complicado a lembrança de todas as alternativas de representação de endereços, tudo é uma questão de se acostumar. Para facilitar a descoberta do tipo e escopo de endereços IPv6, desenvolvi e está em evolução, aqui, uma facilidade para descobrir, rapidamente, algumas informações sobre um número IPv6 específico.

Continuamos no tópico II desse tema.

Referências

[1] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., Hahn, C., IPv6 Unicast Address Assignment Considerations. RFC5375, December 2008.
[2] RIPE NCC, Understanding IP Addressing.
[3] Aleks, N. & Knittel, B., IBM 1130.
[4] Tahan, M., O homem que calculava. Edição completa em .pdf, aqui!
[5] RIPE NCC, IPv6 Address Allocation and Assignment Policy, June 2009. pdf.
[6] Hinden, R., Deering, S., IP Version 6 Addressing Architeture, RFC3513 (Standards Track), February 2006.
[7] Tsuchiya, P., On the Assignment of Subnet Numbers, RFC1219, April 1991.
[8] IANA, Number Resources => IP Address Allocations => Internet Protocol Version 5 (IPv6).
[9] Singh, S., Big Bang, Tradução de Jorge Luiz Calife, Record, 2006.
[10] Projeto IPv6.br, Guia didático de endereçamento IPv6, http://www.ipv6.br. Curso IPv6 Básico (Presencial).
[11] Blanchet, M., A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block, RFC3531, April 2003.
[12] Hinden, R., Deering, S., IP Version 6 Addressing Architecture, RFC4291, February 2006.
[13] J. Loughney, Ed., IPv6 Node Requirements, RFC4294, April 2006.
[14] IANA, Internet Protocol Version 6 Address Space, http://www.iana.org/assignments/ipv6-address-space/.

Caracterizando a Infraestrutura da Internet – Visão teórica

Introdução

Ando tentando caracterizar, com o máximo possível de precisão, a Infraestrutura da Internet. Como é minha área de interesse e preciso aprender bastante sobre o seu entorno (razão pela qual escrevo esse blog), mais recentemente ando empenhado em um projeto de pesquisa relacionado.

No passado, trabalhei muito em modelos matemáticos, ênfase em modelos lineares, bem mais simples do que os modelos não lineares. Como bolsista de iniciação científica, há muitos anos atrás, senti na pele (oops! – no cérebro), as dificuldades em resolver problemas não linerares. Haviam muitos problemas em aberto que forneciam combustível para meu entusiasmo (e, certamente de muitos outros), na direção da teoria da computação. Naquela época, os membros acadêmicos da ciência se ajustando às mudanças da computação falavam na incrível velocidade com que elas aconteciam [1]. Imaginem tais preocupações hoje, com a Internet se transformando a cada segundo. De qualquer maneira, os problemas continuam os mesmos. Mas com uma número maior de escolhas a serem feitas. As escolhas, são realmente difíceis e estão associadas a paradigmas, de um modo geral, o que piora um pouco o cenário. Paradigmas, teóricos ou práticos induzem-nos a uma enorme perda de tempo, principalmente se a escolha for errada. Um exemplo intuitivo está em Denning [2], quando lembra que do ciclo de desenvolvimento dos sistemas que implementam a memória virtual, só se pode esperar benefícios quando os algoritmos associados forem suficientemente refinados. Ele disse isso em 1980. Em meados da década de 1970, me lembro bem, a IBM implementou a memória virtual em seus sistemas operacionais (nos modelos da linha /370), cuja eficiência estava no mecamismo, por ela denominado DAT (Direct Address Translation), em hardware.

A propósito, Peter Denning sempre foi um brilhante cientista. Presidente da ACM, se preocupou em produzir uma vasta bibliografia na direção de estabelecer modelos para ajudar a eficácia dos pesquisadores, professores alunos e profissionais da ciência da computação, além dos trabalhos de suas áreas de pesquisa. Em [3], um ponto de vista corajoso, na direção de caracterizar a profissão de TI. Feitelson [4], ainda referenciando Denning no seu comentário sobre a memória virtual, compara o método científico com o esforço caracterizado em experimentos de projeto de sistemas. Antes de mostrar o modelo de comparação de Feitelson, vale mostrar dois modelos interessantes (um aperfeiçoando o outro), subsídios consideráveis, para induzir a criação de um modelo para a Infraestrura da Internet. Podem ser vistos em [5], numa abordagem de pesquisadores envolvidos com Sistemas de Suporte a Decisão (DSS), que partiram do modelo tradicional, reproduzido na Figura 1 e, sua evolução, na Figura 2, adicionando perspectivas não existentes no modelo original.

Figura 1. Processo de tomada de decisões (DSS tradicional em Shim et ali [5])

Na evolução do modelo DSS tradicional, representado na Figura 2, que segue, a perspectiva técnica (T) foi quem sempre dominou a formulação de problemas com envolvimento no desenvolvimento de banco de dados e modelos, propriamente ditos. As perspectivas organizacional (O) e pessoal (P) asseguram que em um debate entre todos os participantes do processo, todas as variáveis relevantes estarão incluidas no modelo. Por fim, as perspectivas não quantificáveis, mas relevantes: ética e estética.

Figura 2. Novo paradigma para o processo de tomada de decisões (Shim et ali. [5]).

Os pesquisadores da área de DSS, que desde os anos de 1990 se preocupam com a automação do processo de apoio à tomada de decisões contribuiram de forma relevante para confirmar o pensamento do pessoal da área de engenharia de software quando modelam a relação entre o método científico e o projeto de sistemas, reconhecidamente experimental. Eis a comparação na Figura 3, abaixo:

Figura 4. Método científico (a) x método experimental (b) (Feitelson [4])

O “loop” infinito

“Loop” infinito é uma boa denominação para a representação da Figura 3 acima. O exemplo da memória virtual, dado por Denning é interessante. No início, os procedimentos envolvendo os sistemas de paginação eram constantes na literatura. Técnicas e mais técnicas foram criadas, desenvolvidas. testadas, melhoraras, numa repetição que dura até hoje. Entretando, de uns poucos anos para cá, ela chegou em um ponto razoavelmente estável que raramente se vê um trabalho de aperfeiçoamento. Só usamos os resultados tendo pouco interesse de rever, exceto em aplicações específicas (portanto, não para). Já está em uma etapa bastante madura. Mas levaram-se alguns anos para o aperfeiçoamento.

Um outro exemplo interessante de se observar, são os navegadores. Não tenho interesse nos navegadores, exceto sob o ponto de vista de usuário. Em minhas máquinas pessoais, tenho o Chrome, o Firefox e o IE. Estou inclinado, seriamente, em instalar outros. Percebo, naturalmente como um usuário especializado, que as atualizações (ou os resultados do “loop” infinito) estão acontecendo por exigência da competição entre os diversos responsáveis pelo ciclo de desenvolvimento. O desejo de atrair usuários através de funcionalidades e facilidades de uso, maiores do que o competidor. O tiro pode, entretanto, sair pela culatra.

Mas, porque tenho tantos navegadores? Por uma razão bem simples. Preciso de domínios (de aplicações) bem definidos, quando uso determinados recursos na Web. Por exemplo, como parte da equipe de desenvolvimento do Sistema FaleOK preciso acessá-lo com autenticações diferentes. Se faço isso em um só navegador, não consigo manter a primeira conexão que fiz. Mas, se cada autenticação for feita em um navegador diferente, consigo manter todas ao mesmo tempo. No Sistema FaleOK há pelo menos 4 ambientes: o administrador geral, o administrador de uma Central OK, o administrador de uma Central OK associada e o usuário final. Assim, abrindo três navegadores diferentes, consigo manter três dominios de aplicações diferentes … Fico precisando de mais um. A Figura 5, abaixo, ilustra o efeito desse tipo de demanda, quando adicionamos o Netscape.

>

Figura 5. Domínios de aplicações e os navegadores.

Naturalmente, o usuário comum ou não especializado não possui tal demanda. Mas não seria uma boa competição se o “loop” infinito dos produtores de navegadores nos entregasse a perspectiva de domínios de aplicações quando abríssemos uma nova janela? Poderíamos ter um só navegador! Nenhuma avaliação mais detalhada foi feita sobre o modelo acima, mas é de se esperar que um respeito adicional sobre o sistema operacional que hospeda um navegador seria, também, de grande valia. O exemplo acima, se aplica quando usamos o Zope e/ou Plone, que provocam uma razoável complexidade no domínio de aplicação de um usuário. Por outro lado, não cabe imaginar que o dominio de aplicação seja um problema dos desenvolvedores de software e não dos navegadores, penso eu.

Projetos em computação e a Engenharia de Software

Até agora, estamos discutindo com ênfase na abstração. Mas, meu projeto é de natureza prática, embora tenha componentes teóricos associados. Não tivesse tal característica prática, talvez simulação fosse uma alternativa interessante. Provavelmente, em alguns casos usaremos simulação. Por exemplo, no treinamento à distância de alguns protocolos. Mas sempre atento ao que diz Floyd, em [6].

A computação é uma área equivalente à engenharia. Nos últimos anos, as instituições de ensino têm popularizado a computação através da criação de cursos de curta duração e alienados do pensamento mais formal e consideravelmente necessário. Apesar disso, uma disciplina tem mantido seu vigor imprescindível: a Engenharia de Software. Muitos tem falado da Engenharia de Software como disciplina fundamental no desenvolvimento de projetos de software ou sistemas de computação. Por exemplo, Dening [7] e, dai para os dias atuais há movimentos bem produtivos. Um conjunto de ferramentas interessantes foi aparecendo, principalmente na área de modelagem de banco de dados e de relacionamento entre os componentes de um sistema de grande porte. Tais ferramentas e o exercício de abstração produzidos pelo pessoal que mantem a engenharia de software no patamar adequado, são essenciais para qualquer projeto e, os manteremos em mente durante as especificações necessárias à caracterização da infraestrutura da Internet. Em particular, estaremos atentos a alguns tópicos propostos em Braga [8], principalmente aqueles relacionados com o gerenciamento do conhecimento.

Referências

[1] Hopcrof, J. E., Computer Science: The emergence of a discipline. Turing Award Lecture, CACM, 30(3), March 1987. pdf.
[2] Denning, P. J., Workink sets past and present. IEEE Trans. Softw. Eng., SE-06(1). ´´; 64-84, Jan 1980.
[3] Denning, P. J., When IT Becomes a Profession. Capítulo 3 do livro The Invisible Future. McGraw Hill, August 2001. pdf.
[4] Feitelson, D. G., Experimental Computer Science: The Need of a Cultural Change, School of Computer Science and Engineering, The Hebrew University of Jerusalem, December 3, 2006. pdf.
[5] Shim, J. P., Warkentin, M., Courtney, J.F., Power, D. J., Sharda, R., Carlsson, C. Past, present, and future of decision support technology. Elsevier, Decision Support System 93, 2002. pdf.
[6] Floyd, S., & Paxson, V. Difficulties in Simulating the Internet. (IEEE/ACM, Ed.) TRANSACTIONS ON NETWORKING , 9(4), pp. 392-403. August 2001.
[7] Denning, P. J., Performance Modeling: Experimental Computer Sciente a its Best, President´s Letter, Communications of ACM, November 1981. pdf.
[8] Braga, J. C., Diretrizes para o Ensino Interdisciplinar de Engenharia de Software, Trabalho a ser publicado, 2009.

Endereços IPv6 bem conhecidos

Na tabela abaixo, a relação de endereços IPv6 definidos na RFC5156, que devem aparecer em regras de filtragem ou firewall. A tabela, na medida do possível será refinada.

Endereço	Uso	Observações
::/0	Não especificado	Não pode aparecer na Internet.
::1/128	Loopback	Não pode aparecer na Internet
::/128	Não especificado	Não pode aparecer na Internet
::FFFF:0:0/96	Mapeamento IPv4	Não podem aparecer na Internet
::/96	Endereços compatíveis com IPv4.	Não podem aparecer na Internet
fe80::/10	Link-local unicast. Usados para configuração sem estado (stateless)	Não podem aparecer na Internet (default)
fc00::/7	Unique-local	Não podem aparecer na Internet (default)
2002::/16	Unicast link-local	Não podem aparecer na Internet
2001:db8::/32	Usados para documentar e como endereços privativos	Não podem aparecer na Internet
2002::/16	Usados em túneis 6to4	Publicado se estiver rodando um relay 6to4 ou em uma oferta de transito em 6to4. Filtros estão na RFC3964.
2001::/32	Usado pelo tunelamento Teredo.	Publicado se estiver rodando um relay Teredo ou em uma oferta de transito via Teredo.
5f00::/8	Usado na rede experimental 6bone.	Bloco retornado ao IANA e será usado em futuras alocações. Não pode aparecer na Internet até ser alocado.
3ffe::/16	Usado na rede experimental 6bone.	Bloco retornado ao IANA e será usado em futuras alocações. Não pode aparecer na Internet até ser alocado.
2001:10::/28	Endereços do ORCHID (Overlay Routable cryptographic Hash IDentifieres).	Não podem aparecer na Internet.
2001:0000::/29 2001:01F8::/29	Endereços especiais reservados ao IANA (RFC4773).	Somente podem aparecer na Internet os que forem publicados pelo IANA.
ff00::/8	Endereçamento multicast	Somente podem aparecer na Internet se os 4 bits de escopo global estiverem definidos.

Coisas importantes sobre o IPv6

Últimas atualizações:
22/04/2009 – 08:17
07/07/2009 – 07:17

Introdução

Às vésperas do primeiro curso presencial de IPv6, oferecido pelo Nic.br, seguem abaixo anotações retiradas dos cursos do projeto 6DEPLOY (veja aqui) e do Introdução ao IPv6, do próprio Nic.br.

A organização segue o esquema dos dois cursos acima e tem a intenção de servir como referência rápida, sem profundidade. Serão completadas nos próximos dias.

Considerações iniciais

• O IPv6 é um novo protocolo e não uma atualização do IPv4! Seu projeto levou cerca de 10 anos.
• Há uma espectativa de os estoques de IPv4 da IANA se esgotem entre 2010 e 2012. Dos registros regionais (no nosso caso, o LACNIC), não durem mais do que 3 anos.
• Medidas do IPv4:
  • 32 bits
  • 4.294.967.296
• Medidas do IPv6:
  • 128 bits
  • 340.282.366.920.938.463.374.607.431.768.211.456 => 2¹²⁸ => 79 trilhões de trilhões de vezes a disponibilidade do IPv4 ~= 5,6 x 10²⁸ endereços por ser humano.
  • Reserva metade dos bits para enderaçamento local => 18.446.744.073.709.551.616 ou 2⁶⁴ redes disponíveis.
• O IPSec é obrigatório no IPv6.
• O ICMP foi modificado, com a inclusão de mecanismos de autoconfiguração de endereços, descoberta de endereços (Neighbour Discovery) e gerenciamento de grupos multicast.
• Implementado o suporte a conexões móveis criando facilidades para permitir que um usuário se desloque de uma rede para outra sem necessidade de alterar seu IP.
• A fragmentação de pacotes no IPv6 passa a ser feito apenas na origem tornando rápido o roteamento.
• Mecanismos de transição: tunelamento, tradução e pilha dupla.
• Política de distribuição de blocos IPv6:
  • A IANA distribui um bloco /12 para cada RIR.
  • Os RIRs distribuem blocos /32 para cada provedor.
  • Os provedores devem distribuir blocos variando de /48 a /56, para seus clientes. Um bloco /48 pode ser dividido em até 65.536 redes diferentes, cada uma com 18.446.744.073.709.551.616 endereços diferentes. Um bloco /56 pode ser dividido em até 256 redes diferentes, cada uma com 18.446.744.073.709.551.616 endereços diferentes.
  • Um usuário pode receber um bloco /64.
• Sistemas operacionais com suporte a IPv6:
  • BSD: FreeBSD desde a versão 4.0. O NetBSD desde a versão 1.5 (2000). O OpenBSD desde a versão 2.7.
  • Linux: desde a versão 2.1.8 do Kernel, com grandes limitações. Suporte estável a partir da versão 2.2.x.
  • MAC OS X: Desde a versão 10.2 Jaguar. Já vem habilitado por padrão.
  • Windows: Primeira versão no SP1. Versões XP SP2 e SP3, Vista, 2003 Server, 2008 Server e SE já estão com a versão mais aprimorada.

Equipamentos de rede com suporte a IPv6:

• 3com: Desde 1997. NetBuilder desde a versão 11.0. Switches PathBuilder 5500 já possuem suporte IPv6.
• Alcatel-Lucent: SR-OS, utilizado nos roteadores 7750SR e 7710SR possui suporte a diversas funcionalidades do IPv6.
• Cisco: A partir da versão 12,0(21) ST do Cisco IOS (2001).
• Hitachi: Desde 2001 os roteadores GR2000 da família Gigabit Router.
• Juniper: Desde a versão 5.1 do JUNOS (2001) nos roteadores T-Series e M-Series

Cabeçalho do IPv6

igura 1. Cabeçalho do IPv6 (Fonte: Curso IPv6 On-line Nic.br)

• Descrição dos campos do cabeçalho IPv6:
  • Versão: Campo de identificação de versão do protocolo IP utilizado (valor: 6). Tamanho: 4 bits.
  • Class de Tráfego: Define as diferentes classes e prioridades dos pacotes IPv6. É a referência básica do mecanismo de QoS. Tamanho: 20 bits
  • Identificador de Fluxo: Identifica e diferencia sequências de pacotes pertencentes ao mesmo fluxo de dados, que necessitem do mesmo tratamento. Torna eficiente a atividade dos roteadores. Tamanho: 20 bits.
  • Tamanho dos dados: Volume de dados, em bytes, que o pacote transporta. Tamanho: 16 bits.
  • Próximo Cabeçalho: Tipo de iinformação que se segue ao cabeçalho. Tamanho: 16 bits. Poderá ser um pacote da camada de transporte (TCP/UDP) ou um dos cabeçalhos de extensão, cujos valores possíveis são mostrados na tabela abaixo.

Valor	Nome do cabeçalho	Definição
0	Hop-by-Hop	Transporta informações opcionais que são processadas em cada nó ao longo do caminho do pacote, incluindo a origem e o destino.
60	Destination Options	Transporta informações opcionais que são processadas apenas pelo destino final do pacote.
43	Routing	Suporte à mobilidade. Armazena o endereço original de um nó móvel (Type 2).
44	Fragmentation	Utilizado pela origem para enviar pacotes maiores do que o MTU de um caminho. Vale lembrar que no IPv6, a fagmentação ocorre na origem e são reagrupados no final.
51	Authentication	Utilizado pelo serviço IPSec para prover autenticação e garantia de integridade aos pacotes.
50	Encapsulation Security Payload	Utilizado pelo IPSec, também. identifica integridade e confidencialidade aos pacotes.
A ordem acima deve ser respeitada pelo nó de origem. Já o nó de destino deve ser capaz de entender os cabeçalhos em qualquer ordem. Se o campo Endereço de Destino tiver um endereço multicast, os cabeçalhos de extensão serão examinados por todos pertencentes ao grupo multicast. O cabeçalho Mobility pode ser usado pelos nós que possuírem suporte à mobilidade. OBS: O espaço reservado para o endereçamento, 128 bits, permite gerar 3,4 x 1038 endereços distintos.

Limite de encaminhamento: Número máximo de roteadores pelos quais o pacote pode passar, antes de ser descartado. Tamanho: 8 bits

Endereço de origem do pacote. Tamanho: 128 bits

Endereço de destino do pacote. Tamanho: 128 bits

Informações adicionais são tratadas através dos cabeçalhos de extensão, localizados entre o cabeçalho base (descrito acima) e o cabeçalho da camada de transporte. Não há limites quanto à quantidade de cabeçalho de extensão em um mesmo pacote.

Endereçamento

• O endereçamento é representado por oito grupos de 16 bits, separados por : e escritos em hexadecimal:
  FEDC:0034:0000:0000:0012:0000:0ABC:00FF
  FEDC:34:0:0:12::ABC:FF
  fedc:0034::0012:0:0ABc:00FF
• Permitida a representação CIDR: FEDC:34::/48 ou FEDC:34:0:0:12::ABC:1A/64
• Endereços de qualquer tipo podem ser atribuídos a uma interface. Uma interface pode compartilhar mais de um endereço, que pode ser de qualquer tipo.
• Endereços do tipo broadcast não existem mais. Mas a funcionalidade do broadcast é provida pelos endereços multicast.
• Tipos de endereços:
  • Unicast: Endereços que indentificam uma interface unívocamente e, com os seguintes tipos:
    • Global unicast: é a versão pública do endereçamento e, portanto, disponível na Internet IPv6. Seu formato possui sete campos: o prefixo de 3 bits (001); um identificador TLA (Top-Lever Aggregation); um campo reservado (RES); um identificador NLA (Next-Level Aggregation); um identificador SLA (Site-Lever Aggregation); o identificador da interface (interfaceID). Abaixo uma representação sumária:

      3	13	8	24	16	64
      FP	TLA ID	RES	NLA ID	SLA ID	InterfaceID

    • Link-local: atribuídos automaticamente e válidos apenas dentro do mesmo enlace. É identificado por FE80::/64 (64 bits reservados para identificar uma interface).
    • Unique-local: Identificados pelo prefixo FC00::/7, seguidos de um ID global único de 40 bits, gerado randomicamente e, não roteáveis na Internet.
    • Mapeamento IPv4: Utilidados para representar um endereço IPv4 como endereço IPv6 e somente disponível na etapa de transição (quando a Internet for completamente IPv6). Seu formato é: ::FFF:wxyz, onde wxyz é o IPv4 convertido em hexadecimal.
    • Loopback: Identifica a própria interface (interface local) => ::1.
    • Unspecified: indica a ausência de endereço => ::.
  • Anycast: utilizado para identificar um grupo de interfaces pertencentes a nós diferentes. Um pacote destinado a um endereço anycast é enviado apenas para a interface deste grupo mais próxima da origem.
    • Há um consenso de que a experiência com endereços anycast ainda é pequena e, até que ela cresça o suficiente, as seguintes restrições foram recomendadas: (a) um endereço anycast NÃO PODE ser utilizado como endereço de origem de qualquer pacote IPv6; (b) um endereço anycast SÓ PODE ser associado a roteadores.
    • Há um formato para definir endereços anycast. O prefixo da sub-rede no endereço, identifica um link específico. Este endereço anycast é sintáticamente o mesmo do endereço unicast, só que com os bits do identificador da interfaze zerados, como mostrado a seguir:
      

      n bits	(128 – n) bits
      prefixo da subrede	00000000000

  • Multicast: semelhante ao endereço anycast. Identifica um grupo de interfaces ou um grupo de nós. Um pacote destinado a um endereço multicast é enviado para TODAS as interfaces do grupo.
    • Um nó pode pertencer a mais de um grupo multicast.
    • A implementação nativa do multicast no IPv6 elimina a necessidade de criar túneis MBone (Multicasting Backbone), já que todos os hosts e roteadores implementam o endereço multicast.
    • O endereço multicast usa o bloco reservado FF00::/8, onde o octeto que segue o prefixo FF contêm quatro flags que determinam o tempo de vida do pacote e um valor de quatro bits que define o escopo do grupo multicast. Os 112 bits restantes são utilizados para identificar o grupo multicast.
    • A facilidade do broadcast pode ser utilizada através do prefixo FF02::1 referenciando todos os nós de um link multicast.
    • O formato dos endereços multicast é o seguinte:
      

      8	4	4	112
      111 111	flags	escopo	grupo ID

    • Na tabela acima, o camplo flags tem o formato 000T, onde T indica um endereço multicast permanentemente alocado. T=1 indica um endereço temporário. O campo escopo limita o escopo dos endereços multicas e assume alguns valores representando endereços multicast node-local, site-local, link-local, organization-local, global, etc.
• Alocação do espaço de endereçamento: O prefixo definido pelos primeiros bits do endereço indica cada tipo de endereço IPv6. O campo variável que compreende esses bits é denominado Format Prefix (FP). A alocação de todo espaço de endereçamento, disponível em [2] e [3], é mostrado na tabela abaixo:

  Prefixo	Fração do espaço total de endereçamento	Alocação
  0000 0000	1/256	Não alocado (inclui alguns endereços especiais)
  0000 0001	1/256	Não alocado
  0000 001	1/128	Reservado para Alocação NSAP
  0000 01	1/64	Não alocado
  0000 010	1/128	Reservado para Alocação IPX
  0000 01	1/64	Não alocado
  0000 1	1/32	Não alocado
  0001	1/16	Não alocado
  001	1/8	Global unicast
  010	1/8	Não alocado
  011	1/8	Não alocado
  100	1/8	Não alocado
  101	1/8	Não alocado
  110	1/8	Não alocado
  1110	1/16	Não alocado
  1111 0	1/32	Não alocado
  1111 10	1/64	Não alocado
  1111 110	1/128	Não alocado
  1111 1110 0	1/512	Não alocado
  1111 1110 10	1/1024	Unicast: Link-local
  1111 1110 11	1/1024	Unicast: Site-local
  1111 1111	1/256	Multicast

Serviços básicos

ICMPv6

• O ICMPv6 é utilizado para: informar características da rede, realizar dignoósticos e relatar erros no processamento de pacotes.
• Isso é feito através da troca de duas classe de mensagens ICMPv6: mesagens de erro e mensagens de informação.
• O cabeçalho do ICMPv6 é o seguinte:
  
  Figura 1. Cabeçalho do IPv6 (Fonte: Curso IPv6 On-line Nic.br)
• Descrição dos campos do cabeçalho:
  • Tipo: tipo da mensagem. Tamanho: 8 bits.
  • Código: informações adicionais para determinados tipos de mensagens. Tamanho: 8 bits.
  • Soma de Verificação: utilizado para detectar dados corrompidos no cabaçalho ICMPv6 e em parte do cabaçalho IPV6. Tamanho: 16 bits.
  • Dados: informações de diagnóstico e erro, de acordo com o tipo de mensagem. Tamanho: variável, de acordo com a mensagem.
• O ICMPv6 incorpora funções de outros protocolos como o ARP/RARP e IGMP (Internet Group Management Protocol). Tais protocolos são importantes para:
  • Descoberta de Vizinhança
  • Gerenciamento de Grupos Multicast
  • Mobilidade
  • Descoberta do Path MTU
• Mensagens de erro

  Tipo	Nome	Descrição
  1	Destination Unreachable	Indica falhas na entrega do pacote como endereço ou porta desconhecida ou problemas na comunicação.
  2	Packet too big	Indica que o tamanho do pacote é maior que a MTU de um enlace.
  3	Time Exceeded	Indica que o Limite de Roteamento ou o tempo de remontagem do pacote foi excedido.
  4	Parameter Problem	Indica erro em algum campo do cabeçalho IPv6 ou que o tipo indicado no campo Próximo Cabeçalho não foi reconhecido.
  100-101	-	Uso experimental.
  102-126	-	Não usado.
  127	-	Reservado para expansão das mensagens de erro ICMPv6.

• Mensagens de informação:

  Tipo	Nome	Descrição
  128	Echo Request	Utilizada pelo comando ping
  129	Echo Reply	Utilizada pelo comando ping
  130	Multicast Listener Query	Utilizada no gerenciamento de grupos multicast.
  131	Multicast Listener Report	Utilizada no gerenciamento de grupos multicast.
  132	Multicast Listener Done	Utilizada no gerenciamento de grupos multicast.
  132	Multicast Listener Done	Utilizada no gerenciamento de grupos multicast.
  133	Router Solicitation	Protocolo de Descoberta de Vizinhança, para que hosts requisitem aos roteadoresas mensagens de Router Advertisements imediatamente.
  134	Router Adivertisement	Protocolo de Descoberta de Vizinhança, enviadas peridodicamente ou em resposta a uma Router Solicitation. São utilizadas pelos roteadores para anunciar sua presença em um enlace e na Internet.
  135	Neighbor Solicitation	Protocolo de Descoberta de Vizinhança: mensagem multicast enviada por um nó para determinar o endereço MAC e a acessibilidade de um vizinho, além de detectar a existência de endereços duplicados.
  136	Neighbor Advertisement	Protocolo de Descoberta de Vizinhança: mensagem enviada como resposta a um Neighbor Solicitation. Pode também ser enviada para anunciar a mudança de algum endereço MAC dentro do enlace.
  137	Redirect Message	Protocolo de Descoberta de Vizinhança: utilizada por roteadores para informar ao host, um roteador mais indicado para se alcançar um destino.
  138	Router Renumbering	Utilizada no mecanismo de Re-endereçamento (Renumbering) de roteadores.
  139	ICMP Node Information Query	Utilizada para descobrir informações sobre nomes e endereços, são atualmente limitadas a ferramentas de diagnóstico, depuração e gestão de redes..
  140	ICMP Node Information Response	Utilizada para descobrir informações sobre nomes e endereços e são atualmente limitadas a ferramentas de diagnóstico, depuração e gestão de redes.
  141	Inverse Neighbor Discovery Solicitation Message	Utilizada em uma extensão do protocolo de Descoberta de Vizinhança.
  142	Inverse Neighbor Discovery Advertisement Message	Utilizada em uma extensão do protocolo de Descoberta de Vizinhança.
  143	Version 2 Multicast Listener Report	Utilizada no gerenciamento de grupos multicast.
  144	Home Agent Address Discovery Request Message	Utilizada no mecanismo de Mobilidade IPv6.
  145	Home Agent Address Discovery Reply Message	Utilizada no mecanismo de Mobilidade IPv6.
  146	Mobile Prefix Solicitation	Utilizada no mecanismo de Mobilidade IPv6.
  147	Mobile Prefix Advertisement	Utilizada no mecanismo de Mobilidade IPv6.
  148	Certification Path Solicitation Message	Utilizada pelo protocolo SEND.
  149	Certification Path Advertisement Message	Utilizada pelo protocolo SEND.
  150	-	Utilizada experimentalmente com protocolos de mobilidade como o Seamoby.
  151	Multicast Router Advertisement	Utilizada pelo mecanismo Multicast Router Discovery.
  152	Multicast Router Solicitation	Utilizada pelo mecanismo Multicast Router Discovery.
  153	Multicast Router Termination	Utilizada pelo mecanismo Multicast Router Discovery.
  154	FMIPv6 Messages	Utilizada pelo protocolo de mobilidade Fast Handovers.
  200-201	-	Uso experimental.
  255	-	Utilizado para expansão das mensagens de erro ICMPv6.

Protocolo de Descoberta de Vizinhança (Neighbor Discovery)

• Utilizado por hosts e roteadores para:
  • Determinar o endereço MAC dos nós da rede.
  • Encontrar roteadores vizinhos
  • Determinar prefixos e outras informações de configuração da rede.
  • Detectar endereços duplicados.
  • Determinar a acessibilidades dos roteadores.
  • Redirecionamento de pacotes.
  • Autoconfiguração de endereços.
• As mensagens de informação do ICMPv6 com tipos 133 a 137 são usadas pelo protocolo de Descoberta de Vizinhança e possuem o valor 255 no campo Limite de Roteamento do cabeçalho IPV6. Tal valor garante que as mensagens serão originadas de um nó do mesmo enlace. Portanto, as mensagens com valores diferentes são descartadas. Tais mensagens podem ainda, conter as seguinte opções:

  Mensagem	Atribuição
  Source link-layer address	Utilizada em mensagens Neighbor Solicitation, Router Solicitation e Router Advertisement. Nele está o endereço do remetente do pacote.
  Target link-layer address	Utilizada nas mensagens de Neighbor Advertisement e Redirect. Contém o endereço de destino do pacote.
  Prefix information	Fornece aos hosts os prefixos do enlace e os prefixos para que o endereço seja autoconfigurado. Utilizada em mensagens Router Advertisement.
  Redirected header	Utilizada nas mensagens Redirect. Essa mensagem contém todo ou parte do pacote de redirecionamento.
  MTU	Utilizada em mensagens Router Advertisemente. Essa opção garante que todos os nós em um enlace usem o mesmo valor de MTU.

• Funcionalidades:
  • Descoberta de endereço da Camada de Enlace: Utlizada para determinar o endereço MAC dos vizinhos do mesmo enlace, onde um host envia uma mensagem Neighbor Solicitation informando no campo de Dados seu endereço MAC e também solicitando o endereço MAC do vizinho. Ao receber a mensagem, o vizinho a responde enviando uma mensagem Neighbor Advertisement informando seu endereço MAC.
  • Descoberta de Roteadores e Prefixos: Utilizada para localizar roteadores vizinhos dentro do mesmo enlace, bem como aprender prefixos e parâmetros relacionas à autoconfiguração de endereço. A descoberta de roteadores e prefixos é realizada através da recepção de uma mensagem Router Advertisement enviada a partir de um roteador local para o endereço multicas all-nodes.
  • Detecção de Endereços Duplicados:
  • Detecção de Vizinhos Inacessíveis: Mecanismo utilizado na comunicação host-a-host, host-a-roteador e roteador-a-host para rastrear a acessibilidade dos nós ao longo do caminho. Um nó considera um vizinho acessível se ele recebeu recentemente a confirmação de entrega de algum pacote a esse vizinho. Essa confirmação pode ser uma resposta a uma mensagem do protocolo de Descoberta de Vizinhança ou algum processo da camada de transporte que indique que uma conexão foi estabelecida. Este processo apenas é executado quando os pacotes são enviados a um endereço unicast, não sendo utilizado no envio para endereços multicast. Para acompanhar os estados de um vizinho, o nó IPv6 utiliza as seguintes tabelas:
    • Neighbor Cache: mantem uma lista de vizinhos locais para os quais foi enviado tráfego recentemente, armazenado seus endereços IP, informações sobre o endereço MAC e um flag indicando se o vizinho é um roteador ou um host. Também informa se ainda há pacotes na fila para serem enviados, a acessibilidade dos vizinhos e a próxima vez que um evento de detecção de vizinhos inacessíveis está agendado.
    • Destination Cache: mantem informações sobre destinos para os quais foi enviado tráfego recentemente, incluíndo tanto destinos locais quanto remotos, sendo atualizado com informações recebidas por mensagens Redirect. O Neighbor Cache pode ser considerado um subconjunto das informações do Destination Cache.
  • Redirecionamento: Mensagens Redirection são enviadas por roteadores para redirecionar um host automaticamente a um roteador mais apropriado ou para informar ao host que o destino encontra-se no mesmo enlace.

Mecanismos de autoconfiguração: stateless e stateful

• Autoconfiguração de endereços Stateless
  • Permite aos nós a configuração automática dos endereços unicast em suas interfaces, sem a utilização de servidores DHCP. Faz isto a partir de informações enviadas pelos roteadores, em mensagens Router Advertisement e, de dados como o endereço MAC das interfaces, criando automaticamente endereços link-local únicos.
  • Os endereços link-local são gerados utilizando o prefixo FE80::/64. A esse prefixo é anexado o identificador de 64 bits da interface física. Se a interface utilizar um MAC de 48 bits, acrescenta-se FFFE no centro do endereço e invert-se o seu sétimo bit. O novo endereço passa a fazer parte dos grupos multicast solicited-node e all-node.
  • Por meio do processo de detecção de endereços duplicados é feita a verificação da unicidade do endereço de link-local gerado. Atenção: Caso outro nó no enlace esteja utilizando o mesmo endereço link-local, automaticamente o processo de auto-configuração é interrompido, exindo uma configuração manual.
  • Se o endereço link-local for considerado único e válido, ele será automaticamente inicializado para a interface. Esse processo é o mesmo utilizado por hosts e roteadores.
  • Para determinar quais roteadores pertencem ao enlace e quais os prefixos, o host envia uma mensagem Router Solicitation para o grupo multicast all-routers.
  • Feito isso, todos os roteadores do enlace respondem com uma mensagem Router Advertisement. Tais mensagens são utilizadas para configurar:
    • os roteadores padrões,
    • um valor predefinido para o campo Limite de Encaminhamento de cabeçalho IPv6,
    • o valor de MTU do enlace e,
    • a lista de prefixos de rede.
  • Para cada prefixo informado nas mensagens Router Advertisement é gerado um endereço através do mecanismo de autoconfiguração stateless, combinando o prefixo ao identificador da interface. Estas mensagens, também apresentam duas flags:
    • managed address configuration: indica se os hosts deve ou não utilizar autoconfiguração stateful para obter endereços e,
    • stateful configuration: indica se os hosts devem utilizar a autoconfiguração stateful para obter informações adicionais, como endereços de servidores DNS e outros dados sobre a configuração da rede.
• Autoconfiguração de endereços Stateful
  • É uma técnica alternativa à stateless, onde é necessário a utilização de servidores que informem aos hosts, os dados a serem utilizados na obtenção dos endereços, além de outras configurações da rede.
  • Utilizado quando não há roteadores em uma rede ou quando as mensagens Router Advertisement apresentam flags que habilitam seu uso. Baseia-se no uso de protocolos como o DHCPv6, a fim de obter endereços e outras opções de configuração.
  • No DHCPv6 as mensagens são trocadas em UDP, entre cliente e servidor.
  • Os clientes utilizam um endereço link-local para transmitir ou receber mensagens DHCP, enquanto que os servidores utilizam um endereço multicast reservado (FF02::1:2 ou FF05::1:3) para receber mensagens dos clientes. Caso o cliente necessite enviar uma mensagem a um servidor, que esteja fora de seu enlace, é utilizado um Relay DHCP.
  • O DHCPv6 fornece opções de configurações de rede tais como endereços de servidores de DNS, NTP, etc. Permite a análise das políticas de acesso antes de atribuir um endereço ao host.

• É possível utilizar os dois mecanismos simultâneamente: statless e stateful.

Fragmentação

• O processo de fragmentação de um pacote de dados se inicia utilizando o protocolo Path MTU Discovery, que descobre de forma dinâmica qual o tamanho máximo permitido ao pacote, identificando previamente os MTUs de cada enlace no caminho até o destino.
• O Path MTU Discovery assume que o MTU de todo o caminho é igual ao MTU do primeiro salto. Se o tamanho de qualquer um dos pacotes enviados for maior do que o suportado por algum roteador ao longo do caminho, este irá descartá-lo e retornar uma mensagem ICMPv6 packet too big. Após o recebimento dessa mensagem, o nó de origem reduzirá o tamano dos pacotes de acordo com o MTU do caminho indicado na mensagem packet too big.
• O procedimento termina quando o tamanho do pacote for igual ou inferior ao menor MTU do caminho.
• Há uma opção do Cabeçalho de Extensão Hop-By-Hop, chamada Jumbo Payload, que permite o envio de pacotes com cargas úteis entre 65.536 e 4.294.967.295 bytes de comprimento, chamados de jumbograms.

QoS

• Foram designadados dois campos do cabeçalho IPv5: Classe de Tráfego e Indicador de Fluxo, ambos com o objetivo de implementar a priorização do fluxo de determinados pacotes.

DNS

• Registro AAAA para o DNS.
• ip6.arpa, para atender o PTR.
• Um cliente DNS com suporte IPv6, em uma consulta, busca primeiro por registros do tipo AAAA. Não obtendo resposta, consulta por registro do tipo A, com o mesmo nome.
• O servidor DNS pode responder a consultas feitas através do IPv4 ou do IPv6> Os dados obtidos na consulta IPv6 devem ser iguais aos obtidos na consulta IPv4.

Suporte à mobilidade

• O suporte à mobilidade no IPv6 permite que um dispositivo móvel se desloque de uma rede para outra, sem necessidade de alterar seu IP de origem.
• Quando o nó móvel se desloca da sua rede de origem, ele obtém um novo endereço IPv6 na rede remota. Este endereço remoto pode ser obtido através de mecanismos de autoconfiguração stateless ou statefull.
• Para ter certeza de que os pacotes IPv6 cheguem a sua rede remota, é necessária a associação entre o endereço remoto e o endereço de origem, que é feita pelo Agente de Origem.
• O Agente de Origem registra o endereço remoto enviado em uma mensagem Binding Update pelo nó móvel e responde com uma mensagem Binding Acknowledgement.
• O encaminhamento de pacotes para o nó móvel pode acontecer de ois modos: tunelamento bidirecional ou otimização de rota.
• Um novo Cabeçalho de Extensão, o Mobility, foi criado. Também, foi adicionado um novo tipo de Cabeçalho Routing, o Type 2.
• Foram criadas quatro novas mensagens ICMPv6:
  • Home Agent Address Discovery Request
  • Home Agent Address Discovery Reply
  • Mobile Prefix Solicitation
  • Mobile Prefix Advertisement

Segurança no IPv6

Roteamento, mobilidade e gerenciamento no IPv6

Coexistencia com IPv4 e a transição

Referências

[1] IPv6.br: melhor referência para começar sobre IPv6.
[2] IPv6 Address Space Allocation, http://www.tcpipguide.com/free/t_IPv6AddressSpaceAllocation.htm.
[3] Adailton J. S. Silva e Marcel R. Faria, Hierarquia de Endereços IPv6.

A hora e a vez do IPv6

Tá na hora de começar a pensar seriamente no IPv6! Por quê? Porque o CGI está exibindo um movimento mais agressivo, nesta direção. Muito bem feito, está o site do IPv6.br e, por onde se deve começar. Depois de uma geral no IPv6.br, anime-se e faça o curso on-line. Muito bom!

Hoje, 02/05/2006, o CGI.br e Nic.br, divulgaram o curso que pode ser visto aqui é mais completo e tão bom quanto ao do 6Deploy.

Tipos de DNS e suas aplicações

Introdução

É um artigo redundante. Mas, com o objetivo de deixar alguns pontos ainda não compreendidos por alguns. Além de dar ênfase à necessidade de implementação do DNSSEC.

Sob o ponto de vista de uma empresa, instituição ou de um provedor, existem dois tipos de servidores de DNS:

• Autoritativo
• Recursivo

Resolvedor não é um servidor de DNS. É um cliente de um servidor recursivo. Os servidores autoritativos não atendem a consultas do resolvedor. O resolvedor, geralmente fica no sistema operacional ou nos programas tipo ftp, ssh e, muitos outros que provocam o sistema operacional pesquisar os resolvedores. Servidores root são sevidores importantes somente quando implementamos servidores de DNS e, portanto, iremos nos abstrair deles. Basta saber que eles informam aos recursivos a quem recorrer para encontrar o autoritativo que responda pelo domínio que está sendo consultado. São servidore muito especializados e irrelevantes para nosso debate.

Existem inúmeros bons programas que implementam servidores de DNS: bind, unbound, djdns, etc. São ótimos! Cada um com suas vantagens e desvantagens. Por exemplo, o djdns, pelo menos até pouco tempo não implementava o DNSSEC. O bind é um dos mais completos, pois é autoritativo e recursivo, além de implementar o DNSSEC. O unbound somente implementa servidor recursivo tratando eficientemente o DNSSEC.

Quem precisa de um servidor autoritativo?

Somente quem precisar difundir dominios na Internet. O autoritativo é o servidor que está autorizado a responder por um domínio. A autoridade para responder pelo domínio é data pelos registros de domínios, oficiais, de uma determinada região do mundo. No nosso caso, Brasil, quem fornece a autoridade para que um servidor autoritativo responda por um domínio é o Registro.br. Como já falamos, a autoridade do Registro.br é reconhecida pelos servidores root, pois o Registro.br é um NIR (National Internet Register) responsável pelo Brasil e autorizado pelo LACNIC, que é um dos cinco RIRs (Regional Internet Register), do mundo. O Registro.br exige, no mínimo, dois autoritativos para repassar a autoridade. O Registro.br não faz nenhuma exigência em relação aos recursivos, isto é, nem dá bola para eles.

Por ser o autoritativo autorizado pelo Registro.br, a responder por um domínio, ele é um servidor que deve ficar disponível para qualquer consulta feita na Internet. Ou seja, ele é um servidor aberto, sob o ponto de vista de consultas aos domínios. Ai que mora o perigo! Se o servidor autoritativo não estiver muito bem preparado e, não usar o DNSSEC, sua vulnerabilidade passa a ser norme! Ele está suscetível à chamada poluição de DNS (ou comprometimento, ou envenenamento), segundo os comprovados argumentos do Dan Kaminsky, cujos artigos e experimentos podem ser vistos em [1]. A era pós-Kaminsky felizmente trouxe melhoras sinificativas nos sistemas que implementam o autoritativo, principal alvo de ataques.

Se você possui poucos dominios, não se meta a perder tempo em estabelecer um servidor autoritativo. Use o serviços de empresas especializadas, garantindo algumas premissas básicas: (a) possuir pelo menos 2 autoritativos em redes diferentes e, preferencialmente, possuir o(s) servidor(es) autoritativo(s) principais, escondido(s), (b) implemente o DNSSEC, (c) possua mecanismos de criptografia para o tráfego relativo às transferência de zonas e, (d) seja de fácil utilização. Achar a empresa que forneça os serviços com tais características é uma tarefa razoavelmente complicada. Depois de achar, tudo fica bem melhor. Todo cuidado é pouco, contudo. Estamos vendo recentes história de envenenamento de servidores da Telefônica, Embratel, etc.

Quem precisa de um servidor recursivo?

Todos aqueles que possuem usuários ou máquinas com acesso à Internet, na rede sob seu controle. Por exemplo, tenho o Speedy na minha casa. Variando de 1 a 5 equipamentos, principalmente nos fins de semana. Implementei um recursivo por lá? Não! Uso o openDNS. Se ele falhar, uso o DNS da Telefônica. Ou seja, não tenho atividades sensíveis em minha casa.

E na minha empresa? Ah, nela sim! A estrutura de meu sistema de servidores DNS está definida à semelhança da topologia mostrada aqui, onde em cada rede colocamos um ou mais recursivos.

O servidor recursivo tem uma característica interessante, diferentemente do autoritativo. Ele consulta o autoritativo, mas não está liberado para toda a Internet. Ou, não deveria! Somente está liberado para as demandas de sua rede. Entretanto, ele traz as informações de domínios vindas dos autoritativos. Se algum autoritativo está comprometido, ele passará tais informaçoes para frente. Nesse caso, somente o DNSSEC poderá aliviar a tensão do comprometimento, já que é impossível criptogafar o tráfego entre recursivos e autoritativos, pelo menos por enquanto.

Porque tráfego criptografado entre os servidores autoritativos?

Para dificultar a vida do “homem do meio”, técnica muito usada para capturar tráfego entre servidores na Internet. Ele irá conseguir, mas terá de descobrir e adicionar a mesma técnica de criptografia e decriptografia. O DNSSEC adiciona, por outro lado, uma dificuldade a mais, nas tentativas de comprometimento dos servidores. É importante lembrar, que o DNSSEC não criptografa o tráfego nas transferências de zonas entre os autoritativos. Existem técnicas no bind para fazer isso. O DNSSEC apenas garante a integridade dos dados, nesse caso, importantíssimo durante as consultas dos recursivos, o que é muito! Faz isso estabelecendo o que se chama de “cadeia de confiança” ou “cadeia de autenticação”.

Uma pergunta final

Ah, se meus servidores de DNS são seguros? Uai, espero que sim … Servidores de DNS são, provavelmente, os mais importantes componentes da infraestrutura da Internet. Não é suficiente, diante da competência do “bad boys” somente o arcabouço de segurança. É preciso monitorá-los e ficar atento às recomendações constantes e avaliações dos melhores especialistas repassadas em listas técnicas nacionais e internacionais. Além de usar, efetivamente, os recursos inerentes ao próprio servidor de DNS.

O DNSSEC nos tranquiliza porque confere ao DNS, três garantias fundamentais, repetindo algumas que já falamos: (a) a identidade da origem ou, a autenticidade do recursivo (consulta) ou autoritativo (transferência de zonas), que está buscando a informação, (b) a integridade dos dados, através de chaves públicas de criptografias associadas ao dominio e, (c) o reconhecimento da não existência de um nome ou tipo de registro de DNS. Três pontos tão importantes, que não se pode imaginar porque DNSSEC não está implementado em todos os domínios. Veja as referências do artigo DNSSEC I, nesse blogue.

Por fim, algumas empresas, com grande número de domínios para publicação, implementam um outro tipo de DNS, denominado forwarder (reencaminhador), como forma de evitar a exposição direta de seus autoritativos, na Internet. Elas recuam os servidores para trás do firewall e colocam o reencaminhador em uma DMZ, por exemplo. Trataremos desse tipo de servidor de DNS, em outra oportunidade.

Imperdível, no e-learning do RIPE NCC (o RIR europeu), [2], sobre como se relacionam os dois tipos de DNS tratados acima, os resolvedores clientes e os servidores root.

[1] Dan Kaminsky, Sobre envenamento do DNS e artigos correlatos.
[2] RIPE-NCC, DNS Basics.

DNSSEC II

O Registro.br, acaba de colocar no ar, uma ferramenta denominada DNSSHIM – DNS Secure Hidden Master, que promete facilitar nossa vida. Para quem possui uma topologia equivalente à mostrada aqui, certamente ficará agradecido. O melhor a fazer é testar a ferramenta e, esperar um pouco mais, pelo Free DNSSEC hosting anunciado na lista dnssec-deployment. Também, é de se esperar algumas mudanças para tornar o uso popular: “We don’t expect people to implement clients for it, we are providing a library and a shell like client for them.”, escreve o Frederico Neves e, na sequência ele ainda diz: “… So their provisioning system will talk EPP with the registry and the “simple” protocol with the DNS hosting back-end (DNSSHIM), instead of the hundreds of scripts magics they currently does…”. Essa última, a melhor velha notícia [3]. O Registro.br, nota-se pelas mensagens nas listas internacionais, faz inveja a outos NIRs do mundo. Eis as referências para o DNSSHIM, que inclui uma lista de debates:

[1] http://registro.br/dnsshim/.
[2] https://eng.registro.br/mailman/listinfo/dnsshim.
[3] libepp-nicbr: Biblioteca para cliente EPP do NIC.br.

Bloqueando ou censurando domínios (Bind e Unbound)

Últimas atualizações: 02/06/2009 – 10:33

Introdução

Dia 18/05/2009, a Abranet, recebeu uma notificação judicial para bloquear uma série de domínios relacionados com pornografia infantil. Esse artigo dá uma dica sumária de como fazer isso, usando servidores de nomes. O uso dos servidores de nomes elimina a preocupação de estabelecer os bloqueios (ou censuras) em equipamentos de borda (roteadores, firewall, entre outros), como inicialmente pensei em fazer, quando perguntaram-me como. Cheguei a passar uma mensagem na lista da Abranet solicitando idéias aos participantes. Os equipamentos de borda não são muito hábeis para tratar domínios, como sabemos. Boa parte da relação de dominios apresentados à Abranet, estavam hospedados no Google. Mas, acabei eu mesmo respondendo meu próprio e-mail indicando a referência [1], que aponta uma solução simples e imediata.

Coincidentemente, um dos colaboradores da Pegasus me ligou, antes da mensagem da Abranet, abordando questão semelhante, em um cenário ampliado. Sua preocupação estava voltada para a demanda de seus clientes em censurar sítios da Internet, com o objetivo principal de manter funcionários e familiares, longe das armadilhas preparadas, geralmente em mensagens (“malware”, por exemplo) e, principalmene, longe de sítios indesejáveis. O cliente mal avisado sobrecarrega a rede interna de uma empresa ou provedor, quando algum programa de má-fé se instala em seu equipamento vulnerável. Também, gera constrangimentos para a empresa ou o provedor, que estão sempre sendo solicitados por terceiros (os CERTs, principalmente), a tomarem providências em relação a máquinas comprometidas de seus usuários.

Ponderações sobre o projeto

Conversa vai e conversa vem, com outros técnicos e amigos levaram-me a conduzir um experimento tendo como base a solução simples proposta em [1], um pouco mais ampliada. Experiencia bem sucedida e, as convesas, conduziram-me às seguintes abordagens e questões, que não se esgotam, por si:

1. O usuário dos servidores de nomes da rede deve ser informado porque o domínio não estava acessível.
2. Manter o DNSSEC intocável.
3. Somente os recursivos devem ser alterados. Os autoritativos continuam exercendo o papel a eles destinado, de somente exibirem as zonas da rede. Os dominios censurados são respondidos com autoridade somente para as respectivas redes internas.
4. Fácil utilização e, imediata disponibilidade, relativos ao bloqueio ou censura.
5. Os domínios devem ser classificados e sub-classificados (2 níveis): malware, pornografia, pornografia infantil, etc.
6. Manter histórico das atividades, por domínio, rede, segmento de rede e cliente.
7. Aplicável hierarquicamente, no sentido de que dominios são bloqueados ou censurados pela administração da rede, pelo administrador de cada segmento de rede e por seus respectivos clientes. E o processo deve permitir a reversibilidade.
8. Deve o cliente ser impedido de usar servidores recursivos externos (por exemplo, o openDNS)?
9. A idéia deve ser exposta no sentido de permitir que servidores extenos à rede a implementassem?
10. Se a resposta à questão anterior for sim, um outro nível hierárquico deve ser implementado?

A resposta ao item 9 é não e responde portanto o item 10. O item 8 foi deixado para cada rede decidir e, a solução está associada aos equipamentos de borda. Para a implementação escolheu-se a linguagem Python. A justificativa pela Python se deu pelo fato da TeleSA ter nos oferecido, como hospedeiro, a base de conhecimento do Sistema FaleOK e do VoIP Completo, implementada sob o Zope 3. Por outro lado há um conjunto de ferramentas na Python para trabalhar com DNS (unbound, principalmente) e DNSSEC .

O projeto envolvendo o pessoal de engenharia de software está em desenvolvimento. Será divulgado, para que possa ser implementado por redes de terceiros (item 9), exigência da TeleSA, que tem fornecido sitemático apoio à Infraestrutura da Internet de seus parceiros e disponibilizou sua equipe de desenvolvimento, para o desenho da proposta.

Considerações sobre a implementação

Além dos servidores recursivos, o Apache (2.2), também está envolvido. Em etapas, a implementação, supondo que o dominio a ser bloqueado é o exemplo.com.br. Suponha, ainda, a topologia de servidores de DNS conforme descrita aqui e o dominio para redirecionamento é o pegasus.sec3.br, já com DNSSEC. Embora os exemplos abaixo estejam aplicados a um único domínio a ser censurado, eles podem ser extendidos para mais de um domínio. Automatizadas ou não, as etapas estão descritas para serem feitas manualmente.

Etapa 1 (Bind): Criar a zona de redirecionamento para os dominios censurados, no master.

Estamos, nesse caso, seguindo a proposta em [1] com pequenas modificações. Para isto, criamos uma zona denominada censurado, simplesmente assim:

$TTL 1w @ IN SOA sn01.pegasus.sec3.br. suporte.pegasus.sec3.br. (      2008070308 ; Versao      3600       ; refresh (1 hora)      1800       ; retry (30 minutos)      604800     ; expire (7 dias)      1800 )     ; default TTL (30 minutos)      IN NS sn01.pegasus.sec3.br.      IN NS sn02.pegasus.sec3.br.      IN NS sn03.pegasus.sec3.br.      IN NS sn04.pegasus.sec3.br.      IN NS sn05.pegasus.sec3.br.      IN NS sn06.pegasus.sec3.br.      IN A 192.168.1.1 www IN CNAME censurado.

Etapa 2 (Bind): Criar a referência à zonas do domínio de redirecionamento e para o exemplo.com.br, no master.

Para facilitar o manuseio futuro, manual ou não, adicionamos no named.conf:

. . . include “/algum_caminho_de_diretorio/includes/censurado.inc”; . . .

Como estamos falando do master, geralmente escondido, não há necessidade de usar “view”. Em seguida, construimos o censurado.inc, com as referêncas às zonas censurado, exemplo.com.br e, todas os domínios que desejamos censurar, assim:

zone “censurado” {   type master;   file “diretorio_da_zona/censurado.zone”; }; zone “exemplo.com.br” {   type master;   file “diretorio_da_zona/censurado.zone”; };

Qualquer domínio a ser censurado será referenciado como o exemplo.com.br, isto é, sempre apontando para a zona censurado.zone.

Etapa 3 (Bind): Criar a referência à zonas do domínio de redirecionamento e para o exemplo.com.br, nos secundários.

Considere que a resposta ao domínio exemplo.com.br é somente para IPs da rede. Assim, sua implementação nos Binds secundários, deverá ser feita sob um “view” recursivo, exclusivo para tais IPs, no named.conf. A seguir construa as referências no include censurado.inc, para os respectivos primáros.

zone “censurado” {   type slave;   file “diretorio_da_zona/censurado.zone”;   masters {     IP_do_primario;   }; }; zone “exemplo.com.br” {   type slave;   file “zonas/censurado.zone”;   masters {     IP_do_primario;   }; };

Etapa 4 (Unbound): Garantir que os recursivos façam o redirecionameto do domínio.

No Unbound, a solução é mais simples. Basta acrescentar as linhas seguintes, ao unbound.conf, onde as duas últimas devem ser repetidas para cada domínio censurado:

local-zone: “censurado” redirect
local-data: “censurardo A IP_do_servidor_Apache”
local-zone: “exemplo.com.br” redirect
local-data: “exemplo.com.br A IP_do_servidor_Apache”

O Unbound irá redirecionar tanto o exemplo.com.br como o www.exemplo.com.br para o Servidor Apache.

Etapa 5 (Apache): Preparando servidor Apache para o receber o redirecionamento.

A configuração, também é bastante simples, dependendo da implementação do Apache. No meu caso, o Apache possui VirtualHost e um domínio principal. Então, dentro do VirtualHost do domínio principal, coloquei:

Redirect permanent / http://www.pegasus.sec3.br/

Finalmente, no arquivo httpd.conf, ou equivalente, inseri a seguinte indicação para o domínio censurado:

ServerAdmin email_do_administrador
DocumentRoot “/data/wwwroot/www.pegasus.sec3.br”
ServerName www.pegasus.sec3.br
ServerAlias www.censurado www.pegasus.sec3.br
ServerAlias censurado www.pegasus.sec3.br
AddType application/x-httpd-php .php
ErrorLog …
CustomLog …

Comentários adicionais sobre a implementação

• Consider-se a configuração do bind supondo-o um servidor recursivo ou, recursivo e autoritativo. Nesse caso, o recursivo é um view acessível somente à rede interna.
• Os comentários da Introdução e o item que a seguem mostram que há muitas outras aplicações além das restrições impostas pela Justiça. Criatividade, inovaçao e sugestões podem melhorar as propostas.
• Para quem usa servidores de DNS com IPs não públicos, certos cuidados não são necessários, tornando mais simples, ainda, a implementação.
• Há diversas formas de redirecioamento no Apache. Um bom começo pode ser visto em [2] e nos manuais do Apache, em particular sobre o mod_rewrite, em [3].

Referências

[1] Simpson, J. M., Blocking domain names with bind.
[2] yolinux.com, Apache Web Server Configuration for Web Site Redirection.
[3] Apache 2.2, Módulo mod_rewrite.

Soluções simples para melhorar a Internet

Algumas coisas básicas, me incomodam como administrador de sistemas associados à Internet. E nada posso fazer, pois depende de atitudes de terceiros. A maior parte delas, depende dos RIRs ou do nosso NIR. Abaixo, algumas sugestões que, na medida do possível e por sugestões de colaboradores, serão incrementadas. Nenhuma delas agride o espírito da Internet.

1. O reverso deve ser obrigatório. Quem não tiver o reverso deve ser punido.
2. O Registro.br deve permitir a renúncia de blocos IPs, pelos ID Técnicos. Essa facilidade é pré-requisito para a proposta do item anterior. Atualmente, os responsáveis técnicos por blocos de IPs de terceiros, não conseguem se livrar deles, a partir do momento que não são mais responsáveis.
3. O DNSSEC deve ser obrigatório para todos as DPNs. Quem não fizer isso, deverá ser punido. Quem não atualizar as chaves na época do vencimento, também será punido. O Registro.br deveria indicar nos avisos em que houver quebra de respostas no DNSSEC, QUAIS os servidores de DNS envolvidos, assim como ele fazia quando não havia respostas de servidores de DNS. Esse problema não é grave para quem possui, somente dois servidores de DNS, mas é complicado para quem possui o máximo permitido (5). Se a identificação do servidor específico de DNS não for possível, por alguma razão, então que informe aos administradores que eles devem cuidar dessa questão, monitorando cada um deles. O estado do domínio com DNSSEC implementado, também poderia aparecer por lá, o que nos ajudaria bastante.
4. ASN deve ser liberado, livremente. Para quem provar que tem uma rede. As restrições somente para a liberação de blocos IPv4. Blocos IPv6 deveriam ser liberados para os ASs, mesmo sem IPv4. Isso anteciparia as implementações de IPv6. Muitos ASs com IPv6 estimulariam os fornecedores a implementar tal funcionalidade, já que o mercado estaria disponível. Por outro lado, o LACNIC deveria rever os preços relativos ao IPv6, que pretende cobrar no futuro.
5. Instalação de uma base do IRR espelhada na RADB. De graça e com suporte a IPv6! E o Nic.br (ou LACNIC) pode criar, à semelhança do RIPE NCC, orientações de uso, inclusive das ferramentas disponíveis (IRRTools, p. ex.).
6. Propostas para o tratamento das punições. Sempre haverá avisos, antecedendo a punição. As punições, após os avisos, não devem ser brandas. Os critérios de punição deveriam considerar a reincidência. Quem possui um ID Técnico, pressupõe-se que seja um administrador, conhecedor dos fundamentos da Internet. Os avisos e punições, podem se estender aos outros IDs.

Tráfego, “peering”, trânsito e transporte

Reformulei meu artigo sobre Sistemas Autônomos, Empresas Autônomas, escrito há três anos. Espero ter esclarecido a definição de tráfego, posta no Glossário, através de uma simples fórmula aritmética, não quantitativa, ainda: trafego = transito + peering + transporte, para transito >= 0, transporte >= 0, peering >= 0.

Internet Routing Register (IRR)

Introdução

Alguns de meus amigos que trabalham com infraestrutura da Internet e administradores de redes, em particular, usam com uma certa frequência, o CIDR-Report. Pessoalmente, mantenho-o, permanentemente, no meu desktop. O CIDR-Report gerou um equívoco para estes amigos e para mim, também. O problema é que quando se pesquisava o CIDR-Report para qualquer ASN que tenha sido destinado pelo Nic.br (após a transferência das funções pelo LACNIC), aparecia a mensagem no cabeçalho “–No AS Description–“. Todos diziam que faltava o registro do AS no RADB, a principal base de dados do Internet Routing Register (IRR). E eu, repetia isso para outros. Então, passei a procurar uma maneira de registrar os ASs que administro no RADB. O primeiro impasse, nesta tentativa, foi o fato do registro no RADB custar US$495.00/ano. Uma pergunta do !3runo, na GTER, sobre o ALTDB, deu a pista para o registro do AS no RADB, em bases que eram espelhadas. Minhas tentativas de registro no ALTDB foram de pura frustação. Mas, mesmo percebendo que muitos já tinham registrado no ALTDB acabei usando os serviços do pessoal da Infraestrutura.IP. Em menos de um dia, os ASs estavam na RADB. Sem a anualidade! Recentemente (agosto/2009) a Pegasus implementou a primeira base de dados IRR no Brasil: http://irr.redepegasus.net.br.

Logo fui no CIDR-Report e percebi que, o No AS description, continuava lá. Esperei alguns dias e nada. Logo percebi que não era a inexistência no RADB que gerava a mensagem. Então fiz o que deveria ter feito desde o início: entender o IRR. A conclusão foi de que é uma peça muito importante para a consistência de rotas publicadas pelos ASs, em particular, para detetar o MOAS (acrônimo de Multiple Origin Autonomous Systems), automaticamente. Os conflitos de MOAS acontecem pelo simples problema de que um AS pode “injetar” qualquer prefixo, por configuração correta, incorreta ou maliciosamente^*. A história do No AS description deixarei para o final.

O que é o IRR e para que serve?

Existem inúmeras definições na literatura que pesquisei. Uma delas diz que IRR é um conjunto de bases de dados que permitem ao BGP, documentar suas rotas e políticas de roteamento, com o objetivo de dar consistência às configurações de um roteador. Dizia ainda que o BGP fazia isto “conversando” em uma linguagem chamada RPSL. É a linguagem comum dos whois, jwhois, etc. E a mesma que motivou a construção de uma autômata de pilha em artigo que pode ser visto aqui.

Nada de errado com a definição acima. Mas não era muito precisa. Cheguei então, à página oficial do IRR, em [5]. Há várias informações importantes, incluindo as bases de dados ligadas ao RADB. A relação das bases de dados é quase uma piada, mostrando que alguma coisa não estava sendo levada a sério. A última vez que estive por lá foi no mes de março/2009.

Mais á frente, percebi que muitos RIRs possuem ofertas de bases de IRR, espelhadas no RADB, para os usuários de sua região, mas não vi nada em relação ao LACNIC, exceto propostas, inclusive do Nic.br. Aqui, uma notícia do LACNIC a respeito. O APINIC [6] tem o APIRR e é capitaneado pelo Japão, também com um serviço IRR para seus usuários, como pode ser visto em [3].

Europa (RIPE) e Japão (membro do RIPE), levaram a sério o IRR. E, principalmente no Japão, estão os trabalhos mais consistentes sobre IRR. Em um dos trabalhos que li, [7], uma definição completa sobre o que é, e para que serve o IRR reproduzo, no original: “The Internet Routing Registry (IRR) … is a large distributed repository of information, containing the routing policies of many of the networks that compose the Internet. The IRR was born about ten years ago with the main purpose to promote stability, consistency, and security of the global Internet routing. It consists of several registries that are maintained on a voluntary basis. The routing policies are expressed in the Routing Policy Specification Language (RPSL) … The IRR can be used by operators to look up peering agreements, to study optimal policies, and to (possibly automatically) configure routers.”

Logo a seguir, o trabalho ressalta: “There is a wide discussion about the current role of the IRR … Some people consider it outdated and almost useless. Others have put in evidence its importance to understand the Internet routing and that it contains unique and significant information. Anyway, it is undeniable that the IRR keeps on being fed by many operators, that useful tools have been developed to deal with the IRR (see, e.g., IRRToolSet [3]), …”.

Queria chegar, na citação acima, no IRRToolSet. Acabei implementando a IRRToolSet em FreeBSD e tem realmente algumas ferramentas interessantes. Por exemplo a peval, com a qual descobri que um punhado de gente boa publica blocos /24. Aos montões! Outra que seria interessante, é a prtraceroute, que inclui o ASN em cada etapa do traceroute. Infelizmente, foi escrita para acessar uma referência que não está disponível para nós. Como foi escrito pelo van Jacobson, não iremos fazer mais comentários. Deve ter tido suas razões. Sobre a instalação do IRRToolSet, veja aqui. Há uma lista pouco movimentada, mas interessante, que pode ser assinada aqui.

A história do –No AS Description–, no CIDR-Report

Eu não percebi, de imediato, que a mensagem, tecnicamente incômoda, do CIDR-Report somente ocorria para os ASs distribuídos pelo Nic.br, a partir da mudança do LACNIC, em meados de 2007. Escrevi ao LACNIC a respeito do problema e a resposta que obtive não foi muito clara e resolvi escrever para o Geoff Huston, responsável pelo CIDR-Report. Ele me respondeu de pronto, dizendo que o problema estava relacionado com o jwhois, que o LACNIC não estava autorizando a consulta em suas bases de whois. Três ou quatro mensagens se seguiram para o LACNIC, sendo que na penúltima, finalmente, percebi que o problema eram somente os atuais ASs liberados pelo Nic.br. Por fim, o LACNIC em uma das respostas informou que o problema do proxy seria resolvido nos primeiros 4 meses de 2010, já que o CIDR-Report não era tão importante assim, para os administradores de sistemas.

Mais recentemente, ando desconfiado que outros além do CIDR-Report estão com o mesmo problema. Por exemplo, o Google Analytics. A grande maioria dos acessos de rede (93%), são registrados como comite gestor da internet no brasil.

Últimas notícias sobre IRRToolSet

Há cerca de dois ou três dias atrás (a partir de hoje, 15/05/2009) tem havido um debate interessante sobre as ferramentas do IRRToolSet. Em particular, val a pena ver aqui, a descrição que Nick Hilliard, faz sobre cada uma delas. Para frente e para trás, na sequência dessa mensagem o debate é interessante.

^* Usar a base do IRR para detetar conflitos de MOAS, não é a única técnica disponível. Há uma corrente recomendando o bgp.in.addr.arpa.. Esse grupo, provavelmente está preocupado com a falta de confiabilidade das informações armazenadas na RADB. Como elas são atualizadas pelos próprios responsáveis pelos ASs, observa-se um certo descuido. Entretanto, nota-se que o pessoal que faz peering ou pretende fazer, está cuidando de forma correta das suas informações lá armazenadas.

Referências
[1] Siganos G., Faloutsos, M., Analazing BGP policies: methodology and tool, INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, Vol. 3 (2004), pp. 1640-1651 vol.3.
[2] Alaettinoglu C. et alii, Routing Policy Specification Language (RPSL), The Internet Society, RFC2622, 1999.
[3] JPNIC IRR (JPIRR) Operation Policies and User Guideline, Japan Network Information Center, IRR-Planning Team, July 2003.
[4] Nagahashi, K., Esaki, H. & Murai, J., An integrity check for the conflit Origin AS Prefixes in the inter-domain routing, IEICE Trans. Commun., Vol. E86-B, no. 2, February 2003.
[5] Internet Routing Register
[6] APIRR resource guide
[7] Battista, G. di, Refice, T., Rimondini, M., How to Extract BGP Peering Information from the Internet Routing Registry

Últimas atualizações:
29/04/2009 09:00

Linha Defensiva, o selo site seguro e o Teorema da Parada

Quero reparar um pequeno equívoco, de minha parte. O Fabio Assolin, em mensagem na lista GTS, em novembro de 2008, (aqui), divulgou uma iniciativa da Linha Defensiva¹ relativa à criação de um logo com o texto “Este sáitio é segúrio! Eu agarântio!”, associado à conhecida figura do Sô Cleyson. Algumas pequenas reações vieram em seguida: a, b (minha), c, d, e, f, g e outras. Não estou preocupado em entrar no mérito das respostas, mas sim adicionar um argumento, para assegurar, que o ponto de vista da Linha Defensiva está correto e preciso. Ao mesmo tempo, na medida da disponibilidade de meu tempo irei colocar a figura abaixo e suas variações, nos meus sítios:

Achei que a Linha Defensiva foi pragmática em mudar o logo. Na realidade usou o bom senso e exibiu uma bela noção de objetividade em relação ao resultado desejado.

A abordagem que segue, está disponível em prosa e vastamente, se fizermos uma pesquisa por “teorema da parada”. Uma interessante, clara e didática prosa, em abordagens de segurança, está em Duklin². Em verso, a bela e famosa prova, do Prof. Geoffrey K. Pullum³.

A questão está em uma simples pergunta, portanto: é possível desenvolver um algoritmo (ou programa) que seja capaz de garantir que um sítio é seguro? Mais simples é a resposta: não!^*.

Duklin² é claríssimo e incisivo: Nenhum programa pode dizer (ou explicar) o que um outro programa poderia fazer.

HTML ou qualquer recurso derivado e usado para desenvolver sítios na Web (PHP, ASP, Java, etc.) são linguagens de programação.

Linguagens de programação são sistemas formais. Gödel, por volta de 1932, ao responder a um dos famosos 23 problemas de Hilbert (apresentados em 8 de agosto de 1900, no Congresso Internacional de Matemátcia em Paris como um desafio para o novo século que estava iniciando), provou que sistemas formais são inconsistentes e incompletos. Por exemplo, a aritmética (ou matemática) é um sistema formal, logo … Na realidade, a prova de Gödel foi sobre a aritmética. Pouco tempo depois, surgiu Turing, com sua famosa Máquina de Turing que fez Alonso Church propor a tese, em linguagem coloquial: um algoritmo é computável se ele for executável em uma Máquina de Turing. Na sequência surgiu, finalmente, o problema da Parada: é possivel executar em uma Máquina de Turing, um programa que receba como entrada um outro programa e suas respectivas entradas? Executar, no sentido de parar, após um tempo finito. A resposta é não^*, como já sabemos.

Com esta abordagem informativa, mas cheia de referências, nas quais o formalismo pode ser levantado, a Linha Defensiva está correta! E, quem estiver pagando para colocar um logo de sítio seguro em suas páginas de Web ou para avaliar sua segurança está, literalmente, caíndo no conto do vigário.

Uma bela, completa e didática descrição sobre o trabalho de Gödel e outros, pode ser vista em [4].

Referências:
[1] Linha Defensiva, Este site é seguro. Não Duvide.
[2] Duklin, P., CAN STRONG AUHENTICATION SORT OUT PHISHING AND FRAUD?, Virus Bulletin Conference, October 2006.
[3] Pullum, G. K., SCOOPING THE LOOP SNOOPER A proof that the Halting Problem is undecidable, School of Philosophy, Psychology and Language Sciences, University of Edinburgh, 2008.
[4] Singh, S., O último teorema de Fermat: a história do enigma que confundiu as maiores mentes do mundo durante 358 anos, Record, 2004.

* No sentido de indecidível.

DNSSEC I

O Nic.br está oferecendo um DPN para exercícios com o DNSSEC. Trata-se do sec3.br. É de graça e vale a pena pegar um domínio. Vou exibir minha experiência com o DNSSEC usando o pegasus.sec3.br que peguei por lá.

Veja aqui boas referências iniciais e na apresentação Tutorial DNSSEC, que parece estar sempre atualizada dá para completar o exercício sem problemas. Uma detalhada referência está em DNSSEC HOWTO, a tutorial in disguise. Há um e-mail de suporte. O pouco que usei desse suporte levou-me a imaginar que é melhor saber tudo sobre DNSSEC antes de solicitá-lo.

Há um conjunto de ferramentas interessantes em DNSSEC Tools. Quando houver bastante tempo disponível, vale a pena dar uma estudada.

Suponhamos que a zona do pegasus.sec3.br esteja assim definida, no arquivo pegasus.sec3.br.zone:

$TTL 1d @ IN SOA sn01.pegasus.sec3.br. suporte.pegasus.sec3.br. (      2008070308 ; Versao      3600       ; refresh (1 hora)      1800       ; retry (30 minutos)      604800     ; expire (7 dias)      1800 )     ; default TTL (30 minutos)      IN NS sn01.pegasus.sec3.br.      IN NS sn02.pegasus.sec3.br      IN NS sn03.pegasus.sec3.br.      IN NS sn04.pegasus.sec3.br.      IN NS sn05.pegasus.sec3.br.      IN NS sn06.pegasus.sec3.br.      IN A 192.168.1.1      IN MX 0 pegasus.sec3.br. pegasus.sec3.br. IN TXT “v=spf1 a mx -all” www IN CNAME pegasus.sec3.br. mcw IN CNAME pegasus.sec3.br. ftp IN CNAME pegasus.sec3.br. sn01 IN A 172.16.2.2 sn02 IN A 10.0.1.1 sn03 IN A 10.1.1.1 sn04 IN A 10.2.1.1 sn05 IN A 10.3.1.1 sn06 IN A 10.4.1.1

Há 7 etapas envolvidas no processo de preparar uma zona para o DNSSEC:

1. Geração da chave KSK: Esta operação é executada uma única vez, desde que os resultados sejam preservados, pois as chaves nunca expiram. Executei o seguinte comando:

   
   dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE pegasus.sec3.br
   

   Como resultado, se separamos um diretório para cada zona, veremos os respectivos arquivos da chave pública e privativa:

   
   [root@testejb pegasus.sec3.br]# ls
   Kpegasus.sec3.br.+005+07609.key Kpegasus.sec3.br.zone.+005+07609.private
   pegasus.sec3.br.zone

2. Incluir o arquivo da chave pública KSK no arquivo de zona: Também, somente executada uma única vez. Inclua no final do arquivo de zona:

   
   
   ;; KSKs
   $include Kpegasus.sec3.+005+23658.key
   

3. Assinar a zona: Esta operação deve ser executada à primeira vez logo após a inclusão do arquivo com a chave pública KSK e todas as vezes em que houver alteração na zona e/ou vencimento da assinatura. Portanto, guarde-o (eu guardo em um .txt no próprio diretório da zona). Executei o comando, onde -e 20090630200000 é a data de vencimento das chaves:

   
   dnssec-signzone -z -e 20090630200000 -o pegasus.sec3.br pegasus.sec3.br.zone

4. Tratar os registros DS: Ao terminar a assinatura da zona o arquivo onde estão os registros DS é criado: dsset-pegasus.sec3.br.. Pegue as duas linhas desse arquivo e inclua no arquivo de zona pegasus.sec3.br.zone, LOGO após o último NS. Altere o sequencial da zona e assine a zona novamente, com o mesmo comando acima. Veja que irá precisar de incluir (à primeira vez) o registro DS no Registro.br. O conteúdo do arquivo dsset-pegasus.sec3.br., é mostrado abaixo e em vermelho os respectivos dados que deverão ser colocados no Registro DS 1 da zona, no Registro.br.

   pegasus.sec3.br. IN DS 22852 5 1 5773872FD2E2017C0007C8B6025F708DAB747CC2
   pegasus.sec3.br. IN DS 22852 5 2 934502EF4E4AE1F182A87F9370D86A184AEEF4C7D323AEDC80DD0FD2 BFA8C868.

5. Assine novamente a zona: Após colocar os registros DSs, no arquivo pegasus.sec3.br.zone assine novamente a zona com o mesmo comando que usou para assinar á primeira vez , ou seja:

   dnssec-signzone -z -e 20090630200000 -o pegasus.sec3.br pegasus.sec3.br.zone. Observação: Não é necessário alterar o sequencial.

6. Altere a referência do arquivo de zona no named.conf: Fique atento para que o novo arquivo de zona termine com .signed. Não é mandatório, mas o .signed permite, imediatamente, saber que a zona foi assinada. Faço isso, no master e em todos os secundários autoritativos. Reinicie os servidores de DNS, na ordem necessária.

7. Alterar o registro DS do domínio, no Registro.br: Isso deve ser feito à primeira vez, somente. A figura abaixo mostra os campos a serem alterados, com base no conteúdo do arquivo dsset-pegasus.sec3.br., exibido no item 4, acima. Veja a ilustração na figura abaixo.

   Figura que ilustra os campos preenchidos, da zona, no Registro.br:
   

8. Alterando a zona: Ao fazer uma alteração em zona já assinada, altere o sequencial, comente as duas linhas com os registros DS, e reassine a zona, como feito acima. Em seguida, retire os comentários colocados nas linhas dos registros DS e assine novamente a zona (não precisa alterar o sequencial, nessa etapa.

Também, incluo meus domínios assinados, aqui, após a publicação do Registro.br.

DNS: Um exemplo de topologia

DNS, ninguém tem dúvida representa para a Internet, o mesmo que o ar para o ser humano. Embora esse fato seja reconhecido, as preocupações com os servidores de DNS são relegadas a um último plano. Eis alguns exemplos do que se vê por ai, inclusive em provedores de médio e grande porte:

1. Usam dois servidores de DNS (o mínimo exigido), em uma mesma máquina.
   
2. Usam dois servidores de DNS, na mesma rede.
   
3. Não se preocupam com o TTL das zonas.
   
4. Ignoram a importância do reverso, achando que o reverso reproduz uma transparência indesejável, o que é uma falácia.
   
5. Não estão preocupados com o DNSSEC. Qualquer dia desses, o Registro.br irá dar um prazo para implementar o DNSSEC (espera-se).

Seria bom pensar a respeito dos itens acima. O Itinera, desde seu inicio segue a seguinte topologia em seus servidores de DNS:

Antes da primeira versão do Itinera, a topologia acima existia e mantida manualmente. Nas primeiras versões do Itinera, não se usava o conceito de base de dados. Agora, com o Itinera ad futurum as bases de dados são usadas para cada grupo de servidores. A topologia acima, com ou sem base de dados pode, sem muito trabalho, existir com manutenção manual, trazendo grandes vantagens, em particular sob o ponto de vista da segurança. Mesmo que se venha a usar o DNSSEC, o qual exigirá um esforço de manutenção mais sistemática nos servidores (há ferramentas disponíveis para tratar o DNSSEC manualmente.

Eis algumas características importantes, que permitem implementações de variações do modelo acima:

• É usado o BIND nos autoritativos e Unbound nos recursivos. Para ambos, há uma preocupação, firme, em manter atualizado com a última versão.
  
• Todos servidores autoritativos estão rodando em FreeBSD. Nem todos os recursivos estão sob FreeBSD.
  
• Os servidores primários (P) são em número de dois, para permitir redundância. São atualizados via rsync.
  
• Os servidores primários são escondidos, aos quais, somente os servidores do tipo master (M) possuem acesso. Além das restrições naturais do BIND, são impostas regras de “firewall” locais e nos “gateways”. Isso torna o conjunto seguro? Provavelmente, não. Mas torna-o menos vulnerável.
  
• Todos os servidores estão em redes distintas e remotamente localizados, exceto os recursivos (R), distribuídos a critério dos donos das redes que usam o Itinera.
  
• Os servidores M, embora redundantes, não estão disponíveis. Somente um cuida dos servidores autoritativos (A).
  
• Não há base de dados local ativa, em nenhum servidor (PE, M, A ou R). Há replicação da base de dados, mantendo uma simples cópia atualizada diante de qualquer alteração.
  
• Todo o tráfego na direção das bases de dados e suas cópias, usa openSSL.
  
• A cada duas horas, se houve alteração em algum dos servidores um backup é automaticamente acionado, sobre o servidor que sofreu a alteração, exceto nos A e R.
  
• Todos os servidores são monitorados, para efeito de verificação em suas atividades.
  
• Não há estatísticas de tráfego e/ou utilização geral do servidor. Está na pauta para incluir. Periodicamente, é feito manualmente, usando as ferramentas do BIND e outras disponíveis.
  
• Embora testado, não foi implementado o procedimento automático de gerenciamento do DNSSEC. Entretanto, toda a estrutura dos PEs foram alteradas para facilitar a implementação do DNSSEC. Em outro artigo, falarei sobre o DNSSEC, especificamente.
  
• Todos os servidores estão com NTP. Três deles integrados aos servidores do Nic.br. O restante são clientes destes três e servem como clientes para máquinas das redes locais.

Todos os IPs do mundo (2)

Depois de conhecermos as atualizações dos IPs atribuídos para todo o mundo (em 1), o problema é descobrir de forma automática da real alocação de um determinado IP e qual seu responsável. Por outro lado queremos saber (também de forma automática), se um domínio existe e a quem ele pertence.

Uma das mais importantes ferramentas da Internet para obter tais informações é o whois. Um bom começo está na referência [2]. Tamanha importância, em mesmo grau, equivalente desprezo ao whois por aqueles que governam a Internet, aparentemente. Vejam que a referência [2], não é atualizada desde 2004.

Um dos melhores clientes do whois, que tive oportunidade de experimentar foi o do FreeBSD (7.1). Provavelmente é equivalente a qualquer sistema baseado em Unix. Para ele ser eficaz é bom ter a relação final da referência [2].

Ao Itinera ad futurum, o que interssa é um procedimento automático. Portanto, usaremos o Net_Whois do Pear, como ilustração. A experiência é fantástica!

O Net_Whois, em sua versão 1.0 possui algumas deficiências. Cheguei a localizar duas. Uma delas já há uma sugestão para alterar e trata-se de permitir o uso da linha de comando do whois no Unix. A outra, é o fato dele trazer uma cadeia de caracteres com LF e CR. Se alguém precisar da tabela ASCII, um bom local é aqui, na Wikipedia. Vejamos uma cadeia de caracteres resultante do Net_Whois:

% Copyright (c) Nic.br % The use of the data below is only permitted as described in % full by the terms of use (http://registro.br/termo/en.html), % being prohibited its distribution, comercialization or % reproduction, in particular, to use it for advertising or % any similar purpose. % 2009-01-06 15:11:33 (BRST -02:00) domain: nic.br owner: Núcleo de Informação e Coordenação do Ponto BR ownerid: 005.506.560/0001-36 responsible: Demi Getschko country: BR owner-c: FAN admin-c: FAN tech-c: FAN billing-c: FAN nserver: a.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: b.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: c.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: d.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: e.dns.br nsstat: 20090106 AA nslastaa: 20090106 dsrecord: 57436 RSA/SHA-1 CCB7D717A8868B8739A78FEC8FB60E62EBE2D89B dsstatus: 20090106 DSOK dslastok: 20090106 created: 19970711 #46903 changed: 20070606 status: published nic-hdl-br: FAN person: Frederico Augusto de Carvalho Neves e-mail: fneves@registro.br created: 19971217 changed: 20030721 % Security and mail abuse issues should also be addressed to % cert.br, http://www.cert.br/, respectivelly to cert@cert.br % and mail-abuse@cert.br % % whois.registro.br accepts only direct match queries. Types % of queries are: domain (.br), ticket, provider, ID, CIDR % block, IP and ASN.

Esse é um resultado vindo do whois.nic.br, um dos mais consistentes whois do mundo.

Uma análise mais detalhada nos indica que % antecede um comentário. Há os chamados objetos do whois cujo conteúdo são apêndices de palavras chaves, tais como domain:, nsstat: e outras. Todas as palavras chaves terminam com um :. O conteúdo de um objeto termina quando começa um outro objeto ou com, novamente, o %. E, um comentário termina com o final da cadeia de caracteres. Quem sabe, o conteúdo de um objeto também termina com o final da cadeia.

Nosso objetivo é desenvolver um algorítmo para reconhecer o que é comentário, o que é objeto e seu respectivo conteúdo. Se pensarmos em um algorítmo para transformar a cadeia recebida pelo whois em algo organizado como o whois do Unix, o problema fica resolvido. Para ser mais claro, desejamos transformar a cadeia no seguinte texto organizado:

% Copyright (c) Nic.br % The use of the data below is only permitted as described in % full by the terms of use (http://registro.br/termo/en.html), % being prohibited its distribution, comercialization or % reproduction, in particular, to use it for advertising or % any similar purpose. % 2009-01-06 15:11:33 (BRST -02:00) domain: nic.br owner: Núcleo de Informação e Coordenação do Ponto BR ownerid: 005.506.560/0001-36 responsible: Demi Getschko country: BR owner-c: FAN admin-c: FAN tech-c: FAN billing-c: FAN nserver: a.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: b.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: c.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: d.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: e.dns.br nsstat: 20090106 AA nslastaa: 20090106 dsrecord: 57436 RSA/SHA-1 CCB7D717A8868B8739A78FEC8FB60E62EBE2D89B dsstatus: 20090106 DSOK dslastok: 20090106 created: 19970711 #46903 changed: 20070606 status: published nic-hdl-br: FAN person: Frederico Augusto de Carvalho Neves e-mail: fneves@registro.br created: 19971217 changed: 20030721 % Security and mail abuse issues should also be addressed to % cert.br, http://www.cert.br/, respectivelly to cert@cert.br % and mail-abuse@cert.br % % whois.registro.br accepts only direct match queries. Types % of queries are: domain (.br), ticket, provider, ID, CIDR % block, IP and ASN.

Um programador habilidoso talvez faça um algoritmo desses em 1 dia. Um programador experiente, com formação em Ciência da Computação (ou Engenharia da Computação), levará algumas poucas horas para criar um algoritmo eficiente e elegante. A questão de eficiência no caso da proposta acima é irrelevante, pois a cadeia resultante do whois é muito pequena para a capacidade de computação de um PC atual. Mas a elegância e clareza do algoritmo são as questões importantes para o sistema no qual ele será utilizado. O programador habilidoso, sem os fundamentos teóricos do programador experiente, provavelmente achará o algoritmo muito difícil e, certamente, tornará o sistema do qual fará parte, ineficiente.

O programador experiente usará as técnicas da Teoria dos Autômatos. Em particular, o Autômato de Pilha. Uma procura no Google, com esse título trará inúmeros referências importantes. Aplicar Autômato de Pilha no problema que temos de resolver é um exercício fascinante, da arte de programar.

Eis o algoritmo em PHP+PEAR:

<?php function imprimeLinhaEZeraPilha ($pilha) { $pilha = array_reverse($pilha); // Pilha que vira um array. $linha = ”; while (count($pilha) > 0) { $linha .= array_pop($pilha); } echo ‘<tr><td colspan=”2″><font face=”Courier new” size=”2″>’ . $linha . ‘</font></td></tr>’; return $pilha; // retorna Pilha vazia } // require_once “Net/Whois.php”; $server = “whois.nic.br”; $query = “nic.br”; $whois = new Net_Whois; // Verifica o whois $data = $whois->query($query, $server); // whois.nic.br: dominio $objetos = array(); $objetos[0] = ‘nulo:’; $objetos[1] = ‘domain:’; $objetos[2] = ‘owner:’; $objetos[3] = ‘ownerid:’; $objetos[4] = ‘responsible:’; $objetos[5] = ‘country:’; $objetos[6] = ‘owner-c:’; $objetos[7] = ‘admin-c:’; $objetos[8] = ‘tech-c:’; $objetos[9] = ‘billing-c:’; $objetos[10] = ‘nserver:’; $objetos[11] = ‘nsstat:’; $objetos[12] = ‘nslastaa:’; $objetos[13] = ‘dsrecord:’; $objetos[14] = ‘dsstatus:’; $objetos[15] = ‘dslastok:’; $objetos[16] = ‘created:’; $objetos[17] = ‘expires:’; $objetos[18] = ‘changed:’; $objetos[19] = ’status:’; $objetos[20] = ‘nic-hdl-br:’; $objetos[21] = ‘person:’; $objetos[22] = ‘e-mail:’; $objetos[23] = ‘created:’; $objetos[24] = ‘changed:’; echo ‘<table border=”0″ align=”left” cellpadding=”0″ cellspacing=”1″>’; $alvo1 = “%”; $alvo2 = “:”; $alvo3 = ” “; $pilha = array(); $pilha_auxiliar = array(); $novo_alvo1 = false; // Percorre cada elemento do string while (strlen($data) > 0) { $elemento = substr($data, 0, 1); if (ord($elemento) == 10 || ord($elemento) == 13) { $elemento = ‘ ‘; } array_push($pilha, $elemento); $data = substr($data, 1); switch ($elemento) { case $alvo1: if (!$novo_alvo1) { $novo_alvo1 = true; if (count($pilha) > 1) { array_pop($pilha); $pilha = imprimeLinhaEZeraPilha ($pilha); array_push($pilha, $elemento); } } else { array_pop($pilha); $pilha = imprimeLinhaEZeraPilha ($pilha); array_push($pilha, $elemento); $novo_alvo1 = false; } break; case $alvo2: // Desempilha o : e tudo que segue até um branco, empilhando na pilha auxiliar $elemento = array_pop($pilha); while (ord($elemento) !== ord (‘ ‘) && count($pilha) > 0) { array_push($pilha_auxiliar, $elemento); $elemento = array_pop($pilha); } // Monta string com o suposto objeto $objeto = ”; while (count($pilha_auxiliar) > 0) { $objeto .= array_pop($pilha_auxiliar); } if (!array_search($objeto, $objetos)) { // Não é um objeto, então, devolve para a pilha e continua array_push($pilha, $elemento); // Empilha o branco antes % 2008-12-14 08:56:44 (BRST -02:00) while (strlen($objeto) >= 1) { $elemento = substr($objeto, 0, 1); $objeto = substr($objeto, 1); array_push($pilha, $elemento); } } else { // É um objeto, então imprime a pilha e segue em frente após empilhar tudo que está na pilha auxiliar $pilha = imprimeLinhaEZeraPilha ($pilha); while (strlen($objeto) > 0) { $elemento = substr($objeto, 0, 1); $objeto = substr($objeto, 1); array_push($pilha, $elemento); } } break; } } if (count($pilha) > 0) { $pilha = imprimeLinhaEZeraPilha ($pilha); echo ‘<tr><td colspan=”2″><font face=”Courier new” size=”2″> </font></td></tr>’; } echo ‘</table>’; ?>

Preparando blocos de IPs para estabelecer o reverso

Ao receber um bloco de IPs no seu ASN, é preciso, imediatamente pensar nos respectivos reversos. Preferi criar os reversos para cada bloco /24. Assim, se recebo um bloco /20, digamos, abc.bc.0.0/20, procedemos assim:

1. Dividimos o bloco /20 em dois blocos /21:
   abc.bc.0.0/21
   abc.bc.8.0/21

2. Cada um dos blocos /21 em dois blocos /22:
   abc.bc.0.0/22
   abc.bc.4.0/22
   abc.bc.8.0/22
   abc.bc.12.0/22

3. Cada um dos blocos /22 em dois blocos /23:
   abc.bc.0.0/23
   abc.bc.2.0/23
   abc.bc.4.0/23
   abc.bc.6.0/23
   abc.bc.8.0/23
   abc.bc.10.0/23
   abc.bc.12.0/23
   abc.bc.14.0/23

4. E, finalmente, obter os blocos /24:
   abc.bc.0.0/24
   abc.bc.1.0/24
   abc.bc.2.0/24
   abc.bc.3.0/24
   abc.bc.4.0/24
   abc.bc.5.0/24
   abc.bc.6.0/24
   abc.bc.7.0/24
   abc.bc.8.0/24
   abc.bc.9.0/24
   abc.bc.10.0/24
   abc.bc.11.0/24
   abc.bc.12.0/24
   abc.bc.13.0/24
   abc.bc.14.0/24
   abc.bc.15.0/24

Todos os IPs do mundo (1)

Algumas vezes precisamos de informações sobre a origem de um IP específico. Em ftp://ftp.lacnic.net/pub/stats parece estar atualizado (?), ASN, IPv4, IPv6 alocados e atribuídos ao respectivo RIR: LACNIC, AFRINIC, APNIC, LACNIC e RIPNCC.

Um script, em PHP + PEAR, pode trazer isso todos os dias automaticamente, colocando-o na CRONTAB:

#!/usr/local/bin/php -q <?php require_once “PEAR.php”; require_once ‘Net/FTP.php’; $test = new Net_FTP(‘ftp.lacnic.net’, 21); $test->connect(); $test->login(‘anonymous’, ‘fulano@exemplo.com.br’); $test->cd(‘/pub/stats/lacnic/’); $test->get(‘delegated-lacnic-latest’, ‘/tmp/delegated-lacnic-latest’, true, FTP_ASCII); $test->cd(‘/pub/stats/apnic/’); $test->get(‘delegated-apnic-latest’, ‘/tmp/delegated-apnic-latest’, true, FTP_ASCII); $test->cd(‘/pub/stats/arin/’); $test->get(‘delegated-arin-latest’, ‘/tmp/delegated-arin-latest’, true, FTP_ASCII); $test->cd(‘/pub/stats/ripencc/’); $test->get(‘delegated-ripencc-latest’, ‘/tmp/delegated-ripencc-latest’, true, FTP_ASCII); $test->cd(‘/pub/stats/afrinic/’); $test->get(‘delegated-afrinic-latest’, ‘/tmp/delegated-afrinic-latest’, true, FTP_ASCII); $test->disconnect(); ?>

Os scripts aqui exibidos foram testados sob FreeBSD, exceto se for dito ao contrário.