IETF Logo Mail Archive

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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fri, 22 February 2019 01:58 UTC

Return-Path: <prvs=1956a66f16=jordi.palet@consulintel.es>
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 78813130E2F; Thu, 21 Feb 2019 17:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 dnP-7sMw20Li; Thu, 21 Feb 2019 17:58:40 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E8212D7EA; Thu, 21 Feb 2019 17:58:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1550800716; x=1551405516; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=E4RaoXf2O+Dck6Ob5v+pTZtR2K4mZP76a7Jn4rUKWuo=; b=g5Qu8f9n+YC8a Gaso32S/4k4WSCoM4cqAgXdJgrRjLl+Y+Yb5UcV4QFfFNv+ss6PbIiNFnd/Z0/ux YWcYMYdm8RJmQT1KdcKfJM6dNkX/JHO6Obuvye0s4tHa9vsod7i990wX0pYVFLMM Qdolsi0OkQZRZewCgTon3u9wHR6k6M=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 22 Feb 2019 02:58:36 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 22 Feb 2019 02:58:36 +0100
Received: from [10.10.10.160] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006163789.msg; Fri, 22 Feb 2019 02:58:32 +0100
X-MDRemoteIP: 10.8.10.10
X-MDHelo: [10.10.10.160]
X-MDArrival-Date: Fri, 22 Feb 2019 02:58:32 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1956a66f16=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.7.190210
Date: Fri, 22 Feb 2019 10:58:14 +0900
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Tom Herbert <tom@herbertland.com>, Mark Smith <markzzzsmith@gmail.com>
CC: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Message-ID: <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es>
Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios
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>
In-Reply-To: <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xyYZZh0j1ynk2OtfsQobZE7Gih8>
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:58:41 -0000

    
    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.
    
I'm for as much privacy as possible, however, not at the cost of things such as:
- Unnecessary complexity increase
- Moving from peer-to-peer to client-server for everything
- Single point of failure
- Increasing the attacks chances by reducing the surface to the servers
- Increase the complexity of app development
- Complexity to host services in "clients"
- Complexity to use "freely" and "efficient" DNS
- etc

So, using the "privacy" in the extreme as a repellent to simple peer-to-peer is like if we say "knives need to be forbidden because they can be used to kill people".

If protocols or tools are badly used, law should take care of that.

We should make protocols able to support privacy as much as possible, but never at the cost of an extreme complexity and losing or degrading all the other features.

Regards,
Jordi




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

v2.23.0 | Report a Bug | By Email