how do I disable IPv6?

[Robert Elz]

Date: Tue, 27 Feb 2018 20:20:16 -0700
From: Andy Ruhl <***@gmail.com>
Message-ID: <***@mail.gmail.com>

| There is DAD which shouldn't happen (but humans can cause it quite
| easily which should be easy to test),

Do you mean DAD (which is the protocol that tests for duplicate
addresses), or duplicate addresses? I suspect the latter.

| and then there is DAD for a link
| local address which *really* shouldn't happen.

Assuming the 2nd meaning, then that's true of EUI-64 generated
addresses, whatever scope they have. But it is just as easy (or
at least almost as easy) to manually assign a link local address as
any other, and those are just as likely to be duplicates as any other.

| Although I've heard
| stories of duplicate MAC addresses from unscrupulous vendors before.

I have heard those stories as well, though never actually seen it,
and I am not sure I have ever actually talked to anyone who had
personally seen it either.

| If DAD for the link local address works for one adapter and not
| another, hopefully that would ring some bells for someone familiar
| with that code. If not, get debug info.

If there is some hardware or driver that cannot do DAD correctly
(or just does not) then yes, that would be a bug worth fixing (if it
is the hardware, then unless there's an easy workaround, that
hardware would be worthless, and need replacing - just like a
(rotating metal) disc that refuses to spin...)

| With respect, this isn't the only bug that causes annoying messages.

No, but DAD is not a bug, and the messages it produces when
it detects a duplicate are not "annoying" they are important.

That other systems can still see the duplicate addr, and generate
their own messages when they fail to work is I think a bug (the
ntpd errors in the message seemed to have that cause) and that
one should be fixed.

If we are still having issues with daemons (or clients) attempting
to use a tentative addr, while DAD is still proceeding, and failing in
an annoying way, that is also a bug, and should be fixed.

kre

ps: none of this has anything to do with port-amd64, it should be
moved to tech-net. If anyone replies, please delete port-amd64



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Hi,

Post by Robert Elz
| Although I've heard
| stories of duplicate MAC addresses from unscrupulous vendors before.
I have heard those stories as well, though never actually seen it,
and I am not sure I have ever actually talked to anyone who had
personally seen it either.

Just as a data point - I have :-) - small manufacturer of industrial PCs
with onboard LAN cards. One of the steps in the production line scanned
MAC addresses from a printout with a barcode reader, programming them into
the card EEPROMs. One PC had the wrong line scanned, and two machines got
the same MAC address, ending up both in the office network of said
manufacturer. Funny effects ensued...

(This is an anecdote, it happened 10+ years ago, and I assume it's not
happening very often)

Second anecdote: our vmware cloud managed to cough up a number of VMs with
the same MAC address. Not sure exactly how that happened, but it was
something about multiple clusters all doing dynamic MACs from the same
"base range", and then VMs getting moved from one cluster to the other,
keeping the MAC address. The VMs didn't end up on the same network, but
a switch in-between did not have proper per-VLAN mac tables and funny
effects ensued...


So, yes, it happens.

gert

[Robert Elz]

Date: Wed, 28 Feb 2018 08:59:09 -0000 (UTC)
From: ***@serpens.de (Michael van Elst)
Message-ID: <p75r0t$bv3$***@serpens.de>

| ***@munnari.OZ.AU (Robert Elz) writes:
|
| >Why would a wifi interface be different from any other for this?
|
| Because there is no broadcast.

IPv6 DAD uses multicast (nothing in IPv6 uses broadcast), if WiFi
is unable to do multicast, then it cannot implement half of the infrastructure
of IPv6 - and I find that hard to believe. It matters not how the
multicast support is implemented (snooping on IGMP or sending to
all clients or ...) but it has to work somehow.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Robert Elz
IPv6 DAD uses multicast (nothing in IPv6 uses broadcast), if WiFi
is unable to do multicast, then it cannot implement half of the infrastructure
of IPv6 - and I find that hard to believe.

A true WiFi multicast can only work at the lowest common speed of all devices,
it cannot work if devices don't have a common speed at all.

