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

Wed Feb 22 22:39:40 BRT 2017

Estimados,

Se acaba de publicar el RFC8064
(<http://www.rfc-editor.org/rfc/rfc8064.txt>), del cual soy co-autor.
Este RFC basicamente recomienda la implementacion y utilización de
RFC7217 (<http://www.rfc-editor.org/rfc/rfc7217.txt>), 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:
<https://www.ietf.org/archive/id/draft-gont-6man-stable-privacy-addresses-00.txt>.

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"
(<https://www.youtube.com/watch?v=1YhNGEA8wzo>), 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 (<https://goo.gl/1a3Hya>). Pueden encontrar mas información en:
<https://goo.gl/oqTKtA>

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
(<https://goo.gl/sGAuFg>), 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
(<https://goo.gl/2aB2KL>)

-------- 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
--------------------------------------------------------------------