IETF Logo Mail Archive

Re: [v6ops] ND cache entries creation on first-hop routers

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 03 July 2019 18:29 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 09F0F1200D7; Wed, 3 Jul 2019 11:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 k3u8udofIb1Q; Wed, 3 Jul 2019 11:29:54 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C9B120332; Wed, 3 Jul 2019 11:29:53 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A7DE338192; Wed, 3 Jul 2019 14:27:58 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56506BB7; Wed, 3 Jul 2019 14:29:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jen Linkova <furry13@gmail.com>, V6 Ops List <v6ops@ietf.org>, 6man <6man@ietf.org>
In-Reply-To: <CAFU7BAR57miAW5ERRohqN_CaUztkBzv8m2Bqg09N89=raNt8xA@mail.gmail.com>
References: <CAFU7BAQ4xrjNn9-EUyRhyHKDDT=f381Z4T6x6qJ=ftm2D2K4cw@mail.gmail.com> <376F1849-2EC5-4553-BFCF-A161C48373CF@gmail.com> <CAFU7BAR57miAW5ERRohqN_CaUztkBzv8m2Bqg09N89=raNt8xA@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 03 Jul 2019 14:29:52 -0400
Message-ID: <4250.1562178592@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/EaWV8EIKY2eUzRpGIuQLbrbvB0I>
Subject: Re: [v6ops] ND cache entries creation on first-hop routers
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 18:29:56 -0000

Jen Linkova <furry13@gmail.com> wrote:
    >> My big question at this point is whether (following Michael's lead) it
    >> belongs in v6ops, 6man, or 6lo.

    > Well...IMHO it's in the grey area between v6ops and 6man. It's an
    > operational issue. Caused by ND state machine design (I'm really not a
    > fun of a situation when legitimate packets are dropped by design). The
    > solution might be in v6ops or in 6man - we can either say 'oh, just
    > let hosts ping the routers or tweak their probing logic' or we might
    > look at ND state machine to see if anything could be done there.

It's not an IoT issue, it's just that constrained 6LRs have significantly
(orders of magnitude) fewer NC entries than typical routers, so we have
greater concerns.  If we can fix the ND state machine in some way, it
would likely help.

    >> Operationally, do you see it in non-IOT-attacks?

    > I have no experience and very, very limited knowledge of IOT area. I
    > do see it as an operational issue on IPv6-only WiFi.

    > I'd have never expected it but users do notice when it takes 5-10
    > seconds for their phones to start using WiFi. I'd be happy to consider
    > it a cosmetic issue ("everything will start working, just be patient"
    > but by number of complains it competes with 'Spotify client is broken'
    > one...
    > So I believe we shall at least  try.

So, you didn't answer the question ;-)
Are we seeing neigh-cache exhaustion attacks on IPv6 capable WIFI today?
5-10 seconds seems really high... it is really explained by just the
pathology you described?  Is it because the probes are not retried soon
enough after the first set failed?  Or is it because there are NC exhaustion?

In the IoT context, a sleepy device that wakes up and wants to do an
exchange out to the Internet, would benefit from anything that puts the
neigh cache entries in place faster.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.46.0 | Report a Bug | By Email | System Status