[LACNIC/Politicas] Pol í tica de publicaciones de bloques IPv6 (propuesta para modificacion de politica)

[Roque Gagliano]

Jordi,

Te contesto entre líneas.

On Mar 17, 2007, at 7:09 AM, JORDI PALET MARTINEZ wrote:

> Hola Nicolas,
>
> Ademas de que opino que lo que propones va en contra del diseño  
> original de
> IPv6 por parte de IETF (y por tanto quizas debiera de ser algo  
> realizado
> alli antes que en los RIR, pues no creo que sea logico que las  
> politicas
> sean contrarias a los estandares)
>

Creo que estamos confundiendo el tema. La politica no apunta a  
resolver el problema de qué pasa con prefijos menores a un /32 (site  
multi-homing) sino eliminar de la política IPv6 la "obligación" de  
que un proveedor deba publicar su bloque asignado (por ejemplo un / 
28) como un sólo prefijo. Todo aquello menor a un /32 sabemos que en  
general no va a ser ruteado.

Cuanda hay un BCP que resuelva el problema, podemos simplemente  
referenciarlo como hemos hecho en otros casos. Por ahora no lo hay y  
no podemos desde una política hacerlo.

La política actual además genera una injusticia importante,  
imaginemos que a mí me asignan un /32 y luego al año me asignan otro / 
32. Yo podría publicar los dos en forma independiente. Ahora si de  
primera me asignan un /31, no puedo separarlo en dos /32. ¿esto es  
justo?, ¿realmente los RIR deberian controlar esto?, ¿acaso son la  
"policía" del routing?.

> Como es evidente, yo en principio estoy en contra de esta propuesta  
> y creo
> que no se deben usar politicas para "corregir" *supuestos* defectos de
> diseño, cuando en realidad lo que pretendemos es duplicar errores  
> cometidos
> con IPv4, en lugar de buscar otras soluciones tecnicas como es  
> debido, y
> crear un nuevo factor de explosion de crecimiento de tablas de  
> routing, que
> sera un importante coste para TODAS las redes, incluso aquellas que no
> desagreguen.

No veo que sea un problema de diseño de IPv6 sino es un tema de cómo  
se hace el routing en internet (el tema del "hot potatoes" bgp). Lo  
que se busca es ingeniería de tráfico. De vuelta no son los RIR el  
ámbito para imponer políticas de routing a los proveedores, no lo han  
sido en IPv4 y no lo deben ser ahora.

>
> Por otro lado, esta politica SOLO tendria sentido si se logra  
> aprobar en
> todas las regiones. Imaginemos que solo LACNIC la aprueba. Cuando tus
> prefijos desagregados lleguen a transitos de otras regiones, tu  
> trafico
> seria filtrado, porque la desagregacion no coincide con las  
> asignaciones de
> tu RIR. Creo que eso, en lugar de ayudarte, empeora tu situacion,  
> no ? De
> hecho no es algo teorico, es algo que aquellos ISPs que ya  
> desagregan (en
> contra de la politica), ya estan sufriendo (puedo poner varios  
> ejemplos,
> pero el mas evidente es el de la propia infraestructura de APNIC,  
> que tiene
> un /32, pero anuncian como 2x/33, en contra de su propia politica,  
> y dia si
> dia no, no es alcanzable).

De vuelta, estamos errando a la intensión de la política. La idea es  
que si tenes un /28 puedas publicar 4x/30, no habría problemas con  
los filtros. Si vamos a lo que pasa en IPv4, no hay politica al  
respecto en los RIR (como deben ser) y hay un BCP no escrito donde se  
establece que un /24 es lo mínimo que se puede anunciar.

>
> El problema empeorara cuando empecemos a utilizar la certificacion  
> de los
> prefijos, ya que en ese caso, de forma automatica, todos los  
> routers que
> usen esa tecnologia, te filtrarian.
>
> Por otro lado, creo que seria bueno tener un resumen en la lista de  
> los
> comentarios que hayas tenido de Nanog u otros foros.

Recordemos que ya hemos tenido esta discusión hace unos meses y la  
realidad es que los proveedores lo están haciendo pues...no hay otra  
solución con el sistema de routing existente. Recordemos que estamos  
en Sudamérica, que el BW cuesta mucha $$$ y por ende necesitamos  
poder hacer ingeniería de tráfico para sacarle el mayor provecho a  
cada enlaces. En otras regiones para grandes operadores, simplemente  
se publican los superprefijos en todos los enlaces y que la red lo  
resulve, nosotros NO podemos hacer esto.


>
> Saludos,
> Jordi
>
>
>
>
>> De: Nicolás Antoniello <nicolas at antel.net.uy>
>> Organización: MEI - ANTELDATA
>> Responder a: <nantoniello at antel.net.uy>, LACNIC Policy mailling list
>> <politicas at lacnic.net>
>> Fecha: Fri, 16 Mar 2007 17:53:44 -0300 (UYT)
>> Para: <politicas at lacnic.net>
>> Asunto: [LACNIC/Politicas] Política de publicaciones de bloques IPv6
>> (propuesta para modificacion de politica)
>>
>> Estimados,
>>
>> Envío la propuesta formal para la modificación de la política de
>> asigancion de prefijos IPv6:
>>
>> Propuesta:
>>
>> Se propone eliminar el punto 5.1.1.d:
>>
>> 5.1 Adjudicación inicial
>> 5.1.1 Criterio de adjudicación inicial
>> d) Anunciar en el sistema de rutas inter-dominio de Internet un único
>> bloque, que agregue toda la asignación de direcciones IPv6  
>> recibida, en un
>> plazo no mayor de 12 meses.
>>
>> Y promover la remoción de los equivalentes a nivel de todo los RIR.
>>
>>
>>
>> Motivación:
>>
>> (Adjunto la redacción en ingés que envié al foro de nanog)
>>
>> The problem raises when a RIR assign a /28 prefix (for example) to  
>> an ISP
>> which has 3 internet links with 3 different carriers (tier 1  
>> carriers, for
>> example) using BGP publications.
>>
>> Acording to ARIN (and most other RIRs) policy, the ISP must advertise
>> through all the 3 links the /28 without the possibility of  
>> dissagregation.
>> The problem with this policy is that by doing this, the ISP loses  
>> control
>> of the traffic, not being able to distribute the traffic over the 3
>> different links.
>>
>> A /28 prefix may have a lot of incoming traffic associated to it,  
>> so I
>> believe the dissagregation (subnets) of the prefix should be  
>> allowed by
>> the policy.
>>
>> Please read http://nro.org/documents/nro42.html for information about
>> possible multi-homing solutions being analysed.
>>
>>
>> Saludos,
>> Nicolas Antoniello
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas