SoylentNews is people
SoylentNews
A Swiss VM hosting provider has a technical blog post about how to kill IPv4 completely on FreeBSD. That is to say, turning it completely off, not just preferring IPv6. They then solicit concrete solutions describing, along with a proof of concept, how to turn IPv4 completely off in other operating systems and allowing them to communicate with IPv6 only.
Earlier on SN:
Vint Cerf's Dream Do-Over: 2 Ways He'd Make the Internet Different (2016)
You have IPv6. Turn it on. (2016)
We've Killed IPv4! (2014)
This discussion has been archived.
No new comments can be posted.
Removing IPv4 Completely from FreeBSD and Other Operating Systems
|
Log In/Create an Account
| Top
| 69 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
You will have domestic happiness and faithful friends.
(Score: 2) by EETech1 on Saturday January 19 2019, @10:32AM (5 children)
Are your saying this is "standard practice"
(Score: 4, Informative) by VLM on Saturday January 19 2019, @02:32PM (3 children)
Yes as with many things, that which was intended to be "helpful" sometimes gets perverted into a privacy PITA.
The term you don't know, that google will return a useful explanation of, is EUI-64 address. Its a lame way to turn a 48 bit MAC which is guaranteed unique into a guaranteed unique 64 bit LAN address. Combine that with a link local 64 bit subnet address and you can have IOT type appliances access each other on a non-routable LAN. Your link local EUI-64 address is, plus or minus not much caffeine this morning, your MAC addrs split in half with FFEE inserted in the middle.
Now then combine that with weird stacks and weird apps that don't properly ignore the EUI-64 addrs and report "my ip address is linklocal:mac1:ffee:mac2" to higher level "ISO layer 8+" applications and suddenly you got a privacy leak.
Its "unusual" although perfectly acceptable for ipv4 interfaces to have multiple ipv4 addrs, and "usual" for ipv6 to have multiple and if weird or old or crappy software asks for "the" ip address its quite possible you'll get the ipv6 link local which is essentially your MAC.
The problem isn't located at any specific individual level, although its mostly an application layer problem.
There are even higher level problems in that... knowing your MAC isn't necessarily very useful as a practical attack vector; not exactly mom's maiden name (from FB) plus your SSN (from an infinite number of historical leaks).
As with many standards issues, the classic XKCD about creating more standards infinitely is a problem; ipv6 is VERY old. I remember CGA address generation was proposed as the final solution to this EUI-64 privacy leak about fifteen years ago, or maybe one of a bazillion other standards.
Conceptually EUI-64 is merely a larger version of ipv4 autoconfig (those 169.254/16 addrs you see when your DHCP server is down on a DHCP configured device). Its a typical dumb (or smart????) software dev mistake to "upgrade" from random /16 host addrs to a privacy leaking MAC in the EUI-64 scheme. The problem isn't so much the concept of a EUI-64 as it is the implementation.
(Score: 0) by Anonymous Coward on Saturday January 19 2019, @04:34PM (2 children)
MAC addresses have not been guaranteed unique since Linux let you set them.
(Score: 3, Informative) by RS3 on Saturday January 19 2019, @04:53PM
I remember Ethernet cards in the early '90s that let you set MAC address in the driver. Even if it was set in hardware there are people who can spoof it.
(Score: 2) by VLM on Sunday January 20 2019, @04:10PM
ARP protocol will be unhappy if you set every ethernet card on your lan to 1:2:3:4:5:6, so in the sense that they're unique on a link-local lan that actually works remains correct.
(Score: 2) by rleigh on Saturday January 19 2019, @05:26PM
It is the default behaviour of all modern operating systems, and has been for years. You can disable it if you want the address to be static.