Guest Blog

Getting Serious About IPv6 – Go Big or Go Home

Ed Horley provides a convincing case for the many reasons why you need to get an IPv6 plan in place now and how to overcome some of the common challenges along the way.

Guest Blog Post by Ed Horley

I gave an Interop IPv6 presentation titled “Getting Serious About IPv6 – Go Big or Go Home” in Las Vegas on April 3, 2014. Since then, ARIN announced it has moved to Phase 4 (down to its last /8 of IPv4 – that happened on April 23, 2014).  I think what surprised people the most (based on the feedback I got from the session) was that my argument about adoption for IPv6 had little to do with ARIN running out of IPv4. After all, this is what everyone talks about, that there are no more IPv4 addresses. My argument is:

You have already deployed IPv6… you just didn’t know it.

At this point, you may be scratching your head saying Ed is crazy, what is he talking about? Let me point out that all major OS platforms (and different flavors of those platforms) support IPv6 and have for a while now. It turns out that IPv6 is enabled (on by default) and preferred in almost all cases. To top it off, there are IPv6 transition technologies in Windows, there are zerconf capabilities in all the OSs, there is support for mDNS or LLMNR, and to top it all off, IPv6 has several address mechanisms per active interface on a host. If you add this all up it is highly likely that you have deployed IPv6, you just didn’t do it in a structured and controlled manner the way you did your IPv4 deployment.

If you have deployed IPv6 (congratulations by the way) but didn’t do any planning, what challenges do you now face?

First, do you understand the impact of turning off IPv6? Often when I point out that all the host OSs are running IPv6 many people want to jump immediately to shutting off IPv6. While this is possible (sort of), the question you should ask is, “will this impact my existing services?” Think carefully before you just start shutting off IPv6. Remember, it is enabled and preferred and if your existing production network is using IPv6 for some of its network traffic you will have a production outage while you disable IPv6. Furthermore, you might not even know all the applications that ARE using IPv6, have fun troubleshooting that one. Even after you think you have turned off IPv6 on your equipment, how often do you actually audit and check to see if it is running? Does it get re-enabled with OS patches and updates? What about third party equipment that runs on your network or wireless/wired guest network? How about BYOD and those devices that you can’t control the networking stack? The reality is, even though you think you are simplifying your workload, you aren’t. You will still need to set up sniffers that can detect and capture IPv6 traffic, otherwise, how will you know it is NOT running on your network? You will still have to collect and analysis log files that contain both IPv4 and IPv6. You will still have to write and maintain policy and security rules that include both IPv4 and IPv6.

At this point, it must be obvious, why not just adopt and support IPv6 if you have to do all this work for it anyway?!?

To make matters even more interesting, I argue that if you have industry compliance requirements and you do not have a plan for IPv6 (off, on, whatever) then there is no way you can say you are in compliance of an audit. Why? Because how do you pass an audit when you have a protocol running on your network you don’t understand, can’t get any information from and aren’t even watching?

What challenges do you have once you realize you need to have some sort of IPv6 plan in place?

I have heard repeatedly that education for staff is the biggest issue around IPv6. Does your team know anything about IPv6? Would they even know it if they saw it? ARIN has some great education resources available at along with the IPv6 info center and if you want specific IPv6 and Windows knowledge then consider picking up my book.

The next common challenge is getting your policies (IT, security, purchasing, etc.) modified to include and be thinking about IPv6. For instance, will you purchase the right equipment that supports IPv6 the “first” time or will you have to buy it all again in one to two years? Adopting newer OS platforms becomes easier because these newer platforms support IPv6 from the start. But what do you have to do for older systems? Initially, you really won’t notice anything until your service provider truly depletes their IPv4 address space. Then they will be forced to starting adopting and deploying IPv6 but they will use various methods in the meantime to extend the life of IPv4. They will most likely utilize a tool called Carrier Grade NAT (CGN). CGN breaks IPv4 uniqueness at a much larger scale. We used to hide a single household or commercial company behind a common IPv4 address, now we will hide an entire city, county or larger unit of people. CGN exasperates IPv4 port exhaustion issues; it compounds stateful NAT issues, along with just slowing things down.

Finally, what problems will you see happen as IPv4 runs out? It is going to get harder and harder for your employees to get public IPv4 at home. This can potentially cause problems for VPN, VoIP, Video, Collaboration and Gaming (depending on how those technologies are deployed). If third parties and employees start getting IPv6 through their service provider and you stay on IPv4 only, then their connection will have to be proxied to you. Because the session is proxied, you lose the ability to have end to end connectivity, something taken for granted in our IPv4 only world.

Lack of IPv6 has real world costs and impacts, and you are simply kicking the can down the road with the potential for even greater pain the longer you wait to adopt.

How do we start down the IPv6 path of enlightenment? What do we need to do next?

Well, as I mentioned earlier, education has been identified as the key thing people need, at all levels. This means you need to invest in educating your staff on how to design, deploy, operate and maintain a network running IPv6 and also one doing dual-stack. You will need to have an education plan and resources in place for your company to learn all this. Most importantly, this does not happen overnight, you need to start NOW! Why? Because once your staff is educated it is much easier to build a plan. A plan needs to be tailored to your company needs and requirements. You need to include testing and validation of network, operating systems, apps and everything in between to insure you are on the right path. Oh, and you will need a lab – trust me on this one. You will need people from every team involved in the education and training. Why? Because while IPv6 at first glance appears to be a networking only function you will quickly discover that your application, database and help desk teams will need to know, understand and troubleshoot it. You will also need to understand the business impacts of starting the adoption of IPv6. Seriously? Did he just say business impacts? Yes, you many have critical home grown business applications that do not work with IPv6. You might have partners in the world that only have IPv6 as a protocol option. You likely want to understand what the impacts will be before you run into an unpleasant surprise along the way. If the majority of your business is on, from, or coming across the Internet then supporting IPv6 is critical to your business.

Let’s say I still have not convinced you. You still don’t believe you will be using IPv6 anytime soon in your company. Well, the last holdout OS in the market that did not support IPv6 was Windows XP and Microsoft end of support happened on April 8 2014. This means if you are deploying a newer OS (Microsoft Windows, Apple iOS and OSX, Android, Linux, FreeBSD, CentOS, etc.) of some kind, guess what? Yes, that is right, you will be dealing with IPv6 regardless of how much you want to avoid or ignore it.

IPv6 is the future and the future is NOW!


Ed HorleyEd Horley is the Practice Manager for Cloud Solutions and Practice Lead for IPv6 at Groupware Technology in the San Francisco Bay Area. Ed is actively involved in IPv6 serving as the co-chair of the California IPv6 Task Force and additionally helping with the North American IPv6 Task Force. He has presented at the Rocky Mountain IPv6 Summit, the North American IPv6 Summit, the Texas IPv6 Summit in addition to co-chairing and presenting at the annual gogoNETLive IPv6 conference in Silicon Valley. He has also presented on IPv6 at both Microsoft TechEd North America and Europe, at TechMentor in Redmond, Orlando and Las Vegas, at InterOp in Las Vegas and at Cisco Live in North America and Europe. Ed is the author of Practical IPv6 for Windows Administrators from Apress (2013). He is a former 10 year Microsoft MVP (2004-2013) and has spent the last 18+ years working in networking as an IT professional. Ed enjoys Umpiring Women’s Lacrosse when he isn’t playing around on IPv6 networks. He maintains a blog at where he covers technical topics of interest to him and is on twitter at @ehorley.

