[GTER] RES: RES: AS versus IPv6

Tukso Antartiko tukso.antartiko at gmail.com
Mon Oct 15 20:58:03 -02 2007


Na Ásia o mínimo é /21
http://www.apnic.net/db/min-alloc.html

Na ARIN se for multihomed o mínimo é /22 senão /20
http://www.arin.net/policy/nrpm.html#four215

Na RIPE o mínimo é /21
https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html

A América Latina para esnobar, embora apenas no papel, estabelece o mínimo
de /20. Típica atitude latina, temos as "melhores" leis, mas somos os que
mais as desrespeitam.

Como na prática todos sabem que o mínimo é irreal, acabam fazendo vista
grossa para as exigências e concedem blocos a rodo.
Isso deixa o espaço subutilizado, pois um /22 ou /21 é suficiente para
muitos. E pelo desprezo desde a criação das normas muita gente que nem
deveria ter bloco acaba com um.

Além disso os ASNs que alocam o mínimo normalmente têm apenas um bloco,
considerando que todos anunciem o tamanho do bloco que receberam, então o
número de anúncios que a norma se aplica estaria mais relacionado a
quantidade de ASNs do que o tamanho do bloco.

Digo "estaria" porque estes limites mínimos são normalmente desprezados em
relação a filtragem de anúncios. Não que isso seja um conselho para alguém
se arriscar a desprezá-los mas na prática a maioria despreza. Eu até ficaria
feliz se me indicasse o número da RFC  que orienta para filtrar anúncios
segundo a alocação mínima do RIR.

Assim ao invés de /20 melhorar a situação só serve para o AS da esquina
anunciar uma combinação maior de /24, /23 e /22 de acordo com seu método
tabajara de otimização ou qualquer outra idéia maluca que o leve a
transformar sua alocação em pedacinhos.

A suposição que todos precisam manter uma tabela full no roteador é um mito.
A não ser que esteja vendendo tráfego para outro AS é uma preocupação
geralmente desnecessária.
Qual a utilidade em manter rotas separadas para, digamos todos prefixos da
Ásia? A rota deles diferencia tanto assim?

Tabela full é mais um mito para forçar atualização de roteador, a maioria
ficaria confortável armazenando um número muito menor de rotas.

Se alguém me falar em tabela full no roteador ser uma justificativa para
otimização respondo que uma das melhores ferramentas de otimização (FCP)
armazena a tabela full em um servidor (commodity) à parte. O FCP custa
milhares de dólares mas se C investisse menos em FUD marketing a economia de
escala faria seu papel e os equipamentos de rede "durariam" mais.

On 10/15/07, Lao DanTong <danton at inexo.com.br> wrote:
>
> On Mon, 15 Oct 2007, Tukso Antartiko wrote:
>
> > Não disse que o Brasil está preocupado, o restante da mensagem diz
> > justamente que há falta de mobilização dos órgãos responsáveis. Nossos
> > vizinhos latinos até deram um jeitinho de garantir  v4 para o "dia do
> juízo
> > final", que provavelmente desperdiçarão  estabelecendo prefixos mínimos
> de
> > /20, mas isso é outra história.
>
> os prefixos mínimos de /20 são necessários para que as tabelas de rotas
> que já são enormes não fiquem insustentáveis. o mesmo argumento levou ao
> prefixo /32 (esse sim realmente muito exagerado) no ipv6. o problema de
> tamanho das tabelas de rotas é mais sério do que o de esgotamento do
> espaço de endereços, e o ipv6 não resolve esse problema e, de certa
> forma, ainda o torna mais chato.
>
>



More information about the gter mailing list