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

[David Farmer <[e-mail]>]

On Mon, May 27, 2019 at 7:47 PM 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.
>

Personally, I'm not particularly worried about DHCPDISCOVERS at least in
most cases, there are a few badly behaved clients, but in general
exponential backoff in the client should deal with this nicely. Personally,
my issue is IPv4 LL, in particular, service advertisement/discovery traffic
using IPv4 LL. This service advertisement/discovery traffic can be sizable
and is already problematic for many WiFi networks so the elimination of
such traffic that is by definition futile is an unqualified win in such
situations.

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

Let's stop calling each other names, it's not helpful. Yes, the idea of
wanting to block all IPv4 traffic is restrictive, but equally, the idea
that IPv6 should not impact IPv4 in any way is also restrictive. We simply
disagree which is more desirable, different people and networks can have
different priorities.

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

Using RFC2563 with SAVI and ARP filtering (Ether type 0x0806) is an
interesting option, or maybe filtering IPv4 LL traffic.  However, both of
these require much more thought than simply filtering Ethertypes 0x0800 and
0x0806.  Filtering by Ethertype is simple and elegant, further, it is a
basic feature supported by many more network devices than the
more sophisticated Layer 3 aware filtering otherwise required to not also
block the DHCPv4 exchange required for RFC2563 to work.

I want a belt and suspenders approach; I want to signal dual-stack clients
that IPv4 isn't available, or at least that they SHOULD NOT autoconfigure
an IPv4 LL address, RFC2563 does this nicely, the belt. However, for any
dual-stack clients that ignore the signal provided, I also want to filter
the unwanted and futile IPv4 traffic on the network to ensure that it
doesn't bother other dual-stack clients on the network, the suspenders.

So, RFC2563 with fairly sophisticated Layer 3 aware filtering is an option
that achieves the desired results, at least my desired results. However,
the IPv6-Only flag has the added advantage of allowing the use of simple
and more widely available Ethertype filtering.

Also, the testing that I did shows that most newer clients no longer
support RFC2563. I'd be happy to be wrong on this and I'm not 100% sure my
test was valid, but even if I'm wrong this shows that making RFC2563 work
as desired isn't trivial.

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