[LAC-TF] Fwd: "secured" IPv6 addresses

Fernando Gont fgont at si6networks.com
Sun Aug 28 22:39:22 BRT 2016


Estimados,

Alguno que use Mac y que por una de ellas haya probado esta beta (lo que
sea que ello signifique :-) ), podría confirmar lo de abajo? (ver mail
forwardeado al final)

Desconozco *que* usan las Mac para autoconfiguración (por ej.,
implmentancion en el kernel vs. uso de dhcpcd (*) ).

Esto pareciera ser una buena noticia. Si bien en el ambito de IETF hace
mas o menos 4 años que le venimos dando vueltas a este asunto ;-), el
RFC7217 (**) fue publicado en Abril de 2014, y OSes basados en Linux han
incorporado RFC7217 por sobre el esquema tradicional de generar
direccinoes IPv6, embebiendo la direccion Mac de la placa de red.


(*) dhcpcd implementa todo lo que es configuracion de interfaces de red.
Es decir, *no* es simplemente/unicamente un cliente dhcp sino que, por
ejemplo, implementa slaac en user space.

(**) RFC7217 es una obra realizada en Argentina, bajo la filosofia
maradoniana. Durante su proceso de publicacion, se tuvieron que sortear
obstaculos tales como: algun gran fabricante sugiriendo que tenian una
patente sobre la misma (que te pasha, M$?), y argumentos para no
publicar el estandar durante la propia revisión del IESG. Se logro
publicar el documento, evitando argumentos de patentes y permitiendo
entonces la libre implementación del estandar
(<https://www.youtube.com/watch?v=pAyoml7PycQ>). Esto es, si se quiere,
mas una "falla" ("discontinuidad" :-) ) del sistema, que algo
sostenible: por un lado, porque la región se encuentra en desventaja en
todos estos "entornos", y por otro lado, por problemas propios de la
región (<https://www.youtube.com/watch?v=HyexCdOUokY>).

Saludos cordiales,
Fernando




-------- Forwarded Message --------
Subject: 	"secured" IPv6 addresses
Date: 	Sun, 28 Aug 2016 20:59:20 +0200
From: 	Iljitsch van Beijnum <iljitsch at muada.com>
To: 	ipv6-dev at lists.apple.com



Hi all,

I've installed the most recent public beta, and I see something interesting:

en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
        ether 40:6c:8f:32:4b:c3         inet6
fe80::8f:b474:a9dc:4174%en4 prefixlen 64 secured scopeid 0x9
inet 192.168.178.20 netmask 0xffffff00 broadcast 192.168.178.255
        inet6 2001:470:1f15:8b5:df:900f:a6a3:715c prefixlen 64 autoconf
secured         inet6 2001:470:1f15:8b5:f54c:e5dc:fb28:ddca prefixlen 64
autoconf temporary         nd6 options=201<PERFORMNUD,DAD>
        media: autoselect (1000baseT
<full-duplex,flow-control,energy-efficient-ethernet>)
        status: active

Previously, the link local address as well as the stateless autoconfig
non-temporary address were derived from the Ethernet MAC address. That
is no longer the case, the system now seems to create persistent link
local and stateless autoconfig addresses that are not directly derived
from the MAC address. I believe Windows also does this.

These addresses survive reboots but not a clean reinstall of the system.

I can't find any documentation on how this works, though. Is there an
RFC or something else that describes these secured addresses? How are
they generated?




More information about the LACTF mailing list