Tag Cloud:

Defining Depletion: IPv4 Address Availability in the ARIN Region

By Richard Jimmerson, Chief Information Officer, ARIN

Here at ARIN we have been actively discussing the depletion of the IPv4 free pool for many years. Our goal has been to prepare the Internet community for the day when we can no longer issue IPv4 address space to those who need it. As that day approaches, there has been increased interest in how IPv4 addresses are issued and what the options are after we reach depletion. To help provide more insight into the status of IPv4 at ARIN, this will be the first of a blog series to keep you informed about IPv4 depletion and the current status of IP addresses remaining in our free pool.

IPv4 Depletion is Real

One of the major milestones of IPv4 depletion was in February 2011 when the Internet Assigned Numbers Authority (IANA) issued their final /8 blocks to each of the Regional Internet Registries (RIRs). Working with our final /8 blocks, each of the RIRs were well into establishing their respective countdown to depletion procedures.

In the ARIN region, a four-phase countdown plan was created that described how ARIN would distribute its remaining IPv4 address blocks. Today we are in the 4th and final phase of that countdown plan.

Remaining IPv4 Inventory 18 March 2015We have also been publishing information on a regular basis about the remaining IPv4 free pool inventory at ARIN. As of today, our IPv4 inventory stands at .31 of a /8. We also publish the number of discrete block sizes that remain in the inventory. This information is available and updated daily at our IPv4 depletion information page. In addition to the inventory, you can also find information about the various options to obtain IPv4 address space through ARIN policies as the ARIN IPv4 free pool depletes.

Defining Depletion

Depletion means different things in different parts of the world. In some of the other Regional Internet Registries, depletion has been associated with the triggering of “final” IPv4 regional number resource policy when the RIR dug into it’s last /8 of inventory. For ARIN no such policy existed, but we have already been issuing from our last /8 for almost a year now. ARIN’s current IPv4 inventory no longer includes /8s, /9s, or /10s, so depletion of these size blocks has already occurred.

Within the ARIN region, depletion status varies depending on the needs of an organization. For some larger organizations in the ARIN region, their IPv4 address space needs going forward may exceed the amount they can obtain from ARIN’s remaining inventory, i.e., depletion has effectively already occurred for these organizations. For others, depletion will soon become a reality.

We expect to receive requests in the coming months that qualify for IPv4 block sizes that are no longer available in ARIN’s inventory. In these cases, organizations may elect to be placed on a waiting list for their qualified block size, or elect to receive a smaller block size that is still available in the ARIN inventory. Organizations may also obtain IPv4 address space through a transfer from another organization. More information about these options are available at our IPv4 depletion page.

As ARIN gets closer to IPv4 free pool depletion in the coming months, we will provide additional updates. If you have ideas for topics or questions that you’d like us to address in this blog series, please let us know in the comments below or on social media.


IPv6-Brewed Coffee Over Bluetooth Smart

Glenn Ruben Bakke explains how Nordic Semiconductor is connecting to the Internet of Things using IPv6 over Bluetooth Smart in everything from keyboards to coffee makers.

Guest blog post by Glenn Ruben Bakke

IOT IPv6 Over Bluetooth Smart

Believe it or not, the day has come when your coffee machine could know what exactly what kind of coffee you like to drink depending on the cup you’re using, the time of day, and a multitude of other factors. Earlier this year, the Nordic Semiconductor team demonstrated a smart coffee machine at CES that brewed coffee over IPv6. But coffee machines aren’t the only place where innovation is possible. As a leader in Bluetooth Smart solutions you will find our chips in products all around your home from wireless keyboards and mouse, TV remote controls all the way through to wirelessly controlled toys. Basically, we are already in a wide range of diverse devices. So, for us, extending those devices connectivity through the internet was the next logical step.

We are a strong advocate and believer that the right long term approach for connecting everything to the Internet is by using open standards. In this way obstructive barriers to cross-platform, device and OS communications will be dissolved.

IPv6 Over Bluetooth Smart

Recently a lot of effort has been made by the Internet Engineering Task Force (IETF) to make the Internet suitable for smaller devices, something that is referred to as 6LoWPAN. Bluetooth Smart Specific adaptations and recommendations for 6LoWPAN are being defined as BLE 6LoWPAN and can be found here.

BLE 6LoWPAN enables compression of IPv6 traffic and optimizations in procedures (for example, neighbor discovery) on Bluetooth Smart. BLE 6LoWPAN defines Stateless Address Autoconfiguration (SLAAC) of IPv6 addresses using the Bluetooth Smart Device Addresses. The 6LoWPAN-enabled Bluetooth Smart device will derive a EUI-64 address based on its own EUI-48 MAC address and this is combined with the assigned prefix to form an IPv6 address.

Stack Diagram

BLE 6LoWPAN defines two roles for Bluetooth Smart devices: the 6LoWPAN node role and 6LoWPAN edge router role. In the 6LoWPAN node role Bluetooth Smart devices can connect to the internet over Bluetooth Smart using a border router. The border router role acts as a device that is connected to the internet and provides access for the nodes to the internet.

6lowpan Roles

IPv6-enabled Coffee Machine

We wanted to demonstrate the exciting possibilities that this technology enables and we wanted to show that by doing something practical. What better way than brewing coffee over IPv6? – not only demonstrating a connected appliance that can be controlled and monitored from the Internet, but also getting a nice cup of coffee at the end of it.

The coffee machine, being IP enabled, has its own IPv6 address which means it is directly addressable from the Internet. Also, native support IP protocols allow the coffee machine and the cloud application to use the same protocol without any need of proxy or translations. The application protocol used in this demo is MQTT, a TCP based protocol.

In this demo you can request a brew through the web interface. You can also see if the coffee machine is brewing or idle, the number of cups brewed etc. – all examples of monitoring a remote appliance.

We used the following hardware components to brew coffee over IPv6:

  1. Coffee machine – connected to the nRF51 Development Kit playing the role of BLE 6LowPAN node role and an MQTT client.
  2. Raspberry PI   – playing the role of BLE 6LoWPAN router providing connectivity to the internet to the coffee machine by routing packets between its Bluetooth and Ethernet network interfaces.
  3. PC symbolizing a cloud server. The PC provides the software infrastructure of the demo.

Coffe Machine Setup

The software pieces we used are:

  1. MQTT broker. MQTT protocol requires a central broker that manages messages between various clients that connect to it. Here, HiveMQ is used as the broker.
  2. Django web server providing an interface to control the coffee machine.
  3. Database is used to store information related to the coffee machine.
  4. A controller module that listens for messages from coffee machines. Any updates or request to the database are handled by this module.

Coffee Web Interface

Routing on Raspberry Pi

Once a 6LoWPAN node connects to the Raspberry PI, a Bluetooth network interface appears on the Raspberry Pi. Routing packets to this Bluetooth Network interface is like routing packets on any network interface. Linux provides a router advertisement daemon, radvd, which is used in this setup.

The radvd is setup to delegate an IPv6 prefix to all the endpoints connecting to the switch so that global IPv6 address can be created on the nodes using State-Less Address Auto-Configuration (SLAAC). The Ethernet interface (eth0) takes care of devices connecting to the simulated global network, and the Bluetooth interface (bt0) takes care of the IPv6/6LoWPAN over Bluetooth Smart devices connection. For Bluetooth, radvd will give each node on the link (bt0) a 2001:def:: prefix, and for Ethernet each node will get a 2003:abc:: prefix using 2003:abc::1 as gateway.


6 radvd config

A route is also put up between the global network (eth0) and the Bluetooth/6LoWPAN network (bt0) that connects the 2001:def:: subnet to 2003:abc:: subnet. This makes the Bluetooth nodes available in the simulated global network.

Routing on Raspberry PI

With this setup each coffee machine can create a TCP connection to the MQTT broker using its global IPv6 address, publish messages and listen to responses or commands.

We were proud to demo our IPv6 coffee machine at CES earlier this year and see it as the first – and major – step of many devices into IoT over IPv6.


Glenn Ruben BakkeGlenn Ruben Bakke is a Software Engineer who has been developing software for Nordic Semiconductor’s nRF51 Series ICs as well as working on the development of the IoT SDK.





The Per Scholas Approach to Bringing IPv6 into the Classroom

Eduardo Hernandez of Per Scholas shows why IPv6 is an essential part of the curriculum for IT students as they prepare for jobs in the tech industry.

Guest blog post by Eduardo Hernandez

I am an instructor at Per Scholas, a national nonprofit organization that provides free technology education, career development and job placement services to unemployed and underemployed individuals throughout Columbus and Cincinnati, OH; Dallas, New York City, and Silver Spring, MD. We take pride in providing comprehensive technical training to individuals with no background in technology, and on average the school trains approximately 800 students a year and 75 percent successfully go on to land jobs in tech.   I take a lead role in making curriculum enhancements and adjustments based on the industry trends (I am also a graduate of the program myself!), and recently we decided to add IPv6 to the curriculum.

Per Scholas Teaching

Despite struggles in adaptation, IPv6 is clearly the future when it comes to finding a solution to the currently depleting addressing space.  It is with this thought that Per Scholas is beginning to roll out changes in our curriculum, which not only embrace IPv6, but successfully train students in becoming proponents and implementers of the addressing scheme.  This means that we are assisting nearly 600 freshly trained students with broad technical skills and new perspectives to enter the IT workforce this year with IPv6 networking skills that employers are looking for.

For those unfamiliar with networking, IPv6 can be overwhelming and exceedingly complex. As educators it is imperative that we approach IPv6 via active student participation. To implement this philosophy my students create an account on https://www.sixxs.net at the beginning of my first IPv6 lesson.  SixXs is a free IPv6 tunnel broker.  Once students create an account they may apply for their own tunnel.  Upon tunnel creation students are given their own IPv6 address to a public PoP, along with a range of routable subnets.  The idea behind this approach is that students will go home and do the same procedure on their home networks, thus increasing their knowledge base and preparing for the future of total IPv6 implementation.  Once a student has successfully created a 6-to-4 tunnel on their computer, various other lessons are assigned which further their understanding of IPv6.

Following this preliminary experience with IPv6, we are then ready to tackle the complicated task of IPv6 subnetting.  When it comes to subnetting most educators will agree that it is one of the most difficult concepts for students to understand.  With IPv4, subnetting was necessary, and although with IPv6 it is not required it is still very important for a network technician to know.  Subnetting IPv6 is rather daunting since students need to train their brains into working with hexadecimals.  As practice exercises students work with the subnets given to them from the tunnel broker and apply them in class.  This allows them to see the fruits of their labor.

IPv6 is here to stay! As more and more people get connected to the web, with every device having its own IP address, and the Internet of Things (IOT) becoming a reality, there will be more demand for technicians who can implement IPv6.  The Per Scholas approach is to give students the best tools to succeed in the ever-changing IT world, so that is why we have added IPv6 to our curriculum. It is important that IT educators give the tools necessary for success to their students.  I for one am glad to finally get rid of NAT and the complexities of setting up IPv4 networks.  IPv6 is the future; it is time to embrace it.


Eduardo HernandezEduardo Hernandez is an Associate Director of Technical Instruction at Per Scholas. He began his career there 2 years ago as a student.  He took part in an advanced IT training program called Project Scale.  Upon graduation Eduardo obtained valuable industry certifications: CompTia A+, Security +, and Cisco CCNA certification. Prior to his position at Per Scholas, Eduardo graduated with a Bachelor’s Degree in Computer Science from Pace University and worked as a Network and Security consultant. He also ran a successful after-school tutoring business.

IPv4 Depletion Status at ARIN

By Leslie Nobile, Director of Registration Services, ARIN

What happens after ARIN depletes its free pool of IPv4 address space?  Will there be a Phase 5 added to the IPv4 Countdown Plan? Is the IPv4 inventory counter always accurate?  These are just some of the questions we’ve been hearing in recent weeks. We understand that IPv4 depletion is causing confusion and uncertainty, so we’d like to try address some of these common questions and provide some additional information on the current status of IPv4 address space at ARIN.

Update on the IPv4 Countdown Plan

ARIN moved into the final stage (Phase 4) of its documented IPv4 Countdown Plan in April 2014. ARIN’s IPv4 countdown plan was designed to have only 4 stages, which means that we will continue working in Phase 4 as we move toward full depletion of ARIN’s available IPv4 inventory.  ARIN will not be adding a Phase 5 but will continue in Phase 4 when IPv4 needs will be met through IPv4 address transfers and the IPv4 waiting list.

You can find more detail on the Countdown Plan on our website and in some earlier blog posts (dated April and October 2014). In Phase 4, all IPv4 requests are processed in the order they are received and are team-reviewed by ARIN’s resource analysts. While team review has slowed down overall processing times, we are working diligently to streamline the process and maintain our standard two-day response time on all IPv4 request tickets.

Although you might have expected to see a rapid increase in IPv4 requests, or a “run on the bank” once we hit our last /8, IPv4 resource traffic has actually remained fairly steady since that time.  We did see a slight increase in April 2014 after we announced that we had reached Phase 4 of the Countdown Plan, but other than that, things have been fairly consistent.

2014 Requests for IPv4 Address Space

2014 Delegation Issued by ARIN

The IPv4 Counter

The IPv4 inventory counter displayed on ARIN’s homepage (see it on the bottom right at www.arin.net), was designed to provide the community with a daily snapshot of how much IPv4 address space ARIN has left in its available pool. The counter shows the total number of /8 equivalents remaining in ARIN’s available IPv4 inventory as well as a list of the total number of prefixes available of any given size.  “Available space” includes our current IPv4 inventory minus any returned, reclaimed, or revoked address blocks that may be in a hold status.  Hold status is a term that describes address space held by ARIN until it clears any filters before being released back into ARIN’s IPv4 free pool. The “Available space” as reflected in the IPv4 counter fluctuates regularly based on new allocations and assignments being issued, and incoming address space being taken off its hold status.

ARIN IPv4 Counter 2.6.15

If you use our daily ARIN-issued mailing list to help you keep track of how much IPv4 address remains in ARIN’s inventory, you will find that it does not match the IPv4 inventory counter on our homepage. In fact, you will likely find several discrepancies between the ARIN-issued report and the IPv4 inventory counter.

The ARIN-issued mailing list provides a daily report of IPv4 and IPv6 address space returned to ARIN’s available inventory and IPv4 and IPv6 address space issued directly by ARIN to its customers. The data reported in the ARIN-issued report also includes IPv4 address space issued via 8.3 transfer which is NOT included in the IPv4 counter.  Additionally, once ARIN approves an IPv4 address block, it is immediately removed from the available inventory and placed on hold until registration fees have been paid and a Registration Services Agreement has been signed.  These resources will not show up in the available inventory, nor will they show up on the ARIN-issued report until all administrative tasks have been completed.

As we watch the IPv4 counter continue to drop, ARIN will strive to keep things running as smoothly as possible.  IPv4 depletion comes as no surprise, and as we reach these final stages, we will continue to conduct “business as usual” and provide our customers with the best possible service we can. And in the face of ultimate IPv4 depletion, we will continue to encourage all ARIN customers to get their IPv6 address space to ensure the future growth of their networks. There is plenty for everyone!


ARIN moves main operations out of HQ

By Mark Kosters, Chief Technology Officer

Moving BoxesLast year, ARIN Engineering undertook a monumental effort to move production from our headquarters in Chantilly, Virginia to a colocation center in Ashburn, Virginia. There were many reasons behind this big move, and we were very happy to complete a flawless transfer of our operations.

ARIN has its offices in an office park nestled next to Dulles Airport in northern Virginia. Because of the proximity to the airport having essential production systems singularly located at ARIN’s headquarters is certainly not an optimal situation.

We are also located right at the junction of two major commuter routes, which has its own pros and cons. Based on the existing land use and exit paths (most bounded by Dulles airport), our power situation has been at times, unreliable.  There is only one power feed into the office park and no redundancy, poor network access (only two providers serve the office park) and lack of sustainable power in the event of a failure. To make matters worse, there has been substantial construction on one of these commuter routes, which has resulted a couple of unplanned outages. Because we are committed to ensuring ARIN is available online 100% of the time, we decided it was best for us to move our operations out of ARIN HQ to a more suitable location with robust power and more abundant connectivity options.

ARIN spent a good deal of time testing services before we moved. Our environments are standardized to help with system configuration management software (Puppet) that made the move easier. After a year’s worth of planning and work to prepare for this event, we successfully moved the systems from ARIN HQ to the colocation center. Our only hiccup on moving day was some weird behavior dealing with multicast on our new Juniper switches. We got the issue solved and opened the front door to the public close to 9:00 PM on 1 November 2014. We are happy to report the new colocation has been working out well since the move, and ARIN’s provisioning systems are now more reliably placed to better serve you and perform the essential operations of the Internet.



CES 2015: Bringing IPv6 Answers to the World of Consumer Electronics

By Sean Hopkins, Communications and Technical Editor

Last week ARIN set up shop in the Las Vegas Convention Center alongside a veritable ocean of technology experts and gadget gurus. From automotive technology to personal drones, one of CES’ main themes revolved around all the exciting ways that new devices could connect and take advantage of the Internet.

ARIN Booth at CES

Most of the new gadgets at CES are identified by and will connect to the Internet using IP addresses, which are anything but new. As we hit the home stretch of IPv4 depletion, it’s imperative that IPv6 be enabled on not just new devices but also on the websites that advertise and sell them.

This isn’t a new story, and IPv6 once again found a place on the CES agenda. John Sweeting of Time Warner Cable attended the “Getting to 50 Billion Devices: CEA & The Internet of Things” panel and offered the following comments:

The focus of the panel was to inform attendees that it was really time, perhaps past time, to start deploying IPv6 in order to realize the potential of the Internet of Things. The panelists provided their views on building future proof IPv6 devices, and a new standard was introduced. The new standard, CEA-2048, defines the technical requirements for IPv6-enabled connected devices and home routers. This specification will help developers target the right features for IPv6 compatibility. It’s great to see the consumer electronics industry getting serious about IPv6 with this new standard.

We were happy to see IPv6 connectivity on websites of several CES exhibitors including:


We also found some IPv6-brewed coffee while at the show. John Springer, ARIN Advisory Council member, explains, “It was great to establish contact with Nordic Semiconductor. Those folks have an interesting story with their intent to shift Bluetooth device communications into the cloud via IPv6 and 802.11.” They were demonstrating how even coffee machines could work over IPv6.

Nordic Semiconductor CES


For more information on how you can get your products and services ready for IPv6 check out our IPv6 Info Center and IPv4 Depletion and IPv6 Adoption pages, and we’ll see you at our next event!



CES 2015: Is your web content ready for IPv6?

By Jennifer Bly, Public Relations and Social Media Coordinator, ARIN

This week ARIN is at CES, the largest technology tradeshow of the year.  We will be reaching out to consumer electronics industry movers and shakers to educate them about the importance of deploying IPv6 on all public facing web services.  In the video below, one of the founding fathers of the Internet, Vint Cerf, explains the issue:

Are you unfamiliar with IPv6?

Stop by our booth in Tech East to discuss why IPv6 needs to be at the top of your company’s technology goals for 2015.  You want to be reaching the whole Internet, not just part of it.  Collectively we all want to be able to continue to grow Internet products and services ad infinitum. As Vint said, he’s “urging you to implement IP version 6.”

Is your company’s website IPv6-enabled and participating in CES this year?

Tweet us @TeamARIN and we’ll come find you.  We want to highlight you on social media, and let people know that your company is an IPv6 leader.  We believe we can gain more momentum for IPv6 adoption by commending the successes that companies have already made.  Let us celebrate you!  As peers (and competitors) in every industry begin turning on IPv6, the pressure to deploy IPv6 to will be even greater.

