Subject: Fwd: New Version Notification for draft-ietf-6man-ipv6only-flag-02.txt

From: Bob Hinden <[email-masked]>
Date: Tue, 14 Aug 2018 14:05:55 -0700

Hi,

New version is now available.  Changes from earlier version are:

      *  Added text about logging configuration errors to Section 6
      *  Added text to Section 9 to clarify that hosts not supporting
         this flag are not protected from IPv4-based attacks.
      *  Editorial changes.

Links below.

The authors believe this is now ready for 6man working group last call.

Thanks,
Bob & Brian

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-ietf-6man-ipv6only-flag-02.txt
> Date: August 14, 2018 at 1:59:30 PM PDT
> To: "Robert M. Hinden" <[email-masked]>, "Robert Hinden" <[email-masked]>, "Brian Carpenter" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-6man-ipv6only-flag-02.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-ietf-6man-ipv6only-flag
> Revision:	02
> Title:		IPv6 Router Advertisement IPv6-Only Flag
> Document date:	2018-08-14
> Group:		6man
> Pages:		11
> URL:              https://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6only-flag-02.txt
> Status:           https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6only-flag/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6only-flag
> Diff:                https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6only-flag-02
> 
> Abstract:
>   This document specifies a Router Advertisement Flag to indicate to
>   hosts that the administrator has configured the router to advertise
>   that the link is IPv6-Only.  This document updates RFC5175.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: David Farmer <[email-masked]>
Date: Tue, 14 Aug 2018 17:20:18 -0500

Paragraph 2 or section 6, says;

   The intent is that the administrator of the router configures the
   router to set the IPv6-Only flag if she/he wants to tell the hosts on
   the link that the link is IPv6-Only.  This is a configuration flag,
   it is not something that the router decides on it's own.  Routers MAY
   log a configuration error if the flag is set and IPv4 is still active
   on the router.

Thanks for adding the "MAY log a configuration error".  However, you have
the sentence ending as, "IPv4 still active on the router." I think it
should read, "IPv4 still active on the link." Especially since the flag
seems to be configured on a per link basis, at least that is how I read it.

Thanks.

On Tue, Aug 14, 2018 at 4:05 PM, Bob Hinden <[email-masked]> wrote:

> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-ietf-6man-ipv6only-flag-02.txt*
> *Date: *August 14, 2018 at 1:59:30 PM PDT
> *To: *"Robert M. Hinden" <[email-masked]>, "Robert Hinden" <
> [email-masked]>, "Brian Carpenter" <[email-masked]>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2018 11:03:03 +1200

> seems to be configured on a per link basis, at least that is how I read it.

Yes, so I think you mean "is still active on the router's interface to the link."

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 15 Aug 2018 08:32:07 -0700

> On Aug 14, 2018, at 4:03 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Yes, so I think you mean "is still active on the router's interface to the link.”

That seems right to me too.  We will fix in next update.

Bob

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 16 Aug 2018 23:05:04 +0100

> The authors believe this is now ready for 6man working group last call.

Bob,

I thought I had previously posted some specifics about the problem 
statement / introductory statement, but apparently didn't.  Here goes:

There are four reasons provided as justification for the ipv6-only flag, 
along with a reference to a broadcast traffic snooping incident on the 
ipv6-only network at the IETF100 meeting.  These 5 data points are used 
as the basis to justify a pretty hefty protocol stack behaviour change.

Taking these points in order:

>                       Monitoring of IPv6-only link, for example at the
>    IETF 100 meeting in Singapore, shows that current dual stack hosts
>    will create local auto-configured IPv4 addresses and attempt to reach
>    IPv4 services.

It is true that dual stack hosts will create locally scoped ipv4 
chatter, but it is inappropriate to use anecdotes as serious 
justification for anything and I'd respectfully suggest that it does not 
help your argument to quote an anecdote like this.

In addition, you ignore the valid reasons that vendors may have for 
enabling ipv4 on networks which do not support routable ipv4 addressing, 
and the customer loss of functionality which may occur if this were to 
be disabled.

>                   This may be a problem for several reasons:
> 
>    o  It may result in an undesirable level of Layer 2 broadcast
>       traffic, especially on large wireless networks.

This has been covered in other postings about this draft, but if you 
create large unmanaged wireless networks, you've got to expect to run 
into problems.  At the risk of pointing out the blindingly obvious, lack 
of design does not scale.  There are already operational mechanisms 
available today to handle l2 broadcast and multicast chatter.  It's been 
brought up before that they are not ietf-owned, but this is not 
relevant: they work.

>    o  In particular, this may overload switches in multi-segment
>       wireless networks because it will create IPv4 state for every dual
>       stack host.

I'm not clear what you mean here.  Switches don't carry ipv4 state, and 
creating ipv4 state in dual stack hosts is of negligible overhead (e.g. 
sockets, etc).

>    o  Such traffic may drain battery power on wireless hosts that have
>       no interest in link-local IPv4 traffic.  [RFC7772] indicates how
>       this risk might be quantified.
> 
>    o  Similarly, hosts may waste battery power on futile attempts to
>       access IPv4 services.

These points boil down to management of RX and TX ipv4 host traffic, 
which has been discussed and largely debunked before, except for small 
unmanaged networks - where the problem is constrained by scale anyway.

Please see the following posts for some analysis on how this would work:

https://mailarchive.ietf.org/arch/msg/ipv6/wy56svO1UMxBl45ijQUuxtcwe1E
https://mailarchive.ietf.org/arch/msg/ipv6/NIJ194PI8CLkuZT8U_jKEOY01QI

>    o  On an IPv6-only link, IPv4 might be used for malicious purposes
>       and pass unnoticed by IPv6-only monitoring mechanisms.

On a properly managed ipv4 network, ethertype filtering can be deployed 
which will block this traffic with 100% efficiency.  This works today, 
and can be deployed across multiple network types, but most importantly, 
it's available on properly managed wifi networks and large cabled 
ethernet networks with reasonable quality equipment.

Overall, the justification provided in the introduction section is in 
itself weak by any reasonable standard.  If this were an informational 
RFC about some obscure matter, it probably wouldn't matter too much, but 
this ID is intended as standards track and mandates modification of 
every ipv6 stack in the world.  The justification required for making a 
change of this scale is large.  The problem statement you've provided is 
inadequate, by orders of magnitude.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 16 Aug 2018 23:26:32 +0100

Bob, Brian,

Rather than cutting and pasting text from previous emails into a 
gigantic email that no-one will ever read, please indulge me for posting 
a bunch of URLs about issues that I've raised before, and which were 
agreed to, or not addressed properly, or - in many cases - not addressed 
at all.  Please also excuse referring to the same URLs multiple times; 
this is due to how the various issues were brought up at various times.

These concerns can be summarised as follows:

0. helicopter position: overall, this draft is at best unnecessary and 
should be not progressed further:

Brian kindly responded, and agreed to most of the points raised.

1. the problem statement is poorly justified:

I've just posted some thoughts separately on this issue:

https://mailarchive.ietf.org/arch/msg/ipv6/GCGYTXhg0V9mQBrcO7zhC5wtnp0

2. although worded in more general terms, the draft is really only 
applicable to the specific case of large, poorly designed wifi networks:

There was no response to this.

3. the amount of effort required to implement the ipv6only flag is 
substantial and in no way is matched by the problem statement, ref:

Brian largely agreed with this position.

4. there are better ways of managing the problem, namely ethertype 
filtering on network access devices and reasonable network segmentation:

https://mailarchive.ietf.org/arch/msg/ipv6/01fPwJgtlpgf_fcliwV9FGxs8KU
https://mailarchive.ietf.org/arch/msg/ipv6/wy56svO1UMxBl45ijQUuxtcwe1E

Most of these points were either not addressed, or they were agreed to.

5. there was no feedback from vendors about whether this is a valid 
problem that needs to be fixed, as suggested by Mike Abrahamsson:

https://mailarchive.ietf.org/arch/msg/ipv6/3g3cwEzPa90UYtut1R6IxgON9Gg

There was no followup to this email.

6. from a security point of view, this flag opens up a can of worms. 
It's not good enough just to acknowledge that the can of worms exists: 
common sense needs to be applied about whether this is really a good 
idea to start with - or not, as the case may be.

