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

[Roque Gagliano]

Contesto entre líneas....

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

Bien. Era sólo para aclarar que estamos viendo el mismo tema.

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

Estoy totalmente de acuerdo que el IETF es el ámbito para lograr un  
BCP, pero no las políticas de los RIR. Como hemos planteado, el  
problema no tiene solución actual y sólo hay ideas de cómo atacarlos,  
por ejemplo a través de PCE entre proveedores.


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

te planteo otro ejemplo que ocurre con las políticas de remote - 
whois. Un proveedor tiene un /30, lo publica como 4x/32 y en el  
momento de pedir bloques adicionales, simplemente cambia la  
publicación a un /30, obtiene los bloques adicionales (en realidad no  
es claro que ese sea un requesito para obtenerlo pues no está escrito  
así en la política actual) y luego publica en forma desarreglada.  
¿quien puede evitar esta situacion? de vuelta los RIR no son policías  
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.
>
> Una de las premisas del diseño de IPv6 fue evitar la desagregacion.

Bien, pero IPv6 se comenzó a pensar hace 20 años. No olvidemos que  
hoy en días en varias empresas con MPLS, ya están pensando en  
millones de rutas proveenientes de VPNs...

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

¿hay acceso al acta de estas reunión? se agradecerá.

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

Creo que claramente esta es una herramienta básica para proveedores  
de mediano y pequeño tamañano. El no tenerla beneficia únicamente a  
quienes dan tránsito. Imaginemos que yo tengo un /28 que satura uno  
de mis enlaces con un proveedor de tránsito específico, me veo  
obligado a aumentar mi BW con el, no puedo simplemente desviar el  
tráfico a otros enlaces con por ejemplo menor uso.

Respecto al plano normativo, no soy abogado, pero como aclaraba en el  
párrafo anterior, me da la impresión que es justamente lo contrario.


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

Hoy en día la política de /24 para IPv4 funciona correctamente, no  
entiendo porqué podemos suponer que la politica de un /32 no vaya a  
funcionar para IPv6. Los ISPs han sido muy responsables en esto y  
para ser honesto creo que confío más en dajar el tema del filtrados  
en manos de la comunidad de operadores que en los RIRs.

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

cuál es el costo de los demás? la memoria de sus enrutadores? el uso  
de cpu? Esto no es sacrificar algo todos por el bien común, es  
sacrificar los que pagamos a los TIER1 por su bien común...

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