And whether you are at CES or not, do follow us on Twitter as we wander the halls of CES in search of technology’s forward thinkers and IPv6 early adopters, and share our findings with you.


ARIN by the Numbers

By Jennifer Bly, Public Relations and Social Media Coordinator

This year has been an exciting time for us here at ARIN, so we thought we’d take a peek at some fun numbers from 2014. Some of these you’ll probably expect – like how many IP addresses we’ve issued throughout the year, and others you probably won’t – like how many cups of coffee we’ve drunk (yes, we’re a bunch of coffee addicts). Enjoy these stats as we reflect on our year!

ARIN by the Numbers

  • 71,161 /24s of IPv4 blocks issued (includes end users and ISPs)
  • 103 vacuum pots of coffee brewed
  • Approximately 20 ARIN Online improvements made
  • 9,010 + calls received at the RSD Help Desk


  • 1 Movember themed sprint planning demo complete with mustaches
  • 165 ARIN announcements to the community on arin-announce mailing list
  • 1,957,790 user sessions (3.5% growth over previous year) and 1,037.516 unique visitors (0.7% over 2013) to www.arin.net static site
  • 6 fellows who attended their first ARIN meeting as part of the Fellowship Program
  • 445 IPv6 blocks issued to both end users and ISPs
  • 3,817 phone calls taken in our Financial Services Department
  • 1 employee who sits on a balance ball
  • 22 employees who use standing desks
  • 107,969,050,127 total of all whois queries to date
  • 55 fellowship applicants from Canada, the Caribbean, and USA combined

Fun with Andys Hat

  • 16 photos of staff members wearing this hat at ARIN 33
  • 6 years the average employee tenure
  • 3 software engineering teams: Cyan, Citron, and Crimson
  • 292 stories completed in the Engineering Department, give or take a couple
  • 59 employees
  • .45 /8s of IPv4 address space remaining as of today’s date
  • 11,520 Doritos eaten at the ARIN office (our best guess)
  • 55 outreach events on our calendar
  • 155 uses of the feedback button April through October, with more new feedback rolling in regularly
  • 496 new members
  • 5,002 total members


  • 1,472 ASNs issued, 378 of which were 4 byte ASNs
  • 12 hours a day the Registration Services Help desk has been open for business from 7am-7pm Monday through Friday
  • 56 Blog posts (including this one)
  • 14 Guest blog posts
  • Roughly 780,000 K-cups of coffee and tea consumed at the office
  • 510+ cups of coffee served at ARIN Public Policy & Members Meetings
  • 1,829 Tweets tweeted
  • 5 new hires


  • 34,822 pages views and 21,509 user sessions on 23 April 2014 when we announced we’d entered Phase 4 of the IPv4 Countdown plan making this our largest day of web traffic ever
  • 15 three week long sprints
  • 314 8.2 transfers, 38 8.3 transfers, and 33 8.4 transfers total
  • 858 total LinkedIn followers
  • 4,231 individuals subscribed to arin-announce
  • 21,200 invoices sent out
  • 11 ugly holiday sweaters worn to the office last week

Ugly Holiday Sweaters

  • 2 Public Policy and Members Meetings
  • 3 Public Policy Consultations
  • 8 ARIN on the Road events
  • 9,925,248,239 IPv4 whois queries so far in 2014
  • 42.26% of browsers visiting arin.net with Chrome, the most used browser compared to the top browser accessing arin.net 10 years ago in 2004 at 72.1%
  • 2,205 people subscribed to arin-ppml


  • 30 suggestions submitted to ARIN
  • 491,569,720 IPv6 whois queries so far in 2014
  • 3 new faces and 6 returning ones elected to the Board and Advisory Council during fall elections
  • 130.4% increase in traffic from mobile devices and a 70.8% increase in traffic from tablets to our website
  • 22 draft policies proposed, the highest since 2007
  • 17 year milestone reached this year with ARIN’s incorporation as a nonprofit in 1997


New Get 6 Campaign Launched at ASAE Tech Conference

By Susan Hamlin, Director of Communications and Members Services

After many years of outreach to our core community of Internet Service Providers, web hosting companies, cable providers and large academic institutions, we are branching out.  We are now working to drive all organizations with a web presence to put their content out over IPv6, with an emphasis on public-facing websites in particular. We took our new Get 6 booth to the American Society of Association Executives (ASAE) Technology Conference last week with the message to connect to the whole Internet with IPv6.

ARIN Get6 booth at ASAE Tech Conference

The new display worked well to draw in folks as the typical question we kept hearing was, “get what?”  We cut right to the chase by asking the association communications, marketing and IT folks, “Is your website important?”  Their obvious response was always “yes” and that provided us with an easy entrée to talk about why their website should be available over IPv4 and IPv6. We kept our message simple, “Ask your webhosting provider when they can turn up your website over IPv6.” Lastly, we handed everyone a short checklist of things to do, especially if the association was large enough to be serving up its’ own website.

As we move into 2015, we will be looking for audiences of CEOs, Chief Information Officers, Chief Marketing Officers, and communications/marketing/public relations directors to educate about IPv6. Our hope is that they will take our message back to their company have a three way internal conversation with IT, communications/marketing/PR, and the CEO who will need to support the business case to start the planning process. Getting public facing web services available over IPv6 is goal number one for businesses who want to thrive on the Internet. It isn’t easy, but it’s time to start.

If your company’s website is currently running over both IPv4 and IPv6, we would like to hear from you! Be a role model and share on our TeamARIN site why you made the move.  Just drop was a note below or at media@arin.net.



Invitation to Review CRISP Draft Proposal

By John Sweeting, ARIN CRISP Team Member

The ARIN Consolidated RIR IANA Stewardship Proposal (CRISP) team members, along with our colleagues from each of the other four RIRs, are hard at work preparing the proposal to submit to the IANA Stewardship Transition Coordination Group (ICG).  (Check here for background on the IANA Stewardship Transition) We’ve had four conference calls so far in addition to an initial face-to-face meeting.  We held our most recent conference call yesterday on 18 December, and we are making good progress. The first draft of the Consolidated RIR IANA Transition Proposal is now available for review and comment.  See the PDF of the Draft Response to the Internet Coordination Group Request for Proposals on IANA from the RIR community.

IANA Transition Discussion

The draft addresses all six parts of the ICG’s RFP including:

  • Number Community’s Use of IANA
  • Existing, Pre-Transition Arrangements,
  • Proposed Post-Transition Oversight and Accountability Arrangements
  • Transition Implications
  • NTIA Requirements
  • Community Process

