What happens to old MAC assignments?

[David Lesher]

I have a Bay Networks power controller. "arp" says it's got a
MAC address of 0:c0:48:26:xx:xx

Of course, Bay is long gone; ISTM it was assimated into what's
now Netgear.

I was suprised that not one of the site doing MAC lookups
knows of that MAC, with or without an added leading 0.

Huh?

[Gordon Henderson]

Post by David Lesher
I have a Bay Networks power controller. "arp" says it's got a
MAC address of 0:c0:48:26:xx:xx
Of course, Bay is long gone; ISTM it was assimated into what's
now Netgear.
I was suprised that not one of the site doing MAC lookups
knows of that MAC, with or without an added leading 0.

Entering it into https://macvendors.com/ gives "BAY TECHNICAL ASSOCIATES",
so that looks OK...

I have a prefix that was obtained (for the company I worked for) back in
1990 or so - it was used for just a handfull of devices out of the wild -
it's still registered with the original name. Maybe there are more than
enough to go around without having to recycle any?

(But then they said that for IPv4, so ...)

-Gordon

[Lawrence D'Oliveiro]

Post by Gordon Henderson
Maybe there are more
than enough to go around without having to recycle any?
(But then they said that for IPv4, so ...)

48 bits is a space about 65,000 times larger than 32 bits.

Those exponents can be tricky to think about ...

[Andy Burns]

Post by David Lesher
I have a Bay Networks power controller. "arp" says it's got a
MAC address of 0:c0:48:26:xx:xx
Of course, Bay is long gone; ISTM it was assimated into what's
now Netgear.
I was suprised that not one of the site doing MAC lookups
knows of that MAC, with or without an added leading 0.

what sites did you try?

Post by David Lesher
Huh?

The wireshark OUI lookup tool knows it
https://www.wireshark.org/tools/oui-lookup.html

00:C0:48 Bay Technical Associates

as does
https://www.macvendorlookup.com/

Company
BAY TECHNICAL ASSOCIATES
Address
200 N. SECOND STREET
BAY ST. LOUIS MS 39520
US
Range
00:C0:48:00:00:00 - 00:C0:48:FF:FF:FF
Type/Database
MA-L | MAC Address Block Large | OUI

[David Lesher]

Post by Andy Burns

Post by David Lesher
I was suprised that not one of the site doing MAC lookups
knows of that MAC, with or without an added leading 0.

what sites did you try?

The first 3 that Mr. DDG suggested.
Glad to hear others do work.

[Marco Moock]

Post by David Lesher
I have a Bay Networks power controller. "arp" says it's got a
MAC address of 0:c0:48:26:xx:xx
Of course, Bay is long gone; ISTM it was assimated into what's
now Netgear.

I heard the rumor that vendors reassign addresses from their own pool
because the amount is not enough.
Address conflicts can occur.
Virtual interfaces also use generated addresses (vendor-bits are often
assigned to the virtualization software like VMware).

People must not assume that a MAC address is really unique.

Post by David Lesher
I was suprised that not one of the site doing MAC lookups
knows of that MAC, with or without an added leading 0.

Ethernet MAC addresses are always 48 bit.

[Lawrence D'Oliveiro]

Post by Marco Moock
I heard the rumor that vendors reassign addresses from their own pool
because the amount is not enough.

I thought the 48-bit MAC address was divided into a 24-bit vendor ID and a
24-bit product serial ID. So if a vendor uses up an entire 2 ** 24 address
allocation, it should be easy enough to get another vendor ID allocated,
since they shouldn’t be in short supply, no?

[Grant Taylor]

Post by Marco Moock
Address conflicts can occur.

Yes they can.

No they SHOULDN'T

Post by Marco Moock
People must not assume that a MAC address is really unique.

People SHOULD be able to assume that the MAC is unique on any given
network segment.

N.B.
- the use of RFC "SHOULD" vs "MUST".
- not all vendors adhere to the standards

Post by Marco Moock
Ethernet MAC addresses are always 48 bit.

The only thing that I think which can claim to be Ethernet that doesn't
use a 48-bit MAC address is 3 Mbps experimental Ethernet which I believe
used 8-bit MAC addresses. I know that Fibre Channel uses different
things. I thought Token Ring used something else, but it seems like it
also uses 48-bit MAC addresses.

[Lawrence D'Oliveiro]

Post by Grant Taylor

Post by Marco Moock
Address conflicts can occur.

Yes they can.
No they SHOULDN'T

Conflicts would have been considered practically impossible, if it weren’t
for practices like MAC randomization.

Looking at it as a birthday-paradox-type problem, there are
281474976710656 different possible MAC addresses. If they were being
picked at random, to get a 0.1% chance of a collision, you would have to
look at about 33 million different network nodes.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
Looking at it as a birthday-paradox-type problem, there are
281474976710656 different possible MAC addresses. If they were being
picked at random, to get a 0.1% chance of a collision, you would have to
look at about 33 million different network nodes.

Belay that. I think there’s a bug in my program.

[Grant Taylor]

Post by Lawrence D'Oliveiro
Belay that. I think there’s a bug in my program.

I've seen plenty of times where appliance manufactures had a bug in
their process wherein they had the same MAC in each and every single
device they produced.

Bugs happen.

Sometimes bugs have really unexpected results in really unexpected ways.

Also, when doing the math, remember it's really only a 24-bit space per
OUI. The OUI tends to be used until it runs out and then a new OUI is
acquired.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro
Looking at it as a birthday-paradox-type problem, there are
281474976710656 different possible MAC addresses. If they were being
picked at random, to get a 0.1% chance of a collision, you would have
to look at about 33 million different network nodes.

Belay that. I think there’s a bug in my program.

Hmm, maybe the answer is about right after all.

Calculating from the other end, if I ask for the odds of a match if I have
33554433 different addresses chosen at random, the probably seems small
(less than 0.001). But if add just one more, for 33554434 addresses, the
probability suddenly shoots to 0.865.

Is that plausible?

[Marco Moock]

Post by Grant Taylor

Post by Marco Moock
Address conflicts can occur.

Yes they can.
No they SHOULDN'T

True, but should doesn't mean they don't accidentally occur. Many
virtual interfaces exist (think about the VLAN interfaces of a router,
4096 can exist, virtual links on a computer etc.).

Post by Grant Taylor

Post by Marco Moock
People must not assume that a MAC address is really unique.

People SHOULD be able to assume that the MAC is unique on any given
network segment.

They can, but cases can exist where accidentally 2 interfaces use the
same MAC, even if that case is seldom.

Post by Grant Taylor
N.B.
- the use of RFC "SHOULD" vs "MUST".
- not all vendors adhere to the standards

In some situations, they can't. Think about virtualization solutions
with hundreds of virtual interfaces.

[Grant Taylor]

Post by Marco Moock
True, but should doesn't mean they don't accidentally occur. Many
virtual interfaces exist (think about the VLAN interfaces of a router,
4096 can exist, virtual links on a computer etc.).

I'm not sure what you're alluding to about VLANs.

If 802.1Q (et al.) VLAN trunking isn't in place, meaning the VLAN is
only in the switch then you have ~46-bits of space for MAC addresses.
Or rather 22-bits for OUI and 24-bits for addresses within OUI.

You sort of loose 2 bits in the OUI space to locally administered and
broadcast vs unicast.

Post by Marco Moock
They can, but cases can exist where accidentally 2 interfaces use
the same MAC, even if that case is seldom.

Yep.

Post by Marco Moock
In some situations, they can't. Think about virtualization solutions
with hundreds of virtual interfaces.

Please elaborate.

VMware has multiple OUIs.

You can use locally administered MACs.

IMHO there's effectively no difference between a VM's MAC and a physical
machine's MAC make up and behavior.

Arguably they MUST be the same make up to be able to interoperate.

[Marco Moock]

Post by Grant Taylor

Post by Marco Moock
In some situations, they can't. Think about virtualization
solutions with hundreds of virtual interfaces.

Please elaborate.
VMware has multiple OUIs.
You can use locally administered MACs.
IMHO there's effectively no difference between a VM's MAC and a
physical machine's MAC make up and behavior.
Arguably they MUST be the same make up to be able to interoperate.

Image 2 virtualization solutions that use locally administered MAC with
the OUI of VMware. There is a probability (even when low) that both
systems generate the same MAC.
In such a case, another MAC can be randomly generated.

[R Daneel Olivaw]

Post by Marco Moock

Post by Grant Taylor

Post by Marco Moock
In some situations, they can't. Think about virtualization
solutions with hundreds of virtual interfaces.

Please elaborate.
VMware has multiple OUIs.
You can use locally administered MACs.
IMHO there's effectively no difference between a VM's MAC and a
physical machine's MAC make up and behavior.
Arguably they MUST be the same make up to be able to interoperate.

Image 2 virtualization solutions that use locally administered MAC with
the OUI of VMware. There is a probability (even when low) that both
systems generate the same MAC.
In such a case, another MAC can be randomly generated.

Back in the late 90's I was the one in charge of a couple of mainframes
in a company network, and the software allowed me to set the MAC
addresses as well as the IP addresses.
In my first failover test (taking one component down, bringing another
up with the same IP address) I realised that all the incoming requests
were preventing the reassignment of the IP address. Reinitialising the
arp table fixed that.
In my second test I started setting the last two bytes of the MAC
address to be the same as the last two of the IP address. Problem solved.

[Lawrence D'Oliveiro]

Post by R Daneel Olivaw
Back in the late 90's I was the one in charge of a couple of mainframes
in a company network, and the software allowed me to set the MAC
addresses as well as the IP addresses.
In my first failover test (taking one component down, bringing another
up with the same IP address) I realised that all the incoming requests
were preventing the reassignment of the IP address. Reinitialising the
arp table fixed that.

Not sure I understand that. Was this the ARP table on the backup machine?
Was the backup machine unable to assume the IP address of the primary
machine until its ARP table was initialized?

Post by R Daneel Olivaw
In my second test I started setting the last two bytes of the MAC
address to be the same as the last two of the IP address. Problem solved.

Yeeuuugghh. Shades of DECnet, which unlike TCP/IP and even humble
AppleTalk, did not have an ARP-type protocol.

[Grant Taylor]

Post by Lawrence D'Oliveiro
Shades of DECnet, which unlike TCP/IP and even humble
AppleTalk, did not have an ARP-type protocol.

DECnet didn't have any need for an ARP like protocol.

DECnet addresses are algorithmically translatable to the MAC address
they are used on.

[Lawrence D'Oliveiro]

Post by Grant Taylor

Shades of DECnet, which unlike TCP/IP and even humble AppleTalk, did
not have an ARP-type protocol.

DECnet didn't have any need for an ARP like protocol.
DECnet addresses are algorithmically translatable to the MAC address
they are used on.

Which was a bloody stupid way to do it.

[Grant Taylor]

Post by Lawrence D'Oliveiro
Which was a bloody stupid way to do it.

I suspect it's a hold over from DECnet Phase I, II, or III which existed
before Ethernet.

[R Daneel Olivaw]

Post by Lawrence D'Oliveiro

Post by R Daneel Olivaw
Back in the late 90's I was the one in charge of a couple of mainframes
in a company network, and the software allowed me to set the MAC
addresses as well as the IP addresses.
In my first failover test (taking one component down, bringing another
up with the same IP address) I realised that all the incoming requests
were preventing the reassignment of the IP address. Reinitialising the
arp table fixed that.

Not sure I understand that. Was this the ARP table on the backup machine?
Was the backup machine unable to assume the IP address of the primary
machine until its ARP table was initialized?

Post by R Daneel Olivaw
In my second test I started setting the last two bytes of the MAC
address to be the same as the last two of the IP address. Problem solved.

Yeeuuugghh. Shades of DECnet, which unlike TCP/IP and even humble
AppleTalk, did not have an ARP-type protocol.

What I remember was that I cleared the ARP table on one machine and then
could access the address I needed from another machine. Maybe I
misunderstood what was going on, but since it worked I did not really care.

[Lars Poulsen]

Post by R Daneel Olivaw

Post by R Daneel Olivaw
In my first failover test (taking one component down, bringing another
up with the same IP address) I realised that all the incoming requests
were preventing the reassignment of the IP address.  Reinitialising the
arp table fixed that.
In my second test I started setting the last two bytes of the MAC
address to be the same as the last two of the IP address.  Problem
solved.

What I remember was that I cleared the ARP table on one machine and then
could access the address I needed from another machine.  Maybe I
misunderstood what was going on, but since it worked I did not really care.

If the two machines have the same IP address but different MAC
addresses, the new machine cannot take over so long as the ARP entry
survives. Old implementations would keep the ARP table entry as long as
it was used. Newer implementations re-arp after half the entry's
lifetime has expired. Been there, done that as the implementor of an
embedded IP stack.

If the new machine has the same MAC address as the old one, old MAC
level routes may survive in one or more switching hubs. Best cure for
that is sending a broadcast from the new location. (Seen as an issue in
a wireless network when a mobile end node moves between access points.)

[R Daneel Olivaw]

Post by Lars Poulsen

Post by R Daneel Olivaw

Post by R Daneel Olivaw
In my first failover test (taking one component down, bringing another
up with the same IP address) I realised that all the incoming requests
were preventing the reassignment of the IP address.  Reinitialising the
arp table fixed that.
In my second test I started setting the last two bytes of the MAC
address to be the same as the last two of the IP address.  Problem
solved.

What I remember was that I cleared the ARP table on one machine and
then could access the address I needed from another machine.  Maybe I
misunderstood what was going on, but since it worked I did not really care.

If the two machines have the same IP address but different MAC
addresses, the new machine cannot take over so long as the ARP entry
survives. Old implementations would keep the ARP table entry as long as
it was used. Newer implementations re-arp after half the entry's
lifetime has expired. Been there, done that as the implementor of an
embedded IP stack.
If the new machine has the same MAC address as the old one, old MAC
level routes may survive in one or more switching hubs. Best cure for
that is sending a broadcast from the new location. (Seen as an issue in
a wireless network when a mobile end node moves between access points.)

I'd guess this as having been around 1997-98, that should qualify as an
"old implementation". Both destinations were on the same switch, things
could have got rather sporty if the switch had gone down.
The addresses were something like 192.168.64.x with a second destination
under 192.168.128.x. The alternative machine had 192.168.64.y and
192.168.128.y under normal circumstances, that allowed me to test the
alternative machine.
Things were a bit more complicated than that, the 64.x and 128.x
addresses normally pointed to one front-end machine, the 64.y and 128.y
to a newer front-end - more modern hardware, but it ran software which
had a couple of bugs initially.
There were some other servers which were on both the 64 and 128
networks, I left their MAC addresses alone.

[Lynn Wheeler]

Post by Lars Poulsen
If the two machines have the same IP address but different MAC
addresses, the new machine cannot take over so long as the ARP entry
survives. Old implementations would keep the ARP table entry as long
as it was used. Newer implementations re-arp after half the entry's
lifetime has expired. Been there, done that as the implementor of an
embedded IP stack.
If the new machine has the same MAC address as the old one, old MAC
level routes may survive in one or more switching hubs. Best cure for
that is sending a broadcast from the new location. (Seen as an issue
in a wireless network when a mobile end node moves between access
points.)

circa 1990, when we were doing IBM's HA/CMP ... and doing IP-address
take-over (as part of failure handling) ... while (BSD) Reno/Tahoe 4.3
TCP/IP stack implementations had ARP-cache time-out, it had special code
that would save the previous MAC&IP address pair (to avoid calling
ARP-cache routine, that special save never timed-out) ... in various
client/server scenarios, some (Reno/Tahoe based TCP/IP) client use was
the same server address and therefor there was (almost) never a call to
the ARP-cache routine. We had to do special hack to do pings to clients
from different IP-address (to force a call to the ARP-cache routine)
... when take-over was involved.

[Ted Nolan <tednolan>]

Post by Grant Taylor

Post by Marco Moock
Address conflicts can occur.

Yes they can.
No they SHOULDN'T

Post by Marco Moock
People must not assume that a MAC address is really unique.

People SHOULD be able to assume that the MAC is unique on any given
network segment.
N.B.
- the use of RFC "SHOULD" vs "MUST".
- not all vendors adhere to the standards

Post by Marco Moock
Ethernet MAC addresses are always 48 bit.

The only thing that I think which can claim to be Ethernet that doesn't
use a 48-bit MAC address is 3 Mbps experimental Ethernet which I believe
used 8-bit MAC addresses. I know that Fibre Channel uses different
things. I thought Token Ring used something else, but it seems like it
also uses 48-bit MAC addresses.

On Suns back in the day, you could set any MAC address you liked
(of course the default was the one in the ROM). This could be handy
for spoofing devices that were gone but still expected at a certain
MAC for whatever reason. You could definitely get yourself in trouble
though, as when we switched out our ISP's router for a Sun IPC, spoofing
the MAC so their net would let it in. (I think we were doing something
with port mapping their box didn't support, but I forget exactly why
we thought it was necessary). Worked fine for months and then they did
some sort of upgrade...

[Bob Eager]

On Suns back in the day, you could set any MAC address you liked (of
course the default was the one in the ROM). This could be handy for
spoofing devices that were gone but still expected at a certain MAC for
whatever reason. You could definitely get yourself in trouble though,
as when we switched out our ISP's router for a Sun IPC, spoofing the MAC
so their net would let it in. (I think we were doing something with
port mapping their box didn't support, but I forget exactly why we
thought it was necessary). Worked fine for months and then they did
some sort of upgrade...

DEC, of course, did the same. The MAC address was a simple expression of a
DECnet address.

[Lawrence D'Oliveiro]

On Suns back in the day, you could set any MAC address you liked (of
course the default was the one in the ROM).

I think every *nix system could do that. We did it on a DEC Alpha. The
FlexLM licence server checked for a MAC address as specified in the
licence file. So when we moved it to a different machine when the old one
broke down, we had to give the new machine the same MAC address as well.
Its IP address was different, but that didn’t matter.

[Grant Taylor]

Post by Ted Nolan <tednolan>
On Suns back in the day, you could set any MAC address you liked
(of course the default was the one in the ROM).

Many ~> most routers / systems provide a way to change MAC addresses.

Aside: I believe Sun was a bit weird in that the MAC was set at the
system level. You'd have the same MAC address on all NICs in the
system. At least at one point in time.

Post by Ted Nolan <tednolan>
This could be handy for spoofing devices that were gone but still
expected at a certain MAC for whatever reason.

Yep. So handy that most SOHO routers now have that feature called "MAC
cloning". E.g. change the router's outside MAC to match the station
that you're managing the router from. Or even key in a different MAC
address as you see fit.

[Marco Moock]

Post by Grant Taylor
Aside: I believe Sun was a bit weird in that the MAC was set at the
system level. You'd have the same MAC address on all NICs in the
system. At least at one point in time.

Dangerous. What happened when those NICs were used for bonding?

[Grant Taylor]

Post by Marco Moock
Dangerous.

Agreed.

Post by Marco Moock
What happened when those NICs were used for bonding?

I believe this harks back to a time before bonding was a thing on Sun.

[Lawrence D'Oliveiro]

Post by Grant Taylor
Aside: I believe Sun was a bit weird in that the MAC was set at the
system level. You'd have the same MAC address on all NICs in the
system. At least at one point in time.

Sounds like a pretty dumb decision, for the company which was so fond of
proclaiming “the network is the computer”.

[Scott Lurndal]

Post by Grant Taylor

Post by Marco Moock
Address conflicts can occur.

Yes they can.
No they SHOULDN'T

Post by Marco Moock
People must not assume that a MAC address is really unique.

People SHOULD be able to assume that the MAC is unique on any given
network segment.
N.B.
- the use of RFC "SHOULD" vs "MUST".
- not all vendors adhere to the standards

Post by Marco Moock
Ethernet MAC addresses are always 48 bit.

The only thing that I think which can claim to be Ethernet that doesn't
use a 48-bit MAC address is 3 Mbps experimental Ethernet which I believe
used 8-bit MAC addresses. I know that Fibre Channel uses different
things. I thought Token Ring used something else, but it seems like it
also uses 48-bit MAC addresses.

Then there is infinband, which prefixes packets with routing headers.

[Grant Taylor]

Post by Scott Lurndal
Then there is infinband, which prefixes packets with routing headers.

Interesting.

Does Infiniband claim to be Ethernet anywhere? ;-)

[Lawrence D'Oliveiro]

Post by Grant Taylor
I thought Token Ring used something else, but it seems like it
also uses 48-bit MAC addresses.

IEEE 802.2 defines the common frame format used by 802.3 (aka Ethernet),
802.4 (Token Bus), 802.5 (Token Ring), 802.11 (aka Wi-Fi) and all the
other 802.x specs. This common spec includes the 48-bit MAC address.

Think of this as splitting Layer 2 into two sublayers: the upper part
(802.2) and the various lower parts (802.x for x > 2).

802.11 further splits this into (currently) several dozen even lower-layer
specs, for all the different versions, encodings, bandwidths and frequency
bands that keep coming out all the time.

[Grant Taylor]

Post by Lawrence D'Oliveiro
IEEE 802.2 defines the common frame format used by 802.3 (aka Ethernet),
802.4 (Token Bus), 802.5 (Token Ring), 802.11 (aka Wi-Fi) and all the
other 802.x specs. This common spec includes the 48-bit MAC address.

Agreed.

But not everything Ethernet uses 802.2 (LLC) framing.

Neither older IPX/SPX nor IP on Ethernet use 802.2 framing.

[Lawrence D'Oliveiro]

Post by Grant Taylor
But not everything Ethernet uses 802.2 (LLC) framing.

I think basically everything uses “Ethernet”, where it disagrees with the
strict 802.2 spec.

[Grant Taylor]

Post by Lawrence D'Oliveiro
I think basically everything uses “Ethernet”, where it disagrees
with the strict 802.2 spec.

Ya. I think most things use what Novell called Ethernet II wherein the
frame length field is larger than 1500 bytes, meaning that it's value
specifies the Ethernet Frame Type.

[Marco Moock]

Post by Grant Taylor
Ya. I think most things use what Novell called Ethernet II wherein
the frame length field is larger than 1500 bytes, meaning that it's
value specifies the Ethernet Frame Type.

Which other standards exist?

Which stuff uses others?
Wireshark can use a display filter like frame.encap_type!=1, but is
there also a capture filter?

[Lawrence D'Oliveiro]

Post by Marco Moock

Post by Grant Taylor
Ya. I think most things use what Novell called Ethernet II wherein the
frame length field is larger than 1500 bytes, meaning that it's value
specifies the Ethernet Frame Type.

Which other standards exist?

“Jumbo frames” come to mind ...

[Grant Taylor]

Post by Marco Moock
Which other standards exist?

Novell 802.3 (raw IEEE 802.3 w/o 802.2 LLC)
Novell 802.2 (IEEE 802.3 w/ 802.2 LLC)
Novell (802.2) SNAP (IEEE 802.3 w/ 802.2 LLC w/ SNAP)

Post by Marco Moock
Which stuff uses others?

It used to be common to run different frame types on different networks.
I've even seen different frame types used on the same network for
various segregation reasons.

Post by Marco Moock
Wireshark can use a display filter like frame.encap_type!=1, but is
there also a capture filter?

I don't know.

[Kurt Weiske]

To: Grant Taylor
-=> Grant Taylor wrote to alt.folklore.computers <=-

GT> But not everything Ethernet uses 802.2 (LLC) framing.

GT> Neither older IPX/SPX nor IP on Ethernet use 802.2 framing.

This brings back bad memories of the '90s, trying to get Novell Netware,
NETBIOS, Apple's file sharing and TCP/IP working on the same wire.

Life is much easier now. :)

kurt weiske | kweiske at realitycheckbbs dot org
| http://realitycheckbbs.org
| 1:218/***@fidonet



--- MultiMail/Win v0.52
--- Synchronet 3.20a-Win32 NewsLink 1.114
* realitycheckBBS - Aptos, CA - telnet://realitycheckbbs.org

[Grant Taylor]

Post by Kurt Weiske
This brings back bad memories of the '90s, trying to get Novell
Netware, NETBIOS, Apple's file sharing and TCP/IP working on the
same wire.

Oh, they would go on the same wire. But there's no guarantee that
systems would respond with any grace seeing something on the wire that
they didn't like. Much less getting them to interoperate in any
meaningful way.

Post by Kurt Weiske
Life is much easier now. :)

If you say so.

Gone are the days of a single protocol network. We're going to have
IPv4 and IPv6 battling it out for quite a while. IPv6 is really struggling.

[Marco Moock]

Post by Grant Taylor
Gone are the days of a single protocol network. We're going to have
IPv4 and IPv6 battling it out for quite a while. IPv6 is really struggling.

IPv6 is growing each year, some governments made it mandatory too.
Just look at the graphs from apnic or Google.

[Ahem A Rivet's Shot]

On Tue, 23 Jul 2024 12:59:06 +0200

Post by Marco Moock

Post by Grant Taylor
Gone are the days of a single protocol network. We're going to have
IPv4 and IPv6 battling it out for quite a while. IPv6 is really struggling.

IPv6 is growing each year, some governments made it mandatory too.
Just look at the graphs from apnic or Google.

The last time I enabled IPv6 on my network (about three years ago)
I found it caused no end of trouble because where both exist an IPv6
connection is preferred but many pages got into a mess because some parts
were only available in IPv4 and that triggered the cross site scripting
defenses and other pages just got slower over IPv6.

There seems to be no compelling reason to enable IPv6 on a home
network and one compelling reason not to.

Currently if the firewall gets turned off on my router the only
external connection is to my router which isn't listening on any sockets
and is connected to a network that cannot be addressed externally (unless
you have a very friendly ISP). Effectively my network drops off the
internet. With IPv6 enabled losing the firewall would result in wide open
access to anything on the LAN with a public IPv6 address - which by default
means everything!

[Marco Moock]

Post by Ahem A Rivet's Shot
The last time I enabled IPv6 on my network (about three years
ago) I found it caused no end of trouble because where both exist an
IPv6 connection is preferred but many pages got into a mess because
some parts were only available in IPv4 and that triggered the cross
site scripting defenses and other pages just got slower over IPv6.

Works fine here and on millions of other machines too, must be a problem
at your machine.

Post by Ahem A Rivet's Shot
Currently if the firewall gets turned off on my router the
only external connection is to my router which isn't listening on any
sockets and is connected to a network that cannot be addressed
externally (unless you have a very friendly ISP). Effectively my
network drops off the internet. With IPv6 enabled losing the firewall
would result in wide open access to anything on the LAN with a public
IPv6 address - which by default means everything!

That's why I have a firewall on each machine and only have the services
running that I want. Even if there is no firewall, there is no security
problem on my machines.

[Ted Nolan <tednolan>]

Post by Marco Moock

Post by Ahem A Rivet's Shot
The last time I enabled IPv6 on my network (about three years
ago) I found it caused no end of trouble because where both exist an
IPv6 connection is preferred but many pages got into a mess because
some parts were only available in IPv4 and that triggered the cross
site scripting defenses and other pages just got slower over IPv6.

Works fine here and on millions of other machines too, must be a problem
at your machine.

Post by Ahem A Rivet's Shot
Currently if the firewall gets turned off on my router the
only external connection is to my router which isn't listening on any
sockets and is connected to a network that cannot be addressed
externally (unless you have a very friendly ISP). Effectively my
network drops off the internet. With IPv6 enabled losing the firewall
would result in wide open access to anything on the LAN with a public
IPv6 address - which by default means everything!

That's why I have a firewall on each machine and only have the services
running that I want. Even if there is no firewall, there is no security
problem on my machines.

I don't recall the exact issue now, but several years ago, I found that
having IPV6 turned on in my AT&T Uverse box (the default) caused a lot
of problems and I had to go in and turn it off.

[Marco Moock]

Post by Ted Nolan <tednolan>
I don't recall the exact issue now, but several years ago, I found
that having IPV6 turned on in my AT&T Uverse box (the default) caused
a lot of problems and I had to go in and turn it off.

You should find out the exact reason, so it can be fixed.
At&T customers run IPv6 for years on millions of machines, so I don't
assume it is a general issue.

[Lars Poulsen]

Post by Marco Moock

Post by Ted Nolan <tednolan>
I don't recall the exact issue now, but several years ago, I found
that having IPV6 turned on in my AT&T Uverse box (the default) caused
a lot of problems and I had to go in and turn it off.

You should find out the exact reason, so it can be fixed.
At&T customers run IPv6 for years on millions of machines, so I don't
assume it is a general issue.

We do need an easy-read IPv6 implementation guide for home Linux users.

[R Daneel Olivaw]

Post by Lars Poulsen

Post by Marco Moock

Post by Ted Nolan <tednolan>
I don't recall the exact issue now, but several years ago, I found
that having IPV6 turned on in my AT&T Uverse box (the default) caused
a lot of problems and I had to go in and turn it off.

You should find out the exact reason, so it can be fixed.
At&T customers run IPv6 for years on millions of machines, so I don't
assume it is a general issue.

We do need an easy-read IPv6 implementation guide for home Linux users.

The distribution I use (openSUSE) works out of the box, you just have to
specify whether IPv6 is enabled or disabled. My ISP used to support it
but they were taken over by a larger company and they don't. Nowadays I
have IPv6 disabled, pretty annoying.

[Grant Taylor]

Post by Marco Moock
IPv6 is growing each year, some governments made it mandatory too.

Growing, yes. But it's still struggling. Some, if not much, of it's
growth is by coercion.

I've run into some corner cases with IPv6.

Most of them have to do with breakages in IPv6 communications path
across the Internet and / or discrepancies between content on IPv6 and IPv4.

I generally found that IPv6 was faster to use for my use case than IPv4.
At least with my ISP in another state before I moved.

[Andy Burns]

Post by Grant Taylor
But not everything Ethernet uses 802.2 (LLC) framing.
Neither older IPX/SPX nor IP on Ethernet use 802.2 framing.
This brings back bad memories of the '90s, trying to get Novell Netware,
NETBIOS, Apple's file sharing and TCP/IP working on the same wire.

Add FDDI into the mix with a 3COM switch talking to a Cisco running
CatOS for added pain.

Post by Grant Taylor
Life is much easier now. :)

[Lawrence D'Oliveiro]

Post by Kurt Weiske
This brings back bad memories of the '90s, trying to get Novell Netware,
NETBIOS, Apple's file sharing and TCP/IP working on the same wire.

We had AppleTalk and DECnet, as well as TCP/IP gradually spreading at the
time. I think NetWare was confined to one department. It was my job to
make sure the AppleTalk worked: besides the Macs themselves, we had
AlisaTalk (later DEC PathWorks for Mac) running on VAX/VMS, also
communicating via AppleTalk.

In terms of cabling, we had LocalTalk (the Apple network cabling) and
PhoneNet (Farallon’s even cheaper adaptation of LocalTalk to work over
UTP), and then Ethernet gradually coming in everywhere.

[Scott Alfter]

Post by Marco Moock
People must not assume that a MAC address is really unique.

If I'm not mistaken, they only need to be unique within your own network. I
have some gadgets I built where the MAC address is set by the firmware loaded
into the device, so it's on me to make sure they're unique so that they
don't stomp on each other on my network.

[Grant Taylor]

Post by Scott Alfter
If I'm not mistaken, they only need to be unique within your own
network.

Correct!

Both MAC addresses, and IP addresses, are locally significant.

Where locally is usually defined as in the broadcast domain.

Though there are some devices that have bugs when they see the same MAC
address in different VLANs / broadcast domains but on the same
multi-VLAN / multi-broadcast domain device. HP ProCurve 4000M switches
had this problem years ago.

Post by Scott Alfter
I have some gadgets I built where the MAC address is set by the
firmware loaded into the device, so it's on me to make sure they're
unique so that they don't stomp on each other on my network.

}:-)

[Marco Moock]

Post by Scott Alfter

Post by Marco Moock
People must not assume that a MAC address is really unique.

If I'm not mistaken, they only need to be unique within your own
network.

On the same Ethernet link.
But as Grant said, there might be routers and switches that don't like
when a MAC address is the same on another link at the same time.

I suggest making it site-local. :-)

[Grant Taylor]

Post by Marco Moock
I suggest making it site-local. :-)

First: If you have such a router or switch I suggest you replace it
with one that doesn't have such bugs.

Second: I agree with what you said Marco, but think replacing such
buggy equipment is more important as it'll almost certainly have other bugs.

But, if the R.I.T.A. gets up and flies away, then by all means keep
using it.

[David Lesher]

Post by Marco Moock
I heard the rumor that vendors reassign addresses from their own pool
because the amount is not enough.
Address conflicts can occur.

The classic I recall was on Telebit Trailblazers. The production
line was supposed to auto-increment the MAC address being burned
into the board's ROM. But it stuck; all got the same MAC.

This was not noticed until some outlier had two Trailblazers on
the same LAN segment, and obviously, issues arose.

When troubleshooting routing issues, how many compare the MAC addresses??

[Andy Burns]

Post by David Lesher
The classic I recall was on Telebit Trailblazers. The production
line was supposed to auto-increment the MAC address being burned
into the board's ROM. But it stuck; all got the same MAC.

Cheapo NE2000 clones were known for it too.

[Ahem A Rivet's Shot]

On Sun, 21 Jul 2024 16:43:29 +0100

Post by Andy Burns
Cheapo NE2000 clones were known for it too.

I don't think many of those manufacturers bothered to register.

[Grant Taylor]

Post by David Lesher
When troubleshooting routing issues, how many compare the MAC addresses??

I do as a second pass when all the obvious / simple things don't point
to a problem.

Sometimes I'll check the MAC addresses as part of the first pass,
especially if others have done a first pass and are escalating to me.

I recently compared MAC addresses for devices on separate subnets, the
first 10 digits of the gateway MAC addresses were the same, the last to
were "BE" on one and "C0" on the other, a natural progression two
interfaces away in a multi-interface router / firewall.

[Dennis Boone]

Post by David Lesher
The classic I recall was on Telebit Trailblazers. The production
line was supposed to auto-increment the MAC address being burned
into the board's ROM. But it stuck; all got the same MAC.

Er, Netblazers? Don't think Trailblazers had mac addresses.

De

[David Lesher]

Post by Dennis Boone

Post by David Lesher
The classic I recall was on Telebit Trailblazers. The production
line was supposed to auto-increment the MAC address being burned
into the board's ROM. But it stuck; all got the same MAC.

Er, Netblazers? Don't think Trailblazers had mac addresses.

Could be, my memory lacks parity.

[John Levine]

Post by Dennis Boone

Post by David Lesher
The classic I recall was on Telebit Trailblazers. The production
line was supposed to auto-increment the MAC address being burned
into the board's ROM. But it stuck; all got the same MAC.

Er, Netblazers? Don't think Trailblazers had mac addresses.

The Trailblazer was a dialup modem. I had the ISA card version from
which I carefully unsoldered the UART and replaced it with a socket
in which I put a 16550 UART which had a FIFO that made things run
a lot smoother. No MAC, though.

The Netblazer did have an Ethernet interface. Never used one so
I couldn't tell you if the MAC addresses were oddly repetitive.

[Kurt Weiske]

To: John Levine
-=> John Levine wrote to alt.folklore.computers <=-

JL> The Trailblazer was a dialup modem. I had the ISA card version from
JL> which I carefully unsoldered the UART and replaced it with a socket
JL> in which I put a 16550 UART which had a FIFO that made things run
JL> a lot smoother. No MAC, though.

That was a bold move! Most of my attempts at soldering hobby computers
resulted in non-functional high-tech wall art.

kurt weiske | kweiske at realitycheckbbs dot org
| http://realitycheckbbs.org
| 1:218/***@fidonet





--- MultiMail/Win v0.52
--- Synchronet 3.20a-Win32 NewsLink 1.114
* realitycheckBBS - Aptos, CA - telnet://realitycheckbbs.org

[John Levine]

Post by Kurt Weiske
To: John Levine
-=> John Levine wrote to alt.folklore.computers <=-
JL> The Trailblazer was a dialup modem. I had the ISA card version from
JL> which I carefully unsoldered the UART and replaced it with a socket
JL> in which I put a 16550 UART which had a FIFO that made things run
JL> a lot smoother. No MAC, though.
That was a bold move! Most of my attempts at soldering hobby computers
resulted in non-functional high-tech wall art.

That's why I took out the old chip and put in a socket -- if I damaged the
old chip I didn't care, and the socket isn't as heat sensitive as a chip.

Also, it was a fairly low density board which helped not melt nearby chips.

[Marco Moock]

Post by David Lesher
When troubleshooting routing issues, how many compare the MAC
addresses??

I check for NDP and if they use EUI64, DUD will fail.

[Dennis Boone]

Post by David Lesher
I have a Bay Networks power controller. "arp" says it's got a
MAC address of 0:c0:48:26:xx:xx
Of course, Bay is long gone; ISTM it was assimated into what's
now Netgear.

The registry doesn't really have any way to know what's still in use,
so they can't really know what's safe to recycle.

Full registry list here:

https://standards-oui.ieee.org/oui/oui.txt

De

[Lawrence D'Oliveiro]

Post by Dennis Boone
The registry doesn't really have any way to know what's still in use,
so they can't really know what's safe to recycle.
https://standards-oui.ieee.org/oui/oui.txt

So, no list of “non-operational nets” (non.txt)?

[Dennis Boone]

Post by Lawrence D'Oliveiro
So, no list of “non-operational nets” (non.txt)?

D'oh!

De

[Grant Taylor]

Post by Dennis Boone
The registry doesn't really have any way to know what's still in use,
so they can't really know what's safe to recycle.

Yep.

Post by Dennis Boone
https://standards-oui.ieee.org/oui/oui.txt

I make EXTENSIVE use of that file.

I have a couple of scripts to make doing so a lot easier.

- oui.fetch will download a new copy of the file
- ouilookup will normalize a provided OUI and look it up in the list.

cat oui.fetch
#!/bin/bash
curl https://standards-oui.ieee.org/oui/oui.txt -o ~/Documents/oui.txt

cat ouilookup
#!/usr/bin/env bash
OUI=${1//[GHIJKLMNOPQRSTUVWXYZghijklmnopqrstuvwxyz_:-]/}
OUI=${***@U}
awk -F\ '($1=="'${OUI}' (base 16)"){print $3}' Documents/oui.txt
case ${OUI:1:1} in
1|3|5|7|9|B|D|F)
echo "Multicast"
;;
2|3|6|7|A|B|E|F)
echo "Locally administered"
;;
esac

N.B. the awk like uses spaces to match the oui.txt file. The case
intentions are tabs for preference.

[Bud Frede]

Post by David Lesher
I have a Bay Networks power controller. "arp" says it's got a
MAC address of 0:c0:48:26:xx:xx

I haven't seen any Bay Networks gear since Macy bought a bunch of used
Bay switches. So 20 or more years ago? :-)

[David Lesher]

Post by Bud Frede

Post by David Lesher
I have a Bay Networks power controller. "arp" says it's got a
MAC address of 0:c0:48:26:xx:xx

I haven't seen any Bay Networks gear since Macy bought a bunch of used
Bay switches. So 20 or more years ago? :-)

I've installed it and we are using it. You use telnet to talk to it.