Re: [v6ops] Implementation Status of PREF64

Philip Homburg <pch-v6ops-10@u-1.phicoh.com> Sun, 10 October 2021 20:27 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA123A0D6E for <v6ops@ietfa.amsl.com>; Sun, 10 Oct 2021 13:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, 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 8cYnp4UtI76y for <v6ops@ietfa.amsl.com>; Sun, 10 Oct 2021 13:27:02 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:981:201c:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558F43A0D6D for <v6ops@ietf.org>; Sun, 10 Oct 2021 13:27:00 -0700 (PDT)
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-CHACHA20-POLY1305) (Smail #158) id m1mZfPJ-0000IoC; Sun, 10 Oct 2021 22:26:53 +0200
Message-Id: <m1mZfPJ-0000IoC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
Cc: David Farmer <farmer=40umn.edu@dmarc.ietf.org>
From: Philip Homburg <pch-v6ops-10@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <DDA36020-90CC-471B-83AD-3D98950F1164@delong.com> <CAKD1Yr0T-7t-UHbsJBMLpTjKhPAV5uUQkux6oby89TVUue7PyA@mail.gmail.com> <CO1PR11MB4881D400EA4681F1505040D2D8AA9@CO1PR11MB4881.namprd11.prod.outlook.com> <CAKD1Yr3TmqFxjKuZ57wS7VuPOf6rJvOwnvnQdFrRLQ=DkZ+CCw@mail.gmail.com> <CO1PR11MB4881F411A4D5BEA7A8479726D8AA9@CO1PR11MB4881.namprd11.prod.outlook.com> <D8AEA194-293B-43E4-BCAE-33CD81FB7D8C@delong.com> <CAKD1Yr2Tug-PFV7wAh0s6-gw8W3LcLG7wC1fD7Lu_hMZQYKdtw@mail.gmail.com> <08D2885E-B824-48E8-9703-DCA98771FA37@delong.com> <CAKD1Yr2EVsY3tYUf56R0Q1+KVrowtqh-HgwXj5vxzy4wd-vkTg@mail.gmail.com> <1A6ED87B-666E-439C-852F-2E5C904C0515@delong.com> <CAKD1Yr23fY2DJDvB-9eVFRsxnBnZQ0kZuZfYUfRUHYW=_D=enA@mail.gmail.com> <CAN-Dau1z0q0R61x7iY+Wg_cFRU0jmqr+fR0y=bSXxj+K-n722w@mail.gmail.com> <CAKD1Yr1T_mXfxJGHOrBfqZfexm6GTrUqnFi57710pTroKQK6uQ@mail.gmail.com> <702CB018-1A02-4B32-B9AA-7C7B31521F12@delong.com> <CAKD1Yr0jZR8Efzr_Y6FeiBvHYS8ATmDupx2ABTXXy-rSA_QjmA@mail.gmail.com> <1adb70a8-db0a-4ea6-f7 21-c1035343cda3@foobar.org> <DM6PR02MB69249D4F0A8003E77EC9F153C3B19@DM6PR02MB6924.namprd02.prod.outlook.com> <CAN-Dau0q7p-9NWv=9vouX51Z1Yqe_h06WwpnkMjkyj6=A7EcQw@mail.gmail.com>
In-reply-to: Your message of "Fri, 8 Oct 2021 11:28:49 -0500 ." <CAN-Dau0q7p-9NWv=9vouX51Z1Yqe_h06WwpnkMjkyj6=A7EcQw@mail.gmail.com>
Date: Sun, 10 Oct 2021 22:26:52 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/--eTlFZbtFPniCYLz5dQNR3PUsY>
Subject: Re: [v6ops] Implementation Status of PREF64
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Oct 2021 20:27:05 -0000

>In an effort to find a compromise that allows Android to support DHCPv6 and
>therefore the managed-assignment addressing model, I'm suggesting it is
>reasonable for DHCPv6 clients to require the availability of more than one
>IPv6 address before it enables it's IPv6 stack, and it sounds like Lorenzo
>is at least open to discuss such a comprise.

There is one thing I don't quite understand in this discussion. For a
long time it seemed to be the position of Andoid devs that only SLAAC could
support the number of addresses Android needs. DHCP IA_NA was not suitable.

Now we are having a discussion whether networks should for example support 
64 addresses using IA_NA.

Android is not a new operating system with many unexpected features. 
Android 12 was released recently. I don't know for how long I have had
android devices connect to my network using IPv6, but it is quite a 
few years.

In all that time, I never noticed the android device using more than one
or two IPv6 addresses.

Now obviously I'm not pushing my phone enough that I don't see it using
more than, say, 10 addresses. I'm a bit curious, what are those extra
addresses for? Addresses that are so special, you need them immediately
when connecting to the network.

The strange thing is, my laptop has quite a few IPv4 address. Each VM with a 
network in bridge mode gets its own address for the guest. Addresses 
get added when VMs get started. And expire as stopped VMs fail to 
renew leases.

Why is it that android is so special, it cannot dynamically request more
addresses when it needs them?