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

Toerless Eckert <tte@cs.fau.de> Tue, 30 October 2018 22:35 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 3E559124BE5 for <ipv6@ietfa.amsl.com>; Tue, 30 Oct 2018 15:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.952
X-Spam-Level:
X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 ZkVo61GM3WkX for <ipv6@ietfa.amsl.com>; Tue, 30 Oct 2018 15:35:04 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40D8128D09 for <ipv6@ietf.org>; Tue, 30 Oct 2018 15:35:03 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EA4D1548017; Tue, 30 Oct 2018 23:34:59 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DAD57440210; Tue, 30 Oct 2018 23:34:59 +0100 (CET)
Date: Tue, 30 Oct 2018 23:34:59 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
Message-ID: <20181030223459.kiwio62t7i5jc2s7@faui48f.informatik.uni-erlangen.de>
References: <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> <143d790e624d498c91fbf69b070da007@boeing.com> <20181030210020.66dppz77jeowp722@faui48f.informatik.uni-erlangen.de> <87651dfca4694f599e67abbc593f1787@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87651dfca4694f599e67abbc593f1787@boeing.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2L0laOD2XJzHQSGKoZubOhwoeO8>
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 22:35:06 -0000

On Tue, Oct 30, 2018 at 09:45:55PM +0000, Manfredi (US), Albert E wrote:
> > If you don't have IPv4 only hosts on the subnet and no routers routing
> IPv4, then IMHO IPv4 is unnecessary and should be completely disabled.
> >
> > What would be the argument agains this conclusion ?
> 
> No argument, Toerless. And, just as you have to have an updated host to read the IPv6-only flag, to make the decision to shut off IPv4 entirely, that same updated host could simply be running the better heuristic. Which says, I have no peripherals configured which require IPv4, I have no old IPv4 PCs with which I'm sharing drives, I have access to one or more IPv6 default routers, so I don't need to use IPv4 for anything.
> 
> Your point about assisting in troubleshooting might have merit. A possible counterargument being, possibly, the flag creates errors, that would require troubleshooting.

I don't think i can figure out that there is no IPv4 on the network
needed without even trying. So much better done by the router and then
summarizing (in one bit ;-) to the hosts so they don't ave to try.
Also much easier to diagnose and troubleshoot.

> True story. Years ago, when I was still watching and/or recording TV programs the old-fashioned way, my Philips recording device would sometimes fail to record the program I had set up. I tried updating its software, I was super careful to set it up recording sessions correctly, and yet, sporadically, no recording when I went to watch. Irritation!
> 
> So I had to do some research. Come to find out, even though the US Supreme Court had decided that time-shift recording is perfectly legal, a "do not copy" flag was still configured, in these recording devices. So, I called the engineer from the one station giving me this problem, and the nice guy on the other end had no idea they were transmitting this blasted flag. But, the problem did go away after that.
> 
> Lesson learned (for me, anyway): best to avoid flags that aren't really essential.

In the architecutre i see, the router is helpipng the hosts with the
flags. If the user of a host sees evidence that the help is incorrect,
there can always be manual overrides.

In the case of the copy-bit, the SP box is fully policing the STB,
and STB MUST NOT have overrides or else its not certified for use.

Pretty big difference in semantic IMHO.

Cheers
    Toerless

> 
> Bert