Re: Zaheduzzaman Sarker's No Objection on draft-ietf-6man-grand-05: (with COMMENT)

Jen Linkova <furry13@gmail.com> Wed, 30 June 2021 02:14 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EC73A12DB; Tue, 29 Jun 2021 19:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBrutttNy78G; Tue, 29 Jun 2021 19:14:32 -0700 (PDT)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0423A12C5; Tue, 29 Jun 2021 19:14:32 -0700 (PDT)
Received: by mail-qv1-xf2b.google.com with SMTP id 11so327579qvh.3; Tue, 29 Jun 2021 19:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mHf0SfoyKX2oVQRYpQ5tsTNGtJ93GKrgHI5+UGRJ6+o=; b=uXheUJuGlW8m+Xox2eLvu/sJrRUDdh9r7C8AFg0ncNNvnTOwEX63zDSFX/bLg9mC9P 1zJz+BPhWzOm4PGucjkhL1gRjkCPtHGg99F+nTWUMlDbP4HAkJHQyT9kA1ZKXl2oCodY H04qjhgOC+XSzaJLiaxYFpYO8VLeNcqaLsdUaLvKlJKUxvX2U2kQP781McKjmKlN6kuB iAYvHZsrW44vZQuUpRhEgPPZcp0hHcjYXPcmoQk8nPF73uRgCY/xfzITQF8JbRC0R5e5 Y2BBWfzz7r/dTLVMii/mxV/lQlwg2LLZ0GuZB3OQJhubI5o1lt131D1m3dUBk0EQTV80 PyTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mHf0SfoyKX2oVQRYpQ5tsTNGtJ93GKrgHI5+UGRJ6+o=; b=JLmxjQ5vkNivK5FLSrZy+hOGs9d20v3HaSPfCUisGAkZftqddF/A5awuLSfULfCjJ2 SLCxXC+xd5nAur4LWuKDTiYbe22iLq9UwEdW+WVg8D6AvTRus/SAhK7Vd77vhSCJJKjG /cvXRcuQwZIr/fDPZSppQUisElcTj/zZzqJyvPHrpm5pEgg9Rf/tDz6I/1KWqV13f9mz 6pL3++IfCDt8xR+kRneUfT282PQiGXKO0ILx9YCcqcTkOLbhnJ0cc4n7erWcuoqJvZxS Jrom0OwrHpJ/+OYy1+Tk6FEThApgl/bAxdq8bddzrdpefOV5OKvbid2ObcPlbwPUM0UR SjOw==
X-Gm-Message-State: AOAM530V0hRwOpW0aAc2L7kJrILXbGM9dQXOsE5Vqi9gP+w62waLva+e FrsgPhlIQoNs8wbj4xf0WTepkjUot8WCj377xJY=
X-Google-Smtp-Source: ABdhPJw+vpAbDL2D/Lpr0dzaamh4h5yXPkAmC4Zo2HpUZRb6wyrH/phGUW7p6mkpRpVfG9nU4SpQsGvR5nmFq04fexs=
X-Received: by 2002:a0c:eb0c:: with SMTP id j12mr34392051qvp.3.1625019270445; Tue, 29 Jun 2021 19:14:30 -0700 (PDT)
MIME-Version: 1.0
References: <162499037061.32150.11218576881654906548@ietfa.amsl.com>
In-Reply-To: <162499037061.32150.11218576881654906548@ietfa.amsl.com>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 30 Jun 2021 12:14:19 +1000
Message-ID: <CAFU7BAQp12p3GT4ij7CKUNgy_o-5-FaGyWTOHcYM7jFsXwZSDQ@mail.gmail.com>
Subject: Re: Zaheduzzaman Sarker's No Objection on draft-ietf-6man-grand-05: (with COMMENT)
To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
Cc: The IESG <iesg@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, draft-ietf-6man-grand@ietf.org, 6man <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Kq6zZO4wkuupyw1lgFAYCgIGJjQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jun 2021 02:14:45 -0000

On Wed, Jun 30, 2021 at 4:14 AM Zaheduzzaman Sarker via Datatracker
<noreply@ietf.org> wrote:
>    * Section 3: already a great job done in the terminology section, please add
>    the STALE definition to that list with reference.

I've expanded the Neighbor Cache definition with the following:
"The Neighbor Cache entry can be in one of five states, as described
in section 7.3.2 of [RFC4861]:
   INCOMPLETE, REACHABLE, STALE, DELAY, PROBE."

I think copying the state definitions from RFC4861 into the
terminology section is suboptimal, so I include the reference to the
formal definition of each state.

>    * Section 4.1:
>       * Please provide ref to "onlink routers" or add verbose description of
>       it. Best to add this to section 3, even if this might be very well known
>       term to the active participants.

As it's the only place when this term is used, I've just changed that
to "routers on the given network segment/link"

>       * It would be great if there is some text describing what if "multicast
>       traffic should not
>    increase" is not true and what precaution should be taken.

How about:
"Therefore, unsolicited NAs sent by hosts do not lead to
 increased amount of multicast traffic, if the routers on that network
   segment use those NAs to create STALE entries.  Even if the routers
   do not yet implement the proposed changes and discard unsolicited
   NAs,  each host would only send MAX_NEIGHBOR_ADVERTISEMENT
   unsolicited NAs (see Section 6.1.2 each time a global IPv6 address is
   assigned on the interface.  That additional traffic would be a few
   orders of magnitude less than the usual level of Neighbor Discovery
   multicast traffic."

>
>    * Section 4.2 : this section might be improved by providing some information
>    about duplicate entries unless there is no chance of duplicate addresses in
>    case of unsolicited NAs. May be a hint is enough that it is covered in
>    section X.X.

Added the following text to the very end of Section4:
"The next section analyses various scenarios of duplicated addresses
and discusses the potential impact of creating a STALE entry for a
duplicated IPv6 address.

> And one question -
>
>    * Section 5.2 :
>        "Those packets would be sent to the
>       host with the optimistic address instead of its rightful owner."
>
>       Could this problem be amplified to create issues in the network?

I've updated the text:
"However, it should be noted that the probability of such scenario is
rather low as it would require the following things to happen almost
simultaneously (within tens of milliseconds in most cases):
- One host starts using a new IPv6 address and sending traffic without
sending an unsolicited NA first.
- Another host configures the same IPv6 address in Optimistic mode
before the router completes the address resolution for the rightful
owner."


-- 
SY, Jen Linkova aka Furry