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

[JORDI PALET MARTINEZ]

Hola Roque,

Te contesto debajo, entre-lineas.

Saludos,
Jordi




> De: Roque Gagliano <rgaglian at antel.net.uy>
> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
> Fecha: Sat, 17 Mar 2007 10:51:50 -0300
> Para: LACNIC Policy mailling list <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Pol í tica de publicaciones de bloques IPv6
> (propuesta para modificacion de politica)
> 
> 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.

Creo que no lo he confundido. No me estoy refiriendo a prefijos mas pequeños
de /32 (en realidad mas largos, bloques de direcciones mas pequeños), sino
al texto propuesto por Nicolas, asunto que ya comentamos anteriormente en la
lista.

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

Lo logico es trabajar en ese BCP en IETF (y de hecho hay un documento en
curso al respecto en v6ops), asi que lo suyo es contribuir a ese documento y
si la conclusion es que hay que cambiar la politica, pues se cambia una vez
que IETF haga una recomendación al respecto, pero hoy por hoy, la
recomendación es no romper la agregacion (no realizar anuncios
desagregados).

Si un ISP desda romper la agregacion, como de hecho ya lo hacen algunos,
nadie le va a impedir que lo haga, y sera la comunidad la que decida, bien
mediante la exigencia de la aplicación rigurosa de la politica, o bien el
mercado (el filtrado de las desagregaciones, como asi ya ocurre a algunos).

En casi todas las politicas hay facetas que los RIRs no aplican
estrictamente, y me parece logico hasta cierto punto, pero creo que se deben
de mantener como medida de seguridad, porque nos permite controlar el uso de
los recursos. Y como recursos aquí tambien me refiero a los slots en las
tablas de routing, que tienen un coste en cierto modo oculto que pagamos
TODOS los que tenemos BGP. Sin embargo, cuando un ISP desagrega, no compensa
por ello a todos los demas, verdad ? Hasta que punto es eso logico ? Yo
diria que es logico siempre y cuando no este suponiendo un incremento de
coste "notable" al resto de los participantes de la red, pero si se produce
una explosion y por ello llegamos a tener 100.000 entradas nuevas de
routing, debe de pagarse por ello, y esta politica permite que si no se
logra "cobrar" ese perjuicio, se pueda exigir su aplicación.

> 
> 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?.
> 

Creo que discrepo. De la forma en la que se estan haciendo las
adjudicaciones y las reservas contiguas, y vosotros mismos habeis pasado por
ello, al igual que al menos otros dos ISPs en la region que yo recuerde
ahora mismo, si necesitas un prefijo mas grande, se te amplia la asignacion.
Es decir, no se te entrega un nuevo /32, sino que tu /32 se convierte en un
/31, /30, etc.

Luego no se produce una injusticia. De hecho, pienso que en ningun RIR ha
habido este caso hasta el momento, y espero que no ocurra.

Es mas, diria que si un ISP intenta "jugar sucio" y pide un /32, a sabiendas
de que necesita un /30, y por cualquier motivo ello no fuera posible, pienso
que deberia de plantearse que se le exija renumerar su red a un /30 nuevo,
para evitar que alguien intente dicho "juego".

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

Una de las premisas del diseño de IPv6 fue evitar la desagregacion.

La cuestion de la ingenieria de trafico es un "defecto" tal como se esta
haciendo con IPv4, y no debemos duplicar los errores. Ayer en la reunion del
RRG, precisamente estuvimos viendo este tema y posible alternativas. Parece
que pueda pasar forzosamente por la separcion de Locator/ID.

Tambien como te decia antes, se esta trabajando en un documento en v6ops.

Pero en definitiva creo que nos hemos acostumbrado a hacer "chapuzas" para
solucionar mas que los problemas, los *intereses* de cada proveedor, aunque
esto suponga un coste para el resto de la red, y creo que esto si que es
realmente *injusto*. Dejamos de ser buenos "netcitizens" con tal de ser mas
competitivos a costa de cargar esos costes no solo a nuestra competencia
sino al resto de la red. Fijate, que no lo habia pensado nunca, pero en
muchos paises estas practicas podrian ser incluso constitutivas de delito
(anti-competencia, anti-trust). Creo que es mejor evitar que ocurra, al
menos desde el punto de vista *normativo* (politicas), para evitar que los
gobiernos o los reguladores quieran meterse en ello, no te parece ?

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

Precisamente, en IPv6 hay una politica porque es parte del diseño de IPv6,
aprendiendo de los errores en IPv4.

Los filtros deben de configurarse en funcion de las adjudicaciones. Un ISP
puede abrir la mano, pero no debemos de obligar a los demas ISPs, que no
quieran a hacerlo, y si la consecuencia es que si el ISP A decide hacerlo,
parte de la red no le pueda alcanzar, se lo pensara dos veces.

De hecho, tras mucho insistir, APNIC creo que ya se ha apuntado esto en
serio y posiblemente se resuelva, pues dificulta el acceso a su propia web y
considero que es muy mal ejemplo que un RIR incumpla su propia politica.

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

No solo en LAC el BW cuesta mucho, pero como digo, hasta que punto es justo
que tu ahorres a costa de los demas ?

> 
>> 
>> 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
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.