Interesting NATO study examines Dual-Stack Security Threat


This report, generated by experts at the NATO Cooperative Cyber Defence Centre of Excellence, describes some cyber attack vectors which are particular to a dual-stack environment. As the already lengthy and ongoing IPv4 to IPv6 transition continues, the likelihood that a dual-stack environment will persist into the forseeable future makes it important to address these threats.


Consider that as part of this paper, an experiment was undertaken to demonstrate the potential to exfiltrate information from a standard corporate network. The example network had around 100 hosts, ran an IPv4 LAN, and was protected by a firewall and intrusion detection system. One host was pre-compromised for remote access.


Red Teams were employed to attempt to remove sensitive data from the network using tools designed to leverage the transition environment, essentially by creating tunnels within allowed protocols like http, and then sending parts of the exfiltrated data over IPv4 and parts over IPv6. In particular, the ignorance of the LAN operators about the operational status of IPv6 in their networks posed both an attack vector and exfiltration mechanism which allowed for undeteced removal of data even in the presence of various firewalls and intrusion detection devices.


Finally 20 of the world's top Blue Teams were allowed to review the captured data of the Red Team's exfiltration event and asked to detect it. Only one of these teams succeeded.


Within this report is a section describing the results of an discussions with experimenters and with vendors of security software and appliances. Some noteworthy nuggets:


  • IPv6 support is often not implemented due to customers not requesting it
  • Many monitoring tools were initially built with no IPv6 support in mind, and enabling it requires a fundamental redesign of how 128-bit IPv6 addresses are processed (e.g.notasstringsornumbersinhexadecimalordecimal form)
  • Vendors often use open-source detection tools in their products
  • Automated near real-time detection, traffic decapsulation, and payload decoding is not performed due to high resource requirements and introduction of additional network latency
  • Protocol analysis, payload inspection and extraction is supported only for commonly used plain-text protocols (e.g. HTTP, SMTP, FTP)
  • Manual asynchronous traffic analysis could be done by human analyst whenever detection algorithms are incapable of parsing the data or sorting out the false positives


The situation described above has to change if we are to deploy IPv6 either alone or in dual-stack. We hear the Internet of Things demands copious and end-to-end addressing. Which begs the question of where to put the firewall to protect these easily accessible Things? Which begs the question of whether there is an IPv6 firewall capable and cheap enough? Which begs the question "Why not wait on the IPv6 until these things are sorted?" Which leads to our considered understanding that the IPv4 market will persist for a long time yet.

Transfer times examined


Having completed more than two hundred transfers, we are well-placed to discuss the facts about transfer time and the factors that impact transfer time.  We have completed Intra-regional transfers in ARIN, APNIC, RIPE and LACNIC as well as inter-regional transfers from ARIN to APNIC, APNIC to ARIN, ARIN to RIPE,  and even APNIC to RIPE. We have found some variability due to deal particulars but also general rules which apply to different transfer types.


First the facts as we see them.  Here are various transfer types and the average time to completion, starting from the initial transfer request.

  • RIPE PA to RIPE PA  2-4 days
  • RIPE PI to RIPE PI  2 weeks
  • ARIN to RIPE PI 6 weeks
  • ARIN to RIPE PA  4 weeks
  • ARIN to APNIC  4 weeks
  • ARIN to ARIN  1 week if preapproved buyer
  • APNIC to RIPE 7 weeks
  • APNIC to APNIC  1-2 weeks if preapproved buyer

Now the factors that affect transfer time.

  • Buyers who are not pre-approved for the transfer
  • Slow responses of buyer and/or seller to RIR requests
  • Inter-regional transfers dramatically slower
  • RIR experience with transfer type
  • Variable RIR response times

We completed the world's first inter-regional transfer way back in 2012, but the RIRs still have some work to do in the coordination of their efforts required to process an inter-regional transfer.  And in the case of the most common ARIN to APNIC transfers, these two RIRs have been the fastest to process inter-regional transfers, as can be expected with their greater experience and advance up the learning curve.


Still we believe that all transfers leave a lot to be desired in terms of efficiency. What we are doing is creating or updating some database records. That's the essence of a transfer.  And in 2016 updating databases is something that can happen in realtime in an efficient system.  Even coordinated updates. We expect that ARIN has the most experience with inter-regional transfers, and we  hope that ARIN staff concurs with our assessment that tranfers should happen faster, and that all participants should be striving to make the process more efficient.  Hopefully registration staff from each relevant RIR can work together to create a policy-compliant standard protocol which can be followed by both sides and which will lead to faster transfers.


