Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Mark Smith <markzzzsmith@gmail.com> Fri, 06 December 2019 01:58 UTC

Return-Path: <markzzzsmith@gmail.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 8B93C120072 for <v6ops@ietfa.amsl.com>; Thu, 5 Dec 2019 17:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 o_8-IB8x8-s6 for <v6ops@ietfa.amsl.com>; Thu, 5 Dec 2019 17:58:15 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 B3BF8120018 for <v6ops@ietf.org>; Thu, 5 Dec 2019 17:58:15 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id p8so4466844oth.10 for <v6ops@ietf.org>; Thu, 05 Dec 2019 17:58:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tW0HJss4AIRf0dVmMMfu/bIHTRUVWOQ+PYRZtxunC88=; b=TEC2H8denBW7BYD55FBVdZPiZQT2ImPl8E7hxRwZZr4jwarjMrZaLpvk5TDBuVUYqQ B9NfKfZmMHhfMEAdCArcJf+2QYeEagmILXJAIZ1rfJXhxTwX3mFRWllwd6jzIITdtGI6 QTFlmmhm4x+oggaPWJXAePtVI1+aTT15qnwUv/eMhWWqE3irvm9mUzd8/koRRZm72KTY MUyfuH5HPM9SKo4VCiWyzI6pFQAm7r9h2sMZwgCcGSpSWpwypapxPQlOh7jkRKgyvUBf trYhNGvN1hoqo9raavH34vj9iFUbPX1p2ttP73GMGOqmUylZW+LqcHpAr+ycF9nCxm1G JuKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tW0HJss4AIRf0dVmMMfu/bIHTRUVWOQ+PYRZtxunC88=; b=ASLEFF7PDYePS/5g0YZIownR3VNb/P5nzCAcdtcawab2nQYwhDqvM1Zqz5aaUXzvSA 8moVOdTvVTJd2/YQbzntB/EgBAmlmUQ+hHeVf9/Cll3Oj+QweaOhH3sNAUTnlUheBmTw Ff7HM8USxYBykiKK6nuEhLRGD3Vr+SB9bRupkO+FyD5z1V5i0ZSBeU53Vt6huIjNw8k6 pnUO13chRaI6oapgBvJmep4Qhz9h4XphTmktN2aXVeMLlXqf3gYCeInJ3rT3eT6oNg7Y 1nEaIrJjrQ0/nSz4S5r/eXZnHKj1gtAzjL/Ly4YshZpSYCmwGD0NPlkGM3hFbVx6CtN7 qytg==
X-Gm-Message-State: APjAAAVF80wr96Z6XAUHbBCE9V42syyKwaSphg5kTO54R3srZovSfdf8 d1+OTcT3GkagpLVTkonPSTJbLKJoQGk5X+SfIUw=
X-Google-Smtp-Source: APXvYqyLnsw/ZKbGcFeFP3i3y6ynjvo29jwP91teLGgP9jlnh5QTWGf8dyJnpRKlk85s+KN/bKfwG44tbKdZedhXK54=
X-Received: by 2002:a9d:6005:: with SMTP id h5mr9832319otj.153.1575597495053; Thu, 05 Dec 2019 17:58:15 -0800 (PST)
MIME-Version: 1.0
References: <CAO42Z2wd03gf2_LBd+Bb3N=KUer2yYue9TMhZffNtHPy_yG9Zg@mail.gmail.com> <5876B53D-01D1-4689-8FFA-25320EA265DD@fugue.com>
In-Reply-To: <5876B53D-01D1-4689-8FFA-25320EA265DD@fugue.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 06 Dec 2019 12:57:48 +1100
Message-ID: <CAO42Z2xDi5dNiVJ_DMEWBfX5fk-1FTVMq6B1njQVVzOEGcc+9g@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, v6ops list <v6ops@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/1Etg0wNPXX3eRcNBGgJ14_iINUA>
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:58:17 -0000

On Fri, 6 Dec 2019 at 12:50, Ted Lemon <mellon@fugue.com> wrote:
>
> What’s an ipv6-only application?  Normally I would expect an application to be stack-neutral.
>

>From RFC 3493:

For example, to create an IPv6/TCP socket, applications make the
   call:

      s = socket(AF_INET6, SOCK_STREAM, 0);

   To create an IPv6/UDP socket, applications make the call:

      s = socket(AF_INET6, SOCK_DGRAM, 0);


For example, this application only listens on IPv4 or IPv6, but never both:

https://github.com/markzzzsmith/replicast


Regards,
Mark.


> > 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