Arquivo

Posts Tagged ‘nic.br’

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

Última atualização: 15/03/2011.

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 (~264) 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?

cidr_working4-1

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 (216). São mais de 16 milhões de redes com blocos /56! Blocos /56 implicam em 272. Muito maior, mas muito maior mesmo, do que os grãos do tabuleiro de xadrez! Tá mais para as medias cosmológicas.

TabelaIPv6-Reduzida

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]. Nas Figuras 3 e 3A, que seguem, quadros produzidos pelo pessoal do Nic.br são, realmente, um Guia Didático de Endereçamento IPv6, perfeito! Por razões históricas, foi mantida a Figura 3. Recomenda-se o foco na Figura 3A, que é a última atualização (Dez 2010). Bits, bytes, binário e hexadecimal se misturam sem, absolutamente, nenhuma complicação.

GuiaDidaticodeEndereçamento

Figura 3. Guia do Nic.br.

Figura 3A. Guia do Nic.br (Versão Dez 2010: Guia didático de endereçamento IPv6 – Nic.br).

As escolhas de como dividir o bloco /32 são imensas. Alguns parâmetros devem orientar, como exemplo o tamanho das redes de nossos clientes e as respectivas estimativas de crescimento, entre outras. 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 tendo em vista esse 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. Também, “host” é um nó que não é um “roteador”. Tais definições estão em [13]. Continuando, existem três tipos de endereços IPv6, 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 está em evolução, aqui, uma facilidade para descobrir, rapidamente, algumas informações sobre um número IPv6 específico.

Atualização em 15/03/2011: O documento [15] é uma recente tradução do RIPE, que vale a pena dar uma olhada.

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/.
[15] Preparing an IPv6 Addressing Plan Manual, December 2010: Original text, March 2011: Translation provided by RIPE NCChttp://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf.

