RE: draft-ietf-6man-slaac-renum: Processing of PIO Lifetimes at Hosts

[Vasilenko Eduard <[e-mail]>]

Hi all,
I completely agree to this: I think you need to tweak source address selection, not lifetimes.
In fact I propose 2 solutions:

1.      Long term: solution that I have proposed in this alias before (see below – new flag in RA). As soon as ND would have major refreshment – it should be already in one of RFC updates ready for cut & paste.

2.      Short term: properly choose address on host side. I am not sure should it be update to HE or RFC 6724 (better last one, but HE is more popular). It is easy – just prefer the address that has longer preferred time (if scope and mask are the same).
Both solutions is better to documented in standards. I do not insist on my long-term solution to be properly documented (it is for future anyway – needs ND versioning), but I am sure that for short-term Lorenzo is right.


Long term clean fix:

> RA (section 4.2 RFC4861) has 2 flags and 6 bits reserved.

> I propose to use 1 bit from reserved for additional flag: "C"="Complete". It would mean that RA has all information in this packet, including all PIOs.

> If host have recorded before some other information from the *same router* (same LLA) - then absence of this information in last RA means that information should be deprecated, irrespective of timers.

> I propose to immediately put address from missing PIO into " deprecated " state up to the end of the life for this prefix.

Eduard
From: ipv6 [mailto:[e-mail]] On Behalf Of Lorenzo Colitti
Sent: 7 сентября 2020 г. 6:19
To: Fernando Gont <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-ietf-6man-slaac-renum: Processing of PIO Lifetimes at Hosts

I disagree with this change because it reduces the expressiveness of SLAAC as a configuration protocol. It effectively turns a 32-bit field into a 16-bit field, and makes it no longer possible to have lifetimes that outlive the default router lifetime. This often is a valid configuration. In particular, it is a valid configuration when the IPv6 prefix is statically allocated. This is often the case in enterprise networks, but is also often the case in residential networks as well. My IPv6 prefix is static, for example.

It also complicated host implementations. If you want to make this more reliable, I think you need to tweak source address selection, not lifetimes.

On Sun, Sep 6, 2020 at 10:00 PM Fernando Gont <[e-mail]<mailto:[e-mail]>> wrote:
Folks,

We continue discussing each of the mitigation proposals that we had in
draft-gont-6man-slaac-renum.

The next one is about processing PIOs at hosts, such that hosts cap the
received values to the advertised Route Lifetime -- except when the
Router Lifetime is set to the special value 0 ("do not use this router
as a default router") or when the prefix lifetimes are set to the
special value 0xffffffff ("infinity").

This allows hosts to use more appropriate lifetimes even if routers are
employing the large default values from RFC4861.

The text is:

---- cut here ----
4.1.2.  Processing of PIO Lifetimes at Hosts

    Hosts SHOULD cap the "Preferred Lifetime" and "Valid Lifetime" of
    PIOs as follows:

    o  IF (Router Lifetime != 0) AND (Preferred Lifetime != 0xffffffff)
       AND (Valid Lifetime != 0xffffffff), then:

          Preferred Lifetime= MIN(Preferred Lifetime, "Router Lifetime")

          Valid Lifetime= MIN(Valid Lifetime, 2 * "Router Lifetime")

    RATIONALE:

       *  Capping the lifetimes in PIOs as suggested will not eliminate
          the problem discussed in this document, but will certainly
          reduce the amount of time it takes for hosts to converge to
          updated network configuration information, even when the SLAAC
          router advertises PIOs with the default values specified in
          [RFC4861] (as opposed to the new default values specified in
          Section 4.1.1) or when the corresponding router ceases to send
          RAs.

       *  A Router Lifetime of 0 has the special meaning of "this router
          is not to be employed as a default router", and may be employed
          only to advertise prefixes via SLAAC (but not as a default
          router).  As a result, PIO lifetimes are not capped when Router
          Lifetime == 0.

       *  A PIO lifetime of 0xffffffff has the special meaning of
          "infinity", which means that these prefixes (and their
          corresponding addresses) should never time out.  As a result,
          PIO lifetimes are not capped when the PIO Valid Lifetime ==
          0xffffffff or the PIO Preferred Lifetime == 0xffffffff.
---- cut here ----

The text has been slightly tweaked to reflect recent discussions.


Thoughts?

Thanks!

Regards,
--
Fernando Gont
SI6 Networks
e-mail: [e-mail]<mailto:[e-mail]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------