Slashdot Mirror

You would still have to change out ALL of the hardware in the world and still have to update ALL of the software.

Not true. See RFC1365.

Well RFQ 4941 addresses some of your concerns: http://tools.ietf.org/html/rfc4941

Additionally if you at worried a privacy, then put all web traffic behind a web proxy and filter out certain cookies.

IPv6 most certainly does NAT: http://tools.ietf.org/html/rfc6296

Read his post again:

you can do a network prefix translation thing, which is a bit of a bodge, in the same way that NAT is a bodge.

Then read the title of the RFC you linked to:

IPv6-to-IPv6 Network Prefix Translation

IPv6 most certainly does NAT: http://tools.ietf.org/html/rfc6296

UPNP has any number of serious issues dealing with security so hopefully whatever automated system for IPv6 becomes standardized deals with issues like

host $x is really host $x and not host $y trying to open a port to host $x.
host $g belongs to security group $a with access to features $f while host $h belongs to security group $b and only has the limited features of $b.

There is this, http://tools.ietf.org/html/draft-bnss-v6ops-upnp-01 , but I can't say that I've read it all.

You're talking about RFC 3401, which (if I read it right) randomizes the 64 low bits of the address. DarkOx's point is that ISP's are likely to assign each household a (static, semi-permanent) network with the same 64 high bits. If I'm a web-tracking firm, I'd expect that to be similar to but more reliable than the (temporary, high turnover) IPv4 address that basically identifies a household today.

In cases like these, I feel like whoever is in charge of security over there needs to be held responsible for not following best practices and salting the damn password hashes. This has been security standard since PKCS #5 v2.0 -- and you know security professionals don't publish these standards just for their own health. And this is not a new fangled thing, it was finalized in 2000 12 years ago.

Failure to do so is malpractice ...