That's why multicast is mostly implemented by sending a packet to the access
point which then unicasts the data to each device individually. In that
specific environment it's much faster and occupies less 'air time' than
other solutions.

So, multicasting IP works fine. But you receive the replicated transmissions
from the access point, even when you are the original sender. With standard
DAD it's impossible to distinguish your DAD probes from other devices' DAD
probes, as everything is received from the access point (or even other
access points in case of roaming).

The topic is somewhat discussed in RFC 4862 Appendix A.

Standard DAD works on the IP layer, by merging in WiFi-specific information
(origin mac address) you could resolve the issue for WiFi, but maybe not for
other media.

A generic solution would be a nonce that is sent with a probe to detect the
looped back packet by checking its payload.

AFAIK, there were drafts about such extensions, but nothing standard.

There is also RFC4429 (I don't think we implement it) which would speed
up regular DAD but which would also need to be adapted to such special
WiFi extensions.

[Thor Lancelot Simon]

Post by Michael van Elst
That's why multicast is mostly implemented by sending a packet to the access
point which then unicasts the data to each device individually. In that
specific environment it's much faster and occupies less 'air time' than
other solutions.

Unicast at the link layer, sure, but the AP should not be inserting its own
MAC address into the packet -- it should unicast-forward the packet but
leave the original sender's MAC address alone.

Mine _appears_ to do this, if tcpdump can be trusted. But it's a moderately
expensive Cisco enterprise AP. Do others not?

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

I don't know much about the subject, but I just asked a friend who
definitively should -- he desings network hardware, including Access Points.

Post by Michael van Elst
That's why multicast is mostly implemented by sending a packet to the access
point which then unicasts the data to each device individually. In that
specific environment it's much faster and occupies less 'air time' than
other solutions.

According to my friend, this multicast-to-unicast conversion is optional.
This may explain some people noticing the problems and others not.

Post by Michael van Elst
So, multicasting IP works fine. But you receive the replicated transmissions
from the access point, even when you are the original sender.

But my expert also doubts that the AP normally unicasts the converted
multicast back to the original sender.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Thor Lancelot Simon
Unicast at the link layer, sure, but the AP should not be inserting its own
MAC address into the packet -- it should unicast-forward the packet but
leave the original sender's MAC address alone.
Mine _appears_ to do this, if tcpdump can be trusted. But it's a moderately
expensive Cisco enterprise AP. Do others not?

I don't see where on the way to nd6_dad_na_input() we check for the sender
mac and would filter out our own.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Martin Husemann

Post by Thor Lancelot Simon
Unicast at the link layer, sure, but the AP should not be inserting its own
MAC address into the packet -- it should unicast-forward the packet but
leave the original sender's MAC address alone.
Mine _appears_ to do this, if tcpdump can be trusted. But it's a moderately
expensive Cisco enterprise AP. Do others not?

I don't see where on the way to nd6_dad_na_input() we check for the sender
mac and would filter out our own.

Sadly the sender mac is missing from the protocol itself, unlike the ARP
equivalent which makes life harder.
We would need to look at the ethernet frame.

See here:
https://nxr.netbsd.org/xref/src/sys/netinet/if_arp.c#1046

We need a similar check in nd6_na_input().

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Martin Husemann

Post by Thor Lancelot Simon
Unicast at the link layer, sure, but the AP should not be inserting its own
MAC address into the packet -- it should unicast-forward the packet but
leave the original sender's MAC address alone.
Mine _appears_ to do this, if tcpdump can be trusted. But it's a moderately
expensive Cisco enterprise AP. Do others not?

I don't see where on the way to nd6_dad_na_input() we check for the sender
mac and would filter out our own.

It'd be interesting to see if that fixes the reported problems, no?

Unfortunately my laptop was recently stolen so I'm short a NetBSD wireless
client to test with. OS X does not _appear_ to have the reported issue on
my wireless infrastructure, at least, but I am watching the traffic from
a different host on a mirror port on my switch so I can't tell whether
my APs are in fact sending the DAD packets back to the originating wireless
client by unicast or not. :-/

[神明達哉]

At Wed, 28 Feb 2018 13:19:33 -0000 (UTC),

Post by Michael van Elst
A generic solution would be a nonce that is sent with a probe to detect the
looped back packet by checking its payload.
AFAIK, there were drafts about such extensions, but nothing standard.

I guess RFC7527 is what you'd look into.

--
JINMEI, Tatuya

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by 神明達哉
At Wed, 28 Feb 2018 13:19:33 -0000 (UTC),

Post by Michael van Elst
A generic solution would be a nonce that is sent with a probe to detect the
looped back packet by checking its payload.
AFAIK, there were drafts about such extensions, but nothing standard.

I guess RFC7527 is what you'd look into.

Yes, looks like it.


Greetings,

[Roy Marples]

Post by 神明達哉
At Wed, 28 Feb 2018 13:19:33 -0000 (UTC),

Post by Michael van Elst
A generic solution would be a nonce that is sent with a probe to detect the
looped back packet by checking its payload.
AFAIK, there were drafts about such extensions, but nothing standard.

I guess RFC7527 is what you'd look into.

Attached is a patch to add RFC 7527 to the kernel.
It's based on prior work in FreeBSD found here:
https://reviews.freebsd.org/D1835

I've given limited testing, but I've never suffered from looped back NS
probes and not sure how to test forceably test it. Anyone have such a
faulty setup or a way to test?

Roy

[Edgar Fuß]

MH> Right - but on wifi interfaces it usually doesn't work.
KRE> Why would a wifi interface be different from any other for this?
I don't know whether it's relevant in this respect, but Wireless Frames,
as far as I remember, carry three to four MACs, not two.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Robert Elz

Although I've heard stories of duplicate MAC addresses from
unscrupulous vendors before.

I have heard those stories as well, though never actually seen it,
and I am not sure I have ever actually talked to anyone who had
personally seen it either.

I've seen it personally, though not with anything running NetBSD. I
used to work for a provider that, among other things, did Internet
telephony. They sold, among other things, Linksys PAP2s (an ATA - a
device which speaks Internet telephony out one side and POTS,
traditional wired phone service, out the other).

There was one batch for which the MACs on the stickers did not match
the MACs the devices actually used, and one MAC actually used
duplicated the MAC of one we already had. I don't know what happened,
but I speculate that somewhere in the supply chain someone bought from
a graymarket vendor and got devices that either were part of a stolen
and laundered batch or were part of an unauthorized factory run. I
also don't know whether the "bad" MACs were deliberate duplication or
just randomly chosen, though the collision argues for the former.
(But, hm, they used the right vendor portion, so there were only 24
bits available, so the birthday paradox point was 4K devices. I don't
think we had 4K of them, but we had enough that chance is not too
implausible an explanation.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Tue, 27 Feb 2018 22:25:20 -0800
From: John Nemeth <***@cue.bc.ca>
Message-ID: <***@server.cornerstoneservice.ca>

| Is Sun an unscrupulous vendor? Traditionally, all network
| interfaces on a Sun box had the same MAC address.

One could argue that they are the one vendor doing things correctly
(that is, as originally intended.) Of course, in the early days, with
true shared media ethernet, connecting more than one interface to
a single LAN (other than for reduncancy, where having the same
MAC addr is an advantage) was pointless.

The world didn't end up going that way, largely because on (almost)
all other vendors' systems ethernet was an add on, and not a basic
part of the system - the MAC addr had to be delivered with the add
in board, or you wouldn't have one - and so if you were rich enough to
buy two for one system, you ended up with 2 MAC addrs.

And then switches made it sometimes be rational to connect multiple
times to the same LAN.

That isn't the type of thing that was of concern - rather the kind of
vendor who is too cheap to set up a reliable process (or so it is
rumored, any process) for assigning unique MAC addresses at
all - the "accidental duplication" that Gert Doering mentioned in
his message could happen to anyone, and in the overall scheme of
things is really unlikely (not impossible obviously) to actually result
in a duplicate on the same LAN.

The mythical (maybe) unscrupulous vendor is one that was supposed
to assign the same MAC addr to everything shipped (or perhaps a
small range of MAC addrs). Whether there ever was such a vendor
I have no idea.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Robert Elz
The mythical (maybe) unscrupulous vendor is one that was supposed
to assign the same MAC addr to everything shipped (or perhaps a
small range of MAC addrs). Whether there ever was such a vendor
I have no idea.

There are vendors that used other vendor prefixes to avoid applying
(and paying) for their own. Some also use a test prefix that should
never leave the lab/factory.

[Mouse]

[moving from port-amd64 to tech-net]

Does turning off "options INET6" (or INET) not work?

INET6 as a compile time change, yes, of course. [...]
INET, no, too much of the system requires that one to be enabled, if
it even builds without it, I'd be surprised.

I just did some tests with amd64 5.2 - of course, I don't know how much
things may have changed since then. I started with my GEN52 config,
which is 5.2 GENERIC with a few minor config-time tweaks (I can give
full details if you care) and various kernel code changes, I _think_
none of which are relevant here.

I tried three versions of that: one with INET disabled; one with INET6
disabled; one with both INET and INET6 disabled.

With INET disabled and INET6 enabled, as you suspect, it does not work.
I had to disable jme and sl to get it to compile, and it then fails to
link, with various data structures apparently conditional on INET but
used by INET6. I suspect these would be relatively easy to fix (just
INET -> INET|INET6), but I haven't tried it. (I probably will at some
point; IMO a v6-only config should work.)

With INET enabled and INET6 disabled, all I had to do in addition was
disable pseudo-device stf. (Not surprising considering what stf is,
though I think it really should either disable itself or #error in a
config without both INET and INET6.)

With neither INET nor INET6, I had to also disable jme, ipfilter, sl,
tun, stf, and srt, but I then got a kernel that linked. (I haven't
tried booting it.)

[And] certainly INET6 without INET (a v6 only host) has no chance of
working.

Well, as of 5.2, I suspect it would need only a little work. (That's
only a guess, though, of course.)

I really should fix jme - and maybe sl; I forget which version of sl is
in the source tree I was using, but at least one of my sl versions
should be usable in a no-INET no-INET6 kernel.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ruhl]

