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

[David Farmer <[e-mail]>]

On Thu, May 9, 2019 at 1:10 AM Mark Smith <[e-mail]> wrote:

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

As I see it, at least for the foreseeable future, we want dual-stack hosts
to perform equally well on dual-stack networks as on IPv6-Only networks, so
in my opinion, this means we don't want to completely eliminate
DHCPDISCOVERS, at least at the beginning of the attachment process. Maybe
someday in the future, IPv4 will be rare enough we can delay even
initial DHCPDISCOVERS, but at this point, I don't think that is a wise move.

As I see the intent after initial DHCPDISCOVERS we want a positive signal
to a dual-stack host that further DHCPDISCOVERS are futile and that is can
stop. But upon attachment to a network, at least for now, a dual-stack host
should assume it is more likely to be attaching to a dual-stack network as
a IPv6-only one. Therefore, it should sent both an IPv6 R




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


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