[LAC-TF] PuBlicación de RFC8064 (Fwd: RFC 8064 on Recommendation on Stable IPv6 Interface Identifiers)

Thu Feb 23 00:26:10 BRT 2017

Felicitaciones Fernando !!! por tu aporte y trabajo constante que deja huella plasmada en RFCs y es digno de resaltar.

Rafael Sandoval

Get Outlook for iOS<https://aka.ms/o0ukef>

On Wed, Feb 22, 2017 at 9:28 PM -0500, "Fernando Gont" <fgont at si6networks.com<mailto:fgont at si6networks.com>> wrote:

(por si hace falta la aclaración, hubo un error te tipeo en el Subject :-) )

On 02/22/2017 10:39 PM, Fernando Gont wrote:
> Estimados,
>
> Se acaba de publicar el RFC8064
> (), del cual soy co-autor.
> Este RFC basicamente recomienda la implementacion y utilización de
> RFC7217 (), del cual soy
> autor, para la generación de direcciones con SLAAC.
>
> Este documento actualiza 14 estandares, incluyendo la Arquitectura de
> Direccionamiento de IPv6.
>
> Debajo les dejo una especie de "rant"/descripción/explicación en formato
> de preguntas y respuestas.
>
>
> *** FAQs ***
>
> 1) ¿Que hace este RFC?
>
> Este documento recomienda el RFC7217 (de mi autoria) para generar
> direcciones mediante SLAAC. El uso de direcciones utiizando ahora
> "Modified EUI-64 forma identifiers" (embeber la direccion MAC en el
> identificador de interfaz) es ahora *no recomendada*
>
> Este RFC, basicamente, hace lo que propuse unilateralmente hace mas de 5
> años atras, en este documento:
> .
>
>
> 2) ¿Existen implementaciones de RFC7217?
>
> Si, claro. RFC7217 ha sido implementado en linux kernel desde la version
> 4.0. Tambien en Network Manager v1.0.4, y dhcpd desde alguna version que
> no recuerdo.
>
> Sistemas operativos como Fedora 24 y Mac OS (desconozco la version
> especifica) utilizan por defecto el RFC7217.
>
> Dependiendo de cada sistema operativo en particular, podría ocurrir que
> al actualizarlo, las direcciones IPv6 correspondientes cambien (lease:
> que pases de usar las direcciones SLAAC tradicionales, a usar RFC7217)
>
>
> 3) ¿Como es que todo esto (reemplazar a las direcciones SLAAC
> tradicionales) tardó tanto tiempo?
>
> Porque los grandes vendors tienen demasiada influencia en los procesos
> de IETF.
>
> La propuesta original antes mencionada hacia, en un solo documento, lo
> que IETF decidio hacer en 3 (RFC7217, RFC7721, y RFC8064).
> Originalmente, se opusieron a que RFC7217 reemplace las direcciones
> SLAAC tradicionales, y solo permitieron que se publicara una
> especificacion (RFC7217) proponiendo un esquema alternativo, pero sin
> actualizar formalmente ningun estandar.
>
> Durante todo el proceso, fabricantes de dispositivos moviles se
> opusieron a la idea, ya que segun ellos "por que habria el usuatio de
> querer privacidad?" y "la privacidad deberia ser un opt-in, no un
> opt-out". Luego intentaron afectar la publicacion de RFC7217 de todas
> las formas posibles...desde sugerir que habian patentes de Microsoft
> sobre el mismo, hasta sugerir la publicacion del documento como
> "Informational" en vez de como Standards Track durante la revisión de IESG.
>
> La publicación de RFC7217 como estandar fue casi un milagro.
>
>
> 4) Entiendo que la unica substancia del RFC8064 está en recomendar
> RFC7217. Tengo entendido que en su momento se te sugirió incorporar
> co-autores de algunos grandes vendors al RFC7217, sugieriendo que el
> proceso de publicacion "sería mas facil". ¿Por que no lo hiciste?
>
> Porque Diego Maradona me enseño que "la pelota no se mancha"
> (), y que no hay que
> permitir que "le tmen la leche al gato".
>
>
>
> 5) Durante el proceso de publicación del RFC8064, vi que fue
> principalmente el primer co-autor el que uso energía en el mismo.
>
> Esto no es así. Mi co-autora, y chair electa de IETF, se encargo de que
> la calidad de los "Acknowledgements" del RFC estén al nivel que IETF
> merece (). Pueden encontrar mas información en:
>
>
>
> 6) ¿Es cierto que hubo gente de Cisco que se opuso a la idea de este
> documento?
>
> Si. No querían tener que trabajar en modificar el codigo de sus routers.
>
>
> 7) ¿Es cierto que gente de Google sigue defendiendo el esquema de
> embeber direcciones MAC en los identificadores de Interfaz IPv6?
>
> Si. Aunque es de notar que no es la unica idea descabellada que tienen.
>
>
> 8) El RFC8064 actualiza 14 estandares. Viendo RFCs de tu autoria
> (), veo que has hecho actualizaciones a una gran
> cantidad de RFCs de IPv6, incluyendo el propio RFC2460. ¿Que opinion
> tenes respecto de los estandares de IPv6, y de sus implementaciones?
>
> Creo que tienen, a lo sumo, la misma madurez que las implementaciones de
> IPv4 de principios de los años '90.
>
>
> 9) Lei por ahi que Latinoamerica tiene un dream team en IETF. Que opinás?
>
> En el mejor de los casos, uno solo podria ver tal aseveración como un
> exceso de optimismo.
>
> Personalmente, creo que Latinoamerica no tiene un dream team. Es mas,
> creo que no tiene ni "team", ni tampoco "dreams".
>
>
> 10) ¿Hay alguien a quien agradecer respecto a tu trabajo en IETF0
>
> Si. Los que el 6man wg decidio sacar de los "Acknowledgements":
>
>    Fernando Gont would like to thank Nelida Garcia and Guillermo Daniel
>    Gont for their love and support, and Jorge Oscar Gont and Diego
>    Armando Maradona for their inspiration.
>
> Asimismo, a Iván Arce (a quien ya habia agredecido en RFC8021).
>
>
> 11) Algunos de tus RFCs agradecen a Diego Maradona. ¿No es esto una
> muestra de inmadurez, poca cultura, o similares?
>
> Esta pregunta lo es. Si has estudiado minimamente la vida de Maradona
> (de donde vino, lo que hizo, en que contexto lo hizo, y a que cosas se
> enfrento), el crédito no merece demasiada explicación.
>
>
> 12) ¿Que se podría hacer para mejorar el nivel de participación de IETF
> en la región?
>
> Si quienes fomentan la participación latinoamericana en IETF hicieran un
> 50% de lo que Ivan Arce, y tuvieran un 50% de sus agallas para llamar a
> las cosas por su nombre, las condiciones de participación de
> latinoamerica serian mejores... o al menos tendriamos un mejor y mas
> honesto punto de partida.
>
> El hecho de que las estrategias para mejoras en participación
> latinoamericana se discuten en hoteles estilo Hilton de lugares como
> Tokio y Seul (lease, lejos de la región), con discusiones dominadas por
> personas que no viven en la región ni tienen conocimiento directo sobre
> lo que es participar en IETF desde latinomaerica, te puede dar una pauta
> de las expectativas que se pueden tener respecto del fruto de dichas
> reuniones.
>
> Estaría genial que alguien, alguna vez, le pregunte a alguien que
> escriba RFCs para la región cuales son las trabas que ha encontrado o
> encuentra para la participación en IETF. En lo personal, soy autor de
> mas el 80% de los RFCs de la región, y me he cansado de ver esoterismo y
> teorias varias a la hora de fomentar la participacion latinoamericana en
> la región -- teorias que cualquiera que haya participado desde la región
> (o lo haya hecho sin ser parte de alguno de los dueños del kiosko) puede
> darse cuenta que son equivocadas.
>
> Jamas se han discutido en la región ninguno de los problemas de fondo
> que afectan a la participación latinoamericana en IETF. Tal vez, porque
> se pretende que se mejore la situación de latinoamerica sin afectar el
> status quo de quienes tradicionalmente han dominado IETF. Algo imposible.
>
> Saludos cordiales,
> Fernando Gont
> ()
>
>
>
>
> -------- Forwarded Message --------
> Subject: RFC 8064 on Recommendation on Stable IPv6 Interface Identifiers
> Date: Wed, 22 Feb 2017 14:56:37 -0800 (PST)
> From: rfc-editor at rfc-editor.org
> To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org
> CC: drafts-update-ref at iana.org, ipv6 at ietf.org, rfc-editor at rfc-editor.org
>
> A new Request for Comments is now available in online RFC libraries.
>
>                 RFC 8064
>
>         Title:      Recommendation on Stable IPv6 Interface
>        Identifiers         Author:     F. Gont, A. Cooper,
>                     D. Thaler, W. Liu
>         Status:     Standards Track
>         Stream:     IETF
>         Date:       February 2017
>         Mailbox:    fgont at si6networks.com,
> alcoop at cisco.com,                     dthaler at microsoft.com,
>          liushucheng at huawei.com
>         Pages:      9
>         Characters: 19179
>         Updates:    RFC 2464, RFC 2467, RFC 2470, RFC 2491,
>        RFC 2492, RFC 2497, RFC 2590, RFC 3146,                     RFC
> 3572, RFC 4291, RFC 4338, RFC 4391,                     RFC 5072, RFC 5121
>
>         I-D Tag:    draft-ietf-6man-default-iids-16.txt
>
>         URL:        https://www.rfc-editor.org/info/rfc8064
>
>         DOI:        10.17487/RFC8064
>
> This document changes the recommended default Interface Identifier
> (IID) generation scheme for cases where Stateless Address
> Autoconfiguration (SLAAC) is used to generate a stable IPv6 address.
> It recommends using the mechanism specified in RFC 7217 in such
> cases, and recommends against embedding stable link-layer addresses
> in IPv6 IIDs.  It formally updates RFC 2464, RFC 2467, RFC 2470, RFC
> 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC
> 4338, RFC 4391, RFC 5072, and RFC 5121.  This document does not
> change any existing recommendations concerning the use of temporary
> addresses as specified in RFC 4941.
>
> This document is a product of the IPv6 Maintenance Working Group of the
> IETF.
>
> This is now a Proposed Standard.
>
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for
> the standardization state and status of this protocol.  Distribution of
> this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor at rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20170223/daa94464/attachment.html>