There are of course pre-transfer timelines involving negotiation, contract review, funding, and sometimes "housekeeping" requirements like updating contact information or paying registry fees.  We have found that a relatively simple transaction like the payment of a transfer fee to an RIR can involve a great deal of effort, especially when the payer is out of the region.  We endeavor to make transfers simpler by including fees like this into the escrowed amount, allowing a single international transaction instead of multiple ones. In these cases known fees like transfer fees are paid expeditiously by the escrow agent and timelines compressed.

New Analysis Reveals Benefits of CGN

The report linked ago is chock full of interesting information which supports our contention that CGN is the natural response of the Internet organism to various important stimuli. Because CGN resolves problems at little cost, it has naturally flourished and led to a non-flat Internet topology.

The first important stimulus to the Internet organism is the issue of IPv4 address exhaust. Consumer grade NAT became popular in the timeframe when the rapid growth of the Internet led many to realize that addresses would soon exhaust, in the mid to late 1990s. It became popular to share a single public IP address among many devices, and a whole generation of users became familiar with the ubiquitous block. Now carriers and ISPs are running out of those public IP addresses which they assign to each user, and are realizing they can share their users behind a public IP address in the same manner that their users share multiple devices behind one address. The linked article concludes that ISPs can leverage their IP addresses by a factor of 15:1 without impacting customer browsing experience.

The second important stimulus to which the natural response is CGN is the danger of malevolent intrusion into private networks. The study examined the protective effect that CGN naturally provides against inbound traffic and found that although that protection is not absolute, customers behind NATted IP addresses are up to 800 times less likely to be victims of attack through this vector. So the use of CGN confers a security benefit, but at what cost? Is there a performance penalty?

The study closely examined real-world effects of CGN on customer browsing experience using sophisticated statistical methodologies and concluded that CGN provides no significant impact on the customer browsing experience. But what about customers with more sophisticated requirements, beyond browsing?  The study examined a real pool of users to see how many customers are actualy running servers at their sites, presuming that these customers would require a public IP address. Running port scans to see which customers answered on common ports revealed a scant 0.6% of customers were running servers. So from the customer perspective, CGN does not affect performance and provides some measure of protection against bad actors on the Internet.

The conclusion is obvious. CGN will grow, and that growth will serve to reduce IPv4 exhaust pressure in several ways. First, ISPs who deploy CGN on existing networks will reap a large supply of excess IPv4 address space, which they can sell on the market, reducing prices. Second, ISPs who require space for greenfield deployments will require up to 15X less space through CGN, reducing the market demand for space, also reducing the price. Secondary effects of CGN are a reduction in exhaust pressure on IPv6 transition and a greater understanding that the IPv4 market could last longer than expected with a more stable price curve.

We find that many participants in the market believe it to be a short-term event limited in scale and duration by the hard limits of the 4.3 billion sized 32-bit address pool. They may feel that demand will swamp supply and lead to rising prices, causing them to overbuy if they are buyers, or to refuse to sell if they are sellers.  If we visualize an IPv4 address pool 15 times larger which can be attained via CGN, we can see that there are plenty of addresses that will be available and plenty of time during which they will be traded, and this can lead to a more stable market where participants can rely on future inventory and make rational decisions on purchase sizes. Likewise sellers who understand that there is unlikely to be a run on available space in the future will realize there is little purpose to holding on to underused address space.


Dire Situation in South America

We have been approached by companies in the LACNIC region who have requested space from LACNIC but who have discovered that by a quirk of policy, not only can't they receive the address space from LACNIC, but LACNIC prevents them from receiving those addresses from another LACNIC member who has underutilized space. 

