Check here for the latest news and information about upcoming events.
The article linked above relates the fact that the US government continues to use floppy disks, even 8 inch floppy disks, for important tasks like monitoring nuclear reactors or air traffic control. In the text of the article we learn that often mission-critical systems which have proven reliability are difficult to upgrade. And that often these archaic systems sit behind a more modern front-end. What is the implication for the IPv6 transition? It has long been assumed that governments would be among the leaders in the pioneering of the IPv6 transition, given their large purchasing power and government's ability to respond to commands from the top of the heirarchy. But despite more than a decade of attempts at top-down transition to IPv6, the same issues which have delayed the overall transition have plagued the US government's transition. For example, here is a 2005 GAO report which instructs all federal agencies to plan for their transition with a particular eye towards security. Here is an example from the early Obama administration, complete with deadlines which have not been met. Here is a 2009 Cisco publication describing the planned federal government transition to IPv6, complete with glossy images, graphs, and unmet schedules. Here is an article form 2008, describing the already-five-years-old federal commitment to the transition, complete with a laughably unmet schedule. Maybe we can concentrate on the transition from 8 inch to 5 inch floppies as a more attainable goal.
LACNIC staff presented information of interest to our clients, which we will summarize here.
First there was an examination of the IPv4 exhaust situation at LACNIC, including the status of the two pools remaining. LACNIC calls these the Phase 2 and Phase 3 pools, representing two devices the LACNIC community approved to deal with impending IPv4 exhaust. Phase 2 is a pool which limits maximum allocation size to a /22, and limits these allocations to one per member per six months time. Phase 3 is a pool which is restricted to new LACNIC members, and is limited to a single /22 per new member, one time only.
The exhaust presentation by Gianina Pensky, is here. The best estimate for the exhaust date for the Phase 2 pool is March 16, 2017. The exhaust date for Phase 3 is much further off, likely 2024 or thereabouts.
The second interesting presentation investigated the record of transfers to glean information not apparent when viewing only the transfer logs. This analysis, based on data from Geoff Huston of APNIC, looked into the routing history and allocation dates of transferred blocks to see if there were any patterns to behold. As presented by Carlos Martinez, the data was clear, and indicates that many of the blocks being transferred are dusty old legacy blocks that were absent from the routing table for a decade or more. The success of the transfer market was apparent in the evidence of unutilized blocks being brought into justified and presumably productive use, whereas decades of RIR policies related to utilization requirements failed to achieve this degree of success.
In addition, Mr. Martinez's presentation further indicated a clear signal of directional address flow. Despite the reciprocity of inter-regional transfer policies at ARIN, APNIC, and RIPE, addresses flow virtually always in one direction, and that is from ARIN outwards. We believe this to be a reflection of the high allocation rates in North America in the early years of the Internet. In the classful address era, any recipient with a need for 257 or more addresses automatically received a /16 with 65,536 addresses, and many of these blocks are no longer used for their intended purpose and are availble for sale. This relative glut of supply has the expected effect on price, with ARIN supply being the lowest priced. We have brokered transfers in every combination between the three participating RIRs, but nearly all originate in ARIN. We hope the significance of this point was not lost on the LACNIC audience, where we see more demand than supply, even in the nascent state of the LACNIC market. LACNIC has rejected inter-regional policies more than once, but we expect that they will have still another chance to consider the possibility in the future, when data such as that presented by Mr. Martinez can be verified and buttressed through further experience. Should LACNIC prices rise above those of the global market, we will seek to advertise that fact in support of any future inter-regional transfer policies at LACNIC.
The article linked above relates the use of Carrier Grade NAT by an ISP in Peru. Despite CGN being idiosyncratically referred to as NAT 3, the article includes the all-too-standard handwringing over the business decision of an ISP to use CGN as a method of dealing with IPv4 exhaust in an IPv4 world. As we have argued, the rational business case for CGN is clear. Continuing to disparage CGN as limited, the cause of many problems, and a kludge which prolongs IPv4 on its deathbed have been the standard means that the pure-of-heart IPv6 cognoscenti utilize to try to keep the lid on CGN and the genie in the bottle. CGN deployment is very significant to students of the IPv4 transfer market as it affects both supply and demand for IPv4 addresses and thus can significantly change price points. As we move towards IPv6/CGN dual-stack, will we come to a point where we view the IPv6 as the un-necessary rump that can be dropped? For if such dual-stack worked, would that not indicate that CGN works on its own? CGN has the power to virtually add an octet to our IPv4 address space, transparently and with backwards-compatibility, and it helps organize the Internet naturally into server class and client class, with different security needs, addressability needs, and portability needs.
The article linked above describes the current state of the IPv4 transfer market in Europe and the particular position occupied by tiny Romania. As brokers we have fielded many inquiries involving Romanian sellers and can confirm availability of blocks there. Also mentioned in the article are transfers to Syria and Iran. We have also received many inquiries from those two countries about purchasing address blocks. However the US State department confirmed upon our inquiry that as Americans we were precluded from engaging in any transactions involving brokerage of IPv4 space into either country. Our first such inquiry, involving Syria, occurred more than a year ago, and at the time the State department did not have a specific mention of IPv4 addresses as an item which was definitively included or excluded from sanctions. We were advised that if we engaged and the transaction was later determined to be precluded by sanctions that our penalty could be $250,000. Interestingly a later inquiry revealed that the State department had in fact determined that IPv4 transactions were explicity forbidden. Apparently sanctions did not inhibit Romanian sellers, though.
The article also mentions the difficulties buyers can face after the sale. Apparently at least one seller sold a /17 and it was not noticed by the buyer that some /21s within that /17 were being advertised (for years!) by another ISP. We have advised many sellers and buyers on the necessity of due diligence to investigate not only the reputation of the block vis a vis spam, but the routing history of the block, and any previous delegations of assignments of any part of the block. Many times sellers delegated a small block to a customer via SWIP, and all records and memories of that were lost over time. Sometimes sellers will think their block has been dormant for decades only to learn to their chagrin that it was hijacked and blacklisted years ago. We work with sellers to investigate and correct these problems prior to sale. It's unfortunate for the buyers in the example above that they did not check to see if the block they were buying (or any subnets therein) were being advertised on the global routing table. That's something we help our buyers do in their due diligence process.
Finally there is an example of a seller who re-advertised the sold block after the sale. This could happen by mistake, but it would be wise for the potential for this error to be noted in the sales agreement, with a defined process for remediation or for penalties to the seller.
This paper examines several large datasets to measure real-world IPv6 penetration. Sixteen years after IPv6 was finalized, after IPv6 "Flag Days" in 2011 and 2012, after many RIR events designed to publicize the exhaust of IPv4, and after countless symposia and fora dedicated to IPv6 deployment, reaching 0.6% of Internet traffic is deemed by the authors as evidence of "a dramatic qualitative and quantitative evolution in the state of IPv6." Well, to be fair they mean over the last few years, but it would not be hard to find the same language being issued over and over again during the last decade. The authors also venture a prediction that in 2019 "IPv6 to IPv4 traffic ratio will be between 0.3 and 5.0." Now that is a bit of a head scratcher, as that prediction includes a range greater than an order of magnitude. So in five years, IPv6 will grow to a minimum of 33% of IPv4 traffic, or even up to 500% of IPv4 traffic. Not really much value in that prediction, but that is apparently due to discrepancies in the dataset measurements of different aspects of IPv6 penetration, which yield wildly varying results. We believe that the measurements that are meaningful are traffic volume and makeup. We know that much of the measured IPv6 traffic in the past came from peer-to-peer and NNTP applications, not a pattern matched bynormal IPv4 traffic. This paper claims that IPv6 data is beginning to look more "normal" these days. But that normal traffic is flowing at an anemic 0.6% of IPv4 rate.. A major limitation of the paper is the lack of measurement of Carrier Grade NAT deployments and lack of mention of the IPv4 trading market. CGN is barely mentioned, even though we believe it has enormous impacts on IPv6 deployments. It is very difficult to find accurate CGN address-sharing ratios, and the size of that number bears significantly on the IPv6 transition. It is likely those ISPs who have publicy announced CGN deployments have not had significant issues; there is no evidence of public rejection, or retraction of CGN deployments. Is this silence evidence of success?
Are we seeing evidence of a stampede forming? Today the ARIN free pool plummets from .75 to .73 /8 equivalents, a drop of around 300,000 addresses following the drop of a million addresses yesterday. Together, ATT and Time Warner consumed ten percent of the entire free pool in forty-eight hours. Does this represent real, ongoing demand for IPv4 addresses which will stretch beyond the ultimate exhaust date, or is this a forced march towards a last bite of the apple?
Today, August 13th, the size of the remaining ARIN IPv4 free pool dropped from .81 to .75 /8 equivalents, or about a million addresses. It won't be long before AFRNIC stands alone as steward of a remaining pool of "free" addresses available to those who have a demonstrated technical need for them on the African continent. For the rest of the world, IPv4 address needs will have to be met through the transfer market.
Today LACNIC says they have dipped below the threshold in their free pool which activates their transfer policy. Prior to today, transfers were not permitted in the LACNIC region (Latin America and the Caribbean). But henceforth those in the region with excess supply can sell to those with demonstrated need. IPTrading has addresses available today in the LACNIC region.
Interesting that even Amazon, who purchased a million IPv4 address on the transfer market, has found that implementing NAT inside their cloud provides advantages which outweigh a direct assignment of a routable address to their servers. This article describes the interface to Amazon's Compute Cloud and how to use it to acquire and change the static public ip address mapped to a server. I'm sure Amazon (and HP, Joyent, and Rackspace) found this setup to be a prudent way to enable customer address flexibility while maintaining control over their internal infrastructure. The author ends with the acknowledgment that this NAT usage, which was developed alongside an apparently operational IPv6 infrastructure, is unlikely to change soon without the application of government coercion to force big companies to change to IPv6. Finally, it's notable that the author makes no mention of any technical drawback of the NAT implentation, no claim that what is being offered is a "degraded" or second-rate service, nor any claim that any particular application would fail to work on a cloud server behind NAT.
With a couple of large allocations recently, ARIN dropped below the threshold for policy changes associated with the final stage before exhaust of the free pool. After the recent receipt of a /11 from IANA, ARIN is back up to nearly a full /8. But the inventory shows that there are many non-contiguous /23s and/24s in inventory, with a relatively small number of larger blocks. As ARIN breaks down the largest blocks, including the /11 from IANA, into the sizes being requested, more and more disaggregation will occur. Considering that a very small percentage of ARIN allocations are as tiny as /23 and /24, and that current ARIN policy makes it very difficult for small companies to acquire small blocks, since the minimum size is /20 for most ISPs, it seems like we will have a long tail before complete free pool exhaust is reached. Requestors can only come back once every three months, and all they will get is a /24. Since there are nearly 1200 of these, it could take as much as six to nine months time for this series of 3 month requests to finally reach zero. Possibly longer if companies find that it isn't worth the effort for a /24, and instead turn to the transfer market for larger sizes.
In this thread, a user experiences only IPv6 connectivity after Comcast rolls out dual stack. Apparently as part of a cable modem update to provide IPv6, a slight change in functionality causes the customer's router to fail. The cable modem now temporarily issues an IPv4 address and route during the bootup process, and that route becomes the default route for the customer's attached router. This led to a situation where the customer had only IPv6 connectivity for the four days after the Comcast update. The urgency of the user's voice gives evidence that he does not find working IPv6 to be a substitute for IPv4 connectivity. The particular problem is evidence of that we are still at the beginnings of the deployment of dual-stack, a deployment which was intended far earlier in the planned transition to IPv6. Although this problem was only indirectly caused by IPv6 or dual-stack, it demonstrates the difficulties involved in the wholesale change of a protocol underlying the continued operation of myriad disparate devices. It is simply to be expected that a change of this magnitude will result in unforeseen problems. The realization that this is just one of the early ones should be sobering to those who think an IPv6 transition is around the corner.
By default, IPv6 is preferred over IPv4 in a dual-stack environment.
By default, IPv6 utilizes an auto-configuation option called SLAAC.
By default, IPv6 is enabled on modern operating systems.
These facts, combined with the very small number of dual-stack environments with a fully operable IPv6 network, make it simple to attack many LANs that are fully protected from IPv4-only attacks.
Basically a host on the LAN pretends to be an IPv6 router, advertises itself, and causes other IPv6 enabled hosts to acquire a routable IPv6 address. After that, those other IPv6 hosts, which are not compromised in any way, will begin sending all traffic to the compromised host. The compromised host will answer requests from the other hosts, fetching the requested information from the Internet using IPv4, then sending it back to the uncompromised hosts via IPv6. This will be transparent to the users, but the compromised host is now the Man-in-the-middle, and can capture all information passing to and from the other hosts. What's notable is that all computers can be firewalled and up-to-date on security patches, and it will not reduce the risk, because the uncompromised computers are behaving as designed. This exploit, which was announced in 2011, still has no good resolution, and the recent announcement of Sudden Six, a tool to automate the creation of the compromised host, makes it even more dangerous to those who fail to disable IPv6 on all hosts on networks without a fully functioning IPv6 network.
Interesting article written about one CGN provider who discovered the ceiling for concurrent sessions on their CGN box. A pretty straight-forward technical problem with a straight-forward solution: Upgrade the box. In this case the provider was growing quickly and was aware of the red line of CPU utilization as it approached 100%. So they researched and spent $50,000 on the solution, which included redundant units for robustness' sake. Apparently the new hardware can support more than 7.5 Gigabits per second of translation without license fees and well over 200,000 concurrent sessions, and is available with three years of support from the manufacturer. This article is evidence of a maturing CGN environment, with equipment manufacturers (plural) not only providing the gear but providing an upgrade path to CGN providers on their second generation platform. Hard to believe such an enviroment would exist if there were endemic problems with CGN.
Giant ISP British Telecom joins Plus.net and Verizon in deploying Carrier Grade NAT to its wireline customers. As BT points out in the article, CGN is a widespread industry standard used by most smartphones. As carriers invest more heavily in CGN technology, they will have a natural incentive to maintain the value of those investments. One way to do this while providing a barrier to new competitors is to slow IPv6 deployment. This means that a new competitor to British Telecom cannot use freely available IPv6 addresses, but must succeed in an IPv4 environment where incumbent carriers have the advantage of large holdings of IPv4 addresses, which they can leverage further through CGN deployments. As the lack of economic incentive to deploy IPv6 has stunted its growth, the existence of an economic incentive not to deploy IPv6 could be even more damaging to its prospects.
Just as the industry has adapted to the functionality of CGN, with technical workarounds like rendezvous servers and UPnP-aware routers, according to this article the British Telecom regulator has changed the requirements for notifying ISPs of copyright infringements. Whereas in the pre-CGN days, having the IP address and timestamp was enough information for an ISP to identify a subscriber, that information is not enough to identify a subscriber who is sharing a single IP address with other customers. If the indentifying information includes the port number as well, however, British Telecom claims they can make a positive identification of the subscriber. One of the common arguments raised about CGN comes from legal authorities accustomed to identifying a suspect by IP address and datestamp. Simply adding the port number requirement answers their objections.
Verizon announces their plan to automatically swich over their residential DSL customers to CGN, with the interesting option for the customers to opt-out of CGN after they have been switched. This option, cleverly available only post-switch, should prevent the few customers who would normally balk at CGN from canceling their service, while at the same time ensuring an order-of-magnitude reduction in IPv4 address needs. Verizon's plan gets around the common complaint that CGN "breaks" certain applications by allowing the customer to decide. Verizon knows that the vast majority of customers will neither know nor care that they are using a shared IP address, overwrought fears of "breakage" notwithstanding.
At one time each website required a unique IPv4 address, but long ago virtual hosting enabled many websites to be hosted on a single IPv4 address. Unfortunately this economical address use was not possible on secure websites using SSL certificates. This is still a requirement for some older client devices, but this article shows how we are moving towards a more ubiquitous acceptance of a technology which allows for the sharing of a single IPv4 address among many SSL websites.
Plusnet is asking for volunteers to test CGN and report back on problems they discover. This is an enlightened move by Plusnet, who previously had an IPv6 trial which was canned. Plusnet has a history of innovation with deep-packet inspection of their network traffic to provide a high level of Quality of Service by identifying and prioritizing types of network traffic. This CGN test indicates a willingness to bravely counter the groupthink which affects most technologists when considering the benefits and drawbacks of multi-level NAT. One potential problem is the self-selection of volunteers for the test, which would be likely to result in a test population with different characteristics than the general population. One can be certain that if CGN works for this techie group, it will certainly work for the larger group. We believe that ISPs like Plusnet can address virtually all the conerns associated with CGN by providing secure, limited web-based access to their CGN box to allow customers control over some number of ports on their external IPv4 address. This would allow them the same control they currently enjoy with their own ubiquitous NAT routers, while providing for the transparent use of a single IPv4 address among 10 to 100 customers.
Uniting an Asian buyer with an American seller, IPTrading inaugurates the era of international IP address trading. Space originally listed in ARIN Whois now appears in APNIC Whois, and buyer and seller are happy.
Frustrated by their inability to coerce transition to IPv6 using governmental power and cognizant of a lack of motivating business incentive to transition, the board of 6UK, having fruitlessly spent the seed money expended by the UK Department of Business Innovation and Skills, decides to dissolve the organization.
Ripe announces that it has reached its final /8 worth of IPv4 address space, and has implented new rules for allocating these addresses. No IPv4 address space will be allocated to newcomers, only to those who have had prior allocations of IPv6. And even for these applicants, no matter what their need is, they are limited to a one-time allocation of 1024 addresses, a /22. Unfortunately, RIPE policies only allow for a 90-day justification window for transfers, and prevents inter-regional transfers, so the current IPv4 transfer market in Europe lags behind Asia and North America. Our expectation is that RIPE policies will change in early 2013 to increase the justification window for transfers and allow inter-regional transfers. IPTrading does have inventory in RIPE available for purchase or leasing.
This article points out that federal agencies have now missed IPv6 deadlines ordered by both the Bush and Obama administrations. This despite the Federal Chief Information Officer demanding the designation of IPv6 Transition Managers from each agency, and holding IPv6 Task Force meetings with these agencies back in 2010 and early 2011. One wonders whether these IPv6 Transition Mangers were the same people who were required to be designated by the November 15, 2005 deadline as demanded in the 2005 memo. The larger issue is the disconnect between the top-down authoritarian approach to technological change versus a ground-up transition shaped by user demand. Successful transitions are the result of user demand, and user demand for IPv6 is minimal.
This paper uses the publicly accessible information on IPv4 transfers which occurred in various bankruptcy transactions to analyze the nascent IPv4 transfer market. The paper's concludes that the market exists, and is even thriving.
This article shows that huge blocks of IPv4 space are not currently being routed on the Internet. Most of this space is legacy space, and is presumably available to the IPv4 transfer market.
This article indicates that the flow of IPv4 addresses from North America to Asia is about to commence.
Article describing "launch" of IPv6, which was actually launched back in 1998. Great progress has been made! IPv6 is approaching 1% of network traffic! IPv6 evangelists rejoice, but the Internet yawns, yet again.
Mike Burns, founder of IPTrading.com, was the original author of this proposal, which, when implemented, will allow Inter-RIR Transfers for the first time. Previous attempts to create policy for Inter-regional transfers lacked some critical protections afforded by this complete rewrite of ARIN's transfer policy.
Borders, in bankruptcy, sells addresses, and the sale is coordinated with ARIN based on the model of the Microsoft sale.
In a first-of-its kind public transaction, Microsoft buys the rights to the defunct Nortel corporation's addresses from a bankruptcy court. IPTrading brokers one of the bids.
The lack of a business case for the transition to IPv6 dooms this transition.
With IPv6, spammers could use a unique address for every piece of mail they send, making blacklists impossible.
LACNIC began its IPv4 transfer era on March 14th, 2016 by implementing proposal LAC-2015-1 which we authored. We are proud to have played a part in inaugurating a market which we believe will be transparent to the LACNIC community, result in accurate Whois records, and provides an avenue for address-starved companies to acquire necessary address space.
We invite interested parties to meet with us in Havana at the LACNIC meeting in May.
For answers to your questions, please call:
Or send us an email.
Consultations are free and confidential.