Categories
Growing the Internet Infrastructure and Community Development Internet Exchange Points (IXPs)

Why Is So Much Internet Traffic Leaving Pakistan?

This article appeared first on the APNIC website.

At the recent SANOG meeting held in my homeland, Pakistan, I wanted to provide the local community with some insights into the importance of Internet exchanges (IXs), specifically the need to host content locally.

Knowing that data is king among network operators, I set up a virtual machine as soon as I arrived to collect information on several key metrics, including latency and the hosting location of .pk domains. Needless to say, the results were surprising.

How long does it take to connect to public Domain Name System (DNS) services?

First, I tested for latency, specifically the time it takes to PING three of the most popular public DNS services: Cloudflare DNS (1.1.1.1), Google Public DNS (8.8.8.8), and Quad9 (9.9.9.9). PING is not the best way to test DNS but this is for reachability purpose only.

Before leaving my home in Sydney, Australia, I did the same to offer a comparison. As you can see from the results in Figure 1, all were below 1ms.

Figure 1: Latency measurements to connect to public DNS services in Sydney, Australia

The results for Pakistan were less consistent.

Cloudflare was the best of the bunch with an average of 3ms, thanks largely to the three data centres they opened in Karachi, Lahore, and Islamabad in late 2018.

Google was second and even though it has several caches hosted in Pakistan, its latency hovered around 25ms.

Quad9, which has no local points-of-presence, came in at a very slow 203ms.

What this experiment shows is the importance of hosting services locally. We could expect to see a further reduction in latency if such services were also hosted at a local IX, as it would reduce the number of hops for those that peer with it to one – the benefits of which would be reduced transit costs, with the savings being handed down to customers.

Currently, Pakistan has one IX, PKIX, which has two exchange points – one in Islamabad and one in Karachi – with 17 members peering with it.

Where are “local” websites hosted?

As we’ve seen so far, the best way to reduce latency for DNS services is to make them local, so packets don’t have to travel extreme distances. The same can be said for web content too, whereby websites hosted locally should, in theory, be faster to connect to than those hosted internationally.

So, for my second experiment, I looked at where websites with .pk country code top-level domains (ccTLDs) were being hosted.

The time of my test was short so I could only get public data, which was around 15,000 .pk domains. However, like the latency test, it provided a very clear picture of the current situation.

Of the 14,927 .pk domains, only 1,541 are being hosted by Internet service providers (ISPs) or entities registered in Pakistan, and another 1,304 are being hosted by Cloudflare. That’s less than 20% of sites that, you would think, would be targeting local users. Instead, more than 80% of “local content” is being hosted in servers outside of Pakistan, and, as such, is subject to international transit costs and increased latency.

Figure 2: DNS records for .pk domains

Digging deeper, I also looked it up for gov.pk, who you would think are targeting the people in Pakistan, right? Out of 431 gov.pk domains I found in the 15,000 domain addresses, only 72 are registered or advertised by Pakistani entities, 28 are with Cloudflare, and the remaining 331 are outside of Pakistan.

Figure 3: DNS records for gov.pk domains

Needless to say, I was quite surprised that so many local council websites are hosted outside of Pakistan, most likely because they were cheap.

Finally, I looked at edu.pk. For a university to host something outside of Pakistan and not within the university is blasphemy for me. Unfortunately, this is the case for the majority of edu.pk sites with fewer than 20% hosted locally.

Figure 4: DNS records for edu.pk domains

How many websites have Quad A records?

The IPv6 Task Force was established in Pakistan around 2006/07 during which time it built a test network between several ISPs. Unfortunately, IPv6 never caught the limelight beyond testing and enabling in core networks, and capability remains less than 1%.

I was hoping that because many websites are hosted outside Pakistan, that content might have been accessible via IPv6. Unfortunately, this wasn’t the case either, with the exception of Cloudflare.

Figure 5: AAAA records for .pk domains

One thing that’s not clear from Figure 5 is that of the 1,304 websites hosted by Cloudflare, why were only 1,087 responding to AAAA requests? Have some turned off IPv6? If so, why? I plan on digging deeper into this using the virtual machine generously provided by Rapid Compute (a cloud services provider in Pakistan).

Finally, it’s worth pointing out that all of the above would be a lot worse if it weren’t for Cloudflare setting up its Content Delivery Networks (CDNs) in Pakistan in 2018. However, if more CDNs are set up in Pakistan, there needs to be more local content available for them to host. This surely cannot be too difficult for an economy with more than 200 million people.

Internet Exchange Points are vital to bringing faster and more affordable Internet to people. Learn how you can support them!

Categories
Mutually Agreed Norms for Routing Security (MANRS) Strengthening the Internet

Let’s Improve Routing Security at APRICOT 2020

Internet builders in Asia-Pacific get together around this time every year at APRICOT to learn from each other and other leaders from around the world. Routing security will be a key theme, and we will be sharing in multiple sessions why the MANRS initiative is important to the global routing system.

Also called the Asia-Pacific Regional Internet Conference on Operational Technologies, the conference is the largest meeting of the technical community in the region. It draws many of the world’s best Internet engineers, operators, researchers, service providers, and policy enthusiasts from over 50 countries to learn, share, and network.

Held annually, the ten-day meeting consists of workshops, tutorials, and conference sessions, birds-of-a-feather (BoFs) sessions, and peering forums all with the goal of spreading the knowledge needed to run and expand the Internet.

Technical training workshops will run from Feb 12 to 16, and the conference itself from 17 to 21 in Melbourne, Australia.

Our team at the Mutually Agreed Norms for Routing Security (MANRS) initiative will speak at various sessions throughout the conference, including the Resource Public Key Infrastructure (RPKI) Deployathon on 17 February that I will facilitate. I will also be chairing the inaugural APNIC Routing Security/RPKI SIG on 20 February.

RPKI is a public key infrastructure framework that allows holders of Internet number resources to make verifiable information available about those resources, such as Route Origin Authorisations (ROA), essentially authenticated routing annoucements. RPKI uses a public key infrastructure that creates a chain of resource certificates allowing RPKI users to validate that a network announcing routes for specific Internet addresses actually is authorized by their regional Internet registry (RIR) to have those addresses. To learn more, please join us at the session.

We will also hold a MANRS Community Meeting on 20 February to get together with MANRS participants in the region. Join us if you are part of our growing community!

If you would like to learn more about or join MANRS, our team will be at our booth throughout the conference, so please come over to chat with us about the state of routing security of your networks. You may even get a MANRS T-shirt!

The wider Internet Society team will also be at APRICOT. Rajnesh Singh, Regional Vice-President, Asia-Pacific, will speak at APNIC Global Reports on 20 February with many of our partners.

We will hold an informal gathering with the community on 19 February, so if you are an Internet Society member or simply want to know more, please feel free to come by.

If you are interested in attending the conference you can still register at the event’s website. But if you cannot make it in person, you can also follow the sessions via livestream using the links on the session pages.


Image by Denise Jans via Unsplash

Categories
Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (BGP)

Route Leak Causes Major Google Outage

Google recently faced a major outage in many parts of the world thanks to a BGP leak. This incident that was caused by a Nigerian ISP – Mainone – occurred on 12 November 2018 between 21.10 and 22.35 UTC, and was identified in tweets from the BGP monitoring service BGPMon, as well as the network monitoring provider Thousand Eyes.

Google also announced the problem through their status page:

We’ve received a report of an issue with Google Cloud Networking as of Monday, 2018-11-12 14:16 US/Pacific. We have reports of Google Cloud IP addresses being erroneously advertised by internet service providers other than Google. We will provide more information by Monday, 2018-11-12 15:00 US/Pacific.

In order to understand this issue, MainOne Inc (AS37282) is peering at IXPN (Internet Exchange Point of Nigeria) in Lagos where Google (AS151169) and China Telecom (AS4809) are also members.

Google (AS15169) advertise their prefixes (more than 500) through the IXPN Route Server, where PCH (Packet Clearing House) collects a daily snapshot of BGP announcements of IXPN. Unfortunately, 212 prefixes (aggregates of those 500+ announcements) from Google were leaked, which was recorded by BGPMon and RIPEstat.

Looking at the RIPE stats it is evident that the first announcement via MainOne Inc (AS37282) was recorded at 21:12 UTC and the issue lasted for more than an hour:

As per the tweet from BGPMon, the issues lasted for 74 minutes:

Looking at the circumstances around this incident, it’s likely this was an inadvertent leak from MainOne caused by a configuration mistake. A Google representative is quoted in ArsTechnical as saying “officials suspect the leak was accidental and not a malicious hijack”, and also added that the affected traffic was encrypted which limited the harm that could result from malicious hijackings.

