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

David Farmer <farmer@umn.edu> Sat, 11 May 2019 22:17 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 692CD120092 for <ipv6@ietfa.amsl.com>; Sat, 11 May 2019 15:17:40 -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 7wTkityfRrfS for <ipv6@ietfa.amsl.com>; Sat, 11 May 2019 15:17:38 -0700 (PDT)
Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 C4762120075 for <ipv6@ietf.org>; Sat, 11 May 2019 15:17:38 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id BC6ABA00 for <ipv6@ietf.org>; Sat, 11 May 2019 22:17:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-0jZ6yM6CDX for <ipv6@ietf.org>; Sat, 11 May 2019 17:17:37 -0500 (CDT)
Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 7DDEE9A5 for <ipv6@ietf.org>; Sat, 11 May 2019 17:17:37 -0500 (CDT)
Received: by mail-ua1-f69.google.com with SMTP id v25so1174605uaa.13 for <ipv6@ietf.org>; Sat, 11 May 2019 15:17:37 -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=4G2gWd+pVXi+3fQyhfsE3Qklx+b3xcnwwzEoDzP9WZc=; b=eqV9RS/YgQliaLXeQxbBL8lQH01BIjb28eupSdbvC90kwLgxGGgndvzQ6wQhqgPnGr bqCPB94TeLPhCn46/6SAe8n8nDBcGXDJdSMRHWMXkD7n2V3cizZXxZMDsh78uBTVrS1H dHI3YVqU71SvhPhAylQeg0tedOFueAWhxYR4uzg+oq2X5bRNk3vVuhE7nVWKHVo7zq6T nTUaeOwCwOtPuSjgqIY9rouqJHMfAQGyYhuvF+j7pcI9d+AtK0dA+nD9ZHNg2SreOFQ8 Hkh4xzWUCND9pE4ChzuS8iEhtA3ynVj0qtJoMK1/vb5+wK7tOaTDEC6AHN1qikRmNGfR v3fw==
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=4G2gWd+pVXi+3fQyhfsE3Qklx+b3xcnwwzEoDzP9WZc=; b=Ts14EzKShDH9Jkef77nnCtCVZCnnGptqVbIfGbQoURl1QCorMyBtN+1ZlefnPLOwCZ X5makaz5MyWUXpy0qlFHBQE+9vnm6W07v75cS8ltSETOqBeZRJtJB+ZwC5YQ+dfkKP/j Lv2I342PXeBEkb+zZpgFHtKkruWBhqN4K8KTslAbiKjjHm7X0OtChAzVY0+SS707F16E UHp3OvHWuEwWOW2dJVTaQB1arFhOcGGDDVeePJ/DqNn5WkKz4AxOfQDP14xHcS2tg/UN g9Jrz3NUe1+z2WwBpDNZ6FpezwncCtI4hGwBc6YapgiIUnWghVX4f0iQmEA9V5/VzoVH LCNQ==
X-Gm-Message-State: APjAAAVWQI4EZawKOFIuWdKDTTXwJfMvjqQqDli53ItcPvWFbfEkUg3k EnjKxYzrhA+ZDEtdWMHQ7mBZ2E+0sRAKTZcJic8dVm722YwF0jCgQIs6XRLAhP9H7RQ7G8lm2Tn UoDLm475vkhigUUTgfBhreEZd
X-Received: by 2002:ab0:338e:: with SMTP id y14mr9250209uap.39.1557613056618; Sat, 11 May 2019 15:17:36 -0700 (PDT)
X-Google-Smtp-Source: APXvYqzUZOeRU0DErayQtLqr/gz9za+8uugMVr84nqf5CadthY/VUEEqsqbpfblCfks8eLvGNAmSVIyQl+8P9UcK0r8=
X-Received: by 2002:ab0:338e:: with SMTP id y14mr9250200uap.39.1557613056216; Sat, 11 May 2019 15:17:36 -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>
In-Reply-To: <663F6C0B-7B8A-4088-B9C0-B2867B0C3EB8@gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Sat, 11 May 2019 17:17:19 -0500
Message-ID: <CAN-Dau3VJN7qNHAW-yStMrDRCa4vsDs2ObkAxswnYbcHde2t_w@mail.gmail.com>
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e9dffb0588a40cf2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dvvRxSNSBCsZL9v5pJ8o_Ca_n0E>
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: Sat, 11 May 2019 22:17:41 -0000

On Sat, May 11, 2019 at 3:39 PM Fred Baker <fredbaker.ietf@gmail.com> wrote:

> And for the record, Job, Nick, and Sander are not the only ones that are
> not members of the putative consensus. I have stated (would have to look it
> up to give you the link to the email and the date) that IMHO the benefits
> are minor and there is a security loophole. My issues remain unaddressed.
> So I'm part of the anti-consensus. And I'm pretty sure I'm not alone.
>

Fred,

Please correct me if I'm wrong, but I believe your objection is that it
would be more efficient to simply perform exponential backoff on the IPv4
DHCPDISCOVERS. Do I have that right? If not please help me better
understand your objection.

In my opinion, you are correct if that were the only or even the primary
source of futile IPv4 traffic. In effect, RFC 3927 configures a Link-Local
IPv4 scoped address if a DHCPOFFER is not received, and then this
Link-Local address is used to perform futile IPv4 service discovery. From
my perspective, this is the primary problem, not futile IPv4 DHCPDISCOVERS.
As you say exponential backoff of the DHCPDISCOVERS would easily control
that issue. However, something also needs to signal the dual-stack host to
not perform IPv4 service discovery because the dual-stack host is on an
IPv6-Only network, I believe this flag serves this purpose well.

Further, as of late I've been trying to listen very closely to the
objections. In listening to the objections, I came up with the concept that
the lack of IPv4 DHCPOFFERS should be considered the primary signal and
this flag is a secondary signal mainly intended to disable IPv4 service
discovery.

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