Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-slaac-renum-04: (with DISCUSS and COMMENT)

[Fernando Gont <[e-mail]>]

Hello, Ben,

Thanks so much for your detailed review! In-line.....


On 20/10/20 20:40, Benjamin Kaduk via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> In Section 2.3 we make a claim about item 'e)' of section 5.5.3 of RFC
> 4862, in particular that it says that 'an RA may never reduce the
> RemainingLifetime" to less than two hours', but the relevant text from RFC
> 4862 seems to be:
> 
>        2.  If RemainingLifetime is less than or equal to 2 hours, ignore
>            the Prefix Information option with regards to the valid
>            lifetime, unless the Router Advertisement from which this
>            option was obtained has been authenticated (e.g., via Secure
>            Neighbor Discovery [RFC3971]).  If the Router Advertisement
>            was authenticated, the valid lifetime of the corresponding
>            address should be set to the Valid Lifetime in the received
>            option.
> 
> which clearly allows an *authenticated* RA to reduce the
> "RemainingLifetime" to smaller values.  (Text with a similar
> not-quite-accurate statement appears in Section 2.4 of this document as
> well.)

I know of no-real world deployment where RAs are authenticated.

That said, would noting "unauthenticated RA" in our draft address your 
comment?




> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I look forward to seeing the more comprehensive solution/advice in
> draft-ietf-6man-slaac-renum and draft-ietf-6man-cpe-slaac-renum
> progress.
> 
> I note that https://www.rfc-editor.org/materials/abbrev.expansion.txt
> does not mark "CPE" as "well-known", implying that we should probably
> expand it on first use.

Our bad. We should use "CE Router" rather than "CPE", which is the term 
employed in RFC7084. Will fix this.



> Section 1
> 
>     Scenarios where this problem may arise include, but are not limited
>     to, the following:
> 
>     o  The most common IPv6 deployment scenario for residential or small
>        office networks is that in which a CPE router employs DHCPv6
>        Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from
>        an Internet Service Provider (ISP), and a sub-prefix of the leased
> 
> (nit/editorial) this construction looks like "scenarios where Q might
> happen include: A common scenario for X is Y.  Sometimes, Y can be a
> scenario where Q happens."  Pedantically, the list contents don't match
> the list introduction, since the extra introductory material doesn't
> match the classifier attempting to describe it.

You're right. How about fixing this as:
"The most common IPv6 deployment scenario for residential or small 
office networks, where a CE router..."



>     o  A router (e.g.  Customer Edge router) may advertise
>        autoconfiguration prefixes corresponding to prefixes learned via
>        DHCPv6-PD with constant PIO lifetimes that are not synchronized
>        with the DHCPv6-PD lease time (as required in Section 6.3 of
>        [RFC8415]).  [...]
> 
> nit: I suggest the parenthetical be "even though Section 6.3 of
> [RFC8415] requires such synchronization", since the present formulation
> is potentially unclear about which behavior is the required one.

Will apply this suggested edit. Thanks!



>     This means that in the aforementioned scenarios, the stale addresses
>     would be retained and also actively employed for new communications
>     instances for an unacceptably long period of time (one month, and one
>     week, respectively), leading to interoperability problems, instead of
>     hosts transitioning to the newly-advertised prefix(es) in a timelier
>     manner.
> 
> I am not 100% sure that "would" is always applicable, as I could imagine
> situations that conform to the above-listed scenarios yet have
> qualifying factors that result in non-use of the stale addresses.

Could you please elaborate?


> Perhaps "could" is more appropriate?

Addresses will certainly be retained. I guess one might say "would be 
retained and could also be...actively employed...."?



> Section 2.2
> 
>     IPv6 SLAAC employs the following default PIO lifetime values:
> 
>     o  Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
> 
>     o  Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
> 
> We noted these values previously, in the Introduction.  Is it useful to
> repeat them in both locations?

If anything, I'd remove them from the Introduction, and point to Section 
2.2 from there...




>     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 will take a host 7 days
>     (one week) to deprecate the corresponding addresses, and 30 days (one
> 
> I suggest "up to" [7 days ...].

Saying "up to" would suggest that that's the worst case scenario as 
opposed to the regular case. Put another way: what'd be the scenario 
where it would take less than that?



> Section 2.5
> 
>     At times, the prefix lease time is fed as a constant value to the
>     SLAAC router implementation, meaning that, eventually, the prefix
>     lifetime advertised on the LAN side will span *past* the DHCPv6-PD
>     lease time.  This is clearly incorrect, since the SLAAC router
>     implementation would be allowing the use of such prefixes for a
>     longer time than it has been granted usage of those prefixes via
>     DHCPv6-PD.
> 
> I recognize that this is an informational document and we're not
> obligated to give advice, but we've given advice elsewhere in the
> document and it feels weird to end the section on such a grim note.
> Should we say something about such implementations ideally getting
> updated to reflect the specification?

This document is meant to describe the problem, and provide operational 
advice. As such, there's not really anything one can operationally do 
with this implementation issue -- unless you're thinking of "replace the 
device with one that has a different implementation".

draft-ietf-v6ops-cpe-slaac-renum provides advice in this respect (i.e., 
implementation).

Thoughts?




> Section 3.2
> 
>     NOTES:
>        A CPE router advertising a sub-prefix of a prefixed leased via
>        DHCPv6-PD will periodically refresh the Preferred Lifetime and the
> 
> nit: s/prefixed leased/prefix leased/

Thanks! Will fix.



> 
> Section 6
> 
>                                   This document does not introduce any
>     new security issues.
> 
> (side note) we sort-of recommend using different values for
> AdvPreferredLifetime/AdvValidLifetime, which would presumably affect the
> tradeoffs for robustness vs. susceptibility to attack.  But the values
> from RFC 4861 are just "defaults", so there's a reasonable claim to be
> made that the relevant security considerations should have been covered
> in 4861 itself and we don't need to say more here.

Roman made a similar comment, and my suggestion was to tweak the text to:

    This document discusses a problem that may arise in scenarios where
    flash-renumbering events occur, and proposes workarounds to mitigate
    the aforementioned problems.  This document does not introduce any
    new security issues, and thus the same security considerations as
    for [RFC4861] apply.


Thoughts?




> Section 8.1
> 
> It's not clear to me that the one place we cite RFC 4941 qualifies as a
> normative reference.

Agreed. I will move it to the Informative references.




> Section 8.2
> 
> The use of "[Linux]" as a slug for referencing a post to netdev is
> perhaps debatable.

It's a link to a patch that has been committed to the tree (in the same 
URL, you'll find the note that the patch has been accepted). I could 
provide a link to the corresponding commit on the git repo?

(fwiw, we didn't mean "[Linux]" to convey anything special... it was 
just the obvious choice for the reference).



> The way in which we cite RFC 6724 seems similar to the way in which we
> cite, e.g., RFC 8028 (which is listed as normative).

Agreed. We'll make RFC6724 normative.

Thanks!

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