Later in the same day, the MainOne Twitter account posted on the BGPMon analysis thread, accepting the mistake and assuring the world that corrective measures are now in place:

So this was a configuration mistake that was quickly rectified and didn’t cause any reported financial damage (even though service outages do cause financial and reputational damage to the service provider and its users), but it does demonstrate the problems that can be caused by accidental mistakes, and especially how an actor with bad intent could do a great deal of damage  as with the Amazon Route 53 hijack. It therefore illustrates why greater efforts need to be made towards improving the security and resilience of the Internet.

This BGP leak could have been easily avoided if proper prefix filtering had been undertaken by MainOne (AS37282) or China Telecom (AS4809). It is very difficult for the networks in the middle to block such leaks, because the prefixes are still legitimately originating from the correct AS number (in this scenario AS15169 – Google).

As mentioned in many previous blogs, Mutually Agreed Norms for Routing Security (MANRS) can be part of the solution here. It calls for four simple but concrete actions that ALL network operators should implement to reduce the most common routing threats, including filtering which prevents the propagation of incorrect routing information (the other three are anti-spoofing, address validation, and global coordination).

Network operators have a responsibility to ensure a globally robust and secure routing infrastructure, and your network’s safety depends on a routing infrastructure that weeds out accidental misconfigurations and bad actors. The more network operators who work together, the fewer incidents there will be, and the less damage they can do. It’s time to implement the MANRS actions now!

Categories
Deploy360 Domain Name System (DNS) Improving Technical Security Open Internet Standards Privacy Technology

A Deeper Dive Into Public DNS Resolver Quad9

There are plenty of public DNS resolvers. The best known was Google Public DNS i.e. 8.8.8.8 and 8.8.4.4 for IPv4 and 2001:4860:4860::8888 and 2001:4860:4860::8844 for IPv6. But there are a few other options available now, each with different policies and technical features.

Two new Public DNS resolvers were recently launched. Quad9 (launched Nov 2017) and 1dot1dot1dot1 (launched Apr 2018). We have already covered 1.1.1.1 in detail in a recent blog. So let’s talk about Quad9 (9.9.9.9).

IBM and Packet Clearing House (PCH) partnered with Global Cyber Alliance (GCA) to launch a Global Public Recursive DNS Resolver Service. Quad9 intends to protects users from accessing the overwhelming majority of malware, malicious domains, botnet infrastructure, and more. Leveraging threat intelligence from multiple industry leaders; it currently blocks up to two million threats per day.

A handy little infographic on the Quad9 website helps show how it works. Essentially, you set up Quad 9 as your DNS and when you query a known bad hostname, the DNS servers respond that the domain does not exist (NX DOMAIN or non-existent domain).

Quad 9 provides 2 types of resolvers, “Secure” which provides security features, and “Unsecured” which doesn’t.

Secure IPv4: 9.9.9.9
Secure IPv6: 2620:fe::fe

Unsecured IPv4: 9.9.9.10
Unsecured IPv6: 2620:fe::10

Threat Intelligence on malicious domains comes from 19 threat feeds. 12 partners are publicly listed and include IBM’s X-Force, Abuse.ch, Anti-Phishing Working Group (APWG), Bambenek Consulting, Cisco, F-Secure, mnemonic, Netlab, Payload Security, Proofpoint, RiskIQ, and ThreatSTOP. Seven remaining Threat Intelligence partners are not listed.

Quad9 also uses two whitelisting methods. The first method uses a list of the top one million requested domains from the Majestic Million daily top one million feed. The feed is constantly updated, and the DNS accounts for any changes. The second is a “Gold List” of domains that should remain secure at all times e.g. Microsoft, Amazon, Google etc.

As explained earlier, if the domain is on Quad9’s blacklist, the resolver answers with NXDOMAIN (No Such Domain – this domain does not exist). Let’s see an example of that:

Blacklisted Domain: renovation4all.gr
Source: openphish.com

In the first example, Google Public DNS (8.8.8.8) returns an A record (188.40.68.58), whereas in the second example Quad9 (9.9.9.9) returns NXDOMAIN. Similarly, the “Unsecure” Quad9 (9.9.9.10) returns the A record of the blacklisted domain. Same results for the IPv6.

Privacy

From a privacy point of view, Quad9 is specifically committed to protecting the users’ privacy and its service doesn’t retain request data. As mentioned in their FAQ: “When an entity or an individual is using the Quad9 infrastructure, their IP address is not logged in our system. We, however, log the geo-location of the system (city, state, country) and use this information for malicious campaign and actor analysis, as well as a component of the data we provide our threat intelligence partners.”

