Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Ted Lemon <mellon@fugue.com> Fri, 06 December 2019 01:50 UTC

Return-Path: <mellon@fugue.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 96C4B12004C for <v6ops@ietfa.amsl.com>; Thu, 5 Dec 2019 17:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=fugue-com.20150623.gappssmtp.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 Bet_0QyQz9Qc for <v6ops@ietfa.amsl.com>; Thu, 5 Dec 2019 17:50:09 -0800 (PST)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80838120018 for <v6ops@ietf.org>; Thu, 5 Dec 2019 17:50:09 -0800 (PST)
Received: by mail-pf1-x432.google.com with SMTP id n13so2505380pff.1 for <v6ops@ietf.org>; Thu, 05 Dec 2019 17:50:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=82eBUpoOTCiRPWxVkv5OWXGwxCqyVzRxJTmrD7Z+XuA=; b=inhW/VA7HF4xusoTiivpu5jlO1IVea4pIRv3g1JGTfHvvPN3aLpn4hczu/8TA4ds/F dmcuvyR6Ay7Cl6hBXuD9XMMGIj7QqxVOc5kDCEISpAWh5memlX8xvq9ga5488EkmWZfY gs8rHBHhY14tgWByMj164zSaYkiyBFLk9Yi+OpbNqMB72hQY/kXogGnzUqMO0pVJGIBN Zx+x927fKS50a7fJwLEGM6mAG78xsuQ7zV/PuEmLcWjtIV7ikjmAEh8VxvJQPVdvtPlY Pdvv7Whr+5R0a/Xs6nGS62rb2O5oYsydiDgnEse0d5Bgq1uk5ufJOjiiI9XDyI/dQ2E2 BWUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=82eBUpoOTCiRPWxVkv5OWXGwxCqyVzRxJTmrD7Z+XuA=; b=Q1Kd7LQrcLiCr0zVPlcQ6myYg5GwTvnu5VvuFa1ZuEuSwmf10GJxxceU/Tfzw+XTGZ h+p3z6s0WGFdSL45fOnlrK7rkCG0QkvUlqZxjiqlfT4HAAWnGSkoT9o7kWPITzmwxGCS 6CHoHaXllc9a2Z7Tsin8z70nE60x17yEv8r+H3pHwFJ0vYDSLc8KUvEjg1jlm26sXr+c kCG2bE83rimc5aHq70K6enDZ5eGxSodhHuTPKt4h+RL/t+9slroU00Xf/CRTyGwuUZeA Vzgq9rv7OYMhucgdXUWX3fbSaQunGHrEUDWgAcWheHWUeVmjYzYtpkR+QL1zG7/C3Gz6 rpog==
X-Gm-Message-State: APjAAAVpk9x1s4Nxr6+lO5s2p6GL5q41ht8on5P7pJtO9oZqF7iZtSEm L4lrC0nsPATsn/z46EtZHFc9pQ==
X-Google-Smtp-Source: APXvYqxTmjX5NiC2nzJ3E8o8Zvh94Yx+ujwUt/gyaYeYae1LjAIMh4Et7Z6Uza4ukHGJMbsYrHNGvw==
X-Received: by 2002:a63:6b8a:: with SMTP id g132mr757582pgc.127.1575597008898; Thu, 05 Dec 2019 17:50:08 -0800 (PST)
Received: from ?IPv6:2600:380:852e:6ef7:4dd6:1fa6:7c9b:1aca? ([2600:380:852e:6ef7:4dd6:1fa6:7c9b:1aca]) by smtp.gmail.com with ESMTPSA id u65sm13719768pfb.35.2019.12.05.17.50.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2019 17:50:08 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 05 Dec 2019 17:50:06 -0800
Message-Id: <5876B53D-01D1-4689-8FFA-25320EA265DD@fugue.com>
References: <CAO42Z2wd03gf2_LBd+Bb3N=KUer2yYue9TMhZffNtHPy_yG9Zg@mail.gmail.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, v6ops list <v6ops@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
In-Reply-To: <CAO42Z2wd03gf2_LBd+Bb3N=KUer2yYue9TMhZffNtHPy_yG9Zg@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
X-Mailer: iPhone Mail (17E180a)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/AvuDox_UzJIZ9rcXGuXm_Hsexec>
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 01:50:13 -0000

What’s an ipv6-only application?  Normally I would expect an application to be stack-neutral. 

> On Dec 5, 2019, at 16:59, Mark Smith <markzzzsmith@gmail.com> wrote:
> 
> On Thu, 5 Dec 2019 at 13:20, Lorenzo Colitti <lorenzo@google.com> wrote:
>> 
>>> On Thu, Dec 5, 2019 at 9:53 AM Mark Smith <markzzzsmith@gmail.com> wrote:
>>> 
>>> If hosts only acquired IPv4 addresses via DHCPv4 based on when the first IPv4 application started running, then when a host is only running IPv6 only applications, it would never acquire an IPv4 address because it wouldn't need one, meaning never try to use DHCPv4 (so would avoid the link-layer broadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer broadcast ARP Requests).
>> 
>> 
>> Speaking as an OS implementer: how do I know whether an application is an IPv4 application?
>> 
> 
> So these are reasonable questions, and they're uncovering some
> assumptions and a view point I have:
> 
> - the hosts in question are commonly single homed (and I should know
> better *, however I would't be surprised if that is the unstated
> assumption of most people when they imagine the scenario being
> discussed)
> 
> - the on-demand I'm imagining is inspired by the dial-on-demand that
> used to be implemented with ISDN, triggered by IP traffic. ISDN
> connection establishment happened quickly enough that it was tolerable
> by end-users. If a DHCPv4 transaction occurred within 100 ms, users
> will perceive it as instant - "Response Times: The 3 Important Limits"
> - https://www.nngroup.com/articles/response-times-3-important-limits/
> 
> - IPv6 only applications clearly indicate they're IPv6 only, by only
> opening IPv6 sockets.
> 
> This latter point is probably a significant difference between what is
> being proposed here and what I'm thinking. My thinking is probably
> about a passive and longer term mechanism that would result in IPv4
> disappearing over time, rather than an active mechanism that purposely
> switches IPv4 off on dual stack hosts.
> 
> 
> Responding to these points for completeness:
> 
>> When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do that.
> 
> They wouldn't be IPv6 Only applications.
> 
> 
>> When it creates an IPv4 socket? But what if it's creating an IPv4 socket for the purpose of connecting to another network on the system (e.g., cellular data) that does have IPv4?
> 
> Yes, this would be an issue with what I was describing.
> 
> What I'm thinking about would probably more result in "IPv6 Only"
> being a host level status on a host, covering all interfaces (1 or
> many), rather than an interface status. In other words, if a host is
> only currently running IPv6 Only applications, then there is no need
> for any IPv4 addresses on any of its interfaces.
> 
> 
>> When it does a connect() on an IPv4 socket? But what if that's just a happy eyeballs stack that is using IPv4 because it might be available?
> 
> As above, not an IPv6 Only application if trying to use HE.
> 
> 
>> What if the app knows it needs IPv4 and will refuse to do any networking if it doesn't find an IPv4 address on the system?
> 
> Not an IPv6 Only application.
> 
> 
> I see value in both applications being explicit about what Internet
> Protocol they want to use (e.g. on demand addressing per above), and
> also being agnostic about it.
> 
> 
> 
> Regards,
> Mark.
> 
> 
> 
> (* "The Rapid Rise of the Mobile Multi-Homed Host" -
> https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf)
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops