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

Wed Apr 6 12:12:32 BRT 2016

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> 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 <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 <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 <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 <javascript:;>
> >>  https://mail.lacnic.net/mailman/listinfo/lactf
> >>  Cancelar suscripcion: lactf-unsubscribe at lacnic.net <javascript:;>
> >>
> >>
> >>
> --------------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> LACTF mailing list
> >> LACTF at lacnic.net <javascript:;>
> >> https://mail.lacnic.net/mailman/listinfo/lactf
> >> Cancelar suscripcion: 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 <javascript:;>
> > https://mail.lacnic.net/mailman/listinfo/lactf
> > Cancelar suscripcion: lactf-unsubscribe at lacnic.net <javascript:;>
> >
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont at si6networks.com <javascript:;>
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net <javascript:;>
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe at lacnic.net <javascript:;>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20160406/81affd35/attachment.html>