In the Quad9 Privacy policy they have clearly highlighted what data they are recording:

We do keep some generalized location information (at the city/metropolitan area level) so that we can conduct debugging and analyze abuse phenomena. We also use the collected information for the creation and sharing of telemetry (timestamp, geolocation, number of hits, first seen, last seen) for contributors, public publishing of general statistics of use of system (protections, threat types, counts, etc.) We do not correlate or combine information from our logs with any personal information that you have provided Quad9 for other services, or with your specific IP address.

When you use Quad9 DNS Services, here is the full list of items that are included in logs:

  • Request domain name, e.g. example.net
  • Record type of requested domain, e.g. A, AAAA, NS, MX, TXT, etc.
  • Transport protocol on which the request arrived, i.e. TCP, UDP, and encryption status of the protocol
  • Origin IP general geolocation information: i.e. geocode, region ID, city ID, and metro code
  • Protocol version IP address – IPv4, or IPv6
  • Response code sent, e.g. SUCCESS, SERVFAIL, NXDOMAIN, etc.
  • Absolute arrival time
  • Name of the Quad9-operated machine that processed this request
  • Quad9 target IP to which this request was addressed (no relation to the user’s IP address)

It is also mentioned in the Privacy policy that Quad9 may keep the following data as summary information, including all the above EXCEPT for data about the DNS record requested:

  • Currently-advertised BGP-summarized IP prefix/netmask of apparent client origin
  • Autonomous system number (BGP ASN) of apparent client origin

All the above data may be kept in full or partial form in permanent archives.

Network Infrastructure

Quad9 is leveraging the Packet Clearing House (PCH) global assets around the world. PCH has Points of Presence (PoPs) in 181 internet Exchange Points all across the world.

Quad9 uses AS19281 to announce following IPv4 and IPv6 prefixes.

IPv4: 9.9.9.0/24, 149.112.112.0/24, 149.112.149.0/24
IPv6: 2620:fe::/48

No ROA found for any prefix.

DNS over TLS

A DNS query is by default sent over a plaintext connection, which makes them vulnerable to eavesdropping by attackers with access to the network channel, reducing the privacy of the person sending the DNS request. DNS over TLS (RFC7858) is a security protocol that forces all connections with DNS servers to be made securely using TLS. This effectively keeps any middle party (ISPs) from seeing what website you’re accessing. Initiation of DNS over TLS is very straightforward. By establishing a connection over a well-known port, clients and servers expect and agree to negotiate a TLS session to secure the channel.

RIPE Labs has published some extensive test results on this.

Final Word

Every step taken towards greater security, privacy, and reliability is a positive one. The addition of Quad9 and APNIC-Labs/CloudFlare’s 1.1.1.1 is definitely going to bring good to the whole internet ecosystem.

Categories
Building Trust Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (BGP)

What Happened? The Amazon Route 53 BGP Hijack to Take Over Ethereum Cryptocurrency Wallets

Yesterday, we published a blog post sharing the news and some initial details about Amazon’s DNS route hijack event to steal Ethereum cryptocurrency from myetherwallet.com. In this post, we’ll explore more details about the incident from the BGP hijack’s perspective.

As noted by Dyn, CloudFlare, and various other entities who monitor Internet routing and health, Amazon’s Route 53 (the DNS service offered by AWS) prefixes were hijacked. A BGP update taken from Isolario suggests that on 24 April, its BGP feeders were correctly receiving 205.251.192.0/23, 205.251.194.0/23, 205.251.196.0/23, 205.251.198.0/23, originated from Amazon (AS16509), until 11:04:00 (UTC). But, at 11:05:41 (UTC), Isolario recorded the first more specific /24 malicious announcements via BGP feeder and the announcements originated from eNET (AS10297) to its peer 1&1 Internet SE (AS8560).

screen shot

RIPE Stats collected the first more specific malicious advertisement at 11:05:42 (UTC) originating from eNET (AS10297), but this time through peer Hurricane Electric (AS6939).

Exactly at the same time, 11:05:42 (UTC), the Isolario BGP feeder received another update originating from eNET (AS10297) and it was also coming via Hurricane Electric (AS6939).

