IPv6 products, community and services
Large Scale NATs
deployed as a bridge between v4 and v6 in ISP and mobile networks. What
are your thoughts, opinions and advice for operators contemplating
their deployment?
Views: 768
Replies to This Discussion
-
Permalink Reply by Nicolas Filion on -
Hi Bruce,
As seen in a Cisco presentation :
> Facts:
> Obvious: There aren't enough IPv4 addresses to sustain the current v4 model
> Corollary: There aren't enough IPv4 addresses to support the dual stack model
This problem would never happened if we had started the transition a couple of years ago. Now that it is too late, we can't say anymore that "IPv6 will solve the IPv4 address exhaustion problem". It won't solve it because many ISP will encounter this IPv4 exhaust during dual stack transition. They'll have to deal with it just as if IPv6 didn't exist.
This is scary because the most credible driver just disappeared. The remaining drivers are the easier addressing in the long term, the future ipv6-only applications, the yet-to-know killer app, smart grid, etc. It is as important for me but could be less appealing to many.
I posted in a previous blog entry my fear that temporary solution to the IPv4 shortage (LSN) would become permanent like (We all know that temporary solution often become permanent ones.). Fortunately, the devices that will do LSN might come with IPv6 transition technologies. Meaning that the hardware would already be there. If there is not additional hardware to buy ($$$), it would be easier to make justify the move. e.g. The Cisco CGv6 solution bundle all the technologies in a single piece of hardware.
I don't know how things will evolve but I do know that LSN is not cool! :)
-
Permalink Reply by Mikael Lind on -
On the LSN issues topic this presentation from the last IETF is a good summary. They are trying to document the issues of LSN and the idea is to eventually recommend how LSNs should be used to minimize the pain.
http://gogonet.gogo6.com/photo/lsn-issues?context=album&albumId...
-
Permalink Reply by Ahmed Abu-Abed on -
Cisco's presentation is making the wrong corollary in that it assumes only dual-stack needs to be implemented during a transition, AND that public IPv4 addresses are needed during a transition.
A more practical approach to IPv6 transition is "dual-stack where you can, tunnel where you must".
As DS-Lite and TSP (in the gogo6 client and CPE) have shown, one can use v4-in-v6 tunneling to offer end users with BOTH a public v6 address AND a private v4 address to overcome the v4 exhaustion problem, and then some form of CG NAT will take care of the private v4 addressing mechanism. The end effect is lesser public v4 addresses will be consumed, and this is what Comcast is testing this year to prepare them for the v6 transition.
The killer app is coming, and its likely LTE networks which are the 4G cellular upgrades that all mobile operators are planning a transition to within 2 to 3 years. Unlike 3G and HSPA, the LTE handsets will be IP enabled and on all the time so they need to have an IPv6 address attached to them.
-
Permalink Reply by Philippe Verdy on -
Cisco is wrong. Other solutions running at the application level, not just the routing/network level will be needed. Notably HTTP proxies. And it will still not solve the problem. Other solutions will involve CDNs (notably because video on the Internet doubles each year, and wil represent more than 70% of the trafic in 2013, and today's volume of data (static contents) will represent the volume of today's videos.
With the advent of 4G (LTE), all the existing problems experienced on mobile 3G networks will be even worse...
Yes we need an emergency migration to dual stacks, but Cisco does not propose this dual stack before a long process that will emerge only in 4-5 years. It is currently selling the VERY TEMPORARY "CGv2" solution that will not last more than 1 year. Sold too expensive too !
ISPs must all realize that dual stack will be needed for a much faster transition, where IPv6 should become the major source of traffic worldwide. Forget all tunnels, NATs, and proxies. Only an end-to-end pure IPv6 connectivity will work.
We'll very soon have TWO separate internets: the Internet v2, accessible only to those users that have a pure end-to-end conectivity in IPV6, and the Internet v1 that will be fragmented very rapidly to to the impossibility to provide interoperability with IPv6-based Internet v2, but also with other parts of the IPv4-based Internet v1.
All that it means is that Internet v1 (on IPv4) will soon become a series of private islands. I can easily see these islands already forming in Asia, then in Europe in 2-3 years (about 2013-1014), then everywhere else (starting 2015).
The internet v1 is almost dead. Be prepared.
-
Permalink Reply by James Knott on -
Some companies are still blind to that. A couple of weeks ago, I was shopping around for some network equipment for use at work, where we already run IPv6. Also, we're installing cell network equipment for a major Canadian carrier and all that stuff is IPv6 ready. When I asked an Adtran sales guy about IPv6, he said their equipment doesn't support it as there's no need for it. He seemed oblivious to what the networking world is doing. Even though companies like Cisco have supported IPv6 for quite some time, Adtran appears stuck in the dark ages. You can even buy consumer level gear now that supports IPv6!
BTW, I told that Adtran sales guy that any network gear that doesn't support IPv6 these days is obsolete.
-
Permalink Reply by Dallam Oliver-Lee on
-
Watchguard is introducing IPv6 to their devices.
Fireware XTM OS version 11.4.1 and 11.4.2 already supports link-local IPv6 and expect to have routable public IPv6 support by Q4 2011.
http://www.watchguard.com/ipv6/
http://www.watchguard.com/help/docs/wsm/11-xtm/en-US/index_Left.htm...
I have a Watchguard X700 loaded with pfsense 2.0. pfsense is getting ready to provide IPv6 support for it's (stable) OS.
http://doc.pfsense.org/index.php/Is_there_IPv6_support_available
Here is my idea to provide IPv6 to older non-IPv6 devices. Setup a proxy server on a dual stack IPv4 and IPv6 server. Let the IPv4 device point to the proxy server. Has anyone done this yet? And has been successful? This could be useful for older systems and/or while upgrading older systems and/or network equipment.
-
Permalink Reply by Philippe Verdy on
-
I use that already, for my own home network, or for some hosts and applications running in a LAN, which will take long to support IPv6. Technically, it's just simpler to install a dual-stacked proxy that forwards the incoming IPv4 or IPv6 trafic to a private IPv4 network on which existing applications can continue working for long, without changes (but then there's a longer term problem in scaling the proxy, but this can add years before we really need to have all applications IPv6-ready and not requiring this proxy, but accessible directly in IPv6 in bridged mode). I prefer the HTTP proxy stragegy to the 6to4 and Teredo tunnels, which are much slower, and to LSN or NAT/NAT+PAT (not working reliably, and not a proven technology compared to HTTP proxies), if all what is needed is to support a HTTP(S) web service.
-
Permalink Reply by Jeff Doyle on -
Hi Bruce,
Very late joining this discussion, but I've been having some conversations about LSNs lately that are relevant.
Considering that LSNs exist primarily as a solution to the fact that end users need new addresses which can only be IPv6, but must reach content that is still overwhelmingly IPv4, I wonder if LSNs will have an unexpected consequence (as Nicolas points out). That is, even though end users begin running more and more on IPv6, content providers will still be seeing mostly IPv4 traffic coming from the "outside" of LSNs. If so, this is likely to remove most incentives for content providers to dual stack, and the "core" of the Internet remains IPv4: Only the "user edges" become IPv6.
Certainly service providers (primarily broadband providers) will not like this: They will want to remove the operational and capital expenses of maintaining two IP versions as soon as they can. But without an incentive to content providers, service providers could be stuck with LSNs for a long time.
-
Permalink Reply by Mikael Lind on
-
My view is that LSN will create an incentive for content providers to user IPv6 as it will increase the risk of applications breaking. The problems can be not being able to open specific port or that you run out of available port. A lot of the more advanced net based service use a big number of ports today and this will have to change if all the users are behind LSNs.
I agree that incentive isn't as big as users moving to IPv6 only but an increased risk of services failing might be a big enough incentive. The incentive might also be in reduced development cost when developing for IPv6 compared to LSN environments.
-
Permalink Reply by Eric Nute on -
Also, marketers like to use IP addresses to confirm identity of the endpoint. Yes, cookies and all that, but the CDNs (or, at least, their customers) will want the identity data that gets mucked up by NAT
-
Permalink Reply by James Bradley on
-
What if we considered the tunnel to ipv4 over ipv6 during transition, aswell as incorporating ipv4 addresses at the dns server for the service provider into ipv6 addresses. With the address space allocated to the service provider, this is feasible with redirects into tunnels, and provides the possibility of phasing ipv4 out over a longer time scale.
Some large scale ISP's are going to be interested in /32 prefixes, which is going to incorporate their entire user base + the ipv4 internet. If 8.8.8.8 was made into 2001::8:8:8:8 (for example) would it hurt in the transition period if it enabled connection to both, and if the apps fail, temporary dual stack can be given back (without consuming entire address space)? For the majority of users in this country, it would be acceptable, as they wouldn't notice the change (vista and windows 7 use native ipv6 before ipv4, and I have seen faster connections on a vista machine of lower specm even though the ipv6 pipe was much smaller than the ipv4).
-
Permalink Reply by Philippe Verdy on
-
Actually, some ISPs are already interested in shorter prefixes. One of them in France uses a /19 prefix for its worldwide IPv6 backbone (OpenTransit): this is the current shortest prefix allocated (or aggregated) in IPv6, as seen in BGP.
But /32 prefixes are very common: most prefixes announced in BGP are /32 in fact, much more than /48 or /56; /64 are exceptions (being progressively phased out and withdrawn, due to current agressive aggregations, which I think are a real bonus of IPv6, for shorter AS Path lengths, much less AS in the core, simpler routing, no need for NAT or costly tunnels and proxies)...
What I really want to see now is the complete abandon of tunnels as a way to deploy IPv6 over IPv4. The actual work to prepare now, and urgently, is to think about solutions for interconnecting IPv6-only networks to reach IPv4 sites. Notably for the existing billion of smartphone users (even if they were using IPv4 only, they can't een have a routable IPv4 address, and they are forced to use tunnels or proxies, and this is a severe problem for the preservation of "net neutrality": we all want massive adoption of native IPv6, even if those tunnels or proxies will remain to reach IPv4 sites.
But the most popular IPv4 sites have already dedicated resources to be reachable directly in native IPv6 (think Google, Facebook, Youtube, iTunes, MegaUpload, and all CDNs used by TV and radios on the web; soon you'll have all the SIP users from mobile broadband users of tablets and smartphones).
In 2015, it will become very costly to have a IPv4 address for oneself (this is already the case since long now for Internet hosting: most websites are now hosted behind a shared frontal HTTP proxy, such as Squid, and servers are configured in a private LAN using private IPv4 addresses; not really a NAT, but the HTTP proxy does the same thing; proxies will soon integrate the SPDY technology to help solve another wellknown problem in IPV4: the STARVATION of PORT NUMBERS; because IPv4 hosting providers have now difficulties to manage the trafic coming to their frontal Squid proxies when they constnatly need larger IPv4 address blocks, just to reroute this trafic to their hosted servers...).
Sponsors
gogoNET LIVE! 4
IPv6 Resource Center
IPv6 Product Information
© 2013 Created by gogo6.
