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

[Mark Smith <[e-mail]>]

I hesitate to respond, because when people start resorting to
classifications/name calling, changing the problem definition to suit
their alternative solutions, even the meaning of base words in the
English language, the discussion has probably devolved that time would
be better spent elsewhere.

On Tue, 28 May 2019 at 22:53, David Farmer <[e-mail]> wrote:
>
>
>
> 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.
>>

The thing about DHCPDISCOVERS is that they're a fundamental indicator
of whether or not a host has IPv4 enabled or not.

They're important here because if a host has stopped issuing
DHCPDISCOVERS, then unless it has a manually configured IPv4 address,
the host also won't be sending any other IPv4 traffic you mention.
That means no sending of ARP DUD (ACD), mDNS, Netbios or any other
IPv4 triggered link-layer broadcasts or multicasts.

An IPv4 host without an IPv4 address has no need to use and is unable
to use those other protocols. It is an IPv6 Only host now, rather than
a Dual Stack host.



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