Hurricane Electric has a worldwide presence and as per its own website, it has over 20,000 BGP sessions with over 7,000 different networks via over 180 major exchange points and thousands of customer and private peering ports. Unfortunately, these malicious advertisements were shared with many of their BGP peers, causing a massive re-routing of Amazon’s Route 53 DNS traffic towards a malicious DNS server hosted in the Equinix Chicago IBX. According to a statement from Equinix (as mentioned in blog posts here and here), “The server used in this incident was not an Equinix server but rather customer equipment deployed at one of our Chicago IBX data centres.” Equinix is merely the Data Centre provider, but they also provide Internet Exchange Points; Equinix has more than 25 Internet Exchange Points around the globe. One of the Equinix IXPs is situated in the Chicago IBX.

Interestingly, at 11:05:44, Isolario recorded another advertisement originating from eNET (AS10297) via a different peer i.e. Shaw Communications Inc. (AS6327). Click to enlarge image.

eNET (AS10297) is peering at the Equinix Chicago IX Route Server and must have shared the malicious advertisement; it is evident that Equinix Chicago IX does filter prefixes, otherwise we would have seen a bigger propagation of these advertisements. More likely, eNET (AS10297) has bilateral peering with Hurricane Electric (AS6939), 1&1 Internet SE (AS8560), and Shaw Communications Inc. (AS6327) because all three of them are present at Equinix Chicago IX.

RIPE Stats also recorded a malicious announcement from eNET (AS10297) at 11:05:54 (UTC) via peer BroadbandOne/WV Fibre (AS19151), which is also peering at Equinix Chicago IX.

This BGP hijack saga lasted almost two hours, and both RIPE Stats and Isolario BGP Feeders started seeing malicious specific prefixes withdrawing from the routing table around 12:55 (UTC).

This problem could have been easily avoided if Hurricane Electric (AS6939), 1&1 Internet SE (AS8560), Shaw Communications Inc. (AS6327), and BroadbandOne/WV Fibre (AS19151) had prefix filtering in place. Thankfully, Level3 (AS3356), Cogentco (AS174), and NTT (AS2914) are all MANRS members and had prefix filters in place, or the damage would have been much bigger. As per Dyn they recorded only 15% of their nodes received malicious specific advertisement originated from AS10297, while NLNOG-RING (AS199036) were getting 87 unique paths to 205.251.192.0/23 (one of the Route53 prefix) originating from Amazon (AS16509) at 10am UTC. But when the attack started at 11:05 UTC they installed 15 new paths for 205.251.192.0/24 (one of the malicious more specific prefix) originated from eNET (AS10297). Out of those 15 unique paths, 12 of them were coming via Hurricane Electric (AS6939).

The reason to hijack Amazon’s Route 53 prefixes was to hijack the DNS itself; details of that is further explained in blog posts by global DNS providers such as CloudFlare, Dyn and Quad9.

As discussed in the previous blog, MANRS can be part of the solution here. Mutually Agreed Norms for Routing Security (MANRS) calls for four simple, but concrete actions ALL network operators should take to reduce the most common routing threats. The first is filtering, which prevents the propagation of incorrect routing information. (The others are anti-spoofing, address validation, and global coordination.) If all the operators along the path had implemented the MANRS actions – especially filtering – this would not have propagated across the Internet like it did.

So, once again. What are you waiting for? Be part of the solution and help protect the core. Join MANRS.

Categories
Deploy360 Transport Layer Security (TLS)

MPTCP and TLS 1.3 – Big Announcements from Apple

Apple recently announced some major changes to their operating systems across all platforms during their flagship developer conference WWDC. The Worldwide Developers Conference is where developers can attend sessions and meet with over 1,000 Apple engineers, and this event included a keynote introducing new software (iOS 11, macOS High Seirra and watchOS 4) and hardware (iPad Pro and HomePod) . The 2017 conference was held 5-9 June in San Jose, California, and apart from the other announcements, there are two major developments in the networking area.

  • Support of MPTCP (Multi Path TCP)
  • Support of TLS 1.3

MPTCP (Multi Path TCP) is defined by RFC6824, and has the ambition of enabling the simultaneous use of several IP-addresses/interfaces by modifying TCP to present a regular TCP interface to applications, whilst in fact sending data over several subflows. The benefits include better resource utilization, better throughput and redundancy. Apple has been using MPTCP for their Siri application since the release of iOS 7 in 2013, and according to the statistics presented during the WWDC – Advances Networking event, they have seen 20% (95th Percentile) faster user feedback and a 5 times reduction in network failure.

Apple considers this a great success and in iOS 11 they are opening up the API for MPTCP which they have specifically been using for Siri until now. This requires server support as well, but the good news is that many load balancers already support it, and whilst the main linux kernel doesn’t currently support it, a new kernel with MPTCP support is available from INL (IP Networking Lab, UCL – Belgium). AWS and GCE images are also available, whilst Android images are available for 4.4.x only. Geoff Huston (APNIC) has written a detailed blog on MPTCP.

TLS 1.3 (Transport Layer Security) – The underlying technology that enables secure communication on the Internet is a protocol called Transport Layer Security (TLS), which is an evolution of Secure Sockets Layer (SSL) developed by Netscape in the 1990s. TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0, and was updated with TLS 1.1 that was defined in RFC 4346 in April 2006. The most recent  version, TLS 1.2, was standardized in RFC 5246 in 2008, and is currently supported by the majority of browsers and HTTPS-enabled web services. All TLS versions were further updated in RFC 6176 in March 2011, removing their backward compatibility with SSL so that TLS sessions will not negotiate the use of Secure Sockets Layer (SSL) version 2.0.

TLS 1.3 currently in its draft stage, and was first announced in April 2014. Since then it has undergone many changes, but is expected to become an Internet standard by the end of this year. TLS 1.3 has two main advantages over previous versions:

  • Enhanced security
    • Legacy options, ciphers, and key exchange algorithms removed
    • TLS 1.2 features that have been removed were associated with high profile attacks in the past
  • Improved network efficiency
    • TLS 1.2 requires two round-trips to complete the handshake
    • TLS 1.3 cut the initial handshake into half and require only one round trip.

TLS 1.3 is not enabled by default in iOS 11, but is a huge step forward for web security and performance. Apple also announced support for ECN (Explicit Congestion Notification) during their Advances in Networking session. If you want to check out other announcements, then you can find all the other sessions online.

Deploy360 also aims to help this process, so please take a look at our TLS section to understand why the use of TLS is important.

Categories
Deploy360 IPv6

The Business Case for IPv6 in Pakistan

We had a very successful ION conference in Islamabad on 25 January 2017, and amongst the interesting topics presented at the conference, it’s worth highlighting the statistics on IPv4 and IPv6 allocation in Pakistan. Let me share those in detail here.

As per the APNIC resource delegation data (as of 1 January 2017). There are 5,314,816 IPv4 address allocated to ISPs and enterprises in Pakistan. However, if you look at the graph then it shows PTCL as the holder of nearly 73% IPv4 addresses in Pakistan, leaving the remaining 27% to the rest of the ISPs and enterprises. PTCL is undoubtedly the biggest broadband provider in Pakistan and also provides services to Ufone (telco operator), so you’d expect them to have the largest user base for both wired and mobile broadband services.

The main concern though, is that it’s now only possible to obtain a /22 IPv4 prefix from APNIC (as per the last /8 policy), and those will soon be exhausted. This means that if ISPs need more IPv4 address, the only option will be to buy them open market. The current going rate for IPv4 addresses is around USD 10 for each address  in a /18 block, plus the APNIC transfer fees, which amounts to nearly USD 164K for 16,384 IPv4 addresses.

The other option is deploying Carrier Grade NAT (CGN) to put many users behind a single IPv4 address.In theory, it’s safe to consider that each user may have around 250 concurrent sessions, so with around 65,000 sessions available per IP address, it’s possible to put 250 users behind a single IPv4 address with CGN. The downside though, are that you need powerful boxes to manage that many sessions and it is difficult to guarantee performance.

There’s another graph showing IPv6 delegations in Pakistan, with a very uniform address allocation to all existing APNIC members (with few negligible exceptions). No single entity has an edge over another, and it doesn’t cost anything extra (if you already hold IPv4 addresses) to obtain IPv6 addresses from APNIC. There’s no need to install complex and difficult to manage CGN solutions, nor buy expensive IPv4 addresses from the open market. It’s an open and level playing field for all operators wanting to serve the 200 million plus population of Pakistan.

For many years there was a big debate in Pakistan about the financial benefit of deploying IPv6, but these statistics clearly illustrate the business case for doing it. You can either deploy IPv6 at minimal cost by upgrading some old hardware (very rare), or deploy CGN and buy IPv4 from open market at significant expense. The choice is yours!

Deploy360 aims to help you deploy IPv6, so please take a look at our Start Here page to understand how you can get started with IPv6.