If you're not the registered original purchaser, no dealership will service it
They are at liberty to do this. It would make the independent garages ecstatic - I can't see the main dealers turning away that amount of business.
recognize any warranty
Certainly here in the EU, there's no such thing as invalidating a warranty. Warranties cover design and manufacturing flaws and if you can show that a defect was a design or manufacturing problem then you're covered, if you can't then you were never covered anyway. A car manufacturer would have a hard time explaining to a court that a defect wasn't a manufacturing flaw simply because you bought the car used.
allow you to participate in any recalls.
Refusing to fix a safety problem (which is acknowledged, since they are still issuing recalls to cars that haven't been sold on) would see the company convicted for corporate manslaughter pretty quickly.
No authorized dealership will be allowed to purchase any car used made by a brand that it's not authorized to sell new.
Again, the independents would love this. The manufacturers would be massively shooting themselves in the foot with this anyway since they have just ensured that their competetor's customers must remain loyal to their competetor rather than being free to switch to their product. For example, if I own a car made by Ford, I go to Ford asking about buying a new car and the offer me part exchange which knocks £2000 off the price of my new car. Conversely, I go to Toyota and they refuse to part-ex my Ford because it's a Ford. Unless Toyota's cars are £2000 cheaper than Ford's anyway, they just lost themselves a prospective new customer.
Economically, there is no difference between not buying and pirating.
That's untrue. Resale allows the original purchaser to recoup some of the cost of buying the product. This either makes the product more valuable (i.e. the seller can charge a higher price for the new product), or means the buyer has more money to spend on the next product they want (so they can buy more games or higher priced games as a result). At the end of the day, this means that the publishers should be making more money from each purchaser since a proportion of the money flows up from the resale activities.
Of course, the publishers are restricting resale, under the premise that if people can't buy a used game at a knock-down price, they will instead buy a brand new one at full price. If this were true, then preventing resale would make sense. However, IMHO this isn't going to happen - people only have a certain amount of money to spend on games, and if they can't get old ones for the knock-down price they will either buy less games or turn to the black market.
All this is, of course, disregarding the loss of sales from the primary purchasers who boycott as a result of feelng that they are being abused by the vendor.
Packets are sent in bursts, so increasing the burst size from 3 to 10 packets of 1500 octets gives you a burst of 15000 instead of 4500 octets.
This isn't quite true. Burstyness is an indication that the connection is being underutilised due to the sliding window size being too small. Ideally, the window should not completely fill and the transmission should therefore happen in a non-bursty fasion at close to the link speed.
In any case, the initial congestion window (which is what is being discussed) only affects the slow-start mode employed when a TCP connection is first established. Once the connection is running, the window size automatically scales in an attempt to utilise the full link bandwidth. The reason for increasing the initial congestion window is that on modern networks, the network speed is relatively high and connections are short lived, which means they tend to be closed before the window is scaled to the most optimal size (this is something that persistent connections help with - the slow-start does not need to happen for each request since a long-lived connection should tend to automatically scale the window size automatically). One thought that springs to mind is that is may be sensible for the host to try to cache the last known window size used to talk to a specific host, and use that as the initial congestion window size for new connections to that host, since that would help optimal settings to persist between connections to some extent..
You are absolutely right that when using a QoS mechanism to prioritize the VoIP over the Web traffic the SPDY increased window size doesn't affect the sound quality. However, ISP's don't use QoS to prioritize RTP traffic on your public internet ADSL connection.
You're using the wrong ISP then. ISPs don't tend to use QoS over their core networks (for one thing, there's too much scope for abuse by a customer who decides to tag thair bittorrent traffic as high priority and adversely affecting other customers as a result), but QoS over ADSL lines is quite common (the abuse factor is somewhat mitigated by the fact that these don't tend to be shared amoungst a large number of users, so someone mistagging thir traffic will only hurt themselves).
I was just trying to point out that they are optimizing their own application performance at the cost of performance for other applications.
Nope. For one thing, I don't believe this will cost performance from other applications - this is only an adjustment to the _initial_ window size, so any moderately long lived connection would have adjusted itself in this way already. In traditional HTTP, the browser opens a large number of connections at once, which, if you aggregate the traffic flow from these connections, gives an effective increase in the initial window size anyway. Secondly, the very design of the internet precludes latency sensitive applications from working reliably over (comparatively) low bandwidth connections unless QoS is employed to allow that traffic to jump the queue. (I'm using "comparatively low bandwidth" loosely here - the important measure is actually how long the transmit queue is on the router compared to the link bandwidth - i.e. how long it will take to flush the queue over the link. This is the important measure of jitter, not things like initial congestion window settings).
By increasing the initial window size from 3 to 10 they add to the bufferbloat effect (at the microscopic level) and increase Jitter from tolerable 38 ms to intolerable 126 ms on a 1 Mbit/s ADSL line.
I can't really see how increasing the window size would increase jitter. Network bandwidth aside, the throughput of a TCP connection is a function of latency and window size. Increasing the window size simply increases the throughput on high-latency networks.
You're still limited to MTU-size packets (probably 1500 octets), and if you're using a priority queuing discipline this gives you a network jitter of about 12ms on a 1Mbps connection: (1500*8)/1000000 = 0.012 since the priority queue will insert the small high priority RTP packets between the large low priority packets.
When you improve the performance of your application, you should think about how it degrades the performance of other applications. If someone recommended increasing the O/S priority level of the web browser to the maximum, so all your other applications slowed down to a halt while the web browser was running, you would probably object. The increased initial window size is a comparable recommendation, but at a network buffering level, so very few people understand its negative side effects.
Increasing the window size is not comparable to increasing the priority of the traffic. I would agree with you if the application were setting the ToS flags(*) in an abusive way, but the window size just affects the maximum throughput for a connection given a specific latency connection. Given that latency isn't something generally very controllable, this can't even be regarded as an effective method of intentionally throttling throughput (shaping the traffic on the router would be more sensible here).
(* routers out on the internet won't generally pay attention to ToS flags, so setting them abusively wouldn't normally give you any advantage anyway. However, routers at the ends of low bandwidth links, such as ADSL, should be paying attention to ToS flags in order to prioritise latency-sensitive protocols. If you're not doing this and just relying on FIFO queuing then you're pretty much screwed already for VoIP unless you're using the connection for nothing else).
I'd like to see SCTP getting some love, which sadly enough seems unlikely if it hasn't happened so far. It's a very simple protocol mixing the good parts of both TCP and UDP, plus it supports multiplexing and priorization off the bat.
Unfortunately, whilst its a very good protocol, it isn't supported by Windows, and Microsoft is on record as saying they have no intention of ever implementing it. I guess this is no surprise - the protocol is very new (only 12 years old) and not in common use Microsoft traditionally wait until technologies have been in common use for a good 10-15 years before bothering to produce a half-arsed broken implementation of them (see standards like C99 for details).
That said, it would be nice to see SCTP being used for this sort of thing automatically where it is available, with fallback to TCP where not.
Great! But will it do anything to speed up pages that refuse to display until the advertisements do? Even Slashdot takes longer to display because of some third-party ad server.
XHTML largely fixed that by banning document.write(). Unfortunately the "industry" didn't like that and produced the enormous brain-fart known as HTML5, which went back to allowing all the crazy shit that XHTML had banned for a good reason.
Head of line blocking is a feature of TCP, and my (very cursory) understanding is that SPDY still uses TCP so how is this not still a problem?
A technologically better solution would probably be to use SCTP instead of TCP, but unfortunately suffers from the fact that SCTP is only 12 years old, so Microsoft have stated that they have no intention of ever supporting it. However, despite MS's lack of support, that doesn't prevent the possibility of using SCTP in environments where it is available.
As a software developer, I can see where the call for that comes from - but it's just about as misplaced as it could be. Software developers aren't the 'standard' the rest of the world should orient themselves by.
Developing software is a great skill to have if you're a software engineer -- not sure whether it's a waste of time if you plan to become, say, a doctor, a plumber, etc...
There are very few skills that _everybody_ needs to have for their normal day to day lives - developing software isn't one of them.
Whilst I agree with you that software development isn't a mandatory skill for all careers, I do think that it would be a good idea to give people a mandatory introduction to it at school and then allow them to opt to do it in the later stages of school. Remember that there are mandatory classes in many "non-essential" subjects already - why is it considered a good idea to teach kids art, music, geography, history, engineering (aka "technology") but not software development?
When I was doing my GCSEs (a little under 20 years ago), I ended up doing art and geography as my optional subjects. That wasn't because I thought they were interesting or useful (I firmly believed, and still believe that they were the most boring wastes of time I've ever encountered and have done nothing to usefully improve my education). Computer science wasn't available either as a mandatory or as an optional subject. As far as I know, it still isn't, 20 years later (yes, there are now useless "computing" classes that teach you how to use Word - something that maybe you could dedicate a lesson or 2 to, but I honestly don't see how you can fill an entire subject with that).
In fact, I would go so far to say that a rudamentary understanding of how software works (not just how to use it), would be far more useful to most people than the likes of art, geography, etc. Even if you're not going to have a career in computing, you're still almost certainly going to use computers and have to interact with techies, so having at least some understanding of how they work is helpful. I don't subscribe to the idea that understanding beyond the level that you are working at isn't useful - if you're writing software in assembly language then it helps to have an basic understanding of the physical chip design; if you're writing software in C it helps to have a basic understanding of the instructions that code will be compiled to, as well as how the operating system is going to handle your system calls; by extension, if you're using computers (and people from all areas of life do this, including doctors, company directors, etc.) then it helps to have a basic understanding of how the software actually works.
particularly - who knows what language and what paradigm will be 'state of the art' by the time the kid finally gets to use his/her development skills on.
I fundamentally believe that we shouldn't be teaching languages just because they are currently in use or state of the art. When I was doing my A levels and later when I was doing my degree, basic procedural programming was taught using Pascal, because it happens to be a reasonable teaching language. It is, however, a language that isn't really used in industry, but that doesn't matter because once you've understood the basics of programming, picking up a new language is easy. These days, the university I studied at has switched to using Java to teach basic programming skills, because industry alledgedly wants Java programmers. Java is a pretty horrendous language to use as a teaching language for people who have never programmed before, so it fails at that point. Even if industry does want Java programmers now, they probably won't in 10 years, so using that as the foundation for a degree seems daft.
As a company director myself, I don't want programmers who know a single specific language - we use a variety of languages (Java is not one of them), and which languages are used periodically
Why? Millions of routers -- many of which are built in to the DSL modems that litter the landscape -- have been doing NAT with IPv4 for years.
We're not talking about NAT. We're talking about mangling DNS results into IPv4 addresses and *then* NATting them. Sure, the NAT bit is mature and will work, I'm not so sure about the DNS bit...
Mangling DNS, on the surface, looks fine. But there are foreseeable problems.
For example, how long do you cache the ephemeral "made up" DNS response on the router? I mean, when a client does a DNS lookup you generate an ephemeral address and then need to remember this address and the IPv6 address it must be mapped to so you can catch connections to that address and NAT them to the right place. You can't remember this forever (memory is limited), but you don't know how long the clients are going to keep using that IP address after the initial DNS lookup. If the client looks up the name every time it connects then you just need to cache for TTL seconds, but many clients won't do that - a lot will do a DNS lookup when they start up and assume the address is never going to change (yes, this is bad but guess what - there's lots of badly written software around).
And the aforementioned problem that mangling DNS will utterly break DNSSEC.
And the fact that servers on IPv6 are probably going to assume there is no NAT anywhere, whcih is going to be important for some protocols - expect peer-to-peer stuff like VoIP to break spectacularly in your configuration.
If I'm ever forced to do so, I'll write my own code, probably based on dnsmasq or some other open source DNS cacher. But I'm not going to go through the expense and headache of changing my entire internal IPv4 network just to satisfy the IPv6 "purists" when there's NO NEED FOR ME TO DO SO.
To repeat: this just is NOT that deep.
Strikes me that the effort of writing your own code and then having to continually deal with ongoing broken shit that happens as a result far outweighs the effort of just dual-stacking a network. Your comments come across more as a "I'm going to do things my way even if I have to go through hell and put up with a load of stuff never working properly" stick-it-to-the-man type of thing...
> People saying "I'm never going to upgrade to IPv6" come across the same as people saying "I'm never going to upgrade from IE6" - in short, idiots.
No they aren't. If you upgrade your browser from IE6 you, as in YOU personally, instantly experience benefits. Sites that were broken now work, you won't get 0wn3d, etc.
For the first people to dump IE6 there were very few direct benefits. The sites worked in IE anyway (because the web developers were going through hell to support the 99% of their users who inisted on using a broken piece of crap). Yeah, so it was more secure, but that's not a very tangable benefit for most users.
You could either get into the 21st century and enable IPv6 on your network
Sorry, my ISP is IPv4 only, and I don't have a spare change to the tune of a few million dollars to buy enough shares in that ISP and order them to upgrade.
Why does it matter that your ISP doesn't do IPv6? There have been plenty of tunnelling technologies around for years that make that a non-issue. Look up 6to4, 6in4 and teredo.
Besides, why should I bother?
Because you want to access an IPv6 resource? At least, that's why I presume you're replying to this thread... I posted a link, got a reply saying it didn't work, I explained that they needed IPv6 in order to access it and I got a bunch of people asking why they should bother. given that the whole reason I said they needed to get IPv6 was because they were trying to access an IPv6 resource, the answer to "why should I bother" is clearly because you want to access an IPv6 resource. If you don't want to access an IPv6 resource then no one is telling you to bother (although you'll find that the number of IPv6 resources will gradually increase and at some point you'll be wondering why you can't access a bunch of stuff everyone else can access...)
Everything works fine. I have a static IP, and immediately it gets NATed to 192.168.x.y... I have no need for IPv6,
Then that's fine. You have no need of IPv6, you don't need to access any IPv6 stuff, you don't need any IPv6 users to access your systems, so don't set up IPv6, no one's forcing you to.
I was considering 6to4 and other solutions, but it is a large project that requires a separate box with FreeBSD on it (for pfsense) that would burn 100W per hour... I could possibly go for a small plastic box, like DD-WRT, that does the 6to4, the firewall, dhcp6 and the DNS... but I'm not aware of existence of such an animal.
I don't use 6to4 because I have a native v6 connection, but I do use a Sheevaplug as my home server (runs my firewall, a MythTV backend, DNS server, cacti, nagios, file server, VoIP server, etc.) and it works pretty well, draws very little power and would have no trouble running a 6to4 gateway. Running a 100W server as an always on box is a bit crazy in this day in age unless it's doing something pretty heavyweight, certainly no need for a home server.
NO. I said "translate," and that's what I meant. (Part of the problem I've had when dealing with IPv6 Fanbois is that they think only inside their box and within their rules.)
Yes, did you actually read what I posted? Translation of IPv4 to IPv6 is only possible if you proxy the high level protocols (and then only in certain cases). This isn't something you can do generically. Translation of IPv6 to IPv4 is, however, easy (NAT64).
Look at it this way: inside my IPv4 network, I'm already using NAT. Someone browses to Google.com, the router NATs it out onto the Internet, brings the response back in, then returns it to the original requesting PC.
It would be *criminally* simple to add IPv6-to-4 translation to that.
Yes, it would be very simple to do IPv6-to-IPv4 translation (i.e. client on IPv6, server on IPv4) - this is NAT64, but this is not relevant to what you were proposing (which was IPv4-to-IPv6 translation)
When my browser requests "somenewipv6site.com," (i.e., an IPv6-only site), the router/modem/whatever notes that its an IPv6 address. It does NAT stuff, send the request in IPv6 form, then translates back to IPv4 for the internal network.
No, this demonstrates a significant lack of understanding about how the internet work. Your browser does *not* send a request to "somenewipv6site.com" to your router. Making a web request follows the following sequence: 1. The browser makes a DNS lookup for somenewipv6site.com. 2. The browser makes a connection to the IP address that the DNS server returned. 3. The browser sends a request over that connection. If the browser is on an IPv4-only network and somenewipv6site.com has no IPv4 address, the DNS server won't return an IPv4 address, so step (2) never happens.
It is true that the router could run an HTTP proxy server - the browser makes a request to the proxy rather than performing the DNS lookup itself, and this would work fine. But only for HTTP. You would have to have a different proxy server for each protocol - there isn't a *generic* way of doing this in the same way as NAT64 does the opposite.
I could go on, but you get the picture... it looks like there are only 2 IPv6-only sites on that list.
And so it successfully served the intended purpose of demonstrating that the original poster's assertion that there are *no* ipv6-only sites was incorrect?
VoIP is one of the most obvious applications for IPv6.
Yes, but it is also an application that frequently relies on hardware devices that don't do IPv6. For example, despite my network being IPv6 enabled, my SPA3102 FXO/FXS interface only does IPv4, and my UTStarcom SIP phone also only does IPv4 (barely... the poor quality of the firmware is only surpassed by the poor quality of their customer support). Luckilly in these restricted applications it largely doesn't matter too much because those devices are talking to a single specific server, and that server's configuration can be bodged so it happens to work reliably through NAT (at the expense of certain functionality such as peer to peer calling - the RTP media stream pretty much has to go between that server and the phone rather than communicating directly to another peer).
Of course, once you don't need to worry about NAT, you can safely remove those restrictions and the world is a better place.:)
This is one area where IAX2 seems to be much more robust than SIP. IAX2 supports direct peer-to-peer media, just like SIP; but IAX2 starts be routing the media via the server and actually tests if peer to peer going to work before switching to it. So where you have NAT problems that break peer-to-peer media, the call still works by being proxied via the server. With SIP, no such testing happens and this is why failed NAT traversal sometimes causes one-way audio, etc. So if you're using SIP, you basically have to decide when you configure your server whether to proxy the media or make it peer-to-peer, and choosing the latter is unsafe when clients might be behind NAT.
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.
Really? The only console I own is a PSX, so I don't really have any experience with modern consoles, but I was under the impression that they largely had a built-in OS (shipping a whole OS with each game seems a bit crazy anyway...), which also provides features like media-centre functionality, etc. for when you're not playing games.
The quality of the site (judging by its copy in cache) impresses no less than the small number of IPv6-only sites it lists. Aren't you ashamed to show the list of 15 (fifteen!) IPv6 only sites (with one test site and one user's home page among them) as the proof that IPv6 connectivity is worth setting up?
First of all, the amount of research I did amounted to googling and picking the top link. I'm sure you could find plenty more ipv6-only sites.
Secondly, at no point did I state that that site was "proof that IPv6 connectivity is worth setting up", I simply used it to demonstrate that the original poster was incorrect when they stated that there were *no* IPv6-only services on the internet.
Or I could just wish you all happy days in your little sealed-off IPv6 world until such time as it becomes relevant to the rest of us.
<shrug> your call. I was asked for information, I provided it, you found that you couldn't access it. I frankly don't care whether you can access the whole internet or not, but its only going to get worse for you as more and more content becomes v6-only.
I'm fairly certain home users will still be allocated one IP for their modem at any one time, they won't be given one for each of their devices. To do so would be madness and inviting the same situation further down the line (might be 10-20 years but hey) Whether that is an IPv4 or IPv6 address makes no difference. You still have a NAT requirement.
Home users will be given at least a/64 (I get a/56 from EntaNet). So no, there is no NAT requirement.
Its possible one could build a "dynamic" 4to6 gateway. I get a ipv4 DNS request from a client, discover only AAA records exist. Store the IPv6 address (stateful) create and store a bogus ipv4 address for which the client will use you as a gateway. Create a flow from ipv4addr.port to ipv6addr.port with a keep alive; Send the ipv4 address to the client as the dns reply. Pretty much what overloaded 4to4 NATs do today with the added DNS parts.
The trouble is if DNS is not used how do you determine what v6 host to connect to? I suppose for the most part anything not using DNS you could create static NAT entries for. Desktop users running web browsers will be mostly ok.
Sounds prone to break - how long do you keep the mappings around for? What happens when a client caches DNS responses? What happens when someone needs to use DNSSEC (which admittedly gets broken by DNS64 too)?
And all this complex and potentially unreliable gatewaying is easier than rolling out v6 because... ?
So... how do you address a packet to a system behind a NAT?
I'm quite serious, I really don't know. I know of NAT traversal techniques, but they usually involve the client cooperating.
If you are connected to the same broadcast domain as the network you are trying to access (which may be the case on some infrastructures such as cable), you simply set routing on your machine. Most NAT routers have next to no firewall and just let the traffic through (yes, I've tested this with several different brands of router).
On the other hand, I'd ask you "how do you address a packet to a system behind a stateful firewall"? Again, the firewall can be traversed, but it requires the client to cooperate.
this is actually a PITA. suppose you want to force all outbound traffic via a proxy cache for security purposes and bandwidth management... with iptables-v4 it was trivial. not so with ipv6.
> But in order to access IPv6 content on the internet, your local devices are going to have v6 addresses anyway...
No they won't! That is completely incorrect. That's one of the most common misconceptions about IPv6. As I said above: it is entirely possible to have an internal network that doesn't even use TCP/IP at all. All you'd need is a *translation* mechanism at the gateway to the Internet.
Yes, and back in reality its going to be easier to simply dual-stack the network than deal with translating all the high level protocols individually at the border.
That's what many people are doing right now when you use a paid wireless data plan -- for example, I can tether my Android to my laptop. The laptop is 100% IPv4; IPv6 is *disabled.* But my wireless network is IPv6. Not a problem, my smartphone translates everything for me and I don't even have to think about it.
Your smartphone won't be translating anything. Your smartphone will be tunnelling - i.e. simply encapsulating the IPv4 packets inside an IPv6 packet which the telco will then de-encapsulate and NAT to one of their IPv4 addresses. Your laptop still won't be able to access IPv6 content unless there is a high level protocol proxy involved. If there is a proxy involved then only certain specific protocols will work - the proxy isn't going to know how to translate all protocols.
My *ISP* is still IPv4 on its local network. Their backbone from ATT is still IPv4. They're tunneling and translating everything for us.
I'm confused by what you are claiming here. You say your computer is IPv4 only and your ISP is IPv4 only. Your ISP isn't tunnelling or translating anything, you're simply not going to be able to access IPv6 services.
The flipside: people who are on an IPv6 provider will be given a dynamic IPv6 address by their ISP. But the translation is done at the Internet gateway. The people inside that building don't know and don't care. They enter "google.com" in their Web browser and they get a search page.
First of all, most people who are on an ISP that provides IPv6 connectivity will be getting a dual stacked connection - they will have IPv4 as well (possibly CGNATted). If their PC only does IPv4 then they will be unable to access IPv6 content. If the ISP only offers the customer a single-stack IPv6 connection and the customer's PC doesn't support IPv6, it simply won't work at all.
If the ISP offers the customer a single-stack IPv6 connection, and the customer's PC supports IPv6, the ISP can also run NAT64 and DNS64 servers which would allow their customer to access IPv4 services. The whole IPv4 address space can fit in a tiny corner of the IPv6 address space, so each IPv4 addresses is mapped to a unique IPv6 address. This means that, as far as the IPv6 client is concerned, the IPv4 server has a unique IPv6 address. The client connects to that unique IPv6 address and the NAT64 server intercepts the traffic, extracts the IPv4 address that is encoded within the destination IPv6 address and forwards it on over the IPv4 network. This is easy, but also not what you are proposing.
Your proposal was that the client network remain IPv4-only but would be able to connect to IPv6 servers. The problem with this is that an IPv6 address can't be encoded within an IPv4 address, so a border gateway won't be able to figure out what IPv6 address to send the packet to. The only way you can do this is to have a border gateway that understands higher level protocols. For example, for HTTP the gateway can look at the host name the client is trying to connect to, and do its own DNS lookups to convert that into an IPv6 address. However, you would have to provide a gateway that understands every high level protocol you're using, and for some protocols it simply isn't possible because they don't encode the required information.
Legacy devices are an issue. They are an issue, and will remain an issue. It's not just having money to replace legacy devices, it's also the time that would be spent getting new devices to work. For companies, maybe not a big deal? But for consumers, yeah, it's a big deal, since money isn't free.
Of course. "devices" probably largely fall into these categories: 1. Network routers 2. Network switches 3. Printers 4. PCs 5. Mobile phones 6. VoIP phones (and FXO/FXS gateways) 7. Games consoles 8. NAS
So lets tackle these one at a time: 1. Routers - these will need to support v6, so yes, an upgrade is required. It is a shame that its still largely impossible to get a v6 capable home router because this is something that _should_ have been handled by natural wastage (i.e. old router blows up, buy a new one and it has IPv6 support as standard). I guess it will take a while because I don't expect people to go out and replace their router without a significant reason. That said, there are frequently good reasons to replace this hardware, such as the forever increasing speed of internet connections (which often require a new modem). 2. Network switches - Mostly layer 2 devices so IPv6 is a non-issue. For managed switches then they can still be managed over IPv4 and there doesn't seem to be much need for them to be globally reachable so as long as the network is dual stacked, no upgrades necessary. Admittedly multicast snooping won't work, but that's only important in certain situations on very large networks, so not really a problem for home users. 3. Printers - Again, no need for global reachability, so just using IPv4 on a dual-stacked network is fine here, no need to upgrade 4. PCs - these will largely Just Work. Windows XP needs a driver to be installed, but everything newer (Windows Vista/7, Linux, OS X) will autoconfigure v6 when it receives an RA, so no upgrades needed here. Admittedly most home XP users won't install the v6 driver unless they need to access some service that explicitly tells them they need to. 5. Mobile phones - Android 2.0 supports v6, and given that Apple seem to support v6 quite well on a lot of devices I presume iOS probably does too. So nothing new needed here, it just requires a v6-enabled network for them to connect to. 6. Hard VoIP phones and gateways probably talk to a specific predefined server. So long as that server stays on v4 (Which it probably will since it would be a headache for the service provider to move it to v6 and support all their customers, and it isn't a new deployment so already has a working v4 address), they can continue to work on a dual-stacked network. Admittedly there are sometimes issues combining VoIP and NAT. 7. Games consoles - like VoIP phones, they are probably talking to a single existing server so they can continue to do IPv4 on a dual-stacked network. 8. NAS - no need for global connectivity (usually), so IPv4 on a dual stacked network is fine.
All of these devices will eventually be replaced anyway (because they die or need to be upgraded for another reason), but for the time being there isn't actually a lot of need to replace most of them.
Oh, and for us IE6 users, there are ways around getting to blocked sites. It's called changing the user agent and/or version reply in the registry. You know, for such blocked sites such as www.myspace.com or www.target.com.
I wasn't meaning blocked sites. I was talking about sites being developed _for_ IE6. For example, a lot of web developers don't even bother to test under IE6 these days - the site might work, if you're lucky, but IE6's rendering model is so broken that the chances are it won't work entirely as expected. It just isn't worth the cost of fixing up code so they work well in IE6.
Slashdot Mirror
If you're not the registered original purchaser, no dealership will service it
They are at liberty to do this. It would make the independent garages ecstatic - I can't see the main dealers turning away that amount of business.
recognize any warranty
Certainly here in the EU, there's no such thing as invalidating a warranty. Warranties cover design and manufacturing flaws and if you can show that a defect was a design or manufacturing problem then you're covered, if you can't then you were never covered anyway. A car manufacturer would have a hard time explaining to a court that a defect wasn't a manufacturing flaw simply because you bought the car used.
allow you to participate in any recalls.
Refusing to fix a safety problem (which is acknowledged, since they are still issuing recalls to cars that haven't been sold on) would see the company convicted for corporate manslaughter pretty quickly.
No authorized dealership will be allowed to purchase any car used made by a brand that it's not authorized to sell new.
Again, the independents would love this. The manufacturers would be massively shooting themselves in the foot with this anyway since they have just ensured that their competetor's customers must remain loyal to their competetor rather than being free to switch to their product. For example, if I own a car made by Ford, I go to Ford asking about buying a new car and the offer me part exchange which knocks £2000 off the price of my new car. Conversely, I go to Toyota and they refuse to part-ex my Ford because it's a Ford. Unless Toyota's cars are £2000 cheaper than Ford's anyway, they just lost themselves a prospective new customer.
Economically, there is no difference between not buying and pirating.
That's untrue. Resale allows the original purchaser to recoup some of the cost of buying the product. This either makes the product more valuable (i.e. the seller can charge a higher price for the new product), or means the buyer has more money to spend on the next product they want (so they can buy more games or higher priced games as a result). At the end of the day, this means that the publishers should be making more money from each purchaser since a proportion of the money flows up from the resale activities.
Of course, the publishers are restricting resale, under the premise that if people can't buy a used game at a knock-down price, they will instead buy a brand new one at full price. If this were true, then preventing resale would make sense. However, IMHO this isn't going to happen - people only have a certain amount of money to spend on games, and if they can't get old ones for the knock-down price they will either buy less games or turn to the black market.
All this is, of course, disregarding the loss of sales from the primary purchasers who boycott as a result of feelng that they are being abused by the vendor.
Packets are sent in bursts, so increasing the burst size from 3 to 10 packets of 1500 octets gives you a burst of 15000 instead of 4500 octets.
This isn't quite true. Burstyness is an indication that the connection is being underutilised due to the sliding window size being too small. Ideally, the window should not completely fill and the transmission should therefore happen in a non-bursty fasion at close to the link speed.
In any case, the initial congestion window (which is what is being discussed) only affects the slow-start mode employed when a TCP connection is first established. Once the connection is running, the window size automatically scales in an attempt to utilise the full link bandwidth. The reason for increasing the initial congestion window is that on modern networks, the network speed is relatively high and connections are short lived, which means they tend to be closed before the window is scaled to the most optimal size (this is something that persistent connections help with - the slow-start does not need to happen for each request since a long-lived connection should tend to automatically scale the window size automatically). One thought that springs to mind is that is may be sensible for the host to try to cache the last known window size used to talk to a specific host, and use that as the initial congestion window size for new connections to that host, since that would help optimal settings to persist between connections to some extent..
You are absolutely right that when using a QoS mechanism to prioritize the VoIP over the Web traffic the SPDY increased window size doesn't affect the sound quality. However, ISP's don't use QoS to prioritize RTP traffic on your public internet ADSL connection.
You're using the wrong ISP then. ISPs don't tend to use QoS over their core networks (for one thing, there's too much scope for abuse by a customer who decides to tag thair bittorrent traffic as high priority and adversely affecting other customers as a result), but QoS over ADSL lines is quite common (the abuse factor is somewhat mitigated by the fact that these don't tend to be shared amoungst a large number of users, so someone mistagging thir traffic will only hurt themselves).
I was just trying to point out that they are optimizing their own application performance at the cost of performance for other applications.
Nope. For one thing, I don't believe this will cost performance from other applications - this is only an adjustment to the _initial_ window size, so any moderately long lived connection would have adjusted itself in this way already. In traditional HTTP, the browser opens a large number of connections at once, which, if you aggregate the traffic flow from these connections, gives an effective increase in the initial window size anyway. Secondly, the very design of the internet precludes latency sensitive applications from working reliably over (comparatively) low bandwidth connections unless QoS is employed to allow that traffic to jump the queue. (I'm using "comparatively low bandwidth" loosely here - the important measure is actually how long the transmit queue is on the router compared to the link bandwidth - i.e. how long it will take to flush the queue over the link. This is the important measure of jitter, not things like initial congestion window settings).
By increasing the initial window size from 3 to 10 they add to the bufferbloat effect (at the microscopic level) and increase Jitter from tolerable 38 ms to intolerable 126 ms on a 1 Mbit/s ADSL line.
I can't really see how increasing the window size would increase jitter. Network bandwidth aside, the throughput of a TCP connection is a function of latency and window size. Increasing the window size simply increases the throughput on high-latency networks.
You're still limited to MTU-size packets (probably 1500 octets), and if you're using a priority queuing discipline this gives you a network jitter of about 12ms on a 1Mbps connection: (1500*8)/1000000 = 0.012 since the priority queue will insert the small high priority RTP packets between the large low priority packets.
When you improve the performance of your application, you should think about how it degrades the performance of other applications. If someone recommended increasing the O/S priority level of the web browser to the maximum, so all your other applications slowed down to a halt while the web browser was running, you would probably object. The increased initial window size is a comparable recommendation, but at a network buffering level, so very few people understand its negative side effects.
Increasing the window size is not comparable to increasing the priority of the traffic. I would agree with you if the application were setting the ToS flags(*) in an abusive way, but the window size just affects the maximum throughput for a connection given a specific latency connection. Given that latency isn't something generally very controllable, this can't even be regarded as an effective method of intentionally throttling throughput (shaping the traffic on the router would be more sensible here).
(* routers out on the internet won't generally pay attention to ToS flags, so setting them abusively wouldn't normally give you any advantage anyway. However, routers at the ends of low bandwidth links, such as ADSL, should be paying attention to ToS flags in order to prioritise latency-sensitive protocols. If you're not doing this and just relying on FIFO queuing then you're pretty much screwed already for VoIP unless you're using the connection for nothing else).
I'd like to see SCTP getting some love, which sadly enough seems unlikely if it hasn't happened so far. It's a very simple protocol mixing the good parts of both TCP and UDP, plus it supports multiplexing and priorization off the bat.
Unfortunately, whilst its a very good protocol, it isn't supported by Windows, and Microsoft is on record as saying they have no intention of ever implementing it. I guess this is no surprise - the protocol is very new (only 12 years old) and not in common use Microsoft traditionally wait until technologies have been in common use for a good 10-15 years before bothering to produce a half-arsed broken implementation of them (see standards like C99 for details).
That said, it would be nice to see SCTP being used for this sort of thing automatically where it is available, with fallback to TCP where not.
Great! But will it do anything to speed up pages that refuse to display until the advertisements do? Even Slashdot takes longer to display because of some third-party ad server.
XHTML largely fixed that by banning document.write(). Unfortunately the "industry" didn't like that and produced the enormous brain-fart known as HTML5, which went back to allowing all the crazy shit that XHTML had banned for a good reason.
No, HTTP suffers from head-of-line blocking.
Head of line blocking is a feature of TCP, and my (very cursory) understanding is that SPDY still uses TCP so how is this not still a problem?
A technologically better solution would probably be to use SCTP instead of TCP, but unfortunately suffers from the fact that SCTP is only 12 years old, so Microsoft have stated that they have no intention of ever supporting it. However, despite MS's lack of support, that doesn't prevent the possibility of using SCTP in environments where it is available.
As a software developer, I can see where the call for that comes from - but it's just about as misplaced as it could be. Software developers aren't the 'standard' the rest of the world should orient themselves by.
Developing software is a great skill to have if you're a software engineer -- not sure whether it's a waste of time if you plan to become, say, a doctor, a plumber, etc...
There are very few skills that _everybody_ needs to have for their normal day to day lives - developing software isn't one of them.
Whilst I agree with you that software development isn't a mandatory skill for all careers, I do think that it would be a good idea to give people a mandatory introduction to it at school and then allow them to opt to do it in the later stages of school. Remember that there are mandatory classes in many "non-essential" subjects already - why is it considered a good idea to teach kids art, music, geography, history, engineering (aka "technology") but not software development?
When I was doing my GCSEs (a little under 20 years ago), I ended up doing art and geography as my optional subjects. That wasn't because I thought they were interesting or useful (I firmly believed, and still believe that they were the most boring wastes of time I've ever encountered and have done nothing to usefully improve my education). Computer science wasn't available either as a mandatory or as an optional subject. As far as I know, it still isn't, 20 years later (yes, there are now useless "computing" classes that teach you how to use Word - something that maybe you could dedicate a lesson or 2 to, but I honestly don't see how you can fill an entire subject with that).
In fact, I would go so far to say that a rudamentary understanding of how software works (not just how to use it), would be far more useful to most people than the likes of art, geography, etc. Even if you're not going to have a career in computing, you're still almost certainly going to use computers and have to interact with techies, so having at least some understanding of how they work is helpful. I don't subscribe to the idea that understanding beyond the level that you are working at isn't useful - if you're writing software in assembly language then it helps to have an basic understanding of the physical chip design; if you're writing software in C it helps to have a basic understanding of the instructions that code will be compiled to, as well as how the operating system is going to handle your system calls; by extension, if you're using computers (and people from all areas of life do this, including doctors, company directors, etc.) then it helps to have a basic understanding of how the software actually works.
particularly - who knows what language and what paradigm will be 'state of the art' by the time the kid finally gets to use his/her development skills on.
I fundamentally believe that we shouldn't be teaching languages just because they are currently in use or state of the art. When I was doing my A levels and later when I was doing my degree, basic procedural programming was taught using Pascal, because it happens to be a reasonable teaching language. It is, however, a language that isn't really used in industry, but that doesn't matter because once you've understood the basics of programming, picking up a new language is easy. These days, the university I studied at has switched to using Java to teach basic programming skills, because industry alledgedly wants Java programmers. Java is a pretty horrendous language to use as a teaching language for people who have never programmed before, so it fails at that point. Even if industry does want Java programmers now, they probably won't in 10 years, so using that as the foundation for a degree seems daft.
As a company director myself, I don't want programmers who know a single specific language - we use a variety of languages (Java is not one of them), and which languages are used periodically
> Sounds prone to break
Why? Millions of routers -- many of which are built in to the DSL modems that litter the landscape -- have been doing NAT with IPv4 for years.
We're not talking about NAT. We're talking about mangling DNS results into IPv4 addresses and *then* NATting them. Sure, the NAT bit is mature and will work, I'm not so sure about the DNS bit...
Mangling DNS, on the surface, looks fine. But there are foreseeable problems.
For example, how long do you cache the ephemeral "made up" DNS response on the router? I mean, when a client does a DNS lookup you generate an ephemeral address and then need to remember this address and the IPv6 address it must be mapped to so you can catch connections to that address and NAT them to the right place. You can't remember this forever (memory is limited), but you don't know how long the clients are going to keep using that IP address after the initial DNS lookup. If the client looks up the name every time it connects then you just need to cache for TTL seconds, but many clients won't do that - a lot will do a DNS lookup when they start up and assume the address is never going to change (yes, this is bad but guess what - there's lots of badly written software around).
And the aforementioned problem that mangling DNS will utterly break DNSSEC.
And the fact that servers on IPv6 are probably going to assume there is no NAT anywhere, whcih is going to be important for some protocols - expect peer-to-peer stuff like VoIP to break spectacularly in your configuration.
If I'm ever forced to do so, I'll write my own code, probably based on dnsmasq or some other open source DNS cacher. But I'm not going to go through the expense and headache of changing my entire internal IPv4 network just to satisfy the IPv6 "purists" when there's NO NEED FOR ME TO DO SO.
To repeat: this just is NOT that deep.
Strikes me that the effort of writing your own code and then having to continually deal with ongoing broken shit that happens as a result far outweighs the effort of just dual-stacking a network. Your comments come across more as a "I'm going to do things my way even if I have to go through hell and put up with a load of stuff never working properly" stick-it-to-the-man type of thing...
> People saying "I'm never going to upgrade to IPv6" come across the same as people saying "I'm never going to upgrade from IE6" - in short, idiots.
No they aren't. If you upgrade your browser from IE6 you, as in YOU personally, instantly experience benefits. Sites that were broken now work, you won't get 0wn3d, etc.
For the first people to dump IE6 there were very few direct benefits. The sites worked in IE anyway (because the web developers were going through hell to support the 99% of their users who inisted on using a broken piece of crap). Yeah, so it was more secure, but that's not a very tangable benefit for most users.
You could either get into the 21st century and enable IPv6 on your network
Sorry, my ISP is IPv4 only, and I don't have a spare change to the tune of a few million dollars to buy enough shares in that ISP and order them to upgrade.
Why does it matter that your ISP doesn't do IPv6? There have been plenty of tunnelling technologies around for years that make that a non-issue. Look up 6to4, 6in4 and teredo.
Besides, why should I bother?
Because you want to access an IPv6 resource? At least, that's why I presume you're replying to this thread...
I posted a link, got a reply saying it didn't work, I explained that they needed IPv6 in order to access it and I got a bunch of people asking why they should bother. given that the whole reason I said they needed to get IPv6 was because they were trying to access an IPv6 resource, the answer to "why should I bother" is clearly because you want to access an IPv6 resource. If you don't want to access an IPv6 resource then no one is telling you to bother (although you'll find that the number of IPv6 resources will gradually increase and at some point you'll be wondering why you can't access a bunch of stuff everyone else can access...)
Everything works fine. I have a static IP, and immediately it gets NATed to 192.168.x.y ... I have no need for IPv6,
Then that's fine. You have no need of IPv6, you don't need to access any IPv6 stuff, you don't need any IPv6 users to access your systems, so don't set up IPv6, no one's forcing you to.
I was considering 6to4 and other solutions, but it is a large project that requires a separate box with FreeBSD on it (for pfsense) that would burn 100W per hour... I could possibly go for a small plastic box, like DD-WRT, that does the 6to4, the firewall, dhcp6 and the DNS... but I'm not aware of existence of such an animal.
I don't use 6to4 because I have a native v6 connection, but I do use a Sheevaplug as my home server (runs my firewall, a MythTV backend, DNS server, cacti, nagios, file server, VoIP server, etc.) and it works pretty well, draws very little power and would have no trouble running a 6to4 gateway. Running a 100W server as an always on box is a bit crazy in this day in age unless it's doing something pretty heavyweight, certainly no need for a home server.
> tunneling ...
NO. I said "translate," and that's what I meant. (Part of the problem I've had when dealing with IPv6 Fanbois is that they think only inside their box and within their rules.)
Yes, did you actually read what I posted? Translation of IPv4 to IPv6 is only possible if you proxy the high level protocols (and then only in certain cases). This isn't something you can do generically. Translation of IPv6 to IPv4 is, however, easy (NAT64).
Look at it this way: inside my IPv4 network, I'm already using NAT. Someone browses to Google.com, the router NATs it out onto the Internet, brings the response back in, then returns it to the original requesting PC.
It would be *criminally* simple to add IPv6-to-4 translation to that.
Yes, it would be very simple to do IPv6-to-IPv4 translation (i.e. client on IPv6, server on IPv4) - this is NAT64, but this is not relevant to what you were proposing (which was IPv4-to-IPv6 translation)
When my browser requests "somenewipv6site.com," (i.e., an IPv6-only site), the router/modem/whatever notes that its an IPv6 address. It does NAT stuff, send the request in IPv6 form, then translates back to IPv4 for the internal network.
No, this demonstrates a significant lack of understanding about how the internet work. Your browser does *not* send a request to "somenewipv6site.com" to your router. Making a web request follows the following sequence:
1. The browser makes a DNS lookup for somenewipv6site.com.
2. The browser makes a connection to the IP address that the DNS server returned.
3. The browser sends a request over that connection.
If the browser is on an IPv4-only network and somenewipv6site.com has no IPv4 address, the DNS server won't return an IPv4 address, so step (2) never happens.
It is true that the router could run an HTTP proxy server - the browser makes a request to the proxy rather than performing the DNS lookup itself, and this would work fine. But only for HTTP. You would have to have a different proxy server for each protocol - there isn't a *generic* way of doing this in the same way as NAT64 does the opposite.
I could go on, but you get the picture... it looks like there are only 2 IPv6-only sites on that list.
And so it successfully served the intended purpose of demonstrating that the original poster's assertion that there are *no* ipv6-only sites was incorrect?
VoIP is one of the most obvious applications for IPv6.
Yes, but it is also an application that frequently relies on hardware devices that don't do IPv6. For example, despite my network being IPv6 enabled, my SPA3102 FXO/FXS interface only does IPv4, and my UTStarcom SIP phone also only does IPv4 (barely... the poor quality of the firmware is only surpassed by the poor quality of their customer support). Luckilly in these restricted applications it largely doesn't matter too much because those devices are talking to a single specific server, and that server's configuration can be bodged so it happens to work reliably through NAT (at the expense of certain functionality such as peer to peer calling - the RTP media stream pretty much has to go between that server and the phone rather than communicating directly to another peer).
Of course, once you don't need to worry about NAT, you can safely remove those restrictions and the world is a better place. :)
This is one area where IAX2 seems to be much more robust than SIP. IAX2 supports direct peer-to-peer media, just like SIP; but IAX2 starts be routing the media via the server and actually tests if peer to peer going to work before switching to it. So where you have NAT problems that break peer-to-peer media, the call still works by being proxied via the server. With SIP, no such testing happens and this is why failed NAT traversal sometimes causes one-way audio, etc. So if you're using SIP, you basically have to decide when you configure your server whether to proxy the media or make it peer-to-peer, and choosing the latter is unsafe when clients might be behind NAT.
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.
Really? The only console I own is a PSX, so I don't really have any experience with modern consoles, but I was under the impression that they largely had a built-in OS (shipping a whole OS with each game seems a bit crazy anyway...), which also provides features like media-centre functionality, etc. for when you're not playing games.
The quality of the site (judging by its copy in cache) impresses no less than the small number of IPv6-only sites it lists. Aren't you ashamed to show the list of 15 (fifteen!) IPv6 only sites (with one test site and one user's home page among them) as the proof that IPv6 connectivity is worth setting up?
First of all, the amount of research I did amounted to googling and picking the top link. I'm sure you could find plenty more ipv6-only sites.
Secondly, at no point did I state that that site was "proof that IPv6 connectivity is worth setting up", I simply used it to demonstrate that the original poster was incorrect when they stated that there were *no* IPv6-only services on the internet.
How should I do that without paying to replace my Netgear WGR614v6 with something else?
6to4, toredo, 6in4. There are lots of technologies that will allow you to access the ipv6 network via ipv4 equipment.
Or I could just wish you all happy days in your little sealed-off IPv6 world until such time as it becomes relevant to the rest of us.
<shrug> your call. I was asked for information, I provided it, you found that you couldn't access it. I frankly don't care whether you can access the whole internet or not, but its only going to get worse for you as more and more content becomes v6-only.
I'm fairly certain home users will still be allocated one IP for their modem at any one time, they won't be given one for each of their devices. To do so would be madness and inviting the same situation further down the line (might be 10-20 years but hey) Whether that is an IPv4 or IPv6 address makes no difference. You still have a NAT requirement.
Home users will be given at least a /64 (I get a /56 from EntaNet). So no, there is no NAT requirement.
Its possible one could build a "dynamic" 4to6 gateway. I get a ipv4 DNS request from a client, discover only AAA records exist. Store the IPv6 address (stateful) create and store a bogus ipv4 address for which the client will use you as a gateway. Create a flow from ipv4addr.port to ipv6addr.port with a keep alive; Send the ipv4 address to the client as the dns reply. Pretty much what overloaded 4to4 NATs do today with the added DNS parts.
The trouble is if DNS is not used how do you determine what v6 host to connect to? I suppose for the most part anything not using DNS you could create static NAT entries for. Desktop users running web browsers will be mostly ok.
Sounds prone to break - how long do you keep the mappings around for? What happens when a client caches DNS responses? What happens when someone needs to use DNSSEC (which admittedly gets broken by DNS64 too)?
And all this complex and potentially unreliable gatewaying is easier than rolling out v6 because... ?
So... how do you address a packet to a system behind a NAT?
I'm quite serious, I really don't know. I know of NAT traversal techniques, but they usually involve the client cooperating.
If you are connected to the same broadcast domain as the network you are trying to access (which may be the case on some infrastructures such as cable), you simply set routing on your machine. Most NAT routers have next to no firewall and just let the traffic through (yes, I've tested this with several different brands of router).
On the other hand, I'd ask you "how do you address a packet to a system behind a stateful firewall"? Again, the firewall can be traversed, but it requires the client to cooperate.
There's still plenty of IPs, they just are in someone's closet.
If you think that, you clearly have no idea how quickly IPs are being used.
this is actually a PITA. suppose you want to force all outbound traffic via a proxy cache for security purposes and bandwidth management... with iptables-v4 it was trivial. not so with ipv6.
It is still trivial, that's what TPROXY is for
> But in order to access IPv6 content on the internet, your local devices are going to have v6 addresses anyway ...
No they won't! That is completely incorrect. That's one of the most common misconceptions about IPv6. As I said above: it is entirely possible to have an internal network that doesn't even use TCP/IP at all. All you'd need is a *translation* mechanism at the gateway to the Internet.
Yes, and back in reality its going to be easier to simply dual-stack the network than deal with translating all the high level protocols individually at the border.
That's what many people are doing right now when you use a paid wireless data plan -- for example, I can tether my Android to my laptop. The laptop is 100% IPv4; IPv6 is *disabled.* But my wireless network is IPv6. Not a problem, my smartphone translates everything for me and I don't even have to think about it.
Your smartphone won't be translating anything. Your smartphone will be tunnelling - i.e. simply encapsulating the IPv4 packets inside an IPv6 packet which the telco will then de-encapsulate and NAT to one of their IPv4 addresses. Your laptop still won't be able to access IPv6 content unless there is a high level protocol proxy involved. If there is a proxy involved then only certain specific protocols will work - the proxy isn't going to know how to translate all protocols.
My *ISP* is still IPv4 on its local network. Their backbone from ATT is still IPv4. They're tunneling and translating everything for us.
I'm confused by what you are claiming here. You say your computer is IPv4 only and your ISP is IPv4 only. Your ISP isn't tunnelling or translating anything, you're simply not going to be able to access IPv6 services.
The flipside: people who are on an IPv6 provider will be given a dynamic IPv6 address by their ISP. But the translation is done at the Internet gateway. The people inside that building don't know and don't care. They enter "google.com" in their Web browser and they get a search page.
First of all, most people who are on an ISP that provides IPv6 connectivity will be getting a dual stacked connection - they will have IPv4 as well (possibly CGNATted). If their PC only does IPv4 then they will be unable to access IPv6 content.
If the ISP only offers the customer a single-stack IPv6 connection and the customer's PC doesn't support IPv6, it simply won't work at all.
If the ISP offers the customer a single-stack IPv6 connection, and the customer's PC supports IPv6, the ISP can also run NAT64 and DNS64 servers which would allow their customer to access IPv4 services. The whole IPv4 address space can fit in a tiny corner of the IPv6 address space, so each IPv4 addresses is mapped to a unique IPv6 address. This means that, as far as the IPv6 client is concerned, the IPv4 server has a unique IPv6 address. The client connects to that unique IPv6 address and the NAT64 server intercepts the traffic, extracts the IPv4 address that is encoded within the destination IPv6 address and forwards it on over the IPv4 network. This is easy, but also not what you are proposing.
Your proposal was that the client network remain IPv4-only but would be able to connect to IPv6 servers. The problem with this is that an IPv6 address can't be encoded within an IPv4 address, so a border gateway won't be able to figure out what IPv6 address to send the packet to. The only way you can do this is to have a border gateway that understands higher level protocols. For example, for HTTP the gateway can look at the host name the client is trying to connect to, and do its own DNS lookups to convert that into an IPv6 address. However, you would have to provide a gateway that understands every high level protocol you're using, and for some protocols it simply isn't possible because they don't encode the required information.
Truly, I am impressed.
You could either get into the 21st century and enable IPv6 on your network, or learn how to use the damned google cache:
http://webcache.googleusercontent.com/search?q=cache:X9icMrzufDgJ:ipv6.cybernode.com/list-of-ipv6-only-sites+http://ipv6.cybernode.com/list-of-ipv6-only-sites&cd=1&hl=en&ct=clnk
Legacy devices are an issue. They are an issue, and will remain an issue. It's not just having money to replace legacy devices, it's also the time that would be spent getting new devices to work. For companies, maybe not a big deal? But for consumers, yeah, it's a big deal, since money isn't free.
Of course. "devices" probably largely fall into these categories:
1. Network routers
2. Network switches
3. Printers
4. PCs
5. Mobile phones
6. VoIP phones (and FXO/FXS gateways)
7. Games consoles
8. NAS
So lets tackle these one at a time:
1. Routers - these will need to support v6, so yes, an upgrade is required. It is a shame that its still largely impossible to get a v6 capable home router because this is something that _should_ have been handled by natural wastage (i.e. old router blows up, buy a new one and it has IPv6 support as standard). I guess it will take a while because I don't expect people to go out and replace their router without a significant reason. That said, there are frequently good reasons to replace this hardware, such as the forever increasing speed of internet connections (which often require a new modem).
2. Network switches - Mostly layer 2 devices so IPv6 is a non-issue. For managed switches then they can still be managed over IPv4 and there doesn't seem to be much need for them to be globally reachable so as long as the network is dual stacked, no upgrades necessary. Admittedly multicast snooping won't work, but that's only important in certain situations on very large networks, so not really a problem for home users.
3. Printers - Again, no need for global reachability, so just using IPv4 on a dual-stacked network is fine here, no need to upgrade
4. PCs - these will largely Just Work. Windows XP needs a driver to be installed, but everything newer (Windows Vista/7, Linux, OS X) will autoconfigure v6 when it receives an RA, so no upgrades needed here. Admittedly most home XP users won't install the v6 driver unless they need to access some service that explicitly tells them they need to.
5. Mobile phones - Android 2.0 supports v6, and given that Apple seem to support v6 quite well on a lot of devices I presume iOS probably does too. So nothing new needed here, it just requires a v6-enabled network for them to connect to.
6. Hard VoIP phones and gateways probably talk to a specific predefined server. So long as that server stays on v4 (Which it probably will since it would be a headache for the service provider to move it to v6 and support all their customers, and it isn't a new deployment so already has a working v4 address), they can continue to work on a dual-stacked network. Admittedly there are sometimes issues combining VoIP and NAT.
7. Games consoles - like VoIP phones, they are probably talking to a single existing server so they can continue to do IPv4 on a dual-stacked network.
8. NAS - no need for global connectivity (usually), so IPv4 on a dual stacked network is fine.
All of these devices will eventually be replaced anyway (because they die or need to be upgraded for another reason), but for the time being there isn't actually a lot of need to replace most of them.
Oh, and for us IE6 users, there are ways around getting to blocked sites. It's called changing the user agent and/or version reply in the registry. You know, for such blocked sites such as www.myspace.com or www.target.com.
I wasn't meaning blocked sites. I was talking about sites being developed _for_ IE6. For example, a lot of web developers don't even bother to test under IE6 these days - the site might work, if you're lucky, but IE6's rendering model is so broken that the chances are it won't work entirely as expected. It just isn't worth the cost of fixing up code so they work well in IE6.