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

David Farmer <farmer@umn.edu> Wed, 22 November 2017 03:52 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 D7B15129490 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 19:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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, URIBL_BLOCKED=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 xCyTX7UZySQ6 for <ipv6@ietfa.amsl.com>; Tue, 21 Nov 2017 19:52:21 -0800 (PST)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 EB5AF126557 for <ipv6@ietf.org>; Tue, 21 Nov 2017 19:52:20 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 6330E92D for <ipv6@ietf.org>; Wed, 22 Nov 2017 03:52:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05Rv9acM7SMT for <ipv6@ietf.org>; Tue, 21 Nov 2017 21:52:20 -0600 (CST)
Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id CD37B840 for <ipv6@ietf.org>; Tue, 21 Nov 2017 21:52:19 -0600 (CST)
Received: by mail-lf0-f71.google.com with SMTP id q21so3465431lfb.12 for <ipv6@ietf.org>; Tue, 21 Nov 2017 19:52:19 -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=MDIBqP5k52IiT7RKklNz7jcFTVXNOJo7jiaXe14hFgE=; b=fRZJ4+EtFgohyvCGNxQgGne8sAcahIGgGy8sAQEJuDH3iFGfZnDU+jF+RECiyAjY5K PMxNi+ur+BOA86DNbw2lxUVgPrXNqmVEx+WNN0b+5tS1nXw2OR+ELiMlAdZ/+zTH0Bzu e4SUDmod5aVBVAxf4QqbD2K1SJmWQ18luK0xryYygt+No8QWBjwMJo5drpFbT5GEQQfO zGzXIHpyjRaBjyD+u0JFmgG7CE5nnnsrv1HM7EBT1y1ZRP3Th76LA752vgYsYg6QXseH gun19xA+61qt9UEEDfxwPplrY+eUSsbrmrOxhcXV49rzSUJl2ypmvt9lkqJl6NQj5Tx/ VvNw==
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=MDIBqP5k52IiT7RKklNz7jcFTVXNOJo7jiaXe14hFgE=; b=BeYgNKI8MfhjHFLQpXN3P7IeSYfm+Cs6tlJISbr0Hvbr/FrjuwUe81QyigKZLd0UGI lgUSH73BfVGLmTFbrm14U3TsG/inX3qg/e1dQfRC5+HA8WbTsHT3NecEIBxu42kswFZP XpiaE9YcL5eQ0IS+Osmr7/TW7XErC7yhp7vVUTyn1KS6CQUE1kRSne15nKgs1fK4A6DN c2zIJ72L+3onp44iQjSwqH5A3E7TMz6zNwzaNqxjW9cg29PLLkMLvYye9+TO1tjQo0vz 2FmfWQf2JDoWqfjOXd9oTSX1MBD9bm+5RbbhUZdau84GYK0mSVtOtcIJQ+97Q4JgyIk0 PF7Q==
X-Gm-Message-State: AJaThX669codwNuMc1T2ZmKDVgcu01SCP9OSn8e84/EdiLTxXeF9nkXP mG3K008dYfdT0DO0d1S7k5Uokuc6qYCv4pXRNH+WKYt53BtFrpOPxHghTjHQEJDTLu2+VYD0j1f wyKfEqTkxz4a9m3oy86sMgc6Y
X-Received: by 10.46.7.82 with SMTP id i18mr5986726ljd.123.1511322738261; Tue, 21 Nov 2017 19:52:18 -0800 (PST)
X-Google-Smtp-Source: AGs4zMY5GxbvoO931NYkXOgJX05fEsQn2x2a9ze2VHnIHgHP2CgGX8CINWTagNDnM6D3SB8OLwc5w+C9GubKYFG77To=
X-Received: by 10.46.7.82 with SMTP id i18mr5986721ljd.123.1511322738035; Tue, 21 Nov 2017 19:52:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Tue, 21 Nov 2017 19:52:17 -0800 (PST)
In-Reply-To: <0a91f2b8-d8d2-438b-e5a2-57eed62e053c@gmail.com>
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> <5A12FBE4.9030101@foobar.org> <alpine.DEB.2.20.1711210647151.32099@uplift.swm.pp.se> <5A144A78.6060108@foobar.org> <CAKD1Yr3oQvkSX7ARxfGQVg08=-PTKRFPg1wz_zUKSSAHmMbyMA@mail.gmail.com> <5A14A9A1.5020803@foobar.org> <ea9f56bb-2334-5a5a-9026-d45c74b41d4b@gmail.com> <CAN-Dau0TfDedocjOTkaoiHxDQNemCbTY9Q1in1wqHGoMdYdnHQ@mail.gmail.com> <0a91f2b8-d8d2-438b-e5a2-57eed62e053c@gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Tue, 21 Nov 2017 21:52:17 -0600
Message-ID: <CAN-Dau1Wtpkbt2tutRNCGO=SMp4cx3sedrROEsq1m3brK7oxNw@mail.gmail.com>
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Nick Hilliard <nick@foobar.org>, Lorenzo Colitti <lorenzo@google.com>, IETF IPv6 Mailing List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f736cf12114055e8a3eec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Twrgp1rYV6qBUnU0mtK4yN6W2FM>
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: Wed, 22 Nov 2017 03:52:23 -0000

On Tue, Nov 21, 2017 at 8:32 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com>; wrote:

> On 22/11/2017 13:42, David Farmer wrote:
> > On Tue, Nov 21, 2017 at 6:15 PM, Brian E Carpenter <
> > brian.e.carpenter@gmail.com>; wrote:
> >
> >> On 22/11/2017 11:33, Nick Hilliard wrote:
> >>> Lorenzo Colitti wrote:
> >>>> On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard <nick@foobar.org>;
> >> wrote:
> >>>>> There would also be a requirement
> >>>>> for the network edge to be able to filter out RAs with this option,
> >>>>
> >>>> Why is it not sufficient to configure the routers that emit the RAs?
> >>>
> >>> because you're assuming congruity between ipv4 and ipv6 connectivity on
> >>> a network, which is not codified in any ietf document that I'm aware
> of.
> >>>  If there is a incongruity between management of the two protocols,
> then
> >>> the l2 network must have a mechanism to stop an ipv6 gateway from
> >>> attempting shutting down ipv4 services.
> >>
> >> This is a very interesting point. If every IPv6 router on a link
> believes
> >> there is no IPv4 router/DHCP service, they would all send flag==1 in the
> >> proposed solution. So the proposal only works if at least one IPv6
> router
> >> is colocated with an IPv4 router, and therefore knows to send flag==0.
> >> Oops.
> >>
> >
> > This is a problem only if the flag is set automatically and their is no
> > mechanism to override the automatic setting.  Most routers with an IPv6
> > address configured on an interface by default will send an RA unless you
> > configure them not to.  So, an IPv6 router without IPv4 configured on the
> > interface should set this flag, unless configured otherwise.  In other
> > words you need to be able to tell an IPv6 router there is IPv4 on the
> > interface even if router is not providing it.
> >
> > It is quite possible that the IPv6 topology is incongruous from the IPv4
> > topology, however it is doubtful than the management is also incongruous.
>
> Yes, but do you think we should push a mechanism that assumes correct
> configuration by humans in order to work reliably?
> (Arguing against my own proposal, not for the first time ;-).
>

If you have the funds to build two separate infrastructures, which is what
we are talking about here, one for IPv4 and separate one for IPv6, you
should have the funds to pay for humans smart enough to manage the two
separate infrastructures.  An IPv6 topology incongruous from the IPv4
topology is not going to be a common deployment model, at least for anyone
who will be relying on auto-configuration.

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================