Re: RFC4941bis: consequences of many addresses for the network

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 23 January 2020 13:47 UTC

Return-Path: <prvs=12914b7dcb=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 9F9A512009C for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 05:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] 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 MmYfhmUUfuc2 for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 05:47:04 -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 0000F120096 for <ipv6@ietf.org>; Thu, 23 Jan 2020 05:47:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1579787221; x=1580392021; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=9SidfT24 v89mS6vwY6g4p7zil+iPdGM49cV+mVV7VoU=; b=V1KzpdXEVqCdhoMVgMRktLup XXqLqtGNQuJ25BbqpK41u5gKnjrV4xFw6ofMtMQILMUJ3oosVV1nqbGY3FckAayK Dwi7VTucaNDxFc6xubMFnp9eXRZpnT8RhLXHIqJOhy3IukqNowF7jews7MTjYToZ umlWhPs98C8OR6Rp3R8=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 23 Jan 2020 14:47:01 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 23 Jan 2020 14:47:01 +0100
Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000038428.msg for <ipv6@ietf.org>; Thu, 23 Jan 2020 14:47:00 +0100
X-MDRemoteIP: 2001:470:1f09:495:7806:b5ea:b6ac:3b51
X-MDHelo: [10.10.10.130]
X-MDArrival-Date: Thu, 23 Jan 2020 14:47:00 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=12914b7dcb=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/10.21.0.200113
Date: Thu, 23 Jan 2020 14:46:58 +0100
Subject: Re: RFC4941bis: consequences of many addresses for the network
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>
Message-ID: <AFEBAD7D-DF24-4924-8B9A-60DF22BA1953@consulintel.es>
Thread-Topic: RFC4941bis: consequences of many addresses for the network
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <MN2PR11MB3565330989D411525D30B90DD80F0@MN2PR11MB3565.namprd11.prod.outlook.com> <80207E17-AE8E-4D19-B516-D2E6AB70721E@employees.org> <8D5610EA-49D3-483E-BB7A-67D67BC89346@jisc.ac.uk> <DE7B0688-230F-4A5C-8E24-9EAED9FD9FEB@puck.nether.net>
In-Reply-To: <DE7B0688-230F-4A5C-8E24-9EAED9FD9FEB@puck.nether.net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PWvJlZ7w3ukBFE1AnJfMjCtzED8>
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, 23 Jan 2020 13:47:07 -0000

Even not just debugging, but the operational complexity when in some scenarios, certain apps need to "audit" which user did what. Using DHCPv6 is not an option, because Android doesn't support it ... and I will not recommend a customer to use "manual IPv6 configuration" :-(

El 23/1/20 14:37, "ipv6 en nombre de Jared Mauch" <ipv6-bounces@ietf.org en nombre de jared@puck.nether.net> escribió:

    
    
    > On Jan 23, 2020, at 8:32 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
    > 
    > The problem statement section in 4941bis is all about user privacy, no mention of operational / management complexity, or other “general problems” that SLAAC has.  It seems there are unstated problems here :)
    
    
    I would +1 this here.
    
    I would also generally question if rotating IPs is a adequate privacy protector considering there are other ways to identify users that are being (broadly) employed today.
    
    The complexity that this introduces into networks for operational debugging (provider: what’s your IP address so I can debug? User: Well here’s the 20 on the host because I have limited lifetime privacy addresses, and I don’t know what outbound one it’s using for this connection.  Provider: What’s your IP address so I can debug?  Actually, can you just turn off v6 so I can debug your problem?  User: sure, I just want it fixed).
    
    - Jared
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
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.