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

[Toerless Eckert <[e-mail]>]

On Tue, Oct 30, 2018 at 02:47:00PM +0100, Philip Homburg wrote:
> > So, here's the challenge which you seem to be holding back from,
> > write down the actual rules. No hand waving that "that's a good
> > clue", but actual rules that "if you see <some observable state>
> > then <do some specific action>".
> 
> My take on it:
> 
> 1) If a host has a global IPv6 address and is unable to reach a DHCPv4
>    server, then after a short while agressively reduce the rate of DHCP
>    multicast messages

IMHO:

If the host sees the ipv6only flag from all IPv6 routers, it MUST NOT
perform IPv4 DHCP.

Why:

The flag is a clear indication that these IPv6 routers indicate that
there must not be any global IPv4 on this subnet. Even if the DHCP
operations would result in finding a router tht disagrees, then this
is clearly a misconfiguration of the subnet and the host has to make
a choice whose guidance to follow, and this document mandates
that it must be the IPv6 routers flags.

> 2) If a host has a global IPv6 address and it configures an IPv4 link local
>    address then the host should consider only 169.254.0.0/16 to be 
>    onlink.

The "then" portion of this sentence is just restating rfc3927.

The question is whether the ipv6only flag is meant to indicate that
there should be no global IPv4 operations on the subnet or no global
nor link-local ipv6. The current draft seems to intend the latter
to be able to fully shut down the stack. It could be useful to have
another flag indicating whether ipv4 link-local is still
to be used on the subnet.

> Note: this second requirement makes sure that any global IPv4 address that
> the host knows or learns will not result in any traffic, because the host
> does not have a default router.

nothing new vs. rfc3927.

> 3) If a host has a global IPv6 address and a link local IPv4 address then
>    the host should agressively reduce the rate of any service discovery
>    multicasts on IPv4.

I am not aware of any IP protocol version specific optimization options
for mDNS. If there are common ways to make mDNS less chatty without
slowing down discovery, they should be defined independently of the
v6only flag discussion. 

Confounding the situation like you propoose is like "make ipv4 service
discovery less chatty to a point that it may break because it doesn't
matter if ipv6 is running" - and thats not a correct approach given how
the service in question may be ipv4 only.

There may be optimization options to prefer IPv6 over IPv4 discovery
for dual-stack cases, maybe there is something already defined, but 
that could only be IMHO through timing - e.g.: look for service
first via IPv6 and only try IPv4 adfter some short timeout. But that
too would better be defined independently of the ipv6only flag
discussion because its IMHO useful independent of the flag.

Cheers
    Toerless

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------