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

[Mark Smith <[e-mail]>]

On Thu, 9 May 2019 at 07:56, David Farmer <[e-mail]> wrote:
>
>

<snip>

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


The primary goal is to reduce and ideally entirely eliminate
link-layer broadcasts on the link caused by IPv4.

DHCPDISCOVERS are link-layer broadcasts. Using any form of DHCPv4 to
disable IPv4 is directly counter to the primary goal.

Link-layer broadcasts cannot be filtered by the interface card based
on the frame's destination address (unlike unicast and multicast), so
they must be passed to the host's general purpose CPU for processing,
typically triggered by an interrupt to the CPU, which causes operating
system context switches etc. to process it. If the frame isn't
intended for the host, there is a relatively high processing cost to
ignoring it.

It is much more efficient to be able to filter and drop frames in the
NIC itself based on destination address . (Even if a NIC is "smart"
and can do internal processing e.g. via Linux XDP, it's still more
battery consumption on a mobile device than just dropping the frame
purely based on destination address).

100s or 1000s of devices on a link results in all of those 100s or
1000s of devices having to receive, process with their general CPU,
and then ignore, each and every one of the link-layer broadcast
DHCPDISCOVERS that each of those devices all emit.

RFC3927 may reduce the volume of DHCPDISCOVERS and IPv4 caused
link-layer broadcasts, but it doesn't eliminate them. Any time a new
device joins the link, a link-layer broadcast will still occur and be
flooded, and have to be processed (by the general purpose CPU) and
ignored by all of the other devices already on the link. On a link
where devices come and go regularly, such as conference or similar
public Wifi, and may leave the link when saving power or being
suspended, that could still be a significant amount of link-layer
broadcast traffic caused by DHCPDISCOVERS upon attachment.


(People may not realise why IPv6 only uses link-layer multicasts,
rather than link-layer broadcasts. It isn't a coincidence, since Steve
Deering both developed multicast and co-designed IPv6:

RFC1112, "Host Extensions for IP Multicasting"

7.4. Extensions to an Ethernet Local Network Module

   To support the reception of multicast IP datagrams, an Ethernet
   module must be able to receive packets addressed to the Ethernet
   multicast addresses that correspond to the host's IP host group
   addresses.  It is highly desirable to take advantage of any address
   filtering capabilities that the Ethernet hardware interface may have,
   so that the host receives only those packets that are destined to it.)


Regards,
Mark.




> 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
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------