Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

David Farmer <farmer@umn.edu> Mon, 13 May 2019 14:28 UTC

Return-Path: <farmer@umn.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25AC1200B1 for <ipv6@ietfa.amsl.com>; Mon, 13 May 2019 07:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 VE0_00tsynL2 for <ipv6@ietfa.amsl.com>; Mon, 13 May 2019 07:28:24 -0700 (PDT)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 DDCB1120020 for <ipv6@ietf.org>; Mon, 13 May 2019 07:28:23 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 15E4B596 for <ipv6@ietf.org>; Mon, 13 May 2019 14:28:23 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dFs7X8foPHz for <ipv6@ietf.org>; Mon, 13 May 2019 09:28:22 -0500 (CDT)
Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id B633912B for <ipv6@ietf.org>; Mon, 13 May 2019 09:28:22 -0500 (CDT)
Received: by mail-vk1-f200.google.com with SMTP id l85so6570081vke.15 for <ipv6@ietf.org>; Mon, 13 May 2019 07:28:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JEc5EyfJXflKz3Pynkom6AnW47ov7ec6+4B1PsLPy+c=; b=RDqu6fIGPow7BUV1NCYppLeAs41NUIyVeYAZiH7vjOFNvwq3SFBMmoWbz2Sx6YLHNO BKQTKQon5d2wYtrj8KNSu8vQM2OWL6UZlzxffFgBW70JGJvnVrV8AKc6+Us3bmEw8qZB 7HpXEuoU2NGJpx4G5gDRrwTl2SIV1rssKUgsutU+yWWRaedbo+gaUnqFI8G70uI9E4p+ CXjwOJEGIVI4kzexnk+eG4tMpIktKdE3EtQJqwLsKn0Yt4GUk1C98dB0jbEboBLWe5Ld h7g/prMyuqFtudm9XTLHjHVqnwdq5rwe7T43WHQeCK7mYpMNf1MGcNII5povs0pawW98 wsqg==
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; bh=JEc5EyfJXflKz3Pynkom6AnW47ov7ec6+4B1PsLPy+c=; b=K2ld/lJowMhzakb4PLJHCCmnBVUWpWhZ+rYEWcot7qKAp+WpTBBLIth0CvOTNrG/JB El/yA1/J31JANpv4PRvxa0ww3E587qBhLixs+nmGBUu9gssuU0/ib7BvFNVPq5B3lK5G Qf8n/IuUb/J5cVYsYAe8g7dzMbQw54Ns+Cljynq1tEEVRJwwZb3XPdLnuAQaVy0+hQoO HAolPm/8TfzoKLd/R7be49/aKjvAbuy6FsDIaITkpxd7vlzEOBWrM7cPZOtkQssiSs7i rMQcWXn5C59sxGAWLhfEfgErnwDv6m7gSqI6Nj15M3XBW6eNogF3Zh1GB5Jyjdpu77UZ GREA==
X-Gm-Message-State: APjAAAU+seVfuS4nmliet27JOtBMY3/imsBLsAsRQk6jzzLTlLYRkj5j I5F4Yahp84GtDrEQ6z1QnTXdOim/40GF5JmYe+Gv/NTvhTpMwY1VxUqeHkgOK1YXA39i4ACpHFQ jEJckzGZAc2xcVobaK1YxB490
X-Received: by 2002:a67:ab4a:: with SMTP id k10mr14149655vsh.176.1557757701767; Mon, 13 May 2019 07:28:21 -0700 (PDT)
X-Google-Smtp-Source: APXvYqzHO8/xGD3hIYfjPL73WhPAZu7I57cGdIsyEHBPaT0n4icd+zAandkVoOArkMvptvsoiBmrd+bb+3KKND0UdO4=
X-Received: by 2002:a67:ab4a:: with SMTP id k10mr14149633vsh.176.1557757701286; Mon, 13 May 2019 07:28:21 -0700 (PDT)
MIME-Version: 1.0
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <a2465e81-a17f-ab48-efda-20fe12a70077@foobar.org> <30239E0C-C444-4A7E-8342-AEE47BF8A2BB@employees.org> <20190505200449.GB7546@vurt.meerval.net> <80073906-c3c0-1f22-9e7f-c2b349063936@gmail.com> <CAO42Z2xzVW3m0mN7jEn8SYyYCYhrufVnkfp3rBjJcijBkvucNQ@mail.gmail.com> <CACWOCC-35yVYXSRR0sRL-MBMHyOFZtJx9E9h14G8qqVh5T7qGA@mail.gmail.com> <232c1a43-0fd9-4eae-737b-260a3906f72a@gmail.com> <663F6C0B-7B8A-4088-B9C0-B2867B0C3EB8@gmail.com> <CAN-Dau3VJN7qNHAW-yStMrDRCa4vsDs2ObkAxswnYbcHde2t_w@mail.gmail.com> <m1hPqHO-0000J8C@stereo.hq.phicoh.net> <CAN-Dau3R=4JbcbK7tWkJKYzVjq7DvAAEjVsbCLbZdYYO8OJ0YA@mail.gmail.com> <m1hQ7Dm-0000M3C@stereo.hq.phicoh.net>
In-Reply-To: <m1hQ7Dm-0000M3C@stereo.hq.phicoh.net>
From: David Farmer <farmer@umn.edu>
Date: Mon, 13 May 2019 09:28:05 -0500
Message-ID: <CAN-Dau040j6U+1CCn0QJiVMy2nVShHqqSFdCkM-FbMAH-2wjRA@mail.gmail.com>
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006e860d0588c5ba9c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/qcicpuqC1Cyf30P9yhpm9D3n-gs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2019 14:28:26 -0000

On Mon, May 13, 2019 at 4:26 AM Philip Homburg <
pch-ipv6-ietf-6@u-1.phicoh.com> wrote:

> >The problem is, without a flag to clearly designate a network as
> IPv6-Only,
> >then with your proposal if the DHCPv4 server on a dual-stack network ever
> >decides to not grant an IPv4 address to a client, due to a
> misconfiguration
> >or it simply crashes, then that client will inappropriately disable
> >RFC3927.  Whereas with a flag declaring a network as IPv6-Only, RFC3927 is
> >only inappropriately disabled when two misconfigurations or a
> >misconfiguration and a problem occurs.
>
> This strikes me as a bad trade-off. You propose that every network that
> doesn't want IPv4 link local has to set a flag just to help the rare case
> of a DHCPv4 server failing and users able to get useful work done using
> IPv4 link local.
>
> So instead of letting IPv4 die. We would add a flag to IPv6 to help in the
> case IPv4 has a problem. Does that make any sense?
>

I don't propose this, I simply contend that it is what RFC3927 and
dual-stack model intends. Per Section 2 of RFC 4213, the dual-stack model
expects dual-stack hosts to be fully compatible with IPv4-Only hosts.
Further, there are good reasons to require this for compatibility between
dual-stack hosts and IPv4-Only hosts. If dual-stack hosts were to do as you
say and not configure a Link-Local IPv4 address if they have a working IPv6
address they would not be able to communicate with IPv4 Link-Local or
global scope unicast IPv4 addresses on the local link unless they receive a
global scope unicast IPv4 address via DHCPv4. Your proposed change breaks
the dual-stack model.

By the way, do you mean any working IPv6 address? Because all IPv6 host
will have an IPv6 Link-Local address. So, do you mean a global scope
unicast IPv6 address?

Without some kind of explicit signal that a network is intended to be
IPv6-Only, per Section 2 of RFC4213 a dual-stack host needs to be fully
compatible with IPv4-Only hosts that could be on the dual-stack network.

Thanks.
-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================