[LAC-TF] Sesion en IETF 95 (ERA: Re: implicaciones de declarar IPv4 historico)

Howard, Lee lee.howard at twcable.com
Wed Apr 6 19:10:10 BRT 2016 

Cómo no es prime-time?

What is missing? This draft document would only have affected IETF process, but if there are gaps the IETF needs to cover first, what still needs to be done?

Thanks,

Lee


From: LACTF <lactf-bounces at lacnic.net<mailto:lactf-bounces at lacnic.net>> on behalf of Arturo Servin <arturo.servin at gmail.com<mailto:arturo.servin at gmail.com>>
Reply-To: "lactf at lac.ipv6tf.org<mailto:lactf at lac.ipv6tf.org>" <lactf at lac.ipv6tf.org<mailto:lactf at lac.ipv6tf.org>>
Date: Wednesday, April 6, 2016 at 6:21 PM
To: "lactf at lac.ipv6tf.org<mailto:lactf at lac.ipv6tf.org>" <lactf at lac.ipv6tf.org<mailto:lactf at lac.ipv6tf.org>>
Subject: Re: [LAC-TF] Sesion en IETF 95 (ERA: Re: implicaciones de declarar IPv4 historico)


Yo sigo pensando que querer declarar IPv4 como historica por ahora es algo utopico aun y es querer negar la realidad de que IPv6 no es prime-time.

Slds
as


On Wed, 6 Apr 2016 at 18:38 JORDI PALET MARTINEZ <jordi.palet at consulintel.es<mailto:jordi.palet at consulintel.es>> wrote:
A mi lo que mas me “molesta” es lo que indico en el micro Geoff, pues creo que tiene razón.

Si el IETF abandona el desarrollo de IPv4, y surgen problemas o necesidades, entonces, se resolverán desde la industria de forma “no estándar” (como ocurrió con NAT).

Eso puede ser visto como ventaja o inconveniente:
1) Ventaja: Que proveedores querrían fiarse de un IPv4 que puede ser cambiante de formas no estándar y les crea problemas de interopaerabilidad ?

2) Desventaja: Obviamente, no seria estándar, pero es eso importante teniendo en cuenta 1)

La verdad es que no es facil.

Yo creo que es prudente iniciar el proceso de que IPv4 pase a histórico, indicando fechas concretas (1 año quizás dese que se apruebe el RFC), y poniendo como excepción que si se localizara una “bug” importante si que tendria que resolverse en IETF, pero no nuevos desarrollos, mejoras, etc.

Saludos,
Jordi








-----Mensaje original-----
De: LACTF <lactf-bounces at lacnic.net<mailto:lactf-bounces at lacnic.net>> en nombre de Nicolas Antoniello <nantoniello at gmail.com<mailto:nantoniello at gmail.com>>
Responder a: <lactf at lac.ipv6tf.org<mailto:lactf at lac.ipv6tf.org>>
Fecha: miércoles, 6 de abril de 2016, 12:12
Para: "lactf at lac.ipv6tf.org<mailto:lactf at lac.ipv6tf.org>" <lactf at lac.ipv6tf.org<mailto:lactf at lac.ipv6tf.org>>
Asunto: Re: [LAC-TF] Sesion en IETF 95 (ERA: Re: implicaciones de declarar IPv4 historico)

