Re: IPv4 traffic on "ietf-v6ONLY"

David Farmer <farmer@umn.edu> Thu, 16 November 2017 13:42 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 4FC8D1294CF for <ipv6@ietfa.amsl.com>; Thu, 16 Nov 2017 05:42:30 -0800 (PST)
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 TwF9tN6K4zc0 for <ipv6@ietfa.amsl.com>; Thu, 16 Nov 2017 05:42:28 -0800 (PST)
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 7E9F1124B18 for <ipv6@ietf.org>; Thu, 16 Nov 2017 05:42:28 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 01930C04 for <ipv6@ietf.org>; Thu, 16 Nov 2017 13:42:28 +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 hN1IezL1v54O for <ipv6@ietf.org>; Thu, 16 Nov 2017 07:42:27 -0600 (CST)
Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) (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 6D329C0F for <ipv6@ietf.org>; Thu, 16 Nov 2017 07:42:27 -0600 (CST)
Received: by mail-lf0-f72.google.com with SMTP id o41so1329032lfi.18 for <ipv6@ietf.org>; Thu, 16 Nov 2017 05:42:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9C23F8LiPNT8LjPUTkbagSJcUdwtZoYAFGgatNOK9GM=; b=HgSW1hpwEzBfHol7dt14CiISiSdzzheKiIWDD+8bNB2K5XDs5BG5EGViRTDriFcHTb KP/rJfHoWR7SDA1EHw28j8LHQ/fMA81ymf7M+fE0cb9E/7w55B2PQvjgUaU3oVaSOOIQ xNARaOq7l7PHe7pPhcYNidJQWwAjmX3QTksobWk58jX12UU2PrUGv9ocjSb759ljTvBR Pk6PPa/BtW5Av3bMuxeehcZhZXNZtDGlJ89zeFVHoCVYjr8dj4+I1J2LdpBK8VOCE2kA NmYxUIBPHQJuXPh59VXS1IejiOh+ZCczCi67oRdMKZVxcSGAkXo628AUBgr2gQrKGzFj wdmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9C23F8LiPNT8LjPUTkbagSJcUdwtZoYAFGgatNOK9GM=; b=LLco8nZO6QBrUsPtKm4X+QzzxH4EilcJsK6eBa+LRR86b482H8ybykgDvhGDnhGp5M s4yZ7Arz2fIhtwZkc1aCm4KxN2ptnhJttvfjmLQC20rfrqcs6pdhBppnC332I8Ga3ERI CkP7VjFRx29DvXkFLWJlX9q0vp36Wd3waMVh7lD3Rx7idfEoGWQBVH5fGC4wWlcwsIo3 870MdQzS/8Kw3u80sGdYml1DD35vFA8xLc1GAOFSKVHXSV+wfacW40FR2iPQ7zXmRtbE Wn4ePpbF162xoosG7j2JoIow9ajJ/wDdwkFkZWBzn5yWYczP+z19TRxm2i9Lu1LeMBmT Qemw==
X-Gm-Message-State: AJaThX5ITJZQ9UzqyrNG7lPCK6YpywaWii9W535k2fJUX3TJCaw5rUP+ y0uxK0hkuR3v94aa89krFi84EInqixyE5SDO4QuUjP/TgN536q/Tl6o1SwTuiclPjidvE9lvN+S yiV579vmo9Ep6Ia0xNsOc50YW
X-Received: by 10.25.158.210 with SMTP id h201mr665421lfe.177.1510839745662; Thu, 16 Nov 2017 05:42:25 -0800 (PST)
X-Google-Smtp-Source: AGs4zMbkf+bCOvNZ2rnQDkBjktrn6h/ZTgZ8ljpezulj4tDhdZKgK/PfzxfjSBtA19FMc/kdBAK8/CgpBfBQWbH+2Cs=
X-Received: by 10.25.158.210 with SMTP id h201mr665416lfe.177.1510839745284; Thu, 16 Nov 2017 05:42:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Thu, 16 Nov 2017 05:42:24 -0800 (PST)
In-Reply-To: <m1eEvku-0000F7C@stereo.hq.phicoh.net>
References: <f9805855-68cf-a3e8-a13f-c6ac31b09058@gmail.com> <bbd4e1d2-047f-6758-76f8-fd591c51dad7@gmail.com> <D631CE54.8C0F5%lee@asgard.org> <m1eEvEP-0000G3C@stereo.hq.phicoh.net> <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com> <m1eEvku-0000F7C@stereo.hq.phicoh.net>
From: David Farmer <farmer@umn.edu>
Date: Thu, 16 Nov 2017 07:42:24 -0600
Message-ID: <CAN-Dau0OSqxYWhV4F0MuJFWWfQBA+ntHaPhTbKTtZxYkLmhbGw@mail.gmail.com>
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="001a114030cc54acb5055e19ca2a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RkZSybVt_zqbc9h4BylPRMRl_As>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 16 Nov 2017 13:42:30 -0000

On Wed, Nov 15, 2017 at 5:21 AM, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.
com> wrote:

> >     Perhaps, define a DHCPv6 option to convey v6-only, for which
> >     the client interpretation should be to suppress v4.  Although
> >    this will be at the cross road with allowing client's wishes to
> >    use v4 LL for whatever useless/useful traffic, it would be a
> >    reasonable deployment policy to enforce.
>
> The problem with a DHCPv6 option is that an IPv4-only network may not be
> prepared to defend against rogue DHCPv6 servers.
>
> So anyone who starts such a server can kick everybody else of the IPv4
> network.
>
> Great option for an overcrowded hotel or conference network.
>

Sorry, but that ship has sailed. If you are purposefully IPv4-only, you
have to deal with rogue IPv6 RAs at least, and probably rogue DHCPv6
servers too, or you need to filter ethertype 0x86DD altogether. Otherwise,
a rogue signal to turn off IPv4 is the least of your worries.  Malicious or
even accidental deployment of IPv6 is a bigger security worry on these
networks than a rogue signal to turn off IPv4.

I'm not saying that a rogue signal to turn off IPv4 isn't a problem. Just
if your willing to ignore rogue IPv6 deployment, then worrying about a
rogue signal to turn off IPv4 seems kind of selective.

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 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================