Key points in the proposed transition are:

  • Continue with ICANN as operator of the IANA function
  • Exchange a service-level agreement with ICANN as the IANA function operator on number resources
  • Establish a Review Committee with representatives from each RIR region

Discussion of this proposal will be held on the NRO global mailing list, so please subscribe to ianaxfer@nro.net to provide your feedback on the first proposal from the numbers community.

For links to all documents and meeting notes please visit the NRO CRISP Team Page. Your comments on the first draft of the proposal are due by Monday, 5 Jan. 2015. The second draft of the proposal is scheduled to be published on 8 Jan. 2015 with the end goal of the submitting the final proposal to the ICG on 15 Jan. 2015. With these tight deadlines in mind, please take the time to review the proposal soon and provide your input to the mailing list.


Set Up IPv6 in Your Own Home

Jeremy Duncan, Managing Partner and IPv6 Architect at  Tachyon Dynamics, gives his opinion on some good applications and tunneling providers you can use to get IPv6 in your home if your ISP doesn’t offer it already.

Guest blog post by Jeremy Duncan, Tachyon Dynamics

IPv6 in home or residential networks is getting much better.  North America has seen exponential IPv6 use on the Internet year after year since World IPv6 Launch (6 June 2012).  Residential Internet service providers like Comcast and Time Warner are almost singularly responsible for this sharp and dramatic growth.  However, if you aren’t a Comcast or Time Warner user, it’s a totally different story.  I’m one of those users, and I want to pass on some of the great ways to setup your own IPv6 internet access using one of the great (and free) IPv6 over IPv4 tunnel providers.

Don’t Have IPv6 at Home?

So your ISP is one of any of the minor and major ISPs that have no IPv6 implementation currently.  What can one do?  Do it yourself!  I’ll show you a few applications and tunneling providers to use, as well as ones to never use.

Hurricane Electric

This is probably the best IPv6 in IPv4 tunneling provider out there today. Also, it’s free for small networks. The provisioning is very easy. The graphic below shows how to provision a tunnel and it gives you sample configurations for your gateway of choice. Basically, anything that can do a 6in4 tunnel (IPv4 protocol 41) can use this service. This includes any workstation or server operating system, router, firewall, or custom CPE (e.g. OpenWRT).


Just go to http://tunnelbroker.net. Once there, you can create an account, and select “Create Regular Tunnel.” There it will ask you which PoP you’d like to use and what your public IPv4 source address is. Once you click “apply,” the full configuration screen will be presented and your tunnel is activated and ready to connect. If you aren’t sure how to do tunneling configured you can click “example configurations,” and it will give you the exact CLI configuration needed for your gateway of choice. For example, here is one for a Cisco IOS router:

configure terminal

interface Tunnel0

description Hurricane Electric IPv6 Tunnel Broker

no ip address

ipv6 enable

ipv6 address 2001:db:1:1::2/64

tunnel source

tunnel destination

tunnel mode ipv6ip

ipv6 route ::/0 Tunnel0


Once you have the tunnel up and running, go back into the provisioning page and click “request a routed /48 prefix.” With this prefix you can assign 65,536 /64 network on your home LAN. That will probably be enough for now. :)

Other Hurricane Electric Services:


SixXs is more of a community supported tunneling service. They aren’t backed by a large corporate entity like Hurricane Electric, but still provide a few good tunneling services. They were one of the first 6in4 tunneling providers to the industry.

When you navigate to https://www.sixxs.net, sign up for an account. SixXs is very diligent about keeping tunnels up and healthy and are constantly checking on the health. When you have an account you get points for how long your tunnel remains up, and are subtracted points when your tunnel is down. You can cash these points in for /48 prefixes and other little goodies along the way. These incentives keep the overhead of maintaining dead tunnels to a minimum as it is community supported.

Their data rates don’t match Hurricane Electric. I see comparable IPv4 to IPv6 tests with Hurricane Electric, but much slower with SixXs. However, it remains a very good, free, and relevant IPv6 in IPv4 tunneling service. SixXs also provides:

  • Automatic IPv6 Client Utility (AICCU): This is a client-side software application that uses UDP port 5072 to tunnel IPv6 over IPv4 UDP. Certain networks may not allow UDP port 5072 outbound, so use this with care. Details are here: https://www.sixxs.net/tools/aiccu/
  • IPv6 website gateway: This URL-based proxy allows you to connect to IPv6 enabled website using an IPv6 domain name. For example, http://ipv6.google.com.ipv4.sixxs.org will get you to the IPv6 only Google website, but the SixXs gateways will proxy you using IPv4 to your web browser. Details are here: https://www.sixxs.net/tools/gateway/
  • IPv6 Unique Local Address (ULA) registration site: As per RFC 4193, ULA address must not be routable, but must still be globally unique. This site will use the algorithm to generate globally unique addresses, then will register them so organizations can use them later as bogon lists if needed. Details are here: https://www.sixxs.net/tools/grh/ula/


GoGo6 was a company that sprang from Hexago. Hexago was the company that created the appliance-based IPv6 tunnel broker. It was an all in one, and easy to deploy, full tunneling solution. The company is called GoGo6 now and it’s product is called GoGoServer. It offers a free service for users to connect using a client application similar to SixXs, but with more tunneling options: 6in4, UDP port 3653, and DS-Lite. More details on this service is here: http://www.gogo6.com/freenet6/tunnelbroker  That client application configuration looks like this:


GoGo6 also offers the following services:

  • Appliance/CPE for the client-side tunneling called GoGoCPE that is sold for a very small cost: http://www.gogo6.com/gogoware/gogocpe
  • You can register for the free IPv6 social network called GoGoNET. Most of the IPv6 industry professionals are here and able to talk and answer questions. Details are here: http://www.gogo6.com/getting-started
  • GoGo6 also has an annual conference where they bring in industry experts and talk about IPv6 issues of the day called GoGoNET Live. Details for that event is here: http://gogonetlive.com/

Tunneling You Should Never Do – Ever!

The previous services and providers I mentioned are very good and have a lot of management and oversight around them. However, there are a few services you should never use for the following reasons:


Don’t ever enable this. If your Windows machine is on a Windows domain, whatever you do don’t re-enable it. If you have a home PC, then you need to disable it ASAP! Use the DisabledComponents registry key to do this. Just follow this registry path:


Now in this path create (or edit) the 32-bit DWORD file DisabledComponents with a decimal value of 1. Then reboot your machine. This setting will disable all IPv6 tunneling mechanisms on your machine. This is best practice for all Windows machines unless it is a DirectAccess Server.

