Slashdot Mirror
Worldwide IPv6 Adoption: Where Do We Stand Today?
skade88 writes "IPv4 is much like a limited natural resource; it can't last forever. The well of new IPv4 addresses is already running dry in many parts of the world. The solution to this problem, which was presented decades ago, is to switch to IPv6. With peak IPv4 far behind us, why do we still see limited IPv6 adoption? Ars takes a good look at where we are and where we are going with the future of IP addresses, the internet and you. Quoting: 'As with all technology, IPv6 gets better and cheaper over time. And just like with houses, people prefer waiting rather than buying when prices are dropping. To make matters worse, if you're the only one adopting IPv6, this buys you very little. You can only use the new protocol once the people you communicate with have upgraded as well. Worse still, you can't get rid of IPv4 until everyone you communicate with has adopted IPv6. And the pain of the shrinking IPv4 supplies versus the pain of having to upgrade equipment and software varies for different groups of Internet users. So some people want to move to IPv6 and leave IPv4 behind sooner rather than later, but others plan on sticking with IPv4 until the bitter end. As a result, we have a nasty Nash equilibrium: nobody can improve their own situation by unilaterally adopting IPv6.'"
Not really, you just track them by their IPv6 subnet prefix instead of their full IPv4 address
With peak IPv4 far behind us, why do we still see limited IPv6 adoption?
The reason why is simple: because we haven't run out of IPv4 addresses yet.
I have a native, public, non-tunneled IPv6 address at home through my non-business Comcast cable Internet service. My computer and phone automatically use IPv6 whenever available.
I can use IPv6 at work too.
It's already here and adoption seems to be accelerating.
I'm not taking any chances... I've moved our network to IPv8
...what? It makes it EASIER to track people.
Considerably easier, in fact.
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.
with NAT, the ability for millions of machines to share a single IP, the immediate need for new available IPs has somewhat been averted.
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.
Governements do. ISPs don't.
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.
Don't fight for your country, if your country does not fight for you.
How should a machine on the public Internet connect to one of the millions of machines behind a single IP?
I just rebuilt our monitoring system on Munin 2.0, which can deal with IPv6. Made life a lot easier, since punching holes in NAT routers and screwball port mappings went away.
Google and Facebook are both running ipv6, and both our office and a chunk of our datacenter are on ipv6 through a he.net tunnel. Wish native ipv6 was available, but Amazon hasn't enabled it for AWS, and the Comcast ipv6 rollout is to consumers, not to business clients.
Why can't I mod "-1 Idiot"?
>Many (if not most) end system addresses have the MAC address embedded in the v6 host address,
http://en.wikipedia.org/wiki/IPv6#Privacy
Privacy extensions are enabled by default in Windows, Mac OS X (since 10.7), and iOS (since version 4.3).[39] Some Linux distributions have enabled privacy extensions as well.[40]
My FiOS ISP does not have an IPv6 address. I support it internally on my router. I imagine that the hold up is that the big guys aren't there yet. This makes sense since they have the most equipment to replace/reprogram.
I'd actually be interested in where these guys are at. I'm sure they figured it out for businesses but I'd like an IPv6 address for my house.
We don't live in Shouldland.
bartjan@ix:~$ ping6 slashdot.org
unknown host
bartjan@ix:~$
Maybe about time to update this story from 2003??
maybe we should just say "the Internet is full!" and call it a day...there's already too much crap floating around anyway!
older modems / routers are a issue as well and who knows what bugs are in them that will only show up with higher IPV6 use.
How meany people are useing say the modems from there ISP that may be a few years old that does not have IPV6.
That won't work in the long-term. The problem with carrier-grade NAT is that the ISPs have to... maintain carrier-grade NAT.
Network Address Translation is a stateful protocol, and it's orders of magnitude more expensive to maintain connection tracking on a per-connection basis for your customers than it is to simply route packets between networks. Even ISPs that use Deep Packet Inspection have the luxury of looking at selected traffic flows; carrier-grade NAT has to cover everything or it doesn't work.
"Evil company X is threatening to restrict our rights! Let's all get together to stop--OOOH! SHINEY!!!" -- AC
So why would they go to IPv6, which will cost money, while sticking with IPv4 will bring in money.
Yes, and I'm certain a similar business model sat on the desk of RIM Executives...and we see just how far their "if it ain't broke, don't fix it" mentality has taken them.
If ISP's want to take this mentality, fine. Just don't expect to be in business past the next decade.
ISPs don't want to do carrier-grade NAT, because then they have to maintain carrier-grade NAT.
CGN is a stateful protocol, meaning that each of their implementing-boxes needs to maintain and process state for each data flow to or from your devices. That's no big deal for a single home, but it's a problem for a carrier. If the boxes are too far towards the customer-end of their network, they will be small but they will also be numerous, making maintenance more frequent. If the boxes are too far towards the core of their network, an ISP will only need a few, but the hardware requirements are much heftier to provide acceptable performance. (Already, bittorrent can saturate some of the cheaper home routers).
Simply routing packets is technically far, far easier than running network address translation. Even ISPs that use deep-packet inspection have the option of turning it off if things go wrong -- the network fails open. Carrier grade NAT doesn't have that option.
"Evil company X is threatening to restrict our rights! Let's all get together to stop--OOOH! SHINEY!!!" -- AC
older modems / routers are a issue as well and who knows what bugs are in them that will only show up with higher IPV6 use.
How meany people are useing say the modems from there ISP that may be a few years old that does not have IPV6.
Considering that IPv6 adoption from a software standpoint has literally been around for years now, I would consider this actually less of an issue, not more.
In other words, if you are still running hardware such as modems and routers that have issues with IPv6 adoption that cannot be overcome, then it's time to replace your shit, because it's as old as the IPv4 mentality keeping it there.
I'm taking classes to obtain my CCNA. The class still revolves around IPv4. If the admins don't know IPv6, they'll stick to what they know until they have no choice to buy a book on ipv6, learn the differences, and upgrade. In addition, most business won't want to upgrade until they have to as it is an additional expense.
IPv6 is coming. But it's not something that will be everywhere tomorrow. It will take time... As old equipment fails and is replaced with IPv6 capable hardware, slowly the internet will change over.
It will get to a point where whoever is left on IPv4 will switch over within a short time period - within a few years - but that's only after most of the equipment has already been replaced, and the networking staff have been required to read a book or take classes on the technical differences between the two so they can configure the hardware properly.
Updating Cisco CCNA to revolve mainly on IPv6 wouldn't be such a bad idea either.
A con does not make the number of pros zero. Learn to count.
http://www.startnetworks.info/2011/08/ipv6-and-ipv4-headers.html
"Due to all these reasons, IPv6 headers are more efficient and less CPU intense to Routers than IPv4 headers. "
Comment removed based on user account deletion
Then we replace the modems.
I recently signed up for a Xen Linux vps thru a vendor to run a mail server on, I provisioned it with Debian/squeeze, and while installing everything, I happened to notice that the apt-get sessions were talking to the Debian repos via ipv6. Was kinda startled, as I'm not used to seeing those humongous ipv6 addresses.. The vps vendor gives you at no extra charge two v4 addresses and three v6 addresses. Although I see in their blog, they are dropping the v4s to one per vps without a significant extra charge starting this month. If anybody's looking for a 512mb Xen vps at a truly awesome price, check out Virpus Networks. In the past I'd always gone with OpenVZ slices as they were the cheapest as my "projects" requiring a vps are personal, and have a VERY low budget. But I wanted to get away from some problems that my last OpenVZ vendor had, and I found Virpus offering a 512mb Xen vps for less than I'd been paying for the 512mb OpenVZ slice.. Anyway, have nothing to do with Virpus other than being a satisfied customer...
THANK YOU, Edward Snowden!! Americans owe you a debt of gratitude (whether they know it or not..)
They can still find it.
Try IPv9¾
There are two types of people in the world: Those who crave closure
There should only be one prefix you have to worry about and if you forget it you can look at any other computer on the network. Then just assign your servers each a small number.
For your case with VMs coming and going it would not be at all hard (and would probably result in better testing) to go the ISP route and assign a unique name to every address and then just report that name to your testers and devs. Reusing the name is exactly the same as reusing the ip address. Then you just have a series of machine names. testvm1, testvm2, testvm3, ... etc.
Really none of this is very hard, confusing or cumbersome. It just takes someone asking: "How do I make this work?" instead of thinking "Oh no! that is going to be horrible." and looking for excuses not to make it work.
You've pretty much just described 6to4. We have it already.
I've been waiting for the IPV6 killer application to show its head. Until then I don’t think Joe public will know or care what IPV6 is and why they should use it.
So I mention this here in the hopes that it will light somebodies bulb and somebody will probably correct me on this, but I always thought IPV6 included global multicast, which would make lots of new application possible. Imagine being able to stream content from your home to any number of people without the need for a costly connection. Kinda makes bit torrent look so last century.
6to4 is an extension which is optional as opposed to an intrinsic part of the protocol. This distinction is important.
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.
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.
Unless we come up with a viable DNS RBL for ipv6, the killer app for ipv6 is going to be spam. Hey mister, wanna buy a Rolex?
I hope someone is working on services like this. I can also imagine one heckofa bot net once we get all those soda machines and
refrigerators online.
dreaded scurrilous bit-twiddler from Oklahoma
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.
Again, 6to4 is a patch, not a properly designed transition interface. E.g. from wikipedia:
6to4 does not facilitate interoperation between IPv4-only hosts and IPv6-only hosts. 6to4 is simply a transparent mechanism used as a transport layer between IPv6 nodes.
Due to the high levels of misconfigured hosts and poor performance observed, an advisory about how 6to4 should be deployed was published in August 2011.
Moreover, 6to4 encapsulates IPv4 addresses in IPv6 2002: addresses, which is the reverse of what I'm suggesting.
I've been telling everyone since before the protocol was formalized that it would take a long time to be adopted the way it was designed. Then, just like now people gave silly arguments why I was wrong. Well here we are 16 or so years after I first raised these objections and IPv6 is still less than 1% of the net.
IPv6 ain't working. This should pretty much be clear to all, since it is not being widely adopted. The IPv6 proponents can down moderate those who point the flaws all they want but the facts speak for themselves.
A more constructive approach was to take steps to facilitate its adoption, such as tunneling, the IPv6 day and the IPv6 experiment. It didn't work. Fourteen years since it has been introduced with IPv4 address space running out rapidly and still only 1% of the internet. At this point we have to believe that nothing short of a completely new protocol will succeed.
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.
Privacy extensions are enabled by default in Windows, Mac OS X (since 10.7), and iOS (since version 4.3).
But it doesn't keep ISP's from moving to permanent, static IP addresses. So privacy extensions will "blur" the PC's within a single household together and keep stalking firms (um "ad agencies") from tracking you as you move between coffee shops*, but, in practice, all household traffic you generate will be branded with the same permanent, unique address.
I'm not poo-pooing IPv6, that's just an unfortunate drawback that comes with all of its advantages.
*Tracking you by IP, that is, there are still cookies, local storage, browser fingerprinting, etc.
-1, Too Many Layers Of Abstraction
Start removing classes for use in the IPv4 arena.
Right now, ISPs, esp. in America, are not converting because they do not need to. BUT, to speed it up, all that needs to happen is to require that 5% of the IPs be returned every year or so, starting 1 year out. That will pretty much force the situation.
And for those that will scream that this is not right, BS. It is needed. Long needed.
I prefer the "u" in honour as it seems to be missing these days.
Doesn't really make much difference.
Presumablly each customer will be allocated a v6 prefix just like they are allocated a v4 address now. Combine that with privicy extensions and it will be easy to track to a property but difficult to track beyond that.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
But it doesn't keep ISP's from moving to permanent, static IP addresses.
I wish my ISP could offer me static IPv6, but they currently can't do it!. Right now I have a dynamic /48....
In England, we are lucky, most geolocation services get the city info wrong, I doubt they will be geolocation services which can 100% identify a property for some time, and then it would probably be against EU law on privacy grounds.
FBSD uses the EUI-64 convention, where the MAC address is obvious. It's good to know that iOS and OS-X haven't gone w/ that.
But since an ISP will give one a whole link - be it /64, or a subnet, such as /60, /56 or /48, isn't it obvious that the decision of whether to use static or dynamic addresses (or indeed a combination) is w/ the end user? Not to forget - in IPv6 - unlike in IPv4, multiple IP addresses are allowed on a node.
Test VMs? Why not put them in DHCP under IPv6? Have your usual prefix, followed by something like a code range to indicate that it's a VM, and then let it cycle the numbers under DHCP6? Like if one has 2001:a:b:c:add::[hhhh] where the last word is the random number assigned to the VM, which can range from 0x1 to 0xffff?
1998 called and they want your argument back. The fact is the sort hardware needed to build connections, store them in memory, and do the actual translation is just not that expensive anymore.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Last time I was out to buy a modem, I couldn't find a single one reasonably priced (within 1000% of the cheapest model's price) model that supported IPv6.
I use it as bridge, but most people will have a problem with it.
Rethinking email
6to4 does not facilitate interoperation between IPv4-only hosts and IPv6-only hosts.
Neither does your idea. It requires that v4-only hosts be taught how to speak it, the same as 6to4 does.
Moreover, 6to4 encapsulates IPv4 addresses in IPv6 2002: addresses, which is the reverse of what I'm suggesting.
Surely you are not suggesting that we encapsulate v6 addresses inside v4 addresses. That's not going to work.
Heh, my ISP offers a "semi-static" /56 currently to IPv6 clients. "Semi" static in that, while it hasn't changed yet after over a year of use, they offer no guarantees they won't change something in the future that makes it dynamic :)
Well I don't know "why", but many ISPs around here offer or are starting to offer IPv6. None are thinking about doing carrier-grade NAT (with the exception of some of the cheaper mobile phone networks, and frankly, I don't really have a problem with it for phones ... not like I'm running a server on my phone, plus you can usually pay a nominal sum for a 'real' IP if required).
People want real IPs and any decent ISP will offer them. Simpler to administer for them, and not really much of a cost - they just make sure they always buy IPv6-compatible hardware and software over the course of their normal upgrade cycle, and eventually they will be able to offer IPv6.
When will they come up with an easy/cheap "out of the box" solution for small/medium business so they can plug their dsl & cable modem and have some redundant connection?
Yes i know there are workarounds with NAT66. Wasn't that one of the selling points of ipv6 - not to have to use NAT ?
Describes the dual-stack solution where IPv4 and IPv6 coexists on the same network. This standard dates from 2005, is widely used, and works well. When the tipping point comes, the speed of transition will come as a great surprise to many. Probably within weeks rather than months.
In England, we are lucky, most geolocation services get the city info wrong,
AIUI the free geolocation services are basically built on freely available data while the pay services supplement that with data from their own research. If the ISPs don't make the data easilly available (I don't think there is any obligation on an ISP to post where in the country and allocation is being used) the free databases won't have it. If the ISPs put users from different places in one subnet then the pay databases won't have it either.
But when I wrote that post I wasn't thinking of publically available geolocation services, I was thinking of the government (who can demand information from your ISP) and possiblly big companies (who can correlate IPs used for one activity with those used for another).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
In my experience, most IPv4 private internets use 10/8 or 192.168/16. I haven't seen any using 172.16/12, so I guess that could be used for a VPN if one end is using 10/8 and the other 192.168/16.
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.
Not if the subnet allocation itself changes from time to time.
It requires that v4-only hosts be taught how to speak it, the same as 6to4 does.
No it does not. If they don't speak IPv6 they simply route the packet as if it was IPv4. Only the host destination needs to speak IPv6 and since it is addressed to a port, it does not require the IP stack to speak IPv6, only the server listening to that port.
Surely you are not suggesting that we encapsulate v6 addresses inside v4 addresses. That's not going to work.
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. The gatway uses that part to route the packet for the next leg of the trip. This is the exact same trick used by virtual switching in ATM networks as well as MPLS.
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.
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.
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.
Just because you cannot engineer past the details it doesn't mean it can't be done. Since we have IPv6 on top of IPv4 we can take back most of the IPv4 addresses from every organization. Essentially only border routers need to have IPv4 addresses. Think about it, institutions which currently have thousands or even tens of thousands of IP addresses would go down to a few hundred IPv4 addresses.
Once the packet reaches the IPv4 border 4to6 router the packet traverses the rest of the journey using either intra network IPv6 addresses or private IPv4 addresses,, not unlike NATs. The difference is that you can publicize your NAT+internal_IP address as an IPv6 address to the entire world, whereas it is a bit more of a kludge to make a NAT'ed computer visible to the entire 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.
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. There are very few complete end-to-end IPv6 paths currently on the public Internet. 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.
Heck not even slashdot or www.MIT.edu speak IPv6.
Again, think about it. This should tell you an awful lot about where things stand today.
> As a result, we have a nasty Nash equilibrium: nobody can improve their own situation by unilaterally adopting IPv6.'"
The problem is that nearly everyone pushing IPv6 is so hot and bothered by NAT and the way 99.7% of people use routers that they're overlooking the most obvious way to spearhead nearly-overnight ipv6 adoption: grafting ipv6 onto NAT at the router level so the devices on the consumer side of the router can have 192.168.x.x or 10.x.x.x IP addresses, but have a public IPv6 transparently (and bidirectionally) mapped to it in a 1:1 and deterministic manner. THEN, as the mood strikes and/if they feel sufficiently motivated someday, they can take the next step & give their devices IPv6 addresses one at a time as they see fit, and transparently NAT ipv4 traffic to them with the same router.
For example, suppose your ISP assigns you the following IP addresses: a DHCP-assigned IPv4 address like 64.244.118.17, and an IPv6 /48 prefix like 2001:C80:a72d:db33::.
On day one, you have 4 internet-connected IP webcams assigned to 192.168.100.10 (port 8100), 11 (port 8110), 12 (port 8120) , and 13 (port 8130). Your router is 192.168.100.1, and your computers, tablets, and other devices have DHCP-assigned addresses between 192.168.100.100 and 192.168.100.200. Fairly normal, no? Now, enter the magic IPv6-aware router. You obviously have ports 8100, 8110, 8120, and 8130 of your public IPv4 address forwarded to the cameras. However, you ALSO have ALL ports of 2001:C80:a72d:db33:192:168:100:10 DMZ-forwarded to 192.168.100.10. Ditto for the rest:
2001:C80:a72d:db33:192:168:100:11 is DMZ-forwarded to 192.168.100.11
2001:C80:a72d:db33:192:168:100:12 is DMZ-forwarded to 192.168.100.12
2001:C80:a72d:db33:192:168:100:13 is DMZ-forwarded to 192.168.100.13
(yes, I know 192.168.100.x is decimal, and IPv6 uses hex. 100, 10, 11, and 12 also happen to be valid values for IPv6 address chunks. At the end of the day, they're mostly ornamental mnemonic tools to let our happy homeowner keep his internal, external, IPv4 and IPv6 addresses and port mappings straight, and spare him from having to try and memorize unholy and unmemorable IPv6 abominations like 2001:C80:a72d:db33:1b93:7dca:2819:ff29
OK, so admittedly, at this point, you've gone through a fair amount of manual setup labor, and played with it long enough to verify that it works. However, you discover that your favorite webcam-viewing Android app can't deal with IPv6 addreses, so you abandon the project for a few months.
The following year, your ISP announces that it's going to implement CGN. You freak out and panic. Your cameras! Sure enough, the viewer app still doesn't work properly with IPv6. But in your angry search online, you learn about RFC 6346 ( http://www.fastlaneus.com/blog/2011/10/17/ap-an-interesting-alternative-to-large-scale-nat-lsn-or-carrier-grade-nat-cgn/ ), and learn that if you call your ISP and threaten to cancel, they'll let you pay a one-time fee of $25 and set you up with 4096 ports of a public IPv4 address instead. You end up having to remap your ports (since 8100 through 8199 aren't in the block they assigned to you), but you've dodged the bullet. For now.
Two years later, your ISP announces that it's going to start charging $1/month per 16 ports allocated to you through RFC 6346. Dreading the work of remapping your stuff again, you sigh and buy a new webcam app that can work with IPv6 and try it. It works! You call your ISP and tell them to cancel the A+P service entirely.
Keep in mind, you're still using a bunch of IP webcams that will probably never themselves support IPv6... but thanks to your own router's magic, the camera who thinks of itself as 192.168.100.12 can be transparently reached directly at [2001:C80:a72d:db33:192:168:100:12]:8120. And the new IPv6 webcam you bought last year? Now you can reach it directly at 2001:c80:a72d
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.
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!
Correct, which is one again a simple engineering challenge. You can use port 6 or (6666 in user space if you are not admin) to deploy an IPv6 server in your own computer. Then you can now talk IPv6 from any computer, have the local server translate into IPv4 if need be, or simply pass along as an IPv6 packet if it finds the computer to be IPv6 enabled. The translation into IPv4 uses encapsulation like in 6to4 tunneling and the packet is decoded at the other end also by an IPv6 capable server. From there is routed for the last mile to the actual destination, in a NAT-like manner.
This means that we could have all the applications talk IPv6 in no time and then let the underlying infrastructure migrate to IPv6 in due time. Currently this is clearly not happening at a fast enough rate.
Shhhh. You're forgetting that the people who really dig IPv6 get TOTALLY bent out of shape about home routers in any form.
IMHO, the nearly-religious hatred its advocates have towards NAT and routers is one of the biggest things holding IPv6 back. If they'd just humor people who want to set up an internal network with private IPv6 addresses and NAT it through their router somehow instead of trying to beat them into submission and force them to abandon their shameful backwards ways, we'd be a lot closer to having IPv6 in widespread deployment today.
The problem is, they're absolutely HELLBENT on abolishing the handy devices we mostly abuse as ghetto-fabulous firewalls. From the way they talk about routers, you'd think they cost thousands of dollars and make the internet unusable, instead of being something that most people either get for free or pay less than $50 for... maybe $150-250 if they're high-end users who want one that's hackable and can be flashed with custom firmware.
The same trick routers do to allow a dozen devices to share one public IPv4 address could transparently map public IPv6 addresses to devices who identify themselves by internal 192.168.x.x or 10.x.x.x addresses. Better, in fact, because every IPv6 address mapped to an internal IPv4 address by the user's router could enjoy the equivalent of "DMZ" mode port forwarding. Give the same user a public IPv4 address (or at least a fixed range of ports from one, a-la RFC 6346), and every IPv4-only device sitting behind his router can be made fully-accessible to the outside world via both IPv4 and IPv6.
For IPv6-native devices, it's even better. They can have their public IPv6 address, but let the router assign them a phantom 192.168.x.x address, and DMZ-forward all of its ports to their IPv6 address. Create an additional router forwarding rule forwarding port xxxx of the public IPv4 address to port yyyy of the phantom 192.168.x.x address that can be chained with the rule forwarding all of 192.168.x.x's traffic to the device's IPv6 address, and you have an IPv6 device that can be easily reached by IPv4 devices on the other side of the router, too, just like NAT'ed IPv4 devices can be. The bonus is that if IPv6 is talking to IPv6, they can drop the act and communicate directly.
The people who hate routers forget that they're a wonderful way to allow end users to embrace IPv6 at THEIR OWN pace, in ways under THEIR DIRECT control, instead of dictated by their ISP or someone else's timetable -- usually, in ways that will break expensive legacy hardware that will never work natively under IPv6.
Routers aren't going away. If anything, 10-20 years from now, we'll have legacy devices connected to the rest of the LAN through a $10 POE-powered adapter from China that sits inline between the device and the rest of the network, and acts like a single-port DMZ-forwarding NAT router dedicated to just one device. A box that lets your IPv4-only device be a:b:c:d:e:f:g:h to the rest of the world, while thinking of itself as 192.168.1.1 and never knowing the difference.
If they don't speak IPv6 they simply route the packet as if it was IPv4
This is true for intermediate routers, as it is with 6to4.
Only the host destination needs to speak IPv6
The source needs to understand it too, and if you're updating the source to understand this interop method then your source is no longer v4-only.
and since it is addressed to a port, it does not require the IP stack to speak IPv6, only the server listening to that port
This doesn't even make any sense. If you could send the traffic to the server in the first place, why bother with all this tunnelling of extra bits? Just send your traffic to the server and be done with it!
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
OK, so that's 6to4.
The gatway uses that part to route the packet for the next leg of the trip.
6to4.
This is the exact same trick used by virtual switching in ATM networks as well as MPLS.
And also -- you guessed it -- 6to4.
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!
IPv4 is like a limited natural resource... a limited natural resource that you can divide up and each of the parts are pretty much as good as the original
-- I was raised on the command line, bitch
You are too worked up to understand any of what I'm saying. Sleep over it and come back tomorrow. Meanwhile chew on this: the scheme requires an IPv6 server at both ends if the ends are only IPv4 enabled. When you figure out why you'll understand why you don't even need an IPv6 stack locally for an application to use IPv6 (though ideally you would have one) and why we bother with the tunneling.
Here in Australia, Internode is the only ISP offering full IPv6 to its customers.
Others (Telstra for one) are talking about it but have yet to actually make it available to customers.
Most older home routers don't handle. So what? Replace them.
It would have been trivial to keep the current IPv4 address space
In the sense you mean, no it wouldn't. v6 and v4 routers don't work the same way.
In the sense of all software other than routers that's exactly what you do. You copying the v4 space to the local subnet to create the v4 internet inside your subnet and then address v4 traffic through a gateway. That's standard dual stack.
Thank you. I repeated your point.
There are 2^128 v6 addresses. There are 2^32 v4 addresses. The gateway can only possibly be one way.
So implement 200 technologies to get a system that works worse than v6 rather than implement v6?
Once you get rid of the v4 addresses what is the point?
Expensive legacy hardware sits on a v4 subnet which you map to part of your v6 subnet.
And v6 people don't hate routers, one of the main advantages of v6 is making routers much much faster.
There is still a cost on large ISPs. The holy land of carrier grade NAT would be to NAT the entire ISPs v4 network and route statics for customers who want their own addresses. Even with big iron (think ASR9k) the active translation table can be far beyond the scale of the hardware.
/30 between edges for private networking. Another VRF would carry static routes for customer subnets. Customers would be CGNATed at the PE from a single IP for multiple customers. This makes the router requirements larger at the provider edge but much easier to maintain. Then it would use 2-4 IP addresses (depending on use of /30 or /31 subnets) per PE router and completely free up the pool used for P routers. This means a national scale ISP like Comcast could probably function on a /16.
That said, a more conservative approach would use private IPs for the P routers and internal addresses for the PE routers. Then a VRF would provide a
v6 doesn't allow for the complex routing tables of v4. Geolocation is going to be much better in theory. Privacy laws might mean that ISPs have to not sell this data though.
From what I've seen things have finally started moving. Obviously there are about three sides: the servers, the users and the backbone network between those networks.
Many hosting companies now offer IPv6 by default but most customers don't use it yet. Only very few consumers have IPv6 at home. Even fewer have IPv6 at there workplace. The only exception being a small number of universities and tech companies.
The graphs of my local internet exchange show that the daily peaks are around 9PM which supports the view that most IPv6 users are consumers.
Whenever a large party like Facebook or Youtube turns on IPv6 there is an immediate jump in traffic.
Over the last year the number of sites that offers IPv6 has grown significantly, double or even triple from only a few months ago.
IPv6 is growing on all bases and things are starting to come together.
One of the biggest hold ups to IPV6 implementation is those IP (tier 1 and above) companies that own IPV4 addresses. Now a salable commodity the IPV4 addresses are becoming more valuable as scarcity increases. The volume of IPv4 traffic makes it a more lucrative revenue stream. Implementing V6 will make those V4 addresses worthless, and so where is the incentive to change? Politics and people
this can only work nationwide, not worldwide.
But go for it, if you feel like killing off your nation's internet
Right, just like we cannot use a few bits to label IPv4 traffic over ATM... oh wait!
As I said, we map many IPv6 addresses into a single IPv4 and use encapsulation to encode the remaining part. Not unlike NATs which use the local address translation table to tease apart many things being mapped to a single IP address, but in this case we use the extra bits encapsulated in the packet.
Once the packet reaches a fully IPv6 capable node it gets send on IPv6 or we use private address space for the journey to complete over IPv4, again, not unlike NATs.
not to forget, that they removed NAT, without thinking about loadbalancing, multihoming and topology hiding at all.
thats what i like about protocols by comitee: its like politicans thinking about their own pockets first.
That is a problem. But if they have that issue, they should give /64 links to their customers, and leave the static/dynamic decision to them!
Exactly. Now every your device will be scanned for open ports and possibly exploited.
Coding etudes
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.
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.
Only because the protocol wasn't made backward compatible. One easy way to make IPv4 only nodes compatible with IPv6 applications would have been to preserve the old IPv4 prefixes. Say if an IPv6 application wants to talk to an IPv6 address X1:X2:X3:X4 where each of the Xi's is a 32 bit chunk you can pass the packet through IPv4 to destination X1 port 6. That is inside the other application domain, which has to be IPv6 aware (otherwise why are you trying to talk to it using an IPv6 app?). Then this node grabs the packet and from then on is treated as an IPv6 address within that network. Even better, if the final destination is IPv4-only aware, then the IPv6 node becomes a NAT like device which de-encapsulates the packet and passes it on to IPv4 (private) address X2.
Subnets would be X1:X2. There is no reason X1:0:: would know anything about X1:X2:0:: structure.
If you mean setting up arbitrary gateways via. DNS, you just pass the IPv6 packet inside an IPv4 packed and do 4over6. That's already part of the protocol, for example RFC 5747.
You just pointed to a recent, experimental RFC from two years ago proposing, experimentally, exactly what I'm suggesting. This proves two things (1) it is not part of the protocol and (2) I'm not alone when pointing out the flaws on the IPv6 design.
Hell even P2P networks will work as long as there's enough "active" hosts to talk to the passive ones.
It's not just enough "active" hosts (which I assume means hosts with permission to control their own port forwarding); it's also that these hosts have to be in the same swarm. Two machines downloading different files are in different swarms, and two different sessions of a multiplayer video game are in different swarms.
When we run out you'll probably have to pay a little to have a full IPv4 address to yourself, just like many now charge a little extra for a fixed IP
Go Daddy, for example, charges about $70 per year extra for a full IPv4 address, which is pretty much a requirement for HTTPS until Windows XP and Android 2.x are no longer in use. (The built-in SSL stack on those systems does not support Server Name Indication.)
http://meetings.ripe.net/ripe-55/presentations/bush-ipv6-transition.pdf
It's a presentation I keep coming back to again and again (every single time somebody asks me "why don't people deploy more IPv6?").
Yes, the font and colors used will make your eyes water (I really wonder if he actually chose them that way on purpose :) ). But the actual content is just as accurate now as it was in 2007, and it comes from someone who actually has quite a bit of experience working with this stuff...
Look a little more into the subject, and you will see that 6to4 does not offer backward compatibility in any way, shape or form. It is simply a way for IPv6 "islands" to communicate over an IPv4 network.
The real problem, however, is getting an IPv6-only host to communicate with an IPv4-only host. Until we have that, there is no backward compatibility to speak of. And so far, the only mechanism that can do that (at least partly) is a form of NAT - NAT64. And that is still in its infancy, works only one way (v6 client to v4 server), and brings with it all the disadvantages of NAT (which we are trying so hard to avoid by moving to IPv6).
Even though I do not agree with his solution to the problem (I don't think his multicast solution would have solved the problem), the OP (Alomex) is right - there is no backward compatibility built into IPv6. And this is what has hindered IPv6 adoption from the very beginning.
It's not quite what you are suggesting. While I admit I never heard of RFC 5747 before, it seems to discuss a way for IPv4-only islands to communicate over an IPv6-only backbone (something like 6to4 in reverse). Which means it doesn't help with backward compatibility in any way (just like 6to4 doesn't).
In the sense you mean, no it wouldn't. v6 and v4 routers don't work the same way.
Can you elaborate on that? The actual routing process is exactly the same, it's just the headers that are different.
That's standard dual stack.
And "standard dual stack" means having two separate networks - one that only speaks IPv4, and one that only speaks IPv6. With no way to communicate between the two. And this is the real issue.
First off I think the discussion here has more or less proven you don't know enough about IPv6 to talk about "flaws in IPv6 design". That issue about who was supposed to do the unwrapping in your routing suggestion was not a minor mistake it shows you don't really understand how routing works now or under v6. Second, every flaw you've mentioned would equally have applied to IPv4 over the protocols it replaced like ARPNet, DECNet or NetBEUI. All protocols are incompatible with most other protocols. That's not a flaw, it is just a fact. IPv6 was not designed as a minor upgrade of v4 anymore and IPv4 was not designed as a minor upgrade of ARP. Third, most of what you have described is stuff that is part of implementing any protocol. There are already people providing IPv6 over IPv4
http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers . Since 1999 tunnels have existed. Tunnels have existed in Windows since Windows 2000 ::/0 2/::$ipv4a pub
ipv6 install
ipv6 rtu
ipv6 adu 2/$ipv6b
nothing had to change in IPv6 for this to exist. I just pointed to an example showing that everything you could want is already implemented in v6. You'll notice that this RFC leaves v6 alone.
Around here the cheapest option costs about $40.
Rethinking email
Can you elaborate on that? The actual routing process is exactly the same, it's just the headers that are different.
No... The routing process isn't close to the same. There is no capability in IPv6 for a routing table. That goes away. A router handling a particular route is simply implementing a particular bit. So if I'm sending a packet to you in v6 and we disagree on 37 bits there are 37 virtual routers (there may be more one virtual router implemented on a physical router) between you and I exactly. Nothing like that is true of IPv4 where you have complex routing tables. IPv6 makes routing much less complex in exchange for bring latency down. Given that we can't do much about the speed of light along the paths packets are traveling, and most of the features we want are going to involve increasing latency to reduce jitter, this is one of the few opportunities we have for total latency reduction.
And "standard dual stack" means having two separate networks - one that only speaks IPv4, and one that only speaks IPv6. With no way to communicate between the two. And this is the real issue.
Of course they communicate. There is a gateway in between. Your cell phone does this today.
IPv6 A wants to talk to IPv4 B:
1) A gets a dynamic IPv4 addresses assigned to it (unless (4) below).
2) A sends IPv4 packets wrapped inside IPv6 packets to a gateway device which unwraps those packets and sends them to B. Or the dual stack goes all the way and A is routable in which case the packet never gets wrapped.
3) B responds to the virtual IP address. When it does, the gateway wraps B's responses and sends them to A. And or if the dual stack goes all the way through and A can get the packets directly.
B wants to initiate with A.
4) Since A wanted to receive traffic it has setup its own permanent gateway with a fixed permanent v4 address
5) Everything else is like (3).
What is not the case though, what started the discussion with GP is that every v6 address is reachable by v4. As traffic moves to v6, a smaller percentage of v6 services will be offered on the v4 internet, and v4 will become a less and less functional subset of the internet. That's good, that's what we want. That's why this website is on HTML and not Gopher.
The GP was intermixing the use of protocol and the culture around a protocol. Most technology have associated cultures. DNS is part of IPv4 as it is used.
A proper upgrade path has been planned and is being executed. As for the 1% adoption rate. That's entirely false. Cell traffic which is mainly v6 is about 30% of the internet's traffic. What is 1% right now is v6 clients accessing v6 services and frankly that's because carriers can't handle v6 services. That has nothing to do with end users.
" Now every your device will be scanned for open ports and possibly exploited."
Yeah, it's too bad firewalls don't exist.
I don't because I can't - Nothing I have supports IPv6 and until someone makes a router capable of NAT'ing between IPv6 and IPv4 I'm basically stuck.
Really?
Do you use Windows? Because that supports IPv6, since XP. If not, then maybe Linux? That supports IPv6, since 2.4. Or if not that, then maybe OSX, which supports IPv6 since... er, dunno, 10.something. Heck, the BSDs support IPv6, even though they've been dying for years.
I'm pretty sure you use stuff that supports IPv6.
Well, it is backwards compatible. There's a "version" field in the IP header, just set that to 4 for v4 and 6 for v6. You can run both of those over the same link and neither will break the other. Any v6 host that wants to speak to a v4 host just has to do it with v4. It's very simple.
The real problem, however, is getting an IPv6-only host to communicate with an IPv4-only host. Until we have that, there is no backward compatibility to speak of.
OK, there are two ways I could respond to this, depending on what you meant by "IPv4-only host". Did you mean a v6-capable host that has no v6 connectivity? In which case the answer is 6to4. That's how a host that understands v6 but has no v6 connectivity can send and receive packets to v6 hosts over a v4-only network.
But perhaps what you were really trying to say is that you want this communication to happen with a computer with no v6 stack (e.g. something running Linux 2.2), or with an unconfigured/disabled v6 stack. In other words, you want a way for v4 hosts to send packets using v4 to v6 addresses, and a way for v6 hosts to send packets using v6 to v4 addresses, and you want to do it without updating legacy v4-only OSs. The v6->v4 case is easy enough. The problem is the v4->v6 case. Via the pidgeon hole principle, it's fundamentally impossible to specify which v6 computer you want to send a packet to using v4 alone, because there's just not enough address bits in v4 to specify the destination.
This impossibility is why IPv6 has no way to do it.
As I said, we map many IPv6 addresses into a single IPv4 and use encapsulation to encode the remaining part. Not unlike NATs which use the local address translation table to tease apart many things being mapped to a single IP address, but in this case we use the extra bits encapsulated in the packet.
Once the packet reaches a fully IPv6 capable node it gets send on IPv6
This, right here, is exactly how 6to4 works.
or we use private address space for the journey to complete over IPv4, again, not unlike NATs.
This isn't. This is basically a NAT64 (or NAT46, rather) step on top. It's not really worth it in the general case; just do native v6 over this part, unless there's some real reason you can't do v6 on the hosts (if you're still on Linux 2.2, for instance).
What I keep trying to tell you is that the ideas you're complaining we "should have done", have in fact been done already. They're not integrated directly into v6 because that would make no sense; 6to4 as a tunnelling protocol is transparent to the IPv6 side and is thus optional (and it would be very bad if it wasn't, since we'd be forced to deal with the limited space and fragmentation in v4 until the end of time -- instead we can get rid of it as each network goes native v6) and NAT46 is stateful, which is obviously not doable in a stateless L3 protocol.
These things are available, and have always been part of the intended transition mechanisms for v6.
No... The routing process isn't close to the same. There is no capability in IPv6 for a routing table. That goes away. A router handling a particular route is simply implementing a particular bit.
Uhh... what. No. Routing in v6 is fundamentally the same as in v4. v6 has routing tables. Take a look at `ip -4 route show` and `ip -6 route show` on a dual-stack Linux router (or just look at the manpage for the syntax for manipulating the tables) and you'll see how similar they are.
It'll look something like this, based on the output from my own router:
~# ip -4 route show
:: dev eth1 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295
198.51.100.0/24 dev eth1 proto kernel scope link src 198.51.100.148
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
default via 198.51.100.1 dev eth1
~# ip -6 route show
2001:470:db8:42::/64 via
2001:470:91f3:1::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:470:db8:42::1 dev eth1 metric 1024 mtu 1480 advmss 1420 hoplimit 4294967295
No real difference there.
I'm sure you can probably configure Linux to do whatever you want. It is mainly designed to allow you to split routes.But no that's not the way it is going to work.
3 bits = format prefix (right now always 001)
13 bits = TLA ID = top level identifier
8 bits = RESV reserved expansion (this is where nasty routing stuff will end up in the future)
16 bits = NLA ID identifiers within carriers / ISPs
16 bits = subnet identifier
64 bits = interface identifier
So right now it is not variable it is a series of binary calls getting you to a subnet based on those 29 key bits. Nothing like IPv4 setup with tables.
Woah, woah, woah. We don't hate home routers. Routers are absolutely essential for the internet. It couldn't function at its current scale without routers. Every home should have a router on-site. Any ISP rolling out v6 in a way that prevents users from having their own routers is doing it wrong and they suck. Routers are nice. We want more routing in the world, not less!
What we don't want is ubiquous NAT on all those routers. NAT is just a pain, it breaks a huge ton of stuff without giving you any advantages in return. We need to get away from that.
That said, you can certainly do some nifty and useful things with NAT64 and NAT46, like allowing remote v6 nodes to connect to a local v4-only legacy device. I do that myself to poll my managed switch with SNMP. That's a useful ability for a router to have. But by default, just push v6 to your end hosts without using NAT. Pretty much all of them support v6 themselves just fine.
That's at the administrative level, not the technical level. At the technical level, v6 routing is the same as v4 routing.
Also your table doesn't really reflect the administrative splits that we're seeing on the internet, other than the first 3 bits and the last 64 bits. For instance, many ISPs only give a /56, /60 or /64 to end users, who have a "subnet identifier" part of the address that is 8, 4 or 0 bits long.
Or similarly, ARIN allocates /32s to LIRs, but actually reserves a /29 for them -- for instance, take the allocations around 2001:470::/32: the next 7 /32s are unallocated, and the next allocation is 2001:478::/32. The next one after that is 2001:480::/32. In this case ARIN have reserved 3 bits for expansion of the /32s -- but note that this isn't nasty routing stuff, the space is being left deliberately so as to avoid nasty routing fragmentation in the future.
There's also the IANA global unicast address assignment list, which has allocations from all over the shop.
You've got the right idea in the sense that allocations are heirarchical, but the strict bit boundaries are mostly ignored. And it's all administrative anyway; the computers doing the routing couldn't care less.
Well, it is backwards compatible. There's a "version" field in the IP header, just set that to 4 for v4 and 6 for v6.
I suggest you have a look at the term "backward compatibility", and try to understand what I am talking about. Quote: "a product or technology is backward or downward compatible if it can work with input generated by an older product or technology.".
Simply specifying a version number does NOT make a product backward compatible.
If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).
In other words, you want a way for v4 hosts to send packets using v4 to v6 addresses, and a way for v6 hosts to send packets using v6 to v4 addresses, and you want to do it without updating legacy v4-only OSs.
Exactly. Because there is no way you will update the entire Internet (or, on a smaller scale, all the components and legacy applications of an enterprise) all at once. And until you do, you will need your shiny new IPv6-enabled machine to access everything else.
The v6->v4 case is easy enough
No, it isn't (if you do not agree, please feel free to tell me how it is). And please remember that "I'll just put an IPv4 address on it" is not a solution - that will just make it an IPv4 machine as well. And then, why bother adding IPv6 to it??
It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space). Yes, there is more to it than that (you would need gateways capable of "translating" between that prefix and IPv4), but that is one idea.
Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?
Via the pigeon hole principle
Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).
If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem. It might even be an incentive for the host's owner to upgrade :) . But that case will only come into play many years later, when we actually have an IPv6-only internet.
There is no capability in IPv6 for a routing table. That goes away.
No it doesn't. And it cannot. There still is a routing table, it's just... bigger :) (not that big as you would expect though, due to the larger subnets and better aggregation. In theory, at least).
In fact, one of the major selling points of IPv6 is that the subnetting and routing remain the same as in IPv4 (making things a bit easier to understand for administrators).
So if I'm sending a packet to you in v6 and we disagree on 37 bits there are 37 virtual routers (there may be more one virtual router implemented on a physical router) between you and I exactly.
That makes no sense to me. Do you have any kind of reference for the idea that "a bit in the address = a virtual router"?
IPv6 A wants to talk to IPv4 B:
1) A gets a dynamic IPv4 addresses assigned to it (unless (4) below).
Congratulations - your IPv6-only is now also an IPv4 host! That does not solve the original problem - getting an IPv6-only host to talk to an IPv4-only host. Aka "compatibility".
What is not the case though, what started the discussion with GP is that every v6 address is reachable by v4. As traffic moves to v6, a smaller percentage of v6 services will be offered on the v4 internet, and v4 will become a less and less functional subset of the internet. That's good, that's what we want.
I completely agree with you there (see a previous comment of mine). Getting stuff on the IPv6-only Internet might actually persuade a lot of host owners to upgrade.
Until we have an IPv6 Internet however, we need to make sure that people who move to IPv6 can still access the existing IPv4-only services. This is where the v6-to-v4 compatibility is necessary. And that compatibility was completely overlooked.
And no, "just add an IPv4 address to your host" doesn't cut it. If I'm going to have to run IPv4 to access my services, why bother with IPv6 at all?
This, right here, is exactly how 6to4 works.
Correct. I'm proposing a superset of 6to4 as part of the protocol.
Look, at a higher level, IPv6 was designed to be a flag day transition. When this didn't work people started proposing transition protocols like 6to4 in the hope that they would ease the transition. Fifteen years later it hasn't happened.
What I'm trying to argue is that, clearly, making IPv6 a flag day protocol was a mistake and all the patches that have been proposed (none of which cover all the things I'm proposing) should have been part of the design of the protocol from day one.
We could have made IPv6 such that all applications could go IPv6 native the next day as opposed to hosts. From then on all addresses at the app level are now treated as IPv6, have the IANA issue only IPv6 addresses from then on, and have a simple IPv6 server on the localhost take care of the translation to IPv4 if the host itself is not IPv6 native. Remember software is easy to change, hardware is expensive to upgrade,
All of the above eventually partially happened, in random order and piecemeal fashion. Is it really that difficult for you to see what is inherently wrong with that? Do you not take home any lessons from the dismal state of adoption of IPv6?
If you don't see any lessons from those facts there is little I can tell you that will change your mind.
getting an IPv6-only host to talk to an IPv4-only host. Aka "compatibility".
That's not the strategy, assuming by host you mean all the way up the chain. Somewhere someone has to be doing 6to4. That is the compatibility strategy that 6to4 exists for a while. And having 6to4 be a service is useful for the important reason that at some point in the future it can be turned off or become an addition fee generating service for service providers or ISPs. The way most ISPs don't support Usenet anymore even though they did a decade ago. When IPv6 hosts can't / won't talk to them, that's probably how you get the last 20% off IPv4 network. Which leaves the IPv4 network as a purely isolated legacy network that ISPs aren't supporting and the only people on it are people who desperately need to be on it for some reason.
Until we have an IPv6 Internet however, we need to make sure that people who move to IPv6 can still access the existing IPv4-only services. This is where the v6-to-v4 compatibility is necessary. And that compatibility was completely overlooked.
We don't want full compatibility you want degraded compatibility. And the reason is because it encourages those IPv4 services to move to IPv6. And that is precisely what we have today with ISPs offering 6 to 4 gateways where some important features (for services) like geolocation break.
And no, "just add an IPv4 address to your host" doesn't cut it. If I'm going to have to run IPv4 to access my services, why bother with IPv6 at all?
1) For carriers / ISPs because their growth is directly tied to their ability to allocate addresses, and the top level agencies don't have anymore to give out.
2) For cell phones / homes / small businesses because you don't have a choice in the matter and / or v4 addresses are an extra charge.
3) After step (1) For the public facing web or many B2B services because that is where your customers are. You want performance or features from being IPv6 in any IPv6 world.
4) For larger businesses eventually after (2) you have to maintain a IPv6 network that is substantial and maintaining a true dual stack is expensive and confusing. It is just easier to move most of the company over to IPv6 rather than have constant gateways.
We are between steps (1) and (2) right now. (3) will happen once the carriers and ISPs are more ready.
I'm not sure if I understand the distinction you are making between technical and administrative.
I have two pipes I need to push lots of stuff through:
Strategy 1: there is a particular marking that controls which pipe it goes in
Strategy 2: I read the marketing, look stuff up in a table and pick the pipe.
Strategy 2 is much slower. Right now we are build the system around 1. And Strategy 1 is one of the very few opportunities we have to cut latency. I certainly agree we could implement routing on IPv6 using strategy 2, a protocol doesn't tell you how you route. But yes, the routers do care. The simpler the routing strategy the more quickly they can decide on how to handle the packet. That allows for much "bigger" pipes per router.
I think the more common issue is that since most corporate intranets are likely to use Class C private addresses, chances are that 2 totally separate entities may be using 192.168/16, and then 2 nodes on either end have the same addresses, making them much more of a pain to network.
While ARIN may be pretty generous w/ doling them out (like they've been w/ IPv4), I believe that both APNIC and RIPE will give out a maximum of /56, and require a justification of one wants a /48. I think the protocol would have done well, or would do better, by having the entire top half of the address the global prefix, and split the lower half b/w the subnet and the interface ID.
If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).
Well, I looked at RFC 4893 section 4.2, and the very first thing it says is Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. Is that the example you were thinking about? Because it sounds like roughly the same problem, and solution, v6 and v4 have.
No, it isn't (if you do not agree, please feel free to tell me how it is). [...] It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space).
That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.
Via the pigeon hole principle
Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).
If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem.
Um... what? No, this is a huge problem. You can't just ignore it. You need bi-directional communication or it's useless. There's no point making it possible to send packets to v4 hosts with v6 if you don't also make it possible for the v4 host to respond.
Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?
OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack", which means that we run IPv4 and IPv6 on the same network, at the same time. You won't "move" to IPv6. What you do instead is add IPv6 to the network, which gives you the benefits of IPv6. Then, at some later date, you might remove v4 from the network. Of course you can't remove v4 from the network now, because you'll lose access to Slashdot -- but that's not a reason to not add IPv6 to the network, it's just a reason to not remove IPv4 from it.
Well, I looked at RFC 4893 section 4.2, and the very first thing it says is Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. Is that the example you were thinking about? Because it sounds like roughly the same problem, and solution, v6 and v4 have.
Keep reading beyond the first phrase. And you will find this: However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it).
This is called actually the important part of the transition strategy. And it is completely missing in IPv6.
That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.
And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".
No, this is a huge problem. You can't just ignore it. You need bi-directional communication or it's useless. There's no point making it possible to send packets to v4 hosts with v6 if you don't also make it possible for the v4 host to respond.
I'm not ignoring it - I'm saying that an IPv4-only host does not need to be able to address the entire IPv6 space in order to respond. There are translation mechanisms that allow bidirectional communication with only one side being able to initiate the connection. You might actually have heard about one - it's called NAT.
OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack"
No need for sarcasm - I really don't feel the need for this to degenerate into a flame war. You seem to be confusing "transition" with "no problem, we'll just run two completely separate networks and we'll call it transition". Some day you may realize that there is a very big difference between the two.
And yes, dual stack does exactly that - run two separate networks, totally separate from each other ("ships in the night"). And think about it - if I'll have the resources, address space, knowledge and manpower to keep running that IPv4 network for as long as necessary (your misnamed "transition period"), and everybody else will keep doing that, why exactly would I bother to dedicate more resources and manpower to run an additional, separate network (IPv6)?
"without thinking about loadbalancing, multihoming and topology hiding at all."
actually, they did think about it. Just because you are ignorant of a feature doesn't mean it doesn't exist.
Keep reading beyond the first phrase. And you will find this: However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it).
It sounds somewhat akin to 6to4. I'm not very familiar with BGP, but I did some thinking based on what I do know and I came to the conclusion that doing backwards compatibility the way BGP does it would be similar to the IPv4/IPv6 case if every v4 host was already aware of how to do 6to4. Since this isn't true for existing v4 hosts, and we've already established that we don't want to modify the existing hosts, it wouldn't work for IPv6.
That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.
And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".
Yes, that was the point I was making.
I'm not ignoring it - I'm saying that an IPv4-only host does not need to be able to address the entire IPv6 space in order to respond. There are translation mechanisms that allow bidirectional communication with only one side being able to initiate the connection. You might actually have heard about one - it's called NAT.
IPv6 is stateless. Any transition mechanism you want to integrate with it must also be stateless. NAT64 is stateful, so it doesn't count. You can run it on top, sure, and that can be a useful thing to do -- but the original point of your post was a complaint about something like it not being an integral part of the protocol, and I was attempting to explain why it's not possible.
You seem to be confusing "transition" with "no problem, we'll just run two completely separate networks and we'll call it transition". Some day you may realize that there is a very big difference between the two.
That is how we're doing the transition from a v4-only internet to a v6-only internet though. I'm not sure what else I can call it. Don't forget that computers can be present on both networks at the same time. It's not like it's an either/or choice (and indeed if it was, I'd agree that a mechanism of communicating between the two networks would be required.)
And think about it - if I'll have the resources, address space, knowledge and manpower to keep running that IPv4 network for as long as necessary, and everybody else will keep doing that, why exactly would I bother to dedicate more resources and manpower to run an additional, separate network (IPv6)?
That's a big "if"... but the answer is "because it saves you resources and manpower".
Look, at a higher level, IPv6 was designed to be a flag day transition. [...] What I'm trying to argue is that, clearly, making IPv6 a flag day protocol was a mistake
IPv6 was not designed to be a flag day transition. It was designed to be transitioned to gradually. Tunnels were expected to be part of the transition.
We could have made IPv6 such that all applications could go IPv6 native the next day as opposed to hosts.
Do you realize what you're saying here? You're saying that upgrading the software is too difficult, so let's just upgrade all the software instead. This makes no sense.
We could have made IPv6 such that...
Hm, let's look at this from a different angle: how IPv6 was actually designed. IPv6 has a very simple backwards compatibility mechanism in it already. Basically, if you want to talk to a v4 host... you use v4. Adding v6 connectivity to a host does not affect its ability to use v4 at all. The host will be able to do everything it could before, plus it can also talk to v6 hosts.
Why is this insufficient?
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
Your comment was in direct response to my observation *UNMODIFIED* IPv4 hosts cannot access the IPv6 network no matter how IPv6 was designed.
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 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.
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.
I came to the conclusion that doing backwards compatibility the way BGP does it would be similar to the IPv4/IPv6 case if every v4 host was already aware of how to do 6to4.
In one of my previous posts, I linked to the definition of http://en.wikipedia.org/wiki/Backward_compatibility. You either didn't read it, or didn't understand it - the whole idea behind compatibility is getting the thing to work without modifying the other devices that talk to it.
I'm not saying that the exact same solution that was applied for BGP could be used for IP. They are completely different protocols, with different sets of rules. I just gave you two examples of what real compatibility looks like, since you still seem to believe that 6to4 offers it.
IPv6 is stateless. Any transition mechanism you want to integrate with it must also be stateless. NAT64 is stateful, so it doesn't count.
By your own logic, IPv4 is stateless, NAT is stateful, so NAT doesn't count. Yet the world at large disagrees with you - NAT works just fine, and it is the thing that has extended IPv4's useful life by years. Yes, it has its own set of problems, and we all would like to get rid of it - but until then, it works just fine, stateful or not.
That is how we're doing the transition from a v4-only internet to a v6-only internet though. I'm not sure what else I can call it.
Totally agree with you - it's basically the only solution we have right now. But the fact that it's the only solution doesn't make it a good one. Because this "we'll just run dual stack" thing, in the end, will not lead to an IPv6-ony Internet. It will lead to a world in which most of the computers will be forced to run both IPv4 and IPv6. With network administrators being forced to maintain and update twice the number of ACLs, QoS policies, routing protocols, and so on.
And before you say "no problem, at that point we'll just turn off IPv4!", keep in mind that this will not be possible until there is no IPv4 Internet to speak of. How long do you think that will be? My guess would be on the order of decades...
That's a big "if"... but the answer is "because it saves you resources and manpower".
A big "if", but your logic actually requires it. If we do dual stack, that means that we keep maintaining an IPv4 network. With all that it entails.
And if we're already running that network, how exactly would adding another network (Ipv6) by its side would save anything? Please don't forget that we are talking about the transition here - that transition being done by using dual stack.
It was designed to be transitioned to gradually.
Nope. For all the reasons I explained to you previously, chief being the fact that IPv6 is 100% incompatible with IPv4 on the wire.
Tunnels were expected to be part of the transition.
True. And just as true is the fact that tunnels only solve half the problem. Yes, they help getting new IPv6 hosts to talk to each other (over a potentially non-IPv6 compliant infrastructure). But they do not solve the bigger issue - getting new IPv6 hosts to talk to existing IPv4-only hosts (like, I don't know... the entire Internet?!).
IPv6 has a very simple backwards compatibility mechanism in it already. Basically, if you want to talk to a v4 host... you use v4.
And once again, I strongly suggest that you should read and understand the term "compatibility". I'll give you a hint: "just use the old protocol at the same time" isn't it!
Why is this insufficient?
Because there are only two possibilities: a) we will be able to keep running IPv4 in the foreseeable (or at least short- and medium-term) future, or b) we will not.
In the first case, why bother to add IPv6 to it (and spend a ton of money and manpower on that)? Just because "it's cool"?
And in the second case, there's no way to do dual stack anymore - and where's your "simple mechanism" then?
I'll hazard a guess and say that you've never worked as a network administrator. Or at least not one that has to explain to non-technical people why they need to spend money on technology (in which case, you have been really lucky :) ).
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.
Administrative is how we humans pick which allocations to make. Technical is how routers see the addresses.
On the administrative side, the allocation scheme you suggest in your great-grandparent post... well, take a v4 analogy. In v4, each RIR is allocated a (or multiple) class A networks. Inside those networks, each ISPs/companies are allocated a (or multiple) class C networks. The first 8 bits are the RIR ID, the next 16 are the company ID and the last 8 are the interface identifier.
But in reality we don't actually do it like that. The RIRs get /8s, sure, but companies get /<whatever they need>, and might subnet further if they need to. You can't actually split the address up neatly into well-defined parts.
v6 is the same. The first 3 bits are "001", and we seem to have settled on /64s for subnets (mostly, but not everywhere!). But for the rest of the address? /32 is a common LIR size, unless the LIR is too big, in which case they get something bigger. And ISPs give end users anywhere from 16 to 0 subnet bits each. There is no fixed split that applies to all addresses.
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.
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.
(I'm getting quite tempted to look up the actual code that does routing in Linux, so I have something to point to as proof rather than just the circumstantial evidence of `ip` and what I've seen from using IPv6. I'll post back if I do manage to find it.)
the whole idea behind compatibility is getting the thing to work without modifying the other devices that talk to it. I'm not saying that the exact same solution that was applied for BGP could be used for IP.
Right, that was where I was going. With BGP, when you pass a message to an AS (regardless of whether the destination AS is 16-bit or 32-bit, or whether or not you support 32-bit), the packet has the true destination (the IP) inside it.
It's sorta like 6to4, where the true IPv6 destination is inside the v4 packet. This style of tunneling works as backwards compatibility for BGP because BGP nodes already know how to do it, but it doesn't work for IPv6 because IPv4 nodes don't already know about it.
I believe that IPv4/IPv6 are incapable of doing this sort of backwards compatibility. The only semi-exception is...
By your own logic, IPv4 is stateless, NAT is stateful, so NAT doesn't count. Yet the world at large disagrees with you - NAT works just fine, and it is the thing that has extended IPv4's useful life by years. Yes, it has its own set of problems, and we all would like to get rid of it - but until then, it works just fine, stateful or not.
It certainly has. I wouldn't count NAT as integrated though, which was the point I was making. It's an optional thing on top.
NAT64 is the semi-exception; it's a way to get a v6 client to talk to a v4 server (but not the other way around!)
Because this "we'll just run dual stack" thing, in the end, will not lead to an IPv6-ony Internet. It will lead to a world in which most of the computers will be forced to run both IPv4 and IPv6. With network administrators being forced to maintain and update twice the number of ACLs, QoS policies, routing protocols, and so on.
...
A big "if", but your logic actually requires it. If we do dual stack, that means that we keep maintaining an IPv4 network. With all that it entails. [...] And if we're already running that network, how exactly would adding another network (Ipv6) by its side would save anything?
Definitely all true. But consider the costs involved in sticking with a v4-only network, vs a dual-stack network where you can use both v4 and v6.
(Warning: wall of text incoming.)
You've got to NAT all your traffic. This isn't free; you may need to buy some quite beefy hardware to do it fast enough. Merging two networks is a pain, because their private ranges collide. Running servers is a pain. You've got to get enough public IPs for them, which is going to start getting expensive. Or you can put them behind NAT too, but there's limits to doing that -- you can't put two DNS servers behind the same IP, say, and what are you going to do when your ISP is using CGN? You can't port forward to your servers at all then. Split DNS is a pain. Debugging problems with any of this costs money.
Having dual stack on the network allows you to side-step a lot of this. For servers that are fully internal, you don't need v4 at all. You might be able to drop v4 on servers that need external access too (maybe all the external clients are your customers, so you can force that on them -- or maybe you just don't care about losing a few viewers.) Split DNS can go away for those servers.
Merging two corporate networks? You might be able to get away without merging the v4 parts at all, if both sides have v6 -- which means no renumbering.
The less external v4 traffic you do, the less fancy your v4 NAT hardware needs to be. With v6 enabled, 50% of your traffic is v6 today. (That stat is from a big university network -- it's mostly Youtube, but still. I've heard of companies turning it on in branch offices and seeing 90% of their traffic be v6, simply because it's all internal traffic and internal servers had v6.)
Yeah, you need to keep v4 around for remote single-stack servers. But your v4 network is going to get more and more painful to manage as the ad
I wouldn't use the routing code in Linux. Linux isn't used for high performance routers. What you want is IOS (Cisco's not Apple's).
As far as your post I agree with most of it other than the existence of routing tables. My understanding is that there will be no complex lookups. So while it is not the case globally, it will be the case that in individual router will be making a routing decision based on very simple criteria unlike today where there is a table lookup.
I'm guessing you use Internode? I used them when I lived in Sydney, theyr'e great.
And they've decided that everybody gets a static /56 now.
I have a whole bunch of /64's in my /48. The problem is they keep changing every time pppoe reconnects.
Yesterday I had 2406:e000:e26c/48, today I have 2406:e000:e317::/48
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.
Ah, but that seems to be the very nature of PPP - the IPs are dynamic and change every time. Looks like you'd have needed a static connection from your ISP.
The ISP determines whether the prefix is allocated statically or dynamically, the end user determines whether the addresses within the prefix are allocated statically or dynamically. If the prefix is static then trackers can use it to track down to the premisis level regardless of whether the addresses within the prefix are static or dynamic. If the prefix is dynamic then it makes network administration a massive PITA.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
It's perfectly possible to run a PPP server with static mappings from logins to addresses (of course this means you can only have one client at a time per set of login details but that isn't usually too much of a problem).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The holy land of carrier grade NAT would be to NAT the entire ISPs v4 network and route statics for customers who want their own addresses.
That sounds like a bad idea from multiple perspectives, first there is the issue of finding hardware capable of doing it (or finding load balancing hardware). Secondly it means that if routing in the ISP network chooses a different exit point then a different NAT will be used which will break existing sessions. Thirdly if the ISP provides hosting or premium connections with public IPs and a private IP user connects to them then it may not get natted which may cause problems. Fourthly having routing to multiple NATs will break many nat traversal techniques.
If NAT has to happen (and for some ISPs NAT or a similar IP sharing system WILL have to happen) it's much better if it happens near the edge where there is only really a single route. If the ISPs management systems want to see the private addresses then that can easilly be arranged which keeping the NATs near the edge by adding an exception to the NAT rule.
This means a national scale ISP like Comcast could probably function on a /16.
Comcasts problem is they want to keep a flat network for managing their devices and there simply aren't enough private v4 IPs to do that. That is why they are working to move as much as possible to IPv6.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
BS
There was a load of talk about hierarchical routing when IPv6 was being developed but what we actualy ended up with was much the same as we have with IPv4, autonomous systems advertise prefixes over BGP which combine to produce a massive routing table. The table will have less cruft than the IPv4 one both because it's newer (The IPv4 table contains a lot of cruft like legacy allocations where an equivilent allocation wouldn't be PI under current rules, multiple seperate allocations for companies whose IP space needs have grown and so-on) and because IPv6 gives the RIRs room to make allocations sparsely allowing them to extend existing allocations rather than making new ones but that isn't really relavent here..
As with IPv4 autonomous systems are able to route things as they wish within their own networks and as with IPv4 some autonomous systems span multiple continents and as with IPv4 some users traffic may pass for considerable distances over non-ip networks (or tunneled over a non-internet ip network) before entering the providers "general routing" (for example most smaller ISPs in the UK have only on PoP).
Further allocation procedures may make geolocation worse for IPv6 than IPv4. IIRC the default allocation to an ISP is a /32 so if the ISP only gives out a /56 or smaller by default they will probably never need to get any more IPs (how many ISPs really have more than 16 million customers) which means they won't need to worry too much about keeping the RIR happy. I know when I get an IP from freenet6's dutch gateway the geoipv6 database lists it as being in canada.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
6to4 never contributed to IPv6 traffic cause default host policy says prefer IPv4 over IPv6. It only ever contributed to headaches.
This statement seems kind of contradictory to me If 6to4 is causing "headaches" that means hosts must have been using it. Googles stats also indicate that a load of clients were using it at one stage though that number has dropped off more recently
6to4 provided an easy way for people to build experience with ipv6 without having to agree to a possibly onerous list of terms from some tunnel provider and provides a way for users to access v6 only resources (which aren't very numerous yet but they can only become numerous if everyone can reach them) with only a v4 internet connection.
Having said that 6to4 does have it it's problems. Firstly running over IP directly may have made it slightly more efficient but it also meant it couldn't really be run behind a NAT box, it would have made far more sense to run it over UDP which can easilly be port forwarded. Secondly and more importantly it has performance and reliability problems because ISPs don't take it seriously. If every dual stack PoP had a 6to4 relay router then 6to4 would be fast and reliable but they don't so 6to4 traffic ends up handled by benevolent third parties who may or may not provide acceptable quality of service.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
a load
I should clarify, by "a load" I meant a significant proportion of total IPv6 traffic at the time, it's still of course tiny compared to IPv4 traffic and pretty small compared to total IPv4 traffic now.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I would assume for geolocation regardless of what the ISP does the /64s will be cleanly marked. Unless of routing is insane the IP addresses are going to follow something like a physical infrastructure. Right now no one is bothering to geolocate IPv6 addresses since their isn't much B2C.
\As for the non table routing, maybe I am wrong on that one. Other people are saying the same.
Look a little more into the subject, and you will see that 6to4 does not offer backward compatibility in any way, shape or form. It is simply a way for IPv6 "islands" to communicate over an IPv4 network.
Note that the "island" can be as small as one host.
The real problems with 6to4 are
1: it doesn't work behind NAT (even with manually configured port forwards) meaning a large proportion of internet hosts can't use it.
2: ISPs haven't taken it seriously leading to inefficient routing. If 6to4 was considered a requirement for a dual stack core router then it would be far more reliable than it is today.
Teredo fixes 1 but it's pretty fragile because it works against the nat rather than working with it and also has the problem of not being taken seriousy by ISPs.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
16 bits = NLA ID identifiers within carriers / ISPs
Assuming you are reffering to rfc2374 then that should be 24 bits.
However it doesn't really matter anyway rfc3587 says that the TLA/NLA structure defined in rfc2374 has been made historic.
The early designers of IPv6 seemed to think the internet was a heirachical network but it never was and probablly never will be. The internet is a collection of ISPs and other companies whose relationships are in a constant state of flux. No large company wants to be stuck with a single provider on pain of readdressing, nor do they want to give multiple IP addresses to each end system with a horriblly complex dns system (which has also been relegated to historic status) to manage them.
So in practice IPv6 is routed the same way IPv4 is, autonomous systems declare what prefixes they can reach over BGP and core routers build up a big table of where to send stuff.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
pretty small compared to total IPv4 traffic now.
Grr that shuold have said compared to total IPv6 traffic now
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I copied this from ARIN.
As for the rest, you are making good points. Next time there is an IPv6 conference I'm going to ask. Bringing back tables strikes me as a huge tragedy. I'd rather large companies have to use variable prefixes, but you could very well be right. Do you have any cites?
Except you can run both IPv4 and IPv6 over the same wire, and they won't break each other, which allows you to add IPv6 to the internet gradually. Your traffic will gradually convert from being v4 to being v6 as other people do the rollout. That's a gradual transition.
The fact that you can roll out v6 on an existing network and not lose any functionality on it, even if nobody else rolls out v6, means that it doesn't require a flag-day transition.
I guess the other way to look at it is that the lack of communication between IPv6 and IPv4 doesn't translate necessarily to a lack of communication between internet hosts, which are the things we actually care about. As such, you can't say that IPv6 is stillborn just because it doesn't integrate a means to get around the pigeon hole problem and do v4<->v6 conversations.
Plus NAT64 is a thing anyway, so if that's what you really want to do, then the option is available, with no need for it to be integrated. (Nobody uses it because dual-stack is easier, so having it available earlier wouldn't have helped v6 deployment.)
Because there are only two possibilities: a) we will be able to keep running IPv4 in the foreseeable (or at least short- and medium-term) future, or b) we will not.
You're simplifying (a) a bit too much. NAT works surprisingly well for outbound connections -- sure, we're heading towards having multiple layers of NAT, which is expensive and is going to be incredibly annoying, but in all fairness an outbound connection does tend to make it through them all.
Where is starts being a real pain is when you need inbound connections. Then it's either difficult (= expensive) or impossible to deal with NAT. (Think SIP, or multiple DNS or SMTP servers behind a single IP -- or just things like multiple web or SSH servers. Now imagine what it'll be like when your ISP puts you behind NAT, and you can't even port forward.)
So ideally, you'll be running your own servers on v6, and use the v4 purely for connecting to other people's legacy v4 servers. You can't just run your servers on v4, because the address shortage and NAT on v4 is a problem.
I think (b) is a long way out for outbound connections. But for inbound connections, it's going to be here far sooner. It's already here for some of us.
In the first case, why bother to add IPv6 to it (and spend a ton of money and manpower on that)? Just because "it's cool"?
I know you've seen it, but for thread continuity I'll link the post I made earlier, where I wall-of-text a bunch of reasons for wanting v6 even when you have v4 (the summary being that it allows you to side-step the problems in your v4 network caused by address shortages).
I'll hazard a guess and say that you've never worked as a network administrator. Or at least not one that has to explain to non-technical people why they need to spend money on technology (in which case, you have been really lucky :) ).
OK, you're right there. But I feel the start of the issue is more that the expense of dealing with NAT in v4 is ongoing and something you're already paying for, and the savings from v6 are in reducing that ongoing expense. Everybody ignores all that and concentrates on the upfront costs of a v6 rollout, because those are obvious and all they care about is next quarter's statement.
I have a static IPv4, they just can't yet offer static v6