IETF Logo Mail Archive

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

Jan Zorz - Go6 <jan@go6.si> Thu, 14 February 2019 23:19 UTC

Return-Path: <jan@go6.si>
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 C1A8C131170 for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 15:19:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 TX8-vwyi-35X for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 15:19:48 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [IPv6:2001:67c:27e4::23]) (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 9ABA712F1A5 for <ipv6@ietf.org>; Thu, 14 Feb 2019 15:19:48 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 240DE65A61 for <ipv6@ietf.org>; Fri, 15 Feb 2019 00:19:45 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id O1b3_CQg9uOl for <ipv6@ietf.org>; Fri, 15 Feb 2019 00:19:43 +0100 (CET)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id 6DA8865A2D for <ipv6@ietf.org>; Fri, 15 Feb 2019 00:19:43 +0100 (CET)
Received: from ISOC-BMDKQ4.local (unknown [IPv6:2001:67c:27e4:102:182a:e622:682:93c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 482EF807EB for <ipv6@ietf.org>; Fri, 15 Feb 2019 00:19:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1550186383; bh=HdgjTcV/21+Qj7A17fqNPBuaHDXFpn8eCTQeCMXL5F4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EZ834e31vj6Tr/7Mf2VgsAsmEdxbZZ4xqUhCOYnjeMtfwczWRQkss/R2l9Tt/kgvb NZPieYwNjj/oRjo3Tk7JrfpAYGzMBR5eIoJADNaH/yQI9muJ6rH02KY+iDDyHTh2E1 jG45ib9n0fa5dS4T8I3AJU2E+L5DPqTxUJia86ss=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <CAO42Z2xdKtLJV11KXELBKca6CWn=B6Avz6bO_94kFFXaKiZ-pQ@mail.gmail.com> <4602.1549908472@localhost> <CAO42Z2w1swQNuwnrOyTCEMXt0NSyrBx7Ww3kUN-7dfEV=fvk3A@mail.gmail.com> <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si> <1F2C2AEE-1C7D-481C-BBA7-7E507312C53A@employees.org> <e56a6e5b-648d-200e-c35d-97f15a31fb2a@asgard.org> <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>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si>
Date: Fri, 15 Feb 2019 00:19:42 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <e3e0bf2273e04f15b792665d0f66dfe5@boeing.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tAVViXSCrQA4NDq971XLHQfiVKo>
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: Thu, 14 Feb 2019 23:19:51 -0000

On 14/02/2019 20:30, Manfredi (US), Albert E wrote:
> If the prefix is known to be 64 bits wide, and is persistent, that
> prefix identifies a household every bit as positively as a persistent
> 64-bit IID identifies a device. How come we aren't seeing
> recommendations AGAINST persistent prefixes for CPE devices?

Because in current state of today generic 
ISP_provisioning/CPE/host_stack implementations combination it doesn't 
work properly in real environment. ISPs ASNs and IPv6 traffic gets 
blacklisted by large content providers that are measuring for broken 
IPv6 implementations. Happened many times, hence this effort to make 
situation better :)

To augment what many already have said here - it's a tie between IP 
address and household address and name/surname that should not be 
public, the address itself is mostly harmless and it doesn't matter if 
it's static or dynamic. Tracing gets done on L7 and above anyway ;)

Cheers, Jan

v2.23.0 | Report a Bug | By Email