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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 20 Oct 2020 16:40:33 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-v6ops-slaac-renum-04: 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-slaac-renum/

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

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

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.

   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.

   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.
Perhaps "could" is more appropriate?

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?

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

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?

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/

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.

Section 8.1

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

Section 8.2

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

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 21:47:06 -0300

Hello, Ben,

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

On 20/10/20 20:40, Benjamin Kaduk via Datatracker wrote:
[....]

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

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

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

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

> is potentially unclear about which behavior is the required one.

Will apply this suggested edit. Thanks!

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

> repeat them in both locations?

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

> 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?

> 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?

> nit: s/prefixed leased/prefix leased/

Thanks! Will fix.

> 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?

> It's not clear to me that the one place we cite RFC 4941 qualifies as a

Agreed. I will move it to the Informative references.

> The use of "[Linux]" as a slug for referencing a post to netdev is

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

> cite, e.g., RFC 8028 (which is listed as normative).

Agreed. We'll make RFC6724 normative.

Thanks!

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 21 Oct 2020 22:53:02 -0700

Hi Fernando,

Also inline...

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

Yes, that is the resolution I was expecting.

> office networks, where a CE router..."

That looks like it should do the trick.  And nicely done, too -- I don't
think I would have found that elegant of a tweak!

> Could you please elaborate?

I think I'm complaining more about "would be actively employed" than "would
be retained" -- the "would be retained" part is pretty clearly true...which
is what you go on to say below :)
But they would not be employed if the node didn't generate any traffic at
all, for example, or had a fresher prefix arrive and policy chose to use
the newer one.

> retained and could also be...actively employed...."?

That would address my concern here, yes.  I would also understand if you
decide that this new text is ugly and prefer to keep the old text even if
it is pedantically not-quite-correct.

> If anything, I'd remove them from the Introduction, and point to Section 

No complaint from me; I could also understand if the answer to my literal
question was "yes", but wasn't sure just on my own first reading.

> where it would take less than that?

I guess it depends on the frequency of RAs (which I do not have fresh in
memory).  In principle if you advertise something with a lifetime of 7 days
and the recipient sets a timer, then if you crash and lose state, there
could be anywhere from 0 to 7 days left on that timer.  But if you are
re-sending the "7 days" announcement every hour, then yes, it's pretty much
always going to be 7 days.  So, sorry for not having thought this through
more thoroughly at first.

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

I was imagining "such broken implementations should be updated to honor the
spec" (but worded a little more nicely).  In practice that would probably
be "replace the device" (as you note) for many affected devices, and thus
is not particularly useful advice.  So I would certainly understand if it's
easier to just leave this text alone.

>     new security issues, and thus the same security considerations as

Indeed, I only noticed Roman's comment after I filed my ballot.  The text
you agreed with him addresses my concerns, too.

> just the obvious choice for the reference).

To me (and no guarantees about anyone else), "[Linux]" sounds good for a
link to the commit in the official git repo, and "[Linux-update]" sounds
good for a link to the netdev post.  Either seems like it would perform the
role of reference adequately for the statement in question.

Thanks!

-Ben