IETF Logo Mail Archive

Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Wed, 04 December 2019 15:05 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 66B6212081D; Wed, 4 Dec 2019 07:05:05 -0800 (PST)
X-Quarantine-ID: <DJrWA34awLkd>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
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 DJrWA34awLkd; Wed, 4 Dec 2019 07:05:04 -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 A769812008C; Wed, 4 Dec 2019 07:05:03 -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 m1icWD6-0000JdC; Wed, 4 Dec 2019 16:05:00 +0100
Message-Id: <m1icWD6-0000JdC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
Cc: Jen Linkova <furry13@gmail.com>
Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org
From: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
In-reply-to: Your message of "Wed, 4 Dec 2019 23:09:08 +1100 ." <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com>
Date: Wed, 04 Dec 2019 16:04:54 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/1_TpXKj3hXaq0gXdd-Ch_sHAxzc>
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: Wed, 04 Dec 2019 15:05:06 -0000

>Abstract:
>   This document specifies a DHCP option to indicate that a host
>   supports an IPv6-only mode and willing to forgo obtaining a IPv4
>   address if the network provides IPv6 access.
>
>Any comments/suggestions/reviews are highly appreciated!

I wonder about the deployment scenario.

Basically the draft assumes that an operator is running both a dual stack
network and IPv4-as-a-service in the form of NAT64.

The draft assumes a migration path to NAT64, so we can assume that the 
IPv4 in dual stack is behind NAT as well.

In general, address shortage on a local network behind NAT is not a problem
(RFC 1918 space is big enough).

So the main motivation I can find for running NAT64 next to dual stack is
to collect statistics.

I wonder how many network would offer two ways to do IPv4 just to collect
statistic on how many hosts can both do NAT64 and have been modified to send
the new DHCP option, which does not benefit the host.

v2.23.0 | Report a Bug | By Email