So why is Teredo so bad? One word: control. First, the tunneling mechanism uses UDP port 3544 for client-to-server communication. However, that’s not the only port. Once the server assignes the address to the client it then directs the client to a Teredo relay based on Anycast. This means the client could theoretically be pointed to a Teredo relay anywhere in the world. At this point the Teredo-enabled client can get to the IPv6 Internet through the Teredo relay anywhere in the world. That is the bad part. So I recommend never using it, ever.

  • Disable IPv6 tunneling in DisabledComponents
  • Block UDP destination port 3544 and 3545 on your gateway device


Don’t ever enable this either. Regardless if your Windows machine is on a domain or not this function is always enabled. However, it will not configure itself unless it has a public IPv4 address. However, if it does have a public IPv4 address, then the Windows machine does not need a server to configure its address. It uses a 6to4 addressing algorithm as explained in RFC 3056. This algorithm from an IPv4 only client to the IPv6 Internet uses the 6to4 prefix, IPv4 public source address, the subnet ID, and the local IPv4 private address. So it looks something like this: 2002:4A7D:2B63: 5EFE::C0A8:0064

When setting up 6to4 on a local LAN, the subnet ID can be configurable, but Microsoft uses the 5EFE subnet ID. Once it auto configures this address the windows machine will go out to ipv6.microsoft.com. That DNS name resolves to the public IPv4 address of the Anycast 6to4 relay. This machine will then be able to go to the IPv6 Internet. The same security problems remains as with Teredo, it could go anywhere in the world.


  • Disable IPv6 tunneling in DisabledComponents
  • Block protocol 41 on your gateway device


The residential ISPs are doing better. Between Comcast and Time Warner, users mostly likely have IPv6 in their networks. However, others still trail behind. There are many good and free tunneling solutions from Hurricane Electric, SixXS, GoGo6, for home users to try. However, I recommend to never use Teredo and 6to4 for security reasons outlined above. If you have any questions or comments about this blog please don’t hesitate to reach out to me at jduncan@tachyondynamics.com


Jeremy DuncanJeremy has spent over 10 years working in enterprise IT doing next generation technology deployments like IPv6, advanced networking, and open source solutions.  He participates regularly with the North American IPv6 Task Force; often speaking at the North American IPv6 Summits each year.  Jeremy spent 11 years in the U.S Marine Corps deploying to Iraq twice during Operation Iraqi Freedom 1 and 2 as a Communications and Information Systems Officer.  Jeremy has worked in the DoD with a wide range of information security, network engineering, and network architecture experiences with DISA, JITC, DTRA, and DTIC.  He currently leads up Tachyon Dynamics’ DoD UC APL and IPv6 training and engineering portfolios. He has a Masters of Science in Information Systems and is married with two wonderful children.


5,000 Reasons to Celebrate

By Jud Lewis, Member Services Coordinator, ARIN

We are glowing because we have just reached 5,000 Members! We wanted to get you each a cupcake with 5,000 candles but with local fire ordinances and all, we hope you enjoy this picture instead.

Cupcake with candles

ARIN is a member-based organization, and we couldn’t have made it this far without the support and guidance of our Membership. Since our inception, you have participated in 34 Public Policy and Members Meetings, initiated and discussed over 88 community-developed policies, and cast over 21,000 votes in ARIN Elections. Thank you!

When ARIN was established in 1997, we had just 100 member organizations. As the Internet expanded so did ARIN, averaging about 30 new Members each month.

ARIN membership graph

ARIN’s Membership structure differs from most of the other Regional Internet Registries as holding Internet number resources from ARIN Is a prerequisite for obtaining ARIN Membership.

The vast majority of ARIN Members are Internet Service Providers, who are granted automatic membership when they receive a direct allocation of IPv4 or IPv6 addresses. Currently ARIN has 4,949 Subscriber Members. Some examples of ARIN Subscriber Member organizations include Google, Galaxy Networks, Comcast, and PGI Solutions LLC. ARIN also offers an option to be a Paid Member to organizations that have Autonomous System numbers (ASNs) or direct assignments of IPv4 or IPv6. Currently ARIN has 53 Paid Members like Blue Cross and the National Water Commission (Jamaica).

We rely on our members to be “good citizens” by voting in elections, attending meetings, and participating in the policy process, so we can continue to fulfill our mission. The primary benefit and responsibility of the ARIN Membership is voting each year in ARIN Elections for the ARIN Board of Trustees and Advisory Council. So we especially appreciate all the Designated Member Representatives (DMRs) of member organizations  who vote in ARIN Elections. ARIN Members can also subscribe to the ARIN Discuss Mailing List, publish the ARIN Member logo on their website, and appear in our online member list.

ARIN Member Logo Sample

Considering applying for Membership?  You can click here to find application instructions.  Perhaps your organization is already an ARIN Member.  If so, we encourage you to consider becoming more involved by attending an ARIN Meeting.  Our next meeting is ARIN 35 in San Francisco from 12-15 of April. If attendance isn’t in your budget, we encourage you apply to an ARIN Fellowship for a chance to attend your first meeting at no cost.

ARIN Members are the organizations that have paved the Information Superhighway that is increasingly critical to our region’s economic, educational, and social lives. Thank you ARIN Members for all of your vital work and we look forward to watching our membership numbers continue to rise as the Internet soars to unseen heights!

If you have questions about membership please reach out to ARIN’s Communications and Member Services Department at info@arin.net.



Meet your 3 ARIN Region CRISP Team Members

By Bill Woodcock, John Sweeting, and Michael Abejuela

If you’ve been involved in the Internet community for any length of time, then you know we can’t speak more than a couple minutes without dropping 1 or 2 (or 10) acronyms at a time. Well, here’s one more to add to the alphabet soup – the CRISP team, short for the Consolidated RIR IANA Stewardship Proposal (CRISP) team.

The CRISP team was established by the five RIRs (there we go again, the Regional Internet Registries) to develop a single proposal on behalf of the numbers community for the IANA Stewardship Transition to the IANA Stewardship Transition Coordination Group (ICG). Each of the global numbers, protocol, and names communities are tasked with presenting unified proposals, and the CRISP team will be facilitating the process for the IP addressing community.

Meet the 3 representatives on the CRISP team from the ARIN region as they introduce themselves to you:

Bill WoodcockBill Woodcock

President and Research Director at Packet Clearing House

In addition to his seat on the ARIN Board of Trustees, Bill Woodcock is the Executive Director of Packet Clearing House, the international non-governmental organization that builds and supports critical Internet infrastructure, including Internet exchange points and the core of the domain name system. Since entering the Internet industry in 1985, Bill has helped establish more than two hundred Internet exchange points; was one of the developers of the anycast routing technique that now protects the domain name system; was one of the principal drivers of California 17538.4, the world’s first anti-spam legislation; and was principal author of the Multicast DNS and Operator Requirements of Infrastructure Management Methods IETF drafts.

