Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Fri, 06 December 2019 10:04 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 D6C8D120096 for <v6ops@ietfa.amsl.com>; Fri, 6 Dec 2019 02:04:11 -0800 (PST)
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 nQTlDJeEMy5m for <v6ops@ietfa.amsl.com>; Fri, 6 Dec 2019 02:04:10 -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 37D5D12008A for <v6ops@ietf.org>; Fri, 6 Dec 2019 02:04:10 -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 m1idAT1-0000L9C; Fri, 6 Dec 2019 11:04:07 +0100
Message-Id: <m1idAT1-0000L9C@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com> <E03BBE6C-3BED-4D49-8F79-0A1B313EFD9D@apple.com> <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <m1icmif-0000JrC@stereo.hq.phicoh.net> <CAFU7BAThtF=Fio_CZFPA+0D7GBZbzpgXMQ5kBiSK5XKi29vkJw@mail.gmail.com>
In-reply-to: Your message of "Fri, 6 Dec 2019 09:26:07 +1100 ." <CAFU7BAThtF=Fio_CZFPA+0D7GBZbzpgXMQ5kBiSK5XKi29vkJw@mail.gmail.com>
Date: Fri, 06 Dec 2019 11:04:07 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IAbpULiA52lajkMI7Rr9TYdO0o0>
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option
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: Fri, 06 Dec 2019 10:04:12 -0000

>I'm an operator who could not wait to implement that draft (and I'm
>aware of at least one other operator who might be interested).
>Maybe I'm not creative enough but all other options of incremental
>deployment of IPv6-only I've come up with are much more ugly
>(doubling the number of SSIDs/VLANs or having a portal when users have to
>request IPv4 so their MACs are whitelisted etc).

Can you describe why offering both NAT64 and native IPv4 on the same lan
doesn't work?

Note that I don't have a strong opinion on what would be enough demand from
operators. It seems to me that running both dual stack and NAT64 on the same
network is bad from an operational point of view. But if people want to do
it anyway, then it is fine with me.

One thing that worries me a bit is that with this option the host signals that
it doesn't need an IPv4 address if there is NAT64.

There are two things that can go wrong: the network provides the NAT64 
transation prefix in a way that the host doesn't understand. 

The second thing, what if some other IPv4aaS technology becomes popular,
do we need a new option for every IPv4aaS technology?