Subject: IPv4 traffic on "ietf-v6ONLY"

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 03:13:07 +0100

There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Nov 2017 15:44:28 +1300

> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.

Also on the DNS64 network. But it is all one-way, you
will notice. No replies as far as I can see. Most of them
are sourced from 169.254.*.*, but there are some oddities such as
31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general

I have a couple of Wireshark capture files if anyone cares.

   Brian

---

From: Jen Linkova <[email-masked]>
Date: Wed, 15 Nov 2017 13:57:01 +1100

> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.

Nothing prevents a host form configuring 'link-local' IPv4 address and
trying to reach other hosts over Ipv4 even if the network itself does
not provide IPv4 as a service.
However those v4 connectivity attempts will be unsuccessful indeed
(well, communication in the same broadcast domain might be OK as long
as L2 environment supports switching Ethernet frames with IPv4
inside).

>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
SY, Jen Linkova aka Furry

---

From: Lee Howard <[email-masked]>
Date: Wed, 15 Nov 2017 10:59:06 +0800

>31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general

Does that return us to the question of how to tell hosts that IPv4 doesn’t
live here, and to stop trying?

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Nov 2017 16:07:24 +1300

> live here, and to stop trying?

Maybe. But on the other hand there is no reason in principle
that peer2peer traffic between 169.254.*.* addresses won't work.
(There are reasons in practice, e.g. it doesn't work on Windows 7.)

   Brian

---

From: Jen Linkova <[email-masked]>
Date: Wed, 15 Nov 2017 14:08:04 +1100

> live here, and to stop trying?

I do not believe we should be doing this. How do you tell the hosts
'Ipv6 does not live here, stop trying' and why would you
be doing this when I can just get hosts talk to each other on link
using IPv6 LLAs?
Or that...I don't know, DECNET, Appletalk or MPLS does not live here?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Nov 2017 14:08:20 +1100

> On 15 Nov 2017, at 1:59 pm, Lee Howard <[email-masked]> wrote:
> 

I don’t think so.  Enterprises that want to get rid of local IPv4 traffic can filter it.
In the home it really doesn’t matter if there is still local IPv4 the same way as
on most hotel nets there is a lot of IPv6 local traffic but no external IPv6 traffic.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Nov 2017 22:11:28 -0500

> On Nov 14, 2017, at 10:07 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Can you get any sense of how much of the IPv4 traffic is useless?  Would it be useful to try to quench that useless traffic to improve network performance, behavior, operations?  

- Ralph

---

From: joel jaeggli <[email-masked]>
Date: Wed, 15 Nov 2017 11:11:01 +0800

> live here, and to stop trying?

Ah but it does, because in the absence of ipv4 network instruction you
still build an adhoc network, just as you do for ipv6.

J@mb:nobackup$dns-sd  -G v4 "mb.local"
DATE: ---Wed 15 Nov 2017---
11:04:02.802  ...STARTING...
Timestamp     A/R Flags if Hostname
Address                                      TTL
11:04:02.804  Add     2  5 mb.local.
169.254.36.108                               120

J@mb:nobackup$dns-sd  -G v4 "Zamboni.local"
DATE: ---Wed 15 Nov 2017---
11:06:42.643  ...STARTING...
Timestamp     A/R Flags if Hostname
Address                                      TTL
11:06:42.644  Add     2  5 zamboni.local.
169.254.150.104                              120

if you turn off your ipv4 stack you'll no longer do that.

There is some (possibly misguided) assumption that if you have only
adhoc networking available for a given address faily that your network
is broken. In fact it is not, it is working.

joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Nov 2017 16:31:32 +1300

> Can you get any sense of how much of the IPv4 traffic is useless?  Would it be useful to try to quench that useless traffic to improve network performance, behavior, operations?  

At the moment I think it's 100% useless traffic - in the two captures,
I see messages from many 169.254.*.* addresses and, I think, none that
are sent to such an address (except 169.254.255.255). Haven't quite
figured out the Wireshark display filter to be 100% certain

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Nov 2017 18:13:53 +1300

Update at the end...

> figured out the Wireshark display filter to be 100% certain

The correct display filter is ip.dst==169.254.0.0/16 and ip.dst!=169.254.255.255
and the result is exactly zero messages with a unicast destination
in 169.254.0.0/16. So I can assert that there is no peer to peer
IPv4 link local traffic, just futile attempts to reach multicast
destinations.

There's quite a lot to 255.255.255.255, with a large majority being 
"Dropbox LAN sync Discovery Protocol".

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 15 Nov 2017 11:47:39 +0100

> Does that return us to the question of how to tell hosts that IPv4
> doesnt live here, and to stop trying?

The safest option to do that is a DHCPv4 option that says 'no IPv4 service
here, go away'.

Any network that has IPv4 production traffic already has to protect against
rogue DHCPv4 servers. 

Of course, a DHCPv4 option conflicts with the goal of some people to have
no IPv4 related infrastructure at all.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 15 Nov 2017 11:02:01 +0000

Perhaps, define a DHCPv6 option to convey v6-only, for which the client interpretation should be to suppress v4.

Although this will be at the cross road with allowing client’s wishes to use v4 LL for whatever useless/useful traffic, it would be a reasonable deployment policy to enforce.

We have to remember that allowing this would continue to hurt WLAN (not wired LAN) for obvious reasons - radio bandwidth.

During one of ciscolive conferences, i recall having observed lots of useless v4 traffic (e.g. discovery) on WLAN.  Andrew (cced) may remember more details.

Cheers,
Rajiv

On Nov 15, 2017, at 5:48 AM, Philip Homburg <[email-masked]<mailto:[email-masked]>> wrote:

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 12:16:12 +0100

Le 15/11/2017 à 03:44, Brian E Carpenter a écrit :
> will notice. No replies as far as I can see.

Brian,

I looked at it for longer time.  I did spot some successful exchanges, 
i.e. replies too.

> Most of them
> are sourced from 169.254.*.*,

YEs, most of them.

> but there are some oddities such as

YEs, but there is more.  There are also TCPs and https and 
re-transmissions.  I dont recollect precisely but there is surely more 
than LL.

> I have a couple of Wireshark capture files if anyone cares.

I think it's good to produce many now at IETF and analyze later, because 
no access to "ietf-v6ONLY" later.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 12:20:08 +0100

Le 15/11/2017 à 03:59, Lee Howard a écrit :
>> Also on the DNS64 network. But it is all one-way, you will notice.
>> No replies as far as I can see. Most of them are sourced from
>> 169.254.*.*, but there are some oddities such as 31.130.227.98
>> 224.0.0.1	IGMPv2	42	Membership Query, general
> 
> 
> doesn’t live here, and to stop trying?

I think the question is relevant.

On one hand, it's counterproductive to tell some computer to stop
sending, "protocol police" is making laugh.

On another hand, recent documents do have these kinds of semantics:
PIO-X, prefix-exclude option in DHCP, and others.

On the same vein, even for IPv6 there is need of such semantics: the
IPv6 DNS address in the RA gets installed on a Client forever.  And it's
that IPv6 Host that makes IPv6 noise on IPv4-only networks.

Alex

>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Philip Homburg <[email-masked]>
Date: Wed, 15 Nov 2017 12:21:19 +0100

>     Perhaps, define a DHCPv6 option to convey v6-only, for which
>     the client interpretation should be to suppress v4.  Although
>    this will be at the cross road with allowing client's wishes to
>    use v4 LL for whatever useless/useful traffic, it would be a
>    reasonable deployment policy to enforce.

The problem with a DHCPv6 option is that an IPv4-only network may not be
prepared to defend against rogue DHCPv6 servers.

So anyone who starts such a server can kick everybody else of the IPv4 network.

Great option for an overcrowded hotel or conference network.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 12:23:15 +0100

Le 15/11/2017 à 04:08, Jen Linkova a écrit :
> 'Ipv4[] does not live here, stop trying' and why would you

You could do that with DHCPv4: it has some mechanism to not respod to 
DHCPv4 Request, or to reduce the lifetime, or reply negatively altogether.

You could also invent an ICMPv4 message send by the Router to the 
IPv6-only Host that says: I only do IPv6.

But to avoid the IPv4 LL-addressed traffic I dont know.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2017 00:29:30 +1300

There's an L flag in draft-ietf-intarea-provisioning-domains
that says "DHCP(v4) on this network". So L=0 says "No DHCP(v4) on
this network".

    Brian

---

From: Warren Kumari <[email-masked]>
Date: Wed, 15 Nov 2017 19:30:32 +0800

> interpretation should be to suppress v4.

Can someone remind me what problem we are trying to solve?
W

>
> Although this will be at the cross road with allowing client’s wishes to use
> v4 LL for whatever useless/useful traffic, it would be a reasonable
> deployment policy to enforce.
>
> We have to remember that allowing this would continue to hurt WLAN (not
> wired LAN) for obvious reasons - radio bandwidth.
>
> During one of ciscolive conferences, i recall having observed lots of
> useless v4 traffic (e.g. discovery) on WLAN.  Andrew (cced) may remember
> more details.
>
> Cheers,
> Rajiv
>
> On Nov 15, 2017, at 5:48 AM, Philip Homburg <[email-masked]>
> wrote:
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2017 00:32:58 +1300

> prepared to defend against rogue DHCPv6 servers.

A bigger problem is that not all networks/hosts support DHCPv6. It needs
to be an RA option if you want everybody to see it.

    Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 15 Nov 2017 13:39:44 +0100

>that says "DHCP(v4) on this network". So L=0 says "No DHCP(v4) on

Maybe I'm reading the draft too strictly, but it seems that the L flag is used
to tell which provisioning domain DHCPv4 information belongs to. Not to tell
a host to avoid using DHCPv4 in the first place.

If it does have the intention to make hosts avoid DHCPv4 requests then it
has the same drawback as in sending a 'no IPv4' option in RA or DHCPv6:
in an IPv4-only network that can be used to prevent hosts from connecting to
the network.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 14:29:40 +0100

> Can someone remind me what problem we are trying to solve?

To me, the problem comes mainly from the impossibility to say "IPv6-only".

It's not just a terminology problem.  There are bad side-effects of 
abusing the term "IPv6-only".  Some people claim that IPv6 is there 
already, because there are "IPv6-only" networks.  But there are no 
"IPv6-only" networks at all.  (except in some very rare cases that are 
not visible at IETF nor at mobile network operators.)

Another problem can be related to that wireless network efficiency (too 
many useless IPv4 packets on the air of "ietf-v6ONLY").

The 'noise' problem is symmetric - valid in IPv4 too.  The person at the 
IETF ticketing system tells me I have to go meet them to manually remove 
the DNS Server IPv6 address that the "ietf" SSID has put on my Windows 
and that stays there forever.  That DNS IPv6 address makes noise on my 
corporate IPv4-only network.  I suppose the person does not want me to 
go there at each IETF for that manual operation.  That's a speculation 
of a problem too.  Maybe he has some magic means (a protocol?) that 
makes that the DNS IPv6 address has a lifetime, or so.

Alex

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Nov 2017 05:33:05 +1100

Do we provide a DHCPv6 server and set the O bit in the RA to provide the DNS server addresses?  Manual config shouldn’t be required if we do that unless your OS is broken. I’m not on site to check. 

-- 
Mark Andrews

> On 16 Nov 2017, at 00:29, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> It's not just a terminology problem.  There are bad side-effects of abusing the term "IPv6-only".  Some people claim that IPv6 is there already, because there are "IPv6-only" networks.  But there are no "IPv6-only" networks at all.  (except in some very rare cases that are not visible at IETF nor at mobile network operators.)
> 
> Another problem can be related to that wireless network efficiency (too many useless IPv4 packets on the air of "ietf-v6ONLY").
> 
> The 'noise' problem is symmetric - valid in IPv4 too.  The person at the IETF ticketing system tells me I have to go meet them to manually remove the DNS Server IPv6 address that the "ietf" SSID has put on my Windows and that stays there forever.  That DNS IPv6 address makes noise on my corporate IPv4-only network.  I suppose the person does not want me to go there at each IETF for that manual operation.  That's a speculation of a problem too.  Maybe he has some magic means (a protocol?) that makes that the DNS IPv6 address has a lifetime, or so.
> 
> Alex
> 
>> W
>>>

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Nov 2017 11:15:18 -0800

On Nov 15, 2017, at 02:47, Philip Homburg <[email-masked]> wrote:
> 
> The safest option to do that is a DHCPv4 option that says 'no IPv4 service here, go away'.

Better: extend ARP with a signal that says, “ARP is not welcome here."

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2017 12:49:57 +1300

> Do we provide a DHCPv6 server and set the O bit in the RA to provide the DNS server addresses?  Manual config shouldn’t be required if we do that unless your OS is broken. I’m not on site to check. 

I believe that Windows 7 may be broken in this regard, although
I have never seen the issue Alexandre mentioned. Windows seems to
sometimes put things into the permanent config when they clearly
should be non-persistent; or it fails to clear stuff out when
switching from one SSID to another. I don't know if this has been 
fixed in Windows >7, but it surely isn't a protocol issue.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2017 12:54:56 +1300

> Better: extend ARP with a signal that says, “ARP is not welcome here."
 
However, the IPv4 traffic seen on ietf-dns64 is negligible and harmless.
That is a practical indication that this problem probably isn't worth
solving. 

I submit for example that sending a new "not welcome" response to
ARP requests would do more harm than good, since the legacy hosts
would probably react badly.

   Brian

---

From: David Farmer <[email-masked]>
Date: Wed, 15 Nov 2017 18:39:41 -0600

> would probably react badly.

I'd love to see some data to back up the conjecture, that is the "traffic
... is negligible and harmless"

I completely agree that "a new "not welcome" response to ARP requests would
do more harm than good."

The problem I see is that WiFi airtime is precious, and worse yet broadcast
packets (DHCPv4 discover and ARP) can use excessive airtime in some
situations, more than the fraction of the bits they represent would
indicate.  On a wired network I'm not all that worried, but on WiFi, I'd
like some data on the matter.

On enterprise WiFi, you could filter ethertypes 0x0800 and 0x0806 at the
AP, or they usually have DHCP and ARP proxies, either of which would
prevent sleeping devices from being pestered by the traffic.  However, the
traffic still consumes airtime and that's my concern, especially on large
congested WiFi networks, like at IETF.

Thanks.

-- 
===============================================
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: Thu, 16 Nov 2017 13:56:36 +1300

> ... is negligible and harmless"

That it's negligible was shown in Bob Hinden's statistics from Wireshark.
That it's harmless seems obvious - it's virtually all multicast discovery
traffic that goes nowhere. As I said, I have a couple of capture files
if anybody is interested.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 03:26:45 +0100

Le 15/11/2017 à 19:33, Mark Andrews a écrit :
> Do we provide a DHCPv6 server and set the O bit in the RA

The RA has the M reset and the O set.

It contains a "Recursive DNS Server Address" Option, and with lifetime 
9000 seconds.

> to provide
> the DNS server addresses?  Manual config shouldn’t be required if we
> do that unless your OS is broken. I’m not on site to check.

I suppose then Windows is wrong to keep this address forever.

Or maybe it received just once from IETF an 'infinity' value in that 
field so it stays there forever.  It's a stretch though.

Alex

---

From: Tim Chown <[email-masked]>
Date: Thu, 16 Nov 2017 09:44:02 +0000

> On 16 Nov 2017, at 00:56, Brian E Carpenter <[email-masked]> wrote:
> 

Careful with that ethics can of worms you’re holding there ;)

