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

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Tue, 21 May 2019 17:08 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 3CD3F1200D5 for <ipv6@ietfa.amsl.com>; Tue, 21 May 2019 10:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 XFg2pgLE7fh9 for <ipv6@ietfa.amsl.com>; Tue, 21 May 2019 10:08:36 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (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 BB8E0120086 for <ipv6@ietf.org>; Tue, 21 May 2019 10:08:34 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1hT8Fc-0000H1C; Tue, 21 May 2019 19:08:32 +0200
Message-Id: <m1hT8Fc-0000H1C@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Fernando Gont <fgont@si6networks.com>
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
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> <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>
In-reply-to: Your message of "Tue, 21 May 2019 12:36:51 -0400 ." <ce07ade8-5105-055f-4798-f4ef20a2393c@si6networks.com>
Date: Tue, 21 May 2019 19:08:31 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Pm7vH_uHyeG6lA7OnjNCTwYZdqU>
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: Tue, 21 May 2019 17:08:38 -0000

>If I understand correctly, you were arguing that IPv4 SD should be
>disabled by default for IPv6 only networks.

>For the average user, this means that if they actually needed, now they
>are in trouble.

Not really. It just means that you need to have a DHCPv4 server if you want
to use IPv4. Whether a CPE ships with DHCPv4 enabled by default can change
over time.

Or to put it in other words, IPv4 SD would only work if supported by DHCPv4.

>What saves headaches is to not disable functionality. At the end of the
>day, I wonder the extent to which a few IPv4 packets affect battery on a
>normal network as opposed to multiple 200MB+ apps  that drain the CPU
>for even the most trivial stuff, continuous wake up do to online
>presence apps, etc.

It is more than just a bit of SD. I think some (most? all?) stacks assume
that all of IPv4 is onlink when they have an IPv4 link local. So any A
record returned in DNS may trigger ARP traffic for that address. That
requires all applications to deal with broken IPv4.

>And no, it's not just the printer. a bunch of the smart devices you can
>connect at home (cameras, smart plugs, sensors, etc.) are still IPv4
>only. An "IPv6-only network" will just break all that.

What about running a DHCPv4 server to support those devices? 

>If you *don't want IPv4*, you filter at layer 2. Otherwise you're mostly
>advising your network on the intent.  But nodes are free to communicate
>over ipv4 if they wish.

That is true. But most of networking is based on cooperation not on 
enforcement. Describing intent is important.

>auto-linklocal is, in a sense, -- and by definition --  a kind of
>anarchy. Such "anarchy" has proven valuable, both when the network
>fails, or there are issues with the infrastructure (or there is no
>infrastructure).

In the case of working IPv6 the network is in some sense managed. From a
host (and user) perspective is more clear if the network is actually treated
as managed, and not as half managed (IPv6), half chaos (IPv4).