Guest Blog

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 www.comcast6.net 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.

 

Be Sociable, Share!

    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
    LACTLD
    www.lactld.org

     

     

     

     

     

    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.

     

    Be Sociable, Share!

      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.

       

      Be Sociable, Share!

        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.

         

        Be Sociable, Share!

          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 internetgovtech@iab.org (subscribe by sending email to internetgovtech@iab.org).   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.

          -Cathy

           
           

          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.

           

          Be Sociable, Share!

            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 iepg@iepg.org and there is a document archive at iepg.org.

            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.

            http://www.potaroo.net/presentations/2013-11-03-googlepdns.pdf

             

            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 www.ipv6hackers.org.

            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:

            http://tools.ietf.org/html/draft-wkumari-dnsop-hammer-00

            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.

             

            Be Sociable, Share!

              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

              Overview

              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.

              Summary

              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.

              Resources

              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 http://idisperse.info.

               

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

              http://idisperse.info

               

               

               

               

               

              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.

               

              Be Sociable, Share!

                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
                Blog: www.network-chef.com
                 

                 

                 

                 

                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.

                 

                Be Sociable, Share!

                  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
                  Blog

                   

                   

                   

                   

                   

                   

                   

                  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.

                   

                  Be Sociable, Share!

                    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
                    Blog

                     

                     

                     

                     

                     

                    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.

                     

                    Be Sociable, Share!

                      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.

                       

                      Be Sociable, Share!

                        Calculating IPv4 Run Rate: How to Make Your Own Projections – Guest Blog

                        Have you seen projections of when each RIR will run out of IPv4 space, and wondered where that information came from or even how you could come up with your own? Lee Howard provides easy step by step instructions on how to forecast the run out of IPv4 address space DIY-style.

                        Guest blog post by Lee Howard

                        Everyone should be able to run their own analysis of when ARIN (or LACNIC or AFRINIC, but I’m going to use ARIN as an example) will run out of IPv4 addresses. Here’s how you do it.

                        1. Grab the data (use FTP or web browser) from http://ftp.arin.net/pub/stats/arin/delegated-arin-latest

                        a. Save As a text file

                        b. Open a new worksheet in Excel, do File > Import > CSV File, and choose Delimited, and the | character.

                        c. Delete the summary, ASN, and IPv6 rows.

                        2. Convert dates to dates.  The 20130717 format isn’t recognized by Excel, so in a new column, use this formula (replacing F2 with the cell that has the date): =DATE(LEFT(F2,4),MID(F2,5,2),RIGHT(F2,2))

                        a. You may want to add a few hundred dates after the final date given, to label the projections you’re going to do.

                        3. Save your work!

                        4. Create a new tab to calculate ARIN’s inventory.

                        a. Find the Block Size Distribution of Remaining IPv4 Inventory at https://www.arin.net/resources/request/ipv4_countdown.html

                        b. Copy it into the worksheet.

                        c. I found it easiest to clean up the CIDR sizes by hand; you want a column with just the CIDR value (i.e., “8” for “/8”); the net column is the inventory for that size.

                        d. The third column will be the count of addresses in that CIDR range.  If A2 is the CIDR value and B2 is the count of CIDR blocks, use the formula: =POWER(2,(32-A2))*B2

                        e. Add up all those addresses to see how many addresses ARIN has left.  Check your work: is it equivalent to the number of /8 equivalents shown on ARIN’s home page?

                        5. On the worksheet that has the delegated-arin-latest date, add a column to the last row: the value of ARIN’s remaining inventory (the actual total IP addresses remaining or pull it from the other sheet with something like =’ARIN Inventory’!C19).  This makes sense: this is a list of all of the allocations and assignments ARIN has made, and now you show the inventory after all of those assignments.

                        6. The inventory on the previous row will be how many addresses ARIN had before the assignment.  So for instance, cell J50954 will be =J50955+E50955.  In other words, add the inventory to the number of addresses.  For each row above that, add the amount issued; you can use the autofill function here.

                        7. Save your work!

                        8. Select the inventory column, and Charts > Line Chart.  Your x-axis labels will be the entire date column.  Check your work: does this look like other run-rate charts you’ve seen?

                        9. Run some projections.  Right-click the line on the chart, and choose “Add Trendline.”  Then pick Linear, Polynomial (try different order polynomials!), or whatever looks interesting.

                        10. You may need to adjust the x-axis scale, by right-clicking on the x-axis labels.

                        11. You may want to add charts using different historical sets.  For instance, choose only assignments from 2013, or the last 12 months, or since IANA runout, or since Y2K.

                        Spreadsheet Calculate IPv4 Run Out

                         

                        Here’s what I got when I did this on 14 July 2013.  Sometimes the curves go up; that’s a vagary of trying to draw a curve—it’s very unlikely that ARIN will get more addresses, so upward curves should be ignored.

                        Since Y2K

                        Since IANA Runout

                        Since July 2012

                        Since YTD2013

                         

                        Run your own analysis, and compare to the predictions of Geoff Huston (http://www.potaroo.net/tools/ipv4/index.html) and Tony Hain (http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg and http://tndh.net/~tony/ietf/ARIN-heavy-tail.pdf ).

                         

                        Lee Howard Lee Howard
                        Director, Network Technology
                        Time Warner Cable

                         

                         

                         

                         

                         

                         

                        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.

                         

                        Be Sociable, Share!

                          The Internet. It’s not commodity, it’s community. – Guest Blog

                          Frustrated by the slow uptake of IPv6, Kevin Otte has been doing what he can to become an agent of change.  In this blog he shares his personal journey and experiences educating others about IPv6. What are you doing to help get the word out about IPv6?

                           
                          Guest blog post by Kevin Otte

                          When I was a sophomore in high school, I participated in a job shadowing program. I was paired up with the Network Administrator of a decently sized company in the area. When he first showed me the network core of the building and I saw the lights on the switches, I was hooked. It was a bit like walking into Engineering on the Enterprise, only instead of Hollywood blinkenlights, I could tell what each one meant.

                          Most of the school networks I connected to were very restricted. There were ways out to the Internet, but it usually involved some crazy proxying scheme (the sanest of them was a SOCKS server). Once I made it to university, I saw public IPv4 addresses for the first time. Finally having end-to-end connectivity made life _so_ much easier.

                          I started working with IPv6 back in 2009, but it was still very much a “that’s new and interesting” sort of thing. Nonetheless, I explored the protocol deeply and really started to understand. It wasn’t until early 2010 that I started to see the pressing need. Once I saw John Curran’s “IPv6: No Longer Optional” talk at SouthEast LinuxFest that year, I knew I had to be an agent of the change to come.

                          Public speaking was never my forte, but I knew I had to get the word out. Already being involved with the open source community, this seemed like a prime avenue for introducing people to these concepts. We all use the Internet every day now and probably even see dotted quads without even registering it, but how close to consciousness were the inner workings of the network? A few months later I would find out.

                          In August 2010 I gave my first talk, “Getting Started with IPv6″, to my local LUG. It was very well received and the audience was very engaged with many relevant questions. Thoroughly excited by this, I left them all with a homework assignment: Go home and set up an IPv6 tunnel. This way they could start gaining experience for themselves. At the next month’s meeting, I asked during community announcements who in the group had completed my assignment. Sadly, not a single hand went up.

                          My first major speaking engagement was presenting this same talk at the Ohio LinuxFest in September 2010. Again I had a wonderfully engaged crowd, and conversations went well into the evening. Unfortunately, once the event was over, it again felt like a deafening silence. This, in addition to my local LUG experience, led me to realize that I had to do something more engaging.

                          The coming months led to the creation of a somewhat portable IPv6 test lab where people could bring their own gear to interact directly with the test environment. With the help of my local LUG and hackerspace, I conducted two hands-on workshops in May 2011. In each session I reprised my “Getting Started” talk in very condensed form and then let the attendees go to town. They were smash hits. I don’t think I sat down for more than ten minutes during the seven hour sessions.

                          The lead-up to World IPv6 Launch was spent helping a large university prepare, and reprising my speaking role at the local LUG. Three days after launch, despite Mr. Curran being a tough act to follow, I delivered “IPv6: All Systems Go” to the SouthEast LinuxFest, and this time it was caught on tape:


                           
                          Now that we’re approaching one year past launch, I find it’s time to renew my efforts to engage the community. As such, I’ve made plans to take the hands-on workshop on the road. Of course, conventions are used to dealing with groups rather than individuals when talking about booth space. As such, I formed Flying Penguin Technologies with the help of a friend. We’ll start off at SouthEast LinuxFest 2013, and go on to other venues from there.

                          Much as ARIN has the slogan “It’s not new, it’s now” for IPv6, my takeaway from all this can be summed up in a similar slogan: “It’s not commodity, it’s community.” The Internet isn’t something you just turn on and start using. It’s a huge group of people with a wide range of interests working together, and it’s been an honor to contribute to making it better.

                          Kevin Otte

                          Kevin Otte
                          Flying Penguin Technologies

                           

                           

                           

                           

                           

                          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.

                           

                          Be Sociable, Share!

                            How ISATAP Works and How It Can Help You Migrate to IPv6 – Guest Blog

                            Companies are developing different solutions for IPv6 deployment – here is a blog from a Microsoft Engineer that explains a bit about the approach they have chosen. How is your organization implementing IPv6?

                            Guest blog post by Gregg O’Brien

                            It’s no secret by now that IPv6 is the way of the future. Many IT/Network administrators know that they will inevitably be required to start moving towards IPv6 sooner or later, but the idea of migrating servers, applications, and network infrastructure is a large undertaking.

                            Fortunately, along with IPv6 came a series of transition technologies including ISATAP to make the switch to IPv6 easier.

                            ISATAP stands for Intra Site Automatic Tunneling Address Protocol and is defined in RFC 5214. ISATAP is an interface that hosts can use to pass IPv6 traffic over IPv4 networks. It does this by taking an IPv6 frame and applying headers to the frame with IPv4 network information. The hosts can then send this frame over the network to an IPv6 host, which can then process the IPv6 frame contained therein.

                            ISATAP is pretty easy to recognize. Its addresses are formatted in a very unique way. Here is an example of an ISATAP address:
                            2002:9D36:1:2:0:5EFE:192.168.12.9

                            If you look closely, you will notice that the first portion of the address, 2002:9D36:1:2:0:5EFE: is formatted like a typical IPv6 address. The subsequent portion of the address looks like an IPv4 address – 192.168.12.9. The format of this address provides some key information:

                            1) It is a valid IPv6 address that can be used for IPv6 communication

                            2) The presence of the IPv4 address indicates the IPv4 information that will be used to shuttle the IPv6 traffic over the IPv4 network.

                            But why would we want to transport IPv6 traffic over the IPv4 network? Why not just continue using IPv4 then?

                            Well, the idea here is to facilitate transition to IPv6. Consider the following scenario:

                            An existing IPv4 network in place with several hosts and applications.

                            Proposed Future Network Expansion

                            Investing in overhauling the infrastructure to accommodate IPv6 is a longer term project, but the goal is to do as much with IPv6 now, to save work later.

                            ISATAP can help here allowing IPv6 networks and IPv4 networks to talk to each other. So as the network expands, new hosts and network gear can deployed with IPv6 instead of IPv4, but still communicate with the legacy IPv4 portions of the network.

                            Recently Expanded Network Running on Native IPv6

                            Here we now have two segments of the network, one running IPv4, the other running IPv6. With the use of an ISATAP router and by enabling ISATAP on the hosts present in the IPv4 network, native IPv6 can be deployed on the new network segment. As time passes and hardware/applications are decommissioned, the IPv4 network can be phased out until the organization is fully operational on IPv6.

                            Hopefully that gives you some ideas about how to get an IPv6 project started in your own environment using IPv6!

                             

                            Gregg O’Brien

                            Gregg O’Brien
                            Field Engineer
                            Microsoft

                             

                             

                             

                             

                            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.

                             

                            Be Sociable, Share!

                              How many IPv6 eyeballs are you missing?

                              Guest blog post by Tim Rooney

                              Many organizations have expressed skepticism about deploying IPv6. But they need to understand that the issue is not how much IPv4 address space they have, but how much is available for global distribution. As IPv4 exhausts around the world over time, a new generation of web users possessing only IPv6 addresses will materialize and grow substantially.

                              But when will this new generation of Internet users appear in numbers? Many service providers are masking an indeterminate number of these users due to the necessity of providing them access to both IPv6 and IPv4 web content. This makes it difficult to gauge IPv6 client requests on a global scale, but you can actually measure this, albeit coarsely, on your own web presence. Let’s see how.

                              Presumably, service providers with IPv6-addressed subscribers will attempt to connect using native IPv6 end-to-end if possible, but drop back to using an IPv4-IPv6 co-existence technology such as tunneling or translation should the subscriber’s intended destination be reachable only via IPv4. The means to determine this reachability is initially done via the domain name system (DNS).

                              An IPv6-addressed device will attempt to resolve a user-selected URL to an IPv6 address by issuing a DNS query for the AAAA resource record type for the URL The service provider’s caching DNS server, to which the subscriber device directs this query, will attempt to locate the DNS server on the Internet that is authoritative for the corresponding domain, then query the server for the AAAA record. Should the query resolve successfully, the result is returned to the subscriber device and it will attempt a native IPv6 connection. If unsuccessful, the caching server may issue a similar DNS query for the A resource record type to determine if the destination is configured with an IPv4 address.

                              If the subscriber device has only an IPv6 address, configuring the caching DNS server as a DNS64 server provides a standardized method to translate the returned A record query result into an IPv6 address. When this synthesized IPv6 address is returned to the subscriber device in the form of a synthesized AAAA query response, the device will  attempt to establish connectivity via a service provider NAT64 gateway, which interconnects the service provider IPv6 network with the IPv4 Internet.

                              If the subscriber device is dual stacked, with both an IPv6 and an IPv4 address, it should issue both the AAAA and A queries itself, then apply its address selection policy table to determine which source and destination addresses to use. The default policy table implemented by most common operating systems today does favor IPv6 in the event of results returned from the AAAA query. If the AAAA query fails to return results, the device will attempt to initiate the connection via IPv4.

                              The bottom line is that IPv6 end users may be attempting to connect to your website using IPv6. The best way to determine this is by analyzing your DNS query logs. Review your query logs for AAAA query rates over time to identify increases in AAAA queries. As mentioned, this metric is rather coarse, as caching DNS or DNS64 servers will cache  responses received from other DNS servers, but it can serve as a useful indicator of IPv6 connection attempts to your website.
                               

                              Tim Rooney
                              Product Management Director
                              BT Diamond IP

                               

                               

                               

                               

                               

                              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 made by a guest blog post. ARIN shall not be liable for any representations, omissions or errors contained in a guest blog post.
                              Be Sociable, Share!