Re: RFC4941bis: consequences of many addresses for the network

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Fri, 24 January 2020 10:35 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 4C55E1200BA for <ipv6@ietfa.amsl.com>; Fri, 24 Jan 2020 02:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Level:
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 QsT_wwQaIiPH for <ipv6@ietfa.amsl.com>; Fri, 24 Jan 2020 02:35:56 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 6E1191200A1 for <ipv6@ietf.org>; Fri, 24 Jan 2020 02:35:55 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iuwJV-0000MAC; Fri, 24 Jan 2020 11:35:45 +0100
Message-Id: <m1iuwJV-0000MAC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: RFC4941bis: consequences of many addresses for the network
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <e936078e-01f9-0254-a8d0-4095455154ac@si6networks.com> <D85412DF-4B03-4790-9E39-968D50ECF86B@employees.org>
In-reply-to: Your message of "Thu, 23 Jan 2020 15:11:31 +0100 ." <D85412DF-4B03-4790-9E39-968D50ECF86B@employees.org>
Date: Fri, 24 Jan 2020 11:35:44 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zahVMEjHpuzNUu6iQJPVZL25cGo>
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:35:59 -0000

>Absolutely. Just that temporary addresses changes the equation quite a bit.
>A network might be willing to serve a small set of addresses to a host, but wi
>th temporary addresses there are really no limit.
>If you do an address per transport connection, would you expect the network to
> serve that?
>And if it doesn't, how is the host supposed to detect it? An happy eyeballs ap
>proach?
>Right now that is completely unspecified in 4941bis (and sure it also was in 4
>941).
>Question is if we should (try to) fix that?

I'd say that if a network wants to have control over how addresses are
allocated it should use DHCPv6. Certainly if we are talking about relatively
low limited on the number of addresses per host.

However, given the desire to fit everything in SLAAC, what is missing at
the moment is a way for the network to express intent. 

The most basic way would be for a flag that disables temporary addresses.

A more adavanced option would be specify limits on the number of temporary
addresses and possibly ways to register/deregister an address. For example,
nodes can keep addresses alive be periodically generating a NA for the address.

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.

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.