IETF 90 Part 1

ARIN Advisory Council member, Cathy Aronson, is at IETF 90 in Toronto, Ontario, Canada this week. Follow along as she shares her findings with us on TeamARIN!

Guest blog post by Cathy Aronson

Cathy Aronson

Yesterday morning I attended the IEPG (Internet Engineering and Planning Group) meeting here at IETF 90.  George Michaelson of APNIC gave an interesting presentation about Teredo (a tunneling technology that allows IPv6 capable hosts to use IPv6 over a IPv4 only connection).  George’s slides are here.  The great thing about his presentation is that he observed Microsoft doing exactly what they said they were going to do.  They turned off their Teredo relays.  It is clear in George’s graphs that the Microsoft Teredo relays have been turned off.   The presentations about sunsetting Teredo are linked here:

George talked about how the Microsoft relays continue to cause a lot of zombie tunnels. Microsoft is apparently still sending “who am I” endpoint signaling but not carrying IPv6 data.   Further there are a lot of other autonomous systems that are serving up Teredo tunnels.  George listed them in his presentation and suggested that they stop doing Teredo.


IPv6 Effects on Web Performance

Will IPv6 positively affect web performance in the future? Blake Crosby shares his thoughts on the answer to this question.

Guest Blog Post By Blake Crosby

There are a lot of efforts to improve the speed of the web. The inevitable release of HTTP 2.0 in the near future will address many of the existing web performance bottlenecks.

Will IPv6 increase web performance in the future?

The answer is Yes! IPv6 has many improvements over its v4 counterpart that will help make the web a faster place.

Packet Fragmentation

IPv6 does not fragment packets; this means that any packet reassembly does so at the client or at some other endpoint. The router is free to use those extra CPU cycles to move packets faster through the network.

Checksumming Done at Higher Layers

Routers don’t need to spend time checking the integrity of the IPv6 header (for TCP packets). Instead, validating the data packet happens at the TCP layer. Less work for the router means moving those packets faster!

Keep It Simple

The IPv6 packet header is much simpler than the IPv4 header, making it much easier to process these packets as they flow through routing equipment

IPv6 and IPv4 Packet Headers

For example, the Time To Live (TTL) field has been replaced with a Hop Limit field (a simple counter), thus routers don’t need to calculate the time the packet has spent in queues. One less calculation to be made before sending that packet along to the next hop.

Bigger Is Better

Reducing the number of round trips is the best way to improve your web browsing experience. IPv6 can help with that by using Jumbograms. Having the ability to squeeze up to 4096 MB in a single packet will reduce the number of round trips required to download data. Provided the link layer has a large enough MTU.

Better Mobile Performance

Due to IPv4 limitations, mobile devices need to use Triangular Routing in order to receive and send packets to/from the Internet. In triangular routing, the mobile device is able to send packets directly to the remote host; however, the remote host must route packets through a “Home Agent” which can be very far away from the actual user.

For example, a particular network may have a limited number of home agents. If the mobile device is located in San Francisco, and the mobile carriers home agent is located in Houston, all packets destined for that San Francisco mobile device must be routed through the home agent in Houston.

Mobile IPv6 eliminates the need for this network architecture. Packets need not be routed through a home agent.

If you are interested in learning more about the challenges of improving web performance, see my analysis of IPv4 versus IPv6.  Additionally, I highly recommend “High Performance Browser Networking” By Illya Grigorik.


Blake CrosbyBlake is an Operations Engineer with Fastly, the smartest CDN on the planet.

His intimate knowledge of web performance ensures that Fastly stays ahead of the curve with emerging technologies.

He’s also on the Board of Directors for the Toronto Internet Exchange (Torix).


IPv6 Addressing Tips

Ross Chandler, Principal Network Architect of IP network evolution at Eircom/Meteor, shares a few tips on working with IPv6 from his own experience.  The bottom line? You can do this!

Guest Blog Post by Ross Chandler

The most significant changes with IPv6 are: vastly more addresses and the way the extra bits are used. Here are a few practical tips for when you’re adding IPv6 to your network and connected devices.

Don’t stress about the length of IPv6 addresses

The long ones only occur when they’re generated automatically. Don’t attempt to read out one of these long addresses for another human being. You can assign shorter IPv6 addresses by static configuration or by DHCPv6.

Use the 4-bit nibbles when making an addressing plan

The 4-bit (hexadecimal) character positions makes subnetting easy.

e.g. Your assignment might be 2001:db8:1234::/48

This can be subnettied into 16 /52s  (prefix length increased by 4)






Each of the /52s can be further subnettted into 16 /56s





And so on down to the /64s.

Combining contiguous nibbles allows a prefix to be subnetted into a larger number [16^(number of nibbles)] of smaller subnets with prefix length increased by 4 * (number of nibbles).

2001:db8:2014:1000::/48 can be subnetted into 16 /52 prefixes. 16 = 16^1 and 52 = 48 + 4 * 1.

2001:db8:2015:1200::/48 can be subnetted into 256 /56 prefixes. 256 = 16^2 and 56 = 48 + 4 * 2.

2001:db8:2016:1230::/48 can be subnetted into 4,096 /60 prefixes. 4,096 = 16^3 and 60 = 48 + 4 * 3.

IPv4 subnetting is not as simple as that.

Odd or even address conventions

If you use a /30 IPv4 subnet on a link then a /126 IPv6 prefix length will allow both the IPv4 and IPv6 address at either end to be odd or even.  Similarly for /31 IPv4 or /127 IPv6 links.

You can be liberal with your use of IPv6 /64 prefixes

Don’t be afraid to be liberal when assigning /64s. It’s often helpful to think of 64 bit prefixes as the smallest unit of address assignment of v6. For example, assign a full /64 for each point-to-point link even if you intend using a /126 or /127 mask. This is all right because whether there are 1 or a 1,000 devices on the LAN, compared to the 2^64 possible addresses both are almost equally sparse. Stateless address autoconfiguration (SLAAC) mandates the use of a /64 prefixes on LANs. This fact and the :: compactor allows manually assigned IPv6 addresses to be written in short form with almost half the number of characters as a typical SLAAC assigned address.

Assigning more specific IPv6 subnets

You can make assignments with larger prefix lengths. For example, you may have IPv4 DNS server addresses and and so decide to use the first two addresses from your IPv6 allocation for your IPv6 DNS server addresses 2001:db8::1 and 2001:db8::2. The service number (e.g 53 for DNS) could be the host part of the address.


Ross ChandlerRoss Chandler
Principal Network Architect – IP network evolution





IPv6 Advice for Service Providers and Home Users

Preparing for IPv6 is easier than you’d think. Chris Phillips, Managing Partner of Aptient Consulting Group gives some useful advice for service providers and home users who are ready to make the effort toward IPv6.

Guest Blog Post by Chris Phillips

Oliver Wendell Holmes once said, “The mode by which the inevitable comes to pass is effort.” With ARIN’s available IPv4 addresses dipping below 1.5 /8s, an IPv6 Internet is inevitable. But the effort bit is underwhelming, at best.

At the current rate the old addresses are being acquired, we may see complete IPv4 depletion by the end of 2014. Yet just a slim 12 percent of the Alexa top 1000 most-visited websites on the Internet are reachable through IPv6. An even more minuscule 2.75 percent of Internet users reach Google via IPv6. And according to the Amsterdam Internet Exchange – the world’s largest single Internet exchange point by member ports – a paltry 0.6 percent (IPv4 2,469 Gbps vs. IPv6 15 Gbps) of traffic exchanged is over IPv6

Based on the disappointing IPv6 adoption numbers, it seems like businesses are avoiding the new protocol because they believe the transition is too difficult. But in my professional experience preparing for IPv6 is actually quite simple.

Service providers

Network service providers who already have an IPv4 allocation from ARIN will find it is easy to get IPv6. All you need to do is apply for an IPv6 allocation, and the process is usually far less complicated than applying for an IPv4 allocation because different policy requirements apply. For example,  instead of the rigors of justifying each subnet as small as a /29 from your current IPv4 assignments, like you would if you were applying for additional IPv4 addresses; your IPv6 allocation size is determined by the number of geographically diverse locations your network has for an end user. Once you provide ARIN that information, you can be allocated a minimum of a /32, or 79 decillion (yes, that’s actually a real number) IP addresses.

Once you have IPv6 addresses, adding them into your existing network is astonishingly easy in most well-engineered networks.   Most tier 1 and tier 2 carriers offer\ native IPv6 transit services and will have no problem accommodating your BGP announcements.  Adding IPv6 into your IGP is also very simple.  OSPFv3′s configuration syntax is nearly identical to OSPF’s on both Cisco and Juniper equipment.  Running OSPF and OSPFv3 in parallel is uncomplicated.  The case is the same for IS-IS.  A lot has been written about how to add IPv6 to your network.  IPv6 implementation will vary depending on your infrastructure, so there’s no one “right” way. But a quick Google search for “IPv6 IGP” should yield a lot of useful results, including many from popular hardware vendors.  Once you receive your IPv6 allocation, it should only be a matter of days before you can start offering IPv6 services.

IPv6 at home

For end users, adoption has been negligible.  Understandably, this is the slowest market to adopt IPv6 – even though it’s the market that needs it the most. The disappointing statistics with regards to IPv6 adoption on the Alexa Top 1000 seem to bear out the perception among uninformed end users that parts of the Internet will become unreachable to them. In actuality, 6to4 gateways will ensure they can communicate with IPv4-only networks. Fortunately for savvier home consumers, Comcast, the largest eyeball network in the US, has started rolling out IPv6 to those users who want it. Comcast customers can log onto to find out whether their areas support IPv6, and how to enable it.

What Can I Do?

Petition your cable and DSL provider to adopt IPv6.  They likely already have a plan in place to adopt IPv6, but it may not be a priority if there doesn’t seem to be much consumer demand.  Inform them that ARIN only has 25 million IPv4 addresses left. That works out to just one IPv4 address for every 7.88 Americans, and doesn’t count Canada and many parts of the Caribbean, which are also served by ARIN. The time to act is now.

Petition your hosting provider to add IPv6 support, or find an alternative provider.. Rackspace, for instance, assigns every new VPS an IPv4 and an IPv6 address by default, and their cloud-based hosted DNS service also supports quad A records.

Finally, you can join me and become an IPv6 evangelist. There are many IPv6 readiness and awareness websites.  Find out how you can become involved in the IPv6 awareness community and help push the Internet’s transition forward. IPv6 is inevitable, but it won’t be pretty without our effort.


Chris Phillips HeadshotChris Phillips
Managing Partner
Aptient Consulting Group






Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


Enhancing Stakeholder Cooperation – Guest Blog

General Manager of LACTLD, Carolina Aguerre, explains the importance of enhanced cooperation for the many diverse stakeholders in Internet governance discussions.

Guest Blog Post by Carolina Aguerre

One of the legacies of the World Summit of the Information Society (WSIS) process is the principle of “enhanced cooperation”. This has been a hotly contested issue in the policy discussions surrounding Internet governance in recent times. The constitution of the “Working Group for Enhanced Cooperation” at the beginning of 2013 is a landmark in the attempts to move forward.

It is well known that the Internet has no owner, and that the forms of exercising control are much more diffuse and complex than those in other intercommunication networks. The Internet’s architecture and its design principles: decentralized, distributed, end-to-end, among others, has imposed coordination and cooperation as key governance attributes of the relationships amongst both stakeholders as well as in the diverse layers of technologies that bring about the Internet. Particularly after the adoption of the Internet at a global scale, cooperation has become a challenge. The Internet pioneers belonging to the scientific communities that promoted the first institutional mechanisms for transnational Internet governance (such as the IETF and the IAB), now coexist with governments, civil society, companies, academic and technical staff which all have different perspectives and capacities to determine Internet policies at a global scale.

With the new millennium, the problem of the new technologies in governmental agendas became much more visible. The challenges to public policy and regulation after the explosion of the Internet in all social orders materialized the need to develop mechanisms to promote an agenda on a topic with diffuse topic, with an impact in specific national contexts in domains such as public administration, health and education. It was in such a context, where organizations such as ICANN had already formed in 1998 for the coordination of critical Internet resources that Kofi Annan, then Secretary General of the United Nations, called for the process called World Summit of the Information Society (Geneva, 2003 and Tunis, 2005).

The Tunis Agenda for the Information Society established two fundamental concepts for Internet governance:

  • (i) the principle that Internet Governance is a multi-stakeholder effort, with specific roles for the different players that participate in its development, use and application in equal conditions;
  • (ii) the principle of enhanced cooperation to promote mechanisms of participation and involvement of all actors, particularly those of governments. 

Enhanced cooperation articles in the Tunis Agenda for the Information Society 

69. We further recognize the need for enhanced cooperation in the future, to enable governments, on an equal footing, to carry out their roles and responsibilities, in international public policy issues pertaining to the Internet, but not in the day-to-day technical and operational matters, that do not impact on international public policy issues.

71. The process towards enhanced cooperation, to be started by the UN Secretary-General, involving all relevant organizations by the end of the first quarter of 2006, will involve all stakeholders in their respective roles, will proceed as quickly as possible consistent with legal process, and will be responsive to innovation. Relevant organizations should commence a process towards enhanced cooperation involving all stakeholders, proceeding as quickly as possible and responsive to innovation. The same relevant organizations shall be requested to provide annual performance reports.

According to Markus Kummer, Internet Society (ISOC) Global Policy Vice President enhanced cooperation is “one of the code words in Internet governance discussions and means different things to different people.  The term goes back to the second phase of World Summit on the Information Society held in Tunis in 2005. There is no common understanding of what is meant with the term, but it is used by some countries to push for setting up a new UN body to deal with Internet issues.”

Between 2006 and 2010 there were several formal attempts to consolidate working principles for this issue. In 2006 Nitin Desai, then special advisor to the United Nations, developed a consultation process which produced no substantive results but which was a starting point. In 2009, a document called “Enhanced cooperation on public policy issues pertaining to the Internet” was published by the UN Social and Economic Council. This report delineated some of the main themes and assessments on the topic and process of enhanced cooperation on the basis of feedback provided by ten organizations. In 2010, another UN initiative with the support of the US government promoted a process of public consultations whereby 98 interventions were received from governments, international organizations, civil society and the private sector.

Since 2015 is fast approaching and that year is a landmark since it is a decade after the Tunis Agenda and evaluations about Internet Governance will be performed, enhanced cooperation becomes of the most controversial issues due to the ambiguity of its definition, scope and operationalization. This has motivated the creation of a working group, a process which began in late 2012 to approach this issue under the institutional umbrella of the United Nations’ Commission for Science and Technology for Development (CSTD).

