Re: A common problem with SLAAC in "renumbering" scenarios

Mark Smith <markzzzsmith@gmail.com> Wed, 20 February 2019 06:16 UTC

Return-Path: <markzzzsmith@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 8A89B12426A for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 22:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 MSkrani89puR for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 22:16:35 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 4E5B8124C04 for <ipv6@ietf.org>; Tue, 19 Feb 2019 22:16:35 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id c18so16781304otl.13 for <ipv6@ietf.org>; Tue, 19 Feb 2019 22:16:35 -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:content-transfer-encoding; bh=WTvLwVaPLn/Xfwv1oxr9kk6HHgdhS7FZSpxO+zP2cXM=; b=QiKM88ldQ1SReHYt2rNEP5096MTjAn16rJyFBDNyuGkcZlucpcDsy9bbbs5KeVadpT kLFWOlWQnHVkPDP1RJrrBz4TXnA9cjWg3yLviFtTpD1lHula8PJQPlLEDm75+vhMerax e0U93lrgNF641tak72uSvoJ6Tg0XTuzwXG6LRp0yq4ExqxSzZ9zo6u54Iiq90KEQN7qF vsBS5XzBgVK203VGw0XX2OyzjiHh/ljaaziizrhTdPWVRF5Oa/nYpfyhSFHEl1YEI9vU FBIfTjVb7jNweDydOHbIbeqTXOO+I/7Ce5zlGTYzDW2ejQiPUUKWvW9b0VgIU++EQkFl Ozuw==
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=WTvLwVaPLn/Xfwv1oxr9kk6HHgdhS7FZSpxO+zP2cXM=; b=ENtMYEzTRg+Kt0R+AqTMnUTsk7OpfVo0TfDAlTSOnG7b6Nw1MxHPlARrb2429eyW6t hawiPo+qKPh0jBpU1W4kKoSKbCuky1EdqjDbcnoEvkgRXjOVJJvfQvmwGqzJ5QM0l7/Y o0PY0KIxSUaeJP8sWmz/rzRsz6j01C3/vRekCtgpvAa0kkmM5dBuPu+rdXGq0xs0vIQ8 OCRNQaA9+P5AEzP/vuQwnDjVK3aiiVLdmKVwZNu+nXTgbc8Gi1ITP3LsZRIZCuz4xt7L fyzXdXS6zlmHX3orNJMALsWA2cTXddqlb196Ga7NBCgPq7Yb1YO7md6wRL+gCHGPd6ek MDaQ==
X-Gm-Message-State: AHQUAuYYWn4CKmgoxdXA8aTVznQAbWppaiIQFODQ852QXvjakxh2bZCO HWh5/vrF0Y21/piCjy6IHENMfUvpFwKgNIzlZ6E=
X-Google-Smtp-Source: AHgI3IYmezedALUAS4WgmjJxRSO5IrAWg9wo+JJBmKXuQfzwTWIpJz58EcYokHcB8putKym2CauF6ErHKcDJzVzhHGU=
X-Received: by 2002:aca:be85:: with SMTP id o127mr4754537oif.164.1550643394202; Tue, 19 Feb 2019 22:16:34 -0800 (PST)
MIME-Version: 1.0
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <56F813F4-C512-40A9-8A68-1090C76A80F6@consulintel.es> <CAHL_VyCN8kU7qnLOphfGR25-xGBe_p6WeGTkKVXwU5uy5aJ8Dg@mail.gmail.com> <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es> <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com> <8CE7A0CD-97D9-46A0-814D-CAF8788F9964@consulintel.es> <e3e0bf2273e04f15b792665d0f66dfe5@boeing.com> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <b4525832-9151-20bf-7136-31d87ba6c88d@huitema.net> <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com> <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org> <bbd8b761-403a-5b3f-3f04-dc3bfdea116e@foobar.org> <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org> <433607c1-dbc6-a42e-cb17-dc209e33bdaa@si6networks.com> <12EA4FAE-BE3D-4CFE-9837-DF052F79A998@employees.org> <5bc3eaf0-3ef0-d954-b228-00a7faac7f4c@si6networks.com>
In-Reply-To: <5bc3eaf0-3ef0-d954-b228-00a7faac7f4c@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 20 Feb 2019 17:16:07 +1100
Message-ID: <CAO42Z2wa9gWoB_bWrYt79urHF8ihmMAbjDSZCBoZa8dn8SCNFw@mail.gmail.com>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Fernando Gont <fgont@si6networks.com>
Cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/y0fnraT-sr4D5SYeMpR8s3BDzXc>
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, 20 Feb 2019 06:16:38 -0000