He co-founded INOC-DBA, the security-coordination hotline system that interconnects the network operations centers of more than three thousand ISPs around the world. And in 2007, Bill was one of the two NSP-Sec international liaisons in the Estonian CERT during the Russian cyber-attack.  Bill has been working on the IANA oversight transition issue since 2004, when he began pressuring NTIA to allow ICANN to DNSSEC-sign the root zone, and found considerable opposition for non-technical reasons.

John SweetingJohn Sweeting

Sr. Director, Network Architecture & Engineering at Time Warner Cable

John Sweeting is the Sr. Director, Network Architecture & Engineering at Time Warner Cable, working out of their Herndon, VA office.  His team is responsible for engineering of the Time Warner Cable backbone and providing standards, documentation, and guidance for the regional networks. John has over 25 years of experience in engineering networks. Previous to Time Warner Cable he worked for international carriers, MCI, Cable & Wireless and Teleglobe (Tata Communications) building out global IP networks. John previously served on the ARIN Advisory Council (AC) from 2000 – 2005. He rejoined the ARIN AC in 2008 and has served as the AC Chair for the past 3 years. He was reelected in 2011 and his current term expires 31 December 2014.

My interest in serving on the CRISP team originates from my years serving on the ARIN advisory council. I have had an interest in the management of Internet Number resources since my first involvement with ARIN over 16 years ago. I view the transition of the IANA functions oversight as it relates to this topic as a very logical and timely next step in the evolution of the Internet. My experience as a member of the advisory council, most recently as the Chair, provides me with a unique insight into working with the community to develop a solid proposal for the transition.

Michael AbejuelaMichael Abejuela

Associate General Counsel at ARIN

Michael Abejuela is ARIN’s in-house legal counsel and has been with ARIN for over four years.  He has practiced law for over ten years, and from the beginning of his legal career, has worked on various Internet law issues including CAN-SPAM Act litigation, UDRP disputes, online copyright/trademark infringement, online business consulting and contracts. Since coming to ARIN, he has counseled the organization on a variety of corporate legal matters and supported both the ARIN Board of Trustees and Advisory Council as well as ARIN executive management and staff.

I am excited to be working as the ARIN staff representative with the CRISP team on this critical issue of IANA stewardship oversight transition.  I look forward to supporting our ARIN region community representatives as we participate in the development of the IANA stewardship transition proposal from the global IP addressing community. My work with ARIN, specifically engagement with the ARIN community and our bottom up, consensus driven policy development process, has provided me with the ability to ensure the incorporation and consideration of valuable community feedback in the preparation of the transition proposal to be submitted to the ICG.


The CRISP team will be communicating via a public mailing list – ianaxfer@nro.net – Subscribe to join in the conversations about this important transition.  If you’d like to learn more about the process, the Number Resource Organization (NRO), representing the five RIRs, has more information on the CRISP Team that will be diligently working on the IANA Stewardshiptransition proposal to present to the ICG by 15 January 2015 on behalf of the numbers community.


The Sun Sets on the 2014 ITU Plenipot

Part 1 by Cathy Handley, Executive Director of Government Affairs & Public Policy, ARIN

As the sun rises in the ARIN region, the sun sets on another Plenipot…

ITU Plenipot In Busan, Republic of Korea, the main policy-making conference of International Telecommunications Union (ITU) just concluded after a long three weeks. This Plenipotentiary Conference (PP for short) is held every four years for Member States to decide on the future role of the organization.

It’s funny how things change in four short years. At this time four years ago at the ITU PP in Guadalajara the mood was far from collegial. The RIR community was in attendance physically, but not there in the eyes of many of the Member States.

This PP we were there with our friends. Yes friends. It was nice to be greeted with open arms and smiling faces. We had made it, we were recognized as members of the ITU that had a stake in the game and were included in the negotiations during the conference. That is not to say we didn’t have our differences of opinion; we did, but this time we all listened to each other and worked through the issues as colleagues not as adversaries.

Of concern to our community, I think the most significant negotiation resulted in the removal of language that suggested the ITU should look into becoming a number registry that allocates IP addresses. This discussion centered around the observation that the Regional Internet Registries (RIRs), already provide this service to the community based on an transparent bottom-up process with proven success.

ITU Plenipot

Part 2 by Einar Bohlin, Senior Policy Analyst, ARIN

I joined Cathy for the second half of the meeting, starting with an adhoc working group on Internet related issues. The adhoc’s agenda included proposed changes to three existing Resolutions:

  • 101 Internet Protocol-based networks
  • 102 ITU’s role with regard to international public policy issues pertaining to the Internet and the management of Internet resources, including domain names and addresses
  • 180 Facilitating the transition from IPv4 to IPv6

These existing Resolutions are ITU policy. As far as changes are concerned, in addition to the item Cathy mentioned above on the number registry, topics of discussion included: multilingualism and IDNs, best practice information for Internet Exchange Points (IXPs), reducing the cost of international connectivity, and the “ITU’s role in realizing Secure Information Society.” This last topic was one of a few new proposals, none of which advanced to become Resolutions.

If you attend a Plenipot, you will notice the meetings are run formally. The Chair must recognize speakers, and he controls the queue. All speakers have their own microphones with a button to push to ask to be recognized. As many speakers pointed out, the discussions took place in an atmosphere of “compromise and collaboration.” It was very interesting to see the give and take, and to see member states align and support each other.

I was intrigued by the process here. In a nutshell, proposals called Limited Distribution Documents (DLs), are discussed first in smaller adhoc groups. Proposals then go to the larger gathering of the working group (WG). When the WG finds consensus, it requests that the proposals be translated into the UN languages (this makes them Temporary Documents (DTs)). Finally, proposals are presented and approved at the full plenary. There is less discussion as proposals climb up the process. That’s how it is supposed to work, and it worked.

Plenipot attendees are a community of colleagues and friends, and I’m grateful for the warm welcome that was extended to me as a new person, by sector members and member state delegates alike. Of course this is due to the outstanding work that Cathy Handley has done making ARIN a recognized and respected sector member here at the ITU.

If you would like to watch some of the sessions from the PP, archive webcasts are available to view and documents are available to download.


8 steps to get your site ready for IPv6

Republished with permission from the Mythic Beasts blog detailing how to get 10/10 on their IPv6 domain readiness checker.

1. Add an IPv6 address to your web server