This group, more well-known as the Working Group for Enhanced Cooperation (WGEC), is formed by 42 members, 22 Member States and then five representatives for each of the following: civil society, technical community and academia, international organizations and the private sector. From Latin America and the Caribbean there are participants from the member States of Brazil, Dominican Republic, Mexico and Peru. The region is also represented by a Andrés Piazza from LACNIC and Carlos Afonso from Instituto Nupef of Brazil. Chris Disspain from .au registry (Australia) is a member of the technical community as a ccTLD.

The WGEC has convened twice in 2013 with the objective of defining the enhanced cooperation agenda and scope of action. Following this line, a survey on enhanced cooperation was launched and it obtained 69 responses. These were analyzed and disseminated during the second meeting of the group, which was held during the first days of November in Geneva and they summarize five main issues:

  • (i) level of implementation of the principles contained in the Tunis Agenda;
  • (ii) public policy issues and possible mechanisms;
  • (iii) the role of the different stakeholders;
  • (iv) the role of developing countries and
  • (v) the barriers for participation in enhanced cooperation.

The following section develops the main points contained in each of these.

The critical issues of enhanced cooperation

With respect to the degree of implementation of the principles for enhanced cooperation in the Tunis Agenda there are three basic positions. In the extremes there are those which consider that it has not been implemented, since no structures have been put in place for governments to develop public policies on the subject (such as the government of Saudi Arabia). Others maintain that enhanced cooperation has been implemented following the processes that promote a multi-stakeholder dialogue, notably the IGF. This position is supported by the government of Japan and Finland, and by ARIN and LACNIC. Middle-ground positions such as those expressed by the Foreign Affairs Ministry of Brazil, or the Association for Progressive Communications (APC), acknowledge that progress has been accomplished since 2005, but that enhanced cooperation has not yet been implemented.

Regarding the mechanisms and public policy issues in enhanced cooperation, there is an agreement that the most relevant themes identified in the main documents such as the Tunis Agenda, the report produced by the Working Group on Internet Governance (WGIG) and the ITU Council Resolution 1035, are barely sufficient since they are not comprehensive enough and they are outdated. Even though several organizations developed compendiums of Internet public policy issues, many consider that this is a moving objective since it is under permanent evolution.

The report also points that the majority of responses value the decentralized open eco-system of Internet governance, comprised by 150 governmental and non-governmental organizations of the technical and private sector. Nevertheless, other responses point to the need to develop new mechanisms in order to face new emerging issues. The most radical proposal of enhanced cooperation mechanisms, in line with those already put forward in 2005 during WSIS, develop the need for an international organization, under the institutional umbrella of the UN, for the supervision of public policies pertaining the Internet, as well as an international board to supervise ICANN. (Initiative proposed by IT for Change, an Indian NGO). The government of Brazil, in line with the actions it has deployed in the last months since the surveillance strategies deployed using cryptography on the Internet, points to the need to develop a new platform, to deal with the new problems that today are out of scope of the current institutional mechanisms of already existing organizations.

One of the most analyzed mechanisms was the IGF. The government of Brazil made an important distinction between the Internet Governance Forum (IGF) and enhanced cooperation as distinct processes. Whereas enhanced cooperation is a “policy–making space”, the IGF is a “policy dialogue space”. The IGF may serve as a ground for future discussions on enhanced cooperation, but according to this stakeholder, this should not be considered as the only forum.

With respect to the role of the different stakeholders, even though paragraph 35 of the Tunis Agenda defines the interests of the main players involved in the process, the survey responses tend to agree that these definitions, and the roles assigned, are not sufficient to cover the interrelatedness of the different issues and current Internet governance mechanisms. The analysis of the different responses distinguishes two positions: some acknowledge a hierarchy between stakeholders, where governments should have a leading position; others on the contrary emphasize the equality of conditions for all. This is a key aspect for the future application of enhanced cooperation.

Under this theme there is a discussion about the mechanisms for the promotion and development of content in national languages, as well as a need to promote national processes, particularly the experiences of national Internet Governance Forums. This last mechanism is one of the most highlighted as an element to promote the participation of developing countries in the Internet governance processes, which is the fourth issue highlighted in the agenda for enhanced cooperation from this survey report.

Regarding the role of developing countries, the generalized assessment of most respondents is that there is an imperative need to incorporate more stakeholders from these countries, inasmuch as they represent the major volume of users of the Internet in the world, and the forthcoming billion. Despite this, the identified barriers do not only respond to a training gap, or to the lack of public visibility of these issues in the national agenda, but also to the need to explicitly open the dialogue in the existing forums to these actors, as the Bulgarian government expressed.

The last issue, barriers to participation in enhanced cooperation, identifies the following obstacles, among others: economic, political, technical, cultural. The Russian government has expressed that there is a participation barrier for governments since the spaces and mechanisms for governmental participation are not clearly defined. IT for Change (NGO from India), underlines that every time new institutional spaces are created, these are overtaken by the same stakeholders, most of the coming from organizations from the developed North. The International Chamber of Commerce expressed that the scarce knowledge on the theme is a central barrier for an effective participation.

There is a long list of issues for improvement and problems raised by this report. The WGEC will meet again in February 2014 to elaborate the main document where the main basis and lines of action will be included in the future agenda for enhanced cooperation in Internet governance.


This post originally appeared in LACTLD Report Year 2, Issue #3


Carolina AguerreCarolina Aguerre
General Manager






Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


Odds and Ends – IETF 88 Part 4 – Guest Blog by Cathy Aronson

ARIN Advisory Council member, Cathy Aronson, was at IETF 88 in Vancouver, BC, Canada last week. Follow along as she continues to share her findings with us on TeamARIN!

Guest blog post by Cathy Aronson

Cathy AronsonIRTF – Internet Research Task Force

On the last day of IETF I went to a group of the IRTF.  It was the Network Management Research Group.  I have to confess I haven’t paid much attention to this group so I wasn’t really sure what they have been working on.  In my mind that morning when I decided to attend that group I thought maybe they would be solving the age old network management problems.  What do I think that is?  Well it is still mostly the case that network management systems (NMS) monitor the network and can usually only tell you when something is down.  They can’t usually tell why it is down.  To me that is the age old problem of network management.  So off I went to this installment of IRTF.

The group is not working on my age old problem with network management.  They are working mostly on autonomous networks.  So basically making the network configure itself and adapt to changes.  The theory is that minimizing human futzing with the network will make it more reliable.

One draft was Network Configuration Negotiation Problem Statement and Requirements.  The premise here is that network devices should be plug and play, less hierarchical and less dependent on humans.  An example they used was that two CGNs might want to negotiate to switch around which IPv4 address blocks they’re using based on traffic and time of day.  The example was horrible because it wasn’t a bit aligned block of addresses and it also had the CGNs connected via the Internet instead of being on the same network.  In this case the address block would have been too small to be advertised on the global Internet.  I suggested they fix the diagram.

There were two other documents describing a framework and implementation of these autonomous networks. I explained my personal concerns about managing all these autonomic networks.  I am not sure that the folks doing this work manage large networks.

The other document is Bootstrapping Trust on a Homenet.  This was super interesting.  The idea is that your home network would figure out its boundaries and build a trust model.  So if someone else plugged a device in it would have to be approved to connect.  The scenario described was one where a home user brings home a router.  They use their phone application to scan the barcode on the box and it has all the information needed to build a trust model in the home.  The phone application would then notify the user if something new connected and give the home user the opportunity to say yes or no regarding its use on the network.  In this way the home network would know its boundaries and what was inside and outside.