I’ve seen some university networks where the wireless is surprisingly flat, and the multicast/broadcast traffic is not insignificant. The more recent trend is to VLAN pool or similar to avoid that, but that then affects service discovery (two WiFi devices in same room, but potentially on different subnets).

The service discovery traffic is generally replicated over IPv4 and IPv6; you’ll see the same advertisements and discovery traffic essentially duplicated.  But this is potentially useful in say a home network where you have legacy devices like TVs for which you can only discover the display over IPv4, and throw data to it over IPv4. 

The model in the DNSSD WG for wider area discovery is to keep resolution local, and relay the responses from the discovery proxies using unicast. 

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2017 22:52:49 +1300

> Careful with that ethics can of worms you’re holding there ;)

Yes, maybe we need to add "IP packets" to the last sentence of the Note Well ;-)

   Brian
 
> I’ve seen some university networks where the wireless is surprisingly flat, and the multicast/broadcast traffic is not insignificant. The more recent trend is to VLAN pool or similar to avoid that, but that then affects service discovery (two WiFi devices in same room, but potentially on different subnets).> 
> The service discovery traffic is generally replicated over IPv4 and IPv6; 
> you’ll see the same advertisements and discovery traffic essentially duplicated.  But this is potentially useful in say a home network where you have legacy devices like TVs for which you can only discover the display over IPv4, and throw data to it over IPv4. 
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 16 Nov 2017 10:32:20 +0000

