IETF Logo Mail Archive

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

Bob Hinden <bob.hinden@gmail.com> Fri, 24 May 2019 14:40 UTC

Return-Path: <bob.hinden@gmail.com>
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 4966A120337 for <ipv6@ietfa.amsl.com>; Fri, 24 May 2019 07:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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=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 3M29bcEcLRko for <ipv6@ietfa.amsl.com>; Fri, 24 May 2019 07:40:11 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 194A8120096 for <ipv6@ietf.org>; Fri, 24 May 2019 07:40:11 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id w13so1923344wru.11 for <ipv6@ietf.org>; Fri, 24 May 2019 07:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9+jKZ8KHFK4DPf4ZeUg1Ql15QK0c2eO+K9kaO8aRa6A=; b=PuJpq+u6+/uX4n7NgNiFonmL96T4X8UnttZ1JUU6GSYZJomnWqaFicpOGb0kdeGFl/ 1ZEcHxxuJ0tan6kIWyStDiforRJgVnT2l3RiqDDmhiMmsV6Yn9UfvkLwlvB15ZpgW87s cHnyYpULdz5kRSQGHQkcMLlIpgdbQ6hqueVZeX0VkfnDEs6UjvcLJKf5fOTkEMOIOlfW qOZrhvFhO055u5+aMRamSfzbvBn7Q2pifv+T9zfRdEpp+IzFluSK80HWQ9nN26tXlptf jHhumK1bbltGFSbiS7gnnKViqBifdtxW5H7EpYWOUyunhUpJnqD2uvra5wPUSjKocRUR 5B4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9+jKZ8KHFK4DPf4ZeUg1Ql15QK0c2eO+K9kaO8aRa6A=; b=ib0pWhFUIb6RLzC2rrveukgdaMrDoCkyq8dzcQ7xTc1s9zlr9jat0nhfp52Wx4qp8O Cye3Hnba6+5EKQhO06l4l7awYFOcpw7EhP7yX1YdNU9CdtGvll4G1ZVo0HsIGWLIqQkq 2bY4ZiC4shHgHSpNq1b71f8H+jXxKKQjThER74V/s8FZ1szAD+2LvdPbbOV1xQSrAIOR hB3aVe4PqgBl2DHorSWnQAUR61V7Ey+p2XXBM/j/laY0IY4DO44JJ0VyPBo0BQSqnDs1 5KlIUbxSi3Y6M4DaOcfKVfGK3DJLDskEi2TDbjW8bUoIHsCXJs2avHGEnIrlaz9/YSub OuGA==
X-Gm-Message-State: APjAAAVIp63dUzYrGehxxJBwebo6pVMiR+9mKQ77B2LsBvyowmArt/gD 7mdvgJ0MvVud+AXvQslPrcc=
X-Google-Smtp-Source: APXvYqyhY8U8vtfPdxO3rGWnH7I5thiJtDn9nMpBbnIijgr6vBg+DL6DRk6o+cQF0HwTYtvDlrW+jw==
X-Received: by 2002:a05:6000:1201:: with SMTP id e1mr62263171wrx.136.1558708809530; Fri, 24 May 2019 07:40:09 -0700 (PDT)
Received: from [172.20.5.136] ([50.234.163.151]) by smtp.gmail.com with ESMTPSA id g16sm2871192wrm.96.2019.05.24.07.40.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 07:40:08 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <m1hUAkR-0000GSC@stereo.hq.phicoh.net>
Date: Fri, 24 May 2019 10:40:04 -0400
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <24C5314C-B2D9-4469-AEB1-58B573909359@gmail.com>
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.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> <CAN-Dau040j6U+1CCn0QJiVMy2nVShHqqSFdCkM-FbMAH-2wjRA@mail.gmail.com> <m1hQCYr-0000KBC@stereo.hq.phicoh.net> <561d9dc3-c769-c774-8f65-f975ac2a10a0@gont.com.ar> <m1hT1DZ-0000HEC@stereo.hq.phicoh.net> <ce07ade8-5105-055f-4798-f4ef20a2393c@si6networks.com> <CAN-Dau02MYCrKx2BgyuYJeHBdoz6SHCnp+-byM+LMM8af0S+rA@mail.gmail.com> <40e99171-6dda-2 9e3-6152-da5ca5219ed9@foobar.org> <CAN-Dau0ALqfAA-Dz56oHAfOtY7E2obx5E7TgoeH357Mckp3t9g@mail.gmail.com> <m1hUAkR-0000GSC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ULw23j31aZPJds8V5le-ioTCueg>
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: Fri, 24 May 2019 14:40:15 -0000

Philip,

> On May 24, 2019, at 10:00 AM, Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> wrote:
> 
>>> Obviously, from an operational point of view, if DHCP service is
>>> important on a network, the operator is at liberty to install redundant
>>> servers / relays.
>> 
>> WHAT ARE ARE YOU SAYING?  The IETF SHOULD NOT concern itself with
>> accidental misconfiguration? And SHOULD only create fragile and brittle
>> protocols? The IETF SHOULD NOT seek robustness in its protocols?
>> 
>> If that is the case I think you just said half the work in V6OPS and GROW
>> is out of the scope of the IETF. And you just said your objection to the
>> IPv6-Only flag is out of scope. I believe just the opposite, and I believe
>> your objections to the original formulation of the IPv6-Only flag were well
>> placed.
> 
> The IPv6-only flag is an additional feature. Before accepting such a 
> feature it is worth asking what happens if the feature gets enabled
> accidentally or maliciously.
> 
> In my opinion that is different from creating workarounds for poorly
> maintained services. The normal expectation of a DHCPv4 server failing
> is that there will not be any IPv4. Creating workarounds for that creates
> operational complexity. 
> 
> At the recently concluded RIPE meeting, Geoff Huston suggested that the
> reason some networks have very high IPv6 failure rates is because the
> failures are masked by happy eyeballs. Networks that rely on IPv6
> (i.e. those with NAT64) have very low failure rates.
> (https://ripe78.ripe.net/programme/meeting-plan/ipv6-wg/)

I wonder if the ipv6only flag could be used to test IPv6 on networks.  That is, turn off IPv4 and see if the IPv6 is working.  Turn off IPv4, then make sure there is working IPv6 connectivity, throughput, etc., then turn IPv4 back on.  

Perhaps a new use case.

Bob


> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email