911 service. With a traditional POTS phone, it's attached to a physical address. If you need emergency service (fire, police, ambulance), dispatch can have someone on their way to the address attached to your landline phone even if you can't speak for some reason, and before you have an opportunity to describe where you are if you can.

Many places have E911 service for cell callers, and these work in two ways. If your cell phone has a GPS built in, it can send your coordinates to a roughly 10m radius, but without the E911 system uses cell tower triangulation with a resolution of approximately 300m radius. This may not seem like a big problem if you live out in the country, or are stranded at the side of the highway, but what if you're in a situation where you can't speak, and you live in high-density housing? E911 can't tell dispatch or the responders which apartment or suite you live in, and the time it takes to determine that information could mean the difference between life and death. By way of example, if you're alone in a 7th floor apartment in a 10-story building and are choking severely enough to require emergency assistance (in which case, you probably can't speak), which would you prefer to call from -- a landline that gives dispatch your exact building and apartment number, or a cell phone that can only inform dispatch that you're in or around the building? The extra time it would take emergency service to walk around the building and knock on all the doors in an attempt to find you would be the difference between you being found dead on the floor, or alive enough to be revived.

True, these situations don't happen to specific individuals all that often, but it just happens that that one in a million time when it does occur that suddenly becomes the most important thing in your life.

Yaz

Don't misunderstand me -- I'm not claiming that the rates we pay here are the best in the world; only that they're reasonable by Canadian standards. My parents in southern Ontario are paying slightly less than that for less than 10Mbps service, which is criminal. Many places don't even come close to providing 100Mbps service.

Yaz

Things are pretty bad in Ontario, and Bell and Rogers are completely to blame. But get outside Ontario, and things are significantly better in many places.

Here in Victoria, BC, I'm running 100/30Mb through Shaw for fairly reasonable rates (on its own it's about $85/mo, but as we're on a bundle with digital HDTV service we pay less than that -- unfortunately, they don't break it out for the sake of comparison. As I telecommute, I'm fortunate that my employer pays for it anyway), with 500GB of monthly data. They're currently upgrading our area to support 250MB connections, with 1TB of data per month.

Which is WAY better than when I lived in Toronto and was a Rogers customer, or for my family still living in the area (and still using Rogers). They're paying just a little bit less, and aren't even getting 10Mb service. Which, if anything just goes to show that what we should be taking from Roger's paid report here is that other providers outside Roger's coverage area are pulling up the average. Rogers itself still has a lot of work to do to improve their service.

Yaz.

I'll admit up front that the console I'm most familiar with is the PS2, however my understanding is that things haven't really significantly changed in the latest generation of consoles, other than having the built-in software becoming more sophisticated.

Including a "whole OS" with each game isn't anywhere as bad as you think, as the "OS" in this case is really just a few libraries of common routines, consisting of a boot loader, some libraries for dealing with the common hardware bits (memory cards, controllers, etc.), and perhaps a network stack (should the game support some form of online play). The rest is game code. This isn't an uncommon strategy for embedded systems coding where there is no common UI, no multitasking, etc. In effect, the contents of the disc are just a boot loader and everything needed to run the game being played.

The interface you get when not playing games can be thought of something akin to a fancy PC BIOS. It can provide all sorts of functionality, but most/all of it tends to go into "hibernation" when game media is run: it's there in the sense that it's binary data exists in the system as firmware (or for newer consoles on-HDD data files), but isn't typically called when a game form optical media is run.

Downloadable games on the latest generation of consoles may differ in that they may use some form of shared libraries of routines stored on a HDD -- I honestly don't know. But the typical model for optical media based games is that they contain everything they need to run directly on the hardware, and the bits that constitute the "OS" are just a bootloader and some libraries they include to gain access to the bits of common hardware they require, along with some common libraries on top of them, such as the network stack for networked games.

Yaz

iOS does indeed support IPv6.

VoIP is one of the most obvious applications for IPv6.

Modern game consoles aren't that big of a concern, as typically the OS and network protocol stack live on the game media itself, and not on the hardware. Old games won't be magically upgraded to IPv6 support, but then again online support for old games isn't all that reliable anyhow. New games that wish to support IPv6 will simply include the necessary protocol stack drivers on their game media. Online features built into the consoles themselves can be handled via a firmware update. The Playstation 2 has IPv6 support (according to this

, it's part of the Standard Developer Kit) -- I would expect that newer consoles also have support in their development kits, even if developers aren't currently taking advantage of it.

Yaz

Sorry, but RFC 3484 isn't intended to apply to network architecture tools like ping, as it would introduce unpredictability. Indeed, RFC 3484 cautions against this in the Introduction:

Hence the "standard behaviour" your quote isn't what you think. Network architects and engineers need to be able to test connectivity for specific protocol families. Ping's job isn't some mushy "can I get some response for some domain name", it's "can I get a response from the host at address X".

I have not only run and maintained a dual-stack IPv4/IPv6 network for the last several years, I did some of my graduate research in this area, have taught advanced networking at the honours level at a major university, and have actually written an ICMPv6 library. I know what I'm talking about.

As I'll say now and hopefully won't have to say a thousand times more: you have no idea what you're talking about.

First off, of course ping has no way of knowing what protocol family the destination host is running. That's not its job, nor its purpose. Ping also can't automatically account for one host responding to multiple addresses (perfectly permissible in an IPv4-only network as well as an IPv4/IPv6 network). It can't account for hosts that don't respond to ICMP requests. It also can't account for servers that aren't listening on specific application ports, nor for server applications that don't return any data. If you are diagnosing network problems, those issues are YOUR job, not ping's. All that ping can do is test connectivity for a specific protocol family from one host to another, and report on the results. And you can only trust the results when they're positive and you're getting responses (if you don't get a response, that doesn't mean the host is down. It could simply be ignoring ICMP requests as many public hosts do these days).

So you used the wrong tool for the job at hand, and your response is that the tool is at fault?

You could have run into exactly the same fault in an IPv4-only network. DNS doesn't enforce one name==one host; it is possible for one name to point to a number of hosts, with the local OS using some form of policy to choose between them (round robin, FIFO, random, etc.). Google is a good example -- ay my location, "dig google.com A +short" returns six different IPs. One or more of those could (theoretically) be offline at any given time, which won't be reflected by doing a simply "ping google.com" if ping picks the IP of a host that is online. If ping decides to use a different IP than my web browser, then I can't trust that the ping is representative of what I'd expect to see in the application.

This is an old problem, which predates IPv6. Proper network architects and developers know that the only way to properly debug such a situation is to know the address of the host your application is trying to reach, and then debug from there. You missed this step completely, and are blaming the tool.

Ideally, what should happen is that the browser should have some way to determine the address used to grab the resources from a given host. I admittedly don't know of a browser that offers such functionality, but ideally it should be available. Because again, regardless of protocol family, you can run into exactly the same situation you've run into within the same address family (browser resolving hostname to one address, other tools resolving to another). The proper way to diagnose this in the absence of application-supplied destination addresses is to use a network stack analysis tool like Wireshark. Get the TCP SYN packet being open against the host, and check the destination address in the IP packet encapsulating the TCP SYN. Get the address form there, and continue your analysis (here is actually a good time to use ping -- you know the specific address you're trying to reach, see if the host is reachable).

Actually, none of the major OSs work as you describe. Windows 7 requires the use of a -6 parameter, otherwise it assumes IPv4. Mac OS X 10.7 has separate ping and ping6 utilities, just like Linux (and uses the BSD implementations -- indeed, you can browser the source for their implementation here). FreeBSD's IPv6 Internals documentation also specifies separate ping and ping6 utilities.

Sorry, but you have no ide what you're talking about. You've mischaracterized an RFC (which contradicts your characterization right in the Introduction -- it even gives an example!), gave an example where you used the wrong tool for the job, and whinged about having to make your erroneous claims over and over again (that should have given you a clue). If ping worked as you describe (and it doesn't, in any implementation), it would be unpredictable. Ping isn't intended to be the end-all diagnosis tool -- you have to know what you're doing to use it properly, and to determine the proper context of when to use it. It's YOUR job to know the address and address family being used by applications before just randomly pinging host names and expecting relevant results. It's not ping's fault that you seem to not understad this.

Yaz

Fair enough, but while we're still in a dual-stack situation, you'd have to care enough to at least be able to tell a unified ping utility which protocol you want to use (even if it's just via a -4 or -6 switch). Otherwise, if a given domain name resolves to both IPv4 and IPv6 addresses, which should it pick? Perhaps if you're just using it to see if a host is up, you don't care -- but if you're trying to determine the connectivity of your network graph for a specific protocol set, it's important.

Ping isn't intended to be a novice utility. It's a serious piece of a network diagnostic toolkit. Your grandma isn't going to be running it, so the harm of having it separated into two utilities is minor; anyone serious about network diagnostics and administration isn't going to be phased by the fact that there are two commands, one per protocol.

Anyhow, you have every right to rant on about the separation of ping and ping6 into separate utilities if it's important to you; I simply wanted to point out that due to protocol differences, ping is not comparable to something that relies solely on TCP to function. TCP hasn't changed, and rides inside either IPv4 or IPv6 packets seamlessly.

Yaz

Except that TCP hasn't changed. TCP still rides inside IP packets (v4 or v6), and thus apps based off TCP should work this way[0].

Ping doesn't run off TCP, it runs off ICMP, and there are two different versions of this protocol: one for IPv4 and one for IPv6. ICMPv4 and ICMPv6 are nearly identical, but not quite (different mechanisms for checksum calculation, different error message enumeration). This protocol is ICMPv6.

Now that isn't to say that the developers of the current ping tools couldn't create some uber-ping tool that can handle both ICMPv4 and ICMPv6 packets. The formats are indeed similar -- most of the difference is in how checksums are calculated based on the packet (pseudo)headers and in the error message identifiers. For whatever reason, they decided to have independent versions per protocol.

The point being, it's not correct to compare ping to a web browser. Your web browser will use the same TCP packets regardless of if they're encapsulated within IPv4 or IPv6 packets. The DNS resolving is identical as well. Ping however has to use a different protocol depending on the version of IP being used, which changes the game slightly. And for whatever reasons, the developers who maintain these tools decided by-and-large to leave ping for IPv4 alone, and release a separate version for IPv6. You can certainly question the wisdom of that decision, but it certainly isn't as easy as the case of a web browser.

Yaz

-----

[0] - Of course, "should" doesn't mean "will". The biggest problem often being apps that have only ever reserved 32 bits for storing resolved addresses, or who don't know how to parse IPv6 formatted addresses entered directly.

It refutes your claim pretty directly I'd say.

Now if you want to complain that you have to pay $99/year for the privilege of installing your own apps, and that you need a series of certificates and keys to sign the apps, more power to you. You'd be right -- Apple forces you to pony up and install a pile of keys and such to install apps onto iOS devices. Complain about it all you'd like.

But to complain that you can't compile and install stuff onto the devices you own is 100% incorrect. Compile and install whatever you want. Apple's system for doing so may not be free, but it also isn't particularly onerous either.

To quote again the specific part of your post I have a problem with:

I responded with what I know about iOS development (as I have personal experience with writing iOS apps). However, as you stated that there is NOTHING you can buy off the shelf, I decided to look into Android development. As it turns out, while Android also requires your app to be signed to install it into a device, you are permitted (/required) to generate your own signing keys using the keytool. Once you have that key, you aren't required to share it with anyone, and can install the app you've compiled onto whatever Android device you'd like. No $99/year, and no other restrictions

So either you're misinformed, or you're purposefully spewing crap. Every current smartphone OS permits you to compile and install your own apps. Some are free, some require a subscription service -- but there is no restriction as to what you can write and install on a device you own.

Yaz.

Not true at all -- if you have an iOS device, pay Apple the $99 per year, download the development kit, get yourself the necessary signing certificates from Apple, and compile and run anything you want. You can even get the necessary certificate files to install it onto the devices of up to 100 friends.

Does this require Apple to put your app in their store? No. Their store, their rules. And they don't have to permit other peoples stores either. But you can still compile and install whatever you want -- you just have to compile and install it yourself, without the aid of a pre-compile app downloadable from their store.

When Carmack released the first version of Wolfenstein 3D for iOS, he simultaneously put the source and project files online for anyone to download, modify, build, and install on their iOS devices. Anyone with an iOS developer account and a signing key and certificate could change the source however they wanted, whether it would be Apple approved or not, and install it onto their own devices. If I wanted to replace the Nazis with giant walking vaginas, and install it onto my iOS devices (and those of my friends) there isn't anything Apple could do about it. They won't put it in their store, but I can still compile and run whatever I want on my devices.

Of course, like many anti-Apple ./ers here, you may be someone who really has no intention of ever compiling and installing software onto a mobile device yourself, but what you really want to complain about is being locked into their online store. If that's what you want to complain about, feel free -- but you can't complain about not being able to install stuff you've compiled yourself. That is still perfectly permissible (and always will be -- kinda hard to develop software for a platform if you can't compile or install whatever you want onto it).

Yaz