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 01:15 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 A83B712D4EA for <ipv6@ietfa.amsl.com>; Sat, 16 Feb 2019 17:15:48 -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 7SDlFyzKfxls for <ipv6@ietfa.amsl.com>; Sat, 16 Feb 2019 17:15:47 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 B8FA2128CF2 for <ipv6@ietf.org>; Sat, 16 Feb 2019 17:15:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x1H1FhDM022347; Sat, 16 Feb 2019 20:15:43 -0500
Received: from XCH16-01-09.nos.boeing.com (xch16-01-09.nos.boeing.com [144.115.65.234]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x1H1FdZk021244 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 16 Feb 2019 20:15:39 -0500
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-09.nos.boeing.com (144.115.65.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Sat, 16 Feb 2019 17:15:38 -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; Sat, 16 Feb 2019 17:15:38 -0800
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
CC: 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: AQHUxCBHRRM+C8/2XkuG8rODXW4PVqXfllAAgAAFt4CAAAUwgIAAAy4AgAAM9oCAAAQqgP//9njQgADJZQCAAJC5gIAAGd2AgACnDwCAAB9bAIAACEMAgAB46ACAAMeBgA==
Date: Sun, 17 Feb 2019 01:15:37 +0000
Message-ID: <d2704b05cf844ed181921636bd7b6b57@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> <9CDF4 1CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <2839D69E-1AB8-485E-95C4-B2882A355217@thehobsons.co.uk> <alpine.DEB.2.20.1902160553370.23912@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.20.1902160553370.23912@uplift.swm.pp.se>
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: 522BC99574995AA6E9A1C9804088B2C633376F334201882055292E044031F98E2000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_CurWmSyjdM7qdpgl9iwElR7iJQ>
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 01:15:49 -0000

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Mikael Abrahamsson

> I advocate the semi-static model, where the same address space is handed 
out as long as the customer is up and there are no network changes. This 
is what I have and it means my addresses (IPv4 and IPv6) change at a 
frequency of once per year or something like that. This is acceptable to 
me...

That's much like my ISP is doing. With IPv4, as long as I don't reboot my home router, the WAN side IP address remains the same. Occasionally, the ISP remotely reboots my CPE, and then too, the WAN facing IP address changes.

What are the security aspects of this sort of operation, for IPv6? Well, if I were concerned about someone keeping track of the household, then I'd just reboot the CPE equipment more frequently. Done.

But this has nothing to do with someone tracking my own movements. If I bring my phone or PC to a library of coffee shop, I get a different IP address anyway. Even if the home IPv6 prefix remains fixed, one's movements outside the home aren't impacted. Still (repeating myself), since the IETF has been so diligent in recommending against the use of EUI-64, and for random and even short-lived privacy IIDs, it only makes sense for the IETF to not spend a lot of time finding ways to keep your IPv6 home prefix static.

To solve this problem, it seems more beneficial to make appropriate changes to SLAAC, than anything else.

Bert

v2.23.0 | Report a Bug | By Email