Subject: [v6ops] Erik Kline's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 21 Oct 2020 13:49:41 -0700

Erik Kline has entered the following ballot position for
draft-ietf-v6ops-slaac-renum-04: No Objection

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-slaac-renum/

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

[[ comments ]]

[ section 2.1 ]

* There should be some clarification that use of dynamic prefixes does
  not automatically imply flash renumbering, but rather that it increases
  the likelihood of a flash renumbering event occurring (basically make it
  clear that flash renumbering is the issue, not dynamically changing
  prefixes).

* There's also more than one layer of PD stability to be considered: the
  stability of the block delegated from the ISP to the modem/ISP-provided
  CPE (discussed here), and (for example) the stability of the prefix that's
  subdelegated to another router in the home (in cases where the user has
  purchased an additional router to place between nodes in the home and the
  ISP CPE).  In this way, even with stable ISP->CPE prefix delegation, it
  might be possible for the home router to get a different subprefix on
  reboot.

[ section 2.2 ]

* This section should make it clear that magnitude of the impact is a
  function of these timers and that these defaults are not necessarily in
  common use.  The text strongly implies that all flash renumbering events
  impact hosts for 7 days, and I don't think that's true.  (I don't think
  I've been on any dynamic prefix network that used these defaults for a
  long time.)

[ section 2.3 ]

* I support Ben's observation about authenticated RAs.

[[ nits ]]

[ abstract ]

* "will continue using stale prefixes" -> "may continue using stale prefixes"
  or "could" or "might" or "are likely to"

  I think "will" is only correct under very certain circumstances.

  Same text change in the first paragraph of the introduction as well.

[ section 1 ]

* "and and" -> "and"

* "configure for": perhaps "configured from" the previously-advertised prefix

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 19:45:51 -0300

Hi, Erik,

Thanks so much for your comments! In-line....

On 21/10/20 17:49, Erik Kline via Datatracker wrote:
[....]

How about adding this to the front of Section 2.1:

"In network scenarios where dynamic prefixes are employed, changes in 
the employed prefixes are propagated through the network, such that the 
renumbering event is handled in gracefully handled. However, if the 
renumbering event happens along with e.g. loss of configuration state by 
some of the devices involved in the renumbering procedure (e.g., a 
router crashes, reboots, and gets leased a new prefix), this may result 
in a flash-renumbering event, where new prefixes are introduced without 
properly phasing out the old ones".

?

Then tweak:
" In simple residential or small office scenarios, the problem discussed in
   this document would be avoided if DHCPv6-PD would lease "stable"
   prefixes."

(I've added "simple").

And then added a bullet in between the first and second that says:

"While an ISP might lease a stable prefixes to the home or small office, 
the Customer Edge router might in turn leases sub-prefixes of this 
prefixes to other internal network devices. Unless this late lease 
database is stored on non-volatile storage, these internal systems might 
be leased dynamic sub-prefixes from the otherwise stable prefix leased 
by the ISP. In other words, every time a prefix is leased there is the 
potential that the resulting prefixes are dynamic, even if the devices 
has been leased a stable prefix by its upstream router."

?

>    I've been on any dynamic prefix network that used these defaults for a

How about tweaking this section as:

---- cut here ----
The impact of the issue discussed in this document is a function of the 
lifetime values employed for the PIO lifetimes, since these values 
determine for how long the corresponding addresses will be preferred and 
considered valid. Thus, when the problem discussed in this document is 
experienced, the longer the PIO lifetimes, the higher the impact.

[RFC4861] specifies the following default PIO lifetime values:

    o  Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)

    o  Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)

    Under problematic circumstances, such as where the corresponding
    network information has become stale without any explicit signal from
    the network (as described in Section 1), it would take a host 7 days
    (one week) to deprecate the corresponding addresses, and 30 days (one
    month) to eventually invalidate and remove any addresses configured
    for the stale prefix.  This means that it will typically take hosts
    an unacceptably long period of time (on the order of several days) to
    recover from these scenarios.
---- cut here ----

Please do let me know if there's more to add/change.

Note: I have dynamic prefixes at home, and my Mikrotik router employs 
the RFC4861-specified default values. :-(

> * I support Ben's observation about authenticated RAs.

I'll s/RAs/unauthenticated RAs/. That say, are there any real 
deployments where RAs are authenticated?

>    Same text change in the first paragraph of the introduction as well.

Will do.

> * "configure for": perhaps "configured from" the previously-advertised prefix

Will do.

Thanks a lot!

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