[lacnog] [LAC-TF] Bloques /48

[JORDI PALET MARTINEZ]

Hola Fabian,

Perdona la tardanza, pero he estado viajando mucho ultimamente y tenia mucho
correo acumulado y queria dedicar cierto tiempo a este asunto porque
considero que es muy importante.

Bajo mi punto de vista y el de muchos otros creo, es un grave error
encaminar prefijos mas largos de /32, dado que ese (/32) es el prefijo mas
largo que todos los operadores encaminan por defecto.

Si un solo operador en el mundo, bloquea algo mas largo que /32, pierde
totalmente el sentido que se utilice dicha longitud, porque no tienes
garantia de que tu trafico sea visible globalmente, que en el fondo es tu
objetivo, correcto ?

Cuando hemos diseñado IPv6, en el IETF hemos preparado un documento que es
el RFC3177, en el cual se basaron inicialmente las politicas publicas de los
RIRs.

Este documento indica que el "ultimo salto" (ejemplos: usuario residencial,
oficina de un banco o de una empresa cualquiera), ha de recibir un /48, y
excepcionalmente un /47 (si se justifica).

El mismo documento explica que un /64 ha de ser asignado cuando se sabe que
hay una sola red. Por ejemplo, yo diria que es el caso de un telefono
cecular, dado que cada PDP context (algo asi como cada interfaz con la red),
recibira un /64, y por tanto varios equipos detrás de esa interfaz tendran
direcciones IPv6 disponibles.

Por ultimo, el caso del /128, hoy en dia es cada vez mas dificil. Por
ejemplo ya no seria aplicable a un dial-up, puesto que detrás del modem,
tipicamente habra mas de un dispositivo, con lo cual incluso en este caso se
deberia de asignar un /48, o en el peor de los casos un /64 (si no es de
banda ancha). Pero se me ocurre el ejemplo de un ISP que gestione para la
compañía electrica la lectura de los contadores de agua, gas, electricidad,
y que no use el prefijo de la red de banda ancha del usuario, o incluso ni
siquiera esa red, sino la propia red electrica para realizar dichas
lecturas. Obviamente, no tendria mucho sentido asignar mas de 1 /128, dado
que es claro que hay un solo dispositivo (cada contador). Es decir el caso
en el que se esta seguro que hay solo un dispositivo.

Este documento, se ha intentado modificar en el IETF en varias ocasiones y
no ha obtenido consenso. Es decir, hay un consenso en que el documento es
valido tal y como esta ahora, al menos por parte de mas de un millar de
ingenieros trabjando en IETF. Creo que eso dice mucho.

La idea destras de esto es en definitiva, EVITAR que se necesite utilizar
NAT con IPv6 para tener una unica direccion IPv6 o un conjunto de ellas, y
luego direcciones privadas, etc. No volver a repetir errores que complijan
el diseño de aplicaciones y hacen la red mas costosa de operar, al igual que
las aplicaciones mas costosas de desarrollar.

El estudio realizado por Tony Hain indica, que si seguimos el RFC3177, y
asignamos a cada sitio final (usuario residencial, oficina del banco o
empresa, division de una universidad o laboratorio, etc.), /48, tendremos
IPv6 para los proximos 480 años. Yo ya he comentado varias veces, que aun
cuando nos hayamos equivocado en un 80%, por decir algo, es realmente
dificil pensar que IP, tal y como lo conocemos hoy, seguira en nuestras
redes dentro de 40 o 50 años, y no por un problema de falta de direcciones,
sino por que tendremos otras necesidades en la red, diferentes a las que
somos capaces de preveer ahora.

Es decir, el argumento de que esta forma de asignacion es malgastar
direcciones, se cae por su propio peso.

Si no mal recuerdo, la politica de asignaciones para infraestructuras
criticas indica que se asigne entre un /48 y un /32. Es logico que un NAP
reciba un /48, dado que 1) no requiere mas, 2) no se publica. Sin embargo,
según creo, lo habitual es que se asigne /32 al resto de los casos.
Concretemante, un TLD no se PUEDE arriesgar a que su prefijo sea filtrado ni
tan siquiera por un solo encaminador del mundo, logico no ?

Como autor de la politica de IPv6 PI, la idea fue la misma, partiendo de los
que se habia decidido para las infaestructuras criticas, tras una larga
discusion según nos indico el staff de LACNIC. Dar flexibilidad al
hostmaster, por si en el futuro hay casos, o se modifica la politica de
enrutamiento global para que esa longitud maxima no sea /32.

