Slashdot Mirror

There is already a RFC defining a protocol for this, no need to reinvent the wheel.

HTCPCP

... because this type of "Linux for the desktop" articles gets posted almost every month. If I could, I would mark all of these articles dupes even across month boundaries.

Let the flames begin, though. I may* come back to read the comments in the coming days.

_________
* The word MAY, as used in this comment, has the same meaning as in RFC 2119.

I was curious enough that I had to look. It looks like its referenced in RFC3696:

http://tools.ietf.org/html/rfc3696#page-5

example.com exists for a reason. Please use it.

A link-local address can allow a computer on a LAN to reach a router. That same link-local address (or another if the router needs to use another interface) can allow that router to reach a router that's Internet-facing and has its own globally-routable IP. Right?

WRT "site-local" vs. "unique-local":
You should double-check the RFC that I linked to... I got the terminology confused, but nothing else.
Also, I read this as saying that unique-local SHOULD NOT, but may be used to bridge multiple "private" networks. (Why else would site-local addresses have a low probability of collision?) ;)

Your claims are a bit inaccurate.

Link local addresses are local to the local network segment. They can't traverse a router at all. Site-local addresses are considered deprecated, replaced by unique local addresses: http://tools.ietf.org/html/rfc4193

Neither site-local nor unique-local addresses should *ever* be routed to the outside world. They're only for use within private networks, like RFC1918 for IPv4.

Although, if you were going to set up an IPv6 NAT (most people would consider this a bad idea), then you would most likely use unique- or site-local addresses on the private side.

"IPv6 is a world without NAT". The hell it is. My internal routers don't get publicly routable IP addresses, even if I have to NAT back to IPv4.

Hi. You're ignorant. Let me educate you.

RFC3513 gives us Link-Local (fe80::/10) IPV6 addresses.
http://tools.ietf.org/html/rfc3513#section-2.5.6
These are addresses that *must not* be routed to the outside world.

RFC4193 gives us Site-Local (fc00::/7) IPV6 addresses.
http://tools.ietf.org/html/rfc4193#section-3
These are addresses that you *may* choose to not route to the outside world.

You don't need NAT. :)

"IPv6 is a world without NAT". The hell it is. My internal routers don't get publicly routable IP addresses, even if I have to NAT back to IPv4.

Hi. You're ignorant. Let me educate you.

RFC3513 gives us Link-Local (fe80::/10) IPV6 addresses.
http://tools.ietf.org/html/rfc3513#section-2.5.6
These are addresses that *must not* be routed to the outside world.

RFC4193 gives us Site-Local (fc00::/7) IPV6 addresses.
http://tools.ietf.org/html/rfc4193#section-3
These are addresses that you *may* choose to not route to the outside world.

You don't need NAT. :)

IPv6 is depressing, because whoever is in charge of it does such a crummy job of explaining what it is and why I should care, and more importantly, why my folks should care.

Actually, I would claim that that's not a big deal. The big problem is that IPv6 just doesn't provide a sensible migration path from IPv4. The idea that we're all going to wake up one day and switch off IPv4 at once just doesn't cut it. More precisely, an IPv4 node just has no way of talking to an IPv6 node. If we built some sort of standardized IPv4-to-IPv6 NAT technology that was invisible to existing IPv4 nodes, then IPv6 could be adopted gradually and incrementally with minimal cost (the cost could be rolled into the cost of general network gear upgrades).

Haven't you heard about Dual-Stack Lite (DS-Lite)? http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00

I thought IPv6 split the network and local address segments right down the middle (i.e. each is 64-bit).

Geez, no wonder adoption of IPv6 is having so much trouble... they don't even include important information such as the size of the network identifier in the IPv6 Addressing RFC (RFC 3513: Internet Protocol Version 6 (IPv6) Addressing Architecture, obsoletes RFC 2373)

RFC 5233 mentions it.

RFC 3972 seems targeted at authentication, not anonymity. For that you would want something more like RFC 3041. But even then that is only for interface anonymity, there is no network/typology anonymity (i.e. they can still track down the network).

IPv6 has a nice little RFC going for it - Cryptographically generated addresses (CGA), defined in RFC 3972. Consider the possibility where every TCP/UDP session, or even every packet, comes from a different address...

IPv6 has a nice little RFC going for it - Cryptographically generated addresses (CGA), defined in RFC 3972. Consider the possibility where every TCP/UDP session, or even every packet, comes from a different address...

The funniest part of your post was using a ip version 4 address in your header but referencing the early days.

Check out RFC 208 to see how addressing was actually done in the old days.

6 bits of IMP (essentially the network address)
2 bits of host

8 bits total.

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

But the parent (who I assume is also my sibling) is more than correct. Many of us post to slashdot anonymously because we refuse to use cookies. Since slashdot uses something non-standard (invented by netscape) intead of the standard way to log in, it is all but impossible for the principled to post on this website with an account.

