I agree with you on points 2 and 3. However, I do not agree with points 1 and 4:
"anything reasonably current" - first of all, there are lots of software routers (c.f. 72xx series), and there are all kinds of versions of 65xx code which handle v4 forwarding in a more efficient way than v6 forwarding. This is not to mention the assorted legacy equipment which is deployed in ISP POPs - the EOL on the 7500 was just announced last year, and how many ISPs do you think are still using those for T1 termination? (answer, lots) - heck, there are dial platforms which have a hard time dealing with classless IPv4 routing, and those are still in place.
Further, coming back to the current spec - DOCSIS v3 is required to support IPv6. Who's got that universally rolled out? (answer: nobody - everyone is just starting to install v3 gear) How about which version of PPPoE? (answer: it's currently in the "kludging it together" stage - DHCPv6 is required instead of autoconf if you want people to get DNS, but then you get conflicts with DHCPv4...) or SIP? (none)
So given the above, that knocks out cable internet, most DSL internet, and most VoIP providers (VoIP is currently VoIPv4 - nobody has yet written VoIPv6 and productized it).
So there is a heck of a lot of work to be done, and handwaving that everything works doesn't help (in fact, it hurts, because it convinces management that no money needs to be spent on development).
Regarding point #4, where the length of the header and address really matter is in small packets (like the aformentioned VoIPv6) - running little-packet low-jitter protocols over v6 will be substantially less efficient than it is in v4. We can either a) suck it up and deal, b) live with dual-stack forever, and have voice just run on v4, or c) come up with some more technical magic.
I don't know which of those is more likely, but again, there's a lot of work to be done. Comparing the drop in efficiency of header transmission to the difficulty of getting address space is apples to automobiles.
I think that any fixed time (3mos, 6mos, 1yr) would work in the same way: there wouldn't be an unlimited license to track non-suspects, but you'd have a really great background for when you, for instance, catch a terrorist/drug dealer/kiddie porn ring member - you could go back X months, and probably find a whole lot of other people who would be interesting to talk to.
I've been in a situation where something was ringing up lower than I thought it should be, and I pointed it out to the cashier. She looked at the item, re-rang it (for the same low amount), and then said "it's fine" - at that point, I consider it a nice windfall.
I've also pointed out to cashiers when they've given me too much change.
As for an ATM, I think I'd probably let the bank know that the ATM is broken, and if I were lucky, they wouldn't want the extra cash back. If they did ask for it, I might see if they'd quit charging me fees for a while...
FYI, there are two VoIP codecs which are common: G711 is relatively uncompressed, and when Ethernet overheads are included, comes out to about 80K per stream (yes, much more than POTS). G729a is highly compressed, and runs about 8K. There is a significant MOS score difference between the two codecs, and many IP Telephony add-ons (lots of voice mail, for instance) requires G711.
Just to be clear, "mandates suppport" means neither "is implemented" nor "works."
Besides, if you're using a tunneling method, you'll by definition be creating a unicast stream to the v6 endpoint, which is probably topologically further away than the actual source of the content. Now, if you were able to buy a native IPv6 connection from some provider which didn't rely on IPv4 somewhere, you might be in luck. Then again, it would probably be easier to get most providers to implement IPv4 multicast than native IPv6 + v6 multicast...
It was my impression that Randi and the Skeptical Inquirer folks mostly went after those people who claimed scientific authenticity, or claimed to display supernatural powers in real time.
I am unaware of any major religion which would fit the bill above: matters of faith are clearly not scientific (and mixing the two is a bit like mixing motor oil and olive oil: they're both quite a bit better apart). It would surprise me tremendously if the LDS church (or their members) would describe their garments as "magical." Certainly that isn't the description Jews give of the undergarment they wear (tallit katan)...
While I don't think a single tube is reason to call for the EPA superfund, mercury is pretty darn icky stuff, and it lingers in area for quite a while. The bigger concern from increased use (and non-recycling of) CFLs is that landfills will get more and more mercury in them, which could either escape into groundwater, or cause unpredictable effects.
The solution is simple: implement recycling programs.
Mercury is not a gas at room temperature. It is one a only two elements which is liquid at room temperature, and has a propensity to get into everything.
AT&T had $233M in R&D in 2006, according to their claim to the SEC. I noticed that no telecom companies were listed, or any serious-router manufacturers (Cisco spent $4.1B in 2006 R&D, for instance, as documented here.
I do think that some religions are more condusive to people who question/challenge assumptions than others are, and the questioning types will tend to gravitate there.
There has been a rise in fundamentalism over the past 30 years: lots of people do seem perfectly willing to shut their brains off; as a religious person myself (who accepts nothing whatsoever blindly), this phenomenon disquiets me.
A person can make an informed, reasonable decision that a particular religous worldview explains the inputs to his/her senses better than any other available worldview.
Your analysis of Orthodox Judaism and what it would take to be a rational person and accept it is pretty flawed. I suggest hanging out with some Orthodox Jews to get some exposure to their worldview, or at least read Jewish Literacy by Rabbi Telushkin, or Contemporary Orthodox Judaism's Response to Modernity by Rabbi Freundel. I guarantee you'd be surprised at the nature of the religion and its beliefs.
As far as not accepting answers, I would say that that's a strawman argument: the answer to "where do people come from?" could just as easily be "their parents," "their mothers," "Africa," or a host of other non-sequitur answers. The question is ill-formed.
Perhaps what you mean to ask is, "do species change over time, and does this process of change lead to speciation (the creation of new, independent species)?" Anyone who answered "no" to that question is denying a whole host of scientific evidence. There are some ostensibly religious people who would answer that way; in the circles in which I travel, the overwhelming majority would answer "yes" and would treat the question as an "is water wet?" sort of rhetoric.
Whether or not there was a Divine (i.e. supernatural) role/hand in the creation of human beings as we now know them is not a question which science is prepared to answer, and it is not a scientific question (think of it this way - could you make a predictive test? If not, it's not science).
Maybe some believers whom you've met (or not) don't question. I certainly know a tremendous number of sincerely religious people who question everything they're told (for examples, see Orthodox Judaism or Jesuit Catholicism). Perhaps the difference isn't the presence or absence of the question, but the willingness to say "I don't understand" or "I don't know."
Not trolling: are you careful to question Athiesm itself? (as a negative can't technically be proven...)
My one piece of advice is this: don't trust anyone who says it'll work without doing a proof-of-concept. There are enough ooky bits that are a lot better to find in a lab than on a production network...
That's a fair point, about ugrading the Mars Rovers. This is a tad different, however, because the device in question is a commercial product rather than homerolled-code, and there isn't currently an IPv6 protocol stack which is anywhere near as well understood and tested as most of the IPv4 stacks out there.
sigh. I'm quite familiar with the capabilities of much of the Cisco product set. Remotely upgrading code is a PITA (and not entirely risk-free), and tftp across a link with packet-loss is even worse. Better is straightforward FTP, due to TCP's retransmission properties.
In general, most space science software is nowhere near cutting edge, because the engineers (rightly) want code which is known to work always. Cisco is still in the "adding significant features" mode with its IPv6 implementations (various chunks of DHCPv6 were being added in 12.3(14)T, for instance, and aren't available for any of the high-end ISR line [28xx, 38xx] at all). The proof is here. I'll leave the implications of the freshness of the code for you to figure out.
DHCPv6 was created to solve this exact problem. However, its implementation is pretty spotty at this point, although it's getting better. Anycast DNS is a fantastic idea, but you've still got to get the server addresses into the system somehow - Windows XP wouldn't send DNS requests over IPv6 (sans v4) for love or money: my understanding is that Vista is better about this, but I have not personally tested it.
And by "Use secure protocols" did you mean "secure [higher-layer] protocols" like SSL or some such? There are substantial advantages to being able to encrypt at lower layers of the OSI stack: if I'm in an IPsec VPN environment, I don't need to worry (as much) about getting my exchange server to speak securely... SSL is designed to be single-host to single-host - it gets pretty clunky to use it as an IPSec substitute.
Perhaps you could let me know exactly which versions of Cisco IOS include support for DHCPv6? Or how exactly were the expected v6 (without v4) hosts going to find their v6 DNS servers?
Or perhaps it would be support for IPv6SEC as a GRE tunnel encryption, or for DMVPN support?
How about those nifty Cisco SIP/SCCP phones running VoIPv6?
An RFC != a code implementation, and many companies have somewhat aggressive PR departments who will say that "IPv6 is implemented" when what they mean is "some very small IPv6 feature subset is implemented, and turning it on might break a bunch of other things."
To be fair, Cisco (and others) have been steadily adding IPv6 support for features, and their support is getting better, but it's nowhere near feature parity with IPv4.
There are other vendors who have more feature parity, but most of them achieve this parity by excluding infrequently-used IPv4 features (DLSW+, anyone?)
NAT is generally an edge phenomenon: I am not aware of any provider who performs NAT in the core. Latency, however, is largely core-driven - as more masses deploy IPv6, it won't affect the latencies (software switching an IPv6 packet takes about the same amount of processing power and time in a consumer-grade appliance that performing a NAT does) - many core routers pass IPv6 traffic orders of magnitude more slowly than IPv4 ones (unless the ASICs have been custom-spun for v6, the switching will be software-based, which means that each packet becomes a CPU-hit). Core routers have a relatively long depreciation period (~ > 6 years or thereabouts depending...), so that's going to be a problem for a while.
Also, there are a LOT of backbone tunnels, and not much native peering and infrastructure - you'll sometimes see paths which go from Asia -> USA -> Europe -> USA -> Asia and other silliness. This will need to be cleaned up before any sort of actual improvement can be seen by an end-user.
The network effect won't improve the situation: it'll make it worse in the sort term, but if/when more folks deploy v6, then the providers will have a financial incentive to improve their networks.
I assume by "Verio" you mean NTT (AS2914). NTT is an incumbent Japanese telco, which bought the US-based Verio some years ago. I know that NTT offers IPv6 services, and their brochure is here, which claims that they're running dual stack on all of their routers. That brochure also claims that they have 500 customers for their IPv6 services, and claims that they're the largest provider of IPv6 in the world.
As for Sprint, they often brag about their L2TPv3 core, with MPLS, and other private-IP services offered as edge services. It would make sense for them to run 6PE and just treat v6 as yet another edge service which doesn't interfere with their core. BTW, Sprint's documentation on this indicates that they have a grand total of seven IPv6 speaking routers.
So while you might have a point about NTT running v6 in the core, they're not that big an ISP in the US: the weekly routing table analysis doesn't show them in the top 20 in either the ARIN region or the APNIC region. From the map on their website, they've got all of 9 POPs in the US... Their focus seems to be on business and webhosting customers, rather than on end-users - they don't offer a TDM product below a DS3.
In any case, the idea that having 500 customers of a given technology shows the provider as the most deployed/largest in the world misses the scale of the Internet entirely: Cablevision might have more than 500 customers in a single building who are IPv4-only.
Re:You are already are using IPv6
on
IPv6 Tested in Space
·
· Score: 2, Interesting
Oh believe me, I'm familiar with ARIN's policies: I'm one of the people who argued for the adoption of PI (provider independent) allocations as opposed to PA-only allocations, which was the policy for a very long time.
IPv6 was designed by a lot of smart people who work on end-systems, with not a whole lot of folks who actually run very large networks being involved - that's why multihoming still remains a problem (yes, yes, I know, get some PI-space, or is Shim-6 still the suggested approach? Oh wait, that's right, there isn't a working implementation of shim-6...), and to a great extent, IPv6 solves problems which have already been solved for most ISPs and enterprises.
Other than address shortage.
Yes, I agree that there is an IPv4 address shortage, and there is a concern about depletion. But deploying IPv6 requires changing a lot of operational paradigms of the network (middlebox proxy vs. end-to-end), and also the firewall behavior is quite different.
So yeah, I think that there's a v4 address issue: I'm just not sure that v6 is the answer. Time will tell.
Both are fair points, although from this description they sound like a smaller provider, as opposed to one of the really big ones (AT&T, Comcast, Charter, Cox, Verizon...)
My contention was that the big players aren't doing this yet (although Comcast is making noises about it).
The benefits of having separate addresses for each of these interfaces should be compared to the benefit of having different TCP port numbers for different services, which goes back to part of what I see as a problem with the way IPv6 has developed: instead of merely replacing the layer-3 function, it wraps a bunch of layer 2 and layer 4 functionality into it as well, defeating some of the advantages of layering...
2) If I have 1000 aggregation routers connected to customers running IPv4, and two routers in my network where IPv6 is turned on, am I "running IPv6 on my internal network?"
Slashdot Mirror
Here are some of the helpful words which can be made from hexidecimal quads: :aced: :bade: :beef: :cede: :dead: :face: :fade:
:dada: (for the art fans, or perhaps new parents) and :acdc: (for rock & roll fans)
and of course
I use a lot of those in lab settings...
I agree with you on points 2 and 3. However, I do not agree with points 1 and 4:
"anything reasonably current" - first of all, there are lots of software routers (c.f. 72xx series), and there are all kinds of versions of 65xx code which handle v4 forwarding in a more efficient way than v6 forwarding. This is not to mention the assorted legacy equipment which is deployed in ISP POPs - the EOL on the 7500 was just announced last year, and how many ISPs do you think are still using those for T1 termination? (answer, lots) - heck, there are dial platforms which have a hard time dealing with classless IPv4 routing, and those are still in place.
Further, coming back to the current spec - DOCSIS v3 is required to support IPv6. Who's got that universally rolled out? (answer: nobody - everyone is just starting to install v3 gear)
How about which version of PPPoE? (answer: it's currently in the "kludging it together" stage - DHCPv6 is required instead of autoconf if you want people to get DNS, but then you get conflicts with DHCPv4...)
or SIP? (none)
So given the above, that knocks out cable internet, most DSL internet, and most VoIP providers (VoIP is currently VoIPv4 - nobody has yet written VoIPv6 and productized it).
So there is a heck of a lot of work to be done, and handwaving that everything works doesn't help (in fact, it hurts, because it convinces management that no money needs to be spent on development).
Regarding point #4, where the length of the header and address really matter is in small packets (like the aformentioned VoIPv6) - running little-packet low-jitter protocols over v6 will be substantially less efficient than it is in v4. We can either a) suck it up and deal, b) live with dual-stack forever, and have voice just run on v4, or c) come up with some more technical magic.
I don't know which of those is more likely, but again, there's a lot of work to be done. Comparing the drop in efficiency of header transmission to the difficulty of getting address space is apples to automobiles.
I think that any fixed time (3mos, 6mos, 1yr) would work in the same way: there wouldn't be an unlimited license to track non-suspects, but you'd have a really great background for when you, for instance, catch a terrorist/drug dealer/kiddie porn ring member - you could go back X months, and probably find a whole lot of other people who would be interesting to talk to.
I've been in a situation where something was ringing up lower than I thought it should be, and I pointed it out to the cashier. She looked at the item, re-rang it (for the same low amount), and then said "it's fine" - at that point, I consider it a nice windfall.
I've also pointed out to cashiers when they've given me too much change.
As for an ATM, I think I'd probably let the bank know that the ATM is broken, and if I were lucky, they wouldn't want the extra cash back. If they did ask for it, I might see if they'd quit charging me fees for a while...
The one that isn't evil, duh!
FYI, there are two VoIP codecs which are common: G711 is relatively uncompressed, and when Ethernet overheads are included, comes out to about 80K per stream (yes, much more than POTS). G729a is highly compressed, and runs about 8K. There is a significant MOS score difference between the two codecs, and many IP Telephony add-ons (lots of voice mail, for instance) requires G711.
-David
Very well said indeed.
Just to be clear, "mandates suppport" means neither "is implemented" nor "works."
Besides, if you're using a tunneling method, you'll by definition be creating a unicast stream to the v6 endpoint, which is probably topologically further away than the actual source of the content. Now, if you were able to buy a native IPv6 connection from some provider which didn't rely on IPv4 somewhere, you might be in luck. Then again, it would probably be easier to get most providers to implement IPv4 multicast than native IPv6 + v6 multicast...
It was my impression that Randi and the Skeptical Inquirer folks mostly went after those people who claimed scientific authenticity, or claimed to display supernatural powers in real time.
I am unaware of any major religion which would fit the bill above: matters of faith are clearly not scientific (and mixing the two is a bit like mixing motor oil and olive oil: they're both quite a bit better apart). It would surprise me tremendously if the LDS church (or their members) would describe their garments as "magical." Certainly that isn't the description Jews give of the undergarment they wear (tallit katan)...
While I don't think a single tube is reason to call for the EPA superfund, mercury is pretty darn icky stuff, and it lingers in area for quite a while. The bigger concern from increased use (and non-recycling of) CFLs is that landfills will get more and more mercury in them, which could either escape into groundwater, or cause unpredictable effects.
The solution is simple: implement recycling programs.
Mercury is not a gas at room temperature. It is one a only two elements which is liquid at room temperature, and has a propensity to get into everything.
AT&T had $233M in R&D in 2006, according to their claim to the SEC. I noticed that no telecom companies were listed, or any serious-router manufacturers (Cisco spent $4.1B in 2006 R&D, for instance, as documented here.
Shoddy article.
Sensible points.
I do think that some religions are more condusive to people who question/challenge assumptions than others are, and the questioning types will tend to gravitate there.
There has been a rise in fundamentalism over the past 30 years: lots of people do seem perfectly willing to shut their brains off; as a religious person myself (who accepts nothing whatsoever blindly), this phenomenon disquiets me.
A person can make an informed, reasonable decision that a particular religous worldview explains the inputs to his/her senses better than any other available worldview.
Your analysis of Orthodox Judaism and what it would take to be a rational person and accept it is pretty flawed. I suggest hanging out with some Orthodox Jews to get some exposure to their worldview, or at least read Jewish Literacy by Rabbi Telushkin, or Contemporary Orthodox Judaism's Response to Modernity by Rabbi Freundel. I guarantee you'd be surprised at the nature of the religion and its beliefs.
As far as not accepting answers, I would say that that's a strawman argument: the answer to "where do people come from?" could just as easily be "their parents," "their mothers," "Africa," or a host of other non-sequitur answers. The question is ill-formed.
Perhaps what you mean to ask is, "do species change over time, and does this process of change lead to speciation (the creation of new, independent species)?"
Anyone who answered "no" to that question is denying a whole host of scientific evidence. There are some ostensibly religious people who would answer that way; in the circles in which I travel, the overwhelming majority would answer "yes" and would treat the question as an "is water wet?" sort of rhetoric.
Whether or not there was a Divine (i.e. supernatural) role/hand in the creation of human beings as we now know them is not a question which science is prepared to answer, and it is not a scientific question (think of it this way - could you make a predictive test? If not, it's not science).
Maybe some believers whom you've met (or not) don't question. I certainly know a tremendous number of sincerely religious people who question everything they're told (for examples, see Orthodox Judaism or Jesuit Catholicism). Perhaps the difference isn't the presence or absence of the question, but the willingness to say "I don't understand" or "I don't know."
Not trolling: are you careful to question Athiesm itself? (as a negative can't technically be proven...)
My one piece of advice is this: don't trust anyone who says it'll work without doing a proof-of-concept. There are enough ooky bits that are a lot better to find in a lab than on a production network...
That's a fair point, about ugrading the Mars Rovers. This is a tad different, however, because the device in question is a commercial product rather than homerolled-code, and there isn't currently an IPv6 protocol stack which is anywhere near as well understood and tested as most of the IPv4 stacks out there.
sigh. I'm quite familiar with the capabilities of much of the Cisco product set. Remotely upgrading code is a PITA (and not entirely risk-free), and tftp across a link with packet-loss is even worse. Better is straightforward FTP, due to TCP's retransmission properties.
In general, most space science software is nowhere near cutting edge, because the engineers (rightly) want code which is known to work always. Cisco is still in the "adding significant features" mode with its IPv6 implementations (various chunks of DHCPv6 were being added in 12.3(14)T, for instance, and aren't available for any of the high-end ISR line [28xx, 38xx] at all). The proof is here. I'll leave the implications of the freshness of the code for you to figure out.
DHCPv6 was created to solve this exact problem. However, its implementation is pretty spotty at this point, although it's getting better. Anycast DNS is a fantastic idea, but you've still got to get the server addresses into the system somehow - Windows XP wouldn't send DNS requests over IPv6 (sans v4) for love or money: my understanding is that Vista is better about this, but I have not personally tested it.
And by "Use secure protocols" did you mean "secure [higher-layer] protocols" like SSL or some such? There are substantial advantages to being able to encrypt at lower layers of the OSI stack: if I'm in an IPsec VPN environment, I don't need to worry (as much) about getting my exchange server to speak securely... SSL is designed to be single-host to single-host - it gets pretty clunky to use it as an IPSec substitute.
Perhaps you could let me know exactly which versions of Cisco IOS include support for DHCPv6? Or how exactly were the expected v6 (without v4) hosts going to find their v6 DNS servers?
Or perhaps it would be support for IPv6SEC as a GRE tunnel encryption, or for DMVPN support?
How about those nifty Cisco SIP/SCCP phones running VoIPv6?
An RFC != a code implementation, and many companies have somewhat aggressive PR departments who will say that "IPv6 is implemented" when what they mean is "some very small IPv6 feature subset is implemented, and turning it on might break a bunch of other things."
To be fair, Cisco (and others) have been steadily adding IPv6 support for features, and their support is getting better, but it's nowhere near feature parity with IPv4.
There are other vendors who have more feature parity, but most of them achieve this parity by excluding infrequently-used IPv4 features (DLSW+, anyone?)
NAT is generally an edge phenomenon: I am not aware of any provider who performs NAT in the core. Latency, however, is largely core-driven - as more masses deploy IPv6, it won't affect the latencies (software switching an IPv6 packet takes about the same amount of processing power and time in a consumer-grade appliance that performing a NAT does) - many core routers pass IPv6 traffic orders of magnitude more slowly than IPv4 ones (unless the ASICs have been custom-spun for v6, the switching will be software-based, which means that each packet becomes a CPU-hit). Core routers have a relatively long depreciation period (~ > 6 years or thereabouts depending...), so that's going to be a problem for a while.
Also, there are a LOT of backbone tunnels, and not much native peering and infrastructure - you'll sometimes see paths which go from Asia -> USA -> Europe -> USA -> Asia and other silliness. This will need to be cleaned up before any sort of actual improvement can be seen by an end-user.
The network effect won't improve the situation: it'll make it worse in the sort term, but if/when more folks deploy v6, then the providers will have a financial incentive to improve their networks.
I assume by "Verio" you mean NTT (AS2914). NTT is an incumbent Japanese telco, which bought the US-based Verio some years ago. I know that NTT offers IPv6 services, and their brochure is here, which claims that they're running dual stack on all of their routers. That brochure also claims that they have 500 customers for their IPv6 services, and claims that they're the largest provider of IPv6 in the world.
As for Sprint, they often brag about their L2TPv3 core, with MPLS, and other private-IP services offered as edge services. It would make sense for them to run 6PE and just treat v6 as yet another edge service which doesn't interfere with their core. BTW, Sprint's documentation on this indicates that they have a grand total of seven IPv6 speaking routers.
So while you might have a point about NTT running v6 in the core, they're not that big an ISP in the US: the weekly routing table analysis doesn't show them in the top 20 in either the ARIN region or the APNIC region. From the map on their website, they've got all of 9 POPs in the US... Their focus seems to be on business and webhosting customers, rather than on end-users - they don't offer a TDM product below a DS3.
In any case, the idea that having 500 customers of a given technology shows the provider as the most deployed/largest in the world misses the scale of the Internet entirely: Cablevision might have more than 500 customers in a single building who are IPv4-only.
Oh believe me, I'm familiar with ARIN's policies: I'm one of the people who argued for the adoption of PI (provider independent) allocations as opposed to PA-only allocations, which was the policy for a very long time.
IPv6 was designed by a lot of smart people who work on end-systems, with not a whole lot of folks who actually run very large networks being involved - that's why multihoming still remains a problem (yes, yes, I know, get some PI-space, or is Shim-6 still the suggested approach? Oh wait, that's right, there isn't a working implementation of shim-6...), and to a great extent, IPv6 solves problems which have already been solved for most ISPs and enterprises.
Other than address shortage.
Yes, I agree that there is an IPv4 address shortage, and there is a concern about depletion. But deploying IPv6 requires changing a lot of operational paradigms of the network (middlebox proxy vs. end-to-end), and also the firewall behavior is quite different.
So yeah, I think that there's a v4 address issue: I'm just not sure that v6 is the answer. Time will tell.
Both are fair points, although from this description they sound like a smaller provider, as opposed to one of the really big ones (AT&T, Comcast, Charter, Cox, Verizon...)
My contention was that the big players aren't doing this yet (although Comcast is making noises about it).
The benefits of having separate addresses for each of these interfaces should be compared to the benefit of having different TCP port numbers for different services, which goes back to part of what I see as a problem with the way IPv6 has developed: instead of merely replacing the layer-3 function, it wraps a bunch of layer 2 and layer 4 functionality into it as well, defeating some of the advantages of layering...
2 questions:
1) how do you know they're using IPv6 internally?
2) If I have 1000 aggregation routers connected to customers running IPv4, and two routers in my network where IPv6 is turned on, am I "running IPv6 on my internal network?"