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

Toerless Eckert <tte@cs.fau.de> Tue, 30 October 2018 21:00 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 30D62124408 for <ipv6@ietfa.amsl.com>; Tue, 30 Oct 2018 14:00:28 -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 fS_03IKX3iGM for <ipv6@ietfa.amsl.com>; Tue, 30 Oct 2018 14:00:26 -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 B8AFF1276D0 for <ipv6@ietf.org>; Tue, 30 Oct 2018 14:00:25 -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 5D23B548017; Tue, 30 Oct 2018 22:00:20 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4BD74440210; Tue, 30 Oct 2018 22:00:20 +0100 (CET)
Date: Tue, 30 Oct 2018 22:00:20 +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: <20181030210020.66dppz77jeowp722@faui48f.informatik.uni-erlangen.de>
References: <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> <143d790e624d498c91fbf69b070da007@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <143d790e624d498c91fbf69b070da007@boeing.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Roj3HUmTQYxPUyVoNL6-nRuXnDY>
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 21:00:28 -0000

On Tue, Oct 30, 2018 at 07:34:45PM +0000, Manfredi (US), Albert E wrote:
> -----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.

What i wrote is meant to be in support of what you cited from the draft.
Maybe i wasn't writing that clearly enough, but not sure where you see
the difference.

> (And I still think that local IPv4 traffic is, and must, be completely legit, so that too needs to be stated explicitly.)

As i stated in before, i am too in favor of having an explicit notion of
"IPv4-link-local-only(no-global) as a separate flag, but i think that
this may need more regurgitation to fully conclude that that
functionality can not equally well be achieved with heuristics.

It is a lot more easy to conclude that you need some non-IP signaling
to indicate that the IPv4 stack should be disabled completely (IMHO
simple logic tells us that). 

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

True. Which is why the draft is correct in stating that only if all
IPv6 routers announce the flag wold it be considered to be active.
> 
> > 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."

Definitely. As i wrote in my prior email, the most lightweight
interpretation is that we want a signal to tell hosts not to bother
switching on IPv4 and ideally routers figure this out automatically.

Why would the network operator make that decision explicitly ?

In one case because we can't figure out good enough heuristics so that
the routers can announce the flag automatically. Thats a fair reason,
but i would have to be persuaded that this is really necessary.

In another case, the operator wants to announce the flag even though
there could be IPv4 devices on the network to talk to and he wants
to prohibit that. Thats a lot less interesting to me because it
brings up all type of followup questions. At best this is a
desriable mutually agreed upon router announced policy that consenting
upgraded routers could or should comply to. is that really worth it ?
And it can't be enforced without additional enforcement. 

> 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 host would still continue to try to do IPv4 forever in DNS
and simultaneously enable link-local scope IPv4 addressing, and
both these activities are just useless trash activites making
diagnostics more difficult and likley also being issues for
wireless. So i think it would be great if the IPv6 router would
be able to help out dual-stack hosts, telling them when they can
skip these attempts into IPv4.

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

But lets get back to the most core point: Heuristics on every
host would eiher need to be explicitly standardized or we'll
end up with very difficult to troubleshoot environments where
every host stsack does the same thing. AND i can never completely
disable the IPv4 stack if i want my host to do heuristics.

So its a lot easier model if the router(s) figure out if IPv4 is
needed and signal that to the hosts. And given how the hosts
we care about have IPv6 but may not have any other L2 protocols,
it is logical to put it into IPv6. No strong feeling in this respect
into which field of which protocol to put it. I assume the authors
choose a pretty good location (except eating up on of the last bits
in the encoding).

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

Right. automatic setting of the flag(s) by routers. Routers can IMHO
easily figure out if there are IPv4 link-local only nodes on the LAN.

As said in before, even without automatically setting flags, i think
the diagnostic itself we could get from routers tracking what type of
hosts are present: IPv4-link-local, IPv4-global, IPv6/IPv6, IPv6
would IMHO be very helpfull.

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

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 ?

Cheers
    Toerless
> 
> Bert