IETF Logo Mail Archive

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

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 20 November 2017 07:51 UTC

Return-Path: <swmike@swm.pp.se>
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 E4BC912947E for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 23:51:25 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 ynnCimO_jXUs for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 23:51:24 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 DE62912946C for <ipv6@ietf.org>; Sun, 19 Nov 2017 23:51:23 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 988FFB0; Mon, 20 Nov 2017 08:51:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511164281; bh=AWS+rhmlboj5gdICHBBAjxbIeT+WUemxAFEAbU4vNUw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=IUb8hWSrctSzBLBIX4CrrV3LpEfR2K5FY9wuXqKis8MPRmSrAE74aiAYjaV0J9c4j s1Dh4BCf/zedI10xGFILIeE1XV7qXH8+1RviI9J7Zv8L7pueKxKzLSB5Z7F2bkyqzX BNjPSAe+ws2KfSZTVQPrfKJMA6Mlmmaz6G7/egg4=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 811D39F; Mon, 20 Nov 2017 08:51:21 +0100 (CET)
Date: Mon, 20 Nov 2017 08:51:21 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Lorenzo Colitti <lorenzo@google.com>
cc: Jen Linkova <furry13@gmail.com>, IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
In-Reply-To: <CAKD1Yr3pKk22Hkxy4_8YMZYiA4Wwp=6JzdRDKFGdTY1gf=ntfA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1711200848390.32099@uplift.swm.pp.se>
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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gLTLUe2DYzjhQSslmRRkl4zL7Jg>
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 07:51:26 -0000

On Mon, 20 Nov 2017, Lorenzo Colitti wrote:

> Sure. But you wouldn't need complicated infrastructure for this - if all 
> that's necessary is to respond to a DHCPv4 request with a canned "no 
> DHCPv4 here" packet that is always the same, that's a lot easier to 
> deploy than a full DHCPv4 infrastructure.

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. 
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.

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.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email