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

Sander Steffann <sander@steffann.nl> Tue, 28 May 2019 00:47 UTC

Return-Path: <sander@steffann.nl>
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 B61A912010D for <ipv6@ietfa.amsl.com>; Mon, 27 May 2019 17:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
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 z1TyGoj1XTqR for <ipv6@ietfa.amsl.com>; Mon, 27 May 2019 17:47:16 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 DF27A120089 for <ipv6@ietf.org>; Mon, 27 May 2019 17:47:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7C2A261; Tue, 28 May 2019 02:47:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1559004431; bh=gPKRrBpFG09AfRoklThclNUQYTz0giH038KvmIxxBWU=; b=o LTzpXr+xxGkO3nDZ6j2nJxdFHN/iSBxeknSwrQdGc8kM5C2sk7WlJ3OBODCrf+yO IuwRKX+/YNuRQ83Xl4WP/qQbUlD8oMktxNRgUuIDmcyYRojf03vK7g2GQ9PkunwA jBQECqNEydizWu68ONA5G1RzlMiktDsepjsOnknatY=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MMGx61fHeh_I; Tue, 28 May 2019 02:47:11 +0200 (CEST)
Received: from [100.125.112.167] (unknown [188.206.109.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 1F6B25A; Tue, 28 May 2019 02:47:11 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail-EE3353EC-5D1A-4C2E-B065-2FFA5C489177"
Mime-Version: 1.0 (1.0)
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
X-Mailer: iPhone Mail (16F156)
In-Reply-To: <CAO42Z2yUDi3FHOZsLrHqwLsEWkB1X9FREa8m6dU6ecOr=SsX4g@mail.gmail.com>
Date: Tue, 28 May 2019 02:47:09 +0200
Cc: David Farmer <farmer@umn.edu>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <E51102E7-D4F0-4469-8888-5072F624EE06@steffann.nl>
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <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-29e3-6152-da5ca5219ed9@foobar.org> <CAN-Dau0ALqfAA-Dz56oHAfOtY7E2obx5E7TgoeH357Mckp3t9g@mail.gmail.com> <093ba8e2-6f0a-4c91-9df1-cda33fffea97@foobar.org> <CAN-Dau3kVqb+ZEHB7iPGeRuq1Mu8UHR3FEZv8SgmiqZexaFhuA@mail.gmail.com> <12db9629-f92a-e12a-5ff1-7db2c5d2137e@foobar.org> <CAN-Dau0 EGN+bLZCTA-A4ksd40KprhKn-HkL4gotG=v-=kD0zrg@mail.gmail.com> <F6F0C9DC-545E-4FE5-BB4C-55BB29022E84@steffann.nl> <CAO42Z2yUDi3FHOZsLrHqwLsEWkB1X9FREa8m6dU6ecOr=SsX4g@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IAGQsHGquWRU5D9l_L2u8jD8c2k>
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, 28 May 2019 00:47:18 -0000

Hi Mark,

> Blocking 0x800/0x806 on individual link-layer ports would prevent IPv4
> traffic including link-layer broadcasts on the link, but it doesn't
> stop hosts initialising their IPv4 stack and trying to acquire an IPv4
> address via DHCP. It requires link-layer per-host port configuration,
> which would involve configuring 100s if not 1000s of individual ports.

Most switch operating systems and/or automation solutions provide easy ways to do that, but let's look a bit further.

> RFC2563 should stop an IPv4 host sending IPv4 packets after the
> initial DHCP transaction. However, it doesn't prevent link-layer
> broadcast DHCPDISCOVERS, which is flooded to all other hosts on the
> link and has to be processed by their main OS CPU to be discarded,
> because the NIC can't filter them using the DA. This is where the main
> battery cost will be when mobile nodes join the link, likely
> continuously on big Wifi networks at e.g. conferences.

Do you have numbers on this? I'd like to see whether this is a significant drain on batteries.

> A link with a DHCPv4 server on it supporting RFC2563 is not an IPv6
> Only link, because IPv4 is still present on the link. There should be
> no IPv4 services/infrastructure and no IPv4 packets on an IPv6 Only
> link, including IPv4 zero-conf link-local traffic. An IPv4 only
> zero-conf printer should not work on an IPv6 Only link, intentionally.

This is what I consider an overly restrictive view ("purist") of an IPv6-only link. Telling your clients that ask for IPv4 using DHCP that there isn't any isn't an operational problem.

> The combination of those two mechanisms would go close to achieving what this flag would, except that the first mechanism prevents the
> second from working.
> 
> So individually or in combination, neither of these are a solution to
> the problem of achieving an IPv6 only link.

Ok. SAVI then instead of full ethertype filtering. Widely implemented and it allows DHCP, DHCP filtering and if the clients don't get addresses assigned it will drop their traffic.

Cheers,
Sander

PS: it's almost 3am here. Don't expect more replies until tomorrow :)