[LACNIC/Politicas] Cambios en la pol í ticade IPv6 - 2

[JORDI PALET MARTINEZ]

Hola Roque,

Estoy deacuerdo contigo hasta cierto punto, el problema es que incialmente
se han hecho estas recomendaciones, basandose en el RFC3177, que bajo mi
punto de vista era bastante correcto.

Ahora se pretende cambiar estas recomendaciones en contra del RFC3177.

La cuestion al final es que si se publican BCPs e INFOs en IETF, y luego no
se hace caso de ellos, no se hasta que punto tiene sentido publicarlos ...
Pero esto es otra historia.

En cualquier caso, mis comentarios quieren ser practicidad. Que es lo logico
y que debemos evitar con la experiencia del daño que se ha hecho con IPv4 y
NAT (aunque bien es cierto que ha resuelto un problema inicialmente, pero en
este caso ya no hace falta).

La cuestion es que es razonable bajo el principio de conservacion ? Para mi,
480 años de vida (aunque fueran solo 150), me parecen suficientes y eso
implicaria /48, que es lo que tenemos hoy.

De acuerdo en que tenemos que definir como justificamos las asignaciones muy
grandes de LIRs, pero por el mismo principio de conservacion, acepto como se
viene haciendo. Seguimos pensando "en IPv4" (en blanco y negro por hacer una
comparacion), y pensamos que un telefono celular no necesita mas de un /64,
lo cual cada vez sera mas incorrecto. No pensamos en el coste de cambiar
esto cada x pocos años ... Y es un coste que pagamos TODOS.

Creo que quien debe de estar en el whois es algo diferente y debe de separse
de esta discusion. Lo llevaria de nuevo al tema de privacidad. El hecho de
obligar a inscribir en whos a cualquier usuarios residencial,
independientemente del tamaño de la asignacion, es una brecha contra la
privacidad y lo considero cada vez mas peligroso.

Entiendo que los RIRs tienen que contabilizar la realidad de las
asignaciones, pero el whois no es la herramienta apropiada y es facil
engañar. Luego es absurdo.

Es mucho mas facil diseñar un procedimiento automatico de verificacion desde
el LIR que periodicamente contabilize todas las asignaciones y el uso REAL.

Saludos,
Jordi




