<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-01-17 6:12 GMT-05:00 Fernando Gont <span dir="ltr"><<a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Estimados,<br>
<br>
Para aquellos que hayan desplegado v6 en algun entorno de producción,<br>
unas breves preguntas (sirvánse enviarlas off-list si es que lo<br>
prefieren, o por algun motivo no quiren escribir por la lista):<br>
<br>
En lo referido a configuración automatica:<br>
<br>
1) Desplegaron SLAAC y/o DHCPv6? (es decir, solo SLAAC, solo DHCPv6, o<br>
ambos?)<br>
<br>
2) En caso que hayan desplegado ambos:<br>
   2a) Que cosa hacen con cada protocolo?<br>
   2b) Que motivo la decisión?<br>
<br></blockquote><div>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.<br><br></div><div>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.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Están al tanto de lo descripto en:<br>
<<a href="https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem" rel="noreferrer" target="_blank">https://tools.ietf.org/html/<wbr>draft-ietf-v6ops-dhcpv6-slaac-<wbr>problem</a>>?<br></blockquote><div><br></div><div>No.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4) En caso que estén al tanto de "3)", o que lo estén ahora, tienen<br>
alguna opinión al respecto?<br></blockquote><div><br></div><div>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.<br><br></div><div>Definitivamente necesitan ser reevaluados los flags mencionados, corregir el RFC correspondiente e indicar a los vendors la manera correcta de utilizarlos. Lo que no veo, o no leo, es qué propone el draft para evitar estas divergencias. Puede ser también que no tenga un conocimiento amplio sobre cómo funcionan los drafts, RFCs, etc.<br><br></div><div>Tomás Lynch<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Saludos, y gracias!<br>
--<br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href="mailto:fgont@si6networks.com">fgont@si6networks.com</a><br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
LACTF mailing list<br>
<a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lactf" rel="noreferrer" target="_blank">https://mail.lacnic.net/<wbr>mailman/listinfo/lactf</a><br>
Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a></blockquote></div><br></div></div>