Some more odds and ends from IETF

In at least one of my previous ARIN talks about IETF I mentioned Igor’s draft.  The document is now an RFC.

This is the one that describes a problem with the default subnet size in IPv6.  The size is a /64.  This is 18,446,744,073,709,551,616 addresses.  It’s huge.  The average subnet size in IPv4 is 254 usable addresses or a /24.  There are denial of service attacks that could happen if someone scanned a port range that large.  The devices on the LAN have to deal with the requests even though most of the subnet is most likely empty.

In the Benchmarking Methodology group there is now a draft that addresses this issue. This document provides a test methodology to see what happens in this scenario.  At least now it’s possible to see how different networking devices might handle such a scan or just how they may handle a subnet that big.




Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


Please Don’t Push the Buttons Randomly – IETF 88 Part 3 – Guest Blog by Cathy Aronson

ARIN Advisory Council member, Cathy Aronson, is at IETF 88 in Vancouver, BC, Canada this week. Follow along as she shares hers findings with us on TeamARIN!

Guest blog post by Cathy Aronson

Please Don't Push the Buttons RandomlyWell I blinked and it’s already mid week here at IETF.   Here are some highlights as I see them.

Nov 5th the Internet Society hosted a lunch. The topic was “IPv6: what does success look like?”.   I am not sure if we determined yet what success looks like.  Some ideas were these:

  • Usage of IPv4 is trending downwards
  • VPNs also ran over IPv6 so corporate networks running IPv6 would work for folks connecting in remotely
  • A large wireless company pushing out v6 only devices perhaps using NAT64
  • Transition technologies are no longer needed
  • In 2020 we still have the Internet and folks can still get to everything
  • Users get IPv6 by default from their ISP
  • Software is IP version agnostic. IP is IP and should not mean IPv4

I think some really great things are happening.  For example, Comcast’s John Brzozowski says that 75% of their broadband network now supports IPv6 and 25% of those are currently using it.  Next year they plan to have 100% of their broadband network supporting IPv6.   Right now, however, when they turn up a home with IPv6 only 20% or so of the traffic is IPv6.  This needs to improve.   As I have mentioned before in my talks Comcast is also looking for ways to do all their internal traffic over IPv6.   They also have an IPv6 only trial in the works.

Another positive is that Teredo (a transition mechanism) is going to be turned off sometime next year.  Last month at the ARIN meeting I talked about the experiment where they turned of Teredo briefly.  Chris Palmer says that Microsoft will still be using Teredo for peer to peer Xbox applications but not for relay service.

Right now 2% of the Internet traffic is IPv6.  They now can show IPv6 and IPv4 on the same graph without the scales being hosed (it’s the simple things).  The trend in the slides was definitely up and to the right.  These are all good signs.

Cathy Aronson So what else is going on at IETF?  I’ll circle back on some more IPv6 stuff in the upcoming days but I want to talk a little bit about the “Internet-wide Geo-Networking BOF”  It is stated to be “Location aware solution that provides packet delivery using geographical coordinates for packet dissemination over the Internet”.

I am still trying to get my mind around this and to decide if it’s the bad idea fairy or not.  The idea is that there are all these devices out there, for example, cars. So an application may want to tell all the cars in a geographic area where the closest open charging station is located.  They talked some about geographically assigned addresses and at first it seemed they were talking about IP addresses but then it seemed as if maybe they meant some huge database of geolocation addresses that map to IP addresses.  I am having a hard time getting my mind around some car speeding down the road at 70mph and a service trying to maintain at any moment in time where it is and how to contact it.   Further these cars may be connected to different ISP infrastructures.  Just as an FYI if you want to read further there is a vehicular wireless standard that is 802.11p.

So next… as you might expect there is a lot of time being dedicated to security and privacy on the Internet in light of the NSA gathering large amounts of data on everyone.  The IETF is starting to formulate how it is going to be dealt with in Internet Standards.

From the technical plenary on November 6th the following summary has been set out.  These are a series of IETF “hums”.  Basically for those of you who haven’t been to IETF the whole process is based on “rough consensus and running code”.  Rough consensus is often determined by asking folks to hum (yes literally).  These are the hums from the plenary.

1.  The IETF is willing to respond to the pervasive surveillance attack?

    Overwhelming YES.  Silence for NO.

2. Pervasive surveillance is an attack, and the IETF needs to adjust our threat model to consider it when developing standards track specifications.

    Very strong YES.  Silence for NO.

3. The IETF should include encryption, even outside authentication, where practical.

    Strong YES.  Silence for NO.

4.  The IETF should strive for end-to-end encryption, even when there are middleboxes in the path.

    Mixed response, but more YES than NO.

5.  Many insecure protocols are used in the Internet today, and the IETF should create a secure alternative for the popular ones.

    Mostly YES, but some NO.

So we’ll see what happens with this over time.  I suggest that everyone interested in this subject join the IETF perpass mailing list.

Also this draft is really relevant.  I expect more work to be done in this area over the upcoming years.



Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


IETF 88 Part 2 – Guest Blog by Cathy Aronson

ARIN Advisory Council member, Cathy Aronson, is at IETF 88 in Vancouver, BC, Canada this week. Follow along as she shares hers findings with us on TeamARIN!

Guest blog post by Cathy Aronson

Cathy AronsonNovember 4, 2013

The first day of IETF is in full swing.   There is a lot of IPv6 activity today and I will write about that next. First, I feel that I need to emphasize something that happened this afternoon.  In my opinion it is of particular interest to the ARIN community.

