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

[Mark Smith <[e-mail]>]

On Wed., 31 Oct. 2018, 20:43 Simon Hobson <[e-mail] wrote:

> Manfredi (US), Albert E <[e-mail]> wrote:
>
> > Which says, I have no peripherals configured which require IPv4
>
> how do you know in advance that there are no peripherals that the user
> might want to connect to which are IPv4 only ?
>

Because the network operator has actively asserted that there aren't, by
actively choosing to set this flag.

If any such devices attached to an IPv6 only link, they shouldn't have
been, and it is a network connection policy violation for the link. They'll
fail to work and should fail to work, because they don't talk IPv6.

If IPv4 only devices can be legitimately connected to this link, then
clearly it isn't an IPv6 Only link, and the flag shouldn't be set.

We're getting into trying to prevent insanity territory with these sorts of
corner cases.



> > I have no old IPv4 PCs with which I'm sharing drives
>
> how do you know that the user won't want to connect to an IPv4 only share ?
>
> > I have access to one or more IPv6 default routers
>
> describes pretty well every dual-protocol network)
>
> > so I don't need to use IPv4 for anything.
>
> So your user of a device on a dual-protocol network goes into whatever UI
> they have to find local devices (printers, file shares, etc). They didn't
> previously have any persistent IPv4 connections defined*, the network is
> dual-protocol so you have at least one default router for IPv6 - by your
> heuristics the user will not find any IPv4 only devices. So you have broken
> the network for them.
>
> Using the administratively set flag model, they will not have a problem
> because (unless he's a twit) the admin won't have set this flag for this
> network.
>
> * For whatever reason - it may be that this device is new to the network
> and so has no prior knowledge of the devices on it. Or may be a freshly
> imaged device which is effectively the same thing.
>
>
> > A possible counterargument being, possibly, the flag creates errors,
> that would require troubleshooting.
> >
> > 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.
>
> The lesson learned from this is that the flag is the right way to do it.
> The flag was incorrectly set causing a **hard** fault, it was diagnosed and
> unset, problem solved.
>
> The alternative ? Your recorder makes guesses and indeterminately fails to
> record programs that it thinks (according to some obscure heuristics)
> shouldn't be copied. Harder to diagnose as it's a soft fault, and even
> harder to fix.
>
> Had the station not turned the flag off, then your option to work around
> the misconfiguration would have been the same as if the heuristics model
> been used - you'd need to hack the recorder to disable the feature.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>