Overall, there is still an uncomfortably large number of fundamental, 
serious problems outstanding with this draft, several of which have been 
acknowledged by the authors, many of which have not been addressed at 
all, and each of which on its own would be sufficient reason to question 
the wisdom of progressing the draft further.  Right now it seems that 
the draft is a solution looking for a problem, rather than the other way 
around.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Aug 2018 10:42:58 +1200

Nick,

> help your argument to quote an anecdote like this.

It wasn't anecdotal. Both the NOC and various individuals were
observing the traffic. Agreed, there is no published analysis to
cite.

> and the customer loss of functionality which may occur if this were to 

No. We don't purport to block such traffic. (Layer 2 filters might
do so, but that's a different matter.) We actually address this
point specifically in the Applicability section:

>>>    Dual stack hosts that have a good reason to use IPv4, for example for
>>>    a specific IPv4 link-local service, can continue to do so.  This is
>>>    consistent with the SHOULD language in this document.

> brought up before that they are not ietf-owned, but this is not 

Which is why they are discussed (non-normatively) in the draft.

> creating ipv4 state in dual stack hosts is of negligible overhead (e.g. 

1) Switches may sometimes do things like ARP snooping and caching.
2) Any overhead is significant in a battery-limited device.

> unmanaged networks - where the problem is constrained by scale anyway.

Again, we're thinking of the issue affecting individual battery-limited
devices, which we expect to see in increasing numbers on both managed
& unmanaged networks.

> https://mailarchive.ietf.org/arch/msg/ipv6/NIJ194PI8CLkuZT8U_jKEOY01QI

Yes, we understand your point of view, but the WG adopted the draft
all the same.

> ethernet networks with reasonable quality equipment.

Right... on properly managed networks. There are improperly managed
networks too.
 
> every ipv6 stack in the world.

Like every IETF standard, it's voluntary. It's also a classical case of
incrememental deployment, with safe backwards compatibility. So the market
can decide, as it always does.

   Brian

> The justification required for making a

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Aug 2018 18:30:23 +0100

> observing the traffic. Agreed, there is no published analysis to

this was more of a suggestion than a criticism.  It's a single datum 
rather than a broad spectrum of data, so doesn't help justification of 
the ID because of its limited application.

> Which is why they are discussed (non-normatively) in the draft.

they are touched on but this doesn't deal with the more important issue, 
namely that it's not the responsibility of the ietf to create 
workarounds for broken operational designs.  Deploying broken designs 
needs to be considered operator error, and gigantic l2 domains are the 
textbook examples of this since the days when people used their /16 
net-blocks on the campus backbone.  Throwing piles of devices on an 
uncontrolled flat network domain was a terrible idea then, and it 
remains a terrible idea now, regardless of medium.

> 1) Switches may sometimes do things like ARP snooping and caching.

DHCP snooping and other technologies like dynamic arp inspection don't 
consume forwarding-plane hardware state, just tiny amounts of RAM on the 
control plans for display purposes.

 From the point of view of snooping in general, any reasonable switch 
will rate-limit punted traffic before it hits the SP.  Some don't, but 
if you use hardware which is unfit for purpose, then this comes down to 
design and consideration about how to handle scaling issues: no-one 
ploughs a field with a mini cooper, and if you attempt to do so, you'll 
find out quickly enough that it's a terrible idea.  It doesn't make 
sense to add an option to fields to make them more easily ploughable by 
minis.  This is the wrong way fixing this style of problem.

> Yes, we understand your point of view, but the WG adopted the draft

The issues brought up in these posts were either not addressed or only 
partially addressed before wg adoption.

> Right... on properly managed networks. There are improperly managed

Then these improperly managed networks should be approached by writing 
IDs (or even better, BCOPs) about how to manage them properly from a 
design principal point of view.

> can decide, as it always does.

The difficulty I have with this draft is that if you acknowledge that 
it's really only useful for large, flat wifi networks which lack 
segmentation, and that the reasons for proposing the flag are wafer thin 
with the single exception of wifi battery usage for handheld devices, 
which can be better handled by application of l2 filters, the rationale 
for continuing with the draft just doesn't add up.

