Slashdot Mirror
Statement on IPv6 Privacy Concerns
angio writes "As a followup to the IPv6 privacy concerns
(discussed in
this slashdot news item), the IANA has released a
statement addressing these concerns. Their major point follows
the objections slashdotters raised, that is, that IPv6 does not require
divulging the hadware address. Good to read. "
I think the primary question everyone should be asking themselves is:
Even if IPv6 is as horrible as the most skeptical, paranoid, privacy-centric folks think it must be, how could it possibly be any worse than IPv4?
The answer is (get ready for this, cause it's a huge surprise): it couldn't be. Under IPv4, it's simple to find out the geographical location of every web surfer as well as what ISP you should contact should they be doing anything bad. If they have a static IP or they have cookies enabled, it's also simple to tell if they come to your site often. All of these can be bypassed (disabling cookies and changing your MAC address), as most of the world is aware.
Even under the guise of part of your IP address being "randomly generated," it's still traceable directly back to your ISP, for all intents and purposes.
In other words, what on earth is anyone worried about? I see comments like "Well, it sounds good, but is it really?" and "Be careful.. 128 bits is a lot of IPs.. the government must be spying on us," (among others which have no real logical basis and leave me wondering why the poster is imparting his lack of knowledge upon us).
For those of you who aren't aware, the IETF is a highly respectable organization. If you can trust them with the responsibility of making every other protocol you touch, then surely this one isn't too much of a leap. The last thing you have to worry about is that they would intentionally deceive you into adopting some sort of covertly anti-privacy concept (don't think for a second I'm asserting that everything that the IETF produces is perfect.. merely that they're honest and have genuinely good-karma-filled intentions).
If somebody can answer this to get it out of the way, I'm just posting it to be thorough and polite:
There is much use of the words "not required." Does this mean that the specs and standards don't require hardware IPv6 addresses to be transmitted, but allow it? Or does it mean that the specs and standards require the system to not require the hardware addresses? Could somebody design or build something to take advantage of hardware addresses, despite the specs and standards?
Somebody's got to ask the stupid questions, for the masses, you know.
-- "So far, I have not found the science" -Soul Coughing
It's almost like the author of this article _actually_reads_ this forum.
I have to say that this is one of the reasons that I like slashdot. It's a meritocracy of ideas, because the people who often best understand a technology are on hand to help explain it to those in another area of expertise. The amount of (unintentional) misinformation floating around here is uncharacteristic of the forum.
Rob, you rock. And if nobody's said that lately, it's never because you've been taken for granted...
Check my Go-related blog for beginners: DGD
i said it before, i'll say it again.
Compliments of the linux.com tuning guide :
On a related note, you can also have your card use a different MAC address
ifconfig eth1 hw ether deadbeef0001
(this needs do be done while the card is down for obvious reasons)
now your card will answer all arp requests with DE:AD:BE:EF:00:01.
Note:
The kernel performs this trick on most cards by setting the card into promiscous mode and using software to filter out all MACs that
aren't yours which stands to reason it would be slightly slower than just using your real MAC.
In other words, if you don't want to use the hardware address option, you can use one of the tried and true methods that have always been used to generate unique IP addresses.
Also as the article pointed out, devices that don't need to be contacted, but just want to spit info out somewhere don't need a stable IP address.
The network number is assigned by the network and is used to route the packet back to you, just as in IPv4.
See RFC2373: IP Version 6 Addressing Architecture as well as Privacy Extensions for Stateless Address Autoconfiguration in IPv6 for more details.
this IETF statement smells a little too much like the kind of letter a telco sends when it's rais^W giving you a discount. the fact that the IETF isn't requiring a unique identifier isn't very comforting: they could just as easily recommend - which goes a long way - that no packets carry a persistent identifier other than an IP address. let vendors and sysadmins build in optional peristent IDs for those who want them or situations where they're needed.
the vast majority of traffic on the net involves this statement's second category, "less trusted targets," and that proportion will only grow over time, to the point where implicitly trusted traffic is a barely expressible nanopercentage. if in fact the IETF is interested in articulating a structure that will reflect those plain facts, then they should skip this kind of condescending "explanation," with it's "there's two situations" stuff, and base their analysis on the actual directions in which the net is developing.
IPv6 offers a chance to develop a protocol that will allow the net to develop into a field for truly open, random, and free social engagement - or to become a tool for systematic surveillance by those in a position to do so. and note well: encouraging persistent, unique IDs will put a lot of people in a position to do so.
we'll see what the IETF decides on this - and on the question of whether "the IETF [should] develop new protocols or modify existing protocols to support mechanisms whose primary purpose is to support wiretapping or other law enforcement activities."
It seems to me that people want both privacy and security . No one can talk to you unless you reveal your address to them. It's that simple. What people really want is anonymity. This can/should only be done through trusted third parties. How many third parties can you trust -- not many if any at all.
In order for there to be security on the internet, we must be able to verify who sent a packet and that requires knowing the address sending it. Which do we want? I vote for security. You can also use tunnels to hide networks (and therefore addresses) behind edge devices like VPNs.
matt
Most of you have no clue what "FUD" means. You just see other people using it and think it's a nifty cool Linux hacker buzz-word that other people don't know. Just because somebody doesn't know that the MAC address can be changed in many ethernet cards doesn't mean he's trying to spread "fear, uncertainty and doubt" about Linux.
Joy, another "Big Brother" reference.
Contrary to what you seem to think, not every Internet host is owned/used by a dialup user. Things like routers, web servers and people that secretly know their IP address isn't being cross-referenced in some database along with their sexual orientation, want and in many cases require their IP address to be static.
Now, to generate these static IP addresses, the IPv6 address specification says that there's this huge link identifier part of the address that conveniently is able to hold a MAC address, thus instantly guaranteeing a unique IP address on the local subnet (where it needs to be unique). No administration headaches involved.
OBVIOUSLY this will not be the best solution for all IPv6 hosts. There are reasons certain IP addresses would need to remain unique, such as in the event of a machine upgrade (swap-out) where the IP address is important (such as a name server).
An "Internet cafe" does not need cryptographically-secure random link ID's for each of its machines. MAC addresses would work perfectly with a minimum of administration.
The people responsible for implementing IPv6 are not idiot buffoons. They tend to be highly educated network and electrical engineers. No offense to you, but I really think they're smart enough to figure out how to implement IPv6 on their own. I sincerely doubt they've all been reading the IPv6 spec and saying to themselves, "well err durrh.. it sez mac address so let's use mac address!" If you're really concerned that vendors are going to implement IPv6 in this fashion, perhaps you should write them a letter and ask them.
If your NIC dies, and you need to put in another one, you're going to need to restart the machine anyways, so the only reason you'd even need the same persistent IP is if the machine itself were a server.
In that case, just manually set up your IP address so that it's the same as the old one. No MAC modifications necessary. Remember: the MAC address suggestion was just meant to be an easy method for obtaining a link identifier that didn't require manual intervention. If your machine is acting as a server, you'd probably want a manually specified IP address regardless.
The kinds of things which IPv6 was created to do can be achieved without referencing any kind of unique number that can be tied to a specific computer. The only way to truly achieve privacy is to make certain that addresses cannot be directly traced back to a host without going through a virtual "paper trail." IPv4 can do this, therefore IPv6 must be able to before it can be trusted as a viable Internet protocol.
In other words, all references to a MAC address need to be removed from the IPv6 standard, at least as pertains to network addressing. This can be done, despite what the IANA would have us believe. Verification of the origin of a packet/message/whatever can also be done without resorting to MAC addresses, so it's still possible to have both privacy and security, without letting Big Brother get in the way.
Given the complexity of IPv6 addresses anyways, DNS will probably play a greater role under IPv6 than IPv4, where static IP's were common. If an IP address changes every few weeks, it's probably a lot easier just to use already standard dynamic DNS to keep track of the new IP address.
So even if your machine *does* act as a server, so long as it isn't a major Internet infrastructure type of thing (such as a name server), so long as the hostname was kept updated with the correct IP you shouldn't really need to worry...
But yah, IPv6 doesn't *remove* administrative options in the least for selecting IP addresses, so you're always free to manually specify an IP if you need to.
While I'm encouraged by IETF's sound technical and privacy statement on MAC addresses in IPv6, there's a second issue that's still open. IMHO the technical and privacy factors are even stronger when it comes to decisions that amount to building a security hole into the system.
If a pro-privacy stand was the right thing for MAC addresses in IPv6, then it's even more so for CALEA and other wiretapping "standards".
IP's are generated EACH AND EVERY TIME you connect to the Internet, move from ISP to ISP, or even if your ISP moves from one ISP to another.
IPv6 IP addresses are STRICTLY transitory. They have NO permanence. They last as long as YOU want. Unlike IPv4's "dynamic allocation", though, the numbers aren't picked out of a preset pool. IPv6 is based on transitions, not permanence.
Oh, and if you piss people off, chances are it's not their fault. Yes, they get to pick their reactions, and if they react badly, that is their problem, but if you act like an idiot, you can't blame that on others, either.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The current situation is this: Any PC running Windows 95/98/NT with the Microsoft network client installed will give it's MAC address out if you query it. Hence the vast majority of all computers on the Internet right now give out the MAC addresses.
See this article for a complete explanation