Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]

Nick Hilliard <nick@foobar.org> Mon, 20 November 2017 15:59 UTC

Return-Path: <nick@foobar.org>
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 A7803129B22 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 07:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 v80-pjxbXYg1 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 07:59:37 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB126129B21 for <ipv6@ietf.org>; Mon, 20 Nov 2017 07:59:36 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vAKExLaD097282 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Nov 2017 14:59:21 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <5A12FBE4.9030101@foobar.org>
Date: Mon, 20 Nov 2017 15:59:32 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Mikael Abrahamsson <swmike@swm.pp.se>
CC: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <CAFU7BAQKoWPcEFQZgU3k_d0gUL4en6d2pyNq1V4RMNZ6HrSG8w@mail.gmail.com> <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com> <CAKD1Yr3WC+vwL_=0PeiJ_D85NqFVTCkb8c83x-ZtGhAbSELGMA@mail.gmail.com> <5A119443.2030108@foobar.org> <CAFU7BASwgLfkO-4kk9-vba_P+jmcFHD5+Hy_7b3cnNkOSv30wg@mail.gmail.com> <CAKD1Yr3pKk22Hkxy4_8YMZYiA4Wwp=6JzdRDKFGdTY1gf=ntfA@mail.gmail.com> <alpine.DEB.2.20.1711200848390.32099@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.20.1711200848390.32099@uplift.swm.pp.se>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0u9fRqtKdELSHKGK5hzgNcpv7MI>
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: Mon, 20 Nov 2017 15:59:40 -0000

Mikael Abrahamsson wrote:
> This functionality doesn't exist today in any access network I know of.
> It's also non-trivial to do considering how access networks are done.

Both of these statements also apply to encoding a no-ipv4 flag in an RA
message.

> Preferrably one would like to ahve an ethertype filter on the access
> port to only allow 0x86dd and nothing else. Then putting this flag into
> IPv4 means this isn't possible.

if you can filter everything except 0x86dd (or the equivalent for
different media, e.g. docsis, pppoe, etc), then the ipv4 problem
statement which draft-hinden-ipv4flag is intended to solve has already
been handled.

> IPv6 is the next generation IP protocol. I prefer that it can signal
> that the legacy version is not available, instead of having to keep
> legacy IP functionality around.
> 
> ... or we put it in some other L2 protocol, such as LLDP.

It comes down where in your stack you want to put your hacks.  A sentry
dhcpv4 agent is simple to define in terms of protocol scope, behaviour
and meaning, and has relatively well constrained requirements in terms
of the amount of ipv4 infrastructure required to sustain it (virtually
none, in the minimal case).

If you want to define and implement this functionality via some other
protocol, it requires potentially substantial complication on the client
side, as well as creating a requirement to define what is meant by "no
ipv4".  This, IIRC, was one of the issues that led to the sunset4 draft
not progressing further.

Nick