The issue aint in the school its what happens when kids leave.
A cell phone trigger with someone looking in through a window would work better,
Only better at increasing your chances of getting cought. BTW there was enough concern over these scenarios the US government now includes RFID shields with their RFID passports.
I mean, it's not like the kids have to be implanted with the badges. You can easily leave the badge somewhere if you want to go somewhere naughty. Is there something I've missed?
RFID tags can be read over large distances with proper equipment. This data can then be used by anyone including pedo stalkers and family members with restraining orders against them to wholesale spy on the movements of students.
It could also be used to trigger hidden explosives or other harmful devices when the right people are present.
Since there is no assured association between badge holder and the student due to lack of implantation it would increase the chance of teacher laziness in dealing with attendance. It is too easy to just trust the technology and turn off your brain. This can have harmful consequences.
After the first few weeks it takes most teachers all of 20 seconds to figure out who is and is not in class.
Failing that is swiping a card thru some sort of reader when you get to class really all that difficult? Why are radio tags necessary?
On the technical side of things, the routers don't care about any of this. They scan through the routing tables looking for a match, in the same way for both v4 and v6.
Routers with hardware associative tables do care. Most provide options to effect tradeoff between table entries and prefix length.
v6 definitely does offer an opportunity to shorten our routing tables though. The huge address space means we can significantly reduce fragmentation -- each company only has one allocation (even if it needs to be expanded), vs needing potentially many thousands in v4. But routing happens in the same way between the two protocols.
Unfortunatly much fragmentation is administrativly configured for TE reasons having nothing to do with managing non-consecutive allocations. It will certainly help but don't expect much. Any savings will be more than erased by minimum/48 prefix length for interdomain routing on the Internet.
Instead of a permissive action link for handguns one might consider an x-ray backscatter sentry gun outside of schools, shopping malls and paintball arenas. In addition to fine points made by TFA it would offer backwards compatibility for all existing weapons.
Operation is quite simple. When a weapon is detected a gamma-ray radar in the sentry automatically estimates density of the weapon and transmits the calculated minimum energy required to the integrated fire control system.
The sentry gun then fires a projectile at the weapon shooting it out of your hand, holster, book bag, purse or fanny pack.
I can't think of any possible problems with this as long as you don't show up to class with a walking hard on or concealed water pistol.
You know what is even easier than installing software? Replacing your router with a new one when it eventually fails or becomes obsolete. Half-life of these devices is only a few years.
Riiight, which is why 15 years after IPv6 was first introduced it is deployed everywhere... oh wait!
While your response ignores the specific issue concerning upgrades it is shocking people would wait till the last possible minute to make a change with little to no immediate return. Who'd have guessed? Who isn't surprised?
Your assertion that IPv4 resources "don't exist" is beyond flying-cows nonsensical, so I'm signing off.
APNIC and RIPE are already out. APNIC itself was consuming multiple/8's per month. It is not possible to make up for this type of demand by belt tightening and exchanges alone. There are practical limits on disaggregation without forcing everyone pulling a full table in DFZ to spend untold riches on router upgrades. ARIN and LACNIC to follow in the next year or two.
Only addresses left from these RIRs are in the form of small allocations to facilitiate IPv6 transition.
If your an existing ISP in APNIC or RIPE and you need more IPv4 space your only option is to find someone willing to sell you theirs or go without.
IPv6 is only now being deployed in earnest precisely because IPv4 resources for many types of deployment scenrios no longer practically exist.
Correct, and I've already explained to exhaustion that an application level IPv6 server at the host side, which is much easier to deploy that a change in the OS/network gear at a lower level would have taken care of that.
You know what is even easier than installing software? Replacing your router with a new one when it eventually fails or becomes obsolete. Half-life of these devices is only a few years.
Most of the transition work when amortized out is in needed administrative configuration of address space and related systems.
OS and software vendors, router vendors, and ISPs bear disproprotionate burdon yet there are relatively few of them.
Regardless of what happens all need to develop the same IPv6 functionality anyway regardless of whether your solution was deployed or not to allow addressing and branching off the IPv4 core.
Currently most end-users being turned up with IPv6 have no clue it has happened.
You refuse to admit this because it means that I had already thought (so far) through every one of your simplistic objections and had already devised a way around them.
My objection is not about whether a given scheme is technically possible. Just cause you can do something it does not automatically follow it should be done.
To be viable better alternative it must provide value and incentives beyond what is being offered with the native dualstack transition.
Currently all I am hearing is nonsense talk about leveraging IPv4 resources which don't exist.
Schemes to take IPv4 allocations back with no regard for viability or the fire it would pour on routing table growth.
Schemes to take the IPv4 network down while concurrently building the IPv6 network with no regard for effect on people stuck with IPv4 only.
Only because the protocol wasn't made backward compatible.
Your comment was in direct response to my observation *UNMODIFIED* IPv4 hosts cannot access the IPv6 network no matter how IPv6 was designed.
The reason for this as myself and others have pointed out is due to the simple truth larger address space can not map 1:1 to smaller space no matter how hard you try it is impossible.
The problem is not about IPv6's lack of backwards compatibility it is about IPv4s fixed address space. Increasing IPv4s address space has the same cost as IPv6 deployment.
One easy way to make IPv4 only nodes compatible with IPv6 applications would have been to preserve the old IPv4 prefixes.
Technology allowing an IPv6 only host to access IPv4 network by way of mapping an IPv6/96 subnet to the IPv4 universe, using a NAT translator and altering DNS response to sell the effect are currently in production use. There is some breakage but it mostly works for web sites and basic access.
It does nothing to address the unmodified IPv4 only hosts dilemma. Allowing IPv6 to access IPv4 does not in any way enable the reverse to occur.
My tour thru those transition ideas which sounded good on the surface but don't actually work is pretty exhausted at this point.. Perhaps more importantly quite pointless at this stage to be reflecting on.
Well... there might still be one lingering possibility left...perhaps we are all just complete idiots who don't know how to count... enjoy...
He is living in the year 2000 if he doesn't understand the impact of
I guess people are easily impressed these days.
JSON,
Hey lets just take all of this javascript structure shit and...ya know fuck it just call eval(). Afterall mixing execution with data is the safest bestest way to program in the whole wide world.
jQuery
Hey lets take javascript write a set of useful high level APIs and then fuck the user over with as much ridiculous $ # . ()''$$ noise we can muster.
and Node.js.
Hey if you loved javascript on the browser wait till... WTF... I give up...
Even if something surpasses Javascript
If?
As long as there is demand for a data exchange format that is both human-readable and easy for machines to parse, JSON will not die any more than XML will.
Human readable is not easy for machines to parse. XML parsers are not simple not even close. Neither are dedicated JSON parsers the ones which don't simply punt to eval().
I think overall humans are being put at a disadvantage by operating under the illusion human readable formats are necessary. They should easily be made readable with proper tools the same way IP transactions are made readable by wireshark.
Insiting on human readabilty incurrs large opportunity costs while insuring insane amounts of bandwidth are wasted.
TLVs are easy for machines to parse and do not waste bandwidth. XML is unusable for transport or storage of anything but trivially small datasets and JSON aint that much better either.
What I find most interesting about all of this is even soon after 9/11 airline security was never soo bad I stopped flying.
It happened many years later seemingly in step with Jherkove group backscatter manovourings under cover of underwear bomber the chapter of egregous nonsense of groping and irradiation started.
It sort of reminds me of locutus/piccard taking datas arm and saying "sleep data" who had been working dilligently to find a command to stop the borg.
I think one of few such command that stands any chance of working to effect systematic change is coordinated insistance on campaign finance reform.
Trying to correct the results of structures which breed corrupt behavior is like lobbing a photon torpedo at a borg cube and expecting it to have any effect.
Right, just like we cannot use a few bits to label IPv4 traffic over ATM... oh wait!
In these cases each layer has necessary procedures already baked in to understand what is to be done next with the data at each layer.
An IPv4 only host without some form of access to your special translation machinary is cutoff from the IPv6 universe until that changes.
This is no different than the current situation. An IPv4 only host is cutoff from IPv6 until their ISP upgrades after which it just works or any number of tunneling solutions are installed by the user or upstream ISP including the obnoxious anycast based solutions and any dynamic NAT mapping of 1918 or E space to IPv6.
The operational advantages of native dualstack deployment over the tunneling hacks boil down to minimizing risk of breakage and delivering production quality network at every step. This is critical.
First and foremost content is unwilling to deploy to anything that causes breakage, higher latency or lower throughput and availability.
It is better for everyone to just wait until their ISPs deliver native IPv6 than to encourage customers or ISPs to get IPv6 early with shortcuts only to have it not be as capable as IPv4. This will only make the customer unhappy and therefore content and ISP will also be unhappy.
It is hard to see any of the current tunnel based solutions scaling to any significant fraction of current native IPv4 utilization unless deployed as nothing more than a last mile bandaid.
In short are a lot of things that are possible. Out of those only subset of what is operationally viable actually matter.
I don't WANT direct-accessibility to internal network ranges, that's why NAT has always been a viable option because it prevents that and that's what I WANT to do anyway.
SPI is better in every way including being more secure than restricted cone NAT.
The fact is that the entire NAT thing is a diversion to make us think we have to do entire network overhauls and upgrades to make this new-fangled thing work. It's just not true. I will no more allow internal clients to send out on SMTP ports or allow external hosts to access, well anyway internal, over IPv6 than I would over IPv4. It's just a diversion.
Nobody is bothering to make a distinction between full and restricted cone. This is the real diversion.
People keep using the word 'NAT' like they do the word 'Cloud' like its going out of style without conveying necessary context to communicate exactly what it is their thinking.
I don't recall anyone seriously advocating you renumber your internal networks or enforce an access policy not to your liking.
And a nice diversion from those sites, like Slashdot, that posts an IPv6 article about once a month and NEVER, EVER, EVER accepts traffic or publishes IPv6 addresses for any of their services. Why? Because "it's so much work". If it's that much work, let's just work from w hat we have in the simplest possible way, eh?
Did you not get the memo? The world is running out of IPv4 addresses... we all can't have what works because their aint enough of it to go round.
As far as web sites finding it difficult to move to IPv6 thats absurd. They may have to wait for their ISP to catch up or spend time fixing internal software to store larger address fields but it aint the end of the world. When a third party can magically make any IPv4 site appear on the IPv6 network (http://slashdot.org.sixxs.org/) it is a load of crap to pile on with the lame excuse of it being too much work.
Because simple = secure, and that's just for starters.
A fully routed native IPv6 network is more simple than a duct taped IPv4 network with restricted cone NAT strung out everywhere.
In other words, the IP version is not a significant factor in development of new commerce over the Internet. Skype works fine over IPv4 as it is, and the browser works.
Most of skype is dealing with endpoints who are both behind nats and threfore unable to connect directly to each other so conversations are punted unecessarily thru other users systems with better connectivity. This creates significantly higher latency, unecessarily wastes resources of multiple parties and lowers overall reliability and quality of the communication.
With a network of peers "skype" would simply consist of an optional directory to facilitate people finding and connecting to each other.
People don't care about IP version and they don't care about network topology. What they care about is results and capabilities of the tools they use.
Delivering a network of peers enables better tools and lowers the barrier to entry for developers. You no longer need to design complex P2P schemes or operate an armada of supernode servers to facilitiate communication between people.
That's all that the common man cares about.
These sorts of arguments ignore the opportunity cost of the equation. It is not enough to simply assert x works fine so y is not needed. One should also consider what would additionally be possible if y was delivered.
If 6to4 and other tunneling technologies hadn't been developed the percentage of IPv6 traffic would round down to 0.0%. I can guarantee you that.
6to4 never contributed to IPv6 traffic cause default host policy says prefer IPv4 over IPv6. It only ever contributed to headaches.
The packet is tunneled at least part of the way, often by the last mile ISP, but until recently even by some of the backbones themselves.
A few ISPs are deploying 6rd at least temporarily to get past CPE/last mile issues. ISP core all native has been for awhile.
Comcast 100% native already deployed to about half of its customer base of ~20m subs? My understanding other half likely within the year and all other major US ISPs following suite.
Heck not even slashdot or www.MIT.edu speak IPv6.
Sad... going to take forever to get everyone upgraded. At least www.irs.gov has my back:(
Again, think about it. This should tell you an awful lot about where things stand today
Yea it sucks. IPv6 deployment has been dormant for a decade and a half only in the last few years have things finally started picking up. Keep in mind long tail.. handful of sites responsible for >50% of all network traffic. All already have IPv6 native deployed. Will take forever to get smaller content and subscribers with those exceptionally well made CPE PSUs to upgrade. Need flag day!
Just because you cannot engineer past the details it doesn't mean it can't be done
Just because you can do something does not matter if it is a nonstarter operationally.
Since we have IPv6 on top of IPv4 we can take back most of the IPv4 addresses from every organization
Keep dreaming...
Essentially only border routers need to have IPv4 addresses
I'm really confused. The world is running out of IPv4 addresses and not everyone has IPv6 connectivity.
The act of removing IPv4 addresses means those on the IPv4 only network loose access to IPv4 only resources.
Additionally act of renumbering your network is essentially the same cost that would be incurred by moving to native IPv6.
Breaking the IPv4 internet while concurrently requiring everyone to renumber seems counterproductive. I'm sorry if I don't understand but I don't.
The difference is that you can publicize your NAT+internal_IP address as an IPv6 address to the entire world,
I think you mean to say the entire world that has an IPv6 address.
The problem all of these schems gloss over or otherwise pretend don't exist is that IPv4 nodes on the IPv4 only network are disconnected from IPv6 nodes on the IPv6 network! They have no way of addressing IPv6 cause their aint enough bits. At least with IPv4/IPv6 dualstack there is explicit knowledge of who can get to what via what network.
Really, think about it for a moment. What I'm suggesting is a combination of existing technologies. 6to4 tunneling, MPLS switching, NAT, ATM label switching, shimming, IPv4, IPv6. All the pieces are already there, they just need to be combined in a better way.
I think I like BGP and native IPv6 better. If I'm going to have to renumber anyway native sounds a heck of a lot better to me than tunnels/encapsulation and assorted MTU robbing machinery. As an added bonus the IPv4 Internet for IPv4 only participants is not destroyed in the process.
Moreover the fact that 6to4 was developed at all, after IPv6 was proposed, proves my point and shows that my criticisms of IPv6 were/are shared by many.
The fact that 6to4 was developed at all is a mistake which is being rectified.
Of course it will work You coalesce many IPv6 addresses into a single IPv4/IPv6 node. The packet traverses then to the 4to6 gateway over IPv4 where it is opened and the rest of the IPv6 address is recovered from within the encapsulation.
None of these schemes are worth a hill of beans when there are no more IPv4 addresses available to serve as bearers for such an overlay network. Exhaustion has consequences.
About as productive as going off to check your email to see why the Internet is down.
It's basically why we still use x86 even tho' it's a terrible architecture
x86 is a superficial interface to the underlying architecture. x86 has not dictated processor architecture for decades.
When they designed IPv6 they didn't put any thought into forward and backward compatibility concerns
Compatibility dominated the process.
have is not an upgrade but a shift to a totally new protocol standard that is 100% incompatible
In a nutshell IPv6 is the same as IPv4 with larger source and destination address fields. All upper layer and general protocol operation is unchanged. As Gaurab put it - 96 more bits no magic.
It would be just as difficult to move the Internet from IPv4 to IPX or NetBEUI!!
The jist of the problem to be solved is lack of addressing space in IPv4 header. Whatever clever way you decide to arrange fields in a protocol header still does not change the reality you are dealing with two separate universes of addresses regardless of what the protocol looks like.
This is an operationally unavoidable reality. You can't do any better without touching everything IPv4 in existance. This has the same cost as IPv6.
Seriously, we have to play God with the environment for our large human population to survive
My central point is blanket statements such as this are harmful. Each situation needs to be carefully weighed on the merits. All arguments must be falsifiable or they are meaningless.
Until the Earth's population peaks and starts to come back down again (hopefully late this century), there's no other option that doesn't include mass famine.
The earths population means nothing when contrasted with disparity of consumption between haves and have nots.
IPv6 ain't working. This should pretty much be clear to all, since it is not being widely adopted.
All major ISPs in US are in the process of testing and rolling it out.
Google, Netflix, Akami, Federal government, Facebook all on IPv6.
All major CPE vendors shipping IPv6 enabled gear.
Perhaps you know something they don't?
There will be a long tail and it will take forever to move enough for the plug to be yanked on IPv4. Nobody is saying RFC 801.
A more constructive approach was to take steps to facilitate its adoption, such as tunneling, the IPv6 day and the IPv6 experiment.
All these "steps" did was throw a wrench in the process of adoption. This is 2013 and people demand a production quality network. Tunneling does NOT provide that.
Content is not going to deploy to a shit network with no bandwidth and crappy availability that tunneling provides.
IPv6 day was necessary mostly to identify and fix what went wrong with the tunneling nonsense already deployed.
still only 1% of the internet. At this point we have to believe that nothing short of a completely new protocol will succeed.
We all get to believe what we want. I choose to believe publically available bandwidth charts showing an exponential curve and the interface statistics on my router showing ~30% of my traffic by volume is IPv6.
This is a legitimate gripe for some VoIP and assorted realtime applications with very small per-packet payloads. When I looked into this I found about a 20% increase in channel capacity would be required per VoIP stream just by switching from IPv4 to IPv6.
This however is worse case. For most the packet overhead is a pointless rounding error for data transfers and most web traffic, streaming video..etc even being if being generous and assuming minimum 1280 MTU.
In all cases this overhead is absorbed quickly by ever increasing channel capacity over time.
The alternative to not using IPv6 will eventually be CGN with latency and overall suck that will make your per-packet overhead argument look ridiculous.
The argument for upgrading was never about what you gain..it is about what you get to keep in the long term.
Without it, they can sell IPs for nice amounts without paying for it themselves. For ISPs it would even be nice to just give everybody a 10.x.x.x address (as they do with phones) so you can not run any server, or with very much work.
It is much better and easier to control on many levels of control.
So why would they go to IPv6, which will cost money, while sticking with IPv4 will bring in money.
Given scale of traffic large ISPs are dealing with today it is expensive enough just for the gear to look up L3 addresses in IP header and make routing decisions in hardware associative memory.
ISPs benefit today by deploying IPv6. When they do a huge slice of their traffic (youtube, google, facebook, netflix) no longer has to go thru more expensive and headache causing carrier NAT where headers must be inspected, mangled and where state must be allocated for every transaction.
There are other benefits to the customer in overall reduced latency, issues with P2P, games and hosting servers/content without dealing with NAT barriers and assorted headaches. These benefits translate into happy customers and less support overhead for the ISP.
There are also regulatory headaches stemming from lack of ability to associate an IP with a subscriber where multiple are behind NAT for CALELA. If you think this is a good thing the workarounds are far worse.
How so? Many (if not most) end system addresses have the MAC address embedded in the v6 host address, so you get more information out of a v6 address than you do out of a v4 address (including the ability to trace the same device even if it changes layer-3 networks).
Since most vendors aren't supporting RFC 3972, tracking is probably going to be easier, not harder.
I think you might be thinking about privacy addresses enabled by default on Windows and configurable on MAC and Linux.
We have so many test VMs appearing and disappearing on our network that we don't bother putting them in DNS, we just give out the IP4 192.168... address for the testers and devs. I dread to think what would happen if we had to give them the line noise that is an IP6 address.
Whatever other merits IP6 has, the designers REALLY didn't think it through at the manual address entry level.
I know...take for example the IPv6 address of sprints public web site... It's huge...sorry I mean smaller than any possible IPv4 address.."2600::"
I think you have a choice. You can go for large unwieldy autogenerated messes of address from SLAAC or you can manually (or via DHCP) configure easy to use IPv6 address especially if it is for an internal network.
I do not think it is fair to assert both the idea manual configuration is required and IPv6 addresses are impossible to work with concurrently.
If you are manually configuring then intentionally handing out an impossible to type IPv6 address especially on an internal network does not make much sense.
Also keep in mind nobody is saying you have to dump IPv4 on an internal network EVER. Only your public facing resources EVER have to change.
Slashdot Mirror
No, they can't. Secondly, if that's an issue, shield the school so they can never be read through a school wall.
Why do I even bother?
http://blog.makezine.com/2008/02/29/defcon-rfid-world-record/
The issue aint in the school its what happens when kids leave.
A cell phone trigger with someone looking in through a window would work better,
Only better at increasing your chances of getting cought. BTW there was enough concern over these scenarios the US government now includes RFID shields with their RFID passports.
carry no credit cards
It not only sounds obviously dangerous and stupid to own a credit card with a NFC tag it has been demonstrated to be dangerous and stupid.
None of my cards have radio tags and that will never change.
have no plans on ever leaving the country (passport),
My passport does not have RFID. If my next one does ebay is your friend. No shortage of rfid blocking wallets and cases. Its your CHOICE.
don't own a cell phone
Cell phones can be turned off.
only buy from an increasingly-limited number of stores who don't embed RFID tags in their products for inventory control
RFID-tagged pills on things like pain medication, etc., for medication management is in the works
Don't confuse the rumblings of industry marketeers with reality.
Pray tell, where do these hypothetical people live, with the Amish? RFID is everywhere. It is a pervasive technology
Lets assume RFID was everywhere what would your point be?
I mean, it's not like the kids have to be implanted with the badges. You can easily leave the badge somewhere if you want to go somewhere naughty. Is there something I've missed?
RFID tags can be read over large distances with proper equipment. This data can then be used by anyone including pedo stalkers and family members with restraining orders against them to wholesale spy on the movements of students.
It could also be used to trigger hidden explosives or other harmful devices when the right people are present.
Since there is no assured association between badge holder and the student due to lack of implantation it would increase the chance of teacher laziness in dealing with attendance. It is too easy to just trust the technology and turn off your brain. This can have harmful consequences.
After the first few weeks it takes most teachers all of 20 seconds to figure out who is and is not in class.
Failing that is swiping a card thru some sort of reader when you get to class really all that difficult? Why are radio tags necessary?
On the technical side of things, the routers don't care about any of this. They scan through the routing tables looking for a match, in the same way for both v4 and v6.
Routers with hardware associative tables do care. Most provide options to effect tradeoff between table entries and prefix length.
v6 definitely does offer an opportunity to shorten our routing tables though. The huge address space means we can significantly reduce fragmentation -- each company only has one allocation (even if it needs to be expanded), vs needing potentially many thousands in v4. But routing happens in the same way between the two protocols.
Unfortunatly much fragmentation is administrativly configured for TE reasons having nothing to do with managing non-consecutive allocations. It will certainly help but don't expect much. Any savings will be more than erased by minimum /48 prefix length for interdomain routing on the Internet.
When my living room resembles an IMAX theatre then I'll care..until then 4k might as well be a 40 blade spishak razor.
Heck DVDs are still out-selling blueray by 3-4x after all these years. Nobody cares about higher rez when the only tangable difference is cost.
Instead of a permissive action link for handguns one might consider an x-ray backscatter sentry gun outside of schools, shopping malls and paintball arenas. In addition to fine points made by TFA it would offer backwards compatibility for all existing weapons.
Operation is quite simple. When a weapon is detected a gamma-ray radar in the sentry automatically estimates density of the weapon and transmits the calculated minimum energy required to the integrated fire control system.
The sentry gun then fires a projectile at the weapon shooting it out of your hand, holster, book bag, purse or fanny pack.
I can't think of any possible problems with this as long as you don't show up to class with a walking hard on or concealed water pistol.
You know what is even easier than installing software? Replacing your router with a new one when it eventually fails or becomes obsolete. Half-life of these devices is only a few years.
Riiight, which is why 15 years after IPv6 was first introduced it is deployed everywhere... oh wait!
While your response ignores the specific issue concerning upgrades it is shocking people would wait till the last possible minute to make a change with little to no immediate return. Who'd have guessed? Who isn't surprised?
Your assertion that IPv4 resources "don't exist" is beyond flying-cows nonsensical, so I'm signing off.
APNIC and RIPE are already out. APNIC itself was consuming multiple /8's per month. It is not possible to make up for this type of demand by belt tightening and exchanges alone. There are practical limits on disaggregation without forcing everyone pulling a full table in DFZ to spend untold riches on router upgrades. ARIN and LACNIC to follow in the next year or two.
Only addresses left from these RIRs are in the form of small allocations to facilitiate IPv6 transition.
If your an existing ISP in APNIC or RIPE and you need more IPv4 space your only option is to find someone willing to sell you theirs or go without.
IPv6 is only now being deployed in earnest precisely because IPv4 resources for many types of deployment scenrios no longer practically exist.
Correct, and I've already explained to exhaustion that an application level IPv6 server at the host side, which is much easier to deploy that a change in the OS/network gear at a lower level would have taken care of that.
You know what is even easier than installing software? Replacing your router with a new one when it eventually fails or becomes obsolete. Half-life of these devices is only a few years.
Most of the transition work when amortized out is in needed administrative configuration of address space and related systems.
OS and software vendors, router vendors, and ISPs bear disproprotionate burdon yet there are relatively few of them.
Regardless of what happens all need to develop the same IPv6 functionality anyway regardless of whether your solution was deployed or not to allow addressing and branching off the IPv4 core.
Currently most end-users being turned up with IPv6 have no clue it has happened.
You refuse to admit this because it means that I had already thought (so far) through every one of your simplistic objections and had already devised a way around them.
My objection is not about whether a given scheme is technically possible. Just cause you can do something it does not automatically follow it should be done.
To be viable better alternative it must provide value and incentives beyond what is being offered with the native dualstack transition.
Currently all I am hearing is nonsense talk about leveraging IPv4 resources which don't exist.
Schemes to take IPv4 allocations back with no regard for viability or the fire it would pour on routing table growth.
Schemes to take the IPv4 network down while concurrently building the IPv6 network with no regard for effect on people stuck with IPv4 only.
Only because the protocol wasn't made backward compatible.
Your comment was in direct response to my observation *UNMODIFIED* IPv4 hosts cannot access the IPv6 network no matter how IPv6 was designed.
The reason for this as myself and others have pointed out is due to the simple truth larger address space can not map 1:1 to smaller space no matter how hard you try it is impossible.
The problem is not about IPv6's lack of backwards compatibility it is about IPv4s fixed address space. Increasing IPv4s address space has the same cost as IPv6 deployment.
One easy way to make IPv4 only nodes compatible with IPv6 applications would have been to preserve the old IPv4 prefixes.
Technology allowing an IPv6 only host to access IPv4 network by way of mapping an IPv6 /96 subnet to the IPv4 universe, using a NAT translator and altering DNS response to sell the effect are currently in production use. There is some breakage but it mostly works for web sites and basic access.
It does nothing to address the unmodified IPv4 only hosts dilemma. Allowing IPv6 to access IPv4 does not in any way enable the reverse to occur.
My tour thru those transition ideas which sounded good on the surface but don't actually work is pretty exhausted at this point.. Perhaps more importantly quite pointless at this stage to be reflecting on.
Well... there might still be one lingering possibility left ...perhaps we are all just complete idiots who don't know how to count... enjoy...
http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys-05
He is living in the year 2000 if he doesn't understand the impact of
I guess people are easily impressed these days.
JSON,
Hey lets just take all of this javascript structure shit and...ya know fuck it just call eval(). Afterall mixing execution with data is the safest bestest way to program in the whole wide world.
jQuery
Hey lets take javascript write a set of useful high level APIs and then fuck the user over with as much ridiculous $ # . ()''$$ noise we can muster.
and Node.js.
Hey if you loved javascript on the browser wait till ... WTF... I give up ...
Even if something surpasses Javascript
If?
As long as there is demand for a data exchange format that is both human-readable and easy for machines to parse, JSON will not die any more than XML will.
Human readable is not easy for machines to parse. XML parsers are not simple not even close. Neither are dedicated JSON parsers the ones which don't simply punt to eval().
I think overall humans are being put at a disadvantage by operating under the illusion human readable formats are necessary. They should easily be made readable with proper tools the same way IP transactions are made readable by wireshark.
Insiting on human readabilty incurrs large opportunity costs while insuring insane amounts of bandwidth are wasted.
TLVs are easy for machines to parse and do not waste bandwidth. XML is unusable for transport or storage of anything but trivially small datasets and JSON aint that much better either.
What I find most interesting about all of this is even soon after 9/11 airline security was never soo bad I stopped flying.
It happened many years later seemingly in step with Jherkove group backscatter manovourings under cover of underwear bomber the chapter of egregous nonsense of groping and irradiation started.
It sort of reminds me of locutus/piccard taking datas arm and saying "sleep data" who had been working dilligently to find a command to stop the borg.
I think one of few such command that stands any chance of working to effect systematic change is coordinated insistance on campaign finance reform.
Trying to correct the results of structures which breed corrupt behavior is like lobbing a photon torpedo at a borg cube and expecting it to have any effect.
Right, just like we cannot use a few bits to label IPv4 traffic over ATM... oh wait!
In these cases each layer has necessary procedures already baked in to understand what is to be done next with the data at each layer.
An IPv4 only host without some form of access to your special translation machinary is cutoff from the IPv6 universe until that changes.
This is no different than the current situation. An IPv4 only host is cutoff from IPv6 until their ISP upgrades after which it just works or any number of tunneling solutions are installed by the user or upstream ISP including the obnoxious anycast based solutions and any dynamic NAT mapping of 1918 or E space to IPv6.
The operational advantages of native dualstack deployment over the tunneling hacks boil down to minimizing risk of breakage and delivering production quality network at every step. This is critical.
First and foremost content is unwilling to deploy to anything that causes breakage, higher latency or lower throughput and availability.
It is better for everyone to just wait until their ISPs deliver native IPv6 than to encourage customers or ISPs to get IPv6 early with shortcuts only to have it not be as capable as IPv4. This will only make the customer unhappy and therefore content and ISP will also be unhappy.
It is hard to see any of the current tunnel based solutions scaling to any significant fraction of current native IPv4 utilization unless deployed as nothing more than a last mile bandaid.
In short are a lot of things that are possible. Out of those only subset of what is operationally viable actually matter.
I don't WANT direct-accessibility to internal network ranges, that's why NAT has always been a viable option because it prevents that and that's what I WANT to do anyway.
SPI is better in every way including being more secure than restricted cone NAT.
The fact is that the entire NAT thing is a diversion to make us think we have to do entire network overhauls and upgrades to make this new-fangled thing work. It's just not true. I will no more allow internal clients to send out on SMTP ports or allow external hosts to access, well anyway internal, over IPv6 than I would over IPv4. It's just a diversion.
Nobody is bothering to make a distinction between full and restricted cone. This is the real diversion.
People keep using the word 'NAT' like they do the word 'Cloud' like its going out of style without conveying necessary context to communicate exactly what it is their thinking.
I don't recall anyone seriously advocating you renumber your internal networks or enforce an access policy not to your liking.
And a nice diversion from those sites, like Slashdot, that posts an IPv6 article about once a month and NEVER, EVER, EVER accepts traffic or publishes IPv6 addresses for any of their services. Why? Because "it's so much work". If it's that much work, let's just work from w hat we have in the simplest possible way, eh?
Did you not get the memo? The world is running out of IPv4 addresses... we all can't have what works because their aint enough of it to go round.
As far as web sites finding it difficult to move to IPv6 thats absurd. They may have to wait for their ISP to catch up or spend time fixing internal software to store larger address fields but it aint the end of the world. When a third party can magically make any IPv4 site appear on the IPv6 network (http://slashdot.org.sixxs.org/) it is a load of crap to pile on with the lame excuse of it being too much work.
Because simple = secure, and that's just for starters.
A fully routed native IPv6 network is more simple than a duct taped IPv4 network with restricted cone NAT strung out everywhere.
In other words, the IP version is not a significant factor in development of new commerce over the Internet. Skype works fine over IPv4 as it is, and the browser works.
Most of skype is dealing with endpoints who are both behind nats and threfore unable to connect directly to each other so conversations are punted unecessarily thru other users systems with better connectivity. This creates significantly higher latency, unecessarily wastes resources of multiple parties and lowers overall reliability and quality of the communication.
With a network of peers "skype" would simply consist of an optional directory to facilitate people finding and connecting to each other.
People don't care about IP version and they don't care about network topology. What they care about is results and capabilities of the tools they use.
Delivering a network of peers enables better tools and lowers the barrier to entry for developers. You no longer need to design complex P2P schemes or operate an armada of supernode servers to facilitiate communication between people.
That's all that the common man cares about.
These sorts of arguments ignore the opportunity cost of the equation. It is not enough to simply assert x works fine so y is not needed. One should also consider what would additionally be possible if y was delivered.
If 6to4 and other tunneling technologies hadn't been developed the percentage of IPv6 traffic would round down to 0.0%. I can guarantee you that.
6to4 never contributed to IPv6 traffic cause default host policy says prefer IPv4 over IPv6. It only ever contributed to headaches.
The packet is tunneled at least part of the way, often by the last mile ISP, but until recently even by some of the backbones themselves.
A few ISPs are deploying 6rd at least temporarily to get past CPE/last mile issues. ISP core all native has been for awhile.
Comcast 100% native already deployed to about half of its customer base of ~20m subs? My understanding other half likely within the year and all other major US ISPs following suite.
Heck not even slashdot or www.MIT.edu speak IPv6.
Sad... going to take forever to get everyone upgraded. At least www.irs.gov has my back :(
Again, think about it. This should tell you an awful lot about where things stand today
Yea it sucks. IPv6 deployment has been dormant for a decade and a half only in the last few years have things finally started picking up. Keep in mind long tail .. handful of sites responsible for >50% of all network traffic. All already have IPv6 native deployed. Will take forever to get smaller content and subscribers with those exceptionally well made CPE PSUs to upgrade. Need flag day!
Just because you cannot engineer past the details it doesn't mean it can't be done
Just because you can do something does not matter if it is a nonstarter operationally.
Since we have IPv6 on top of IPv4 we can take back most of the IPv4 addresses from every organization
Keep dreaming...
Essentially only border routers need to have IPv4 addresses
I'm really confused. The world is running out of IPv4 addresses and not everyone has IPv6 connectivity.
The act of removing IPv4 addresses means those on the IPv4 only network loose access to IPv4 only resources.
Additionally act of renumbering your network is essentially the same cost that would be incurred by moving to native IPv6.
Breaking the IPv4 internet while concurrently requiring everyone to renumber seems counterproductive. I'm sorry if I don't understand but I don't.
The difference is that you can publicize your NAT+internal_IP address as an IPv6 address to the entire world,
I think you mean to say the entire world that has an IPv6 address.
The problem all of these schems gloss over or otherwise pretend don't exist is that IPv4 nodes on the IPv4 only network are disconnected from IPv6 nodes on the IPv6 network! They have no way of addressing IPv6 cause their aint enough bits. At least with IPv4/IPv6 dualstack there is explicit knowledge of who can get to what via what network.
Really, think about it for a moment. What I'm suggesting is a combination of existing technologies. 6to4 tunneling, MPLS switching, NAT, ATM label switching, shimming, IPv4, IPv6. All the pieces are already there, they just need to be combined in a better way.
I think I like BGP and native IPv6 better. If I'm going to have to renumber anyway native sounds a heck of a lot better to me than tunnels/encapsulation and assorted MTU robbing machinery. As an added bonus the IPv4 Internet for IPv4 only participants is not destroyed in the process.
Moreover the fact that 6to4 was developed at all, after IPv6 was proposed, proves my point and shows that my criticisms of IPv6 were/are shared by many.
The fact that 6to4 was developed at all is a mistake which is being rectified.
Of course it will work You coalesce many IPv6 addresses into a single IPv4/IPv6 node. The packet traverses then to the 4to6 gateway over IPv4 where it is opened and the rest of the IPv6 address is recovered from within the encapsulation.
None of these schemes are worth a hill of beans when there are no more IPv4 addresses available to serve as bearers for such an overlay network. Exhaustion has consequences.
About as productive as going off to check your email to see why the Internet is down.
It's basically why we still use x86 even tho' it's a terrible architecture
x86 is a superficial interface to the underlying architecture. x86 has not dictated processor architecture for decades.
When they designed IPv6 they didn't put any thought into forward and backward compatibility concerns
Compatibility dominated the process.
have is not an upgrade but a shift to a totally new protocol standard that is 100% incompatible
In a nutshell IPv6 is the same as IPv4 with larger source and destination address fields. All upper layer and general protocol operation is unchanged. As Gaurab put it - 96 more bits no magic.
It would be just as difficult to move the Internet from IPv4 to IPX or NetBEUI!!
The jist of the problem to be solved is lack of addressing space in IPv4 header. Whatever clever way you decide to arrange fields in a protocol header still does not change the reality you are dealing with two separate universes of addresses regardless of what the protocol looks like.
This is an operationally unavoidable reality. You can't do any better without touching everything IPv4 in existance. This has the same cost as IPv6.
Seriously, we have to play God with the environment for our large human population to survive
My central point is blanket statements such as this are harmful. Each situation needs to be carefully weighed on the merits. All arguments must be falsifiable or they are meaningless.
Until the Earth's population peaks and starts to come back down again (hopefully late this century), there's no other option that doesn't include mass famine.
The earths population means nothing when contrasted with disparity of consumption between haves and have nots.
IPv6 ain't working. This should pretty much be clear to all, since it is not being widely adopted.
All major ISPs in US are in the process of testing and rolling it out.
Google, Netflix, Akami, Federal government, Facebook all on IPv6.
All major CPE vendors shipping IPv6 enabled gear.
Perhaps you know something they don't?
There will be a long tail and it will take forever to move enough for the plug to be yanked on IPv4. Nobody is saying RFC 801.
A more constructive approach was to take steps to facilitate its adoption, such as tunneling, the IPv6 day and the IPv6 experiment.
All these "steps" did was throw a wrench in the process of adoption. This is 2013 and people demand a production quality network. Tunneling does NOT provide that.
Content is not going to deploy to a shit network with no bandwidth and crappy availability that tunneling provides.
IPv6 day was necessary mostly to identify and fix what went wrong with the tunneling nonsense already deployed.
still only 1% of the internet. At this point we have to believe that nothing short of a completely new protocol will succeed.
We all get to believe what we want. I choose to believe publically available bandwidth charts showing an exponential curve and the interface statistics on my router showing ~30% of my traffic by volume is IPv6.
we have zero reasons to use it.
This is a legitimate gripe for some VoIP and assorted realtime applications with very small per-packet payloads. When I looked into this I found about a 20% increase in channel capacity would be required per VoIP stream just by switching from IPv4 to IPv6.
This however is worse case. For most the packet overhead is a pointless rounding error for data transfers and most web traffic, streaming video..etc even being if being generous and assuming minimum 1280 MTU.
In all cases this overhead is absorbed quickly by ever increasing channel capacity over time.
The alternative to not using IPv6 will eventually be CGN with latency and overall suck that will make your per-packet overhead argument look ridiculous.
The argument for upgrading was never about what you gain..it is about what you get to keep in the long term.
Without it, they can sell IPs for nice amounts without paying for it themselves. For ISPs it would even be nice to just give everybody a 10.x.x.x address (as they do with phones) so you can not run any server, or with very much work.
It is much better and easier to control on many levels of control.
So why would they go to IPv6, which will cost money, while sticking with IPv4 will bring in money.
Given scale of traffic large ISPs are dealing with today it is expensive enough just for the gear to look up L3 addresses in IP header and make routing decisions in hardware associative memory.
ISPs benefit today by deploying IPv6. When they do a huge slice of their traffic (youtube, google, facebook, netflix) no longer has to go thru more expensive and headache causing carrier NAT where headers must be inspected, mangled and where state must be allocated for every transaction.
There are other benefits to the customer in overall reduced latency, issues with P2P, games and hosting servers/content without dealing with NAT barriers and assorted headaches. These benefits translate into happy customers and less support overhead for the ISP.
There are also regulatory headaches stemming from lack of ability to associate an IP with a subscriber where multiple are behind NAT for CALELA. If you think this is a good thing the workarounds are far worse.
How so? Many (if not most) end system addresses have the MAC address embedded in the v6 host address, so you get more information out of a v6 address than you do out of a v4 address (including the ability to trace the same device even if it changes layer-3 networks).
Since most vendors aren't supporting RFC 3972, tracking is probably going to be easier, not harder.
I think you might be thinking about privacy addresses enabled by default on Windows and configurable on MAC and Linux.
We have so many test VMs appearing and disappearing on our network that we don't bother putting them in DNS, we just give out the IP4 192.168... address for the testers and devs. I dread to think what would happen if we had to give them the line noise that is an IP6 address.
Whatever other merits IP6 has, the designers REALLY didn't think it through at the manual address entry level.
I know...take for example the IPv6 address of sprints public web site... It's huge...sorry I mean smaller than any possible IPv4 address.."2600::"
I think you have a choice. You can go for large unwieldy autogenerated messes of address from SLAAC or you can manually (or via DHCP) configure easy to use IPv6 address especially if it is for an internal network.
I do not think it is fair to assert both the idea manual configuration is required and IPv6 addresses are impossible to work with concurrently.
If you are manually configuring then intentionally handing out an impossible to type IPv6 address especially on an internal network does not make much sense.
Also keep in mind nobody is saying you have to dump IPv4 on an internal network EVER. Only your public facing resources EVER have to change.