Post by Robert Elz
Date: Tue, 27 Feb 2018 20:20:16 -0700
| There is DAD which shouldn't happen (but humans can cause it quite
| easily which should be easy to test),
Do you mean DAD (which is the protocol that tests for duplicate
addresses), or duplicate addresses? I suspect the latter.

I was talking about DAD (Duplicate Address Detection) as a positive
result, not as a function. It shouldn't happen in IPv6 for the most
part, but of course if a human is involved and typing in static
addresses, the chances of it happening increase quite a bit.

Post by Robert Elz
| and then there is DAD for a link
| local address which *really* shouldn't happen.
Assuming the 2nd meaning, then that's true of EUI-64 generated
addresses, whatever scope they have. But it is just as easy (or
at least almost as easy) to manually assign a link local address as
any other, and those are just as likely to be duplicates as any other.

Yes, I was implying EUI-64 addresses should never trigger a duplicate
detection based the idea that MAC addresses should be pretty unique.
MIchael van Elst's reply to the amd64 thread explains why DAD can find
a duplicate address on WiFi even if the address is unique, and why it
needs a fix. And we got a test fix from Roy Marples.

Post by Robert Elz
| Although I've heard
| stories of duplicate MAC addresses from unscrupulous vendors before.
I have heard those stories as well, though never actually seen it,
and I am not sure I have ever actually talked to anyone who had
personally seen it either.

Someone at my company shared a story of "engineering" (meaning,
pre-production) adapters from a vendor where a mistake was made and
all ethernet MAC addresses were the same. My response was meant to
point out the possibility of duplicate MACs (since they can be set by
hand) or duplicate hand coded IPv6 addresses is why DAD needs to be
done and needs to be reliable.

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de