> De: "Gagliano Molla, Roque [NTK]" <Roque.Gagliano at sprint.com>
> Responder a: <Roque.Gagliano at sprint.com>
> Fecha: Fri, 14 Apr 2006 17:54:01 -0500
> Para: <jordi.palet at consulintel.es>, <politicas at lacnic.net>
> Conversación: [LACNIC/Politicas] Cambios en la políticade IPv6 - 2
> Asunto: RE: [LACNIC/Politicas] Cambios en la políticade IPv6 - 2
> 
> Jordi/Sebastian,
> 
> Creo que hay que tener cuidado en no perder el norte.
> 
> Lo que Lacnic regula son las reglas de juego a los ISPs para poder reclamar un
> bloque inicial, mantener un bloque o pedir una ampliacion. No me parece, y
> creo que nunca ha sido la intencion, que LACNIC deba regular como cada
> proveedor opera su red, comercializa sus servicios y maneja la reserva de sus
> recursos.
> 
> Creo que debemos concentrarnos en:
> 
> - Cual es la recomendacion de buenas practicas (BCP) que vamos a recomendar a
> los ISPs seguir de forma de asegurar que no van a tener problemas en sus
> renovaciones y hacer el proceso transparente. Aqui lo unico que LACNIC le
> deberia requerir a los proveedores es que aplique el principio de
> conservacion, el resto, de vuelta, son practicas que cada uno adopta.
> 
> - Cual es tamano de bloque minimo que se va a pedir para registrar en el
> Whois. Yo presentaba el caso de muchos proveedores que estan justificando
> asignaciones muy grandes usando /48 para cada usuario DSL o celular. Bueno,
> con la politica actual, cada uno de estos usuarios deberian estar en el whois.
> Si mantenemos el minimo en un /48 (como me parece a mi), pero recomendamos un
> /56 para clientes DOCSIS, DSL o celulares resolveriamos este problema tambien.
> 
> 
> Roque
> 
> 
> -----Original Message-----
> From: politicas-bounces at lacnic.net [mailto:politicas-bounces at lacnic.net] On
> Behalf Of JORDI PALET MARTINEZ
> Sent: Friday, April 14, 2006 5:23 PM
> To: politicas at lacnic.net
> Subject: Re: [LACNIC/Politicas] Cambios en la políticade IPv6 - 2
> 
> 
> Hola Sebastian, todos,
> 
> Ante todo perdonad por lo largo del email, pero es dificil de explicar con
> menos texto ...
> 
> Voy a intentar reproducir aquí, los mismos comentarios que he hecho a la
> politica equivalente en ARIN, y que en su momento ya hice presencialmente en
> APNIC, donde la respuesta mayoritaria fue en contra de esta politica, entre
> otros motivos, no solo por lo que expongo abajo, sino por las implicaciones
> que este cambio tendria en hardware que ya esta en el mercado, coste por parte
> de los fabricantes para hacerlo (que redunda en coste para los ISPs y los
> usuarios finales), y retraso en la introduccion de IPv6, que perjudica a todos
> en el desarrollo de la sociedad de la informacion.
> 
> Por otro lado, hemos pensado en la implicacion que esto tendria de desigualdad
> con aquellos que ya han recibido asignaciones basadas en el /48 (tanto
> usuarios finales por parte del ISP como ISPs por parte del RIR) ? Se les
> reclamaria la diferencia del espacio ? Si no es asi, es eso justo ?
> 
> Merece la pena el coste de reclamar este espacio frente al pretendido ahorro
> de direcciones que si bien ahora no se utilizan, si se utilizaran en el futuro
> ?
> 
> Tambien, si otras regiones no aprueban esta modificacion, no estaria LACNIC en
> desventaja en este aspecto ?
> 
> Insisto en que creo que un /48 por defecto debe de ser asignado a cualquier
> end-site cuando no se requiere espacio portable. Aun asi, yo estaria dispuesto
> a aceptar esta propuesta en determinadas condiciones que entiendo deberian de
> aclararse en el texto final de la politica:
> 
> 1) Que se garantize que un end-site tiene derecho a pedir el cambio del /64 o
> /56 al /48, sin necesidad de una justificacion detallada (la cual iria en
> contra de su privacidad).
> 
> 2) Que dicho cambio no supongo un incremento del coste mensual (es aceptable
> un coste de "setup" del cambio, y quizas una pequeña y razonable diferencia en
> el precio, basada en el coste adminstrativo equivalente al incremento de
> precio del ISP por parte de su pago a LACNIC, si lo hubiera, pero no un cargo
> que impida a la mayoria de los usuarios acceder a mas subredes).
> 
> 3) Que el usuario que pide esa actualizacion no tenga que renumerar su red, lo
> cual implica que el ISP reserve el /48 del cual asigna el /56 (o /64).
> 
> Hay quien considera que el /48 es malgastar el espacio de direcciones. En
> realidad lo que ocurre es que estamos acostumbrandos a IPv4 y nuestra mente no
> esta preparada para IPv6. Tenemos que entender que ese supuesto malgasto de
> direcciones no es tal si vemos que no se agotara en cientos de años y que si
> esto ocurriera, siempre podemos modificar la politica para volver a utilizar
> los /48 reservados y que los usuarios no hubieran pedido, aun cuando ello
> pudiera suponer renumerar muchos o todos los bloques de usuarios finales.
> Renumerar una vez en 100 años no es tan malo, si tenemos en cuenta que es
> dificil que un usuario siga con el mismo proveedor despues de tanto tiempo.
> 
> La idea final detrás de toda mi argumentacion es la situation en la que
> estamos hoy en la cual los usuarios no tienen mas remedio que utilizar NAT y
> generalmente disponen solo de una direccion IPv4 dinamica. No queremos repetir
> el mismo error con IPv6. Hay que ser conservadores, pero no propasarse, y los
> calculos mas pesimistas (con el cambio del HD-ratio que tambien se propone y
> que estoy seguro que sera aceptado en todas las
> regiones) indican que IPv6 sobreviria al menos 480 años. Seguimos creyendo
> entonces que es malgastar ? Alguien cree que IP seguira siendo IP (me da igual
> IPv4 que IPv6) en ese plazo ?
> 
> Por otro lado, os parecera exagerado que un hogar pueda tener necesidad de
> 65.000 subredes y que 256 subredes son suficientes, pero teniendo en cuenta
> los desarrollos que se estan produciendo en campos como el hogar digital, 256
> subredes no son suficientes. Quizas algo intermedio lo seria.
> 
> Tened tambien en cuenta que el concepto de usuario final aquí no es solo cada
> uno de nosotros en casa, sino tambien una pequeña o incluso mediana empresa
> que normalmente no tienen una conexión mejor con el ISP que la que nosotros
> tenemos en casa.
> 
> En españa cuesta 20 Euros una linea ADSL, y 12 Euros una IPv4. Considero que
> es un crimen, mas tratandose las direcciones de un bien de la humanidad. Pero
> mas alla de esto, los ISPs creen que hacen negocio con la venta de direcciones
> (que por otro lado podria considerarse ilegal y que se oculta como venta de
> servicios o clases de servicios), cuando en realidad de los 4.5 millones de
> usuarios de banda ancha en España, dudo que haya ni 100 pagando esos precios
> por las direcciones. El negocio por tanto no esta en vender las direcciones,
> sino asegurarse que estan estan disponibles de tal forma que se evite para
> siempre el NAT o algo similar y por tanto se pueden desplegar todo tipo de
> servicios y aplicaciones, por las que los usuarios si que pueden estar
> dispuestas a pagar y consecuentemente los ISPs si que pueden hacer negocio.
> 
> Recordad que en IPv6 ya no hablamos de direcciones, sino de subredes, se
> sobreentiende que hemos aceptado un modelo de IP en el que la unidad minima es
> un /64, lo cual permite cosas como autoconfiguracion, privacidad, CGAs, y
> muchas otras por venir seguramente.
> 
> Por ultimo, creo que debe de dejarse bien claro que en general solo veo un
> caso en el que se asignara un /64 (desde luego no en redes de banda ancha), y
> este seria el caso de un telefono celular al que no se conectedn otros
> dipositivos y por tanto que no tenga otras interfaces (pues si tiene otras
> interfaces, necesitas generalmente una subred /64 para cada una de ellas).
> Incluso un telefono movil puede considerarse un router movil, y de hecho ya
> hay muchos desarrollos en este sentido, ejemplo en medios de transporte, y por
> tanto necesita mas de un solo /64.
> 
> Para mas detalles, la discusion que continua en este sentido en ppml (ARIN).
> 
> Saludos,
> Jordi
> 
> 
> 
> 
>> De: Sebastian Bellagamba <sbellagamba at ssatelital.com.ar> Responder a:
>> <politicas-bounces at lacnic.net>
>> Fecha: Tue, 4 Apr 2006 15:17:21 -0300
>> Para: <politicas at lacnic.net>
>> Asunto: [LACNIC/Politicas] Cambios en la política de IPv6 - 2
>> 
>> Estimados,
>> 
>> El segundo cambio de propongo tiene que con las provisiones que se
>> establecen en Políticas de registración para la asignación y
>> adjudicación de direcciones IPv6 respecto al tamaño de las
>> asignaciones que deben realizar los LIRs.
>> 
>> El punto 5.4.1 Asignación del espacio de direcciones establece que:
>> 
>> "Las asignaciones deben ser realizadas de acuerdo con las
>> recomendaciones existentes [RFC3177,RIRs on 48], las cuales resumimos
>> aquí
>> como:
>> 
>> /48 en el caso general, excepto para suscriptores muy grandes /64
>> cuando cuando se conoce por diseño que una y solo una subred es
>> necesaria /128 cuando se conoce absolutamente que uno y solo un
>> dispositivo se está conectando."
>> 
>> De esto se desprende que la política establece que la asignación
>> mínima para un sitio final por defecto es un /48, y las otras son sólo
>> excepciones.
>> 
>> De esta manera, un usuario de banda ancha, una pequeña empresa o una
>> gran corporación obtendrían como asiganción inicial un /48. Separando
>> de los 128 bits que componen una dirección IPv6 los últimos 64 bits
>> (que están reservados a la interfase), cada uno de estos usuarios
>> podrían utilizar el espacio asignado para generar hasta 65536 subredes
>> (2^16, siendo los 16 bits los que surgen de 64-48). Entiendo que pocos
>> de esos usuarios finales tienen efectivamente una necesidad de manejar
>> 65536 subredes, por lo que realizar esta asignación conlleva un alto
>> grado de ineficiencia en la distribución de direcciones con el
>> consiguiente desperdicio.
>> 
>> Por lo tanto, propongo que se modifique la política de manera tal que
>> permita a los LIRs la asignación de /56s para el caso de usuarios
>> finales que sean pequeñas y medianas empresas, residenciales o redes
>> personales, donde el número de subredes potenciales exceda 1 pero no
>> exceda 256. Además, propongo que se cambie el párrafo referente a las
>> asignaciones /48, de manera que refiera específicamente a asignaciones
>> a grandes empresas y entornos corporativos finales cuyo requerimiento
>> es superior a 256 subredes. Tambiém, propongo que se tome como por
>> defecto la asignación /56, tanto para la definición de Utilización
>> (Punto 2.7) como para el cálculo del HD Ratio.
>> 
>> Es de notar aquí que, de aprobarse este cambio, numerosas correcciones
>> deberán realizarse al texto de esta política, dada la reiterada
>> aparición del /48 como tamaño por defecto de asignación.
>> 
>> Saludos
>> 
>> Sebastián Bellagamba | Director
>> www.ssatelital.com.ar
>>  
>> Tel: 5411 6334 1000 | Fax: 5411 6334 1010
>> Tte. Gral. J. D. Perón 949, 5º Piso, C1038AAS,
>> Buenos Aires, Argentina
>>  
>> sbellagamba at ssatelital.com.ar
>> 
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net http://www.lacnic.net/mailman/listinfo/politicas
> 
> 
> 
> 
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
> 
> 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 http://www.lacnic.net/mailman/listinfo/politicas
> 
> 




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

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

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.