[lacnog] [LAC-TF] Despliegue SLAAC y/o DHCPv6

[Fernando Gont]

Hola, Tomas,

Muchas gracias por tu respuesta! -- Inline....

On 01/17/2017 12:28 PM, Tomas Lynch wrote:
> 2017-01-17 6:12 GMT-05:00 Fernando Gont <fgont en si6networks.com
> <mailto:fgont en si6networks.com>>:
> 
>     Estimados,
> 
>     Para aquellos que hayan desplegado v6 en algun entorno de producción,
>     unas breves preguntas (sirvánse enviarlas off-list si es que lo
>     prefieren, o por algun motivo no quiren escribir por la lista):
> 
>     En lo referido a configuración automatica:
> 
>     1) Desplegaron SLAAC y/o DHCPv6? (es decir, solo SLAAC, solo DHCPv6, o
>     ambos?)
> 
>     2) En caso que hayan desplegado ambos:
>        2a) Que cosa hacen con cada protocolo?
>        2b) Que motivo la decisión?
> 
> En una operación con unos 12 BNGs cada uno con alrededor de 50.000
> subscriptores desplegamos SLAAC . Los DNS los pasamos por RADIUS con
> atributos específicos del vendedor.
> 
> Hicimos pruebas de DHCPv6 y SLAAC y el operador decidió por SLAAC por
> comodidad de configuración, i.e. quedaba parecida a la configuración de
> IPv4.

Pero... no hubiera sido mas similar DHCPv6?




>     3) Están al tanto de lo descripto en:
>     <https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem
>     <https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem>>?
> 
> 
> No.
>  
> 
> 
>     4) En caso que estén al tanto de "3)", o que lo estén ahora, tienen
>     alguna opinión al respecto?
> 
> 
> Parecería ser una mezcla fatídica entre ambigüedad de RFC e
> interpretación de esa ambigüedad por parte del implementador. En el caso
> que comento no puedo decir que haya habido o detectado problemas, o
> divergencias como las indicadas en el draft, ya que es difícil descubrir
> un problema asociado a él cuando en general en el mercado masivo se pide
> como primer paso apagar y prender todos los elementos del usuario final.

Si. El tema es que incluso en otros entornos (e.g., campus), dado que
distintos sistemas no soportan los mismo features, puede que tengas que
morir en proporcionar mucha informacion demanera redundante mediante
slaac + dhcpv6. EN tales casos, incluso en esos escenarios pueden
aparecer los comportamientos divergentes mencionados.


> Definitivamente necesitan ser reevaluados los flags mencionados,
> corregir el RFC correspondiente e indicar a los vendors la manera
> correcta de utilizarlos.

En lo personal, coincido. En la practica, lamentablemente dudo mucho que
sea realizable.


> Lo que no veo, o no leo, es qué propone el
> draft para evitar estas divergencias.

El draft intenta escribir el problema, lo cual uno esperaria que no
fuera necesario... Pero la muchachada de Google duda al respecto.

Tristemente, el problema relacionado de en general tener que soportar
tanto SLAAC como DHCPv6 (ambos) tampoco será solucionado.

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