[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).
- [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6… Benjamin Kaduk via Datatracker
- Re: [v6ops] Benjamin Kaduk's Discuss on draft-iet… Fernando Gont
- Re: [v6ops] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk