Well, I for one don't believe ISP's will implement IPv6 multicast, even if they can be dragged kicking and screaming into implementing IPv6 unicast, which I'm not sure I believe either.
Certainly not all of IPv6 multicast will ever see the light of day. The best you can expect is that ISP's will allow, for an extra monthly charge of course, their business and enterprise customers to originate source-specific IPv6 multicast with global scope.
You can forget all about any-source multicast. It's dead.
Look more carefully at how Apple is using IPv6. What you will find is that Apple is using IPv6 mostly as a replacement for Appletalk and tunneling it over IPv4 where necessary. There is precious little evidence to suggest that Apple believes there will ever be a functioning IPv6 default-free zone that ordinary people rely on every day. In fact, just about the only major company I can think of that has done anything like that is Google, with their ipv6.google.com service.
If the IPv6 transition never happens at all, which seems likely at this point, then the carrier-grade NAT engines are still needed for operating the IPv4-only networks we have today.
If the IPv6 transition actually does happen, somehow, then you're right. The carrier-grade NAT engines are only needed for IPv4-compatibility. In the unlikely event that IPv4 goes the way of the OSI stack, then maybe the NAT engines will be obsoleted. Not until then.
In any case, if you're using IPv4 now and you haven't started transitioning to IPv6, then you need to prepare for a future when most of your residential and mobile customers will be communicating with you from behind carrier-grade NAT engines that multiplex multiple customers behind a single address.
For example: identifying your customers by the IP address from which they connect to you has always been a bad idea, but it will soon be an extremely bad idea.
Residential and personal mobile device customers can expect to pay extraâ" on the order of US$5-10 per monthâ" if they want a public, i.e. non-RFC1918, IPv4 address assigned to them. Also, don't expect the carrier-grade NAT to support any kind of port forwarding whatsoever. Lastly, you can expect the NAT to implement address/port-dependent endpoint filtering.
So, the writing for P2P applications like BitTorrent is pretty much on the wall now. Read it and weep, MF'ers, we TOLD you this would happen a long time ago, and you didn't believe us.
Ask yourself this question: is $BIGWEBSITE one user or millions of users?
Will $BIGWEBSITE be required to use a "weighted TCP stack" and apportion each client their "fair share" of the network or will they get a special deal that allows them to use the traditional AIMD congestion control and rate adaptation algorithms? If the latter and not the former, why? Will ordinary residential customers be able to get such deals? If not, why not?
p.s. Yes, these are rhetorical questions, and the next time I'm in an IETF presentation from one of these people, I'll be sure to put them to the presenter and watch the rhetorical handwaving come back in response.
While DHCPv6 is currently the only implemented [barely] way to configure hosts with NTP, WINS, et cetera, it is absolutely NOT the best practical way to do it. A simpler and more robust way to do it would be to configure hosts only with addresses for their recursive DNS resolver proxies and let them use DNS-SD to obtain configuration for other services.
Just about everything on the Internet needs DNS. Application interfaces for resolving DNS and DNS-SD are well-defined. If a client application needs to discover the network location of an appropriate server, then it's easier to just go straight to the DNS for it. It's really fricking DUMB that the DHCP client needs to know what services that applications on the host might need to locate at the time of joining the network, which is potentially well before the user of the host decides to run the client. This makes DHCP clients have to ask for every last possible configuration parameter the host is even capable of using, whether it ever uses it or not, and if it doesn't ask for it, then the client application has to fail. This is TOO STUPID for words.
Oh, and your example about the web server changing its MAC address is bogus. All DHCP does is move the place where the new MAC address has to be recorded from the DNS service to the DHCP service. The real solution to that problem is to manually configure the interface address on your web server and record it in the DNS where it never has to be changed again.
There was a reason we kept telling people to encrypt everything by default, and it wasn't because we wanted to keep the Department of Homeland Security from catching terroiristes. It was because we wanted to keep these fucking content filters out of the common carrier network.
Enjoy your ubiquitous, heavily filtered, Internet access, because that's what you asked for.
It might be dated now-- I don't know--but when I was that age, it was Isaac Asimov's non-fiction Realm of Algebra that did the most to set my trajectory. I don't think I've seen anything that was accessible as this since then.
Egads. It looks like this out of print, and expensive on the used-books market. Grrr.
The IP addresses aren't hashed with ESP, but IPsec is still broken by NATs because they need an ALG for IKE. You can encapsulate ESP inside UDP, but you're committing to keepalives and all the rest of the whole VPN experience at that point, so why not just go all the way and build out full-on VPNs for your BitTorrent love? The point is: all that hassle wouldn't have been necessary if we hadn't crapped all over the end-to-end principle by rolling out NAT everywhere.
p.s. No, IPv6 won't save you. It has all the same problems and more.
We told you that you'd regret breaking IPsec with NAT, but did any of you people listen to us? No. Now, you're going to have to set up VPN's if you want your Torrent love to flow. We told you this would happen.
Love, your pals, the end-to-end zealots in the IETF.
"I don't have to qualify for IPv4 multihoming; I already have it."
Are you absolutely sure you will continue to remain qualified under whatever procedures and policies are adopted to conserve IPv4 address and routing table space?
I don't think that, in your shoes, I'd be as confident as you seem to be. If I were you, I'd be looking to re-negotiate all my IPv4 peering contracts at nice fixed rates over very long terms, e.g. 20-25 years. Then I'd be making contingency plans for how I'd multihome on IPv6 without PI space in the event I couldn't manage to grow enough to qualify for PI before all my IPv4 rope ran out.
"[It's] good for everybody if IPv6 is widely deployed before IPv4 depletion."
Is it? I thought you just got through explaining why it wouldn't be good for everybody. <smiley/>
If we were to give away the IPv6 store to the early adopters just like we did the IPv4 store so many years ago, then it wouldn't be good for everybody--just the early adopters. Then, we'd have an IPv6 address crunch hit us just like the IPv4 crunch that looms over us now. If there's just gonna be another address space crunch after the transition, then what's the point of going to all the extra work to get off IPv4 in the first place? It's not like IPv6 is useful for anything that IPv4 doesn't already do today. There's no other point to IPv6 than reforming the addressing architecture. All the other stuff is just window dressing.
"I doubt much breaks. The only thing likely to break with multiple nats is peer to peer."
p1. There is a scaling limit because there's only 16 bits of TCP/UDP port (and ICMP id), and fully-transparent NAT is extremely expensive to implement in hardware. (Has anybody succeeded yet?)
p2. There are additional costs associated with NAT, particularly with passive listeners on battery-operated devices, which have to keep waking up to transmit periodically or their middlebox state collapses. This really hoses the idle-time battery life on your phone, to name an example I'm familiar with...
p3. Another additional cost is the STUN/TURN servers required for enabling offer/answer protocols to work. Those things aren't too cheap to meter--you will be paying for access to them, and they wouldn't be necessary without NAT in the way.
Give me a few more minutes, I'll think up more way NAT break your shizzle.
"IPv6 offers lots of tasty features because they took the opportunity to fix a lot of..."
Yeah, but network operators are refusing to make any of those other feature viable. Multicast? No. End-to-end security? Sorry... IKE is broken by ubiquitous firewalls. Autoconfiguration? Major ISP's are rolling out IPv6 service with the M=1 and O=1 in the router advertisements. Larger datagrams? There isn't any support for negotiating MTU in neighbor discovery.
Pretty much, the only thing left is the larger address space and the obsolescence of NAT.
p0. I didn't (and still don't) think you're an idiot.
p1. How will deployment of IPv6 make your existing IPv4 network less useful? I don't get that. Nobody is talking about deprecating IPv4 any time soon. (The author of the I-D has taken my suggested edits to revise section 2.3.4, which is the only place where it implies that IPv4 will ever be deprecated.)
p2. Traditional IPv4 site multihoming is only going to get harder and more expensive as address conservation efforts get underway. At some point, it won't be any easier to qualify for multihoming on IPv4 than it will be to qualify for PI space in IPv6. It will probably be harder, in fact. The forces at work here have nothing to do with IPv6 transition and everything to do with IPv4 address conservation and BGP scalability. A lot of smaller organizations will be able to get along just fine with IPv6 by routing multiple PA prefixes to every node. This isn't as hard as many people think, and it's getting easier all the time.
p3. A lot of people think they need PI space when what they really want is ULA space. There's plenty of that, and it's absolutely free-- as in FreeBeer(TM). Generate a ULA prefix and start assigning addresses. No permission necessary.
p4. I'm not ready to agree that the RIRs are "trying too hard" not to give away the IPv6 address store. Just because there are 128 bits of address space is no reason to start handing out PI prefixes like candy at Halloween on Nob Hill.
1. Neither John Curran nor the IETF has the the authority to bring this about, thus the use of the word "must" is misleading...
It's an I-D. It's intended to be Informational, i.e. it describes how to classify the phases of incremental deployment. If it's "misleading," it's because some people are trying way too hard to mislead themselves.
2. The natural course of IPv4 depletion is more likely to drive conservation of IPv4 addresses than it is to drive IPv6 adoption...
Exactly correct. I wish more of my fellow IPv6 specialists understood this. IPv6 adoption will only be driven by the capability to deploy applications with IPv6 that cannot be deployed effectively or efficiently with IPv4. Secure mobile IP comes to mind. Secure multicast comes to mind. P2P content distribution would come to mind, but alas, IETF seems bent on ensuring that IPv6 in the real world is just like IPv4/NAT, i.e. communications between endpoints are always expected to originate with nodes behind firewalls and mediated by services in data centers.
3....More critical is the wide swath of legacy multihomed content providers who because they are too small don't qualify for IPv6 addresses from ARIN. Those folks can't get the so-called "provider-independent" addresses...
If the Internet (regardless of protocol version) is to scale up to meet future requirements, then there are going to be a lot of small organizations that can't operate multi-homed simply because they can't afford the peering contracts. Routing table entries in the IPv4 default-free zone are never going to be too cheap to meter again, and the IPv6 default-free zone has all the same scaling characteristics. That's why we have PA addresses in the first place. At least, you should be able to get those without too much trouble. If the problem is that the RIRs are trying too hard not to give away the store to the early adopters (like was done with IPv4 back in the day), then that's a problem to take up with the RIRs, not the IETF.
Native? Not for residential customers and reasonable rates. But that's okay... you don't actually need it.
p1. Just buy either the Apple AirPort Extreme or the Buffalo WZR-AG300NH N-finiti AirStation. Both those products route IPv6 with 6to4 automatically in the factory default configuration. (Of course, they also do manual tunnels, like what you can from SixXS, HE.Net or my personal local favorite: Sonic.Net.
p2. Pick an ISP that has a good route to a nearby 6to4 relay router. In SFO, I use Sonic.Net, and I strongly recommend them. Both AT&T and Comcast are still routing all their 6to4 relay traffic to SWITCH in Zurich, Switzerland. You won't like that. Trust me.
I find it amusing that not one of the legions of Slashdot geniuses has yet to snoop the packets with tcpdump and notice that the IKE phase 2 ISAKMP packets coming back from the server through the NAT have broken UDP checksums. If that had been in the comments on this thread on Sunday when it was created here, then maybe Slashdot discussion threads would be worth following.
I know. You think that's still inside the United States. I thought so, too-- until Bill O'Reilly told me the plain "No Spin Zone" truth. I'm living in a completely foreign country. My neighbors and I are, apparently, all terrorists and enemies of the United States--though, I'm not sure what we did to be so designated.
There could be a downside, however-- all it takes is one look at a contour map and you'll see that San Francisco will fall to an American invasion faster than even Montreal. Plus, we really don't have much of an army or a navy. Our defense strategy against foreign invaders is pretty much: dude, put away the nine if you want to get laid around here; and, if you can help with the rent, then you're welcome to hang out--otherwise, good luck finding another roommate.
Don't look now... some of us hunting for ways to make IPv6 transparently work better than IPv4 when you're behind a NAT gateway. Step one: making sure your NAT can translate your IPv6 network just like it's part of your private IPv4 network. Step two: couple your NAT with a DNS forwarding proxy that translates IPv6 requests for AAAA records into IPv4 requests for A records.
At some point, users will notice, when they turn off their IPv4 protocol, that 1) their IPv6 applications [see parent] work better, and 2) all their legacy IPv4 Internet sites are all still just as reachable over IPv6 as they ever were. At that point, they will be annoyed when they have to run applications that still require IPv4 because they're coded to the old sockets API-- they force you to put up with a second class experience because your IPv4 stack is still enabled. Wheels will then begin to squeak, and real dollar values will be on the table for transitioning applications to use IPv6.
Slashdot Mirror
Well, I for one don't believe ISP's will implement IPv6 multicast, even if they can be dragged kicking and screaming into implementing IPv6 unicast, which I'm not sure I believe either.
Certainly not all of IPv6 multicast will ever see the light of day. The best you can expect is that ISP's will allow, for an extra monthly charge of course, their business and enterprise customers to originate source-specific IPv6 multicast with global scope.
You can forget all about any-source multicast. It's dead.
Look more carefully at how Apple is using IPv6. What you will find is that Apple is using IPv6 mostly as a replacement for Appletalk and tunneling it over IPv4 where necessary. There is precious little evidence to suggest that Apple believes there will ever be a functioning IPv6 default-free zone that ordinary people rely on every day. In fact, just about the only major company I can think of that has done anything like that is Google, with their ipv6.google.com service.
Read the article more carefully.
If the IPv6 transition never happens at all, which seems likely at this point, then the carrier-grade NAT engines are still needed for operating the IPv4-only networks we have today.
If the IPv6 transition actually does happen, somehow, then you're right. The carrier-grade NAT engines are only needed for IPv4-compatibility. In the unlikely event that IPv4 goes the way of the OSI stack, then maybe the NAT engines will be obsoleted. Not until then.
In any case, if you're using IPv4 now and you haven't started transitioning to IPv6, then you need to prepare for a future when most of your residential and mobile customers will be communicating with you from behind carrier-grade NAT engines that multiplex multiple customers behind a single address.
For example: identifying your customers by the IP address from which they connect to you has always been a bad idea, but it will soon be an extremely bad idea.
What WILL happen is "carrier-grade NAT" deployments inside service provider networks.
Residential and personal mobile device customers can expect to pay extraâ" on the order of US$5-10 per monthâ" if they want a public, i.e. non-RFC1918, IPv4 address assigned to them. Also, don't expect the carrier-grade NAT to support any kind of port forwarding whatsoever. Lastly, you can expect the NAT to implement address/port-dependent endpoint filtering.
So, the writing for P2P applications like BitTorrent is pretty much on the wall now. Read it and weep, MF'ers, we TOLD you this would happen a long time ago, and you didn't believe us.
This is why the labor movement happened.
Ask yourself this question: is $BIGWEBSITE one user or millions of users?
Will $BIGWEBSITE be required to use a "weighted TCP stack" and apportion each client their "fair share" of the network or will they get a special deal that allows them to use the traditional AIMD congestion control and rate adaptation algorithms? If the latter and not the former, why? Will ordinary residential customers be able to get such deals? If not, why not?
p.s. Yes, these are rhetorical questions, and the next time I'm in an IETF presentation from one of these people, I'll be sure to put them to the presenter and watch the rhetorical handwaving come back in response.
While DHCPv6 is currently the only implemented [barely] way to configure hosts with NTP, WINS, et cetera, it is absolutely NOT the best practical way to do it. A simpler and more robust way to do it would be to configure hosts only with addresses for their recursive DNS resolver proxies and let them use DNS-SD to obtain configuration for other services.
Just about everything on the Internet needs DNS. Application interfaces for resolving DNS and DNS-SD are well-defined. If a client application needs to discover the network location of an appropriate server, then it's easier to just go straight to the DNS for it. It's really fricking DUMB that the DHCP client needs to know what services that applications on the host might need to locate at the time of joining the network, which is potentially well before the user of the host decides to run the client. This makes DHCP clients have to ask for every last possible configuration parameter the host is even capable of using, whether it ever uses it or not, and if it doesn't ask for it, then the client application has to fail. This is TOO STUPID for words.
Oh, and your example about the web server changing its MAC address is bogus. All DHCP does is move the place where the new MAC address has to be recorded from the DNS service to the DHCP service. The real solution to that problem is to manually configure the interface address on your web server and record it in the DNS where it never has to be changed again.
There was a reason we kept telling people to encrypt everything by default, and it wasn't because we wanted to keep the Department of Homeland Security from catching terroiristes. It was because we wanted to keep these fucking content filters out of the common carrier network.
Enjoy your ubiquitous, heavily filtered, Internet access, because that's what you asked for.
It might be dated now-- I don't know--but when I was that age, it was Isaac Asimov's non-fiction Realm of Algebra that did the most to set my trajectory. I don't think I've seen anything that was accessible as this since then.
Egads. It looks like this out of print, and expensive on the used-books market. Grrr.
Doesn't work for P2P networks like BitTorrent.
The IP addresses aren't hashed with ESP, but IPsec is still broken by NATs because they need an ALG for IKE. You can encapsulate ESP inside UDP, but you're committing to keepalives and all the rest of the whole VPN experience at that point, so why not just go all the way and build out full-on VPNs for your BitTorrent love? The point is: all that hassle wouldn't have been necessary if we hadn't crapped all over the end-to-end principle by rolling out NAT everywhere.
p.s. No, IPv6 won't save you. It has all the same problems and more.
We told you that you'd regret breaking IPsec with NAT, but did any of you people listen to us? No. Now, you're going to have to set up VPN's if you want your Torrent love to flow. We told you this would happen.
Love, your pals, the end-to-end zealots in the IETF.
"I don't have to qualify for IPv4 multihoming; I already have it."
Are you absolutely sure you will continue to remain qualified under whatever procedures and policies are adopted to conserve IPv4 address and routing table space?
I don't think that, in your shoes, I'd be as confident as you seem to be. If I were you, I'd be looking to re-negotiate all my IPv4 peering contracts at nice fixed rates over very long terms, e.g. 20-25 years. Then I'd be making contingency plans for how I'd multihome on IPv6 without PI space in the event I couldn't manage to grow enough to qualify for PI before all my IPv4 rope ran out.
"[It's] good for everybody if IPv6 is widely deployed before IPv4 depletion."
Is it? I thought you just got through explaining why it wouldn't be good for everybody. <smiley/>
If we were to give away the IPv6 store to the early adopters just like we did the IPv4 store so many years ago, then it wouldn't be good for everybody--just the early adopters. Then, we'd have an IPv6 address crunch hit us just like the IPv4 crunch that looms over us now. If there's just gonna be another address space crunch after the transition, then what's the point of going to all the extra work to get off IPv4 in the first place? It's not like IPv6 is useful for anything that IPv4 doesn't already do today. There's no other point to IPv6 than reforming the addressing architecture. All the other stuff is just window dressing.
"I doubt much breaks. The only thing likely to break with multiple nats is peer to peer."
p1. There is a scaling limit because there's only 16 bits of TCP/UDP port (and ICMP id), and fully-transparent NAT is extremely expensive to implement in hardware. (Has anybody succeeded yet?)
p2. There are additional costs associated with NAT, particularly with passive listeners on battery-operated devices, which have to keep waking up to transmit periodically or their middlebox state collapses. This really hoses the idle-time battery life on your phone, to name an example I'm familiar with...
p3. Another additional cost is the STUN/TURN servers required for enabling offer/answer protocols to work. Those things aren't too cheap to meter--you will be paying for access to them, and they wouldn't be necessary without NAT in the way.
Give me a few more minutes, I'll think up more way NAT break your shizzle.
"IPv6 offers lots of tasty features because they took the opportunity to fix a lot of..."
Yeah, but network operators are refusing to make any of those other feature viable. Multicast? No. End-to-end security? Sorry... IKE is broken by ubiquitous firewalls. Autoconfiguration? Major ISP's are rolling out IPv6 service with the M=1 and O=1 in the router advertisements. Larger datagrams? There isn't any support for negotiating MTU in neighbor discovery.
Pretty much, the only thing left is the larger address space and the obsolescence of NAT.
p0. I didn't (and still don't) think you're an idiot.
p1. How will deployment of IPv6 make your existing IPv4 network less useful? I don't get that. Nobody is talking about deprecating IPv4 any time soon. (The author of the I-D has taken my suggested edits to revise section 2.3.4, which is the only place where it implies that IPv4 will ever be deprecated.)
p2. Traditional IPv4 site multihoming is only going to get harder and more expensive as address conservation efforts get underway. At some point, it won't be any easier to qualify for multihoming on IPv4 than it will be to qualify for PI space in IPv6. It will probably be harder, in fact. The forces at work here have nothing to do with IPv6 transition and everything to do with IPv4 address conservation and BGP scalability. A lot of smaller organizations will be able to get along just fine with IPv6 by routing multiple PA prefixes to every node. This isn't as hard as many people think, and it's getting easier all the time.
p3. A lot of people think they need PI space when what they really want is ULA space. There's plenty of that, and it's absolutely free-- as in FreeBeer(TM). Generate a ULA prefix and start assigning addresses. No permission necessary.
p4. I'm not ready to agree that the RIRs are "trying too hard" not to give away the IPv6 address store. Just because there are 128 bits of address space is no reason to start handing out PI prefixes like candy at Halloween on Nob Hill.
A few comments on your observations...
...More critical is the wide swath of legacy multihomed content providers who because they are too small don't qualify for IPv6 addresses from ARIN. Those folks can't get the so-called "provider-independent" addresses...
1. Neither John Curran nor the IETF has the the authority to bring this about, thus the use of the word "must" is misleading...
It's an I-D. It's intended to be Informational, i.e. it describes how to classify the phases of incremental deployment. If it's "misleading," it's because some people are trying way too hard to mislead themselves.
2. The natural course of IPv4 depletion is more likely to drive conservation of IPv4 addresses than it is to drive IPv6 adoption...
Exactly correct. I wish more of my fellow IPv6 specialists understood this. IPv6 adoption will only be driven by the capability to deploy applications with IPv6 that cannot be deployed effectively or efficiently with IPv4. Secure mobile IP comes to mind. Secure multicast comes to mind. P2P content distribution would come to mind, but alas, IETF seems bent on ensuring that IPv6 in the real world is just like IPv4/NAT, i.e. communications between endpoints are always expected to originate with nodes behind firewalls and mediated by services in data centers.
3.
If the Internet (regardless of protocol version) is to scale up to meet future requirements, then there are going to be a lot of small organizations that can't operate multi-homed simply because they can't afford the peering contracts. Routing table entries in the IPv4 default-free zone are never going to be too cheap to meter again, and the IPv6 default-free zone has all the same scaling characteristics. That's why we have PA addresses in the first place. At least, you should be able to get those without too much trouble. If the problem is that the RIRs are trying too hard not to give away the store to the early adopters (like was done with IPv4 back in the day), then that's a problem to take up with the RIRs, not the IETF.
Point conceded. Damn biologists are the most depressing people on the goddamn planet.
I could think of much more efficient ways to keep brain size under control...
You think that was a bad design? I have two words for you: Cephalopelvic Disproportion.
Native? Not for residential customers and reasonable rates. But that's okay... you don't actually need it.
p1. Just buy either the Apple AirPort Extreme or the Buffalo WZR-AG300NH N-finiti AirStation. Both those products route IPv6 with 6to4 automatically in the factory default configuration. (Of course, they also do manual tunnels, like what you can from SixXS, HE.Net or my personal local favorite: Sonic.Net.
p2. Pick an ISP that has a good route to a nearby 6to4 relay router. In SFO, I use Sonic.Net, and I strongly recommend them. Both AT&T and Comcast are still routing all their 6to4 relay traffic to SWITCH in Zurich, Switzerland. You won't like that. Trust me.
I find it amusing that not one of the legions of Slashdot geniuses has yet to snoop the packets with tcpdump and notice that the IKE phase 2 ISAKMP packets coming back from the server through the NAT have broken UDP checksums. If that had been in the comments on this thread on Sunday when it was created here, then maybe Slashdot discussion threads would be worth following.
I just stopped buying EMI compact discs.
I know. You think that's still inside the United States. I thought so, too-- until Bill O'Reilly told me the plain "No Spin Zone" truth. I'm living in a completely foreign country. My neighbors and I are, apparently, all terrorists and enemies of the United States--though, I'm not sure what we did to be so designated.
There could be a downside, however-- all it takes is one look at a contour map and you'll see that San Francisco will fall to an American invasion faster than even Montreal. Plus, we really don't have much of an army or a navy. Our defense strategy against foreign invaders is pretty much: dude, put away the nine if you want to get laid around here; and, if you can help with the rent, then you're welcome to hang out--otherwise, good luck finding another roommate.
Don't look now... some of us hunting for ways to make IPv6 transparently work better than IPv4 when you're behind a NAT gateway. Step one: making sure your NAT can translate your IPv6 network just like it's part of your private IPv4 network. Step two: couple your NAT with a DNS forwarding proxy that translates IPv6 requests for AAAA records into IPv4 requests for A records.
At some point, users will notice, when they turn off their IPv4 protocol, that 1) their IPv6 applications [see parent] work better, and 2) all their legacy IPv4 Internet sites are all still just as reachable over IPv6 as they ever were. At that point, they will be annoyed when they have to run applications that still require IPv4 because they're coded to the old sockets API-- they force you to put up with a second class experience because your IPv4 stack is still enabled. Wheels will then begin to squeak, and real dollar values will be on the table for transitioning applications to use IPv6.