Anúncios
Categorias:IPv6, TCP/IP Tags:, , , , , , ,

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 => 2128 => 79 trilhões de trilhões de vezes a disponibilidade do IPv4 ~= 5,6 x 1028 endereços por ser humano.
    • Reserva metade dos bits para enderaçamento local => 18.446.744.073.709.551.616 ou 264 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

    headerIPv6-Nic.br

    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:
      cabecalhoICMIPv6
      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.


    Categorias:IPv6 Tags:, ,

    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.

    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 e a política de roteamento, em cada etapa do traceroute. 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

    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.

    Sistemas Autônomos, Empresas Autônomas

    Últimas atualizações:
    22/04/2009 – 08:17
    14/12/2008 – 08:17
    10/12/2008 – 16:39
    26/03/2006 – 11:20
    18/03/2006 – 19:15
    16/03/2006 – 07:30
    1. Introdução

      O micro, pequeno e médio provedor brasileiro de serviços agregados da Internet, seja ele licenciado do SCM ou não, está sendo afetado duramente pela idiossincrasia do modelo brasileiro de telecomunicações. Sem representatividade, o provedor brasileiro fica à mercê das regras impostas pelas concessionárias do serviço público e, quase inerte na sua preocupação de sobrevivência, deixa de lado questões importantes que tornam difusas as fronteiras entre as velhas e as novas tecnologias.

      À distância e, curiosamente, pouco lembrado pelos provedores está o Comitê Gestor da Internet brasileira (CGI). A permanente presença das instituições de ensino e pesquisa brasileiras no CGI alentam nossas preocupações com o futuro em relação à governança da Internet Brasileira.

      As principais razões do alento e motivações do presente trabalho são:

      1. Atuação do Comitê Gestor. Disponibilizando o PTTMetro9 que, em linhas gerais, propõe aumento da confiabilidade e disponibilidade da Internet, diminui os custos de interconexão e, mais importante, diminui o poder das grandes concessionárias.
      2. Ausência de conhecimento técnico em relação às facilidades e recursos disponíveis.
      3. Disponibilidade de números IP´s, tanto IPv4 como IPv6.
      4. Perspectiva de mudança de paradigma tecnológico (IPv4 -> IPv6).
      5. Política: há um profundo desconhecimento das instituições sobre o que os provedores fazem neste país, sob o ponto de vista social. E, consequentemente, a aparente ausência de lideres e instituições com ampla e consistente visão de nossos problemas.
      6. Meios alternativos de transmissão e transporte de dados, gerando capilaridade em grande parte do território brasileiro.
      7. Necessidade de nivelar e ampliar o debate em torno de alternativas de negócios para os provedores de pequeno e médio porte.

      Talvez em (g) resida a principal motivação desse artigo. Não somente a legislação é confusa mas, insaciavelmente relegada ao cenário da impunidade. A falta de equilíbrio e precisão nos debates não nos está permitindo levar ao conhecimento de instituições como a Anatel, o fato de que os tempos mudaram. Somente para citar um exemplo, mas extremamente agressivo para os pequenos e médios provedores, está a questão da fixação de preços das telecomunicações através do que se denomina “degraus tarifários”. Esse critério é demasiadamente antigo e não reflete a realidade. Os recursos de interconexões se transformaram com as novas técnicas e tecnologias, as facilidades para se atingir as localidades estão alterados e, portanto, devem ser revistos. Ideias brilhantes e representativas dos interesses do país, como da Aneel, que estabeleceu a livre negociação no mercado de energia elétrica poderiam ser transpostos para a área de telecomunicações.

    2. Fundamentos históricos e definições

      Há certas dificuldades para introduzir o conceito da Internet atual. A procura pela descentralização da oferta de acesso à Internet gerou inúmeras alternativas, uma imensidão de técnicas e, consequentemente, uma variedade incomum de termos para classificar tais técnicas e, particularmente, para identificar os participantes que habitam o cenário da Internet global. Fica um pouco mais complicado quando se expõe o mosaico mundial, onde cada país adota caracterizações próprias.

      O regionalismo é um aspecto interessante. Aqui no Brasil, o modelo escolhido (1995), que deu origem à privatização (1996) foi distorcido ao longo do tempo. Em particular, na concepção da privatização, uma vez que, efetivamente, houve concessão. E, associada às distorções, uma série de leis, decretos, portarias e outros insumos burocráticos deturparam os princípios fundamentais estabelecidos na Lei Geral das Comunicações e legislação acessória6.

      Mas distorções e interesses financeiros envolvidos no cenário das telecomunicações de um país parecem estar proliferados em diversas regiões do mundo. Na Austrália, por exemplo, o chamado Grupo dos Quatro, recebe um nome pejorativo de Gang of Four (GOF), para designar os acordos entre a Telstra, Optus, AAPT e MCI. Apesar de três competidores da Gangue das Quatro (Comindico, Agile Communications e Primus Telecom) terem mais tráfego e rede maior do que duas das quatro (AAPT e MCI), não conseguiam acordos com as Quatro. A evidente demonstração de tentativa, de formação de cartel fez com que a Australian Competition and Consumer Commission (ACCC), criada em 1995, já em 1998, exigisse uma mudança nos acordos de “peering” feitos pela Gangue das Quatro. Detalhes dessa história, podem ser encontrados em 13

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

      Há uma certa confusão na definição dos termos acima. Sabemos que a Internet (ao contrário de internet, como identifica a mídia) é uma rede de redes de computadores, usando o protocolo TCP/IP. A figura abaixo, mostra a Internet, somente com três redes, para simplificarmos as definições:

      tresredes1

      Figura 1. Peering: acordos bilaterais

      A figura acima mosta interconexões entre as redes A e B, e entre as redes B e C. Estamos supondo que tais redes (A, B e C), pertencem à Internet e, também, nos abstraindo do tamanho de cada uma. Podem possuir um tamanho continental ou ser redes de um só computador, por exemplo. Tudo o que passa entre uma rede e outra, através da interconexão ou interconexões, é tráfego (ou seja, tráfego de pacotes TCP/IP). Se as redes A e B possuem interesses mútuos de que seus clientes troquem tráfego entre si, geralmente elas fazem um acordo sem que haja troca financeira. Isso é o que se chama de peering. O mesmo acontece entre as redes B e C, onde interesses mútuos podem criar um peering, entre elas. Mas clientes da rede A, estão impedidos de trocar tráfego com clientes da rede C, pois não há uma interconexão diretra entre elas ou, em outras palavras, não é possível um acordo ou arranjo de peering entre as redes A e C. Para que a troca de tráfego entre A e C possa ocorrer, existem duas maneiras: (a) A rede A faz um acordo de trânsito que permitirá o tráfego passar pela rede B e atingir a rede C ou, (b) as redes A e C estabelecem uma conexão física e fazem um acordo de peering. O tráfego, de A, que passa por B, para atingir C, geralmente é pago, pois está usando recursos físicos de B.

      Imaginando que as três redes da figura acima fossem os únicos membros da Internet, provavelmente, cada “dono” de uma das redes, seria um Provedor de Serviços de Internet (PSI). Seus clientes ou usuários estariam comprando trânsito, para trafegarem na Internet.

      Há algumas ideias que tornam o problema das interconexões entre redes um pouco mais complexos. Vamos supor, que a Rede A seja a CTBC, que a Rede B seja a Telefônica. Imaginemos que a CTBC tenha interesse de fazer uma conexão com a Telefônica e, vice-versa. Em outras palavras, desejam estabelecer um peering para agregar valor às suas ofertas de acesso à Internet, aos seus clientes (ou usuários). A questão que aparece é: de que maneira será feita a interconexão entre elas, para estabelecer o peering? Existem inúmeras alternativas, que devem ser passadas pelo crivo do menor custo. Vamos imaginar, ainda, que depois de uma análise adequada, elas cheguem à conclusão de que a melhor alternativa é usar a rede da Eletronet, digamos, de Uberlândia até São Paulo. Se isso acontece, então as duas (CTBC e Telefônica), ou uma delas, contrata tráfego da Eletronet, para fazer o ponto-a-ponto. Este tráfego é denominado transporte. Em outras palavras, a Eletronet foi contratada para transportar os pacotes TCP/IP entre Uberlândia e São Paulo e, vice-versa, para que o peering entre a CTBC e a Telefônica seja estabelecido, portanto.

      Nesse cenário, das três redes podemos imaginar que a Rede C, está em uma posição desconfortável em relação ao peering com a Rede A (e o inverso, também!).

      No contexto do que foi dito acima, vale lembrar que a Eletronet é um Provedor de Serviço de Backbone (PSB).

    4. PSI e PTTs

      Vale lembrar que PSI (ou, ISP, do inglês) possui o significado comum expresso na literatura em geral, sem as limitações da concepção brasileira. PSI é uma empresa ou organização que oferece acesso à Internet e disponibiliza, também, valores agregados a esse acesso. Muitos PSIs, em qualquer parte do mundo são as concessionárias ou empresas de telefonia (ou licenciadas do STFC, no Brasil). Mas, muitos outros PSIs são, unicamente, provedores de acesso à Internet e de seus valores agregados. Os serviços prestados pelos PSIs incluem, além da Internet, registro de nomes (agora no Brasil, em expansão), hospedagem de servidores, acesso discado, colocação, redes sem fio e muitos outros. Os provedores brasileiros, espalhados por todo o canto de nosso país, são PSIs. Alguns PSIs, tem se aventurados a fornecer serviços de backbone, relativamente restritos. Outros, contratando grandes servidores de backbone (como a Eletronet, por exemplo), com sucesso atendem a transporte de longa distância e, também, trânsito.

      No Brasil há um comportamento diferenciado da grande maioria dos provedores que não são concessionários de telefonia pública e que não se encaixam na categoria de fornecedores de “backbone”, hospedagem e co-locação, em relação aos provedores do resto do mundo. Eles são sensivelmente dependentes das concessionárias do STFC. Provavelmente, por razões de natureza técnica e, em alguns casos, por puro desconhecimento dos recursos e técnicas disponíveis.

      Vamos retornar à figura das três redes e lembrar das dificuldades para o estabelecimento do peering. Em particular, se pensarmos na Rede C e os interesses mútuos com a Rede A. Um dos recursos disponíveis para resolver problemas dessa natureza, é o chamado Ponto de Troca de Tráfego (PTT), que poderia ser ilustrado na figura abaixo:

      tresredesptt

      Figura 2. PTT: acordos multilaterais

      No Brasil, o NIC.br entre suas atividades está “a promoção da infra-estrutura para a interconexão direta entre as redes que compõem a Internet Brasileira, através do PTT.br”. Quando um PTT é estabelecido em uma região metropolitana, ele recebe o nome de PTTMetro. A descrição técnica8 do PTTMetro9 explica as regras propostas e no vasto material do PTT-MG7 podemos acompanhar o nascimento de um PTT sob a coordenação do NIC.br, através de suas atas. Nelas é possível ver os atuais interessados em participar. Chama atenção a presença de algumas concessionárias, sobre cuja participação falaremos já. Há uma dificuldade, entretanto o fato de que os PTT’s brasileiros estarem projetados somente para as principais capitais. Portanto, o desafio, ao se desejar estabelecer no ambiente de um PTT é chegar até lá. No exemplo de Minas Gerais (em Belo Horizonte), o PTT-MG não é somente um local físico. Ele é projetado para disponibilizar vários locais físicos, cada um podendo ser um PTT, interconectados via uma rede de fibra ótica de alta capacidade e, pelo que indica, usando Ethernet. No documento técnico do MGIX (PTT-MG) é claro o fato de qualquer empresa poder se estabelecer como PTT. O uso do protocolo Ethernet torna mais barato a troca de tráfego, inclusive trânsito.

      Umas das principais perguntas que surge é: qual a rzazão pela qual o NIC.br está provocando a criação dos PTTMetro em todas as regiões metropolitanas brasileiras? Uma resposta imediata é o fato econômico envolvido, que é possível concluir das descrições acima. Uma outra é observando a presença das concessionárias do STFC no MGIX e perguntando como poderia ser o relacionamento com tais membros que pertencem a um grupo de PSIs diferenciados. Elas pertencem ao grupo de PSIs que possuem um grande volume de tráfego e são quase provedores de backbone. Estes PSIs trocam tráfegos entre si, geralmente, em acordos de peering, sem transação financeira. Mas tarifam a troca de tráfego entre os pequenos ISP’s (aqueles com pequeno volume de tráfego). Nos EEUU, os ISP´s classificados como Tier 1 são conhecidos, informalmente, como membros do clube SFI, acrônimo de “Settlement-Free Interconnection”. Até 2005, faziam parte deste seleto clube: Qwest, MCI, Sprint Nextel Corporation, AOL, Verio/NTT, Level 3, Global Crossing, Savvis e AT&T. As concessionárias brasileiras, devem merecer um estudo, em separado, sobre onde elas se encaixam nesse contexto. Mas algumas destas gigantes americanas possuem seus próprios PTTs (inclusive no Brasil, curiosamente articulado ou facilitado, por uma instituição de fomente brasileira – como é o caso do NAP, em Barueri) e, provavelmente, grandes empresas brasileiras (por exemplo, as empresas estaduais de processamento de dados, grandes provedores, grandes empresas de co-locação e hospedagem, ISP’s virtuais), não conseguem troca de tráfego com estes PTTs, enquanto que, provavelmente, as concessionárias brasileiras do STFC conseguem.

      Das observações acima é possível imaginar que o NIC.br está liderando a construção dos PTTMetros preocupado em permitir o acesso de interessados, com pequeno volume de tráfego, favorecendo condições econômicas de “peering” e de trânsito, estimulando o desenvolvimento seguro e eficaz da Internet brasileira. Além de tentar neutralizar ou diminuir as tendências de formação de monopólios e cartéis no cenário brasileiro. Felizmente, a partir do final de 2008 e início de 2009, uma frente de apoio da comunidade está levando à criação dos chamados PTTs Regionais (PTT-R). Não é possível deixar de lembrar um dos mais ativos atores, nesse movimento: a ANID.

      Um dos prérequisitos para se ligar a um PTT é ser um Sistema Autônomo ou participar de um grupo de possua um Sistema Autônomo “compartilhado”.

    5. Sistemas autônomos e o BGP-4

      Um AS é um grupo redes TCP/IP conectadas, sob o controle de um ou mais operadores ou entidades. Vejam a figura abaixo. Ela mostra dois grupos de redes TCP/IP conectadas. Cada uma pertence à respectiva entidade. Entidade A e Entidade B.

      São dois grupos de redes independentes. Para que os dois grupos de redes possam se integrar é necessário que a Entidade A e a Entidade B façam um acordo de “peering”. Fazendo o acordo de “peering”, então a conexão entre os dois grupos de redes TCP/IP (ou entidades) é estabelecida. Como a figura abaixo:

      Se o acordo de “peering” entre as A e B tem como objetivo a visibilidade dos equipamentos de cada uma (por exemplo, um navegador em uma máquina de A poder acessar um servidor de Web de B), então elas precisam estabelecer uma política de roteamento comum. Então, cada uma das entidades, separadamente, passam a ser um Sistema Autônomo ou AS. Se imaginarmos milhares de entidades interconectadas, a melhor definição para AS é a dada por20: um AS é uma porção lógica de uma grande rede IP.

      Portanto, podemos esquecer a identificação “entidade” e passar a chamá-las de AS A e AS B. Na realidade, na Internet, cada AS é identificado por um número único, chamado de “Autonomous System Number“, ou ASN. Embora não esteja representada, ainda, o trânsito de Internet nas figuras acima, o ASN, por ter a característica de ser único, é obtido através de uma instituição controladora. Aqui no Brasil o ASN é obtido via o NIC.br em acordo com o LACNIC14.

      Os preços para aquisição de um ASN, blocos de IPv4 e IPv6 podem ser vistos em [25].O ASN é um número de 16 bits (já com um projeto para 32 bits). O 0-(zero) e o 65535 são reservados. De 1 a 64511 são ASN’s públicos, fornecido pelo NIC.br. Os ASN’s de 64512 a 65534 são considerados privativos e usados para o estabelecimento de AS particulares. Supondo que A e B possuem políticas de roteamento compatíveis com a Internet, então podemos recompor a figura usando a referência do ASN de cada uma delas. Suponhamos que A tenha o ASN=i e B tenha o ASN=j, onde 0 < i != j < 64512. Então, a figura agora fica mais clara:

      Então, recapitulando, AS constrói o cenário da Internet. Com sua nova definição, o cenário da nova Internet, em franca expansão! AS´s se entendem através de uma política de roteamento comum. No Brasil, existem atualmente (março/2006) cerca de 200 AS’s. O NIC.br, por ocasião da Telexpo 2006, considera esse número muito baixo e a expectativa é de que ele dobre em um ano. Em se tratando da Internet, a política de roteamento é estabelecida através do uso do protocolo BGP-411. O BGP é um protocolo antigo, mas a versão 4 passa a suportar o conceito de agregação de rotas e o CIDR 23. Tais recursos permitem a publicação de rotas de maneira simples, transformando complexidades em facilidades na interconexão de redes em ambiente de grande porte. O BGP-4 aumentou, consideravelmente, a escalabilidade do BGP!

      Escapa do escopo desse trabalho, detalhes técnicos sobre o BGP-4. Na área restrita, estaremos fazendo abordagens mais adequadas e profundas sobre AS e, naturalmente, dos poderes do BGP-4 integrando e facilitanto o projeto. Um bom tutorial sobre BGP-4, oferecido no 17° GTER está em 24.

    6. Mais sobre “peering”, trânsito e algumas considerações econômicas

      O entendimento do conceito exato de “peering” e trânsito não é muito fácil. Alguns profissionais experientes consideram uma questão obscura e complexa. Basicamente, duas razões levam ao pensamento de dificuldade de compreensão: o oligopólio das grandes concessionárias (monopólio regional, no Brasil – o que piora o cenário) e os custos envolvidos.

      Vamos recompor nossa definição de “peering” para estimular o entendimento: “peering” é uma relação entre ISP’s ou entre outras redes que agregam Internet, na qual eles trocam o tráfego de seus clientes, entre si, geralmente sem envolvimento de dinheiro. A idéia por trás dos PTT’s é proporcionar facilidades para “peering” entre seus participantes. Mas, no Brasil, os PTT’s estão nas regiões metropolitanas e, portanto alijam do processo, os pequenos provedores do interior. Por outro lado, “peering” é, também feito entre ISP’s sem passagem por um PTT. É o que acontece entre as concessionárias de telecomunicações no Brasil. Mas não acontecem entre provedores, principalmente de pequeno porte. E há muitos equívocos por trás da ausência de “peering” entre os provedores brasileiros. Primeiro porque não há, absolutamente, interesse das concessionárias, de que os ISP’ saibam desse recurso. Segundo por um desconhecimento profundo dos ISP’s sobre o que pode ser feito e, curiosamente, das próprias concessionárias em face de seu modelo de negócios. Por exemplo, quando um ISP possui dois enlaces para a Internet (isto é, trânsito) ele imagina que esta alternativa é factível somente para evitar perdas de conexões para seus usuários. E nem pensam que a melhor forma de garantir isso é obtendo um ASN e, consequentemente, implementando BGP-4 poderiam, além de adequar de forma correta o balanceamento de tráfego, se tornar independente em relação à publicação de seus IPs (IPv4 e IPv6 – esse, em uso crescente). Com o ASN, o provedor está fazendo “peering” sob trânsito nas duas concessionárias, numa solução barata, provavelmente usando recursos que já possui. E, não se pode esquecer o fato de que as concessionárias fazem “peering” entre si, sabe-se lá como.

      A próxima questão importante a ser debatida é: porque fazer “peering”? Há três razões imediatas: (i) é barato, (ii) irá melhorar a eficiência da conexão sob o ponto de vista de eliminar terceiros no relacionamento entre grupos de PSIs com interesses na troca de tráfego (VoIP, por exemplo) e, (iii) ganha-se maior controle sobre as rotas. Cada uma destas razões merecem comentários e novos debates, que serão feitos em outra oportunidade.

      E, existem motivações para não se fazer “peering”?. Sim, muitas! A primeira razão é curiosa e associada a uma pergunta óbvia, praticamente recursiva, de “o que é “peering?”. Quando se compra trânsito, um conjunto de facilidades estão embutidas, simplificando o trabalho e tornando os administradores de redes despreocupados com o significado de “peering”, se existe “peering” e como se faz “peering”! Uma segunda razão, para não fazer “peering” é o fato de, curiosamente, ele ser caro sob o ponto de vista dos investimentos, dependendo do cenário ou localização do interessado. Embora o “peering”, em si, seja livre de custos, há custos associados à física para chegar ao PTT. Há o espaço para hospedar servidores, switchs e/ou roteadores, nas proximidades do PTT. Além de investimentos em equipamentos necessários ao “peering”. Em resumo, o trânsito acaba sendo mais barato se abandonamos a idéia do “peering”. A terceira razão é de que “peering” pode dar trabalho e exigir conhecimento, excedendo á competência dos administradores de redes. Tudo isso com que os custos fiquem elevados com contratação de terceiros, por exemplo. Como quarta motivação sobressai a questão da eficiência, cujo ganho irá depender das condições em que o trânsito é estabelecido. Mesmo essa questão pode nos enganar facilmente. Os oligopólios fazem “peering” entre si, como falamos. E, repetindo, sabe-se lá como! O “sabe-se lá como” é a parte preocupante da questão que pode negar a vantagem de não se fazer “peering” devido ao quarto propósito acima. A governança da Internet brasileira (leia-se, Comitê Gestor), está preocupada com essa questão, tanto que já comunicou às grandes operadoras que irá monitorar os “peering” por elas estabelecidos. A eficiência pode estar sendo comprometida e, em face da complexidade, os provedores e/ou empresas usuárias nem percebem isto ou não podem resolver e nem discutir as demonstrações de ineficiência do trânsito contratado.

      Estas questões são abordadas com muita propriedade em [21] incluindo um interessante cálculo de custos envolvidos no “peering”. Muitos outras informações podem ser encontradas no sítio da Packet Clearing House (PCH)22.

    7. Conclusões e considerações finais

      As técnicas envolvendo Sistemas Autônomos e os protocolos que circundam o BGP-4, por sí só, garantem a viabilidade do segundo projeto (a principal expectativa). Mas, o componente financeiro, em particular, os custos de projeto e aqueles necessários à manutenção do ambiente central de oferta de recursos e facilidades, indicam que não se pode viabilizar um projeto como esse sem a participação (ou união), de uma considerável parcela dos provedores brasileiros.

      É praticamente impossível abordar um projeto como esse, que exige razoáveis investimentos, no esquema tradicional de divisão de cotas, onde cada provedor participa com um valor préviamente estabelecido, por duas razões. A primeira, pela dificuldade em estabelecer o valor da quota (ou, o número de participantes). A segunda, porque os provedores brasileiros já estão cansados de investir em perspectiva, sem que ela se apresente, efetivamente. Sendo assim, os modelos até hoje procurados, Associações, Cooperativas etc., tendem a não oferecer resultados e, infelizmente, não viabilizariam a saida do papel de um projeto como esse. Vale dizer, que outras formas de agrupamento dos ISP´s são válidas e devem continuar sendo mantidas ou criadas.

    8. Agradecimentos

      Inúmeras pessoas contribuiram para este trabalho e de várias maneiras. Gostaríamos de expressar o agradecimento a todos e alguns, em particular. Ao Eugênio Fonte Boa13, que revisou o texto inúmeras vezes. Ao Bruno Cabral1, da Openline que leu o texto várias vezes, contribuindo com diversas observações. Ao Rubens Kuhl Jr. que, em diversas conversas e e-mail, contribuiu para o entendimento de questões técnicas e concepção das ideias, as quais são mais fortes na área restrita. Finalmente, ao Nicolau Meisel que recompôs todo o conjunto recomendando ajustes fundamentais, como sempre o fez e de maneira original.

    9. Epílogo

      Esse artigo foi escrito no início de 2006. Na época, o principal objetivo era estabelecer um equilíbrio no pensamento dos provedores, em relação aos conceitos e termos envolvendo PTTs. Havia, também, a preocupação de nos aproximar na defesa da criação dos PTT regionais (PTT-R). Na medida do possível, iremos atualizando e simplificanto o texto, além de ajustá-lo aos movimentos que estão tornando a Internet brasileira, mais preparada para reagir aos interesses de grupos poderosos e desinteressados em levá-la a toda a sociedade brasileira, em benefício do resultado financeiro. Finalmente, observa-se uma diferença significativa, na visão positiva dos PSIs em relação aos PTTs, desde o ano de 2006 até agora, 2009.

    10. Referências
      1. Bruno L. F. Cabral, E-mails, etc.
      2. Comitê Gestor Internet/Brasil, GT-ER, Proposta para a Recomendação de PTTs
      3. Eugênio Fonte Boa, E-mails, reuniões, etc.
      4. Freesoft
      5. Hawkinson, J. e Bates, T., Guidelines for creation, selection, and registration of an Autonomous System (AS), RFC1930, 1996.
      6. Legislação brasileira de Telecomunicações
      7. MGIX
      8. N. Silva e outros, Metropolitan Internet eXchange – MIX (em português PTTMetro)
      9. PTTMetro
      10. Rede Eletronet (mapa)
      11. Rekhter, y. e Li, T., A Border Gateway Protocol 4 (BGP-4), RFC1771, 1995
      12. Rubens Kuhl Jr., E-mails, reuniões, etc.
      13. Wikipedia
      14. Lacnic – Solicitando ASN
      15. IANA, Autonomous System Numbers
      16. BGP
      17. Redes da Infovias
      18. REMAV – Redes Metropolitanas de Alta Velocidade
      19. RedeRio de Computadores (FAPERJ)
      20. Adolfo Rodriguez, John Gatrell, John Karas, Roland Peschke, TCP/IP Tutorial and Technical Overview
      21. Steve Gibbard, Economics of Peering
      22. Packet Clearing House
      23. Introdução a CIDR (Classless Inter-Domain Routing)
      24. Caio Klein, BGP v4 – Tutorial
      25. LACNIC – Tabela de preços

      * Alguns chamam de última milha. Ambos os termos não possuem definição bem clara. Preferimos identificar como primeira milha, já que é onde começa a demanda para o acesso à Internet e é, também, um ponto bem definido.

    Categorias:PTT, TCP/IP Tags:, , , , ,
    %d blogueiros gostam disto: