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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 20 October 2020 23:40 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: v6ops@ietf.org
Delivered-To: v6ops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD463A09C0; Tue, 20 Oct 2020 16:40:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong <owen@delong.com>, v6ops@ietf.org, owen@delong.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160323723374.19211.14841316122738197736@ietfa.amsl.com>
Date: Tue, 20 Oct 2020 16:40:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/I8SmB1sQ7eJoZbAs5DDi4rSqQt4>
Subject: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-slaac-renum-04: (with DISCUSS and COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2020 23:40:34 -0000

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