IETF Logo Mail Archive

Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Owen DeLong <owen@delong.com> Fri, 22 February 2019 01:04 UTC

Return-Path: <owen@delong.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 E8518129AA0; Thu, 21 Feb 2019 17:04:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.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 Z9MJxtMPtLd6; Thu, 21 Feb 2019 17:04:42 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C1F67130E7E; Thu, 21 Feb 2019 17:04:40 -0800 (PST)
Received: from kiev.delong.com (kiev.delong.com [192.159.10.5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x1M14aWe019017 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Feb 2019 17:04:37 -0800
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x1M14aWe019017
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1550797477; bh=rUzKDbCpidMpLBo6HXNzYj5PU7qLxZefZCmBeYqL7vs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=eYX815VDBImwe9wLHzYTJz1EwSoUGx9CxRry3mchu2bPh/kfaWquLTkx3JdzpNMKY +/YlzeOfC1/YE026AtQXqJW3m0ZPPU+fAijY+slWeehVz+MtdqEa/Wht/G0YkFgxfZ TrJAW+2e5nXY9y0aZMBbr/PwD0kLpJlby/arg6hM=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CALx6S37Ya0cRmh-KgOsc+CVJrvV8tbS8pMmzavcYcFTy3UYo6A@mail.gmail.com>
Date: Thu, 21 Feb 2019 17:04:36 -0800
Cc: Mark Smith <markzzzsmith@gmail.com>, "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A3A4AF6B-9CFE-4099-8DE5-612E9D3D974D@delong.com>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <D1BACB13-1C00-4E23-A8BC-A669BFE73559@delong.com> <CALx6S37Ya0cRmh-KgOsc+CVJrvV8tbS8pMmzavcYcFTy3UYo6A@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Thu, 21 Feb 2019 17:04:37 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/X3EdPgQmBX8e-o5TyzPk_UKdEU0>
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: Fri, 22 Feb 2019 01:04:46 -0000


> On Feb 21, 2019, at 16:18 , Tom Herbert <tom@herbertland.com> wrote:
> 
> On Thu, Feb 21, 2019 at 3:49 PM Owen DeLong <owen@delong.com> wrote:
>> 
>> 
>> Mark,
>> 
>> I agreee with that with one exception. I believe that NAT/IPv4 can
>> offer better privacy in addressing than IPv6 given current addess
>> allocation methods.
>> 
>> 
>> Huh? Random 64 bit numbers are less private than semi-opaque translation of 32 bit numbers?
>> 
>> In today’s world (where CGN is fortunately still mostly the exception rather than the rule), the
>> 32 bit public number (mostly) identifies the household on a transient basis.
>> 
> Owen,
> 
> Privacy in CGN effectively if the device lives behind a NAT with
> thousands of user. So if the an external external third party observes
> two different flows that share the same NAT address, then the observer
> can not infer that the two flows are sourced form the same device or
> user.
> 

Sure, but today, CGN is the exception, not the rule… Hopefully it will remain that way for the
foreseeable future as CGN is really an awful awful thing for the end user.

Also, due to CALEA constraints, most CGN implementations are going to quasi-static port
reservations per household, so it’s not as private as you think it is. It will raise the bar
slightly, forcing the third party to track an extra 32 bits per flow (2xport number), but that’s
about it.


Owen

v2.23.0 | Report a Bug | By Email