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

[Mark Smith <[e-mail]>]

Hi Sander,

On Tue, 28 May 2019 at 10:47, Sander Steffann <[e-mail]> wrote:
>
> Hi Mark,
>
> Blocking 0x800/0x806 on individual link-layer ports would prevent IPv4
> traffic including link-layer broadcasts on the link, but it doesn't
> stop hosts initialising their IPv4 stack and trying to acquire an IPv4
> address via DHCP. It requires link-layer per-host port configuration,
> which would involve configuring 100s if not 1000s of individual ports.
>
>
> Most switch operating systems and/or automation solutions provide easy ways to do that, but let's look a bit further.
>
> RFC2563 should stop an IPv4 host sending IPv4 packets after the
> initial DHCP transaction. However, it doesn't prevent link-layer
> broadcast DHCPDISCOVERS, which is flooded to all other hosts on the
> link and has to be processed by their main OS CPU to be discarded,
> because the NIC can't filter them using the DA. This is where the main
> battery cost will be when mobile nodes join the link, likely
> continuously on big Wifi networks at e.g. conferences.
>
>
> Do you have numbers on this? I'd like to see whether this is a significant drain on batteries.

I think the impact of link-layer broadcasts on battery life is going
to be pretty similar to that of multicast RAs that are also link-layer
flooded to all-nodes, as they both have to be passed up to the general
purpose OS and CPU for processing.

The impact of multicast RAs on battery life has been enough that we've
published a BCP on using unicast RAs when possible to reduce devices'
energy consumption.

"Reducing Energy Consumption of Router Advertisements"
https://tools.ietf.org/html/bcp202

There are numbers in section 4 discussing the battery consumption
costs of flooded multicast RAs.


It is self-evident that doing nothing is more efficient and effective
than spending resources on doing something that is of no use and has
no value. The latter is the definition of the word "waste".

Link-layer broadcasts caused by IPv4 on an IPv6 Only link are wasting
mobile devices' battery capacity.

It's been advice to reduce or avoid link-layer broadcasts, well before
battery powered mobile devices were common.

"But broadcasts must be used with discretion, since all hosts that
receive one incur a certain amount of software overhead, if only to
discard it."

"Practical Considerations in Ethernet Local Network Design", by Ronald
C. Crane and Edward A. Taft
October 1979, revised February 1980

https://ethernethistory.typepad.com/papers/PracticalConsiderations.pdf



>
> A link with a DHCPv4 server on it supporting RFC2563 is not an IPv6
> Only link, because IPv4 is still present on the link. There should be
> no IPv4 services/infrastructure and no IPv4 packets on an IPv6 Only
> link, including IPv4 zero-conf link-local traffic. An IPv4 only
> zero-conf printer should not work on an IPv6 Only link, intentionally.
>
>
> This is what I consider an overly restrictive view ("purist") of an IPv6-only link. Telling your clients that ask for IPv4 using DHCP that there isn't any isn't an operational problem.
>

It's not being purist, it is being literal. It is complying with the
literal definition of the word "only".

You can't call your link an "IPv6 Only" link if there is any IPv4 is
present on it.

A link with DHCPv4 and RFC2563 is an "IPv6 Mostly" link, not an "IPv6
Only" link.

> The combination of those two mechanisms would go close to achieving what this flag would, except that the first mechanism prevents the
> second from working.
>
>
> So individually or in combination, neither of these are a solution to
> the problem of achieving an IPv6 only link.
>
>
> Ok. SAVI then instead of full ethertype filtering. Widely implemented and it allows DHCP, DHCP filtering and if the clients don't get addresses assigned it will drop their traffic.
>

Doesn't solve the problem of hosts needlessly, wastefully and
persistently trying to acquire IPv4 addresses that they'll never get.

It's making hosts into hamsters in wheels, activity with no progress.

Regards,
Mark.




> Cheers,
> Sander
>
> PS: it's almost 3am here. Don't expect more replies until tomorrow :)
>