RE: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Tue, 30 October 2018 19:35 UTC

Return-Path: <albert.e.manfredi@boeing.com>
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 0B4BD130DC0 for <ipv6@ietfa.amsl.com>; Tue, 30 Oct 2018 12:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 sgIq2FgP79DE for <ipv6@ietfa.amsl.com>; Tue, 30 Oct 2018 12:35:00 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 282C4130DD9 for <ipv6@ietf.org>; Tue, 30 Oct 2018 12:35:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w9UJYvMu001760; Tue, 30 Oct 2018 15:34:57 -0400
Received: from XCH16-01-08.nos.boeing.com (xch16-01-08.nos.boeing.com [144.115.65.218]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w9UJYlBj001341 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 30 Oct 2018 15:34:47 -0400
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-08.nos.boeing.com (144.115.65.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1466.3; Tue, 30 Oct 2018 12:34:45 -0700
Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.1466.003; Tue, 30 Oct 2018 12:34:45 -0700
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Toerless Eckert <tte@cs.fau.de>
CC: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
Thread-Topic: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
Thread-Index: AQHUcFcpYquacc8opU6a6i/ZWJF0uqU4EEbQgACCtwD//41FEA==
Date: Tue, 30 Oct 2018 19:34:45 +0000
Message-ID: <143d790e624d498c91fbf69b070da007@boeing.com>
References: <0d6008a4-337b-2ccb-2d9f-837f786eca65@gmail.com> <bfa4397a-aa7a-1184-4147-4cbfbfd13603@si6networks.com> <8C587906-F0EE-4A61-9046-2BFAC52588C0@isc.org> <E8DE18B5-94FC-411C-A310-E49A382E0079@thehobsons.co.uk> <e0fa8fad1b4249c9af79788323b0a922@boeing.com> <3A03A073-72E2-43A8-90A4-5C29DF445361@thehobsons.co.uk> <27fdbd71125842d888c5136684bf6e7b@boeing.com> <9A4368D6-E4B1-474C-9838-B584AF6D70C8@thehobsons.co.uk> <m1gHUMI-0000I6C@stereo.hq.phicoh.net> <acb0984ec73b40c9a350a0d144b23835@boeing.com> <20181030183416.wfv47m63w5xk3cqe@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20181030183416.wfv47m63w5xk3cqe@faui48f.informatik.uni-erlangen.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: CCDCCDC43B4806A3B18F838169E5902DE1818641DE22F720D2AE5020F500C8222000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tJg1_f1-v1O8yiSFpDYBJbNWY7U>
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, 30 Oct 2018 19:35:03 -0000

-----Original Message-----
From: Toerless Eckert <tte@cs.fau.de> 

> If as i suggested the flag really means to trust IPv6 routers more than
IPv4 routers (aka: don't do IPv4 even if some IPv4 router tells provides
DHCP addresses), then it would be an explicit mechanism for IPv6 to
superceed IPv4.

Except that contradicts the current draft wording. Which says, only if all default routers have the flag set, does it mean that the net admin doesn't appreciate IPv4 on the link. (And I still think that local IPv4 traffic is, and must, be completely legit, so that too needs to be stated explicitly.) IPv6 has added complexities of allowing multiple default routers to advertise, pick the best prefix for your needs. Which says to me, it is reasonable to think that IPv4 *is* allowed, across one or more of these default router choices, but not on those with the flag set.

> I would support that interpretation on the rough
estimate on my side that it simplifies policies and evolution. Without
that interpretation, you have more complex policies whom to trust
in an automatic way.

Agreed. It is "more complex," because any one flag set does not mean that IPv4 can't be used. For instance, as a simplest case, it is fair enough for my ISP to say, "I am not routing IPv4 over my network." It is not okay for my ISP to say, "You are not allowed to use your old HP printer."

So, IMO, the flag is not necessary. The ISP can simply not provide a default IPv4 router, not provide IPv4 DNS to resolve outside names, and that gives a less ambiguous message. A host should be able to do the right thing, under those circumstances, sans flag.

> The second interpretation is vs. this means to just not even try to
do DHCP to get global IPv4 addressing/router, or whether it means
to not do IPv4 at all, including no link-local multicast. IMHO both
options are valid and would best be indicated through two separate
flags.

Yes, and we can increase complexity that way. Or, hosts decide whether to start with IPv6, rather than creating more complexity in IPv6. And again, it's not the business of the net admin, if I want to have internal IPv4 available to me. Imagine the annoyance that would create, for the average user, who knows nothing about any flag. So, suddenly, after a router update the user is totally clueless about, his peripherals, or other equipment, don't work. Aaaargh!

> I don't think there is any way to achieve complete disablement of
ipv4 operations automatically without using some additional signaling
across non-IPv4. I think it would be cleaner to do this signaling at L2,
but given the overhead/politics of anything like that with IEEE, i think
its fine to have this signaling in IPv6. I don't think there is any
simpler/better way than at least one such flag.

Agreed on L2, but "complete disablement of IPv4" should be out of the question. That breaks things that do not need to be broken. If net admin doesn't route IPv4, fine and good. IMO, stop there.

Bert