Pero ademas, si seguimos el razonamiento anterior respecto de los /48 para
cada "extremo" de la red, es obvio, que si yo soy un banco, una empresa, un
data center, una universidad, etc. (llamemos a todos estos "usuarios
finales" para abreviar a partir de ahora), quiero poder asignar a cada
"usuario final", el /48 que les corresponde.

Por tanto si recibo un /32, no solo esto seria posible, sino que ademas, no
tendria necesidad de ir a hablar con "x" numero de operadores (y me da igual
que sea 1 o decenas o centenares), para convencerles de que permitan mi
prefijo mas largo que /32.

Sin embargo, hay que tener en cuenta que la politica permite que se te
asigne un /48. Pero como he dicho, el fondo del diseño de la politica no fue
para que esto se usara por defecto, sino que el defecto fuera /32, y de
hecho, a muchos receptores de IPv6 PI, se les han asignado /32, tanto
universidades como data centers, y probablemente otros muchos casos.

Es obvio que si yo tengo una universidad, no le voy a dar a cada laboratorio
un unico /64. Si yo tengo racks en un data center, es logico pensar que cada
rack pueda tener varias redes, y por tanto no le voy a dar solo un unico
/64. Cada oficina del banco puede ser mas compleja que un usuario
residencial, y por tanto necesita recibir un /48. Etc. Son solo algunos
ejemplos.

Yo no se si los hostmasters estan asignando por defecto a quienes solicitan
IPv6 PI un /48, anteriormente no era asi, sino que se asignaba /32 sin mas
justificacion. Quizas esto es necesario aclararlo.

Yo entiendo que una de las misiones de los RIRs es la conservacion del
espacio de direcciones, pero logicamente dentro de unos valores razonables,
y no llegando al final a fomentar NAT con IPv6 ni nada parecido. Tambien
ellos tienen que seguir los razonamientos de IETF que he intentado explicar
antes, y si es preciso, dar informacion a la comunidad de los posibles
contras si por defecto asignan un /48, explicando que hay la opcion de
justificar (si es preciso), la necesidad de un /32.

Para mi seria suficiente justificar un /32 (y de nuevo ese fue el principio
del diseño de la politica), con una afirmacion como "algunos operadores
filtran /32, no voy a usar todos los /48, pero no puedo permitirme el lujo
de ser filtrado". De igual forma que un ISP recibe tambien un /32 aunque no
use todos los /48.

Ademas, si a algunas peticiones de IPv6 PI se han asignado /32, no tiene
logica que se asigne /48 a otros, siendo la politica la misma. Quizas es un
tema exclusivamente de informar de los contras, como decia anteriormente a
las solicitudes que llegan y que por defecto piden /48 (si ese ha sido el
caso, que lo desconozco).

La realidad es que hay otros RIRs que si que utilizan /44, alla ellos. De
hecho, conozco varios casos que aun no han logrado, incluso despues de dos
años de trabajo, que sus prefijos sean visibles globalmente. NO creo que eso
lo desee nadie.

Es obvio que LACNIC, ni ningun RIR, garantiza el encaminamiento, pero
tambien es obvio, que las politicas y las asignaciones deben de seguir las
practicas generales de encaminamiento.

Y por tanto, de hecho, mi recomendación es tambien que se filtren los
prefijos mas largos que /32, tal y como siguen haciendo muchos operadores.
Sino, la agregacion que hemos diseñado para IPv6 como una de las metas, la
perdemos. Como tu bien has dicho, ya es el colmo que haya quien anuncie /64
! Acaso vamos a permitir que se anuncien /32 en IPv4 ??? Porque hay que
entender que el /64 es el tamaño minimo de un subred IPv6, asi como /32 lo
es en IPv4 (a causa de la posibilidad de hacer NAT).

Ademas, el coste de que filtremos prefijos /48 o /64, lo pagamos todos (cada
vez necesitamos router mas grandes y costosos, porque rompemos el diseño de
encaminado agregado de IPv6). Si todos empezamos a dejar libertad en este
sentido en lugar de seguir la regla del /32, nos van a compensar
economicamente por ello ?

Por ultimo, lo que he comentado aquí, se basa no solo en los razonamientos
dados, sino en nuestra experiencia de varios años, en los que hemos
desplegado o ayudado a desplegar IPv6 en cerca de 300 redes de muchos tipos.
Creo que es una experiencia muy fundada.

Saludos,
Jordi





From: "Fabián R. Mejía M." <mejiaf en aeprovi.org.ec>
Reply-To: <lactf en lac.ipv6tf.org>
Date: Tue, 29 Sep 2009 15:51:15 -0500
To: Latin America and Caribbean Region Network Operators Group
<lacnog en lacnic.net>, <lactf en lac.ipv6tf.org>
Subject: [LAC-TF] Bloques /48

Hola a todo en s
 
Aquellos que tienen algún tiempo trabajando con IPv6, quisiera que me
comenten cual es la experiencia real que han tenido con el enrutamiento de
prefijos /48 en el BGP de los grandes operadores, ¿Han sido bloqueados
alguna vez?, ¿qué restricciones (si las hay) han visto?.
 
En un túnel, yo recibo hasta unos cuantos bloques /64.
 

Saludos,
 
Fabián Mejía
 

-- 
Este mensaje ha sido analizado por MailScanner
<http://www.mailscanner.info/>
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.

_______________________________________________
LACTF mailing list
LACTF en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lactf




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