[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