IETF Logo Mail Archive

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

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Sun, 17 February 2019 21:28 UTC

Return-Path: <albert.e.manfredi@boeing.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 5042D124BAA for <ipv6@ietfa.amsl.com>; Sun, 17 Feb 2019 13:28:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 FMBDxKSn88if for <ipv6@ietfa.amsl.com>; Sun, 17 Feb 2019 13:28:23 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597E71271FF for <ipv6@ietf.org>; Sun, 17 Feb 2019 13:28:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1HLSKYC019501; Sun, 17 Feb 2019 16:28:20 -0500
Received: from XCH16-01-10.nos.boeing.com (xch16-01-10.nos.boeing.com [144.115.66.5]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1HLSCtj019406 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 17 Feb 2019 16:28:13 -0500
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-10.nos.boeing.com (144.115.66.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Sun, 17 Feb 2019 13:28:11 -0800
Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1591.014; Sun, 17 Feb 2019 13:28:11 -0800
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Ole Troan <otroan@employees.org>
CC: 6man <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: AQHUxCBHRRM+C8/2XkuG8rODXW4PVqXfllAAgAAFt4CAAAUwgIAAAy4AgAAM9oCAAAQqgP//9njQgADJZQCAAJC5gIAAGd2AgACnDwCAAB9bAIAACEMAgAB46ACAAMeBgIAAm3MAgACgVACAAJA0AP//iOtA
Date: Sun, 17 Feb 2019 21:28:11 +0000
Message-ID: <5784cd04d57548d896e890eb8aba5a89@boeing.com>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <CAO42Z2zh7fKAgQJq9aLCTiFoSSsTeGM=pK3gXitg+gcxH=9fhQ@mail.gmail.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> <2839D69E-1AB8-485E-95C4-B2882A355217@thehobsons.co.uk> <alpine.DEB.2.20.1902160553370.23912@uplift.swm.pp.se> <d2704b05cf844ed181921636bd7b6b57@b! oeing.com > <CALx6S34Zyjz62fs3DZjW0oiYmmzuOoQj_2s7T1b-saqfTKmBVw@mail.gmail.com> <20c80a52c8db4beb8381b21b633bc7f7@boeing.com> <31115B90-B25B-4136-8C1E-D445DE9680CD@employees.org>
In-Reply-To: <31115B90-B25B-4136-8C1E-D445DE9680CD@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: 7BCF67237F8BC406DA194BE762A3F351B254FE2266BE14B08BCFD05AC8E4153B2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3vTxVcxZ4oFjKaQ-dTw0zb3I5ho>
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: Sun, 17 Feb 2019 21:28:25 -0000

-----Original Message-----
From: Ole Troan <otroan@employees.org> 

> If your model of networking is dynamically changing addresses, then don’t you need a rendezvous point for all inbound communication anyway? Guess then you will not have much benefit from a 128 bit address space either.

Well, even if addresses can change, you still need lots of them, or you'll end up with conflicts.

But again, these arguments about apps surviving a reboot also existed with unpredictable and even short-lived IIDs, yet no one has suggested going back to totally predicable EUI-64. We seem to be doing that now, with static prefixes.

Apps can always be written to survive middlebox reboots, though, if that's important. If nothing else, the app can use its own session IDs, to bridge over short interruptions. I've seen some very credible objections by operators, on here, as to why long-term, permanent prefixes are problematic. That, plus consistency concerning previous privacy arguments, should be leading 6man to recommend against permanent prefixes? Not finding ways to ensure them?

Bert

v2.23.0 | Report a Bug | By Email