[LACNIC/Politicas] Solicitudes IPv6

Thu Apr 14 09:51:41 BRT 2005

Hola Roque,

| Una pregunta para Ricardo, cuantas de las asignaciones corresponden a
| ccTLDs/redes academicas y cuantas a ISPs?

las 19 asignaciones /32 ipv6 que tenemos están distribuidas entre:

ccTLDs/redes academicas: 11
ISPs: 8

esta mas o menos balanceado.

Ricardo,

| Una idea de cara a la reunion de Peru, tener una presentacion sobre que
| estan haciendo en LacTLD sobre el tema. Algunas preguntas que se pueden
| responder alli: Que dominios se pueden resolver?, hay un plan global
| para la region?.
| 
| roque
| 
| 
| 
| On Wed, 2005-04-13 at 15:54, Oscar A. Robles-Garay wrote:
| > Más allá de todos los deseos que podamos tener para el desarrollo oportuno 
| > del IPv6 en nuestra región, tenemos 3 retos:
| > 
| > 1. Convencer a los ISPs grandes (Carriers incluídos) de que esto YA es 
| > necesario, a pesar de que son quienes requieren una mayor inversión.
| > 
| > 2. Convencer a los ISPs medianos y pequeños de que esto YA es necesario, a 
| > pesar de que son quienes tienen necesidades financieras m´sa apremiantes a 
| > corto plazo y para quienes 4 años es hablar de ciencia ficción.
| > 
| > 3. Convencer a los usuarios finales de que esto YA es necesario, a pesar 
| > que al día de hoy no lo conozcan y no perciban ningún valor agregado a su 
| > servicio y que pasará mucho tiempo para que lo perciban y además no tengan 
| > que pagar más por ello.
| > 
| > Saludos,
| > 
| > Oscar
| > 
| > 
| > At 12:30 p.m. 13/04/2005, JORDI PALET MARTINEZ wrote:
| > >Hola Oscar,
| > >
| > >Para mi, en este caso, medio-largo plazo es 1-2 años. Se dice que Internet
| > >se renueva y crece cada 6 meses (asi que considero que este es el corto).
| > >Por supuesto estas apreciaciones son personales, basadas en la experiencia
| > >en otras regiones. Perfectamente podriamos hablar de 3-4 años, pero habria
| > >poca diferencia, porque el hecho importante es que muchos ISPs pueden
| > >necesitar perfectamente 2 años en ponerse en marcha.
| > >
| > >Ya ha habido casos en Europa, incluso alguno en España, de clientes que han
| > >cambiado de ISP porque el suyo no ofrecia IPv6 ni respuestas de cuando.
| > >
| > >Conozco personalmente incluso algun caso de algun gran ISP que ha cambiado
| > >de ³carrier² (upstream provider) por este mismo motivo, y me consta que esto
| > >ha ocurrido ya tambien en AP y NA.
| > >
| > >Logicamente no puedo ³airear² nombres, y me gustaria ;-)
| > >
| > >Un buen ejemplo generico, sin dar nombres, serian organizaciones de defensa
| > >(gubernamentales y empresas que les suministran productos y servicios).
| > >
| > >Hay el hecho objetivo para la perdida de clientes, que depende de la calidad
| > >de servicio percibida. Cuando Microsoft lance la proxima generacion, IPv6
| > >estara activado por defecto. Hablamos del 2006, maximo 1.5 años. En este
| > >caso todas las aplicaciones funcionaran con IPv6, y si el ISP no ofrece
| > >soporte nativo ni mecanismos de transicion, la calida de servicio se
| > >deteriora, porque se utiliza Teredo con reles situados en otras redes de
| > >otros operadores, con lo cual ademas del overhead innecesario, se
| > >incrementan los retardos. Para el usuario, la culpa es del ISP (y en cierto
| > >modo lo es, por no tener una infraestructura mas preparada). Creeis que el
| > >cliente cambiara de SO, o dejara de utilizar esas aplicaciones ? No, siempre
| > >habra algun ISP que ofrezca mejor IPv6 (quizas tan solo con instalar un
| > >mecanismos de transicion en su red si no puede ofrecer soporte nativo).
| > >
| > >Hoy ya estas usando IPv6 con algunas aplicaciones Microsoft, sin saberlo ...
| > >
| > >Mi punto de vista es que los ISPs tienen que tener YA sus espacio de
| > >direcciones para:
| > >1. Experimentar en laboratorio.
| > >2. Establecer pilotos con terceros, quizas incluso con alguunos clientes.
| > >3. Planificar su transicion.
| > >4. En algunos casos instalar en la red sistemas que permitan la transicion
| > >(tunel brokers, 6to4, Teredo, otros)
| > >5. Hacer la transicion a dual stack de la red de core.
| > >6. Hacer la transicion a dual stack de la red de acceso.
| > >7. Desconectar IPv4 en la red de core (seria el final de la transicion, en
| > >el que el poco trafico IPv4 se transporta encapsulado en IPv6, pero hay
| > >casos en que esto puede ser el MEJOR comienzo, sustituyendo a los puntos 4,
| > >5, 6 y 7).
| > >
| > >Logicamente, no necesariamente hay que pasar por todos los pasos, depende de
| > >cada caso y circunstancias concretas, pero siempre requiere algunos meses
| > >como minimo, y sabemos lo que son estos proyectos en cualquier empresa. Esos
| > >1.5 años se quedan rapidamente cortos.
| > >
| > >Los IX son fundamentales en esto, son una infraestructura basica que hay que
| > >potenciar, y dotandoles de IPv6 facilitamos los pasos anteriores.
| > >
| > >
| > >
| > >Saludos,
| > >Jordi
| > >
| > >
| > >
| > >
| > >
| > >De: "Oscar A. Robles-Garay" <orobles at nic.mx>
| > >Responder a: <orobles at nic.mx>
| > >Fecha: Wed, 13 Apr 2005 12:01:36 -0500
| > >Para: <jordi.palet at consulintel.es>, <politicas at lacnic.net>
| > >Asunto: Re: [LACNIC/Politicas] Solicitudes IPv6
| > >
| > >Jordi,
| > >
| > >Permíteme entender mejor estos comentarios:
| > >
| > >At 07:24 a.m. 13/04/2005, JORDI PALET MARTINEZ wrote:
| > > > IPv6 no
| > > > necesariamente aporta negocio de por si, pero no ofrecerlo implica a
| > > > medio-largo plazo, perder clientes. Luego se pierde negocio.
| > >
| > >Cuando años representan para tí este medio-largo plazo?
| > >Porqué infieres que al no ofrecerlo al cabo de ese tiempo (los ISPs)
| > >perderán clientes? en qué te basas para ello?
| > >
| > >Saludos,
| > >
| > >Oscar
| > >
| > >
| > >
| > >
| > >************************************
| > >Barcelona 2005 Global IPv6 Summit
| > >Registration open. Information 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
| > _______________________________________________
| > Politicas mailing list
| > Politicas at lacnic.net
| > http://www.lacnic.net/mailman/listinfo/politicas
| 
| _______________________________________________
| Politicas mailing list
| Politicas at lacnic.net
| http://www.lacnic.net/mailman/listinfo/politicas
| 