Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Tommy Pauly <tpauly@apple.com> Wed, 04 December 2019 15:52 UTC

Return-Path: <tpauly@apple.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 A036412002E; Wed, 4 Dec 2019 07:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 Hl7cT2jtuZxQ; Wed, 4 Dec 2019 07:52:03 -0800 (PST)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 9940D120025; Wed, 4 Dec 2019 07:52:03 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id xB4Fpt3n036949; Wed, 4 Dec 2019 07:52:02 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=g2EURWenXaRWg2/+jnbG7d8VVzyTVStpaWqJ1EQa3Mk=; b=IPnkPLS4mzmCUkLMYmBOI5n/i4fLQ1qPjA9uOHmyKJD64oYz9fky7K8/dG37CiC14Fgr fl6NShcMnTTIuqpEOqoacsJBOgVksnY7BXwnuQddr950qU4AIq7A1Ezyb7FQ/lRnB+ok AWOsndxXqeswEqYiuJAbH3BewZoG1yc97AxTd1EcJmdi3C9rNiYnfRp6QEAw/xYJ4Sjm R2y76pR9CO9UmCA/KgP+yFd0hL8bvzP+Ds1s+3Wmhj/DPERAT3Cb3mg+Wr9pt2CtxqvH KvbqMGlATqsVmUuC8/J/SBP9PDFu1eGpTZkhQEZGYFsygcwqHBLQEpT5iU70a0dZTxMp iA==
Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2wkqy9hwwd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 04 Dec 2019 07:52:02 -0800
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q1Z00MFIW2PSZ30@mr2-mtap-s01.rno.apple.com>; Wed, 04 Dec 2019 07:52:01 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1Z00L00VY83W00@nwk-mmpp-sz11.apple.com>; Wed, 04 Dec 2019 07:52:01 -0800 (PST)
X-Va-A:
X-Va-T-CD: edc22c7821eb8520bdad23543016aae0
X-Va-E-CD: d3299f328e4d3e92a5daeb3eb183023b
X-Va-R-CD: aefc5808c3e3aec3e91cdc4e147c91e7
X-Va-CD: 0
X-Va-ID: 8de9e9fc-c7c6-4672-ae2d-e4ba2a788ecc
X-V-A:
X-V-T-CD: edc22c7821eb8520bdad23543016aae0
X-V-E-CD: d3299f328e4d3e92a5daeb3eb183023b
X-V-R-CD: aefc5808c3e3aec3e91cdc4e147c91e7
X-V-CD: 0
X-V-ID: cbdc32e8-84a8-436e-bc2b-7176a1c82b44
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-12-04_03:,, signatures=0
Received: from [17.234.58.39] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q1Z00K97W2LMX40@nwk-mmpp-sz11.apple.com>; Wed, 04 Dec 2019 07:52:01 -0800 (PST)
Sender: tpauly@apple.com
Content-type: text/plain; charset="us-ascii"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com>
Date: Wed, 04 Dec 2019 07:51:46 -0800
Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List <v6ops@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <E03BBE6C-3BED-4D49-8F79-0A1B313EFD9D@apple.com>
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com>
To: Jen Linkova <furry13@gmail.com>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-04_03:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/KrLm_aAsKYAQJtEmU4zSLcyeIug>
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:52:06 -0000

Hi Jen,

Thanks for posting this draft! I find it to be both a well-written document, and a great solution.

This will be particularly critical for networks that want to adopt IPv6-only (read, NAT64), but can't easily ensure that *all* devices on the network upgrade to support that. This concept of IPv6-mostly networks is a good stepping stone! =) What we've seen in cellular networks for NAT64 rollout has had hiccups, and an option like this to smooth the transition would have been useful there. But without an option like this, I don't see a good way for less-managed networks (enterprise Wi-Fis, public Wi-Fis) to make the transition since they can't guarantee what devices are on their networks.

As a client OS vendor, I think this would be easy for the client hosts to implement, and we'd likely see a scenario in which pretty quickly, most modern mobile devices and laptops would support this, and we'd end up with using v4 on networks only for more "legacy" devices.

I'd certainly support this document going forward and being adopted.

Best,
Tommy

> On Dec 4, 2019, at 4:09 AM, Jen Linkova <furry13@gmail.com> wrote:
> 
> Hello,
> 
> One of the biggest issue in deploying IPv6-only LANs is how to do it
> incrementally, when some hosts work just fine in NAT64 environment
> while some legacy devices still need IPv4. Doubling the number of
> network segments (having an IPv6-only and dual-stack segments of each
> type) is an operational nightmare. So it would be just awesome if all
> devices can co-exist in the same network segment and hosts capable of
> operating in IPv6-only environment do not consume IPv4 addresses.
> So here is the draft proposing a new DHCPv4 option to help saving IPv4
> addresses and deploying IPv4-as-a-service:
> 
> Name:           draft-link-dhc-v6only
> Revision:       00
> Title:          IPv6-Only-Preferred Option for DHCP
> Document date:  2019-12-04
> Group:          Individual Submission
> Pages:          9
> URL:
> https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-link-dhc-v6only/
> Htmlized:       https://tools.ietf.org/html/draft-link-dhc-v6only-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only
> 
> 
> 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!
> 
> Adding v6ops@ to Cc: as the problem is related to operating IPv6-only networks.
> 
> Thank you!
> -- 
> SY, Jen Linkova aka Furry
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops