Subject: [v6ops] Clarification/addition on the cpe-slaac doc.

From: Warren Kumari <[email-masked]>
Date: Wed, 10 Feb 2021 09:46:41 -0500

Dear V6OPS,

During the final editing of cpe-slaac, the authors noticed that we should
have included:
“WPD-10: CE routers SHOULD, by default, attempt to use a stable IAID value
that does not change between CE restarts, DHCPv6 client restarts, or
interface state changes. e.g., Transient PPP interfaces.”

To me this seems like an obvious and non-contentious clarification (it's
already required in RFC8145), and so I'm asking the authors to include it
while addressing the other IESG comments/ballots.

Please let me know by the end of Monday if you *strongly* object to this
change.
W

-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky

---

From: [email-masked]
Date: Wed, 10 Feb 2021 16:05:15 +0100

> During the final editing of cpe-slaac, the authors noticed that we should have included:
> “WPD-10: CE routers SHOULD, by default, attempt to use a stable IAID value that does not change between CE restarts, DHCPv6 client restarts, or interface state changes. e.g., Transient PPP interfaces.”
> 
> To me this seems like an obvious and non-contentious clarification (it's already required in RFC8145), and so I'm asking the authors to include it while addressing the other IESG comments/ballots.

I think you mean 8415, but at least all the digits are there.
I support the change, but I do think it should be strengthened.
An "unintended" change in IAID has dire consequences for the end-user network.

"WPD-10: CE routers MUST by default use a stable IAID value that does not change between CE restarts, DHCPv6 client restarts, or interface state changes. e.g., Transient PPP interfaces."

8415 has: "For any given use of an IA by the client, the IAID for that IA MUST be consistent across restarts of the DHCP client."...

Ole

---

From: Warren Kumari <[email-masked]>
Date: Wed, 10 Feb 2021 10:09:14 -0500

On Wed, Feb 10, 2021 at 10:05 AM <[email-masked]> wrote:

> > “WPD-10: CE routers SHOULD, by default, attempt to use a stable IAID
> value that does not change between CE restarts, DHCPv6 client restarts, or

I did indeed :-)

> "WPD-10: CE routers MUST by default use a stable IAID value that does not
> change between CE restarts, DHCPv6 client restarts, or interface state
> changes. e.g., Transient PPP interfaces."
>
> 8415 has: "For any given use of an IA by the client, the IAID for that IA
> MUST be consistent across restarts of the DHCP client."...
>

Fair enough. That's better, and the new proposed text; I actually intended
to copy and paste the RFC 8415 (see, I *can* type :-)) but forgot....
Thanks!
W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 10 Feb 2021 15:37:29 +0000

It seems odd to me to be cherry picking things for RFC-8415 to reiterate as requirements?

Doesn’t that open up the possibility that someone skips other things because “well it wasn’t in the CPE-SLAAC” requirements?

  *   Bernie

From: v6ops <[email-masked]> On Behalf Of Warren Kumari
Sent: Wednesday, February 10, 2021 10:09 AM
To: Ole Troan <[email-masked]>
Cc: IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] Clarification/addition on the cpe-slaac doc.

I did indeed :-)

Fair enough. That's better, and the new proposed text; I actually intended to copy and paste the RFC 8415 (see, I *can* type :-)) but forgot....
Thanks!
W

Ole

---

From: Richard Patterson <[email-masked]>
Date: Wed, 10 Feb 2021 17:15:53 +0000

My view is that it's worth directing the implementer's attention to, and
highlighting the importance of the clause in the context of non-fixed PDs.
People do miss things, or may not understand the impact, as obvious as it
may seem to us.

On Wed, 10 Feb 2021 at 15:38, Bernie Volz (volz) <volz=
[email-masked]> wrote:

> Doesn’t that open up the possibility that someone skips other things
> because “well it wasn’t in the CPE-SLAAC” requirements?
>
>
>
>    - Bernie
>
>
>
> *From:* v6ops <[email-masked]> *On Behalf Of * Warren Kumari
> *Sent:* Wednesday, February 10, 2021 10:09 AM
> *To:* Ole Troan <[email-masked]>
> *Cc:* IPv6 Operations <[email-masked]>
> *Subject:* Re: [v6ops] Clarification/addition on the cpe-slaac doc.
>
>
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 10 Feb 2021 14:11:31 -0300

Hi, Bernie,

> because “well it wasn’t in the CPE-SLAAC” requirements?

This was motivated by the default behavior of some popular CE Routers, 
which end up triggering the use of dynamic prefixes, because they simply 
randomize the IAID in such cases. So this is relevant here.

(One may wonder whether they are doing so by extrapolating RFC7844, or 
simply because they don't store the IAID on stable storage and also 
don't use an algorithm that always computes the same value...)

I think one could add this note to the corresponding subsection that 
explains the requirement:

    [RFC8415] requires that IAID for an IA MUST be consistent across
    restarts of the DHCP client. However, some popular CE Routers are
    known to select a new random IAIDs e.g. everytime the underlying PPP
    session is established. This could be the result of extrapolating the
    behavior described in [RFC7844], or simply a consequence of not
    storing the IAID on stable storage and failing to employ an algorithm
    that consistently generates the same IAID upon reboots. Thus, this
    requirement prevents CE Routers from inadvertently triggering a
    flash-renumbering event on the local network.

... or the like.

Thoughts?

Thanks!

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 10 Feb 2021 12:50:39 -0500

> because “well it wasn’t in the CPE-SLAAC” requirements?

Maybe, but I *think* that this requirement is more closely related to the
CPE-SLAAC that the others in RFC8415. We do already have some callouts to
RFC8415 like:
"This is in line with the requirement from Section 6.3 of [RFC8415], which
states that "if the delegated prefix or a prefix derived from it is advertised
for stateless address autoconfiguration [RFC4862], the advertised preferred
and valid lifetimes MUST NOT exceed the corresponding remaining lifetimes
of the delegated prefix."

Perhaps we should just clarify that this document just draws attention to
requirements in 8415, and doesn't replace it (which should be obvious, but
I agree may be worth doing).
W

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 10 Feb 2021 18:34:34 +0000

Yes, adding this further text would give a reason for why it is highlighted as a requirement.

- Bernie

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Wednesday, February 10, 2021 12:12 PM
To: Bernie Volz (volz) <[email-masked]>; Warren Kumari <[email-masked]>; Ole Troan <[email-masked]>
Cc: IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] Clarification/addition on the cpe-slaac doc.

Hi, Bernie,

> because “well it wasn’t in the CPE-SLAAC” requirements?

This was motivated by the default behavior of some popular CE Routers, which end up triggering the use of dynamic prefixes, because they simply randomize the IAID in such cases. So this is relevant here.

(One may wonder whether they are doing so by extrapolating RFC7844, or simply because they don't store the IAID on stable storage and also don't use an algorithm that always computes the same value...)

I think one could add this note to the corresponding subsection that explains the requirement:

... or the like.

Thoughts?

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 10 Feb 2021 15:19:53 -0300

Hi, Warren,

On 10/2/21 14:50, Warren Kumari wrote:
> 
> 
> On Wed, Feb 10, 2021 at 10:37 AM Bernie Volz (volz) <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
[....]
> 
> Perhaps we should just clarify that this document just draws attention 
> to requirements in 8415, and doesn't replace it (which should be 
> obvious, but I agree may be worth doing).

FWIW, something along these lines could be used for the content of the 
subsection that elaborates on the requirement:

Tweaks welcome :-)

Thanks,

---

From: Warren Kumari <[email-masked]>
Date: Thu, 18 Feb 2021 15:21:26 -0500

On Wed, Feb 10, 2021 at 2:02 PM Fernando Gont <[email-masked]> wrote:

> Thank you everyone who commented. This seems good to me.

Thanks again,
W