The first step is to get your web server listening on an IPv6 address, as well as an IPv4 address. How you achieve this will depend on how your web server is managed. If you’re on a shared hosting account, you’ll be dependent on your hosting provider. If you run your own server, you’ll need to obtain an IPv6 address from your hosting provider (assuming they support IPv6), configure your server to use it and then ensure that your web server (e.g. Apache is listening on this address).

2. Add an AAAA record for your website

AAAA records are the IPv6 equivalent of A records, which resolve hostnames to IP addresses.  In order for users to find your website over IPv6, you will need to add an AAAA record for www.yourdomain.com pointing to the IPv6 address configured above.  You can check that this is in place using the dig command:

$ dig +short A www.mythic-beasts.com

$ dig +short AAAA www.mythic-beasts.com

It’s possible that your existing “www” record will be a CNAME for another hostname, in which case you should add the AAAA record to that hostname, rather than the “www” record.

Our health checker will skip this test if your domain doesn’t have an A record for “www”.

3. Add an AAAA record for your bare domain

Most websites are configured to work if the user omits the “www” prefix from the name, for example http://mythic-beasts.com

In order for this to work, you will need an A record for your domain name itself, and to be IPv6-enabled, you’ll also need a corresponding AAAA record.

Once again, our checker will skip this test if the bare domain doesn’t have an A record.

4. Ensure your DNS servers have IPv6 addresses

The steps above make it possible to access your website over IPv6, but unless your DNS servers are accessible over IPv6, users (or more specifically, their DNS resolvers) will still need to use IPv4 in order to find your site in the first place. To avoid this, you need to ensure that your nameservers have IPv6 addresses.

You can find the nameservers for your domain using “whois”, and you can check whether the servers have IPv6 addresses using dig, as before:

$ whois mythic-beasts.com
[ ... ]
Name Server: NS0.BEASTS.ORG
[ ... ]
$ dig +short AAAA ns1.mythic-beasts.com

If your nameservers do not have IPv6 addresses, then unless you run your own nameservers, you’ll either need to persuade your hosting provider to enable IPv6, or switch your DNS provider to a different provider.

For a full pass, our health checker requires that at least two of your servers have IPv6 addresses.

5. Add IPv6 glue for your nameservers, if necessary

In order to find the address for your website, a DNS resolver will first need to find the address of your nameservers. If your nameservers are in your own domain, this creates a bootstrapping problem. For example, in order to find the address for ns1.mythic-beasts.com, you need to ask the nameservers for mythic-beasts.com, which includes ns1.mythic-beasts.com. The solution to this is a glue record, a record containing the address of your nameserver which is held by the nameserver for the next zone up. In this case, the next zone up is .com, so the .com nameservers would contain glue records for the ns*.mythic-beasts.com nameservers.

If a nameserver has an IPv6 address, then any glue records for it should also contain that IPv6 address.

Checking for glue records is a little bit involved. The quickest way to do it is to use “dig +trace” to find a nameserver for the next zone up:

$ dig +trace ns1.mythic-beasts.com
com.      172800  IN  NS  a.gtld-servers.net.
com.      172800  IN  NS  b.gtld-servers.net.
com.      172800  IN  NS  c.gtld-servers.net.

We can now ask any of those servers for the NS records for our domain. Any glue records that exist will be returned in the “additional” section of the response:

$ $ dig NS mythic-beasts.com @a.gtld-servers.net.
ns1.mythic-beasts.com.  172800  IN  AAAA  2600:3c00::f03c:91ff:fe96:beac
ns1.mythic-beasts.com.  172800  IN  A
ns2.mythic-beasts.com.  172800  IN  AAAA  2a00:1098:0:80:1000::10
ns2.mythic-beasts.com.  172800  IN  A

If your servers are missing glue records, you will need to get your domain registrar to add them.

It’s worth noting that even if you don’t directly require glue because your nameservers are in a different zone, at some point along the chain there will be a nameserver that does require glue.

For a full pass, our glue checker requires at least two nameservers to be discoverable by a single-stack IPv6 resolver at every step of the chain of delegation.

6. Add IPv6 addresses for your incoming mail servers

In order to receive mail over IPv6, at least some of the mail servers listed in the MX records for your domain must have IPv6 addresses. You can find the mail servers for your domain using dig:

$ dig +short MX mythic-beasts.com
10 mx1.mythic-beasts.com.
10 mx2.mythic-beasts.com.

You can then check that these servers have IPv6 address by using dig to resolve an AAAA record, as before.

In order to pass this test, at least one of the servers listed in your MX records must have an IPv6 address.

7. Add reverse DNS for your mail servers’ IPv6 address

It is generally advisable to have working reverse DNS for any addresses from which you send outgoing mail. In the case of IPv6, this becomes pretty much essential, as one of the biggest mail providers in the world, Google, will reject mail over IPv6 unless the sending server has working reverse DNS for its IPv6 address.

Unless you run your own mail servers, adding support for IPv6 will be down to your mail provider.

Unfortunately, there is no reliable way to obtain the outgoing mail servers that are used for a particular domain, so instead our health check makes a bold assumption that your outgoing servers are the same as the incoming servers listed in your MX records, and checks those. This assumption is certainly not true of all domains, which is why a failure of this test is only treated as a warning.

8. Check your SPF records

SPF (Sender Policy Framework) is a mechanism for publicly listing your outgoing mail servers, so that receivers can detect spoofed email sent from other servers. If you enable your outgoing mail servers to start sending mail over IPv6, and you have an existing SPF record, it is important that you make sure that it includes the IPv6 addresses for your mailservers.

There are various ways of doing this. If your incoming and outgoing mail servers are the same, then you can use the “mx” mechanism in your SPF record. This means that any hosts listed in the MX records for your domains will be regarded as a legitimate source of mail for your domain, and this will automatically include any IPv6 addresses (assuming you’ve done step 6).

If you list IPv4 addresses or address ranges in your SPF record explicitly, then you will need to add corresponding IPv6 addresses for those servers.

The rules applied by our health checker aren’t entirely trivial, as it’s not uncommon for legitimate third party servers to be included in a domain’s SPF record, and there’s no way of pairing up IPv6 addresses with their IPv4 counter parts. Our health checker applies some very broad rules: if you use the “mx” mechanism, then the checker requires at least one IPv6 address for a server listed in the relevant MX records. If there are any explicit “ip4″ addresses or ranges specified in the record, then the health checker expects to find at least one explicit “ip6″ mechanism.

If your domain does not list an SPF record then this test will pass automatically, as this effectively defaults to “accept from all”.

These rules aren’t watertight, but have proven to be quite effective in identifying mail sources that either haven’t been enabled by IPv6, or which have but haven’t been added to the SPF record.