Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

[David Farmer <[e-mail]>]

On Wed, May 8, 2019 at 2:54 PM Fernando Gont <[e-mail]> wrote:

> The question is probably why not use IPv4 to disable IPv4. Entangling
> one protocol with another generally leads to increased complexity, and
> interesting attack vectors.
>
> I wonder why, if the issue is really a layer 2- one (e.g., stations
> being awaken unnecessarily), the problem is not solved at layer 2- --
> e.g. filtering at layer to, based on the Ether Proto.
>
> Thoughts?
>

First, I don't think this flag is tangling the streams so to speak, IPv4
and IPv6 are tangled by the dual-stack model. I think of the flag as trying
to untangle IPv6 from IPv4 so we can run IPv6-Only on dual-stack hosts.

The primary signal for a dual-stack host to not configure an IPv4 address
should be the failure to receive an IPv4 address from a DHCPv4 Server
[RFC2131]. This flag should be a secondary signal for a dual-stack host to
not auto-configured an IPv4 Link-Local addresses [RFC3927] assuming an
address has not received via DHCPv4, to not perform any IPv4 service
discovery (such as mDNS [RFC6762]) using IPv4 Link-Local Addresses, and
further, to limit the number of attempts that are made to configure an IPv4
address via DHCPv4.

Otherwise, without this secondary signal, when a dual-stack host does not
receive an IPv4 address from a DHCPv4 Server it would
normally auto-configured an IPv4 Link-Local addresses, perform IPv4 service
discovery (such as mDNS [RFC6762]) using IPv4 Link-Local addresses, and
some dual-stack hosts are quite persistent in their attempt to configure an
IPv4 address. It is these sides effects of not receiving an IPv4 address
from a DHCPv4 Server that the flag needs to mitigate and that are necessary
to untangle IPv6 from IPv4 to run IPv6-Only on dual-stack hosts.

This secondary signal needs to be expressed with an IPv6 mechanism so that
it is compatible with Layer 2 filtering of IPv4 Ethertypes, however, use of
the flag doesn't require this filtering. If this signal is expressed in
IPv4 then it is impossible for the signal to be received in the presence of
Layer 2 filtering of IPv4 Ethertypes.

The following is the rewrite I propose for the logic in the Host Behavior
Considerations Section based on the above restatement of the purpose of the
flag.

---

A host that receives any RAs with the flag set to 1 SHOULD NOT
auto-configured an IPv4 Link-Local Addresses [RFC3927] when it fails to
receive an IPv4 address via DHCPv4 [RFC2131] and therefore SHOULD
NOT perform IPv4 service discovery (such as mDNS [RFC6762]) using IPv4
Link-Local addresses.

A host that receives only RAs with the flag set to 1 SHOULD make a limit
number of attempts to configure an IPv4 address via DHCPv4 and then make no
further attempts. OPTIONAL, such a host could make no attempt to configure
an IPv4 address at all.

As soon as a host receives any RAs with the flag set to 0 it SHOULD attempt
to configure an IPv4 address via DHCPv4 if it does not already have an IPv4
address configured, and MAY continue to periodically attempt to configure
an IPv4 address via DHCPv4 if it does not receive an IPv4 address from a
DHCPv4 Server as long as it is receiving any RAs with the flag set to 0.

A host that successfully configures an IPv4 address received via DHCPv4
SHOULD continue using it and attempt to renew it when necessary regardless
the status of the flag in the RAs it is receiving. Further, it MAY perform
IPv4 service discovery (such as mDNS [RFC6762]) using the configured IPv4
address.

Thanks.

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================