We’re gearing up for fall and it promises to be a busy one! In this edition of ARIN Bits, you’ll learn about ARIN 44 in Austin, ARIN Elections, the first ARIN Community Grant recipients, our upcoming outreach events, our latest Internet Governance efforts, and more. If you missed any previous editions of Bits and want to catch up, you can find them on our ARIN Bits archive page.
We want to see YOU at ARIN 44 in Austin!
ARIN 44 is fast approaching! We hope to see you in Austin,
Texas from 31 October – 1 November at the JW Marriott Austin, directly
following NANOG 77 in the same location. This will be a great opportunity to
engage in policy discussions, network with colleagues, learn more about ARIN
services and operations, and attend workshops and tutorials.
If you can’t join us in Austin, remote participation is always
an option and can be equally rewarding! In an effort to create a truly open
community forum, ARIN provides meeting materials, live transcripts, and
webcasts so you can be part of the action, wherever you are. Remote attendees
will also have access to a live chat as well as voting options to make sure
your voice is heard. It’s the next best thing if you can’t be there in person.
Be sure to join in for the policy discussions and also for candidate speeches
on Thursday afternoon.
Ready to start planning for ARIN 44? Check out these links:
- View the agenda for ARIN 44
- Register for ARIN 44 as an onsite or remote participant
- Register and learn more about NANOG 77
Vote in ARIN Elections Beginning 31 October
2019 ARIN Elections will be here before you know it, so make
sure you’re prepared to vote and help shape the future of the Internet.
Elections for two seats on the ARIN Board of Trustees, five
seats on the ARIN Advisory Council, and one seat on the Number Resource
Organization Number Council (NRO NC) will be held online 31 October – 8
Only ARIN Member organizations in good standing 45 days
before the election and with a designated Voting Contact on record may vote in Board
of Trustees and Advisory Council elections. ARIN member organizations in good
standing with designated voting contacts, ARIN 44 attendees, and NANOG 77 attendees
may vote in NRO NC elections.
Before you can vote, make sure you’re eligible by 16 September! Organizations can verify their Voting Contact by logging in to their ARIN Online account or by emailing email@example.com.
When it comes time to vote, eligible Voting Contacts from
General Members in Good Standing should log in to ARIN Online and look for the
“Vote Now” message on the dashboard. Additionally, all NANOG 77 and
ARIN 44 meeting attendees registered for these meetings by 24 October (and who
are not ARIN Voting Contacts) will be sent an email on 28 October with a link
to vote in the NRO Number Council election.
Congratulations to the first ARIN Community Grant recipients!
The ARIN Community Grant Program provides financial grants in support of initiatives that improve the overall Internet industry and Internet user environment. In its inaugural year, the ARIN Grant Selection Committee selected four projects to receive funding, and the ARIN Board of Trustees approved the selections.
The 2019 grants were awarded to:
DNS Open-Source Tools Enhancement & Maintenance
- Indianapolis, IN, USA
- Grant amount: $7,500
IPv6 Training for
- Industry Network Technology Council
- Fairfax, VA, USA
- Grant amount: $20,000
CrypTech Open Source
- CrypTech/Stichting NLnet
- Amsterdam, The Netherlands
- Grant amount: $10,000
Global NOG Alliance
- Global NOG Alliance
- Apeldoorn, The Netherlands
- Grant amount: $7,000
More information about each of these projects, including application statistics, is available on our website.
Thank you to everyone who applied for a grant this year.
Applications will be accepted for next year’s program beginning in March 2020.
Upcoming Outreach Events in Des Moines, Brooklyn, and Wilmington
ARIN hosts a variety of outreach events to create
opportunities for customers and the community to learn more about how they can
maximize the value of their ARIN experience. These events are designed to help
potential, new, and existing customers understand all of the services that ARIN
provides in support of our community.
Registration is now open for three upcoming outreach events!
ARIN on the Road
ARIN on the Road is your chance to get face-time with ARIN
and get your questions answered. These traveling, no-cost events provide the
latest from ARIN on everything from technical services and tools, to current
ARIN policy developments and the status of IPv6 adoption. An onsite help desk
will also be available.
Join us at the Embassy Suites Des Moines Downtown on Thursday, 19 September for ARIN on the Road: Des Moines.
ARIN Lunch by the
These lunches are tailored to ARIN customer organizations
that may not have much visibility into the inner workings of ARIN. During
lunch, ARIN staff will present an overview of current ARIN activities and
services. Afterward, there will be plenty of time for questions and for you to
provide us with feedback. An onsite help desk will also be available.
Join us in Brooklyn, New York and Wilmington, Delaware on 1 and 2 October, respectively, for ARIN Lunch by the Numbers: Brooklyn and ARIN Lunch by the Numbers: Wilmington.
ARIN to Delete “Orphaned” Point of Contact and Organization Records
ARIN is moving forward with our plan to delete from the ARIN
registry all Organizations (Orgs) and Points of Contact (POCs) that have been
“orphaned” for two or more years. This project will fulfill two major
obligations: to improve the accuracy and integrity of the registry data and to
ensure that we are not retaining any data that is not necessary for ARIN
We incorporated many of the suggestions received from the August 2018 community consultation into the implementation plan. Much of the feedback received was already part of our existing criteria, but the following community suggestions have been integrated into the revised plan:
- Incorporate the deletion of orphaned POCs into
the POC validation process.
- Notify orphaned POCs in advance of their
- Archive all deleted POC and Organization data
for possible recovery if needed.
Our 30 July announcement contains more details about this project.
NRPM 2019.2 – New Policies Implemented
On 20 June 2019, the Board of Trustees adopted the following
Recommended Draft Policies and editorial changes:
- ARIN-2018-2: Clarification to ISP Initial Allocation
- ARIN-edit-2019-1: Remove IPv4 Reference in NRPM Section 6.10.1
- Recommended Draft Policy ARIN-2019-16: Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet Requests
Version 2019.2 of the ARIN Number Resource Policy Manual (NRPM) was published on 10 July 2019, and these policies went into effect on that date.
Current policy proposals under discussion include:
Recommended Draft Policies:
- ARIN-2018-6: Clarify Reassignment Requirements in 220.127.116.11.1
- ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
- ARIN-2019-3: Update 4.10 – IPv6 Deployment Block
- ARIN-2019-8: Clarification of Section 4.10 for Multiple Discrete Networks
- ARIN-2019-15: Hijacking Authorization Not-intended
- ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers
- ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 Transition Space Requests and NRPM 18.104.22.168 Unmet Needs Requests
- ARIN-2019-10: Inter-RIR M&A
- ARIN-2019-11: M&A Regional Nexus Exclusion
- ARIN-2019-12: M&A Legal Jurisdiction Exclusion
- ARIN-2019-13: ARIN Membership Legal Jurisdiction Exclusion
- ARIN-2019-17: Returned Addresses to the 4.10 Reserved Pool
You can find the status of current policy discussions on our website and subscribe to ARIN-PPML (Public Policy Mailing List) to voice your opinions. And remember, membership is not required to participate!
In July, we added some new features to ARIN Online:
Added functionality to allow inter-regional transfers of Autonomous System Numbers (ASNs) per policy ARIN-2018-1, implemented 7 March 2019. Inter-regional ASN transfers are now included in the Specified Transfers of Internet Number Resources page.
Added search functionality on the Route Origin
Authorizations (ROAs) page for Resource Public Key Infrastructure (RPKI). You
can now search for ROAs by entering the Origin Autonomous System (AS) or prefix
of the ROA. (ACSP 2019.11)
Created two new Point of Contact (POC) types for
organizations: Routing POCs and Domain Name System (DNS) POCs. The Routing POC
is responsible for routing registry and RPKI certification information for the
organization. The DNS POC is responsible for reverse DNS and secure DNS information
for the organization. (ACSP 2018.15)
ARIN and Internet Governance
ARIN is a well-respected leader in the Internet community and likewise a thought leader in Internet governance discussion. Looking toward the future of the Internet, ARIN continues to be a valuable resource for the Internet community by participating in Internet governance to:
- Make sure the interests of the Internet
community are represented in key forums
- Educate governments and international
organizations on the Regional Internet Registry (RIR) structure and bottom-up
community driven number resource management model
- Work within various organizations to remove
barriers that result in misunderstanding
- Facilitate opportunities to exchange meaningful
insight that will impact Internet number resource distribution and management
not only today but in the future as well.
Curious to see what we’ve been up to lately when it comes to Internet Governance? Check out TeamARIN for our latest blogs about what ARIN is currently doing in this space.
Looking for a job in the Washington, DC area? Consider a career at ARIN!
You’re already interested in
the goings-on at ARIN (otherwise, you wouldn’t be reading this newsletter!), so
why not take your involvement one step further and consider joining our team?
ARIN is now hiring for three positions at our headquarters in the DC Metro
We are currently seeking a Software Development Engineer, Financial Customer Service Representative, and a Customer Service Resource Analyst for our Registration Services Department. Take a look at the job descriptions and if any position sounds like a good fit for you, send us your resume. We’d love to talk to you!
What’s it like to work at ARIN? For starters, we offer competitive salaries, comprehensive benefits, training, and education. In lieu of stock options (we are a non-profit, membership association), we have a generous 401(k) retirement plan. Eligible employees received a 14% fully-vested employer match in 2013 through 2018. And last but not least, in 2017, ARIN was named a Top Workplace by the Washington Post.
ARIN Welcomes New CFO
We are pleased to announce that Chris Casselman joined the
ARIN team as our Chief Financial Officer (CFO) effective 31 July 2019.
Chris is a Certified Public Accountant (CPA) who brings a
wide variety of financial experience to his new role at ARIN. He has provided
financial and audit leadership to a variety of science and technology companies
throughout his career, including most recently serving as CFO for a
Please join us in welcoming Chris to ARIN!
Our Featured Policy Requirement:
ARIN Waitlist (NRPM 4.1.8)
After review by the ARIN community, the ARIN Advisory
Council, and the ARIN Board of Trustees, some changes to waitlist policy were
adopted and implemented. The two main changes were:
- Only organizations holding a /20 or less of IPv4
address space may apply and be approved.
- The maximum size aggregate that an organization
may qualify for at any one time is a /22.
In other words, only organizations holding direct registrations
in aggregate of /20 or less may apply and be approved for placement onto the
waitlist. In order to qualify for placement, ARIN staff will need to review the
organization’s demonstrated two-year utilization with a limit of /22.
Organizations will be able to elect a smaller block size than they qualify for
down to a /24.
A Tip from Our Registration Services Department:
With the changes made to waitlist policy, the suspension of
the waitlist has been repealed and organizations have been receiving IPv4
addresses off the waitlist. Your organization may want to consider applying for
placement onto the waiting list as a means to obtain IPv4 addresses to meet
your organization’s IPv4 needs. Here are some interesting statistics that might
help you determine if the waitlist looks like a reasonable option for your
- Number of requests on the Waitlist at the time
the suspension was enacted -> 247
- Number of requests on the Waitlist at the time
the suspension was repealed -> 340
- Number of requests added to the Waitlist since
suspension was repealed -> 48
- Number of filled since the Waitlist suspension
was repealed -> 287
Visit our website to learn more about the IPv4 Waitlist.
Check out these customer and member statistics (as of 31 August 2019):
- 38,422 total customer organizations, including
6,157 member organizations
- 605 8.3 Transfers and 91 8.4 Transfers completed
- 8.4 Transfers completed YTD 2019: 27 to APNIC, 42
to RIPE NCC, 11 from APNIC, 11 from RIPE NCC
- 59.3% of members have an IPv6 block
Recent TeamARIN blogs include information about how ARIN deals with orphaned records, how we use your feedback to shape our services, some new POCs on the block, and more.
Don’t forget to check out some other blogs you may have missed over the past few months!
See you in December!
We’ll see you next quarter as we wrap up 2019.
The post ARIN Bits: September 2019 appeared first on Team ARIN.
This year we kicked off the ARIN Community Grant Program that is designed to provide financial grants in support of initiatives that improve the overall Internet industry and Internet user environment and benefit the Internet community within the ARIN service region. In the very first year of the program we were pleased to receive 23 applications for funding which, in total, amounted to more than $350,000 in requests. Thank you to everyone who took the time to apply. After careful deliberation, the Grant Selection Committee and Board of Trustees selected four projects to receive funding.
In their own words, here are quick summaries of what each of these
projects seek to accomplish.
DNS-OARC | Indianapolis, IN, USA | Grant amount: $7,500
Internet operations and infrastructure critically depend upon the DNS. While there are many vendor solutions available for implementing DNS service, the gathering, measurement, testing and debugging of DNS traffic, protocol features and vulnerabilities are no less critical a part of this. Part of DNS-OARC’s public benefit mission is to develop publicly available tools and services that support these capabilities, and these are widely used by the DNS and operator communities. Our open-source tools including; dsc (dns stats collector), dnsjit (captures and replays DNS), dnscap (network capture utility), dnsperf (performance testing), and drool (replays DNS), (and others). These need constant maintenance and improvements. The use of these open-source tools is free, and as a 501(c3) nonprofit, OARC seeks to fund development and hardware costs to support this public benefit work.
Many of these tools have been developed in-house over time by OARC and its contributors. Others have been developed externally, and either donated to OARC by the original owner, or in some cases OARC has taken custodianship for the community of DNS tools which have become ‘orphaned’ from their original developers.
Industry Network Technology Council | Fairfax, VA, USA | Grant amount: $20,000
IPv6 adoption has lagged. One of the issues is that enterprise technicians don’t
know how IPv6 works. The technicians want to get trained yet the management
does not feel that they do not want to pay for such training because they do
not see a business need for adoption.
creates an unfortunate cycle where misinformation about the complexity of the
IPv6 protocol and unreasonable fears about security and manageability combine
with the perceived lack of urgent business needs to prevent adoption of IPv6.
We have a
multi-pronged strategy. We can provide technical training on many of the core
features of IPv6. We plan a series of webinars this year. We presented one such
webinar last year which was attended by over 120 people from over 70 separate
enterprises including outsourcing companies, “brick-and-mortar”
Fortune 500 type enterprises, small independent software companies and
CrypTech/Stitching NLnet | Amsterdam, The Netherlands | Grant amount: $10,000
Working since 2014 the CrypTech project has developed an open-source hardware cryptographic engine design to meet the needs of high assurance Internet infrastructure systems that use cryptography. Our open-source hardware designs are aimed to be of general use to the broad Internet community, covering needs such as securing email, web, DNSSEC, PKIs, etc. The project has produced a design and hardware boards that have been used in various experiments and test, and now an external product. We are proud to say that the current design has been the subject of a positive external security evaluation. The CrypTech core team are now beginning the process of designing next generation designs and ARIN community funding can help enable this process.
Global NOG Alliance | Apeldoorn, The Netherlands | Grant amount: $7,000
NOG Alliance (GNA) is a non-profit foundation which has been set up to help
Network Operator Groups and technical communities all around the world. We help
NOGs by providing logistical support for their events and membership
administration, thereby freeing up NOG organizers to focus on their core
functions of growing and improving knowledge and expertise in their
initial services to NOGs include providing technical support and hosting their
websites, mailing lists, mailboxes, call-for-papers and event management tools.
Now, while there are many open source tools capable of providing piecemeal
solutions, there is nothing readily available that does exactly what NOGs need
to free them from their administrative burdens.
project therefore is to integrate existing open source solutions into a
cohesive, easy-to-use system providing single-sign-on access to a wide range of
useful event planning and membership administration tools. As open source
advocates, we would also contribute to existing open source projects to improve
their value for NOGs. Where existing tools do not exist or where integration
between tools is not yet available we are looking to develop those parts, and of
course release them as open source.
Congratulations to these first ARIN community grant recipients!
We are excited to support these projects as they aim to improve to
the health and well-being of the Internet and make a positive contribution to
the ARIN community.
Stay tuned for next year’s program
We will begin accepting applications for next year’s program in the spring of 2020. Information about the program will be posted to our ARIN Community Grant Program page, and we will send out an email via arin-announce once the application period opens.
The post Granted – Empowering Projects to Improve the Internet appeared first on Team ARIN.
The post Granted – Empowering Projects to Improve the Internet appeared first on Website Hosting Review.
We recently received a question about whether it’s possible
to check to see if your Point of Contact (POC) or Organization Identification
(Org ID) has been orphaned, and we thought it might be helpful to share some
additional information on this topic with the community.
What is an Orphaned POC or Org ID, and how does it all work?
In general, a POC and Org ID are considered “orphaned” if
they have not been associated with an Autonomous System Number or IP address
(collectively referred to as Internet number resources) for a consecutive
two-year period. The procedure will involve deleting identified orphaned,
unvalidated POCs and Orgs after a two-year period of inactivity from the public
Whois. A notification will be sent to
the POC 60 days in advance of the actual deletion. Because it may not be a
straight forward process to determine orphaned status, we would like to provide
some information that may assist you.
Your POC is not Orphaned if…
- … your POC is associated with an Org ID that has Internet number resources, either directly registered or reassigned from an upstream provider, then neither the POC nor the Org ID would be considered “orphaned”.
- … your POC is not associated with any Internet number resources, but has been validated in accordance with section 3.6. Annual Validation of ARIN’s Public Whois Point of Contact Data of the “Number Resource Policy Manual”, then the POC would not be considered “orphaned” either.
How can I check my status?
If you would like to use ARIN’s Whois to determine whether your POC or Org ID is orphaned (has no associated number resources), go to whois.arin.net and enter either your POC handle or your Org ID in the search button at the top right. Located within the Whois results are links that will take you to any related organizations, POCs, networks or autonomous system numbers. Keep in mind that while Whois will tell you whether a POC or Org has any related number resources, it will not reveal how long a POC or Org has been orphaned. More detailed instructions for using Whois can be found on our website.
Alternatively, if you would like to use ARIN Online to determine
whether your POC or Org ID is orphaned, you can log in to your ARIN Online
account to view your POCs and Org IDs right on your dashboard. For more help
getting started using ARIN Online, you can visit our Account Management
page on our website.
We’ve got your back
Please keep in mind, if a POC or an Org ID you were using happens to be considered “orphaned” and is removed from ARIN’s Whois you may simply request a new POC and/or Org ID. We will gladly create new POCs and Org IDs at your request when they are needed for conducting transactions with ARIN.
As always, we’re here to help. If you have any questions or
need further assistance, you can reach the Registration Services team by calling 703.227.0660 or
submitting an Ask ARIN ticket from within your ARIN Online account.
The post What is an Orphaned POC or Org ID and How Do I Know If I Have One? appeared first on Team ARIN.
The post What is an Orphaned POC or Org ID and How Do I Know If I Have One? appeared first on Website Hosting Review.
It’s no secret that we truly value customer feedback here at ARIN. It’s always been a
key part of our decision making process, and it helps us know that we are providing
the exceptional service our customers deserve. We have many ways of collecting
feedback from you, our community, including the ARIN Consultation and Suggestion
Process (ACSP), the Feedback Button on our website, Customer Surveys, Ask ARIN
Tickets, social media, telephone calls and more.
As part of each resource request ARIN receives from our customers, we provide
a link to a survey that allows real time feedback to be provided for that
transaction. This Transaction Survey specifically allows you to provide us information
on timeliness, courtesy, overall satisfaction and other bits of information
that can be used to improve our process and services. We review and dicuss
these surveys with the team to help us improve the process. We encourage you to
fill out the information requested on the survey, especially if there is
something you would like us to know about your experience with ARIN.
How do we use your feedback?
We use the information in several ways, such as making
changes to the overall workflow, the user interface of ARIN Online, training of
our customer service analysts, and improving the quality of service you
receive. The information is shared with everyone in the department weekly
during staff meetings to discuss how to make improvements. It is also used to
highlight exceptional service that was provided by team members. We share the
information with other departments so that they may also make improvements to
their processes if required. This information is shared with the executive team
and the Board of Trustees as well.
So, how are we doing?
Based on your feedback, I’d say we’re doing pretty well! Since our survey began in 2014, 81% of our customers (465
responses) said that they are either “extremely satisfied” or “satisfied” with
their user experience during a transaction request. Over the last 2 ½ years,
91% of customers responding (226) have been “extremely satisfied” or
“satisfied” with their experience.
A few comments we’ve received include:
- “The ARIN team was extremely patient and helpful in
guiding me through this transfer process after our company’s name change.”
organization always wows me with your professionalism and efficiency.”
- “ARIN has
some of the friendliest people when it comes to working with customer support.”
But we know there is always room for improvement. We’ve
received additional feedback from some customers with suggestions, including:
- “ARIN’s request process is a bit
convoluted, and instructions are not always easy. I think some documentation
with screenshots would be very helpful, in general, when trying to issue
instructions on how to get things done.”
a first timer it would have been advantageous to have a step-by-step guide to
the process of pre-approval. Is there one available?”
Based off of this feedback, we have implemented several tools to guide our customers through the process. These include tools such as our ARIN Online “How-To” videos, simplified and concise language throughout our website, and a quick guide to requesting resources. We’ve also received feedback from other customers indicating they were unsure how to proceed with a Pre-Approval or a Specified Recipient Transfer while others felt that the entire review process could be shortened if they had an idea of what information was going to be needed up-front. Armed with this feedback, we set out to provide an IPv4 Transfers flowchart to give a visual of the Pre-Approval and Specified Transfer process and requirements. We’ve also worked with our staff to enhance their first correspondence to each resource request to include as much information, and ask for all the items needed to begin reviewing each request.
We strongly encourage you to take a few moments to fill
out our Transaction Survey the next time you make an Internet number resource
request. As you can tell, we take the time to read each response very carefully
and use these surveys to continue improving our services, processes and
procedures. If you have any questions, don’t hesitate to contact the
Registrations Services team
by calling 703.227.0660 or submitting
an Ask ARIN ticket from within your ARIN Online account.
The post Sharing Your Experience with our Registration Services Team appeared first on Team ARIN.
The post Sharing Your Experience with our Registration Services Team appeared first on Website Hosting Review.
You’ve Got the Right Stuff
of you may already know that we have a suggestion process in place for our
community members to submit their thoughts and ideas for how we can better
serve you. We always take the time to review these suggestions, and sometimes
implement your ideas!
We recently received two separate suggestions from different ARIN community members asking us to add two new types of optional Points of Contact (POCs) to our public WHOIS database – one for routing purposes and one for DNS purposes. We thought this was a great idea, so we took this feedback and created these two new POCs.
The Routing POC will be responsible for Internet Routing Registry (IRR) maintenance and Resource Public Key Infrastructure (RPKI Certification), and the DNS POC will be responsible for updating reverse DNS delegations (in-addr arpa and ip6.arpa) and DNSSEC (Delegation Signer Records or DS Records). The addition of these two new POC types were part of the initial development of ARIN’s new IRR. You can find discussion points regarding the IRR update by Richard Jimmerson and John Sweeting at ARIN 43 in Barbados.
POC by POC
You may ask,
why do we need all of these different types of POC functions, and what does
The need for different types of POC Records really boils down to
security and POC responsibilities/functions. POC records are standalone objects
that detail a person or role and provide their contact information. The POC
function is defined by how it is added to an Organization Identifier (Org ID)
or to Internet number resources (IP addresses and Autonomous System Numbers) registered
under the Org ID.
Admin POC – The Administrative (Admin) POC is a mandatory POC for an Org ID. This
POC has full administrative rights over the Org ID and its corresponding Internet
number resources. The Admin POC is permitted to manage and update the Org ID;
manage, update and request resources; request transfers; as well as manage
reverse delegations, DNSSEC, RPKI, and many other functions. There can be only
one Admin POC for an Org ID.
Tech POC – The Technical POC (Tech POC) is also a mandatory POC for an Org ID
and has the same administrative rights as the Admin POC. An Org ID can have
multiple Tech POCs.
Abuse POC – The Abuse POC is a mandatory POC for an Org ID and acts as a
contact for reporting and resolution of network abuse issues. Multiple Abuse
POCs may be specified per organization. This type of POC is not permitted to
make any database changes.
NOC POC – The Network Operation Center (NOC) POC is an optional POC and
serves as a contact for network operation issues. There can be multiple NOC
POCs for an Org ID.
Resource Tech POC – The Resource Tech POC is an optional POC for an Org ID and has authority
over specified Internet number resources.
The Resource Tech POC can change the attributes of a resource, such as
the resource name and the public comments displayed in ARIN’s Whois database,
and can also specify nameservers or DS Records.
An Internet number resource can have multiple Resources Tech POCs.
Resource Abuse POC – The Resource Abuse POC is an optional POC that acts as a contact
for the reporting and resolution of network abuse issues regarding a specific Internet
number resource. An Internet number resource can have multiple Resource Abuse
NOC POC – The Network Operation Center (NOC) POC is an optional POC and serves
as a contact for network operation issues. There can be multiple NOC POCs for
an Org ID.
Resource NOC POC – The Resource NOC POC is an optional POC that serves as a contact
for network operation issues for specific Internet number resources. An Internet number resource can have multiple
Resource NOC POCs.
what will the new POC functions do, and how are they helpful?
Routing POC – The Routing POC is an optional POC and will have the ability to create, edit, and delete routing objects within ARIN’s IRR and maintain and implement RPKI. There can be multiple Routing POCs for an Org ID.
DNS POC – The DNS POC is an optional POC and will manage and update Reverse DNS Delegations and Domain Name Systems Security. There can be multiple DNS POCs for an Org ID.
The addition of the Routing and DNS POCs will allow organizations to further detail and delegate authority for specific POC functions to the appropriate people within their organizations. This enhances their security and enables network operators to have more specified access to the individuals responsible for these functions.
continue to improve the community’s ARIN Online experience, and are most
welcomed. Submit a suggestion by logging into ARIN Online and going to the top navigation
bar under “Policy & Participation”, from the drop-down menu you will see “Community
Interaction”, then select “Consultations & Suggestions” and your suggestion
may shape ARIN Online in the near future.
The post New POCs on the Block appeared first on Team ARIN.
SolarNetOne IPv6 Case Study
I am continually impressed by the adaptability of the Internet’s underlying structure. It can bring so many disparate groups with different interests and goals to work together toward the common aim of making our systems interoperate correctly. The network’s response to the challenges of IPv4 depletion by producing IPv6 is a great example of that process. As the founder of SolarNetOne, we have made every service on every host on every public facing network IPv6-enabled. All of our websites have been dual-stacked since it has been possible to do so, you can query our name servers via IPv6, and our mail exchanges all send and accept mail over IPv6.
The early days
SolarNetOne is a small research and development organization that focuses on improving the efficiency of network equipment and power systems, although our efforts at times become more wide reaching, including the development of a solar flare prediction system, advanced renewable/grid interconnection systems, and low power single layer graphene exfoliation.
We primarily provide off-grid networks in areas that are difficult to bring Internet to in the remote Pacific islands and elsewhere. We worked with the Solar Electric Light Fund, the Network Startup Resource Center, and Dr. Vint Cerf to get started, without any of whom we would not have had the opportunity to make the progress that we have. I had been interested in the core network protocols since 1998 when I started studying them and getting involved in the Internet Engineering Task Force (IETF). When IPv6 started to roll out through the working groups, I took notice and signed up for an original 6bone 3ffe:: address allocation, so I could help test it out. We weren’t using “real” routers, just commodity Linux boxes at the time, and we had to hand-write all of routing tables into the kernel without any available routing daemons. It was an interesting time where we got some early hands-on experience with IPv6 to understand what it can and can’t do.
When we rolled out IPv6 with real addresses years later, I used a cookie cutter replica of what we had done with the 6bone. Initially, there were some technical obstacles like the code not being ready yet on the client daemons. For example, the router advertisement daemon was kind of buggy and there were some bugs in the kernel stack when we first rolled it out back in 2003, but those things were resolved quickly, and we’ve had a very stable system after that, once the testing network was sunset and the production network was lit up.
My small-scale IPv6 deployment has happened via tunnels throughout the history of building out the SolarNetOne network. After 6bone shut down, we began tunneling through the Internet Systems Consortium (ISC), and then we needed more varied address space to do some research, so we tunneled to XS4All. When that closed down, we moved that tunnel over to Hurricane Electric. In each of these cases, our address space came from the operator of the remote tunnel endpoint. With the completion my routing infrastructure build, I am now announcing the address block we were allocated by ARIN this year without needing to get the addresses from anyone else, still via tunnels until direct peering opportunities present themselves.
From tunnels to my own allocation
Whereas previously we only had /48s through tunnels, we got a /36 IPv6 allocation from ARIN. To begin with, I had to fundamentally educate myself in BGP. I’ve also had some problems with the business class carrier upstream from me that has necessitated putting some hosts off site and making IPSEC tunnels between here and there to secure the BGP connections, to ensure no corruption of the routing data.
We have PoPs in Miami and Las Vegas connected via discrete routes coming from Daytona Beach, Florida. The peers that we have on the remote end allow us to originate the IPv4 addresses. We are announcing the IPv6 addresses through tunnel drops to New York and Miami. Once our IPv4 routes were being propagated globally, I renumbered our networks with both protocol stacks. I preferred to do it in one shot rather than once for each protocol, since we were already logging into each host to edit the configurations.
It is interesting to have a little more granularity with a real routing daemon rather than the advertisement daemon we’ve been using all these years. In the past I used Router Advertisement Daemon (radvd) on Linux hosts to do stateless auto-config and allocated routes and IP addresses to clients based on their MAC addresses. I would set up a tunnel endpoint where a /48 was routed to my host with multiple network interfaces and then route the packets out on the /64 subnets to the various hosts needing IPv6 connectivity.
The primary reason why I’ve gone through the learning curve from BGP to IPSEC to making sure everything is well-secured is because when we got hit by hurricanes Matthew and Irma, our IPv6 network would go down since our tunnel was end-pointed from one circuit only, in the old configuration. I had redundant circuits, but the packets wouldn’t re-route automatically without BGP and RIR-allocated addresses. If I wanted to bring it back up in the middle of a hurricane, I would have to re-home the tunnel, renumber all the hosts respecting IPv4. This generally was a lot of work to go through to temporarily restore connectivity, which would then have to be manually undone upon restoration of normal conditions. Now, in the event that one or two of our upstream circuits go down, the packets still get routed, and my rack housing the DNS, web, and mail servers are still reachable. In the past, it has been debilitating not to have the full strength of my network to use in situations when we need it the most. With the expansion into an Autonomous System with its own IPv4 and IPv6 assets, this reconfiguration happens automatically, on the fly, leaving me to attend to handling other aspects of the storm response, confident in the knowledge that my network will remain as fully functional as the off-grid solar power system that keeps the uptime at 5’9s.
Move your truck
Neither of my upstream circuits “have the ability” to route IPv6. I understand they want to leverage their investment in their IPv4 infrastructure for as long as possible, but it’s holding back progress. I would like to go IPv6 only, but I have to dual stack or half of my user base couldn’t find me. In the rural, less connected areas of America, it can be a hard sell to get edge carriers to support IPv6 on their networks. In the greater Daytona Beach area, I would think that I could get native IPv6 from any ISP, yet I’ve gotten responses saying that they “don’t support IPv6 over the Layer 1 that we provide you”. To get IPv6, I would have to pay four times more and do a fiber build in order for them to route IPv6 for me.
In response, I stuck with tunnels to route those packets, but that increases latency thereby reduces performance. The way I explained it to the salesmen from the carrier that “could not” support IPv6 (or BGP sessions) was this: “Your house is burning down and the flames from your house have started to come over to my house, too. Your truck is parked in front of fire hydrant. Can you please move your truck so I can hook up the hose and save both our houses? There is a problem that needs to be solved, and you are standing in the way.” I put the onus on the last mile carriers to get their act together. Get with the times, and deploy IPv6 so we aren’t left behind from the rest of the world, who is actively doing so.
Pros of deploying IPv6
Given the potential of IPv6 and the cost of IPv4, I just decided to do it and had it running in only a few extra late nights. A few more late nights gave time to maintain and expand as things grew. Since deploying IPv6, we have seen an increase in the flexibility of what we can do with our networks, without the added costs the monetization of IPv4 has brought. In the market I’m in, a /28 costs about $80/month, so to have a large number of addresses to experiment with is an expensive proposition. It is a notably less expensive proposition to deploy IPv6 than IPv4 via BGP as well, unless you are already well seated on the backbone. For the small business looking for redundant multi-homing, it is a far less costly and time-consuming option than deploying IPv4 on the network edge.
A large portion of IPv6 traffic to e-commerce hosts on our rack comes from mobile customers. More often than not, mobile customers come in over IPv6, showing the mobile carriers are doing a reasonably good job of rolling out IPv6. Indeed, the only IPv6 address assigned here that was not of my doing is on the mobile I carry every day.
Anybody deploying IoT devices is going to run into an addressing problem or a Network Address Translation (NAT) problem. When it comes to deploying a wide range of sensors or home-connected devices, IPv6 solves the shortage issue, particularly with 6LoWPAN, a protocol designed specifically to employ IPv6 to improve the capabilities of IoT networks. I think we are going to get to the point where you can’t leverage all of the services your device offers if it doesn’t have its own unique identifier very soon. If IoT devices are sitting behind a NAT, you are going to have to do some nasty tunneling to get them to function, whereas they will work natively with IPv6, more so as time progresses.
Crawl before you walk
My advice is to start small, make a tunnel, learn how the network works, and learn how to secure it. Since IPv6 is a whole new protocol stack, you need to learn what you need to do in terms of firewalling so you can protect your assets. This all can be done for free; for nothing more than the cost of your manpower. Once you are comfortable with the protocol, get your address allocation, and route your packets. If you are already routing packets for IPv4, it’s really very simple on almost all modern routers to enable the dual stack function. If you don’t want to do that (or if you have a problem doing that on a license level or at some additional cost), you can leverage Multiprotocol Label Switching (MPLS) to move IPv6 over your existing IPv4 routing infrastructure. Start small with a test host, put a couple network interfaces in it, route some IPv6, and see what it looks like. Crawl before you walk, and deploying IPv6 will seem a lot less daunting.
The post Testament to the Adaptability of the Internet appeared first on Team ARIN.
You may have heard during our past few Public Policy and Members Meetings that we’ve been working on moving towards a “stateless architecture.” If you’re in the dark about what this means for ARIN Online as well as future downtime and upgrades, read on for a quick Q&A with Andy Newton, our Chief Engineer.
1. Can you explain what stateless architecture means in terms of ARIN’s systems?
This refers to ARIN Online and how it tracks users who are logged in to ARIN Online. Our previous architecture was “stateful,” meaning each user was tracked by mapping an identifier in the user’s browser with data in the memory of the ARIN Online servers. For every user actively using ARIN Online, the servers would consume memory when keeping the session state of their activities.
Stateless means that the servers no longer keep track of each active user. Instead, the “state” of the activity of the user stays in the user’s web browser.
2. What benefits will users see in their day-to-day operations?
The biggest benefit to our users will be a greatly increased “session” timeout. In the past, users would lose their session after two hours of inactivity. With our new stateless architecture, the session is held in the user’s browser and is therefore not limited by the memory in ARIN Online’s servers. Now sessions will last several days, limited only as a security precaution.
3. Will the new stateless architecture decrease the frequency or the length of time when the system is down for maintenance?
Downtime to fix bugs or add new features to ARIN Online will be very rare in the future. Historically, bug fixes and feature additions have been the primary causes of outages as we upgrade ARIN Online.
However, there will be outages in the future unrelated to ARIN Online itself, such as upgrades to ARIN’s registry database or network changes. But these types of outages will occur at less frequent intervals as we move forward. Right now, ARIN does have a few of these types of outages planned for the off-hours during 2019, as we have a number of core changes to implement.
4. What types of service disruptions might users still expect, and what features will be available or unavailable during these disruptions?
In general, outages to ARIN Online do not impact DNS, RDAP, Whois, or RPKI Repository service availability, nor do they require an outage to the “static” content on www.arin.net or our search facility at search.arin.net.
5. Going forward, what are your plans for ARIN’s architecture?
Achieving stateless architecture with ARIN Online will allow us to start the process of breaking up our systems into smaller, more manageable components. Currently, ARIN Online and its associated systems have what is known as a “monolithic” architecture, and upgrading large systems usually takes large effort. Consequently, ARIN has built a tremendous amount of technical debt. Now that we have stateless ARIN Online servers, we can work on developing an architecture that is more focused on “micro-services.” This would mean maintaining and upgrading software and systems in smaller, more manageable components, with little to no impact on those who use ARIN Online.
The post What Is Stateless Architecture and What Does It Mean for ARIN? appeared first on Team ARIN.
The post What Is Stateless Architecture and What Does It Mean for ARIN? appeared first on Website Hosting Review.
I’ve written several blogs about how IPv6 is faster, and how that results in higher Google search rankings, and that’s good for sales. My presentation at NANOG76 went into it at some depth. The question everyone asks:
Why is IPv6 faster?
I don’t know. So let’s look at some measurements.
This is from APNIC data, using the ten largest mobile carriers in the world, where I know what transition mechanism they’re using. There are four carriers shown who provide native IPv4-IPv6 dual-stack to the handset: they’re all right at 1% failure rate. I should note that the two at 50ms and -50ms are in Bhutan and Trinidad and Tobago, so there may be other factors at play in the speed of their connectivity. The other two dual-stack wireless carriers are in the US and Taiwan, and IPv6 and IPv4 are nearly exactly the same speed.
Among the mobile carriers running NAT64, only the Australian has a faster IPv4, by just one millisecond. For all the rest, IPv6 is faster. Why?
With native dual-stack, the carrier provides both an IPv4 address and an IPv6 address to the handset. With NAT64, the carrier provides only an IPv6 address. If the client needs to reach an IPv4-only server, it has to go through translation (Network Address Translation, NAT64). Apple requires that all iPhone apps just work with NAT64. For Android, if there’s something in the app that uses IPv4 explicitly (or just an IPv4-only library), there’s a little NAT46 function in Android that translates to IPv6, since that’s the only address the handset has. That function is called CLAT (client translation), and when combined with NAT64, is called 464xlat.
It’s possible that going through a NAT64 introduces some latency, though I’ve never seen a NAT64 add measurable latency. Maybe the NAT64 is on a suboptimal path. It’s also possible that the latency difference is not in the NAT64 end, but on the CLAT end: maybe the handset translates from IPv4 to IPv6 before sending traffic out, and the handset software is causing the speed difference.
What about all the fixed line providers with speed differences?
These are just the largest networks in North America. This does suggest a loose correlation between failure rate and latency. Generally (but not closely) networks with more IPv6 failures show better IPv6 performance.
Most operating systems and browsers, including mobile handsets, use an algorithm called Happy Eyeballs to make sure the deployment of IPv6 doesn’t harm performance. That algorithm basically says:
- Send DNS queries AAAA then A, as separate queries but in quick succession.
- Send to an IPv6 name server If you have both an IPv6 name server and IPv4 name server configured.
- Don’t wait for both responses.
- If A comes first, wait 50ms (e.g.) for AAAA, in case it was just that the resolving name server didn’t have it cached.
- Begin your connection.
- If connection fails (e.g., no response in 250ms), and you got multiple DNS responses, try another: maybe use the other address family.
There’s an odd race condition here, I think. Let’s say you fire off your AAAA DNS query (IPv6) and your A DNS query (IPv4) within a millisecond. For whatever reason, the resolver you’re querying only has the A record cached, so it looks up the auth server for the AAAA query, but immediately responds with the A response. Your system waits 50ms for the AAAA response, and if it doesn’t arrive, it begins the connection, sending a TCP SYN over IPv4. Then the AAAA response arrives, so it begins the connection, sending a TCP SYN message over IPv6. Based on that timing, the TCP SYN-ACK is received over IPv4 before it’s received over IPv6.
That’s just an example. Any time the TCP SYN-ACK is received over IPv4 after the TCP SYN is sent over IPv6, but before the TCP SYN-ACK is received over IPv6, the system will use IPv4, and APNIC will count it as an error.
There could be reasons other than DNS why the SYN-ACK is received over IPv4 first. Maybe the TCP ACK required retransmission. Maybe the IPv6 attempt took 260ms (or whatever the connection timer was) and the IPv4 attempt completed in 9ms. Maybe there are different timers than the ones suggested by RFC8305 and some operating system gives a smaller head start to IPv6 but on some networks IPv4 is faster than IPv6 round trip time. Maybe we’re measuring old implementations of Happy Eyeballs (rfc6555).
tl;dr I think Android CLAT hurts IPv4 and I think there’s a race condition in Happy Eyeballs that can make IPv6 look faster in statistics by dropping some cases where it’s slower. If you want to enable IPv6 on your web site, here’s how:
The IPv6 On Button
Step 1. Find your web host below and follow the instructions.
Step 2. Update DNS–create a AAAA record with a test name (www6) pointing to your IPv6 address.
Step 3. Test the site from your machine, your phone, and https://ipv6-test.com/validate.php
Step 4. Update the test name to your web site name.
You should follow up to make sure your web logs tools don’t get confused, and if you’re monitoring the site, make sure to monitor separately for the IPv4 and IPv6 addresses, or users will have a bad experience if one is unavailable.
That’s it! Usually done in ten minutes.
Nothing to do, it’s on by default.
If you’re with another cloud company and they don’t have good IPv6 support, CloudFlare will front-end IPv6 for you.
Log into your portal and for “IPv6 Configuration” choose “Enable.”
Amazon Web Services (AWS)
Assuming you’re running your own server on EC2 in a VPC, you’ll need to start by adding IPv6 to the VPC. From the VPC Console, Actions > Edit CIDRs > Add IPv6 CIDR.
Then go to the EC2 console and find which Subnet your EC2 instance is on and add IPv6 to it. In the EC2 Console view, the Subnet ID will be on the bottom right. Subnet ID > Actions > Edit > Add IPv6 CIDR > any two-digit hex string, like 00.
Then update the Route Tables to route all IPv6 traffic from the subnet to the Internet Gateway. From the Route Tables console, Actions > Edit Routes > add 0::/0 with Target your IGW.
Then update your Security Groups to allow traffic from ::0/0. Security Groups Console > Actions > Edit Inbound Rules > Add Rule > then mirror your IPv4 policy. If you allow from “Anywhere,” then make sure that’s selected and includes ::/0.
Then edit your instance to assign an IPv6 address from it. Console > Actions > Networking > Manage IP Addresses > Add IPv6 Address.
If you’ve configured the server yourself (Apache or nginx) you may need to update your “listen” statements.
Enable IPv6 simply by prefixing your CNAME in DNS with “dualstack.” For example:
If you have a custom host name, follow the link to email Fastly Support saying, “I want to add IPv6 to my server www.example.com.”
Server instances can be configured for IPv6 according to their operating system, but IPv6 support for web servers hosted on Softlayer CDN only get IPv6 via Akamai.
IBM Cloud CDN
Change to a different CDN or use CloudFlare (above).
You’ll need a Basic Load Balancer or VNet to get IPv6. (Microsoft’s documentation does not state whether Standard Load Balancer supports IPv6).
The Load Balancer option comes with a lot of troubling limitations:
You can’t add IPv6 to your existing VM. You’ll have to create a new one behind your Load Balancer. Your Network Security Group policies won’t apply to IPv6. You can’t do it in the GUI–you have to use the CLI or PowerShell. I’d suggest changing to a different cloud or CDN or adding CloudFlare (above). https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-ipv6-overview
The Virtual Network instructions say you can upgrade in place, but they are less clear about security, but the CLI or PowerShell is still the only way to do it. https://docs.microsoft.com/en-us/azure/virtual-network/ipv6-overview
Rackspace gives pretty good examples on using Neutron to configure a port and using cURL to configure a port.
You’ll need to configure Load Balancing. There are several ways to configure Load Balancing to support IPv6, given at the links from https://cloud.google.com/load-balancing/docs/ipv6
Note that Google charges for using a static IPv6 address: “Reserved IPv6 addresses are charged at existing rates regardless of whether they are in use or not.” (“Existing rates” currently $0.01/hour for unused addresses, but since Google charges “regardless of whether they are in use or not” they’ll charge, so something like $7.20/month).
The better option is to find another cloud or CDN, or add CloudFlare (above).
If you have a dedicated server or virtual private server, you’ll pay $5.95/month to reserve an IPv6 address. Find a different host or use CloudFlare (above).
This list isn’t anywhere near exhaustive. If your provider isn’t listed, search for them by name plus “IPv6.”
I can update this post as I learn of corrections or additions. I’ve also created a common Google Sheet where people can add comments and I’ll update the sheet.
EDIT:  @jeremyvisser on Twitter says the Australian provider switched to native dual stack. So IPv4 is slower for all NAT64 carriers shown.
*This article was originally published on Retevia
The post Why is IPv6 faster? appeared first on Team ARIN.
Last week we had an ARIN Help Desk at NANOG 76 in Washington, D.C. I was happy to be there to help attendees with their registry needs and get a sense for the most-pressing concerns for network operators. NANOG is a great community, and we’re happy to be a part of it.
We had quite a few people come to us with questions that were as varied as a typical week on the phones. People asked us what we do, and we provided general education in that area. Some had questions about existing tickets (“I have a ticket open, but since I’m here…”). In some cases, the ticket could be resolved and closed on the spot, other times we were able to guide them with next steps to help keep their ticket moving towards resolution.
Hey @NANOG‘ers, stop by our #NANOG76 ARIN Help Desk this week to get your questions about IP & ASN registration answered. And while you’re here, get started creating an #IPv6 case study with us. pic.twitter.com/y62FJYAa4b
— ARIN (@TeamARIN) June 10, 2019
We were happy to answer educational questions about our services like explaining policy requirements, or explaining how the waiting list and transfer market work. We also answered many “How do I?” questions including: how do I request a resource? and how do I update my records? One of the best things about being on-site at the Help Desk is when we can completely resolve a long-standing customer issue. For example, I was able to help one customer update his account and Whois records. It had been on his to-do list for a couple of years, but he never got around to looking into it. The convenience and easy-access to ARIN staff at NANOG gave him the opportunity to stop by in-person and resolve the whole issue in only 10 minutes. He was happy to have the mystery solved.
While at #NANOG76 , @TeamARIN team member Eddie helped clean up my ARO account after a couple years of mysterious emails. Thanks Eddie!
— Austin Brower (@austonianb) June 12, 2019
In addition to our Help Desk at the meeting, we also asked individuals to tell us more about their IPv6 deployments. ARIN President and CEO, John Curran, gave a call to action for people to contribute IPv6 case studies. Several people stopped by to indicate they’re interested in sharing their IPv6 journey and learning from others who have already published an IPv6 case study.
First talk at #NANOG76 by @TeamARIN #nanog pic.twitter.com/e3YJscDuwv
— Michael T. Voity (@Mvoity) June 10, 2019
The NANOG 76 agenda was full of interesting talks including one from ARIN Advisory Council member, Alyssa Moore, on how to make ARIN policy work for network operators. You are encouraged to get involved in the ARIN policy process. Be sure to come to the next ARIN meeting in October directly following NANOG 77 in Austin, TX to discuss policy and find out more about what’s going on at ARIN.
DC bound for @nanog! Join me Monday morning for a talk on recent @TeamARIN policy developments that affect ~yooooooour~ network operations. #NANOG76
— Alyssa Moore (@lyssamoo) June 9, 2019
We’re happy to work with NANOG to serve the Internet community. If you have a question or concern you can’t find the answer to on our website, find us at an event like NANOG or give us a call at the Help Desk. There’s rarely a queue, we’re all friendly and helpful.
The post Questions Network Operators Ask – NANOG 76 appeared first on Team ARIN.
Telus IPv6 Case Study
TELUS was the first service provider in Canada to deploy IPv6 at scale for the benefit of its customers. As one of the largest telecommunications companies in Canada, TELUS has 1.9 million home Internet subscribers and 9.2 million wireless subscribers. 83% of TELUS Home Internet customers have IPv6 and the other 17% only need a firmware upgrade on their customer premise equipment (CPE). Personally, I have about ten years of experience with IPv6, and I am pleased to be part of a very successful program implementing IPv6 at TELUS. By using TELUS as an example, I will walk you through how service providers or organizations developing their own IPv6 plans can take a few practical steps to accelerate adoption.
Ready for Growth
TELUS implemented IPv6 for two primary reasons. First, to continue to future-proof our systems and, second, to allow for anticipated growth over the coming years. I still have the letter that John Curran sent to organizations in the region in 2009 notifying them of IPv4 depletion as a cool artifact to remember where executive support came from. That letter was received by my CEO, forwarded along to our CIO with notes, then to our CTO and onward. From there, we assembled a program team to determine the big rocks that we needed to get in place, starting with our core network and moving outward. We then factored in our services and created timelines. Much of this planning was driven by knowledge that we were headed to IPv4 scarcity. A key part of our business case was that, at the time, the market was an uncertain element and we didn’t want to be beholden to that market uncertainty. Given today’s IPv4 prices, this was the right decision.
One thing people might not expect is that IPv6 creates a layer of resiliency. If there is a problem with IPv4, whether a content host has an IPv4 outage or there’s BGP hijacking, IPv6 is an alternate path.
There is also a performance gain with IPv6 for both home Internet and mobile. Your home Internet and your CPE/residential gateway will have a network address translation (NAT) function to your private IP. There is a cost of processing time perspective that introduces latency in that path and any increase in latency reduces TCP throughput. By removing the NAT delay, you can expect higher performance from IPv6.
Preparing for IPv6
TELUS has had IPv6 in place for home Internet subscribers since 2015. We have also began rolling out a NAT CGN service to alleviate stress related to the IPv4 scarcity issue. TELUS offers IPv6 for wireless service as well. This is offered on a selective basis, so we are gradually scaling this up. In terms of timing, we prioritized IPv6, and then undertook IPv4 NAT. Our IPv6 project lasted a few years, during which we laid out the capital outlay and people resource capability.
Right off the bat, we asked ourselves – what are the customer end site size subnets that we will allocate for IPv6? We selected a /56 for our home Internet subscribers, a /48 for business end sites and /64 for mobile subscribers. We have a use case for each prefix that helped us to set up the scale of IPv6 allocation needed.
As a national carrier in Canada, we have a broad geography to cover. Part of our efforts to reduce latency involves tying our addresses to the geography. Because we looked at our number requirements, we went back to ARIN to ask for an expansion from our /32 to a /29, and were able to secure that change. We determined how much space was needed per region and broke it down even smaller than by province, so we could optimize routing for our IPv6 blocks. A /32 covers over 64,000 end sites of /48 or 16,000,000 end sites of /56. We then used nibble boundary consistently throughout (hex characters).
Next, we advertised our IPv6 space to our peering and transit partners. If you want to have rich interconnectivity, do an audit of your peering relationships to make sure they are all IPv6-enabled so that your traffic can be exchanged globally. From there, we started rolling out IPv6 at all of our edge nodes across our Multiprotocol Label Switching (MPLS) network. Once the core network routing was functional, we enabled elements like peering and transit. Then, we analyzed the shared infrastructure, like DNS, and completed the service design for each of our standalone services: home Internet, business Internet, fixed services and wireless services.
The Learning Curve
We anticipated that we needed to lubricate the big engine of a large ISP to adjust to IPv6, so we created a learning module that would allow people to get the understanding necessary for their role to manage the changes coming with IPv6. Everyone is used to the IPv4 address format, so wrapping your head around IPv6 was a vital piece to clearing the knowledge base hurdle. We employed both instructor-led training for the core team who would do the engineering and service design, and also multiple e-modules for everyone from our network operations to front line tech support to learn on their own time. For example, those in IT working with BSS, OSS systems need to be aware of IPv6 so they are familiar with the structure and know what to expect.
The other crucial step we took to get ahead of any potential problems was to first perform internal trials in the lab. Then, when we began the production roll out, we started with a friendly trial where employees selected their services and checked to make sure everything was working. We made sure MTUs were not breaking and access to DNS was working. One thing we caught in our friendly trial was that even though we had created the capability for DNS to reply with AAAA records, test sites showed us we had not enabled connectivity to the DNS routes over IPv6 yet. By virtue of our approach of starting with small, internal testing and growing to large production scale, potential risks were reduced as the process progressed.
The implementation of IPv6 was seamless and invisible to the consumer. In fact, the customer contact we did have on IPv6 was only positive. We went back to customers who had posted on our online forums over the years asking when we would move to IPv6 to tell them that it was now available. One of those people we notified even became a friendly tester, so it was cool to include someone who was eager to try it out and get on board.
Now that I have explained how TELUS deployed IPv6, here is a quick outline of some of the practical steps service providers or organizations can take to accelerate IPv6 adoption:
IPv6 Peering & Transit
- Rich IPv6 interconnectivity is a must
- Enable IPv6 on all existing peering links
- Update your process
- Enable IPv6 on transit
- Advertise your IPv6 routes
IPv6 In Your Network
- Enable your core network
- Consider 6PE if you run an MPLS network
- Native IPv6 from the edge out
- DNS and other shared infrastructure
- Services can enjoy IPv6 access
- Network standards
- Customer premise equipment
- OSS & BSS systems
- Proof of concept
- Dev Ops if possible
Start Small & Scale Up
- Roll out in small increments at first
- Begin with employees, then include friendly customers
- Identify problems early and improve
- Prove success at small scale first
- Ramp up your scale
At TELUS, this process resulted in a successful rollout of IPv6.
My biggest piece of advice would be that if you are have having trouble getting buy-in from decision makers for supporting IPv6 deployment in your organization, look broadly at all sets of benefits you could achieve. Don’t rule anything out. Look for those opportunities where you can see gains for your organization, the benefits you might not have anticipated are there. Imagine what the network would like with IPv6 in it. The sheer scale of IPv6 has far less to do with capacity management that it may initially appear. If you have a large enterprise with a LAN to service employees, you are likely in an ongoing battle with IPv4 as you are constantly scaling and rescaling. Renumbering is difficult, but with an IPv6 single /64, the scale is exceptionally beneficial.
Long term, if everyone moves to IPv6, we can begin to phase out IPv4 and again enjoy the benefits of a single stack. There is a lower technical debt to be borne by all service providers, content providers, businesses and vendors of network equipment. In summary, adopting IPv6 will provide several benefits to your organization, so those that undertake the task of rolling it out, however incrementally, will realize gains for both their organization and their customers.
The post Practical Steps to Accelerate IPv6 Adoption appeared first on Team ARIN.