IETF Logo Mail Archive

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

Tim Chown <Tim.Chown@jisc.ac.uk> Tue, 19 February 2019 13:30 UTC

Return-Path: <tim.chown@jisc.ac.uk>
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 C1B25130EEB for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 05:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 cd5YHg8sZDiv for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 05:30:38 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B3E130EE6 for <ipv6@ietf.org>; Tue, 19 Feb 2019 05:30:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1550583035; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Of2sHAsiaquvBQ0ZEsGlNGiJloG4zlsAwUItauU1ePY=; b=MHgCIdfy8uiePChdBPGEPJ5NYgEVi2H5+uYr/NEKjp3/YuhQs5qSuJeXi6UPB0OuUBHgEwDbox3BjDKN8Ih7YXpV/xr4RxdIvWoB6kM2/yaZRvUXGfbF/n8D1eLQyg8DIGcA1CW2r24KNInUJkmHyurTCsX83i+nDq4LYoYBGPo=
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp2057.outbound.protection.outlook.com [104.47.5.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-144-RoN4tI5AO6GjuwvkrubYxQ-1; Tue, 19 Feb 2019 13:30:28 +0000
Received: from DB6PR07MB4183.eurprd07.prod.outlook.com (10.168.23.158) by DB6PR07MB3064.eurprd07.prod.outlook.com (10.170.223.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.9; Tue, 19 Feb 2019 13:30:25 +0000
Received: from DB6PR07MB4183.eurprd07.prod.outlook.com ([fe80::909e:8725:a587:c757]) by DB6PR07MB4183.eurprd07.prod.outlook.com ([fe80::909e:8725:a587:c757%5]) with mapi id 15.20.1643.008; Tue, 19 Feb 2019 13:30:25 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Ole Troan <otroan@employees.org>
CC: Nick Hilliard <nick@foobar.org>, 6man WG <ipv6@ietf.org>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
Thread-Topic: A common problem with SLAAC in "renumbering" scenarios
Thread-Index: AQHUyEzCRyfkiR0M6E+jXGYmGdTvsaXnCugAgAAJvgCAAANHAIAABgIA
Date: Tue, 19 Feb 2019 13:30:25 +0000
Message-ID: <D40A650B-F490-4EAA-BB7F-4675A8075224@jisc.ac.uk>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com> <CAO42Z2yb47OyXk__Sz-kO00pfcBJgLAhff5DF=mpAddR0iCnAA@mail.gmail.com> <2612280f-195a-ae7a-b3b1-9022d9282fa7@foobar.org> <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>
In-Reply-To: <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.102.3)
x-originating-ip: [212.219.99.225]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b1ad69a3-810f-4402-ed43-08d6966e67ed
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DB6PR07MB3064;
x-ms-traffictypediagnostic: DB6PR07MB3064:
x-ms-exchange-purlcount: 2
x-microsoft-exchange-diagnostics: 1; DB6PR07MB3064; 20:hErjvoBIf7NoLQEGrcxSn/uWKOuIvOUUjbKyYaxvGt5NxmMdMlYcd6rygwgjQ1vMFf+uWhINTvEtuqoSgObPuShYwk/CWHkPsAiWkxxPBLkHOhgRMh/HKGZKxjVk6nFaxObxHVU9TPGWom6/uStxi+wjxr/5qYYWcfNLaIFQOGw=
x-microsoft-antispam-prvs: <DB6PR07MB30640D1FCA2897C84E8F7E2FD67C0@DB6PR07MB3064.eurprd07.prod.outlook.com>
x-forefront-prvs: 09538D3531
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39850400004)(366004)(376002)(346002)(199004)(189003)(229853002)(3846002)(14444005)(6116002)(33656002)(606006)(82746002)(68736007)(105586002)(106356001)(7736002)(74482002)(256004)(6916009)(11346002)(476003)(446003)(2616005)(6486002)(2906002)(6436002)(66066001)(97736004)(5660300002)(486006)(966005)(81166006)(4326008)(186003)(72206003)(86362001)(71200400001)(71190400001)(83716004)(6306002)(76176011)(53936002)(81156014)(25786009)(316002)(50226002)(6246003)(8936002)(786003)(14454004)(236005)(57306001)(53546011)(93886005)(54906003)(102836004)(6346003)(99286004)(6506007)(36756003)(8676002)(478600001)(26005)(54896002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3064; H:DB6PR07MB4183.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: zCqouxF79Ix/hwgFgyHBOiDBZO4RE/sIxXOtsQykcB2qUF69cl+ke4X0c5mpRP0kvxnLo3VxtuekXyKjBrOh3S8h7lPPkQHzaUFV5g2aRBeZpNa4o8O7qh+1fcZBnpQAwZsqfTYiIuM7tn7BlkVe5xF8uHrePe7XMQyGDv8NT0YDaIqUkCH6na4OaFhJrBAn5M3bWml/KtRiPv/07CCzcyONPUcd24856GcYov/PEG8NqHwXygAZCJPx2viCL/CQiAEjigKzot8QTlE69G9IT1sMy5tcNO8MWmI1n7+OaCN3axdRCFL0V7cX73ua/+gIjYeQ33pRlexFMkXZawKJcdmeE2Jxa12eiPte3rjg8dppNr1Iyx0JjgBonLjDMInIj/EaVY/XGGdKP7RzSNkloK2/tDcj36cqprtLVLfb7Yo=
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: b1ad69a3-810f-4402-ed43-08d6966e67ed
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 13:30:25.2007 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3064
X-MC-Unique: RoN4tI5AO6GjuwvkrubYxQ-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_D40A650BF4904EAABB7F4675A8075224jiscacuk_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ecjNeps6VXmPCcNtVNz4o66WbNg>
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: Tue, 19 Feb 2019 13:30:42 -0000

On 19 Feb 2019, at 13:08, Ole Troan <otroan@employees.org<mailto:otroan@employees.org>> wrote:

Nick,

On 19 Feb 2019, at 13:57, Nick Hilliard <nick@foobar.org<mailto: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.

There has also been quite a lot of work on IPv6 renumbering mechanisms. Which if used does handle the case where a customer needs to be renumbered, without causing significant disruption.

If we want to do significantly better, (as in handle flash renumbering etc) we need to look towards “session layers”, changing transport protocols.

It's been a while since we had an active IPv6 renumbering WG.  It must be time (again).... ;)

https://datatracker.ietf.org/wg/multi6/about/, b. 2001, d. 2007
https://datatracker.ietf.org/wg/6renum/about/, b. 2011, d. 2013

There’s nothing a bit of regulation can’t fix. :-)

I'm sure you didn't mean to invite regulatory enforcement :-)

So far the ISP industry has managed to stay largely self-regulated. Let’s hope it can continue that way. But that doesn’t mean the IETF should accommodate “operators cannot provide service with fixed addresses”.

Indeed.

Tim

Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email