While I do agree to RA being better than DHCP(v6) for the purpose discussed here, I also agree with Philip wrt L-flag usage. PvD L-flag = 0 would not prohibit a host from using IPv4 on the access.

We might be better off defining a new flag that explicitly indicates for host to ‘Suppress IPv4’. 

-- 
Cheers,
Rajiv

---

From: Markku Savela <[email-masked]>
Date: Thu, 16 Nov 2017 12:39:51 +0200

> We might be better off defining a new flag that explicitly indicates for host to ‘Suppress IPv4’.

And, if the local network has multiple independent routers, this flag 
would be confusing, if one router says "Suppress IPv4", and the other 
provides IPv4 routing? A flag could just be "advisory"...

---

From: Markku Savela <[email-masked]>
Date: Thu, 16 Nov 2017 12:41:39 +0200

On 16/11/17 12:39, Markku Savela wrote:
>> While I do agree to RA being better than DHCP(v6) for the purpose 
>> discussed here, I also agree with Philip wrt L-flag usage. PvD L-flag 
>> = 0 would not prohibit a host from using IPv4 on the access.
>>

...or, sorry.. is this discussion about WiFi only?

---

From: Erik Kline <[email-masked]>
Date: Thu, 16 Nov 2017 10:42:26 +0000

On 16 November 2017 at 10:39, Markku Savela <[email-masked]> wrote:
>> discussed here, I also agree with Philip wrt L-flag usage. PvD L-flag = 0
>> would not prohibit a host from using IPv4 on the access.
>>
> And, if the local network has multiple independent routers, this flag would
> be confusing, if one router says "Suppress IPv4", and the other provides
> IPv4 routing? A flag could just be "advisory"...