A lot of people on Slashdot talk the talk about web standards and the importance of adhering to them, but few walk the walk. And by walking the walk, not just talking, we get punished and ridiculed!

The parent is right. Streetviewer is nothing but marketing hype just like Vortals, Portals and e-tailors. The web is for serving hyperlinked text--he is only wrong in one aspect, the images (hopefully PNG) he downloads should be done using SFTP (hopefully using GNUTLS, not the non-free OpenSSL based variants).

If the grandparent really was a true, real nerd, he would be outraged at how badly Google has abused the standards!

[ Warning: I'm only mildly familiar with the technologies mentioned herein, and have worked with them at the technical level very little. Forgive any terminology errors, but please do correct them, as well as misconceptions and mistakes of all kinds; there's no point spreading misinformation about systems that are already very slow to be adopted. ]

That's not entirely true. You *can* use IPv4-only systems to reach IPv6-only systems in some special cases, but it is a kludge... http://en.wikipedia.org/wiki/IPv6_translation_mechanisms and http://tools.ietf.org/html/rfc2767 for more info.

Once all backbone routing and major website servers support IPv6 out-of-the-box, all of the old IPv4-only machines can be NAT'd during the (long, painful) migration period until they are eventually replaced. Sure, NAT makes things more complicated and can be more of a PITA for security and logging, and it arguably breaks DNS in subtle, frustrating ways, but there are already working systems out there.

Everybody with a linksys/dlink/etc gateway to stick multiple PCs on a single outside IPv4 address is already using sophisticated NAT-like mechanisms; when's the last time you had a masquerading problem that couldn't be easily fixed?. Using a hashing algorithm to do IPv4-to-IPv6 NAT actually breaks fewer application-layer protocols, though at the expense of requiring DNS hacks...

1) "Complete security" doesn't exist.
2) I fail to see how that relates to the needless status of the home NAT router. With IPv6, your ISP can give you your very own public IPv4 sized address space, and you only need a switch instead of a NAT router. It is likely that NAT won't die for quite a while though, and even then people may still opt for a stateful hardware firewall, but IPv6 makes them purely optional. See http://www.ietf.org/rfc/rfc4864.txt

why not promote that Outlook-"Please dear mailserver, delete my last email"-Follow-Up (don't know how it's called there) to a real RFC?

Just like the news cancel feature that is disabled in many, if not most, news servers because of improper usage?

"Richard Stallman has published an article which warns about the 'Javascript trap' posed by non-free AJAX-based applications. The article calls for a mechanism which would enable browsers to identify freely-licensed Javascript applications and run modified version thereof. 'It is possible to release a Javascript program as free software,' Stallman writes. 'But even if the program's source is available, there is no easy way to run your modified version instead of the original ... The effect is comparable to tivoization, although not quite so hard to overcome.'"

Mr Stallman, we already have a standard for this.

For your reference, please refer to RFC 3514 and the relevant wikipedia article.

Anyone who says we're running out of IPv4 addresses needs to go back and look at what is actually allocated and what isn't.

Done. Note that we've been averaging between 10 and 15 /8 blocks assigned per year in total space, which using very simply math against a total of 31 means we have a short number of years. If you'd like to see the actual assignment numbers and some more advanced models, go here: http://www.potaroo.net/tools/ipv4/index.html.

With respect to use of the 16 Reserved-for-Future-Use blocks, please review http://tools.ietf.org/html/draft-fuller-240space-02; it is not certain if this space will be made available for public use or for private reserved use.

You've hit the nail on the head. NAT dovetails very nicely with the "castle mentality" many network administrators have: this is mine, and you can't touch it. It's about control, and there are fewer more tangible symbols of control than your own network numbering scheme. Nobody wants to give up that sense of control by moving to IPv6.

But since 2005, you don't have to: IPv6 now has private address ranges just like IPv4's. Also, NAT has always worked with IPv6.

Since 2005, all four combinations of address spaces can work in principle: IPv4 inside, IPv4 outside, IPv6 outside; IPv4 inside; IPv6 outside, IPv4 inside (with DNS proxying), and obviously, IPv6 inside with IPv6 outside.

Whether this "castle mentality" is appropriate is a different debate. Moving to IPv6 for the public internet is too important to get bogged down in talking about NAT.

Try running multiple servers on multiple machines behind the same NAT, where one would like them to be accessible to the outside world via default port numbers.

To be fair, you can use a reverse proxy for this.

*IF* for some reason that didn't involve how many IP's you actually have available, you still wanted to utilize NAT for some reason, you still could do that with ipv6... no problem at all.

You can, but people were told for ages they couldn't. That's actually a big factor opposing IPv6's adoption.

