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

[Fernando Gont <[e-mail]>]

Hi, Erik,

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

On 21/10/20 17:49, Erik Kline via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> 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.

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."

?



> [ 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.)

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. :-(


> [ section 2.3 ]
> 
> * 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?



> 
> 
> [[ 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.
> 

Will do.



> [ section 1 ]
> 
> * "and and" -> "and"
> 
> * "configure for": perhaps "configured from" the previously-advertised prefix

Will do.

Thanks a lot!

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