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

Mark Smith <markzzzsmith@gmail.com> Wed, 20 February 2019 09:32 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 9E1BE130DC4 for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 01:32:52 -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 gF_nrZg2S1iY for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 01:32:51 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 433C5124B0C for <ipv6@ietf.org>; Wed, 20 Feb 2019 01:32:51 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id v20so7117926otk.7 for <ipv6@ietf.org>; Wed, 20 Feb 2019 01:32:51 -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=kglxITQOiSNknl5YCxC9XNby7oDHvWKC4QZmUM3P8xM=; b=CJ25EiuMhxDcymsckvYSgAjf0eDVJtp09jytwouYaRpi/wmwIXzqH/K0TRVSQP3EX9 jlZB1KY7pL29AbM+1ysOmw0OA9vQ8plWKWVwk9S7VxY8nOHcRol5uDi3F4voSp/2zIAM RbovomuuN8rnzHRFLYycIA3q0iNM8XYyFP1BpzSwWY0u4/ATu722NFYbeO7R346j1eak NEJELHYSChgcCPT7UBMvzErFN3ZRw0O5KoL7UyQPiVBiH2LiEYlsGr8tIWWuhg9KKDVI 7UoJDlMZ96DVSYGIzoEU2dlZHHuugvzb2Oy3NuRvvHrz9LZ2mi+xAO5vVOqBh0Nz8/qj GUDA==
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=kglxITQOiSNknl5YCxC9XNby7oDHvWKC4QZmUM3P8xM=; b=V1lJ1KN8oCGNsjPtEhN/JTT5UhYh6MzYHheQWkv8Z/q8S+ilVVq5CalCV5DV+zUfVa ZTxcJ/oIoVgd8N2GcfEuop7iOrIvZ4MqKuI2YXcCapKIjYHUV91iFF8ccQUhOCSmFEal L/JgLcCzPYe+HSBOP4/HLzcBA1ZuVVSKEP9vKR32yKnJwlLuD5XR2pY1bWqKR/oojXsO Lma5OMLRQs+esx/sYHVOjM9fnNVMjnrARKNuwK7P8QxR8rGTj8i2cpOA1fU5yR9fdHUx mB4bZINk3wilAsb+rwfeTJGHxcG2PdHIQFYmDPhNYTCl5OaJULy7HDLiYqIlIwy1wxCn Juxw==
X-Gm-Message-State: AHQUAubiNtR3o4xqJrtV2wNDlsBU9wsf/8OkjZBL5LXUWRd2HqDRMYNe BUzp8xhf3g2CAyqIjtI3CzTPRiVLXbULjfdzeiI=
X-Google-Smtp-Source: AHgI3IbZ6JnM+y8/NYz/b1XmSEqiP/f1YdJrCAhCsgxPoXij3jYASmRFrUtcvWUr3Z3jm/LXzViXXYbym5p1PeFdZrU=
X-Received: by 2002:aca:4747:: with SMTP id u68mr5349006oia.38.1550655170346; Wed, 20 Feb 2019 01:32:50 -0800 (PST)
MIME-Version: 1.0
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.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> <CAO42Z2wa9gWoB_bWrYt79urHF8ihmMAbjDSZCBoZa8dn8SCNFw@mail.gmail.com> <cfe8d901-b1db-78fc-2a80-ae85ccf0c0d3@si6networks.com>
In-Reply-To: <cfe8d901-b1db-78fc-2a80-ae85ccf0c0d3@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 20 Feb 2019 20:32:23 +1100
Message-ID: <CAO42Z2yAXnFRViCZ7Wf27twUAanuSLA30jcHZZPa30HJsg7adQ@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"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/oCamR2fnDjLbXrV4RU-HXgjJPCE>
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 09:32:52 -0000

On Wed, 20 Feb 2019 at 19:11, Fernando Gont <fgont@si6networks.com> wrote:
>
> Mark,
>
> On 20/2/19 03:16, Mark Smith wrote:
> > On Wed, 20 Feb 2019 at 15:22, Fernando Gont <fgont@si6networks.com> wrote:
> >>
> >> On 20/2/19 00:11, Ole Troan wrote:
> >>>
> [....]
> >>
> >>> 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.
> >>

<snip>

> >
> > - 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.
>
> Your are turning a kludge into a design principle.

It's been a design assumption and expectation rather than a principle,
and an expectation TCP has had since 1974 (see RFC675, 2.2  "Sockets
and Addressing"  (That's TCPv1, before IP was split off)).

 <snip>

>
> Clearly, with your model of TCP connections surviving interface up/downs
> and the default lifetimes, you really have a host that is unusable,
> except in very specific network conditions -- such as: the host never
> moves (quite unlikely these days)

A 2013 presentation that makes that observation and some others.

"The Rapid Rise of the Mobile Multihomed Host, and What It Might Mean
to the Network"
http://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf


> and nothing (including the CPE) fails
> (quite unlikely).
>

I'm not saying these behaviours and expectations are necessarily correct today.

What I am saying is that they are and have been foundation design and
implementation assumptions that have been in place for multiple
decades. I think the longer a foundation assumption has been in place,
the more care and consideration you need to give to changing it,
because there can be unexpected impacts. Given those impacts, it may
be better to preserve them and design around them, compared to trying
to change them ("boiling the ocean"). The Mobile IP people, for
example, took this approach.

People have said moving to multi-path transport layer protocols is
trying to boil the ocean.

Compared to providing stable PD prefixes within the BNG
infrastructure, I consider upgrading CPE to be boiling the ocean -
waiting on a CPE vendor to develop that firmware (depending on their
development priorities you may be waiting 3 to 6 months or possibly
longer), testing, and then deploying 100s of 1000s of CPE software
upgrades during many middles' of the night, with a risk of a
percentage of upgrades failing. That's if you have managed CPE. If you
support BYO CPE (very common in Australia), then the time frame for
CPE functionality changes through upgrades is in the order of 5 years
or more, because people don't replace BYO CPE unless it stops working,
and they don't upgrade firmware either if it subjectively seems to
them to be working.

Upgrading ISP network infrastructure and back-end systems isn't easy
either, however it is within house so runs to your schedule and
resource availability, and all customers using that
infrastructure/system gain the benefit without having any changes made
to their equipment or configuration.

Regards,
Mark.