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

Jen Linkova <furry13@gmail.com> Thu, 01 July 2021 05:13 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 60D833A1048; Wed, 30 Jun 2021 22:13:18 -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 pn-IrDSrfJFc; Wed, 30 Jun 2021 22:13:14 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 F31263A1070; Wed, 30 Jun 2021 22:12:42 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id j11so6475696edq.6; Wed, 30 Jun 2021 22:12:42 -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:content-transfer-encoding; bh=cS7B4meWEeJRxjEDWKNG6iP3ISoFCHck2FuWXlAmjBg=; b=sp00EAyZfuk8O52zJ9K1/jwyULjxfnyfn8Blb5cXd/z0jYHzb9inYx/aRvx40EKlo5 OW2qz6C0ZNmB8Icqkq0pcBzPSjxTNSE458tybi2tCn+XO+FX1OrqFkhX29r68RmOf2gF 1yv2tFOELDF5KM5qxiGSjM0dWNhsRRnkCVF9tBa73iTlyYt+imVnN5vLY924KKgfLhML mIHDHPoNCcNYWG2wJ5WB3CTjny/JR7ji/2vv+1HgUZVfameel51TgK6jUpaJqedInZFT NNzsyGLnESeZzFItFXNKQ6L8cQ1UTJYPrl4NKX77gSI6qH0GedUXM5vku2Z5OZC4d8aJ Q9iQ==
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:content-transfer-encoding; bh=cS7B4meWEeJRxjEDWKNG6iP3ISoFCHck2FuWXlAmjBg=; b=b0VV3zkjFTvVqRT/dYYhoUKDXmxmg7bc0A2wvd2m8xlIRx9tJnduhDcANB6HQu9J4K +iEoSm9tjRhLG7C4taeJJHCSJJXU6DVD8f2gXHrF7AHpXRLs41SXqEHQI9XpJuW2NUiM HJcHPWaquQBzElaRBbi5Cgh5v3zOqjYs7ZhGBEA+z0pTqZ+z3S05c/CQRHjwsSyIxCGs wUMBHk8fJicziLce5vqqrLkJfT3EcjJTcLfHi1MuDCuNjqQ9cLyD64sfEwTIQ0k/PIOS Rx7gapCm7XOF1T/8mGOTP59RE6zYeTQA1qF9xvCrTrpEqAlidRbxCxRJEFgMU/oKYSKA ThJA==
X-Gm-Message-State: AOAM532CJmsP5e+e0L9SWobtLo6zdDuQUH9yu/ob+lYBw0iLDcz1mW0B OAha2lWwMRK5Xoq7YibqeVDsKoYMvToc4DRnzjs=
X-Google-Smtp-Source: ABdhPJznhU+/2wZ4g2d+IH2nDMaoo3AXVnXfqfvokNeIsfKO+okKRQcWqIHZWrcOjCQR1Zf2bHsc4r6u732/XM7fx0A=
X-Received: by 2002:aa7:dd43:: with SMTP id o3mr51334277edw.302.1625116360639; Wed, 30 Jun 2021 22:12:40 -0700 (PDT)
MIME-Version: 1.0
References: <162510315925.6473.16343810620669363979@ietfa.amsl.com>
In-Reply-To: <162510315925.6473.16343810620669363979@ietfa.amsl.com>
From: Jen Linkova <furry13@gmail.com>
Date: Thu, 01 Jul 2021 15:12:29 +1000
Message-ID: <CAFU7BAQkHqJCEZMq3Topba8wnPB1Y7NXs+fk2d8szOAZ_iF4aA@mail.gmail.com>
Subject: Re: John Scudder's No Objection on draft-ietf-6man-grand-05: (with COMMENT)
To: John Scudder <jgs@juniper.net>
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"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/u4wwrlFXYTy1oesJaUbgzAmt1xY>
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: Thu, 01 Jul 2021 05:13:19 -0000

Hi John,

Thank you for your review and comments!

On Thu, Jul 1, 2021 at 11:34 AM John Scudder via Datatracker
<noreply@ietf.org> wrote:
> 1. Section 5.2
>
>               The
>    only potential impact would be for packets arriving to the router
>    after the unsolicited NA from the host but before the rightful owner
>    responded with the solicited NA.  Those packets would be sent to the
>    host with the optimistic address instead of its rightful owner.
>    However most likely those packets would have been dropped anyway:
>    creating the INCOMPLETE entry is usually triggered by traffic, so the
>    router probably has some packets in the buffer already, dropping
>    subsequent packets received before the address resolution is
>    completed.
>
> Wouldn’t the buffered packets (received before the unsolicited NA) be
> misdelivered to the optimistic host? The quoted paragraph restricts itself to
> packets arriving after the unsolicited NA.

Yeah, that's been pointed out already, -06 has this section
re-written, please take a look:
https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-06#section-5.2

>
> 2. Section 5.3.1
>
> Couldn’t step 4 (host detects duplication) complete sometime after step 7
> (router sends NS to host)? (This might also apply to 5.3.2.) If that's possible
> the analysis would be a little less rosy, right?

You are right. I've updated the text to clarify:

7. As the host has detected the address conflict already it does not
respond to the unicast NSes. (It is unlikely that the host has not
completed the DAD process at this stage, as DELAY_FIRST_PROBE_TIME (5
seconds) is much higher than the DAD duration
(DupAddrDetectTransmits*RetransTimer*1000 + MAX_RTR_SOLICITATION_DELAY
secs, section 5.4 of [RFC4862]). The default value for the DAD process
would be 1*1*1000 + 1 = 2 secs, [RFC4861]. If the host has completed
DAD but did not detect the address conflict then there are two hosts
with the same address in the Preferred state and the disruption is
inevitable anyway.

Also, -06 now has the text explaining that all those scenarios could
be easily avoided if the rightful owner also sends unsolicited NAs.

> 3. Section 5.3.1
>
>         However the same
>    behaviour would be observed if changes proposed in this document are
>    implemented
>
> Do you mean “are *not* implemented”?

Indeed I do, fixed.

>
> 4. Section 8.4
>
> Please add SLLAO to terminology section or expand on first use.

Done.

-- 
SY, Jen Linkova aka Furry