Lots of smart, but idealistic IPv6 designers considered private networks harmful, and wanted to eliminate them from IPv6. They thought that by saying "no, there's no support for private networks, and you don't need them anyway", people would start making addresses public again.

They were right, but saying that wasn't very smart. RFC1918-style networks are safety blankets for network administrators, and when the IPv6 people threatened to take them away, they were terrified. Instead of moving to IPv6 and making their networks publicly-numbered, administrators stayed with IPv4. It's a classic case of perfect being the enemy of good.

Finally, in 2005, the IPv6 people realized the value of pragmatism and set aside reserved addresses with RFC4193. However, the delay and initial opposition to private networking has retarded IPv6 adoption by several years, at least.

Protocols exist (such as SRP, PAKE, EKE, etc) where entering a password not only verifies the user but the server as well, all while never transmitting the password to the server.

If browsers, banks, web servers, etc, were to adopt these then the importance of SSL certificates would diminish as the server would be proving prior knowledge of the user's password as much as the user would be proving knowledge of their password.

In the case of suspecting a banking website of being a forgery, assuming a proper implementation in the browser the user wouldn't need to worry about their password falling into the wrong hands since it would be useless to them unless they already had it.

SRP homepage: http://srp.stanford.edu/
SRP/TLS RFC: http://www.ietf.org/rfc/rfc5054.txt
PAKE: http://en.wikipedia.org/wiki/Password-authenticated_key_agreement

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

So much for RFC 1149 and 2549 ... Guess I need to upgrade then. Now where did I leave that 300bd modem. It should somewhere over ...[CARRIER SHOT]

So much for RFC 1149 and 2549 ... Guess I need to upgrade then. Now where did I leave that 300bd modem. It should somewhere over ...[CARRIER SHOT]

And what about servers using vhosts on a single IP?

More people need to use RFC3546 Server Name Indication for SSL name-based virtual hosting. All major browsers already support it; the only barrier is Apache and OpenSSL. mod_gnutls for Apache, however, works perfectly.

Even in the absence of RFC3546 support, there are several workarounds:

• Your form has to submit a single, non-virtually-hosted URL to work properly anyway. Just put the page that displays the form in this location as well.
• Use a wildcard SSL certificate
• Purchase additional SSL certificates

Frankly, if you're legitimate enough to be accepting sensitive information over SSL, you have the resources to use employ of these options.

Check RFC3986 (Uniform Resource Identifier (URI)):

URI producers should use names that conform to the DNS syntax, even when use of DNS is not immediately apparent, and should limit these names to no more than 255 characters in length.

"mailto:" is not the best way to achieve what you're trying to do. Consider people in internet cafe`s with no access to their email, or a visitor who strictly uses webmail.

Just my 2 cents.

Someone contact your representative and convince them to add an amendment requiring all networking devices to properly set and check the Evil Bit.

If the Evil Bit is not set for a packet, of course, there's no need to log it.

You can set up port 25 SMTP to require authentication for relay purposes, without having to configure end user's machines for another port.

You can set up a MSA (mail submission agent) on port 25, but Verizon users will not be able connect to it after this change. If you run a mail service, the practical effects of this change are (1) you will need to set up port 587 if you have any customers who get transit through Verizon and (2) you will receive less spam.

Verizon wants to stop customers from directly connecting to outside MTAs (mail transfer agents, which run on port 25). This will stop customers from sending spam from Verizon's network.

However, they need to allow customers to send mail to MSAs outside their network or customers will (rightfully) sue them for anticompetitive practices. The solution is to encourage use of a separate port for MSAs, port 587. This is outlined in RFC 2476.

Verizon's making a good move here. It will be a temporary inconvenience to some of their customers who will have to get their outside MSAs to set up the submission port, but that's a pretty small cost for stopping the spam.

Writing a program to act like a mail server for the purpose of sending spam would not be difficult. You wouldn't need to implement any kind of backend just the simple mail transfer protocol. Take a look at the RFCs 821 and 2821. The original RFC is 821. It contains most everything you would need to write a mailer. The actual communication is very simple by design.

And for the record some virus and trojans do implement this.

Writing a program to act like a mail server for the purpose of sending spam would not be difficult. You wouldn't need to implement any kind of backend just the simple mail transfer protocol. Take a look at the RFCs 821 and 2821. The original RFC is 821. It contains most everything you would need to write a mailer. The actual communication is very simple by design.

And for the record some virus and trojans do implement this.

wut

It's all detailed in RFC3514.

W

Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out."

This is just the sort of short-sighted thinking that lead to our recent Y2K hysteria, except this time our poor beleaguered descendents will be in the middle of an exodus from the solar system when all their legacy systems throw simultaneous exceptions. This will of course cause their engine and guidance systems to fail, so that the last dying gasps of humanity will consist of:

[Captain]Captain's log, stardate 1704.4. Ship out of control, spiraling down towards Sol; we have 19 minutes of life left, without engine power or helm control. [Engineer interrupting] I'll be damned. The clocks on every piece of technology in existence have failed because that damned Brit used a 64 bit counter... [Captain]COOOOOOOOOOOOOX!!!"

If only they had followed RFC2550, that would never have happened!

If you're about to join the upcoming avalanche of smartass comments, try reading the UDP-Lite RFC first. For some applications (notably real-time voice and video), timeliness and efficiency are more important than accuracy.

If this means my music player or phone get more battery life, I'm all for it.

Wouldn't it be better to use 0.0.0.0 instead of 127.0.0.1? The latter attempts to connect while the former doesn't bother.

No:

0.0.0.0/8 - Addresses in this block refer to source hosts on "this" network. Address 0.0.0.0/32 may be used as a source address for this host on this network; other addresses within 0.0.0.0/8 may be used to refer to specified hosts on this network [RFC1700, page 4].

While you are correct that using localhost for 'ad diversion' would hit a locally running web server, but at least you'd could have a log of your results. Just thinking of it, but wouldn't it be cool to see your own personal pictures/content instead of ads?

Simple: you implement RFC 3514 on the passports.

they're still around, but as the net moves away from the developer/geek crowd and towards more mainstream market penetration (the tipover point on that could be said to be any time between about 1997 and 2003 I think), then the developer-focused RFCs are more rarely seen or cared about. The leading edge of popular focus internet growth is web2.0, facebook, "the cloud", etc. These are not low-level standards which grow from RFCs.

But do they still exist? Sure, they were published at a rate of one every 3 days in January 2009... (based on an eyeball count of 10 at the end of http://www.ietf.org/iesg/1rfc_index.txt)

Anyone got a graph of RFCs per month?
How about RFCs that are adopted into STD, shown over time? Anyone want to do some datamining?

I highly recommend reading RFC 1178

I'd sooner use RFC1149 to transport my emails.

Regs.

Iain.

Oh, and I notice you conveniently forget to mention that Active Directory is considerably better than LDAP for the majority of installations (the system has considerably more features and administration is easier) and that Microsoft's Kerberos extensions are documented in both RFC 3244 and RFC 4757.

Fucking zealots. Grow up.

Oh, and I notice you conveniently forget to mention that Active Directory is considerably better than LDAP for the majority of installations (the system has considerably more features and administration is easier) and that Microsoft's Kerberos extensions are documented in both RFC 3244 and RFC 4757.

Fucking zealots. Grow up.

dude, if the clear channel communication is the problem, enter 1999: http://www.ietf.org/rfc/rfc2487.txt, the year of STARTTLS on the MTA

I also read SOA as Start of Authority per "M. Lottor, Et Al, DOMAIN OPERATIONS GUIDE, Page 4, http://tools.ietf.org/html/rfc1033#page-4" so was expecting a management and legal perspective on a technical subject.

Where the hell is the IETF in all this, I want to know?

http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-10.txt

Abstract:

The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP and the routing information carried within BGP.

This is called eVLBI, and it is now done routinely to, e.g., determine the Earth's rotation (UT1).

From a networking standpoint, one interesting thing is that eVLBI requires high bandwidth (1 Gbps is typical), but can tolerate fairly high loss rates (because the actual cross correlation coefficients are rarely as high as 10^-3). This makes it an excellent candidate for an Internet scavenger service, where packets are sent at "less than best effort," i.e., with the understanding that they can be dropped if there is any congestion at all, so that eVLBI can use all available bandwidth without choking out other uses. The same technology may prove to be very useful for P2P services.

NFS is 1) a block device

No, it's a Network File System (hint, the initials). NFS supports filesystem primitive operations - see: http://tools.ietf.org/html/rfc1094 Networked block devices are possible, but NFS isn't one of them. However, some of the points are still valid - unix doesn't particularly like it when mounted filesystems go away unexpectedly.

It seems to me that TCP/IP is not the proper protocol for this, something like DTN is far better suited for his connectivity situation, especially since you could theoretically get an international phone service and have most bulk data sent only when you get close enough to port to relay through cell phone services. He could even write up an Email convergence layer if he wanted and theoretically get around the online time limitations (even if, as I suspect, email is only sent in big batches at non-peak times). The downside is that this depends greatly on how the online access is structured in the ship, and doing something like this would be somewhere between difficult and near impossible.

Pigs can fly, as was demonstrated in many cases.
The AF1 has its TV's made in China, silverware from Singapore, switches and tyres made in Taiwan and China.
Hell, even Boeing itself has said many times some of its parts are made in China.
AF1 is as american as the t-shirt which is made in mexico and finished in USA to get the Made in U.S.A label.