You can't reasonably claim that it's up to the market to decide - the 
IETF has a responsibility to propose things which are operationally 
useful and which fix broadly applicable real-world problems in a way 
which balances utility against engineering effort.  I don't think that 
this draft falls into either of these categories.

Nick

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Aug 2018 06:05:57 +1000

> > On 2018-08-17 10:05, Nick Hilliard wrote:
<snip>
> which can be better handled by application of l2 filters,

So where are these layer 2 filters going to be applied, and is
applying those layer 2 filters more or less work than setting an IPv6
RA flag in no more than a few router interface configurations?

Unless these layer 2 filters are pushed right down into the wifi
station (i.e. the hosts), these unsupported IPv4 packets being sent
are still going to be unnecessarily consuming Wifi link capacity, even
if the Wifi AP drops them, even on the smallest Wifi networks,
including home ones. As they're typically broadcasts i.e. DHCPv4
discovers, that is a more significant effect due to Wifi's lower
broadcast than unicast capacity.

I think it most cases it is better to inform a device (and any entity
too, including humans), that what they're actively trying to do is
unlikely or not intended to work, so continuing to do so, unless there
is a specific need (e.g. link-local IPv4 in this case), is a waste of
time and resources.

This flag could be described as an out-of-band IPv4 configuration
method, indicating to only use IPv4 for link-local traffic if
necessary, being carried out-of-band in IPv6.

Regards,
Mark.

> the rationale

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Aug 2018 15:22:26 -0500

Nick's criticisms of this draft got me thinking about this problem space a
bit more.

We have been looking at the IPv6-only flag for the network to communicate
that it is IPv6-only, however, this is only truly useful if you first know
the host is capable of functioning in an IPv6-only environment.

So, I think we, more importantly, need a mechanism to communicate the host
capabilities to the network and so the network can put hosts capable of
operating in an IPv6-only environment in that environment. These are hosts
with 464XLAT/CLAT function or a bump-in-the-host, or with all applications
IPv6 enabled.  And then put hosts that need IPv4 on networks that have IPv4
enabled, likely using an in the network 464XLAT/CLAT function. I think
there is at least a small win if I don't have to scale an in the network
464XLAT/CLAT, to all hosts, but to only the hosts that can't cope with an
IPv6-only environment.

If this occurs first, then an IPv6-only flag makes sense to tell the host
it is on an IPv6-only network.  So the host knows to optimize itself for an
IPv6-only environment, not to configure IPv4, and that the network is
likely doing L2 filtering of IPv4.  I'm especially thinking of this for
managed WiFi networks.

So, I'm beginning to doubt the usefulness of an IPv6-only flag by itself,
in conjunction with a mechanism to communicate the host capabilities it
allows the host to optimize itself to an IPv6-only environment. But by
itself, it is an incomplete solution, because it ignores IPv4-only hosts,
and at this time I don't think that is useful for me as a network operator.

Thanks.

---

From: Simon Hobson <[email-masked]>
Date: Tue, 21 Aug 2018 21:48:08 +0100

David Farmer <[email-masked]> wrote:

> So, I think we, more importantly, need a mechanism to communicate the host capabilities to the network and so the network can put hosts capable of operating in an IPv6-only environment in that environment.

What about hosts that (looking at them in isolation) are capable of IPv6 only operation, but there are other devices on the network that they need to connect to via IPv4. At some point, there is a break point between where it's "cheaper" to keep IPv4 going natively, and where it's going to be "cheaper" to use a translation technique to give access to those IPv4 only devices.
Determining that automagically from what hosts tell you is going to be "difficult" - particularly as those legacy systems are also going to be ones that won't tell you that they still need IPv4.

I can't see how you could possibly create a generally acceptable algorithm to do that, rather than just leaving it to the network admin to decide what he wants his network to do and what it's capable of.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 21 Aug 2018 13:57:45 -0700

Simon,

> On Aug 21, 2018, at 1:48 PM, Simon Hobson <[email-masked]> wrote:
> 

The draft is clear that it is intended to be used by an administrator.

Bob

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Aug 2018 16:22:38 -0500

On Tue, Aug 21, 2018 at 3:48 PM, Simon Hobson <[email-masked]>
wrote:

> > So, I think we, more importantly, need a mechanism to communicate the
> host capabilities to the network and so the network can put hosts capable
> of operating in an IPv6-only environment in that environment.
>
> What about hosts that (looking at them in isolation) are capable of IPv6
> only operation, but there are other devices on the network that they need
> to connect to via IPv4. At some point, there is a break point between where
> it's "cheaper" to keep IPv4 going natively, and where it's going to be
> "cheaper" to use a translation technique to give access to those IPv4 only
> devices.
> Determining that automagically from what hosts tell you is going to be
> "difficult" - particularly as those legacy systems are also going to be
> ones that won't tell you that they still need IPv4.
>
> I can't see how you could possibly create a generally acceptable algorithm
> to do that, rather than just leaving it to the network admin to decide what
> he wants his network to do and what it's capable of.
>

Yes, you need to decide if deploying an IPv6-only network segments makes
sense for you.  If the majority of your hosts are IPv4-only then it may not
make any sense to deploy any IPv6-only network segments.

However, if you have enough hosts, you will need multiple L3 network
segments anyway, and if you have enough network segment, deploying some of
them as IPv6-only may make sense.  In my case, I have a very large WiFi
network with 25,000+ concurrent users, it already has many L3 segments 50+.
Making some IPv6-only is not a problem for me, if I know which hosts to put
in the IPv6-only L3 segments.  I'm not saying this is for everyone.

YMMV.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 21 Aug 2018 14:52:39 -0700

David,

> On Aug 21, 2018, at 2:22 PM, David Farmer <[email-masked]> wrote:
> 
> 
> On Tue, Aug 21, 2018 at 3:48 PM, Simon Hobson <[email-masked]> wrote:
> Yes, you need to decide if deploying an IPv6-only network segments makes sense for you.  If the majority of your hosts are IPv4-only then it may not make any sense to deploy any IPv6-only network segments.
> 
> However, if you have enough hosts, you will need multiple L3 network segments anyway, and if you have enough network segment, deploying some of them as IPv6-only may make sense.  In my case, I have a very large WiFi network with 25,000+ concurrent users, it already has many L3 segments 50+. Making some IPv6-only is not a problem for me, if I know which hosts to put in the IPv6-only L3 segments.  I'm not saying this is for everyone.

I think that a fair summary.  It is intended for environments where the admin finds it a useful tool.  IMHO, this will be useful in the short term in some environments, but over time as IPv6 deployment continues to grow it will be useful in more environments.

Thanks,
Bob

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Aug 2018 23:22:25 +0100

Mark Smith wrote on 21/08/2018 21:05:
> So where are these layer 2 filters going to be applied

as close to the edge devices as possible: switch edge ports, AP radio 
interfaces, etc.

> and is

the term "more or less work" is too ill-defined to be useful.

If you're running a large managed wifi network with a centralised 
controller, pushing out an edge filter rule across all APs is almost 
certainly something that can be done with a single action on the controller.

If you choose the wrong tool for the job, for sure it can be a good deal 
more complicated.

> including home ones.

This was brought up here:

> As they're typically broadcasts i.e. DHCPv4

Remember that layer 2 broadcast packets from the station are delivered 
via 802.11 unicast to the AP.  It's the AP-to-station broadcast traffic 
which hogs basic rate capacity because it's delivered using 802.11 
broadcast, which uses basic rate channels.

Basic rate channel usage is expensive, but that is fully controllable by 
the AP: if the operator filters out ethertype 0x0806 and 0x0800, then 
ipv4-related basic rate traffic will drop to zero.

Note that this is 100% effective on a per-AP basis from the moment it is 
deployed at the AP.  Even in the most wildly optimistic deployment 
situations, an ipv6-only flag deployed on some arbitrary network would 
be unlikely to come close to that efficiency in the foreseeable future.

> is a specific need (e.g. link-local IPv4 in this case), is a waste of

I freely admit that at first glance, this flag looks like it could be a 
good idea, but it doesn't stand up to scrutiny.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Aug 2018 11:39:08 +1200

> I think that a fair summary.  It is intended for environments where the admin finds it a useful tool.  IMHO, this will be useful in the short term in some environments, but over time as IPv6 deploy…