>En todo y en nada 😀
>Saco en limpio las siguientes observaciones y/o necesidades:
>
>- Es muy positivo comenzar a tener esta discusión ahora (temprano).
>- Es una discusión que probablemente dure unos años (3 o 4 al menos creo yo).
>- Desde el ounto de vista de ingeniería (mi opinion) no parece sensato cerrar el trabajo sobre un protocolo que soporta más del 90% del intercambio ACTUAL de datos en Internet global.
>- Es necesario y sano elaborar una lista de todos los posibles protocolos y estandares (RFCs) que se impacten potencialmente con esa definición y que sería necesario cambiarles y que no. Esto es algo que podemos comenzar a listar en esta lista (valga la pseudo-redundancia)... Alguno de nosotros puede recopilarla y volvarla al ámbito de IETF (yo me ofrezco a colaborar en esa lista).
>- Se trata de un "mensaje" que no es sino para la propia IETF en el que se llama a trabajar más sobre los "nuevos" protocolos en vez de invertir muchos recursos en continuar parcheando ciertos aspectos (carencias?) de IPv4.
>- Es necesario que la propia industria (que integra una gran mayoría dentro de IRTF) se ponga a trabajar mas fuerte y disponibilice más tecnologia (equipamiento más que nada de Home Networking creo yo) con amplio soporte de IPv6 en sus aplicaciones y funciones nativas... Que los routers domésticos no senlimiten solo a lo sumo a 2 SSIDs, que manejen bien la delegación de prefijos, que se vincules con otros organismos de estandarizacion para resolver el tema de optimizacion y uso de espectro (si explota la cantidad de redes domesticas, en mi opinión WiFi en su version actual no escala...); ETC...
>
>Seguro que Ale y/o otros que asistieron a la discusión tienen aún más aportes...
>Saludos,
>Nico
>
>
>El Wednesday, April 6, 2016, Fernando Gont <fgont at si6networks.com<mailto:fgont at si6networks.com>> escribió:
>
>En que quedo, al final?
>
>
>
>On 04/05/2016 05:09 PM, Azael Fernandez Alcantara wrote:
>> Buen Dia,
>>
>> En poco mas de 30 min. a las 17:40 hrs. Hora de Argentina (UTC/GMT -3
>> hours) durante IETF 95 desde Buenos Aires.
>>
>> Sunsetting IPv4
>>
>> Tema:
>> - IPv4 Declared Historic, Lee Howard
>>    draft-howard-sunset4-v4historic-00
>>
>> https://www.ietf.org/proceedings/95/slides/slides-95-sunset4-0.pdf
>>
>> Si participan remotamente no olvidar registrarse para que puedan preguntar:
>> https://www.ietf.org/meeting/register.html
>>
>> Por Meetecho:
>> http://www.meetecho.com/ietf95/sunset4
>>
>> Por audio:
>> http://ietf95streaming.dnsalias.net/ietf/ietf955.m3u
>>
>> SALUDOS
>> _______
>> Azael
>> ____________________________
>> Mensaje enviado sin acentos
>>
>> On Sun, 20 Mar 2016, villa at reduniv.edu.cu<mailto:villa at reduniv.edu.cu> <javascript:;> wrote:
>>
>>> Nico, como estas?
>>>
>>> En efecto suena demasiado apresurado. Cuando se define catalogar algo
>>> como Historico con independencia de las implicaciones que han
>>> comentado Jordi y Arturo, entre otros; significa que el interes en
>>> dicha tecnologia es minimo (o va siendo desestimado por un amplio
>>> sectore de la comunidad en aras de emplear otras tecnologias mas
>>> consolidadas) y por tanto no tiene sentido continuar esfuerzos de
>>> desarrollo respecto a la misma. Pero en el caso de IPv4 sigue habiando
>>> inversion, continua siendo por mucho el trafico mayoritario en
>>> Internet, seguimos debatiendo nuevas politicas relacionadas con IPv4
>>> en todos los RIRs (de asignaciones, de transferencias de recursos,
>>> etc.). Asi que aunque pueda ser una linea de deseo de algunos de los
>>> que estamos formando parte de este esfuerzo, creo que todavia no es el
>>> momento de declararlo historico.
>>>
>>> Saludos,
>>> Jorge
>>>
>>> From: Nicolas Antoniello
>>> Sent: Sunday, March 20, 2016 2:44 PM
>>> To: lactf at lac.ipv6tf.org<mailto:lactf at lac.ipv6tf.org> <javascript:;>
>>> Subject: Re: [LAC-TF] implicaciones de declarar IPv4 historico
>>>
>>> Lo de no trabajar mas los mecanismos de transición, ademas de que creo
>>> que es muy pronto, se me hace imposible... Si no, deciselo a los miles
>>> de CGN que andan desplegados por alli, combinados con 6RD u otros.
>>>
>>> Si bien suena muy tentador el pasarlo a historico, creo que la
>>> definición de la IETF de que implica histórico o bien es muy fuerte en
>>> este caso o bien es un tanto apresurado ejecutarla ahora.
>>>
>>>
>>> Saludos,
>>> Nico
>>>
>>>
>>>
>>> El Saturday, March 19, 2016, JORDI PALET MARTINEZ
>>> <jordi.palet at consulintel.es<mailto:jordi.palet at consulintel.es> <javascript:;>> escribió:
>>>
>>>  (respondiendo a Nico)
>>>
>>>  Como es muy corto, lo pego directamente en ingles:
>>>
>>>  2.  Implications
>>>
>>>     Moving an Internet Standard to the Historic maturity level does not
>>>     mean that it cannot be used.  It does mean that any Standards Track
>>>     RFC with a Normative reference to RFC791 is Historic.  This is
>>>     appropriate: any RFC defining IPv4 options is Historic.
>>>
>>>     In addition, some RFCs that refer to RFC791, such as [RFC1035]
>>>     "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" which defines A and
>>>     IN-ADDR.ARPA, will be Updated By this document, but are not Historic.
>>>     Other documents with incidental references to RFC791 should not be
>>>     affected.  Documents requiring updates are appropriate for [draft-
>>>     ietf-sunset4-gapanalysis].
>>>
>>>     The IETF does not update Historic RFCs.  Therefore, the IETF will no
>>>     longer work on IPv4 technologies, including transition technologies.
>>>
>>>     The term "IP," without address family specified, is assumed to mean
>>>     "IPv6."
>>>
>>>  3.  Security Considerations
>>>
>>>     It is possible that bugs inherent to IPv4 will yet be discovered.
>>>     Being Historic, the IETF will not further update IPv4.  Therefore,
>>>     for security reasons, the use of IPv6 exclusively is recommended.
>>>
>>>
>>>
>>>  Es decir, en resumen:
>>>  1) No significa que IPv4 no pueda ser usado.
>>>  2) Significa que los otros estándares con referencias normativas a la
>>> especificación original de IPv4 (es decir aquellos que definen
>>> “opciones”), tambien históricos, excepto algunos referidos a DNS u
>>> otras cuestiones con referencias incidentales a IPv4.
>>>  3) El IETF ya no trabajara en actualizaciones de los RFC declarados
>>> históricos.
>>>  4) El termino IP, sin referencia a la familia de direcciones,
>>> implicara IPv6 (en lugar de IPv4 como se sobreentiende ahora).
>>>  5) Si se descubren problemas de seguridad en IPv4, el IETF no
>>> trabajara en ellos.
>>>
>>>  Saludos,
>>>  Jordi
>>>
>>>
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>>  LACTF mailing list
>>>  LACTF at lacnic.net<mailto:LACTF at lacnic.net> <javascript:;>
>>>  https://mail.lacnic.net/mailman/listinfo/lactf
>>>  Cancelar suscripcion: lactf-unsubscribe at lacnic.net<mailto:lactf-unsubscribe at lacnic.net> <javascript:;>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lacnic.net<mailto:LACTF at lacnic.net> <javascript:;>
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net<mailto:lactf-unsubscribe at lacnic.net> <javascript:;>
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net<mailto:LACTF at lacnic.net> <javascript:;>
>> https://mail.lacnic.net/mailman/listinfo/lactf
>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net<mailto:lactf-unsubscribe at lacnic.net> <javascript:;>
>>
>
>
>--
>Fernando Gont
>SI6 Networks
>e-mail: fgont at si6networks.com<mailto:fgont at si6networks.com> <javascript:;>
>PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>_______________________________________________
>LACTF mailing list
>LACTF at lacnic.net<mailto:LACTF at lacnic.net> <javascript:;>
>https://mail.lacnic.net/mailman/listinfo/lactf
>Cancelar suscripcion: lactf-unsubscribe at lacnic.net<mailto:lactf-unsubscribe at lacnic.net> <javascript:;>
>
>
>
>
>_______________________________________________
>LACTF mailing list
>LACTF at lacnic.net<mailto:LACTF at lacnic.net>
>https://mail.lacnic.net/mailman/listinfo/lactf
>Cancelar suscripcion: lactf-unsubscribe at lacnic.net<mailto:lactf-unsubscribe at lacnic.net>


_______________________________________________
LACTF mailing list
LACTF at lacnic.net<mailto:LACTF at lacnic.net>
https://mail.lacnic.net/mailman/listinfo/lactf
Cancelar suscripcion: lactf-unsubscribe at lacnic.net<mailto:lactf-unsubscribe at lacnic.net>

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20160406/9337dd33/attachment.html>

More information about the LACTF mailing list