Re: [EXTERNAL] Re: IPv6 certification - IPv6 Router Advertisement Lifetime 0 and Reachable time 10 seconds

Isaac <isaactheogaraj@gmail.com> Mon, 25 January 2021 05:40 UTC

Return-Path: <isaactheogaraj@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 EA2D73A05D0 for <ipv6@ietfa.amsl.com>; Sun, 24 Jan 2021 21:40:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 v_WzvUwoJS-K for <ipv6@ietfa.amsl.com>; Sun, 24 Jan 2021 21:40:33 -0800 (PST)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 44A953A0475 for <ipv6@ietf.org>; Sun, 24 Jan 2021 21:40:33 -0800 (PST)
Received: by mail-yb1-xb2c.google.com with SMTP id y4so12228247ybn.3 for <ipv6@ietf.org>; Sun, 24 Jan 2021 21:40:33 -0800 (PST)
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=zt67rTK2VRyL5ZpTrJfhSRSLI+Gq4v1BSTX31SWUYA4=; b=IPDYEQ60vs2R4qxthylujwGS5OsiMtgxCgmGubJMDHKb4SwuG3+4OXo1+MCZ+8Cydi 7BMB2DzG3F0l1DQ1hKhxqjy2Db9KY6XeFrEFYRe3nufapTfk67kXoI5W0jA8nSrSOkjT LXjyVVvuo4+S5UA0Z++2l8c/lktPogDBncptE7xbP8uXJTyXSXI0b5I4pR7ue3cYq5iK H5OKwC39joK6h5cdKDuvvdjPqQZUd06vyG7NsWp398w0WLBgb91O4iKQNbOc4nRPl8K8 j1wxgE+bkmpI8XBuc+kQYnZ/lH4EeuCR3Tq+PcU6gUWeauC59OAHZ3L2HK/O5YN4XuE1 F60g==
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=zt67rTK2VRyL5ZpTrJfhSRSLI+Gq4v1BSTX31SWUYA4=; b=Ji18pdz5I4E3dW771FJNrnEFhVljOVpHbU9kaiw5ujTvpOzqVs0LQLfOql+NsqhDAn syLHUrau6uO8tPRqXl2wMaruU7xpjFQp/pTmNRVFWHAzqE+MnP6TkxNJkiX0fEoJoJk4 fpXn6Tc43nyohg4KTM+TRBdwKy5+/r0nLTptt0vReClI1tBj8izECl0BCb+BzRKnFSya +dZnSAsfoMCyIQry4WfRzbdb34sdE92qTnGblGM4Wz4MnZYs20K+R2yL/utG1If5bKhL 0lH1SAXWg/MMfr55H4TuwCfypIhPx3OO0/Mft1xqmMmls8MjN0c8X3TvwKzLKtEXEkip AGsQ==
X-Gm-Message-State: AOAM530z3+GlT6CQEcgs6V9w4p38XfiVv4ShwGWfLBomEixK7VJo2s76 M40H20TtDpD0JW52Jo+g6JAau2FS8+NW9zx4fqU=
X-Google-Smtp-Source: ABdhPJy2j9b/CNkOXBcaJsgBNoNeUseUTqicmKUqp1xo/4D+vzybmIcwhYOka/FkOrB23vijHktlDynkTRNVk84xCE4=
X-Received: by 2002:a25:3bc5:: with SMTP id i188mr23057410yba.332.1611553232318; Sun, 24 Jan 2021 21:40:32 -0800 (PST)
MIME-Version: 1.0
References: <CAGeZV=Q=awxFd=vsfBiBC2vt7o3Wkm9ECMSi+UU90ATKmHY32Q@mail.gmail.com> <BAB67E82-9BE8-4E7A-8548-5475E93FD137@employees.org> <CAGeZV=T4B5m7RYrKL4a4peQjZAoJiUqNv7V=0iaz5VdWeSTKng@mail.gmail.com> <fd7bc4a5272f4081afddfdc1a00ad527@boeing.com>
In-Reply-To: <fd7bc4a5272f4081afddfdc1a00ad527@boeing.com>
From: Isaac <isaactheogaraj@gmail.com>
Date: Mon, 25 Jan 2021 11:10:20 +0530
Message-ID: <CAGeZV=SPczCEk-FixqSM+q5KDiEQf_pdsUWkzUj7f398dSGY8A@mail.gmail.com>
Subject: Re: [EXTERNAL] Re: IPv6 certification - IPv6 Router Advertisement Lifetime 0 and Reachable time 10 seconds
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f2f30205b9b2f9f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mkjIP2eToJ17dHw4g_QQTIUTDWY>
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: Mon, 25 Jan 2021 05:40:35 -0000

Bert,

In a way, yes. Do you think this combination of RA lifetime 0 and reachable
time 10 seconds need to be mandated for all vendors?

I have a question to the IETF group here, when RA lifetime is 0 (which
means the the router is no longer to be used as gateway by hosts) and
prefixes are provided (prefixes have their own lifetime and flags and in
this rare scenario there is going to be a second router acting as gateway),
why do we need reachable time of 10 seconds for the 1st router?

Thanks,
Isaac.

On Mon, Jan 25, 2021 at 10:45 AM Manfredi (US), Albert E <
albert.e.manfredi@boeing.com> wrote:

> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Isaac
>
> > Ole/Tim Winters/IETF team,
> >
> > Yes, we understand these knobs but we wanted to understand more on
> the scenario/topology. More importantly we wanted to understand the real
> world scenario when this combination of RA lifetime 0 and reachable time 10
> seconds is used and the technical merit of it for which we did not get
> clear response (especially in the modern global IPv6 networks context).
> It's surprising that the certification bodies haven't clearly mandated only
> common/practical (although IETF has mentioned that these paramers need to
> be configurable but never said explicitly that all permutation/combination
> of values need to be supported. Vendors (definitely want) comply to RFCs
> but do not want allow impractical values) use cases but have listed even
> the corner scenario which may never be used. We understand that there are
> thousand vendors who have implemented this combination. But we fear that
> these are extra burden for vendors considering that vendors go ahead for
> certification without questioning the certification body itself
> believing that the certification body does its job of validating the modern
> technical relevance. Ideally, we expect the certification body (if not
> IETF) to re visit all the tests periodically to understand the relevancy as
> time passes and modify if required (which is the purpose of the
> certification body we believe). Sorry to have spilled certain discussions
> pertaining to certification body in this forum. But we do not have much
> option as we want technical answer from the IETF group. Let's not stop with
> the high statements in RFC. The reason we approcahed IETF is to go one
> level deep (especially in the context of modern day global networks) to
> undertand the relevance of RA lifetime 0 and reachable time 10 seconds
> whether it makes sense to support. These are our 2 cents contribution to
> the community (if there is someone to listen!)
>
> Isaac, I'm trying to understand your point. At least one scenario in which
> the RA lifetime is set to 0, and reachable time is set to 10 seconds, was
> explained a couple of times. It can be used for a router to provide the
> IPv6 prefix, for example for SLAAC, but for that same router NOT to be used
> as the default router, for the subnet in question.
>
> Is it that this scenario seems unrealistic and unnecessary, to you?
>
> Thanks,
> Bert
>
>