Since it would be new, it would almost inherently be advisory.

It could be the first flag in the EFO!  (if I'm not mistaken...)

---

From: David Farmer <[email-masked]>
Date: Thu, 16 Nov 2017 07:42:24 -0600

On Wed, Nov 15, 2017 at 5:21 AM, Philip Homburg <[email-masked].

> Great option for an overcrowded hotel or conference network.

Sorry, but that ship has sailed. If you are purposefully IPv4-only, you
have to deal with rogue IPv6 RAs at least, and probably rogue DHCPv6
servers too, or you need to filter ethertype 0x86DD altogether. Otherwise,
a rogue signal to turn off IPv4 is the least of your worries.  Malicious or
even accidental deployment of IPv6 is a bigger security worry on these
networks than a rogue signal to turn off IPv4.

I'm not saying that a rogue signal to turn off IPv4 isn't a problem. Just
if your willing to ignore rogue IPv6 deployment, then worrying about a
rogue signal to turn off IPv4 seems kind of selective.

Thanks.
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 14:59:38 +0100

> ...or, sorry.. is this discussion about WiFi only?

There is same IPv4 traffic on the Ethernet in Terminal Room too.  The 
Ethernet Terminal Room was not announced as "IPv6 only" or as "NAT64" 
but that's the way it acts: ping 8.8.8.8 blocked.

The question is whether Ethernet Terminal Room is configured as "IPv6 
only" or as NAT64.

(and yes, I did file tickets about this at the URL provided by Brian; 
and not only me filed such tickets).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 15:06:54 +0100

> provides IPv4 routing? A flag could just be "advisory"...

Advisory sounds good.

We could also consider our Terminology before calling Host or Network 
"IPv6 Only".

And, I am not opposing full IPv6 together with full IPv4 on ietf SSID, 
which is what happens now.

I do disagree when a critical access plug, such as Ethernet in Terminal 
Room, refuses ping 8.8.8.8.

Alex

---

From: Tim Chown <[email-masked]>
Date: Thu, 16 Nov 2017 15:10:35 +0000

> On 16 Nov 2017, at 13:42, David Farmer <[email-masked]> wrote:
> 
> On Wed, Nov 15, 2017 at 5:21 AM, Philip Homburg <[email-masked]> wrote:
> Sorry, but that ship has sailed. If you are purposefully IPv4-only, you have to deal with rogue IPv6 RAs at least, and probably rogue DHCPv6 servers too, or you need to filter ethertype 0x86DD altogether. Otherwise, a rogue signal to turn off IPv4 is the least of your worries.  Malicious or even accidental deployment of IPv6 is a bigger security worry on these networks than a rogue signal to turn off IPv4. 
> 
> I'm not saying that a rogue signal to turn off IPv4 isn't a problem. Just if your willing to ignore rogue IPv6 deployment, then worrying about a rogue signal to turn off IPv4 seems kind of selective.

Indeed. 

Perhaps there’s a case for a ‘flip’ Informational document to RFC 7123, as an advisory document, but even that’s a bit tenuous.

Tim

---

From: Philip Homburg <[email-masked]>
Date: Thu, 16 Nov 2017 16:34:04 +0100

>rogue signal to turn off IPv4 seems kind of selective.

If you want your 'no IPv4' signal to be ignored, then by all means make it
part of some IPv6 signalling protocol.

Nobody needs yet another attack vector.

Of course, eventually, there will be so little IPv4, that not getting a 
DHCPv4 lease quickly is a good signal to stop trying. But that's quite a few
years down the road.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Nov 2017 09:55:24 +1100

I suspect we will see hosts turning off IPv4 apart from DHCPv4 discover when they see
RAs and they don’t get responses to DHCPv4 discover in a few years time.  You don’t
have to bring up IPv4 link-local.

There will be a check box that says “IPv4 link-local with IPv6” or something like that.
It will default on for a few releases then the vendors will switch it to off by default.  The
IETF really doesn’t have to do anything.  The OS vendors will do this all by themselves.

Mark

> On 17 Nov 2017, at 2:34 am, Philip Homburg <[email-masked]> wrote:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Nov 2017 05:50:04 +0100

Le 15/11/2017 à 20:15, james woodyatt a écrit :
> On Nov 15, 2017, at 02:47, Philip Homburg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>>

During changes between the 3 SSIDs I noticed often the message "Windows 
detected an IP address conflict" popped up.  The explanation says that 
another computer on the network has the same address, contact the 
sysadmin, and more details are available.

This makes wonder whether someone put a computer there that responds to 
all ARP resolution requests for LLs 169, claiming them all.

It happens systematically when changing the ESSID from "ietf" to 
"ietf-v6ONLY".  If, prior to that change, I disable the IPv4 checkbox in 
interface Properties, the message does not pop up.

However, this message appears also when changing attachment from SSID 
"ietf-v6ONLY" to "ietf".

Alex

---

From: joel jaeggli <[email-masked]>
Date: Fri, 17 Nov 2017 13:12:02 +0800

On 11/17/17 12:50, Alexandre Petrescu wrote:
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>>

The arp / broadcast suppression proxy in the wireless controller is
responding afirmatively to the gratuitous arp that your client sends in
order to test  that it's auto-configured address is available. Roaming
rapidly between APs can achieve that. It thinks you're in two places at
one. sending any other kinda of packet first that would allow it to
update it's mac address table.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Nov 2017 18:14:15 +1300

> all ARP resolution requests for LLs 169, claiming them all.

It's a Windows 7 bug, I'm pretty sure. I think it fails to clear
something when changing to a new SSID but *not* receiving an
address. I reported it at https://tickets.meeting.ietf.org/ticket/1159

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Nov 2017 18:31:21 +1300

> update it's mac address table.

Hang on... that makes sense within a single SSID, but why would the
controller share info between independent SSIDs?

Unfortunately there is no ARP traffic in the captures I made during the
week.

    Brian