[GTER] RES: RES: AS versus IPv6

[Tukso Antartiko]

Como sempre estou desatualizado:

Já definiram o tamanho mínimo no dia 05/10:
http://lacnic.net/en/registro/index.html

Logo após receberem os blocos no dia 28/09 e os noticiarem ainda no dia
05/10:
http://mail.lacnic.net/pipermail/anuncios/2007-October/000884.html

A "democracia" não podia ser mais rápida. Mínimo /20

On 10/15/07, Tukso Antartiko <tukso.antartiko at gmail.com> wrote:
>
> 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.
> >
> >
>