Exactly. And while it might be useful for hosts to inform routers of their (the hosts') capabilities, that is a much bigger project (a sort of inverse PVD, in fact) that I would say is more than an IPv6 project anyway.

So can we please treat the IPv6-only flag as a single building block, that some people can use some of the time, and move on?

That's also my response to Nick Hilliard's commentary. We aren't boiling the ocean. We've updated the draft to reflect that, when available, Layer 2 filtering can be used. The market will decide what gets implemented and used.

Looking for any specific comments on the text of the draft.

Regards
    Brian

---

From: David Farmer <[email-masked]>
Date: Wed, 22 Aug 2018 03:11:06 -0500

On Tue, Aug 21, 2018 at 6:39 PM, Brian E Carpenter <
[email-masked]> wrote:

> Exactly. And while it might be useful for hosts to inform routers of their
> (the hosts') capabilities, that is a much bigger project (a sort of inverse
> PVD, in fact) that I would say is more than an IPv6 project anyway.
>

Actually, I think I was saying host inform networks, not the routers.  But
that might too fine of a point.

I agree this probably isn't an IPv6 thing, it might not even be an IETF
thing, it might be an IEEE thing.

Looking at this a bit more, and the other way around from what I was
thinking, 802.11u Access Network Query Protocol (ANQP) already talks about
networks advertising address availability;

For IPv6 the current values are:
  o Address type not available
  o Address type available
  o Availability of the address type not known

For IPv4 the current values are:
  o Address type not available
  o Public IPv4 address available
  o Port-restricted IPv4 address available
  o Single NATed private IPv4 address available
  o Double NATed private IPv4 address available
  o Port-restricted IPv4 address available and Single NATed IPv4 address
available
  o Port-restricted IPv4 address available and Double NATed IPv4 address
available
  o Availability of the address type not known

I found some discussion of applicability of ANQP to other 802 networks like
802.3, but I'm not sure it got past discussion.

So can we please treat the IPv6-only flag as a single building block, that
> some people can use some of the time, and move on?
>
> That's also my response to Nick Hilliard's commentary. We aren't boiling
> the ocean. We've updated the draft to reflect that, when available, Layer 2
> filtering can be used. The market will decide what gets implemented and
> used.
>

I mostly agree you have covered Layer 2 filtering. However, the following
two statements seem to be at odds with each other, at least to me.

   Operators of large IPv6-only wireless links are advised to also use
   Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800
   and 0x806) at all switches, and to ensure that IPv4 and ARP features
   are disabled in all switches.

I think maybe the first paragraph should be removed outright. But, If it is
kept, maybe "can attempt to do so". Saying, "can continue to do so" seems
way too strong with the second paragraph in the document. Also, maybe be
more specific about which SHOULDs you are referring to, there are a lot of
them.

This paragraph seems to imply IPv4-only hosts should not be intentionally
connected to these IPv6-only links, but maybe that should be said more
directly.

   Administrators SHOULD only use this mechanism if they are certain
   that the link is IPv6-Only.  For example, in cases where there is a
   need to continue to use IPv4 or there are IPv4 only routers, setting
   this flag to 1 is a configuration error.

Maybe something like;

   Administrators SHOULD only use this mechanism if they are certain
   that the link is IPv6-Only.  For example, in cases where there is a
   need to continue to use IPv4, when there are intended to be
   IPv4-only hosts or IPv4 routers on the link, setting this flag to
   1 is a configuration error.

Finally how about additional non-normative discussion about taking care to
prevent unsuspecting WiFi users from being accidentally connecting
IPv4-only WiFi hosts to IPv6-only WiFi links, such as including "IPv6-only"
in open SSIDs, using secure SSIDs, or using 802.11u Access Network Query
Protocol (ANQP) with "Address type available" for IPv6 and "Address type
not available" for IPv4. Putting this in an appendix would be fine with me.

Remember the IETF's own discussions regarding this issue. If the IETF isn't
willing to have its default WiFi be IPv6-only, maybe some caution is
warranted for the general population of the earth. :)

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Aug 2018 08:24:35 +1200

Thanks David, your suggestions below make sense to me.

Regards
   Brian