You should seriously check RFC 5322 to learn what makes up a valid email address. Especially the local part, since almost any printable character expect "@" is allow there in some way (e.g. !#$%&'*+-/=?^_`{|}~ is allowed without restrictions).

There is nothing more annoying than stupid forms that don't allow typical local address extension characters like '+'. Then again, what you posted looks like a JavaScript function, so it would probably not be such a big hindrance to my NoScript-enabled browser...

Using computer generated RSA/DSA keys is actually a bit less secure than the best option, SRP. I'm not clear on why the Secure Remote Password protocol is not deployed more widely.

Another point is that you can use Google authenticator rather than the SMS garbage. This is much more secure and uses HMAC-Based One-Time Password Algorithm (RFC 4226) and Time-Based One-Time Password Algorithm (RFC 6238). It even has a PAM module that you can use with just about anything that supports PAM, and it has iOS, Android, and Blackberry versions of the client app.

Using computer generated RSA/DSA keys is actually a bit less secure than the best option, SRP. I'm not clear on why the Secure Remote Password protocol is not deployed more widely.

Another point is that you can use Google authenticator rather than the SMS garbage. This is much more secure and uses HMAC-Based One-Time Password Algorithm (RFC 4226) and Time-Based One-Time Password Algorithm (RFC 6238). It even has a PAM module that you can use with just about anything that supports PAM, and it has iOS, Android, and Blackberry versions of the client app.

You mean you want to implement the DANE proposal ?
Well, you just have to wait a bit till NSSEC is widely deployed and the proposal ratified. But the protocols are already on paper.
https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/

you mistake what he's saying - IPv6 has a feature called "Privacy Extensions for Stateless Address Autoconfiguration in IPv6".

This means that your IPv6 address can be randomly generated within your address range handed out by the ISP so that it (to practical purposes) changes all the time. Here's a quick blog entry about it.

Read the first couple of paragraphs here.

So many good comments here - but I still find it disturbing that some people truly believe that the US literally "controls" the Internet, and that having the "control" "turned over" to the UN would be a good thing. However, in reality, the US doesn't "control" the Internet. Yes, the US does "control" ICANN and IANA, but if another country wants to run their own versions of these services, there isn't anything stopping from doing so (other than money and control over their ISPs). That way, they could "control" their own Internet in the same way the United States does. Interoperability could be a challenge if they deviated too far from how things exist today, but my guess is that is something they wouldn't really care about anyway.

What part of the Internet do people really feel like the US "controls"? IETF is somewhat US-oriented, so I guess you could argue that IPv4 and IPv6 (and all other Internet standards) are "controlled" by the US. But, there is still nothing (other than money and control over their ISPs) stopping a country from writing their own protocol stack, then having government backed companies produce the network equipment and software to work with it. Finally, they would be free from the tyranny of the United States!

So far, the worst thing the US Government has done is seize/alter DNS records. Nothing an entry in the ole' hosts file (or alternate DNS service) doesn't fix. Yes, this is dumb, and as a US citizen I feel this is a ridiculous offense against free speech. However, comparatively speaking, what the US is doing is petty. The US version of free speech violation involves whatever the wealthiest corporations tell the government needs to be censored (i.e. RIAA/MPAA sponsored policies to "stop piracy"). Generally speaking, the government doesn't care what I say about it, so long as it isn't extreme enough to get myself labeled as a terrorist. The China/Iran/etc. version of free speech violation involves you going to jail if you say anything negative about the government. India has been struggling to find effective ways to censor their Internet for some time now, and what they are asking for goes far beyond meddling with DNS. Allow the UN to "develop internet policies" and "oversee all internet standards bodies and policy organizations"? Gee, that sounds like a great idea. What could possibly go wrong? Let me get in line to allow the UN to set policies to what I can access and not access on the Internet. While they are at it, they should stop the IETF from publishing RFCs such as 1149 - I'm concerned that could assist with overthrowing a militant regime somewhere.

That sounds way better than what we have today! </sarchasm>

My personal opinion is that India keeps failing to find effective ways to perform the censorship they want to, and this is their way of soliciting external help with "solving" the problem. Maybe someone should put them in touch with China and tell them to leave everyone else out of this. Once the UN solves all of the other world problems, like war, crime, hunger, disease, etc. then they can move on to more minor tasks like this one...

In my mind this and the proliferation of, at best, highly questionable patents is the real problem. I don't see a huge problem with the duration of patents. In part because some really innovative technologies, medications for example, cost billions of dollars to develop and the time to recoup that investment is going to be longer than five years.

Similarly, though, even 20-year patents are devastating in industries that move at a faster pace (e.g., software). 20 years is an eternity in an industry where that same time span could see yourself through multiple major shifts in direction. Just imagine what would have happened if many of the early ITEF RFCs were patent-encumbered.

The duration of copyrights on the other hand are absolutely obscene. Even there five years is really short. I think the danger with such a short term would be that it would empower large corporations to some degree. After all other companies have the resources to go out there and compete head to head even if there is no copyright. The small content creator, without a major corporation behind him, is basically forced to try and compete in a wide open market. My guess is the small creator would just get crushed if anything he made caught the eye of a major company.

I have read where others say that the only copyright duration that makes any sense is the life of the author. I do not know that this always makes sense, but it does seem like a good upper-bound. I would, however, go further and say that copyrights should be non-transferable, and that the most an employment contract should be able to do is require an exclusive license for sale over a limited period. While the company is aiding in the creative process by pumping resources into the author, the idea still comes from the individual.

I think the real problem is that patents and copyrights have been corrupted. Both are good ideas and encourage people to invent and create things.

The problem is that we have no real way to validate this. How do we know both really foster creation? It can be easily proven that invention and creative endeavors existed before copyright and patents, so the burden is in proving that IP laws increase this behavior. But, how do you even test for this? With all the entrenched interests, you sure as hell are not going to get Congress to repeal IP law just to test the hypothesis.

You can even show cases where the opposite is true - where IP law blocks new inventions and/or creative works. But, how does this relate to the supposed incentives? Does it cancel out the benefits? Does it do worse? My gut feeling is that IP law is on the whole more destructive than helpful, but it is no easier (or possible) to prove this position than to prove that IP laws help.

The problem is they've both been corrupted to the benefit of a few entrenched interests. Copyrights in particular bear little resemblance to what they were supposed to be. I mean the whole point of them was to encourage people to create things so that the public domain would be enriched. Now they've become a tool for the virtual destruction of the public domain. Which is clearly not what was intended.

When you introduce big money into anything, expect corruption and perversion of whatever original intent there was.

Real old timers remember back before QR codes and are more likely to suggest something like IPoAC: http://tools.ietf.org/html/rfc1149

Nope haven't read about it. Thing is I'm more interested in using something like it than reading about it. As I said I've been waiting for such tech since the 1990s. And that's like 20 years already.

It wasn't even a great leap back then- quite obvious actually. In the 1990s there was decent progress into brain computer interfaces for animals. Mobile phones were around already, and there were even wearable computers. And the WWW too. Put it all together with a super PDA UI.

So it was the step that we just haven't got around to taking yet.

Of course the problem is, as shown by Apple and Douglas Engelbart, it doesn't pay to be too early. Apple's Newton wasn't a success - the tech and suitable ecosystem (broadband internet) wasn't there yet.

But it is now just so tantalizingly close. I mean "HEY! GET ON WITH IT ALREADY!".

BTW I'm also waiting for this to get done: http://slashdot.org/comments.pl?sid=2845905&cid=39980559

Overall I'm not very impressed with our rate of technological progress. OK Intel and the other CPU/GPU bunch have done their part, but the rest are quite disappointing.

p.s. I even tried to get the IETF and ICANN to reserve a TLD: http://tools.ietf.org/html/draft-yeoh-tldhere-01
Because back then I figured such stuff would one of the building blocks in a suitable ecosystem for wearable computing that would be open, cheap and fairly easy to implement and build on.

So it was rather disappointing and disgusting that the ICANN just kept on with "Yet Another Dot Com Wannabe" and "Yet Another Useless TLD". Yes I did write to them, and no I didn't have a spare 200 kilobux lying around to apply for a TLD (and then give it to the world if successful).

Will this TLD provide a mechanism for filtering out packets with the evil bit set?

IETF

Hey, we can finally get IPv6 adopted everywhere now that the entertainment mafiaas will lobby for every system to have a unique address.

How would privacy extensions - which are enabled by default on recent versions of Windows, OS X, iOS, and some Linux distros - help them track an ephemeral address to a particular system, let alone user?

How would IPv6 help?

...are you going to take the five minutes to code in support for this thirteen-year-old technology? Or do you think âoebugs like thisâ(TM) are acceptable on a purportedly professional-looking website?

That system is a total hack and not a standard.

http://tools.ietf.org/html/rfc4880

The problem with S/MIME is the same one as exists with HTTPS. You're trusting the CAs your vendor tells you to trust (by default -- few people are smart enough to change this), many of whom are not trustworthy, not secure, or can easily be arm-twisted into providing a hostile government with a forged certificate.

That makes no sense. With NAT, you can't reliably tell different computers on the same network apart because once the traffic reaches the internet, it will all have a single source address.

Without NAT, you can tell these devices apart - as long as IPv6 Privacy Extensions for Stateless Autoconfiguration are not in use. This is the default on most modern operating systems intended for use as a client.

This makes it impractical to use IP addresses to opt in and out of filtering, unless some means to ensure that IP addresses are static or at least predictable.

Yet you don't seem to understand privacy extensions, which confound logging by generating lots of useless addresses rather than by trying to hide them all.

I don't see how the same mind that considers NAT broken can formulate this sentence without throttling itself.

Spot on! "IPv6 Support Required for All IP-Capable Nodes" https://tools.ietf.org/html/rfc6540

Yeah they'd like that. They can sell you addresses all over again. And the money ends up helping the guys that publish these "recommendations". Nice little ecosystem.

In the real world if you haven't heard of V6 your email and web still work fine and always will over v4,

I don't think that is right. I tried pouring Exlax on my router and now none of the packets will go. Thank God for my IPoAC backup.

http://tools.ietf.org/html/rfc1475

The strangest RFC I had read in years.

Yet you don't seem to understand privacy extensions, which confound logging by generating lots of useless addresses rather than by trying to hide them all.

NAT breaks stuff. Its benefits are available other ways, so there's no need to put up with its downsides anymore. The world will be better off not having to deal with it everywhere.

Actually the value being widely recommended is a /56. See RFC 6177. That allows the user quite a few subnets, more than most homes and small businesses will likely use. Those with larger requirements should have no problem requesting a larger block.

Spot on! "IPv6 Support Required for All IP-Capable Nodes" https://tools.ietf.org/html/rfc6540

"Not only is this a significant increase in packet overhead, but it is highly likely that some portion will identify a person.
Yes, yes, I know there are lots of things the ISPs _can_ do to under IPv6 preserve anonymity. Most will not"

It isn't the job of the ISP do generate random ipv6 addresses, it is pu to the user:
http://tools.ietf.org/rfc/rfc4941.txt (nearly 5 years old though)

We need a .localhost

You joke, but that domain is actually reserved per RFC 2606. ICANN has no authority to issue it, and the IANA would reject it, even if ICANN attempted to approve it. (The IANA is actually part of ICANN, but only the IANA portion can actual make changes to the root zone. The rest of the organization exists just to create a business model for registrars.)

Already worked out if the abbot is unavailable.

Apple (iOS and OSX), Android, and BlackBerry all support CardDAV. SyncML is dead, not to be missed unless you're using fairly old hardware. For fun I started writing a CardDAV server (so now there are FOSS options written in PHP, Python, and Ruby), but more mature open source projects like Davical, owncloud, and Radicale exist. If you're the sort that likes Zimbra, that does CardDAV too. If you use Exchange, there's always Kerio... and someone's even come up with an adapter for webOS of all things. Looks like Microsoft is the lone holdout.

In contrast the Wikipedia article about SyncML states that interoperability is a big problem. Using SyncML or CardDAV is still bound to be more of a pain than swapping SIM cards, but I'm not sure I see much lost in the de-facto death of SyncML.

Actually though, IPv7 predates IPv6!

The experimental IPv7 protocol was specified in June 1993 in RFC 1475 while IPv6 was specified as in December 1995 as RFC 1883.

Actually though, IPv7 predates IPv6!

The experimental IPv7 protocol was specified in June 1993 in RFC 1475 while IPv6 was specified as in December 1995 as RFC 1883.

And RFCs will even tell you how you should interpret the word should .

And that's ultimately what Chris did: we're now operating on four channels. Well, six, actually -- some of the APs could operate in the 5 GHz spectrum, so rather than leaving them off, they were re-purposed for the equipment that could use them (which offloads all the Macs and iPads from the 2.4 GHz spectrum, bringing the noise floor down). So now, running down one side of the building, we have 1, 5, 9 and 13; and then on the other side, 13, 9, 5, and 1. The APs on the tips of the building (it's shaped like an American football in horizontal cross-section) are on the 5GHz channels 40 and 44. The pattern is reversed for every other floor, to provide as much vertical spacing as possible.

This should help you visualize the layout: http://www.ietf.org/proceedings/83/slides/slides-83-iesg-11-ietf-operations-and-administration-plenary.pdf

Keep in mind also that the APs, when we showed up, were turned up all the way up. Look at the diagrams, and keep in mind that these are small rooms (the building is maybe 150 feet wide along its longer axis), and you begin to see how the deployment failure was pretty complete before we got here.

Of course, we didn't show up with 300 directional antennas to fix the APs themselves. All we could do is change their configuration. The change has been dramatic.

ANA Crowne Plaza Hiroshima Hotel

[...] SPDY insists on SSL secured connections.

Citation Needed.

Certainly the common server-side implementations right now like to use it with encryption, but I can find no mention of that being mandatory in the SPDY IETF draft.

In particular, section 2.1 has all of the following to say about upper-level protocols:

2.1. Session (Connections)
      The SPDY framing layer (or "session") runs atop a reliable transport
      layer such as TCP [RFC0793]. The client is the TCP connection
      initiator. SPDY connections are persistent connections.

SPDY has protocol elements that are only useful when it's wrapped by TLS/SSL, but then you aren't forced to use those on a given connection, either.

Nice straw man. You assumed that an some of the bits of an extended address could be interpreted as a valid address and nasty things would happen. But these nasty things will not happen if an IPv4+ packet with extended addresses is constructed to appear invalid to an unaware network driver. So basically you could have saved typing your last two paragraphs.

Your question of where to put the new addresses bits is constructive. The obsoletestream id option seems like a reasonable candidate, providing additional two octets, enough to supply the world's burgeoning address requirements for quite some time. Not a grandious 128 bits like IPv6, but just a modest expansion to take care of our needs basically for you and me, our kids, and our kids kids. That ought to be enough time to come up with some further *sensible* address expansion scheme.

So the principle is this: two extended address bytes are tucked away in places that will not destroy the internet. Such packets are constructed to appear invalid to unaware applications. If a path exists between a source and a destination both supportting extended addresses then the source and destination can communicate in the extended address space. The new byte goes at the least significant end, not the most significant, so that routing databases do not need to change.

See, it could work, and please aim mud at the argument, not your own straw man.

"All digital communication is inherently recorded, so in some twisted sense it's more like dumpster diving and less like wiretapping to snoop in e-mail."

Not at all. First, it isn't "inherently recorded", any more than your snail mail is "inherently copied" when it is put in a bin at the post office.

Maybe not necessary, but as it has always been implemented, SMTP, IMAP, POP and otherwise, it is stored on each server while they wait to copy it to the next server, and it is stored for a long time on the receiving server waiting for the final (usually human) recipient to acknowledge receipt and request deletion - I have always set my clients to automatically delete received messages after 15 days, during which time, I assume that my ISP is backing the, almost always unencrypted, e-mail up on their disaster recovery system.

To sum it up: there is no real sense in which electronic communications are "inherently recorded" by any middleman, at all, any more than a telephone conversation, unless you count temporary storage, which should be set up as just that... temporary, and wiped when a file is deleted.

Have a look through: RFC5321 and predecessors, those are the rules your e-mail travels under, whether or not they should be amended to ensure privacy is another debate, this is the way things have worked in e-mail for 30 years. Nothing guarantees privacy, an obliquely related quote from the transport standard:

SMTP mail inherently cannot be authenticated, or
integrity checks provided, at the transport level. Real mail
security lies only in end-to-end methods involving the message
bodies, such as those that use digital signatures (see RFC 1847 [43]
and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/
Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]).

Know anybody who uses digital signatures or PGP in regular e-mail conversations? I know exactly one, a geek celebrity who presumably doesn't want people making up quotes attributed to him.

"Similarly for GPS tracking, that's just like old-school tailing a car, but cheaper and more clandestine - what's not to like?"

And this is yet another false argument. GPS tracking is, indeed, inherently worse and more intrusive than an "old-school tail", in several ways. Thankfully the courts, unlike you, have recognized this fact.

If you didn't recognize the sarcasm, I apologize... "What's not to like" comes from the perspective of people who "do" law enforcement, and, thankfully, in January of this year, SCOTUS came out on our side for once.

None of the basic issues have changed. Emails need be no different from telephone conversations. Nor internet sessions. ISPs could (and should) operate like common carriers, such as the old-school telephone companies. That would solve much, right there. Many of these privacy issues would disappear overnight.

Old school telephone lines could be, and were regularly, tapped, with and without warrants - information gained from a warrantless wiretap can not be used to prosecute nor get a warrant, but it certainly did happen. Open and publicly auditable police protection isn't likely to come about any time soon, we certainly have never had it in the past.

E-mail needs to grow up, I use G-mail because it serves my needs, and my needs do not include private e-mail conversation.

What I find horrifying is the security theater that goes around supposedly "sensitive" information handling. Footers on unencrypted e-mails instructing the recipient to de

Not bullshit. A telnet client works best with a telnet server; while you can use it against other servers, it is not ideal. The client interprets certain byte sequences as commands.

Furthermore, I quote the wiki:

a Telnet client application may also be used to establish an interactive raw TCP session, and it is commonly believed that such session which does not use the IAC (\377 character, or 255 in decimal) is functionally identical. This is not the case, however, because there are other network virtual terminal (NVT) rules, such as the requirement for a bare carriage return character (CR, ASCII 13) to be followed by a NULL (ASCII 0) character, that distinguish the telnet protocol from raw TCP sessions.

The wiki lacks citations; I point you to RFC 854 (bottom of page 11).

Thus, the protocol is not plain text. It is very close, close enough that most things should work fine, but if you actually desire the ability to deal with raw TCP streams, you'd be much better off using a tool designed for it. Such as socat or netcat.

The protocol was designed to provide remote access similar to a terminal. As such, it includes escape characters and other terminal-control mechanisms. It was not designed to pass text exactly as entered, or display it exactly as sent. Given the common existence of tools that are, it seems like a poor choice to use the inferior one.

Telnet isn't, it only works "by accident" because the protocol is similar enough to plain text to work sometimes.

Bullshit. It was designed that way. And I can prove it, unlike your assertion.

http://tools.ietf.org/html/rfc15

I just hope that they're RFC 2549 compliant, with (hopefully) an encryption layer along with that.

And finally some, like Skype are simply legacy users that were using this codec before it was open sourced (V7 in this case) and have since actually partially moved away from it (h.264 for HD chat).

Rather than moving away from it, Skype has been adding support for VP8 over the last year:

http://gigaom.com/video/skype-vp8-video-conferencing/
http://blog.webmproject.org/2011/08/one-to-one-vp8-video-calling-now.html

If H.264 Baseline is not offered under a royalty-free licence before the 15th of March 2012, then VP8 will be the required video codec for WebRTC. See the the Video Codec Requirements section of the WebRTC IETF draft: http://tools.ietf.org/html/draft-cbran-rtcweb-codec-01. This is why semiconductor companies are keen to promote their WebM support:

http://www.marketwatch.com/story/verisilicon-releases-new-generation-of-hantro-video-ip-products-to-promote-webm-and-webrtc-2012-02-22

Of course, it's unlikely that H.264 Baseline will be royalty-free before the 15th so VP8 will likely be the required video codec. Still, it could happen and if it does then everyone can implement support for H.264 Baseline in their browsers without issue.

MIME is quite amazing, but some of the RFCs such as RFC 2231 are a real WTF. I took over maintainership of the MIME::tools Perl module and felt murderous sentiments towards the authors of that RFC...

Except I'm right.

http://tools.ietf.org/html/rfc1591
http://en.wikipedia.org/wiki/Top-level_domain#Types_of_TLDs .com doesn't belong to the US any more than .uk or .au

There is a whole RFC on this. Apparently youth has forgotten RFC1178.

tells you how to choose a name for your computer.