[lacnog] Problemas en torno a SLAAC/DHCPv6-PD (nuevo IETF I-D)

[Fernando Gont]

On 31/1/19 09:42, Fernando Frediani wrote:
[....]
> 
> Thanks for sharing this with us.

You're welcome!


> 
> This behavior is quiet common in some scenarios and causes,
> unfortunately, different views from users and some technical people
> believing that "IPv6 is making Internet slower".
> I had the impression, in some occasions, that old IPv6 addresses hang in
> devices were more a OS issue than a SLAAC, but what you describe in the
> Draft makes sense.

This might be the case in some scenarios (see e.g. a somewhat recent
post on the ipv6hackers
<https://www.si6networks.com/community/mailing-lists.html>
mailing-list). However, our I-D describes a case that is not
OS-dependent but rather spec-dependent, so to speak.


> 
> One thing I have sympathy is, where possible, allocate always stable
> prefixes so the same Prefix to the same user using the
> Delegated-IPv6-Prefix and Delegated-IPv6-Prefix-Pool in RADIUS and
> therefore eliminating this issue, easing the user identification should
> you are required by the Estate and reducing the amount of necessary log.

That's one side of it. The other side of allocating stable prefixes is
that such practice renders things like temporary addresses rather
irrelevant: no matter how much the Interface-ID changes, you can still
correlate network activity via the Prefix (because it's stable).

It would seem that in some countries (e.g., Germany) it's actually
*required* that CPEs default to dynamic prefixes.



> Reading the Draft I am wondering here how and if this mechanism could
> also be applicable for something I have put here a while ago: two CPEs
> in the same Layer 2 advertising their addresses with different
> Priorities and one the one with higher priority looses connectivity to
> the upstream immediately deprecate its addresses announced to the LAN
> letting the less priority CPE addresses be the ones used by devices to
> go out to the internet making the IPv6 failover seamless in Home/SOHO
> scenarios where BGP is not available or suitable.

It would seem this mechanism wouldn't help, since it kicks in when a
router ceases to advertise a prefix it used to advertise, and advertise
a different prefix in return. In the scenario you describe, I guess the
lower-priority router would refrain/stop advertising its prefix but
wouldn't "replace" the new prefix with a different one.

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