Slashdot Mirror

RFC 2549 combined with this routing upgrade should finally get me an Internet connection that is faster and more reliable than Comcast Cable! Granted that this isn't exactly a very high standard, but it's a start!

So, when will I be able to sign up for IPOP in my area (IP Over Pidgeon)?

RFC 1149 already documents how IP can be implemented with high latency low reliability environments. You don't really need to be re-inventing the wheel. Although I'll admit, a spacegoing pigeon would present an engineering challenge, so you might just want to stick with something a little more conventional like radio. But you can probably adapt the latency part...

I'll be keeping an eye on this to see how they address these sorts of issues. Also, does this not relate to RFC 1149? Certainly the latency issue is common.

I guess IP over carrier pigeon would be out.

Does anyone offer authenticated or encrypted DNS? Seems like this would prevent attempts at DNS redirection.

Also, what happens to spam blacklist checks that use DNS lookups when your ISP starts redirecting DNS requests?

REFERENCES

Security Issues in DNS
http://en.wikipedia.org/wiki/Domain_name_system#Se curity_issues_in_DNS

DNSSEC (Domain Name System Security Extensions)
http://en.wikipedia.org/wiki/DNSSEC

Secret Key Transaction Authentication for DNS (TSIG)
http://tools.ietf.org/html/rfc2845

TSIG (Transaction SIGnature)
http://en.wikipedia.org/wiki/TSIG

Yes, this could really be a pandemic for all those of us currently connected to the internet only by IP over Avian Carriers.

proprietary "VPN through Internet Explorer" solution

Most likely Citrix Access Gateway, I have seen it used a lot. Works reasonably well, few bugs though and no security certifications.

In either case, PPTP is a routing protocol,

Nope, PPTP is not a routing protocol. EIGRP and BGP are routing protocols.

PPTP is PPP over a GRE connection with a control session for GRE on TCP 1723.
and despite pulling the wool over your eyes, you do NOT have an IP on the system physical subnet.
 
  Got a link on this one? There is no reason you can't give out an IP address from a PPTP server which is on the same subnet as the ethernet card of the PPTP server.

Broadcasts such as NetBIOS and mdns do not cross subnet barriers.

Broadcast? No, ARP? Yes.

ARP does work across a PPP link, so you might find that a customer is using ARP for name resolution. That really wouldn't be the brightest move as far as I was concerned, but it's a possibility.

The other alternative is that as people connect into their PPTP servers, they are given WINS server settings which will assist in them being able to see a browse list

Name resolution doesn't get you network neighborhood population.

Actually if it's WINS, it will do it nicely.

She was using a Firebox firewall to do the pptp vpn, and apparently you can't push the search parameter. yay

My guess here is that you are talking about sending multiple DNS server suffixes through DHCP.

The intention to do this really hasn't been picked up by too many people. It was first discussed in RFC 3397 but Microsoft hasn't implemented it yet, Apple might have for zeroconf and ISC has done so for DHCPd.

My personal opinion here is that you need to learn a bit more about how windows name resolution works (The old way, before AD) as you seem a bit confused.

For future reference, even though I would consider it dilapidated, WINS does do the job of allowing machines to discover other machines across subnets quite well.

The other suggestion I would have had would have been to just provide a link on the desktop to the NAS so that way DNS is involved only, and nothing more. Either that or just mount up the required shares and close the call

Berny

Apple sells overpriced plastic boxes with lock-in that is done in such a way that it somehow doesn't grab the attention of the clueless sheep that use it.

And then there are the butt-reaming assholes who have the arrogance to think that people who choose to buy certain computers are clueless sheep merely by virtue of that choice.

As much as this pains me to say to a fellow Bill Hicks fan: blow it out your ass. I'm not locked into dick with a Mac. My mouse is Logitech. About a year ago I bought new memory -- standard, off-the-shelf DDR2 SDRAM from Crucial, not Apple. Bought a new HD last month, too. Got it at Fry's for $80. Plugged it in, worked.

Software wise? My IM client is OSS (Adium), browser is Firefox, I use Chicken of the VNC to control it remotely. My text editor is vim. My shell is bash underneath GNU Screen.

The photos I import into iPhoto are JPGs. The movies I work on in iMovie can be exported as .movs and from there converted to anything else. I import my music as 192bit MP3s. iCal uses the open iCalendar format for storing its data. The piss-poor music I attempt to make in GarageBand can be exported as MP3s.

So where am I locked in, either hardware or software wise? I can't buy my own motherboard? I don't zero interest in dicking with hardware and never have, so BFD. You're forced to buy OS X when you get one? I like OS X. It's a great OS: powerful, secure, well-designed, and has great frameworks backing it up. No problem there, either.

So tell me: where in all of this is the either cluelessness or lock-in? I thought long and hard before making the switch, and did so for numerous well thought-out reasons, because it's a significant purchase.

The reason why you think this is broken is because you don't know how the back button works. Seriously. Read the specification http://www.ietf.org/rfc/rfc2616.txt. The back button wasn't designed to provide a transparent view of the current system state. It was designed to allow the user to view what they have previously viewed.

The "design" of the back button in rfc2616 are recommendations, not requirements. Please refer to the meanings of MUST, SHOULD, MAY in http://www.ietf.org/rfc/rfc2119.txt.

The reason why you think this is broken is because you don't know how the back button works. Seriously. Read the specification http://www.ietf.org/rfc/rfc2616.txt. The back button wasn't designed to provide a transparent view of the current system state. It was designed to allow the user to view what they have previously viewed.

The "design" of the back button in rfc2616 are recommendations, not requirements. Please refer to the meanings of MUST, SHOULD, MAY in http://www.ietf.org/rfc/rfc2119.txt.

You obviously know fuck-all about web programming.

That's hilarious. I've been doing it professionally since the 90s.

Everything done to make dynamic web applications is a clumsy, tacked-on workaround to get around the built-in, inherent static document metaphor in all HTML browsers.

That's a matter of opinion. Certainly there are some things that are clumsy workarounds. But that doesn't mean that every browser advancement in the past fifteen years is a clumsy workaround. Stating that "it's not part of the original design therefore it's bad" is monumentally stupid.

Take the back button. It FUNDAMENTALLY ASSUMES STATIC DOCUMENT NAVIGATION.

No it doesn't. It assumes that the user transitions from one place to another. There's nothing about that which says that documents must be static.

Guess what, this breaks dynamic page navigation because whatever is in your browser cache could be outdated system state.

Now who knows fuck all about web programming? The reason why you think this is broken is because you don't know how the back button works. Seriously. Read the specification. The back button wasn't designed to provide a transparent view of the current system state. It was designed to allow the user to view what they have previously viewed.

If you're trying to fudge the back button to provide an up-to-date view, you are trying to do the opposite of what the back button was designed to do. You are taking a user interface feature designed to show the past and trying to make it show the current.

If you want to ensure that an app works without javascript, you are stuck making concessions in your visible page design.

Please learn JavaScript from something better than the average "in 21 days" book. This is simply not true.

You can't submit a form to a different location without javascript

Different to what? Some of your rant simply doesn't make sense because you are missing bits out. I obviously touched a nerve somewhere, but you can't expect me to address all of your points unless you remain coherent.

A hash function based on a mathematical problem doesn't provide enough muddle to use here.

How about the Blum Blum Shub Sequence Generator? (see 6.3.2 in RFC 1750)

It apparantly can be used for cryptographic tasks but has the same factoring 'flaw' and size issues as SDLH. Your thoughts if any about this?

Thanks for your long reply to my earlier post, it was very informative. :)

It all sounds like the evil flag to me.

I thought I was for an optional .xxx domain, but after reading the article, and especially reading ".sex considered harmful" I chanced my mind. While it is long and technical, the salient points (for me, and regarding host names for web services only) were:

First, due to the availability of redirects and other features, it is impossible to determine whether when I type something in the location bar or click on a link, whether I will end up at a .xxx labeled site. Thus, for an adult who wishes to police himself, the .xxx domain provides little extra protection to avoid seeing objectionable material before the more effective existing content labels show up in the form of huge tits.

Second, there is no security, nor any provision of security for the assignment of domain names to arbitrary IP addresses. In particular, this means that as owner of stuff.xxx I can create an entry for really.bad.stuff.xxx to point to your web server, possibly creating a denial of service attack against you. Likewise a user with a name in a non-adult namespace can reference my adult site, even if I as a responsible webmaster have delegated all adult content to a .xxx TLD.

The second concerns can be largely but not completely handled through HTTP/1.1 virtual hosts, but that requires correct administrative practices on the part of all webmasters, and restraint on the part of content filters to not block any IP address pointed to by a .xxx address. Neither of which seem likely without penalties, and then we are back to the government (or ICANN) deciding what content should be in .xxx.

Content based filtering is a little harder, but I can't imagine it is hard to correctly identify most adult webpages that are not trying to hide. Excluding that, even a HTML attribute would be superior to hijacking internet naming systems which are not really designed to handle that sort of labeling information, and allow people who don't have control over their web server's virtual host configuration to still label their content if they so choose.

That doesnt seem to be the case.

Looking at the RFC for TLS:

http://www.ietf.org/rfc/rfc2246.txt
It seems sha-1 and md5 are the only options for hashes in 1.0.

Not to mention that the vast majority of existing implemtations would not be interoperable, even if it is technically possible to update the protocol to support newer hash algorithms. (there are asn.1 id's allocated, but the fixed sized buffers for the output of various hash functions may be different, etc, so protocol changes seem mandatory)

VRFY. http://www.ietf.org/rfc/rfc2821.txt section 2.5.2. Not supported by all MTAs. It's an address disclosure vulnerability, or so it is claimed. Though there are those of us who'd say that hiding your address is pointless (it only works until it doesn't, which given malware prevalence on computers you don't control (eg: anyone who's legitimately got your address) is in the very near future.

A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level.

I bet the bandwidth costs from attempted email delivery are huge even though there are no MX records and the server doesn't accept SMTP connections. In addition to spam harvesting, people like me have been using xyz@example.com to satisfy email address requirements for years.

That's what the .invalid TLD is for, also defined in RFC 2606.

".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid.

Are they going to use TCP/IP over dolphin carrier?

TCP/IP over Aquatic Mammal carriers, as it is more officially known, is simply an modification of
RFC1149 (A Standard for the Transmission of IP Datagrams on Avian Carriers).

The above spec has been "embraced and extended" for Aquatic Mammal use; (much) larger packet sizes are supported, as well as a separate optional High Frequency Audio command channel, which is sometimes used for Relay transmission of packets, and the possibility of dynamic packet routing..

There are standards that actually work for the kind of censorship you want. PICS is one of them. There is also various filtering software that you can get. None of these require special top-level domains.

There are significant technical and logistical problems with using top-level domains to categorize content the the purpose of censorship. In 2004, the IETF published RFC 3675, which documented some of these problems. I suggest you read it.

But the they were having a hard time keeping packet loss down.

RFC 3675

NO IT DOESN'T. Please at least pretend you've read RFC 3675.

W...T...F...?

If this place were even approximately "News for Nerds", Our Illustrious Editor would have realized that calling TCP Window Scaling "new" rises to the same level as referring to the recently-inaugurated Clinton administration. Literally: RFC 1323 dates to 1992.

I love the scare quotes around "features" at the end of the summary to. God forfend that that evil Micro$oft CORRECTLY implement a TCP standard.

Sigh. Look folks. In this case, MS isn't at fault. It's craptacular consumer-grade network gear which cuts corners on standards compliance. I acknowlege freely that MS is an evil monopolistic corporation bent on world domination, but in this case that's beside the point.

Is that so?

An RFC is a Request For Comments. It's a suggestion that may or may not become standard practice. It's in no way "law". It's up to software writers and administrators whether or not to implement them. Now, you have some choices... my own sendmail server ignores connections from hosts that don't have full compliance with RFC 821, for example. That's basic greylisting. But his suggested RFC has not passed into canon by any stretch.

Linked here

There is absolutely no chance of this becoming an RFC. It's utterly facile.

Since date and time information isn't included in TCP/IP packets

reminds me of the evil bit.

http://www.ietf.org/rfc/rfc3514.txt

This relies on the people making links to use the NSFW tag or the guys making content to use it. Frankly, I don't see it ever being used properly.

There's plenty of places where NSFW is specified in link text already. This is just a way of making it machine-readable.

how about a universal close tag for the last opened tag

Such shortcuts have already existed since HTML 2. These have been universally ignored by browser developers.

This sounds like an idea from the same guy(s) that gave us the Evil Bit.

Personally I'd miss the formatting features of HTML. Bold, Italic, etc. I'm a little surprised there hasn't been a middle ground estbalished at some point. You know... pretty text, no exploits.

Blanket blocking of connections on port 25 is excessive -- some people have a legitimate need to drop mail on smarthosts outside the local subnet.

As one of those people, I'm happy using the designated port - 587. See RFC 2476. There's no problem with a blanket block of connections to port 25.

I think the pigeon part of the email was first used as a joke regarding the university network (i.e. IP over Pigeon http://www.ietf.org/rfc/rfc1149.txt). Then the Attrition guys, realizing how technically ignorant Shriber was decided to play the pigeon thing a little longer and used it as a way to identify the "customer".

Remember, every IMAP connection performs a linear traversal of that spool file to extract new mail headers. That's the real problem, and it can't be solved with cheap commodity hardware.

But it can be solved with cheap commodity software. This is why IMAP has had UIDs in the spec since at least RFC 2060. The only case I'm aware of in which the entire mailbox still must be traversed (flag synchronization) will be solved when RFC 4551 is implemented on both the client and server side.

If you're thinking of something else, could you please give details?

Remember, every IMAP connection performs a linear traversal of that spool file to extract new mail headers. That's the real problem, and it can't be solved with cheap commodity hardware.

But it can be solved with cheap commodity software. This is why IMAP has had UIDs in the spec since at least RFC 2060. The only case I'm aware of in which the entire mailbox still must be traversed (flag synchronization) will be solved when RFC 4551 is implemented on both the client and server side.

If you're thinking of something else, could you please give details?

You just have to wait until those kids parents put their new government sponsored laptops on ebay.

I hate to praise IE but IE has a way to only load certains stylesheets for IE or even certain versions of IE. It'd be nice to see that built into the standard so it'd be easier to make minor tweaks for individual cases.

Delivering differentiated content to work around buggy user-agents is a function of the transport protocol, not something you want to replicate for each and every file format delivered over that protocol. It is built into the standard - the right standard for this, HTTP. I quote from RFC 2616:

The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations.

Of course, it isn't reliable, but that's because of abuse from both web developers and browser developers. It's only in the face of this abuse that stupid workarounds in particular file formats is necessary.

Heck, I like to switch stylesheets based on window size even so why not make that possible also without resorting to Javascript

That's already possible with CSS 3 Media Queries, already implemented by Opera.

We might need another bit to implement this on IP level.. http://www.ietf.org/rfc/rfc3514.txt

See: http://www.ietf.org/internet-drafts/draft-ietf-beh ave-nat-udp-08.txt for a taxonomy of the ways NATs behave. The method described in the article won't work for all kinds of NATs.

As other have already pointed out, this a very common technique. It is slowly being adopted as a standard in the VoIP and P2P world (Google Voice uses it, for one). RFC 3489 discusses this very technique, and defines a protocol to be spoken to the central server that is brokering the connection. For a good overview, you could check out the Wikipedia article. There is also a simple, cross-platform and open-source library available that implements the server and client side techniques, making it very easy to integrate this technique into other projects. Nonetheless, the article makes for a nice and simple description of the technique.

I seem to have missed your Networking 101. Maybe that's good, because it seems your Networking 101 has garbled your understanding of layers and abstraction within a protocol stack.

As CTCP is a protocol carried in IP, there should be no impact within the network, as practically nothing does deep introspection of packets other than firewalls (for policy) and end systems (for multiplexing and demultiplexing). Intermediate systems (i.e., IP routers) simply won't care or necessarily even notice that the IP datagrams they're forwarding have something other than TCP or UDP or GRE or UTI or, well, there are a hundred other "layer 4" (transport layer) possibilities counting only those with assigned numbers from IANA. Internet routers examine and forward "layer 3" (network layer) packets.

Your ethernet switches and other varieties of LAN equipment will see frames carrying only one network layer protocol for any of these: IP. These switches examine and forward "layer 2" packets.

AppleTalk, IPX, XNS and so forth are separate network layer protocols ("layer 3") from IP, and it is extremely unlikely that CTCP ("layer 4") will be defined for any of these other than IPv6, and it's unlikely that any of them (possibly including IPv6) will be carried natively (i.e., not tunnelled) across more than the tiniest fraction of wide area networking infrastructure.

Using a single network layer ("layer 3") protocol is operationally easier than using multiple network layer protocols, and operator skill has not scaled nearly as well as either bandwidth or forwarding performance since multiprotocol WANs were common (late 1980s, early 1990s). This is especially true for very large scale networks, like international backbones and national network operators, and even larger regional and metro operators.

The trade-off favouring reduced operator knowledge ("we just move IP very very quickly") at the expense of encapsulation overhead (computation in the end systems, bandwidth everywhere else) has been an economic one, not a technical one. Indeed, many technical people, particularly IPv6 and MPLS proponents, really like the idea of a multiprotocol big-I Internet in order to experiment with possible future network-based services like finer-grained addressability or explicit routing. I am not one of these people, but my objections are almost entirely economic (well, I do think both MPLS and IPv6 are weak and overly conservative hacks at operational problems which unsurprisingly have evolved faster and further than these two protocol suites can reasonably be expected to cope with).

RFC 2001 describes the congestion-avoiding system at the heart of TCP, which is the Internet's dominant bulk transfer protocol. Any other bulk transfer protocol with a similar system to RFC 2001's slow start and congestion avoidance could reasonably say that it is designed for "TCP fairness" in that -- on average -- the occupancy of a pure tail-drop FIFO queue in front of a chronic bottleneck will be inversely proportional to the number of congestion-avoiding flows traversing that bottleneck at the same time.

This sort of fairness is easy to demonstrate both in simulation and live across a WAN or the Internet, and is done regularly, since improving TCP specifically or bulk transfer performance in general is an active area of networking research.

With respect to intermediate systems, their operators generally won't care about well-behaved (in the fairness sense) flows, since they should be nondisruptive and should not require special handling of the IP packets they're carried in.

Badly behaved flows are generally counterproductive. Most "greedy" and "impatient" bulk transfer protocols do not perform well in comparison with TCP, and usually end up generating more traffic and take more time to do the same work. Unfortunately, such flows can also slow down TCP bulk transfers by causing and increasing actual network congestion.

Queueing discip

The factors involved seem to be being present when a photo opportunity happens, recognizing a photo opportunity, having a half-decent camera, and having the skill to produce a well composed photograph (instead of a blurry mess with half a thumb).

Being present is somewhat a matter of luck. However, photojournalists (like other journalists) spend more time than most people in many areas where "newsworthy" (IE: "I can turn that into a story!") events are more frequent. This improves their chances.

Recognizing a photo opportunity is a learned skill. Unsubtle ones like the collapse of the World Trade Center can be recognized by any moron with a pulse and an IQ higher than room temperature. However, such moments may be hard to pick out of the crowd of moments around us, as the current Wikipedia example image for Eisenstaedt suggests. The kiss is one amoung millions, probably even millions that day; but capturing it has elevated it. Would you have stopped and taken the shot, or merely smiled kindly at the happy couple and wandered on past? (I don't think "Get a room!" was a current expression at the time; anyone know?)

The ubiquity of cameras has reduced the importance of merely having a camera on the scene. However, all cameras are not created equal. No matter how lucky you are, you won't get the same quality shots with a keychain toy as with a fully kitted Hasselblad. Professionals put serious money into having the best gear, since they can get a return on the investment (and often a tax write-off). The barrier isn't absolute, since the availability of quality and affordable digital camera gear has gone up over the last couple years; there's a lot of "prosumer" grade cameras about. However, the ubiquitous cell phone camera is a lot closer to my first example for quality.

The last element is skill. With the cost of "developing" digital shots so low, it's a lot cheaper to develop the skill of photo composition than it used to be. However, since developing such skill also takes effort, most people still use a RFC 2795-styled approach, taking shots and picking the best afterwards. While a professional does this too, the expert knowlege they possess means they have a higher starting point, and an easier time finding that one utterly outstanding shot.

As Heinlein observed in Have Spacesuit, Will Travel, "There is no such thing as luck; there is only adequate or inadequate preparation to cope with a statistical universe." I wouldn't be too shocked if an "amateur" ended up with a Pulitzer within the next 20 years, but I don't expect the professional photojournalists to die out any time soon.

I created this small partial map of the Internet from the 2005-01-15 data found here using a slightly different rendering technique than was used to generate the maps there. Each line is drawn between two nodes, representing two IP addresses. The length of the lines are indicative of the delay between those two nodes. This graph represents less than 30% of the Class C networks reachable by the data collection program in early 2005. Lines are color-coded according to their corresponding RFC 1918 allocation as follows:

• Dark blue: net, ca, us
• Green: com, org
• Red: mil, gov, edu
• Yellow: jp, cn, tw, au de
• Magenta: uk, it, pl, fr
• Blue-green: br, kr, nl
• White: unknown

Big BIG HUGE (probably unusable in articles) version can be found at Image:Internet map 4096.png.

The private, nonroutable IP ranges, according to RFC 1918 are:
10.0.0.0 to 10.255.255.255 (10/8 prefix)
172.16.0.0 to 172.31.255.255 (172.16/12 prefix)
192.168.0.0 to 192.168.255.255 (192.168/16 prefix)

I was curious about the "BB&N" who had the 4 and 8 nets (how binary!!). Turns out they're described here
One of their guys wrote "[IEN-74] Sequence Number Arithmetic - William W. Plummer, BB&N Inc, September 1978", which is referenced by [RFC 1982] Serial Number Arithmetic.

I'd argue that there's an organization that has demonstrated how to do 'standards by committee' correctly for decades. You know, the one that defined how computers are supposed to communicate with each other so well that all other competing options (many of them from profit driven companies) have all pretty much dried up and blown away? The organization whose predecessors had as the original design goal of developing a communications network so robust it could survive a nuclear war?

For the young and/or clueless who don't get the reference, I'm talking about the IETF. The IETF isn't even the top level in a chain of committees that have governed how the Internet is designed, just the engineers.

The big problem with standards design by single companies is that almost inevitably they succumb to the desire to create environments where their customers suffer from vendor lock-in. That's why I always treat any standard pushed by a single company with a great deal of suspicion initially. I always wait to see if what might be the hidden agenda.

Cynical? Me? Nahh. I've just worked too long in IT. :)

I belive that as both + and - characters (also used for this sort of thing) are valid in the local part (as per RFC2822) they could equally be used to identify entirely seperate mailboxes, belonging to different users.

It's certainly not unique to GMail, but it seems valid to refer to it as a feature of GMail (as it's certainly not supported by all providers and to knowleage there is no overwhelming school of thought or indeed RFC that says mail servers ought to behave that way).

Personally I prefer the @username.domain.com approach, but YMMV.

No, it's one-time passwords, a concept which has been around for a while. http://en.wikipedia.org/wiki/One-time_password http://tools.ietf.org/html/rfc2289

It's doesn't protect against man-in-the-middle attacks, nor against phishing, but it doesn't claim to authenticate the other end either, so I don't see why you'd expect it to do so. Luckily you can combine one-time passwords with something like SSL, which can provide bi-directional authentication, to mitigate the risks of a MiM attack.

using the Punycode encoding, which recent versions of all major browsers support.

If you want to register an internationalised domain name, just convert it to punycode, register the resulting domain as per usual, and you're set to go.

The major browsers even deal with IDN homograph attacks, by making sure that a url containing characters from different languages will be displayed in raw punycode rather than the internationalised string.

What's more, strings containing things like combining diacriticals and different accented marks need to normalised using the Nameprep algorithm to reduce a string that could be encoded in several different (but visually equal) ways into a single representation.

This system has been in place for a couple of years already, and works fine. No need to go breaking anything.

wikipedia provides a whole host of examples which your browser (if it's recent) should automatically convert to punycode when it makes the request to the page you're after, all the while, displaying the nice internationalised name for you to see.

So, move along people, nothing to see here...