On Wed, 20 Feb 2019 at 15:22, Fernando Gont <fgont@si6networks.com> wrote:
>
> On 20/2/19 00:11, Ole Troan wrote:
> >
> >
> >> On 20 Feb 2019, at 03:50, Fernando Gont <fgont@si6networks.com> wrote:
> >>
> >>> On 19/2/19 10:08, Ole Troan wrote:
> >>> Nick,
> >>>
> >>>> On 19 Feb 2019, at 13:57, Nick Hilliard <nick@foobar.org> wrote:
> >>>>
> >>>> Ole Troan wrote on 19/02/2019 12:22:
> >>>>> Indeed. Wonder how these pesky mobile phone operators manage to
> >>>>> deliver the same telephone number to a user, for years. Across
> >>>>> different providers and contracts.
> >>>>> I can’t think this argument is anything but a strawman.
> >>>>
> >>>> Ole,
> >>>>
> >>>> if recommending static IP addressing is an idea that 6man wants to push, you'll need to reach out to the security and ops areas to get their input on this.  I'm not sure this is an issue that 6man can resolve fully.
> >>>
> >>> It’s been the IPv6 addressing model for at least 20 years, so I think the other areas have had ample time to provide their input.
> >>
> >> For the reasons stated in draft-gont-6man-slaac-renum, I don't think
> >> this affects the discussion we are having. But, out of curiousity,
> >> where's the "addressing model" you are referring to documented?
> >
> > I can’t see slaac-renum tackling these issues.Which reasons are you referring to?
>
> A significant percentage of IPv6 deployments don't employ static
> prefixes but dynamic prefixes. That's a deployment reality.
>
> How you (or me) would like things to be doesn't change deployed reality.
>
> Our I-D tries to deal with such deployed reality.
>
>
>
> > With regards to the addressing model, your question shows a certain lack of history, but given that we all gave lived under the reigns of NAT for so long.
>
> You have been referring to an addressing model that implies
> static/stable addressing. I simply asked where that model is described.
>
> If such requirement is not spelled out somewhere, I don't know why you'd
> refer to that as a model, or even why you could expect it.
>
> Not sure how my question for a reference that backs your model can turn
> into something I'm supposed to be lacking, missing, or ignoring.
>
>

I think it is implicit in a lot of places, if not stated explicitly
anywhere (although it may be somewhere in an RFC like RFC1122).

- By default, hosts don't delete addresses from interfaces if the
interface goes down. Addresses persist across interface down/up
events. If the most common cause of hosts' interfaces going down and
coming back up was considered to be attachment to a different link,
then addresses would probably be deleted by default upon link down.

- As Ole implied, TCP uses addresses as identifiers, so TCP expects
that the address will persist for the entire duration of the TCP
connection, regardless of how long that duration is.

- TCP connections survive the host's local interface down/up events.
They're treated as a possible period of transient packet loss (the
same as packet loss anywhere else in the network), rather than an
event that terminates the TCP connection.

- The SLAAC default preferred and valid lifetimes are very exceptional
and remarkably large compared to other typical default networking
timer values that are in the order of 1s, 10s or 100s of seconds. The
default Valid Lifetime is ~2.6 million seconds/30 days.

Considering that a single RA would reset a decrementing address's
Valid Lifetime back to ~2.6 million seconds, I think that suggests
that TCP can expect that an address it is using on a host can be
relied upon to exist for a minimum of 30 days, so a TCP connection
should be able to be relied upon for a minimum of 30 days. That's
exceptionally robust given that the unsolicited RA default maximum
interval is 600 seconds.


Regards,
Mark.

> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------