The LACNIC community passed a transfer policy (, but intended that it not come into effect until LACNIC's inventory diminished to the point that for the first time it would not be able to meet a justified need for addresses. So they included a note to that effect above the transfer policy in the policy manual.

This was fine until the LACNIC community later decided to implement policy with two intentions. The first was that the demise of the address pool should be made more gradual by limiting allocations to a maximum size of /22 and six-months between applications. The second intention was to provide available space for newcomers in the market by creating a pool reserved for the provision of a one-time /22 only to new LACNIC  members.

The result of these two polices was to create new pools which had not existed at the time of the adoption of the transfer policy, and these pools are projected to drain very slowly, with LACNIC projecting a total exhaust date sometime around 2024.

So today, LACNIC companies who need more than 1024 addresses every six months find themselves in a dire situation. They can try to find a company to acquire which has unused addresss space. They can engage in a lease of address space from some third party. Or they can open an office in another region to "shop" for an RIR who will allow them to purchase the rights to more IPv4 addresses. Finally, they can implement Carrier Grade NAT to share the addresses they already have.

None of these are good options, but given the current policy environment we can help those in this situation while we try to effect a change in policy which will enable open ip trading in Latin America.

Please consider voicing support for this change of policy here.

Is IPv4 exhaust limiting Internet growth?

recent blog posting claims that IPv4 exhaust is posing a "very major" constraint of Internet growth. The author describes the routing table as managing to "collapse the entire current state of the Internet into a single database." But the routing database says nothing about increasing CGN deployment, because such deployment is invisible to the routing table. Although there is much to be learned from the routing table, we must dig deeper to detect any increase in CGN deployment.

Routers are stateless, they don't know how many ports any ip address is using, but when sharing connections behind NAT, the number of ports being used by the NATTed address will increase. If we had access to the average number of ports-per-address (PPA) in use, we might we be able to compare any change in that PPA number over time to the change in routing table size to glean information on CGN deployment and perhaps reflect a measure of Internet flatness.

Some efforts have been undertaken to understand the average PPA in the context of a review of CGN deployment considerations in this Internet Draft. We know that individual PPAs are constantly changing and the number is affected by variables outside of CGN deployment. With a large enough database, however, a reasonably accurate number reflecting average PPA could be measured.

According to the draft above, address reuse rates could range from 645 to 64 to 1, depending on whether ports are dynamically or statically assigned to customers. (The draft examines other constraints on CGN deployment, including logging,  performance, and redundancy requirements, and finds no large issues in scalability.)

If IPv4 exhaust is constraining Internet growth, perhaps it could be seen in other data. For example, if growth is constrained, will we see relative bandwidth drops in exhausted regions versus non-exhausted? Or perhaps relative reductions in measures of IPv4 connections in exhausted areas? 

Reviewing Akamai's most recent State of the Internet report we find a table on page 16 indicating the number of unique IPv4 addresses connecting to Akamai's platform broken down by country. This table does not at first glance support a claim that exhausted regions' Internet growth is constrained, with non-exhausted USA dropping 1.1% and long-exhausted China growing at 5.9%. Drops in exhausted South Korea, UK, and Italy are offset by growth in exhausted France, Russia and Japan.

If Internet growth is faced with a constraint due to exhaust, would we see that reflected in changes in connection speeds to those areas? In Akamai's report on page 22 we see a table of connectivity speeds in various countries. Although there is some Quarter-on-Quarter reduction in a few countries, the data shows neither a pattern of relative reduction in exhausted regions versus non-exhausted, nor any large constraint on overall connection speed growth, which on a year-to-year basis is higher in every country listed.

If IPv4 exhaust constrains growth, it would be reasonable to see IPv4 prices rising as we continue post-exhaust. As the Akamai report says, "As available IPv4 address space becomes increasingly scarce it will be interesting to see data emerging on IPv4 market transfer prices."

Here again, data is hard to come by, but as brokers we have been dealing with buyers and sellers daily and have only seen prices drop over time. This is consistent with successful CGN deployment, but inconsistent with the idea that Internet growth has been constrained by exhaust. If the major factor limiting Internet growth is IPv4 availability, constrained businesses would be paying more, not less for address space.

The primary benefit of IPv6 is a larger address space, but if CGN can leverage the IPv4 space by somewhere between 64 and 645 times, that benefit of IPv6 is reduced in importance. But IPv6 space is flat and end-to-end addressable, whereas IPv4 space is multi-level NATted. Does one provide an advantage over another that will decide the issue? 

Chicken Little and IPv4

The author of the article linked above, without mentioning NAT at all, comes to an important conclusion about IPv4 scarcity. He senses that there is a distinction between the absolute number of devices connected to the Internet and the number of devices which require a dedicated public IPv4 address. He senses that the historical prediliction towards the assignment of a public IPv4 address to every connected device is profligate, and that there exists a huge pool of allocated, but not utilized IPv4 address space.  Now we do know that Cisco believes there are already over ten billion connected devices, more than one device per person and more devices than IPv4 addresses. And we do know that the Internet continues to function well every day despite this condition due to the existence of NAT. But the author has come to the understanding that very few connected devices require a dedicated IPv4 addresses.  In cases where devices behind NAT need to accessed from the outside, rendezvous servers, who use a single IPv4 address, can hold a database with the IPv4+TCP port combinations for acess to thousands of devices behind NATs, with the right passwords of course. The Internet organism has changed in response to evolutionary pressures. When initial exhaust pressure was applied early on, the Internet turned to variable subnet masks. When it became clear that every desktop should not have a public IPv4 address assigned to it, the Internet turned to NAT despite the scorn of the technorati. When it became clear that local NAT could not prevent IPv4 exhaust, the Internet turned to multi-level NAT. Development at higher OSI levels ensured that VoIP could be deployed through NAT, that online gaming would work through NAT, and that NAT could be penetrated from outside through the use of rendezvous servers. It will be interesting to watch the further evolution of the Internet as we move to a dual-stack mode which includes a completely flat IPv6 network and a multi-level IPv4 network. Will there be benefits associated with that flatness like end-to-end connectivity which will favor IPv6, or will IPv6 adopt NAT as IPv4 did? In either case it is likely that futher Internet evolution will be occurring at higher OSI levels and that ip addresses of either flavor will become almost ephemera, with DNS names being the foundational identifiers of the Internet.

First Internet message anniversary

The article linked above caused me to reflect on my memorable first Internet experience. It is growing increasingly harder to convey the eeriness of the feelings I had upon my first contact with the Internet. In today's connected world it is hard to remember the earlier "disconnected world." In 1978 I was a junior in high school on Long Island and got my first introduction to computers in a brand-new class called BASIC programming. (Well, I had completed a course in keypunch operation, so maybe that was my first computer experience.) The BASIC course was taught on two teletype machines in a small classroom. No monitors. Before connecting, we had to rotary-dial a telephone, listen for the squeal, and seat the phone in an acoustic coupler. When connected, the teletype would ask us to login. As part of the course we had to choose a username and setup an account. I chose my old CB radio handle, "LuckyM". A few years passed and I found myself in a basement closet in my new dormitory at MIT, where an upperclassman was going to help me get connected to the computer system. This time there was a blurry green screen, and it was asking if we wanted to setup an account. Yes, we typed, and the next prompt was "Enter desired username:". I thought a minute and my old LuckyM moniker was typed in by the helpful classmate. The computer responded with a question that froze us both: "Are you Michael Burns?" Sounds so innocuous now, but very idea that somewhere in the bowels of MIT there was a computer that knew that LuckyM was Mike Burns was unsettling. Well at least disquieting. It took a long time for me to figure out that the connection was made through my high school computer lab. Later I learned that the high school lab was dialing to nearby Brookhaven National Laboratories to share computer time, and Brookhaven was, like MIT, connected to the ARPANET at this time. The memory of that encounter with the connected world is still fresh, even though it occured in September of 1980.

ARIN Advisory Council Nomination

IPTrading's principal Mike Burns was nominated to the ARIN Advisory Council in the election of October 2014. Alas, he did not garner enough votes to be seated, but we want to thank everyone who voted, and we are encouraged at the level of acceptance we discovered in the ARIN community for the "broker class" of stakeholder.  We plan to continue to work in the policy development arena towards policy changes which help to ensure a vibrant and reliable transfer market.  

Another carrier announcing CGN

A new wireless carrier in London, Relish,  has announced the deployment of a 4G LTE network. This network is running Carrier Grade NAT to get around problems of IPv4 scarcity. The company announced that they had completed rigorous testing of their CGN implementation and its effect on a range of applications, including online gaming, with no issues to report.  Although readers of this blog will not be suprised at this, there are still efforts to demonize CGN through overblown fears of broken applications among those IPv6 advocates who understand the effect of CGN on IPv6 deployment. Understanding that CGN offers address sharing ratios that effectively moot the IPv4 exhaust problem, and that IPv4 exhaust is the only reason for IPv6, leads to the conclusion that successful CGN is the enemy of IPv6. In Relish's case, as in the case of British Telecom's CGN implementation, that tiny subset of the customer base which requires a real routable public IPv4 address can request or rent one. Thus every customer's needs are met and the carrier does not have to acquire more IPv4 space to accommodate growth. Clearly CGN affects the IPv4 market through effects on sellers (who can transition to CGN and sell excess IPv4 inventory) and effects on buyers (who can turn up 1000's of customers with 10's of addresses). These effects drive down the price of IPv4 addresses. But if CGN is the ultimate solution preferred by the Internet organism, what is the long term outlook? Perhaps IPv6 transition never happens and the IPv4 network proliferates through CGN. What will the long term value of an IPv4 address be in that dim future? 

Telco revenue streams drying up, Internet of Things not the answer

In this article about market saturation, declining voice revenues, and negligible prospects for the telco industry, left unasked is where the money for IPv6 transition will come from? Are telcos intent on simply slowing their slide into irrelevance so as to maximize profits on the glide path? In this current milieu, are telcos going to undertake new investment with no tangible reward, or are they likely to leverage their dominance in IPv4 address space to slow the decline?  We know that many equipment replacement cycles have elapsed since IPv6 was finalized in 1998, but IPv6 penetration is still negligible. Are the telcos going to upgrade all their old DSLAMs and CPEs to handle IPv6 now, or continue to not fix what isn't broken?

IPv4 Network Suprisingly Robust?

"But a surprising thing happened: because of workarounds that allow many devices to share one address, IPv4 is still used, even though the number of devices now vastly outnumbers the number of available addresses. Most sites and network operators aren’t even using IPv6 yet. That’s why it was so easy to fix BGP routers: all it took was telling them to set aside less memory for data that follows IPv6 and make more room for data based on IPv4." This is a quote from the article linked above, written in response to the 512K route problem. The article has some informational nuggets of interest to IPv4 market-watchers. For example, there is mention of "older but still widely used BGP routers." This informs us about the stability of a network where some core routers can still function effectively despite their great age. These routers remain in place because they work and because there is apparently no business case for their replacement. Writ large, this is a big problem for IPv6 penetration, as ancient IPv4 devices just continue to work and resist replacements necessary to support IPv6. 

Another little nugget in the article is the idea that piecemeal upgrades are often preferable to overhauls, and the Internet seems to have evolved in that way historically, with adaptations like NAT and IPv4 trading markets being preferred to overhauls like IPv6.

Finally the fact that the author is suprised at the current status of the Internet, with the number of connected devices vastly outnumbering the number of available IPv4 addresses, indicates that engineers and intelligent observers are coming to understand that multi-level NATs are more attractive to the Internet organism than IPv6, even if the cognoscenti think otherwise. We are left with this sage remark-" the latest incident shows that 'the IPv4 model still has plenty of growth left,' says Dyn’s chief scientist, Jim Cowie."

IPv4 Global route table crosses 512K Threshold

On August 12th, Internet outages occurred as a result of a burst of temporary growth in the IPv4 routing table. This resulted in some routers crossing the important 512K mark, as many older routers are limited to routing tables smaller than this, and fail when the table grows too large. The addition of about 15,000 new IPv4 routes by Verizon to the roughly 500,000 current entries had the effect of clearly demonstrating the 512K effect.  Those routes were later removed, but IPv4 routing table growth is inexorable, and will permanently reach 512K shortly. This table growth is further evidence of the continued value of the IPv4 Internet. In fact, last week more IPv4 prefixes were added to the table than IPv6 prefixes, meaning that IPv6, although trying to overtake IPv4, faces a Sisyphean task of catching something that is accelerating away. For example, last week IPv6 added about 72 prefixes to the routing table, and IPv4 added 1418. One author notes the absence of IPv6 NAT, and the requirements that multi-homed businesses begin running BGP themselves if they convert to IPv6. What will be the effect on the routing table then? It's worth perusing the comments section for the above article for some lively and informed debate. at HostingCon 2014 was an exhibitor at HostingCon 2014 which marked it's 10th anniversary at the Miami Beach Convention Center on June 16th and 17th.  The convention, attended by web hosting and service providers from around the world, gave us an opportunity to hear first-hand accounts of how those most affected by the IPv4 shortage are dealing with it.  While the strategies of the different players varied from region to region and company to company, there was a consensus that IPv4 would be around for years to come.

To have a little fun, visitors to our booth played the "IPv4 Prediction Game", where they were asked to forecast the average price of an IPv4 address in 5 years.  Predictions ranged from $1/IP to $100/IP (perhaps representing an IPv6 believer and an optimistic IPv4 owner!), but the average of all predictions by the "experts" was $26.22/IP.  It will be fun to look back in 5 years and see how close those predictions are.

Halfway through 2014

We are continuing to work towards reducing the requirement that ARIN test each transfer to make sure the recipient can demonstrate their need to ARIN's satisfaction.  The continuation of this requirement is causing perturbations in this market and problems for companies who desire and can pay for address space, but who are proscribed by ARIN policy from receiving addresses. The needs-test for recipients was a rational method for the dissemination of "free" addresses, but not necessary for that purpose in an era of priced addresses.  One example of how anachronistic ARIN policies prevent fair use of address space is establishment of high minimums for allocations. This has the effect of blocking transfers to small recipients who can demonstrate their need for a routable block, just not a need for an ARIN-approved-sized block.  In a market, price provides ample impetus to conserve valuable resources. We believe that ARIN should concentrate on registration. If you concur, please consider supporting our policy proposal to allow for one needs-free purchase per year per recipient, up to a /16 in size.  This reasonable proposal would allow most transfers to proceed without the need to involve ARIN staff, would likely increase the accuracy of Whois, and would answer the needs of the hard-luck "corner cases" currently blocked by policy from buying space.

More thoughts on the future of this market.

We are often asked about the future of the IPv4 market and I will take some time now to discuss that.

APNIC and RIPE have virtually exhausted their free pools and have severely limited new allocations. As of this writing, ARIN has about .95 of a /8 left, or about 15 million addresses.  On June 10th, 2014, LACNIC, the registry for the South American and Caribbean regions, announced that they have reached exhaust. The next big exhaustion event will be the ARIN exhaust, which should happen in less than a year. The APNIC and RIPE registries ran out of space during the public trading era, which began with the Microsoft/Nortel deal in the Spring of 2011. How did those exhaust events impact the market?

In terms of measurables, not much. Price levels set by the Nortel deal and subsequent bankruptcy sales established the price per address somewhere between $11 and $12, but the APNIC and later RIPE exhausts did not raise the price, as might be expected. In fact we are still seeing trades ranging from a low of $7 to a high of $14, but the outliers are the high prices being paid for very small blocks. Blocks ranging from /20 to /15 are in the $8-$10 range.

The number of transfer transactions is small, as reported by ARINAPNIC, and RIPE. Most of the transfers are of small blocks.  After we brokered the first pair of Inter-regional transfers and demonstrated the workability of such transfers, we expected that pent-up APNIC demand would lead to a raft of similar transfers. But so far this has not happened. What could cause this?

First there is the issue of price. Where did the price for IPv4 addresses come from? Did it come from the intersection of supply and demand curves? Does the price represent the net present value of future profits enabled by the address? Is the price equal to the cost of a substitute for IPv4 like Carrier Grade NAT? Is it connected to other customer acquisition costs like modem ports or bandwidth? Is it even informed by the rate of free pool exhaustion, the rate of IPv6 transition, or RIR transfer policies?

As a bidder against Microsoft for the Nortel addresses, we had to carefully consider what IPv4 addresses were worth, but there was little information available. So we had to guess at that value, and as it turned out, our guess (and bid!) was lower than Microsoft's guess, which was $11.25. Having time to reflect on that price, and the opportunity of speaking with many potential buyers and sellers around the world, we have come to realize that Microsoft's guess may not be an accurate reflection of the real world economic factors at play.

Although IPv4 addresses are a fungible commodity and can be used anywhere in the world, the Internet economies in various regions of the globe vary.  So whereas an ISP in the States or Europe may see a $10 price as a bargain, based on the anticipated profits an IPv4 address can garner for them, an ISP in Mongolia or Malaysia or Afghanistan may see a $10 price as a barrier. 

This is still a small market, albeit global, with a small number of transactions and mostly small transactions at that, with no public knowledge of transaction prices. This is not a recipe for accurate pricing, or at least pricing which accurately reflects the true intersection of supply and demand. In this environment we can expect pricing to be variable.

Although we have good information about the number and size of transactions which occur within policy, we do not know the number or size of transactions which are not conducted under RIR policies, such as legacy transfers or leasing of address space, or the acquisition of shell companies with prior IPv4 allocations. So market participants are generally stumbling around in the dark, attempting to engage in what will probably be the first and last such transaction in their careers. As brokers we do have access to quite a bit more private information, but there are still many uncertainties which permeate the whole market.

One of these is obviously the IPv6 transition, which is the gorilla in the room. Virtually everyone understands that once IPv6 transition is complete, IPv4 addresses will have no value. So understanding the rate of that transition is important. Our feeling is that there are still 10 years left in IPv4, but opinions vary. 

Another uncertainty is the substitutabilty of Carrier Grade NAT (CGN) deployment for IPv4 address block purchase. Pundits have conventionally held that CGN is a poor substitute whose deployment leads to customer loss, making the cost of CGN very high. This belief is expressed here, and here, for those interested.  Based on our own experience, we believe the dangers of CGN are overblown and that CGN deployment can be less expensive than purchasing addresses.

Given that even large ISPs like British Telecom and Verizon are publicly deploying CGN, what will be the effect on IPv4 price if the market finds CGN to be workable? For one thing, demand will be reduced, as some buyers decide to go with CGN instead of purchasing IP addresses. For another, supply could be increased, as existing address holders switch to CGN so that they can monetize their allocations on the transfer market. Both of these eventualities augur a drop in address prices.

On the other hand, widespread CGN deployment will alleviate any IPv4 address shortage, and IPv4 address shortage is the only motivation for the IPv6 transition. What if CGN has the potential to effectively and transparently add an additional 8 bits to IPv4's 32 bit address space? Probably CGN is not that efficient, but what if it affords a 10:1, 100:1, or even the full 256:1 address savings ratio reported here?

This is the realization that has IPv6 advocates gnashing their teeth and drives their hyperbole about CGN problems. What if demonstrated workability of CGN serves to increase the already lengthy transition to IPv6? How will a longer transition affect IPv4 prices? Given that IPv4 prices incorporate a "value horizon" related to transition time, will a longer period of IPv4 usability translate to a higher price?

Understanding that there are about a billion routable unused IPv4 addresses out there now, and that the numbers and sizes of reported transactions are small, and that CGN is on the rise, we are not sanguine about the inevitability of a price rise after ARIN exhausts. In this case, not caveat emptor, but caveat venditor!


Ruminations on the failure of IPV6 transition

A dual-stack transition model was decided upon by the IETF as the appropriate one to use in the transition from IPV4 to IPV6.  This was not unreasonable. Since the benefits of NAT (Network Address Translation) started to become apparent around that same time period, the late 1990s, actual IPV4 exhaustion was not expected for nearly 15 years. And since the plan was to build into the dual-stack transition model a preference for IPV6, it was envisaged that normal equipment replacement cycles would lead to a dual-stack Internet long before exhaust, and the IPV6 preference would serve to constrain IPV4 to an ever-shrinking appendage which could at some point be turned off.

In retrospect, this decision was both naive and shortsighted. Naive in its ignorance of the market requirements for technological transition,  and shortsighted in its failure to appreciate the benefits of NAT and the manner in which the free and open Internet environment would adapt around NAT limitations.

The ongoing saga of this transition (
we're in the 15th year of it at least) exposes the fallacy of the top-down transition model and reveals the true driver of technological transition to be end-user demand. IPV6 may be technologically superior to IPV4. But if the superiority does not move the market, the transition will fall prey to the "first-mover penalty". Who will be the first to turn-off or do without IPV4, and connect to an IPV6 only network?  Predictably, governments will mandate deployment, incurring taxpayer cost and adding to the costs of doing business with the government. But what other stakeholder in this stakeholder-governed Internet does not have to answer to customers eventually?  And what customer is demanding IPV6?  Until the Internet is fully dual-stacked, it will be as fully IPV4 as IPV6. And so, why move?

The failure of IPV6 to thrive in the wild no doubt causes considerable consternation to its erstwhile parents, the IETF. In a triumph of parental pride over rationality, the IETF has steadfastly refused to establish meaningful NAT and NAT-traversal protocols, instead preferring to ignore NAT and flog IPV6. We believe that NAT plays an important role in the Internet today, and we believe that the IETF drive towards complete end-to-end addressability is a mistaken perception of the founding goals of the Internet. After all, the etymology of the word itself means a connection of networks. The Internet was conceived as a means of connecting disparate networks through routers which marked the boundaries of them. It was not meant to be a single network, but a collection of them. The "ends" in the end-to-end connectivity contemplated by the founders referred to the professors and academics themselves, who would be able to communicate directly with each other through applications like email, across various hardware and software platforms.

Without a doubt the major problem with IPV6 is its failure to be backwards compatible with IPV4. The dual-stack transition mechanism has failed to operate in a timely fashion, if it could be said to have operated at all. We believe the IETF should go back to the drawing board and return with a backwards-compatible successor protocol such as envisioned by


An enlightening exercise in demonstrating IPv6's immaturity


This article describes how enabling IPv6 in a dual stack environment led to a frustrating inability to send mail through a Microsoft Exchange Server. The troubleshooting of the problem moves through the networking layer of both IPv4 and IPv6 until the application level is reached. A diagnosis of the SMTP handshake revealed that the IPv6 address was being rejected by the Exchange server. This led to a review of the various IEEE RFC's which applied, and a determination that Apple's mail program did not comply with the current standards. The fact that companies as large as Microsoft and Apple failed to negotiate the IPv6 environment with transparency for the end user engaging in the simple and well worn SMTP protocol is an indictment of IPv6 current status and a harbinger of further undiscovered bugs. It should be apparent that a new addressing protocol that represents a bare 1% of Internet traffic has a way to go in terms of becoming a fully vetted and secure replacement for IPv4. The author, Geoff Huston, is a master of these matters, and the article is worthwhile just to understand the logical troubleshooting steps required to come to the conclusion that the answer to the Apple mail program's problem is to disable IPv6. It is likely that most similarly-situated individuals would not go through the rigorous review of various vague RFC's in order to correctly apportion blame, and would simply jump to the step of disabling IPv6 and leaving it off until the protocol has matured through its 15 year nascency and become vetted through real world use. It should be noted that this was not some hacker probing IPv6 for security issues, but an Internet Hall of Famer simply trying to send mail through dual-stack, using software from two preeminent firms.  As in the response to  the still unaddressed-by-Microsoft vulnerability to IPv6 Man-in-the-Middle attacks, further RFCs will be needed, and their adoption is obviously fraught.


New Mobile Networks continue to be deployed using IPv4


This link describes the deployment of a new Sprint LTE mobile network as being done using Carrier Grade Nat with internal ip addresses which have been allocated the the US Department of Defense.  Because the DoD network's ip network is not connected to the public Internet, ip address conflicts will not occur.


This is of interest to us because it indicates clearly that the CGN model works and is actively being deployed by carriers even in advance of IPv4 runout. Whereas it has been a commonplace observation that the expanding universe of mobile devices would be a driver of IPv6 deployment, here as late as July 2012 we see a brand new mobile technology (LTE) being deployed with an IPv4 architecture.


This augurs for a longer horizon for IPv4 utilization and a longer duration for the IPv4 transfer market.


NAT Considered...


We have been conditioned to consider NAT as the ugly duckling of the Internet Protocol world.  Created as a workaround to the shortage of address space way back in the early 1990s, it came into being at a time when virtually every workstation, every printer, every server got a real and routable IP address. Imagine that. Every machine was reachable from every other machine on the Internet. Talk about feeling exposed!
NAT was simple and elegant. It used the surplus number of TCP ports to share a single IP address. Even absent any IETF established standard, it was seen to meet the needs of end users, and spread throughout the Internet.


NAT worked well for web browsing and email, but posed problems for VOIP and for inbound traffic.  But the problems with VOIP were overcome through new methods of NAT traversal like STUN and SIP, and the problems for inbound traffic were ameliorated through the use of rendezvous servers and UPnP.  In other words, rather than transfer to IPV6, the market invented mechanisms which increased IPV4's utility and made it preferable to stay with IPv4 rather than undergo the expense and uncertainties associated with IPv6.

As it turns out, NAT has had some very real benefits that elevated it to its current ubiquity, including its automatic intrusion protection, ease of renumbering, load balancing, and, of course, address conservation. Although NAT is not a firewall, per se, by its nature it protects from inbound threats and provides an easily perceived demarcation between private and public networks. In addition, NAT is easily understood by anyone who is understands TCP/IP, and the value of NAT is so obvious that there are cries to include NAT in IPv6, even though address conservation is not an issue.


We have long been accustomed to the dread of multilevel NAT, also known as Carrier Grade NAT (CGN) or NAT444, despite the clear evidence that multilevel NAT actually works. In fact, much of the traffic today passes through several layers of NAT. You are probably behind a NAT device right now, and your packets are traversing that NAT, passing through the public Internet to another NAT device which passes packets to the web server which is displaying this page to you. This is far from unusual. In the past when we wished to contact a specific machine behind a NAT device, we had to get involved in configuring that NAT device to direct certain inbound traffic on specified TCP ports to specific addresses behind the NAT box. Now rendezvous servers have developed to perform that task without the need to configure NAT. Have you used a remote access product like Logmein or GoToMyPC? You can very easily access your machine, even though it is behind a NAT device in your office, from another office behind a different NAT device, without touching either device. Do you play online games with a game console from your home? You are behind NAT, and so are the players you are competing against. Yet you can play or even talk with them without bothering about configuring the NAT devices in either of your homes. The smart folks at Cisco are including CGN in their most advanced routing platforms.  Juniper, too. And the ever-inventive market is moving towards a simple new protocol which will allow for more automated control of NAT devices, called NAT-PCP.


What does the future hold?


Many people feel that upon final exhaust of the available free pool of IPV4 addresses, there will be a significant enough change in the state of things as to cause some kind of upheaval. Either there will be a legislative event or a some kind of universal drive towards a rapid transition to IPV6.  Few people understand that the only change in the status quo ante will be the inclusion of a new cost factor to be considered when new Internet infrastructure changes are contemplated.

The new cost factor will be the cost for the IPV4 addresses required to effect that new Internet infrastructure change. Whether that change is the increase in the number of smart phones in Singapore, or the incarnation of a new SSL website in Ohio, one component of the decision-making process, along with the tower rental costs and the router costs and the bandwidth costs, will be the address space costs.

As with any scarce resource, address space will be conserved and utilized as productively as possible if a free market arises to facilitate the buying and selling of these assets. Given the natural tendency of man to trade, the peculiar lack of governmental power to restrict trade in the stakeholder-governed and global Internet, the portability of address space, and the gigantic underlying value of an Internet connection, we think these markets will be recognized as being valuable and overdue additions to the Internet's operational structures.

At, we want to advocate on behalf of our clients, whether they are buyers or sellers of address space. We think it is in the best interest of both buyers and sellers that artificial restraints are not placed between them. We keep abreast of the changing worldwide policy and legal environment so that we can offer the most appropriate options to our customers, depending on the individual circumstances of the deal.



News, Events, and Blog Highlights

IPTrading APRICOT 2017


IPTrading's Mike Burns presented at APRICOT 2017 in Ho Chi Minh City on March 1st. Mike offered inside observations on his decade in the opaque IPv4 transfer market. 

Contact Us Today

For answers to your questions, please call:


+1 855/478-7233

+1 855/IP-Trade


Or send us an email.


Consultations are free and confidential.

PrintPrint | Sitemap Recommend this page Recommend this page
© 2016