This afternoon was the Internet Governance BoF.  The mailing list is (subscribe by sending email to   The IETF,  like ARIN and the RIRs,  is starting to get involved actively in the Internet Governance Forum (IGF) and other Internet governance activities.  I think this is a good idea.  The thing that got me to the microphone in the session today is the fellow who stood up and said that part of the solution to the problem is to give countries large blocks of IP addresses.  Someone stood up at a past IETF and asserted the same thing.  The theory is that there is so much address space in IPv6 that it’s basically infinite (which of course it isn’t) and that we should just make every government happy and just give each a huge block.

I went to the microphone to explain that there is a global bottom up process for handing out IP addresses and each region sets that region’s policies.  I suggested that the IETF folks become familiar with that and not suggest that blocks be given to governments.  I am particularly passionate about this because if the IETF asserts that the RIRs don’t work or that they should be bypassed that is not good for the Internet routing system (at least in my opinion).    Even worse in this case it is as if some folks in the IETF have no idea that the RIR system exists.

In addition assigning address blocks geographically, although an interesting intellectual exercise, is not technically feasible.  The aggregation is done on Internet Service Provider (ISP) boundaries not on geographic boundaries.  Sure,  occasionally this mimics the geography but more often it doesn’t match the geography.

In my opinion it’s discouraging that folks at the IETF are asserting that a fix to Internet governance is breaking routing and aggregation.   I encourage folks who are interested to join the mailing list and participate in guiding the IETF’s role in Internet governance.



Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


IETF 88 Part 1 – Guest Blog by Cathy Aronson

ARIN Advisory Council member, Cathy Aronson, is at IETF 88 in Vancouver, BC, Canada this week. Follow along as she shares her findings with us on TeamARIN!

Guest blog post by Cathy Aronson

Cathy Aronson

Hi everyone.  This is my first blog post.  I am at IETF 88 in Vancouver.   This morning I attended the IEPG meeting.  So first a little bit of background.

IEPG is the Internet Engineering and Planning Group.  IEPG is an informal group that has been meeting before IETF meetings for the past 20 years.  The focus of the group is on operational matters on the Internet.  Sometimes there are a lot of presentations and sometimes there are only a couple.  There is a mailing list and there is a document archive at

Today’s meeting was pretty interesting.  The first talk was about RPKI and Origin Validation deployment in Equador.  The LACNIC folks have been working on RPKI tools and deployment in their region.  A problem in the LACNIC region is that folks say they are not deploying RPKI because they have no experience with RPKI but in order to get experience they have to deploy RPKI.

In this deployment they turned up two route servers, one at each NAP.EC location.  These ran origin validation.  97% of all of Equador’s traffic goes through these exchanges.  This pretty much rolled out RPKI for that country.  This was an almost 10% increase in the uptake of RPKI for the LACNIC region.

As I presented at the ARIN meeting last month.  LACNIC is leading the way with RPKI tools  They have a tool that generates ROAs and also a looking glass that shows how an ORG’s routes are being announced.

RPKI and Origin Validation Deployment in Equador - Sofia Silva Berenguer, LACNIC


There was another interesting talk by Geoff Huston about whether folks are using Google’s public DNS.  They are using a google advertisement to get who it is that is querying and which resolver is being used.  7.2% used Google and 92.8% used others.  5.3% just use google and when it fails they don’t query anyone else.

The slides on who is using google are super interesting and I recommend that folks take a look.


Fernando Gont talked about fragmentation and extenstion header support in IPv6 Internet.  We know that service providers filter fragments but it turns out they filter extension headers too.  Someone from the audience mentioned that it is most likely firewalls that do this filtering.  More info can be found at

Fragmentation and Extension header Support in the IPv6 Internet - Fernando Gont


At the last ARIN meeting I talked about the DNS Hammer draft.  This is the draft that talks about how many hours folks spend clearing DNS caches and provides a mechanism to automatically refresh the cache instead of having someone manually do it all the time.  The Resolver Data Prefetch talk today is similar but in this case individual records are fetched when the timers (TTL) is going to expire.

The hammer draft is here:

The prefetch draft is here:

Resolver Data Prefetch - Wouter Wijngaards, NLnet Labs


“Making Special Better”  – Perl Liang from ICANN.

The special registry that the IANA maintains has gotten updated by the IANA.  The database no contains all special prefixes and what they are used for.  This will assist ISPs in generating the appropriate filters for these blocks.  This is nice work by the IANA and will help the community a lot.

Making Special better – Perl Liang, ICANN


Paul Vixie talked about security issues with DNS.   Paul asserts that there are problems with the DNS that the IETF should be solving.   I think it would be interesting for the IETF to take up these problems.  It does seem that DNSsec would solve most of the issues.  Maybe we should figure out why DNSsec isn’t more widely deployed?  Source address validation would also fix most of the problems but source address validation depends on the bad guys and they’re not going to do that.

On the Time Value of Security Features in DNS - Paul Vixie, Farsight Security


Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


Teaching IPv6 to Old IPv4 Pros – Guest Blog

So you know IPv4 subnetting? Great, you’re on your way to learning IPv6, but some things will need to be “unlearned”.  Sean Wilkins shares the issues he believes could be stumbling blocks for IPv4 pros just getting started with IPv6.

Guest blog post by Sean Wilkins


Over the last several years I have taken advantage of some health issues and transformed my successful career as a full-time network architect/engineer/consultant into a career as full-time technical author/writer.  With this transformation have come a number of challenges that mainly revolve around how best to speak to a large audience about specific technical topics. One of the most requested article topics I have needed to cover for a number of different sites has been IPv6.

Educating the Educated on IPv6

IPv6 has of course been around as a general technology for a number of years (more than a decade in fact), but has been slow to implement for a number of different reasons. With the number of ‘connected’ companies, individuals and devices rising exponentially, it is only a matter of time before IPv6 implementation will be more of a forced change than a choice; this has finally brought many companies to the conclusion that they should get ready for IPv6 and time is quickly running out.

One of the stumbling blocks I have seen for many people is how the math of IPv6 subnetting works especially compared to IPv4 subnetting. Many experienced engineers who have known IPv4 for years need to learn or re-learn the concepts behind hexadecimal math and understand how it differs from the binary and decimal math that they are used to dealing with when implementing and operating with IPv4. It seems that often just looking at the length of the IPv6 address can be a stress inducer, and all those non-numeric characters can make anyone cross their eyes for a few minutes.

But in my opinion, IPv6 is really much easier to work with than IPv4; there are certainly much larger network ranges to deal with that eliminate many of the problems that many of us remember from first implementing IPv4. This includes no classful vs classless; no Class A/B/C and for many network engineers, the host space will almost always (at least for the foreseeable future) be a 64 bit range which simplifies it even further. The point here is that the biggest obstacle for experienced engineers learning IPv6 subnetting is essentially the initial shock of moving an entrenched brain from binary/decimal to hexadecimal.  Once this state has been passed, many will realize rather quickly that IPv6 subnetting is simple.

Another point that I can’t highlight enough when learning IPv6 is the need to hook up some gear (physical or virtual) and play with it.  Most of the major networking vendors have very mature IPv6 implementations and just configuring them into simple common scenarios will help solidify the concepts that engineers will need to implement in a production setting.


The main point that I am trying to make here is that like many technical subjects, the first step for many is to just relax and take the new concepts one at a time.  Sometimes this means un-learning what you know and trying to ‘retrain’ your brain to see something from a different angle. With many experienced IPv4 engineers, this will be part of their IPv6 learning journey; taking the high level concepts that have been learned and become embedded and ignoring some of them in favor of the new mathematical concepts introduced with IPv6.

Hopefully the people reading this article learning IPv6 for the first time and finding themselves a bit bewildered, can take some of the advice given in this article to help in their journey towards IPv6 expertise.


I have written a number of different topics on IPv6 over the last few years; for those interested check out the following links:

Don’t Kill Yourself Over IPv6

IPv4 and IPv6 Subnetting Differences

IPv6 Address Notation

I am also in the process of launching my own content site that will be a shortcut to all of the articles and books that I am involved with; this will be located at


Sean WilkinsSean Wilkins
Network Consultant/Technical Author
SR-W Consulting/infoDispersion






Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


INTERNET PROTOCOL VERSION 6: Are You Sure You Should Not Be In It? – Guest Blog

Should engineers bother with IPv6 yet? Network engineer, Anthony Kellar, gives his perspective on the issue.

Guest blog post by Anthony Kellar

Go to an I.T. conference and listen for the buzz words.  You hear the word, “Cloud”….and people stop to listen.  “Virtualization”…and engineers will already be aware of where we are heading.  “IPv6”…most people think, “Yea…someday…maybe next decade…when the sky is falling”.

I always considered IPv6 to be like the technology of “Frame-Relay”.  When I first started delving into frame relay, there was this weird “Data-Link Connection Identifier” thing, that worked between you and the Internet Service Provider, but, oh yea, it is locally significant, and it is a source identifier rather than destination.  Huh?  Really?

Then comes IPv6 and you see the IP address of “2001:db8:147:18cc::112:143”.  Really?  Imagine the help desk call.

“Yes ma’am.  May I have your IP address please?”

“Ummm…yes, it says 2001:db8 (silence due to cell phone) 14 yadyadyada”.

When most people just look at an IPv6 address, they just think “Don’t understand it!  I don’t like things I don’t understand.  Let’s move on.”

But wait!  It get’s worse.  You buy a Windows machine and you find these totally strange adapters such as Teredo, ISATAP.  You didn’t ask for those!  Why are they there?  What is the impact to your network?  Why does this one have numbers and letters?  Most people aren’t interested…so they move on as long as Facebook and Google are working efficiently.

What I contend, is that we need to get our minds around IPv6.  Not because of the “coolness” factor…but security in what we are doing!

Let’s take an example of a small business.  Most of them do not have a full-time engineering or security staff…they are just working away…using their tools to make their day go….leveraging their computers and network to perform its responsibility…make me money.

A bad guy walks in the door and gets access to the network closet.  He notes that everyone in the company left the machines to the default…with IPv6 enabled.  He also knows, IPv6 is not being used.  What keeps that guy from installing a router and/or PC, putting IPv6 on one interface so that it is the router for the LAN, and putting IPv4 on the other…so that it talks and TUNNELS IPv6 within IPv4.  What did he possibly become?  A man-in-the-middle.

So what is the IT department to do?  Turn off IPv6 and all tunneling adapters from each PC?  Sure…for a small business, I would recommend such a course of action.  Why have your PC try to discover an IPv6 router if one will never exist?  But what about an enterprise?  What are you doing in the long run?  You are turning off a protocol, that someday, may become an intricate part of your corporate infrastructure.  Although a short term fix, this could result in later headaches…running around turning back on what you turned off earlier….then to find you double your headache as you now need to spin IPv6 up.

Let’s face it.  IPv6 is NOT going away.  It gains momentum daily…however small.  There was “World IPv6 Day”…network providers are going from test to realism, manufacturers are building operating systems to prefer IPv6 over IPv4, and it is well known that the Department of Defense has stated all devices must at least be IPv6 capable.

As an engineer, I say learn it…integrate it where it makes sense…SECURE AGAINST IT if you are INCAPABLE OF using it…and SECURE IT IF YOU CAN PRIOR TO RUSHING TO LEARN IT.

Hmmm…rushing to learn it?  There have been “Doomsday” and “Chicken Little” followers stating “IPv6 now as IPv4 is going to quit working some day”.  Nothing can really be further from the truth.  The Internet and organizations will always use IPv4 to some extent.  However, we must pay attention to those out there who are aware of the real problems that exist.

Mobile devices are growing by leaps and bounds; more and more “non-Internet” enabled devices are becoming Internet enabled (TV’s and automobiles for example)…but this is not where the explosion is going to occur.  Devices are going to find Internet presences as a result of their invention!  We don’t really know what those devices are yet…they haven’t been invented yet.

However, I conceptualize that when that big thing comes…everyone will own one.  Everyone will flock to use it…as it is about improving our lifestyle.  And when we consider that a large portion of this planet is not Internet enabled yet…it will be someday…somehow.

The smart engineers out there are embracing the technology of IPv6…and learning it now…so they can design it, they can architect it, they can use it, and oh yes, they can secure it.

Involving yourself in IPv6 today is not about becoming part of the “uber-smart” clan…it is about learning an architecture that is gaining momentum, and being prepared when the real necessity occurs, that you must provide a service to a user that is not IPv4 enabled…but IPv6 only.

I am reminded of one of my favorite quotes from the movie “Under Siege 2”, “Fortune favors the prepared mind”.


Anthony KellarAnthony Kellar
Network Engineer




Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


Beat the Top 5 IPv6 Cable Challenges – Guest Blog

Cable providers can’t ignore IPv6, so what’s holding them back? Stephane Bourque, CEO and President of Incognito Software, takes a look the 5 biggest challenges and how to overcome them.

Guest blog post by Stephane Bourque

Despite the fact that the IPv6 protocol was first made available in 1999, many cable operators have delayed its deployment, and the majority of North American cable providers still have a lot of work to do before migration can occur. In my experience, most operators are daunted by the harsh reality that the transition process is long and complex, and that it must occur even while they are focused on optimizing existing IPv4 resources. Unfortunately, ignoring IPv6 will not make it go away. So what are the major challenges still holding cable providers back?

1. IPv6 is Not Yet Seen as Necessary

Only a small percentage of Internet traffic currently runs on IPv6 and many operators feel that they have enough IP addresses to meet their needs. However, these providers run the risk of not being able to add new subscribers when they do eventually run low on IPv4 addresses. While some have turned to Carrier Grade NAT (CGN) to maximize resources, this is only a short-term solution that adds network complexity and can result in communication breakdowns, reduced performance for end users, and higher management costs, as documented by the IETF. Essentially, CGN is like applying Band-Aids on top of Band-Aids. IPv6, on the other hand, provides you the opportunity to renumber your network and ensures that you have room to grow.

2. Replacement of Infrastructure

The transition to IPv6 involves more than just adding new addresses. Providers will need to upgrade vital infrastructure, such as CMTSs, and ensure that all relevant hardware and software is IPv6-compliant. These upgrades affect all aspects of business, including OSS/BSS and CSR procedures. This can be particularly daunting for smaller and mid-sized providers in established economies where infrastructure already exists and replacing it will be expensive. Conversely, cable operators in developing countries may actually adopt IPv6 earlier than their wealthy counterparts, as governments in these regions build new infrastructure to keep up with growing subscriber bases. However, it’s worth remembering that most equipment produced in the past six to eight years has been built for IPv6 and the remainder usually only requires a firmware upgrade to support IPv6 — so the task may not be as difficult as you think.

3. CPE Upgrades

Providers will also need to upgrade and replace any legacy CPEs for a successful transition. Thankfully, today most new home gateways and cable modems are IPv6-capable. The transition will be much easier — and hopefully seamless for end users — once all subscriber equipment is IPv6-capable. In most cases, a simple configuration change is all that’s required to enable IPv6, but in cases where subscribers have purchased their own equipment, the CPE may need to be replaced. Once you have eased CPEs onto IPv6, you can start exploring transition options, such as running dual stack networks (both IPv4 and IPv6), or Dual-Stack Lite, where IPv6 packets are encapsulated within IPv4 packets for transportation.

4. Time Commitment

The transition to IPv6 requires careful planning and testing. Larger providers in particular tend to spend more time in this phase, which although necessary, can slow the progress of deployment. Even after deployment is complete, it will take time to train staff, from network engineers to CSRs. There are a number of online resources that outline what’s involved in IPv6 preparation, including the ARIN IPv6 Wiki.

5. New Features Cause Confusion

IPv6 has introduced new capabilities, such as prefix delegation, which can confuse the uninitiated. Because IPv6 is much larger than IPv4, cable operators can use prefix delegation to tell routers what network address prefixes to distribute to consumer devices. This lightens the load on provisioning systems and reduces the possibility of downtime. However, some providers have reported problems with hardware vendors not always fully understanding IPv6 capabilities. Again, this issue can be reduced with research and planning. The IETF has an RFC on prefix delegation, along with other resources.

The Road Ahead

IPv6 offers unprecedented opportunities to cable providers but preparedness and education is essential before it can be widely adopted. Although some larger providers are already field-testing IPv6, it may still be several years before large-scale migrations are common in North America, where existing infrastructure and legacy CPEs are not yet compliant.

The first step is to take stock of existing IPv4 resources to understand how and where current addresses are being used. An IP address management (IPAM) solution can provide a comprehensive view of where addresses are deployed to aid IPv6 planning and stretch existing IPv4 resources. A complete solution should include the ability to manage large amounts of IPv4 and IPv6 addresses — both private and public, and customer and internal — as well as track addresses associated with business services. Although there are costs involved in the transition to IPv6, the benefits will save you money in the long run. Once you’re armed with the right information, there really will be no more reasons to delay. Get started by downloading IPv6: The Basics, a complimentary eBook.


Stephane BourqueStephane Bourque
CEO and President
Incognito Software








Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


Key Ingredient in a Successful IPv6 Integration – Guest Blog

What does it take to integrate IPv6 into your network? Jim Bailey describes the major areas you’ll need to focus on while highlighting one virtue you’re going to need at every step along the way.

Guest blog post by Jim Bailey

What do I need for a successful IPv6 integration?  It’s a question that I get quite a bit as I talk with customers that are looking at integrating IPv6 into their networks.  I’ve answered the question in many different ways both technically and business related, but I’ve come to realize that the key piece for a successful integration is…wait for it…patience.  Patience is generally not a feature that is associated with a technical integration project.  Let me explain myself a bit further.

Build the Business Case

One of the first areas of focus for the integration project is to link what you are doing to what the business needs.  This step requires patience because most technical savvy people do not like to build up the dreaded business case.  This step is important because it starts to build consensus across the organization which leads to the next step in the process.

Assemble Your Team

A team needs to be assembled to drive the project.  This team needs representation from all aspects of the IT organization – network engineering/design, security, data center, NOC, applications support/development, OS support, etc.  This step also requires patience because in general these different components in the IT organization are not communicating regularly which means that it can take time to build up the team.  This step is also where having a well thought out business case helps to pull people into the project.

Assess Your Current Environment

Another piece to the integration project is that the current environment has to be assessed for the current capability to support the desired IPv6 features.   This step takes patience because all aspects of the environment need to be evaluated – networking infrastructure (e.g. routers, switches, firewalls, load balancers, etc.), operating systems and applications.  This assessment effort takes time and has to be coordinated across all the IT organizations which makes the team building exercise all that more important.

Execute Your IPv6 Implementation

The last piece is to execute.  The project needs to be broken down into phases, an addressing plan needs to be developed, the designs need to be pulled together, testing needs to happen, feature gaps need to be closed, an implementation plan needs to be decided on and the list goes on.  The time it takes to go through the execution is considerable.  Patience is needed to coordinate all of these activities.

The time it is going to take to successfully steer your organization through the planning and execution of an IPv6 integration project is considerable.  The project will also require extensive coordination among several organizations.  The time to start the process is now and keep in mind that patience is needed.


Jim Bailey Jim Bailey
Advanced Services Technical Leader
Cisco Systems






Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.


Stockholm Syndrome and IPv6 Address Planning – Guest Blog

Don’t be held hostage by IPv4 design requirements in IPv6.  Find out how Tom Coffeen likens the conservation of address space for host assignment in IPv6 addressing plans to Stockholm syndrome.

Guest blog post by Tom Coffeen

Early in my career I was helping a customer provision a DS3 point-to-point link (remember those?). When it came time to configure the IP addresses (and this was before formal certification of IPv6 as a protocol so they were all IPv4 addresses back then), the customer blithely informed me he would be using a routable /16 for the link. Though I hadn’t much networking experience at the time, I was pretty confident that using two addresses out of an available 65,534 was inelegant and wasteful at best, and possibly deserving of some form of corporal punishment at worst.

Flash-forward a decade to the first set of point-to-point links I was preparing to configure on a production network using IPv6. By that time, I had many network designs under my belt and had come to appreciate and rely on the address conservation efficiency provided by VLSM in IPv4. Rather than inelegance and waste, any network interface could be configured with a tidy number of available addresses to accommodate both use and growth.

And if that meant prefix disaggregation, so be it. I could always potentially aggregate my subnets at a higher level in the hierarchy (and if I couldn’t, there was always the fact that a /24 was Internet-routable). I didn’t feel like I had the luxury of time to be concerned with the fact that the IPv4 global routing table was hundreds of thousands of entries and was growing rapidly, consuming ever more router memory and making traffic optimization ever more complicated and costly. As long as I wasn’t wasting IPv4 addresses.

But back to my point-to-point links and their IPv6 address configuration. Based on my experience with IPv4, I naturally assumed such a subnet in IPv6 would be a /127, the minimum number of addresses required for the application. But the first recommendation I came across for a point-to-point link suggested using a /64.

Unsatisfied with that recommendation, I kept digging and found discussions regarding the potential security issues around using a /64 on a point-to-point link (later encapsulated in RFC 6164). Eventually, some were advocating a /127 where supported, but then suggested setting aside an entire /64 for each configured /127. So no matter what, every point-to-point link was going to get a /64. That is, 18 billion billion addresses. Or approximately four billion IPv4 Internets.

IPv6-IPv4 size comparison 1IPv6-IPv4 size comparison 2

Of course, this is also the standard allocation for every LAN interface as well. Given that any given LAN segment can only support a few thousand hosts at most, the quintillion or so remaining addresses in a /64 suggest that conservation has never been a primary concern in the address plan architecture of IPv6. (More evidence of this intent comes from the fact that further subnetting a /64 breaks SLAAC).

Which brings us to Stockholm syndrome.

Stockholm syndrome is defined by Wikipedia as “a psychological phenomenon in which hostages express empathy and sympathy and have positive feelings toward their captors, sometimes to the point of defending them.” For nearly two decades, network architects and engineers have been “held hostage” by an inescapable design requirement when working with IPv4 addressing plans: namely, the conservation of address space for host assignment.

But in designing our IPv6 addressing plan, we have been set free from our former captor in the form of conservation for its own sake. No more subnetting merely to accommodate host counts. Rather, we can now assign groups of prefixes (preferably on hexadecimal nibble boundaries) to location or use types to accommodate operational efficiency. Unused bits within our allocation and plan can be numbered into to accommodate unplanned growth.

And keep in mind that only 15% of the space available in the 2128 addresses available in IPv6 has been set aside for allocation. As routing expert Jeff Doyle recently pointed out in arguing that IP as a communication protocol “is more likely to become obsolete before we run out of IPv6 addresses,” even if the human population reaches the high estimate of 16 billion by 2100, that’s still 2200 /48s per person.

Of course, it is still entirely possible to over- or under-design leading to unnecessary allocation of prefixes. The abundance of IPv6 shouldn’t eliminate the importance of address planning that is as reasonably simple, scalable, flexible, and efficient as we can make it given the requirements of our networks. But we should keep any self-perceived extravagance on our part in the proper (3.4E38) perspective. And let waste now be avoided not out of necessity but rather because it may deprive our address plan of its viability and longevity (to say nothing of its elegance).

Where IPv6 address planning is concerned, it will be tragedy (then farce) if, instead of roaming free across such a practically boundless space, we all keep trying to climb back into our 32-bit cells (like victims of Stockholm syndrome). Instead, paraphrasing a 20th century mathematician’s famous tribute: Let no one expel us from the Paradise that IPv6 has created!


Tom Coffeen headshotTom Coffeen
IPv6 Evangelist







Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.