Re: RFC4941bis: consequences of many addresses for the network

Tim Chown <Tim.Chown@jisc.ac.uk> Fri, 24 January 2020 10:58 UTC

Return-Path: <tim.chown@jisc.ac.uk>
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 90E6D1200E5 for <ipv6@ietfa.amsl.com>; Fri, 24 Jan 2020 02:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 f7wpxa2XXVum for <ipv6@ietfa.amsl.com>; Fri, 24 Jan 2020 02:58:56 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2011200CC for <ipv6@ietf.org>; Fri, 24 Jan 2020 02:58:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1579863534; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lYbc7F4qMYFcV1+or4maoRV8o4adczCHlk9EK/ZtCDw=; b=FuI6SC+5D5U/Z3CI6CnCP4keFCYIzB08eDjXJfkRPi+Ajii0aOgRK/Agq/p2SnAh/QWv1W 3+0VKnib1kKddcZ3YsXacL5oSsucliKANFPXrARsFBx+s/aWYH7J8qx9a1NydoOmB4X4Oj /+/43xKn3ffIj50B7oZp+M1RefNyIEo=
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp2109.outbound.protection.outlook.com [104.47.17.109]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-180-kTHq6uw4Ony_khwS66Lo3w-1; Fri, 24 Jan 2020 10:58:50 +0000
Received: from DB6PR0701MB2856.eurprd07.prod.outlook.com (10.168.84.9) by DB6PR0701MB2167.eurprd07.prod.outlook.com (10.168.58.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.15; Fri, 24 Jan 2020 10:58:49 +0000
Received: from DB6PR0701MB2856.eurprd07.prod.outlook.com ([fe80::5cf1:d058:1210:950f]) by DB6PR0701MB2856.eurprd07.prod.outlook.com ([fe80::5cf1:d058:1210:950f%3]) with mapi id 15.20.2686.013; Fri, 24 Jan 2020 10:58:49 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: "otroan@employees.org" <otroan@employees.org>
CC: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, 6man WG <ipv6@ietf.org>
Subject: Re: RFC4941bis: consequences of many addresses for the network
Thread-Topic: RFC4941bis: consequences of many addresses for the network
Thread-Index: AQHV0cuAf+cCl/1lXUyJflIGA5fqsKf4RoyAgAAD4oCAAVZVHoAABEyAgAAB3AA=
Date: Fri, 24 Jan 2020 10:58:49 +0000
Message-ID: <94B1AF33-7466-4ED0-9BA4-EBA126B97370@jisc.ac.uk>
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <e936078e-01f9-0254-a8d0-4095455154ac@si6networks.com> <D85412DF-4B03-4790-9E39-968D50ECF86B@employees.org> <m1iuwJV-0000MAC@stereo.hq.phicoh.net> <B341FF1B-C559-4D54-B117-A58EB6A3C955@employees.org>
In-Reply-To: <B341FF1B-C559-4D54-B117-A58EB6A3C955@employees.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.40.2.2.4)
x-originating-ip: [2001:a88:d510:1101:54d1:3f90:8530:1f81]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c9ec646b-77f6-4e1b-bf0c-08d7a0bc6452
x-ms-traffictypediagnostic: DB6PR0701MB2167:
x-microsoft-antispam-prvs: <DB6PR0701MB216726F89E287C0BFD446AAAD60E0@DB6PR0701MB2167.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02929ECF07
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39850400004)(376002)(136003)(396003)(346002)(366004)(189003)(199004)(6916009)(966005)(4326008)(53546011)(6506007)(71200400001)(64756008)(66446008)(81156014)(66556008)(66946007)(6512007)(8676002)(81166006)(91956017)(76116006)(66476007)(5660300002)(54906003)(2906002)(316002)(786003)(86362001)(6486002)(33656002)(2616005)(8936002)(36756003)(478600001)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2167; H:DB6PR0701MB2856.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2wXvsM0vg0ghWROZzOw5x3Vf+N5gRbUHgTnHqB0Xch40R7O1bcB1e5t34GRYCzzsYtlZGkn6e3SG2s8/Ml7lwFb80qK1bcY6lWieznyL9nplqjMw0ZXRWN9XC1t7xLKtTo9WlT8Aa9cpA2i8YTPgH3dkSZ24HRubslV/J9x2dtHXtcMUVbgJ+NJQkmoA+wRDVHrnS0wSZ5VTwwZH42fTKwU/MyhBh3VrxzaHTtXOsFXXTfemOguMIh9J5TzXEKsp3aeliLtGlO/P2XyY5RwoMhIylvXBc2FcqFKlllMnpVFf+AiB9KXvhBYdugfS7XHwPLigIYy/KYx8H+93p8N4KRk4HYQ781NNf61tqDjRn1BCJpNZe8ITqA7plmooyG6u/FIsBh2pUXcQ/IFXAO1qm0qeXNO5lAPOt/dM8AgixdVzVP7a20rlSNA93qg/H9VYC6fTu89ztVDGMJ85hpyvzOYthTl8dGcIYo0vHslKbMg=
x-ms-exchange-antispam-messagedata: jpFkCZtPH+H/x90vXwhJZzXb5/1buXWGL4w9Qqi9uBifx9iw83eW1Z+PyyoAQzK0gQWo1nQQpmQM7VnEMwcCyaR6x8S7CYLZa8gHzsCAuLN4fpJeVRW4xIP5jLA9nDKdGM8dZbG9nTTLzP8v7zsEaW9l7sfrnLYAgnMLqsHexQ1yaUvjMJ8WlcfYhS1lq+8bqeUCc5en8FOrwWRfqwAjrQ==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: c9ec646b-77f6-4e1b-bf0c-08d7a0bc6452
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2020 10:58:49.3334 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LqFViiTb3Ot6ZYIDzNeAUG1LLN7dfdyhKCtfJ5uf7WwrUkMhRDE1ADSs3kcoDPrpy76i9GXs+CoQksB6aC/2TQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2167
X-MC-Unique: kTHq6uw4Ony_khwS66Lo3w-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: jisc.ac.uk
Content-Type: multipart/alternative; boundary="_000_94B1AF3374664ED09BA4EBA126B97370jiscacuk_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/EcRkOksUtkapk2ccTdul6xjjYVU>
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, 24 Jan 2020 10:59:00 -0000

On 24 Jan 2020, at 10:52, otroan@employees.org<mailto:otroan@employees.org> wrote:

Hi Philip,

The question of an address per transport connection is why would you do that?
In many IPv4 installations, the NAT box has state per flow. So having an IPv6
address per transport connection doesn't seem beyond what we can do.

On reason might be because the application uses the temporary address in a way that taints it.
E.g. the address is used in a connection where the user is identified through authentication.
That address is now tained from thew perspective of privacy, and should not be used for other connections.

There is new work that is aware of that.  For example (as I was reviewing it very recently) in draft-ietf-intarea-provisioning-domains:


   In order to address privacy concerns around
   linkability of the PvD HTTP connection with future user-initiated
   connections, if the host has a temporary address per [RFC4941<https://tools.ietf.org/html/rfc4941>] in
   this PvD, then it SHOULD use a temporary address to fetch the PvD
   Additional Information and MAY deprecate the used temporary address
   and generate a new temporary address afterward.

I like that from a privacy perspective, even if it is only a MAY, but from the management/ops point of view it’s another address in use.

The flip side is there’s no note there mentioning the downside of doing so.

Given that we are downgrading 4941 to proposed standard, it might also be worth evaluating the state of 4941 implementations.
Are applications clever enough to not reuse tainted addresses?
Are they incorrectly exposed by e.g. MP-TCP or ICE implementations?
Anyone with data on this?

The question is what the benefits are. I don't see a lot of privacy benefits
for lots of addresses.

Note that a single network port may still end up with losts of addresses:
- users may use bridges to extend the network and connect more than one host
to a single port
- users may run virtual machines (or containers) in bridged mode and end up
with multiple virtual hosts by behind a single port
- having an IPv6 address per process on a host may have benefits in particular
if many processes would like to use the same port for some reason

Typically, even very small network switches support many thousand MAC
addresses. I think that network devices should support similar numbers of
IPv6 addresses per /64.

Sure, but when a host incurs a cost in the network, and the network has to have some policy in place to protect itself, there is going to be a limit.
I think we need some text in 4941 discussing this, and also give a recommendation for host behaviour. And perhaps also for network configuration.

It’s an interesting tradeoff, and different environments will want the slider on that tradeoff at different ends of the scale.  But it’s certainly worth capturing.

Tim


Cheers,
Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------