Subject: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 21 Oct 2020 22:37:42 -0700

Erik Kline has entered the following ballot position for
draft-ietf-v6ops-cpe-slaac-renum-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ section 3.2 ]

* I absolutely agree in principle at these other lifetimes should be updated
  to the shorter of the two applicable lifetimes, but I'm worried that this
  text is not sufficiently precise.  Specifically, this recommendation only
  applies to options that depend in any way on the change in the delegated
  prefix, yes?  Perhaps just this qualifier is sufficient?

  For example, none of these comparative lifetime recommendations apply to
  a stable ULA for a router that meets requirements ULA-[1..5] and chooses
  to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think.

  That being said, should this document also be saying that the ULA-derived
  options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot
  causes a new ULA to be generated (i.e. the one supposedly in stable storage
  is lost or otherwise unrecoverable)?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

[ section 3.1 ]

* With respect to the second bullet: the lifetimes need to be dynamically
  *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT
  values are always lower than the remaining PD lifetimes.  In this situation,
  the requirement is still that the lifetimes can be updated, but to the
  casual observer of the steady state the RA contents might appear static
  (e.g., while the PD'd prefix is continuously renewed).

  Maybe there's no text required here, but I didn't want a reader to be left
  with the impression that no two RAs could be identical

[[ nits ]]

[ section 3.3 ]

* In the 2nd bullet's 2nd bullet (this might be easier if these lists were
  numbered), it might be good to clarify that "the *deprecated* prefix can
  simply be advertised..."

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Oct 2020 10:11:24 -0400

I think it’s reasonable to assume that in some situations a ULA will be generated and not remembered, or that the /48 will be remembered but the subnetting will not be. E.g. this could happen in an HNCP-delegated network pretty easily. The set of behaviors we are seeing in existing border routers fairly constrained with respect to what is theoretically possible and even reasonable.  So I don’t think there’s a good reason to suggest different treatment for ULAs. 

> On Oct 22, 2020, at 01:37, Erik Kline via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Erik Kline <[email-masked]>
Date: Thu, 22 Oct 2020 07:28:12 -0700

I agree.  I just think then the text about "the lesser of two lifetime
values" doesn't quite read correctly nor give the impression that this
applies to things like ULA prefixes.  I think it's probably pretty
easy to fix with minimal text.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Oct 2020 11:34:59 -0300

Hello, Erik,

Thanks a lot for your comments! In-line....

On 22/10/20 02:37, Erik Kline via Datatracker wrote:
[....]> 
----------------------------------------------------------------------
>    prefix, yes? 

I'd say it applies to options that depend on the delegated prefix or the 
existence of the router that advertised them (which in a way are 
intimately related).

Local example at home:
I recently installed a backup connection. Both of my ISPs do IPv6.

Say I'm testing whether the setup works. I connect CPE1, connected to 
ISP1. Then Connect CPE2, connected to ISP2. Then unplug CPE1.

What's the usefulness of the options advertised by CPE1 if the only 
thing I have is CPE2? (e.g., ISP1 might have ACLs that only allows 
subscribers of ISP1 to use its recursive servers).

> Perhaps just this qualifier is sufficient?

You mean the qualifier instead of spelling out the option names? Or are 
you suggesting to add this clarification in addition to spelling out the 
option names.

(Adding the clarification, either in the second paragraph of Section 
3.2, or as one of the bullets in the "RATIONALE" below would be useful. 
OTOH, replacing the list of options with this note probably wouldn't 
(since then we're throwing the problem at implementers, who now need to 
know the analysis themselves).

>    to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think.

I see your point. However, my next question would be: do ULA 
implementations behave in that way? (most (if not all) of the CPEs I've 
run into don't treat ULAs in any special way).  And, what if (as you 
correctly noted in your review for the other companion document) you 
have two cascading routers, that do ULA+GUA, where the first router 
generates the /48 ULA, and the cascading one gets a leased ULA prefix 
from the former?

And, besides, if the options are not refreshed, that's because the 
corresponding router is gone. So, in that case, you wouldn't have a 
router that forwards your packets. And, if nodes are on-link, why not 
use link-locals instead.

>    is lost or otherwise unrecoverable)?

At least in my mental model, that was implied (i.e., I don't think that 
ULAs are special in this respect, because of the reasons noted above).

That said, are you suggesting that explicitly note this for ULA PIOs, or 
something else?  (me thinking out loud: I realize that for the CE Router 
connecting to the ISP, ULAs are special case in the sense that they are 
being locally generated... and hence it would make sense to be explicit 
about that).

Thoughts?

Agreed. How about if we tweak the bullet as:

       *  The lifetime values of prefixes advertised on the LAN-side via
          SLAAC must be dynamically updated (rather than static values),
          otherwise the advertised lifetimes would eventually span past
          the DHCPv6-PD lifetimes. In scenarios where the LAN-side
          configured option lifetimes (see Section 3.2 and Section 4) are
          always smaller than (or equal to) the  remaining DHCPv6-PD
          lifetimes, the LAN-side option lifetimes will exhibit constant
          values.

>    numbered), 

Will do the symbols-> numbers .

> it might be good to clarify that "the *deprecated* prefix can
>    simply be advertised..."

Will do.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Oct 2020 12:19:10 -0300

> easy to fix with minimal text.

My shot at it:

At the end of this:

    CE routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT.  CE
    routers SHOULD also set the PIO Preferred Lifetime to the lesser of
    the remaining preferred lifetime (see Section 3.1) and
    ND_PREFERRED_LIMIT, and the PIO Valid Lifetime to the lesser of the
    remaining valid lifetime and ND_VALID_LIMIT.

Add:

"If a ULA prefix is locally generated as specified in [RFC4193] and 
advertised on the LAN-side via PIO options, the corresponding PIO 
Preferred Lifetime and Valid Lifetime SHOULD be set to 
ND_PREFERRED_LIMIT and ND_VALID_LIMIT, respectively."

At the end of:

    CE Routers providing stateful address configuration via DHCPv6 SHOULD
    set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
    the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the
    valid-lifetime of the same option to the lesser of the remaining
    valid lifetime and ND_VALID_LIMIT.

Add:

"If a ULA prefix is locally generated as specified in [RFC4193] and 
employed for stateful address configuration via DHCPv6, the 
corresponding DHCPv6 IA Address Option preferred-lifetime and 
valid-lifetime SHOULD be set to ND_PREFERRED_LIMIT and ND_VALID_LIMIT, 
respectively.

Finally, for the DHCPv6-PD case, at the end of:

    CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6
    IA Prefix Option preferred-lifetime to the lesser of the remaining
    preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of
    the same option to the lesser of the remaining valid lifetime and
    ND_VALID_LIMIT.

Add:

"If a ULA prefix is locally generated as specified in [RFC4193] and the
  CE Router provides DHCPv6-PD on the LAN-side, it SHOULD set the DHCPv6
  IA Prefix Option preferred-lifetime to ND_PREFERRED_LIMIT, and the
  valid-lifetime of the same option to ND_VALID_LIMIT."

Thoughts?

P.S.: Bottom-line is that this is only special for ULA prefixes that are 
*locally* generated, since in that case there's only one lifetime 
involved (no "lifetimes" from the upstream).

Thanks,
Fernando