Arquivo

Posts Tagged ‘lacnic’

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:, , , , , , ,

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

%d blogueiros gostam disto: