[v6ops] AD Review of: draft-ietf-v6ops-nd-considerations
Warren Kumari <warren@kumari.net> Sat, 10 August 2024 22:07 UTC
Return-Path: <warren@kumari.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F8FC14CE29 for <v6ops@ietfa.amsl.com>; Sat, 10 Aug 2024 15:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvxOixqtYiWm for <v6ops@ietfa.amsl.com>; Sat, 10 Aug 2024 15:07:25 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B860C14F701 for <v6ops@ietf.org>; Sat, 10 Aug 2024 15:07:25 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5bb8e62575eso1144395a12.3 for <v6ops@ietf.org>; Sat, 10 Aug 2024 15:07:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1723327643; x=1723932443; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=BIVQoSZoAaPHNHz2ZbupTShk3Sqw9HJCs96BAUYOE40=; b=Ehe/Jf6nNYo147N0jgdLsOidPqUDgbM/MBH1P0NdiaDGUH17Ej0FOKtrJVgj5ha1LM A6PMswMH0E+Zh7iYstH1DR7eqDyqnnuN3dF/67x+V1yQhJck+LpUNSt3yAXqc7KLbusP yL/b/iVLy++dMFBBRxKnBPF4KJA9n51DFMt4TwpH68IvRwHofqXOBNAaDcA7nAY4+cQ1 lpvzjkI7GQqxQCfuHm+ly7yAbQ3DnRaXCFDr09LCPhfj5SUYk97QakCKjmnMGiW8D4Eb zNQrHoK5l7CF8TexYcx8fws1mO0p79XCo+7ZfpSmm/2jJJa4kbuf4zHrnenUl0HTlYUg vaJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723327643; x=1723932443; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=BIVQoSZoAaPHNHz2ZbupTShk3Sqw9HJCs96BAUYOE40=; b=ZmHQhixc+BSLiqQELhuek5LqkkVAOaTNcnduheN0ipZKHeOth7d0Syc/X/OesxFzVx 5EKMOqwSpPzhQwgACAZr+B90+9I0oLJsqH7tdpPdKgPqeCNZRzCkdIri/GFh8oLJjCUz Ku0V8Mm3BP1b7Lei4xuIqnUC/xctswlukRu+LK0f98ouJt0Ql8W6jPyAjmlaSaK44EWY Y+IR7bLO7ndrfxIkdPRiR57INVmYS25TncTOI7e73pLFVF3Hy1CVCzjZPNwM+hjFiVUp 9c54OnGBieknYUY1aqj+UQbnd+imiRIU5vi7dCiaXilSuIJsGmVCd7lippUSpdc/fw7E 3CwQ==
X-Forwarded-Encrypted: i=1; AJvYcCWElE4pF1o+Vfk+5XH5aufKktSPRlkYSakvMAfhG4JMQ6bzFT6bHfwJku/Z2BWXepWWDdhQ7dhKYFxXxMevxQ==
X-Gm-Message-State: AOJu0Yw/s7lcChoShEzMSee40fpVJk7kyPlDBHNNBs4qGesVwZ8vXCRJ BJH8sD6RosoBD14xPQ8dQjfW55dPmlgCtZUrY+goXix47LPsM5pW2exrI5HD73RReaupDYjhaGM Ftbnn8fXy9PQPsEJYVuMcrwBAJ/dT0XfXUWk476DMY3tbMjAU
X-Google-Smtp-Source: AGHT+IF/3u624+54GRPOfdv2n1Kq2lBVaTPAyzV3NkCW7Dj3C7fxo8gmE6xUoBnz+u+MZKI6vbRtVCsmj8CXPXnyIJw=
X-Received: by 2002:a05:6402:34d1:b0:5b9:462d:c53c with SMTP id 4fb4d7f45d1cf-5bd0a50dce9mr4938934a12.6.1723327643093; Sat, 10 Aug 2024 15:07:23 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 10 Aug 2024 15:07:21 -0700
Mime-Version: 1.0
X-Mailer: Superhuman Desktop (2024-08-08T19:05:41Z)
X-Superhuman-ID: lzoorqct.16a1f8d5-0480-4d4d-a31d-1833abe41766
X-Superhuman-Draft-ID: draft0073443c14b3f036
X-Superhuman-Thread-ID: draft00cb926973f08d1c
From: Warren Kumari <warren@kumari.net>
Date: Sat, 10 Aug 2024 15:07:21 -0700
Message-ID: <CAHw9_iJ2CjaOccdJdsM7oCY=K0zASvLU7qcDiH-pMv39TiW2xA@mail.gmail.com>
To: draft-ietf-v6ops-nd-considerations@ietf.org, IPv6 Operations <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ffa700061f5b7b7c"
Message-ID-Hash: N2IOTRFRWLDLI7OP7VAGN4W5POHGXBH4
X-Message-ID-Hash: N2IOTRFRWLDLI7OP7VAGN4W5POHGXBH4
X-MailFrom: warren@kumari.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] AD Review of: draft-ietf-v6ops-nd-considerations
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/y9WMDveq2RH4B0rMfz8EpQEcFCo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>
Hi there, authors (and WG), Thank you for this document, and apologies for the delay in reviewing it. This is definitely a document that will be very useful — but, in its current state, it is difficult to read/understand. I have spent some time reviewing and trying to improve it, and you'll find some examples of proposed text revisions at the end of this email. Most importantly, though, I *do* agree that this document will be very useful once it's ready. Neighbor Discovery is a critical part of the IPv6 protocol and IPv6 operation, and it is both complicated and sometimes fragile. As you state, the issues and mitigations are documented in around 30 RFCs. Therefore, finding, reading, and understanding all of these is challenging , and having a document which collates and summarizes these will be very helpful. That said, I don't think that the document is ready for IETF LC / IESG Eval quite yet. I went to review the WGLC comments to see how we ended up here, and it looks like there has not been very much discussion on the document, other than from the authors, and some in-depth comments from Lorenzo. General notes: Much of the document seems very disorganized and, therefore, hard to follow. For example, Section 2 is titled "Review of ND Issues", and discusses issues, and then Section 3 is titled "Review of ND Solutions" and discusses mitigations / solutions — but both issues and solutions are also discussed in other sections. For example Sec 2.3 ("Router-NCE-on-Demand Causes Forwarding Delay, NCE Exhaustion and Lack of Subscriber Management Issues") discusses the issues with routers not keeping the neighbor cache entries hot, and mitigations are discussed in Section 3.8 ("Gratuitous Neighbor Discovery")... but Sec 2.3 also contains some set of mitigations ("To prevent this NCE Exhaustion problem, some implementations limit the maximal number of NCEs a router will maintain for each host."). I think that the document would be *much* better if it listed each issue, and then the mitigations that exist to, er, mitigate the issue. That way, it is more clear to the reader both what the issue is and what the associated mitigation is. The information and table in "3.15. Observations on the Solutions" helps significantly with this, but it comes very late in the document. As a reader of the document, if I am experiencing issues because my router doesn't (yet) have an ND entry for the host, seeing the issue described in Sec 2.3 is useful. It would be even more useful if this section then discussed solutions for the same, such as RFC 9131, RFC 8273, etc. Again, I really *do* think that this is a worthwhile document, and encourage the WG to review and comment. For now I'll return the document to the WG; I'll be more than happy to review it more once issues have been addressed. More specific notes (most of these are only suggestions, feel free to edit or push back): Throughout: s/link layer/link-layer/ s/in link/on link/ (I think) s/MAC/MAC address/ (in places like "to find the MAC of the host") Section: Abstract 1: "Neighbor Discovery (ND) is a key protocol of IPv6 first-hop." — I don't really understand this sentence / think it is incomplete. Perhaps "Neighbor Discovery (ND) is a critical part of the IPv6 protocol", or "is critical for resolving the IPv6 link-layer address" or something? It's not only used for "first-hop". O: "In some scenarios like wireless networks, multicast can be inefficient. In other scenarios like public access networks, hosts may not be trustable." P: "In some scenarios, such as wireless networks, multicast can be inefficient. In other scenarios, like public access networks, hosts may not be trustable." C: Note: 2 changes. O: "Consequently, ND has potential issues in various scenarios." C: This sentence doesn't seem to add anything to the paragraph. O: "The issues and the solutions for them are documented in more than 30 RFCs. It is difficult to keep track of all these issues and solutions. Therefore, an overview is useful." P: "The issues and solutions for them are documented in more than 30 RFCs, making it challenging to track all these issues and solutions. Therefore, an overview document is helpful." C: Rewritten for clarity / flow. O: "This document firstly summarizes the known ND issues and optimization solutions into a one-stop reference." P: "This document summarizes both the known ND issues and the optimization solutions into a one-stop reference." C: There is no "secondly"... O: "This simplifies the IPv6 first- hops." P: As above - this sentence doesn't make much sense - perhaps "link-layer resolution"? Section 1: O: "For description simplicity, GUA DAD and ULA DAD are not further distinguished." P: "GUA DAD and ULA DAD are not further distinguished for simplicity of description." or "In order to simplify description, GUA DAD and ULA DAD are not further distinguished within this document". Section 1.1: O: "MAC - To avoid confusion with Link Local Address (LLA), link layer address is called MAC in this document." P: "MAC - To avoid confusion with Link Local Address (LLA), link-layer addresses are referred to as MAC addresses in this document." O: "a bridging proxy either passes the message to the host or directly answer with the host's MAC." P: "a bridging proxy either passes the message to the host or directly answers with the host's MAC." O: "This is also applicable to ULA, but to be simple, it is also called GUA Isolation in this document." P:" This is also applicable to ULA, but, for clarity, it is also called GUA Isolation in this document." (or "for simplicity") O: "For example, ND uses no response as an indication of no duplication in DAD." P: "For example, DAD uses the lack of a response as an indication that the address is not currently in use." O: ". Router's address resolution for hosts: in a large L2 network of N hosts, there can be N such multicast messages. This may cause performance issues." C: In a small network of N hosts, there can also be N such multicast messages. Please rewrite this (same for the following). Section 2.2: O: "In some scenarios like public access networks, some hosts may not be trustable." P: "In some scenarios, such as public access networks, some hosts may not be trustworthy." O: "An attacker host in the link can cause the following security issues [RFC3756][RFC9099]:" P: "An attacker on the link can cause the following security issues [RFC3756][RFC9099]:" - throughout the document I think "on the link" makes more sense than "in the link". — This is a only a partial review until structural and editing issues have been addressed —- Thank you again; I know that making edits to address nits can be annoying, but we are expecting many people to read and review the document, and so having it polished is important and polite (also, once people start commenting on nits, they seem to continue :-) ) W
- [v6ops] AD Review of: draft-ietf-v6ops-nd-conside… Warren Kumari
- [v6ops] Re: AD Review of: draft-ietf-v6ops-nd-con… Xipengxiao
- [v6ops] Re: AD Review of: draft-ietf-v6ops-nd-con… Warren Kumari