Posted on Leave a comment

Three Key Standpoints in Implementing IPv6

Three Key Standpoints in Implementing IPv6 1

American Data Technology, Inc. IPv6 Case Study

American Data Technology, Inc is a small hosting company based in North Carolina with variety of customers. We have three datacenter spaces, two in Research Triangle Park, North Carolina and one in Ashburn, Virginia. We provide hosting services over both IPv4 and IPv6 (“dual stack”). In fact, all our IP traffic could be sent over IPv6 including HTTPs, remote desktop, SSH, VPN, and various other types of traffic. Since end users of the websites are the general public, we decided we had to be dual stacked. The same way we couldn’t lock out IPv6 users and be IPv4 only, we couldn’t lock out IPv4 users and be IPv6 only. We have to be able to support both.

providers should implement ipv6

Internal process

As one of the founding members and CTO of ADTI, I manage all the technical and IT-related initiatives for the company. In that role, I oversaw our IPv6 project. We had various tech meetings to make sure everything was lined up in the right sequence.  We asked ourselves: Which routers would be enabled with IPv6 first –internal or border routers? Which switches? and so on. In the end, everything has to support IPv6 all the way from the border router to the servers.

We also had to make decisions about how much IPv6 space we would allocate to each customer. We had conversations about numbering conventions. For convenience, we decided on assigning IPv6 addresses to customers using the last IPv6 address to match their IPv4 address.

Driving incentive to deploy

Back in the 2012 timeframe, there was a lot of press that IPv4 was about to run out shortly, but the biggest reason we deployed IPv6 was due to our U.S. government customers. They were mandated to support IPv6 and to be on a dual stack network by September 30, 2012. Indeed, we have found IPv6 interest is primarily from our federal customers because of the OMB mandated requirement that all government websites have to support IPv6 as well as IPv4.  It is important that government websites be accessible to their customer-base (i.e. everyone in the country). They can’t be in a situation where they are putting out information or forms where only some people can get to it, not everyone.

Even though we still aren’t in a situation where customers are forced to use IPv6 because there is no IPv4 yet, we definitely have customers that prefer IPv6. When their router has a choice between an IPv4 path and IPv6 path, they choose IPv6 first.

Three key standpoints – technical, security, and coordination

I recommend you make sure your IPv6 implementation is planned from a technical, security, and coordination standpoint.

plan ipv6 3 standpoints

From technology standpoint

Deploying IPv6 meant making sure all our equipment supported IPv6. Beyond that our upstream providers (whoever we got our network services from) also had to support IPv6. Back when we were working on our implementation, there were a lot of companies offering pseudo IPv6 capability. By that I mean they would “pretend” to offer IPv6, but then they would provide it through some fancy tunneling or something like that. We weren’t thrilled with that kind of approach, because the bottom line is that it wasn’t really IPv6. On top of that, who knows what security issues you were introducing by doing that. We decided we needed to be on a native IPv6 network. Unfortunately, one of our datacenters indicated they had no immediate plans to deploy IPv6 for the next 12-24 months, so we ended up having to migrate to a datacenter that did support it.  We had to move all our equipment over, and that datacenter lost our business as a result of not supporting IPv6.

Around the same time, we were needing more and more IP addresses so we got our own IPv4 and IPv6 allocation from ARIN. We got the smallest IPv6 allocation available at the time which was a /32. We were one of the companies that had achieved IPv6 capability in time to participate in World IPv6 Day on June 6, 2012.

From a security standpoint

When we were preparing to deploy IPv6, we spent quite a bit of time studying the security ramifications. We wanted to ensure whatever IPv6 configurations we turned were secure and hardened. We didn’t want to introduce any new vulnerabilities into the system or adversely impact the security posture of our infrastructure or our customers’ assets. For example, there were several settings related to address discovery that we needed to configure one way and not the other. Configuring it the wrong way could allow hackers to get a foothold and expand into the network.

From a coordination standpoint

Our IPv6 implementation had to be closely planned logistically with our customers. We had one customer in particular that was eager to be on IPv6 by a certain deadline. We worked with them on all the IP address changes, even having to go through the long process of changing IPv4 addresses so everything was on a new network. With our other customers, we notified them that they had the option of adding IPv6 addresses. We considered whether we should just go ahead and enable IPv6 for all our customers or just let them know they have the option to enable IPv6. For security reasons, we decided it was best to give every customer the option of adding IPv6 at no charge, and they could contact us if they want it enabled. We have seen both government and few commercial customers take advantage of that offer.

Considerations

Our biggest obstacle at the time of our deployment was the lack of IPv6 capability among network or bandwidth providers. Even though most providers had a plan to eventually offer it, some were working on it faster than others. We had to switch companies to one that provided IPv6 immediately. It’s one thing to be on an IPv6 network yourself, but if no one else is, what good is that? It has to be end to end. The same customer I described earlier also had huge challenges in this regard. Even though they were driving the IPv6 requirement, their datacenter was not on IPv6 for at least another year.  That meant we had to provide two sets of equipment for them. We provided them a jump server where they would connect via IPv4 (because they only had IPv4 capability), and then from that jump server they would connect to an IPv6-only server, thus allowing them to be on IPv6 network.

costs implementing ipv6

In general, cost-wise, deploying wasn’t that big of deal. We didn’t suddenly see providers charging more money for IPv6. There was a lot of effort involved that did carry with it a cost. However, that was primarily a one-time engineering and implementation cost. There were no significant additional reoccurring costs in implementing IPv6.

One interesting thing you have to plan for is related to the size of IPv6 in comparison with IPv4 and the time it will take to scan those networks. We allocate about eight IPv4 addresses per customer, but with IPv6 it’s hard to allocate anything less than a few million. In an IPv4 network you can run a scan of everything in a /24 IP range in only a few seconds. In an IPv6 environment where you have a /48 subnet per customer, it will take a longer time to scan everything, to the point where it becomes infeasible to scan an entire IPv6 subnet in a timely manner. Yet as part of ongoing security monitoring, you have to continue doing the scans, because you don’t know what might be lurking somewhere in that range, so the security architecture needs careful planning and design to accommodate these aspects.

IPv6 is a good thing

I believe there’s no reason not to implement IPv6 at this time. The top two pieces of advice I would recommend for other hosting providers are to:

  1. Carefully select your upstream provider. Make sure they are providing good quality IPv6. Nowadays it’s not such a big issue, but back when we were deploying IPv6 there was a blurry line between native and non-native IPv6.
  2. Make sure you pay attention to security aspects. It is not straightforward. Be very careful. Give a great deal of thought in how you implement IPv6 from a security standpoint.

Every bandwidth, hosting, and network provider should implement IPv6. Definitely do not choose to not implement it. That would be a mistake.

The post Three Key Standpoints in Implementing IPv6 appeared first on Team ARIN.

Posted on Leave a comment

You’re Invited! Join Us at ARIN 42 For A User Testing Experience

You’re invited to a special screening of our new website at ARIN 42 on October 4-5 in Vancouver, BC.  We want you to preview the work we’ve done on the totally redesigned www.arin.net. This is your chance to have VIP access and a front-row seat!

The Details:

At your convenience during ARIN Help Desk hours on both Thursday 4 October and Friday 5 October, you can sit down with me and my fellow UI specialist to get a first look at improvements underway. We will be sitting right outside the doors of the general session. Just stop by for a quick walkthrough — most last five to ten minutes — of the site and tell us what you think.

If you’re planning to be in Vancouver all week, feel free to stop by earlier. We will be set up during NANOG 74 as well.  Aren’t joining us in Vancouver? The preview will also be live online with a feedback survey so you can tell us your thoughts.

Is Any Experience Needed?

Nope! You don’t need any prior experience with ARIN or with user testing. We want to make sure our changes and improvements are headed in the right direction for our community, which means anyone and everyone is welcome to test them out.

This is a great hands-on opportunity to make an impact on our website and online service. Be sure to mark that you are interested in being a user tester when you register for the meeting. Or you can email meetings@arin.net to sign up in advance.

We look forward to seeing how many “stars” you think our new website has earned. We thank you in advance for your input — we couldn’t do this without you.

The post You’re Invited! Join Us at ARIN 42 For A User Testing Experience appeared first on Team ARIN.

Posted on Leave a comment

A New Use for RDAP

As you may already know, Registry Data Access Protocol (RDAP) is a Whois alternative for querying resource registration data from Domain Name Registries (DNRs) and Regional Internet Registries (RIRs) like us. You can use RDAP to query for domains, IP addresses or networks, Autonomous System numbers, nameservers, Point of Contact records, and Organization Identifiers.

We know all that, so what’s new?

We’ve been busy working on a new Origin Autonomous System (AS) query feature for you! You can now use RDAP to query the Origin AS Field.

During any IPv4 or IPv6 block transaction, IP address block holders (including legacy address holders) have the option to fill in a field called the Origin AS. This additional field is used to record a list of the Autonomous System Numbers (ASNs), separated by commas or whitespace, from which the addresses in the address block(s) may originate. The Origin AS data assists Internet Service Providers with determining the validity of a Letter of Authority (LOA) provided by a customer when requesting to manage an IP address block. You can read more it in this blog post written by our CTO, Mark Kosters.

Before now, you had to use Whois to query for this data. With our new query feature, you can now use RDAP to search for networks that have a specific AS Number in the Origin AS field. To perform an example query, use the following URL:

https://rdap.arin.net/registry/arin_originas0_networksbyoriginas/10745

{

“rdapConformance” : [ “rdap_level_0”, “arin_originas0”, “cidr0” ],

“arin_originas0_networkSearchResults” : [ {

“handle” : “NET-192-149-252-0-1”,

“startAddress” : “192.149.252.0”,

“endAddress” : “192.149.252.255”,

“ipVersion” : “v4”,

“name” : “ARIN-CHA”,

“parentHandle” : “NET-192-0-0-0-0”,

“port43” : “whois.arin.net”,

“objectClassName” : “ip network”,

“cidr0_cidrs” : [ {

“v4prefix” : “192.149.252.0”,

“length” : 24

} ],

“arin_originas0_originautnums” : [ 10745 ],

}, {

} ]

}

It’s important to note that when you query the Origin AS Field, it will return an array of networks, not just one. You will also see a set of data called CIDR blocks returned to you. We added this data to make it easier for you to take this information and create routing policy with it. Currently, about 23% of our IP address blocks have the Origin AS field completed.

Collecting and making Origin AS information available to our community is part of the implementation of Policy ARIN-2006-3: Capturing Originations in Templates. You can visit our Origin AS Information page to learn more.

If you have any questions about this new feature, we’re happy to help! Please submit a ticket through your ARIN Online account or give our help desk a call at 703.227.0660.

The post A New Use for RDAP appeared first on Team ARIN.

Posted on Leave a comment

Publishing Simple Reassignment Data Via ARIN’s Reg-RWS API

ISPs can automate their interactions with ARIN using our Registration RESTful Service or Reg-RWS API. This Application Programming Interface (API) allows you to make calls to create/update/delete customer reassignment information. This how-to guide covers only simple reassignments, which are recommended for general use. You can learn more about the difference between simple and detailed reassignments on our website. All examples use ARIN’s Operational Test & Evaluation (OT&E) environment, which is a monthly copy of production data.

Getting Started

To use the Reg-RWS API, you must have a reallocation or direct allocation registered in ARIN’s database. You must also have an ARIN Online account which is authorized to manage those resources. If you need assistance associating your account with your resources, contact ARIN’s Registration Services Help Desk either via the Ask ARIN feature from within your ARIN Online account or via phone M-F 7:00 AM-7:00 PM ET at 703.227.0660. Once your account is authorized, create an API key (choose “Your Account” > “Settings” and select “Manage API Keys” from the action menu).

A web-based RESTful client is a useful tool to learn the API. You are welcome to go straight to coding software to use the API, but it may be helpful to start interacting manually so you can learn the API. Advanced REST Client for Chrome is a recommended option.

Sending a GET Command

Before we begin creating new records, it’s a good idea to learn the basics by retrieving one of your own network records via the API. While logged in to your ARIN Online account, choose “IP Addresses” > “Search” and select one of the networks you see. To retrieve that network record via the Reg-RWS API, send a GET call with the following URL:

https://reg.ote.arin.net/rest/net/NET-198-51-100-0-1?apikey=[API Key]

Our examples will use an IP address reserved for documentation. Make sure you substitute your own information. This should return a net payload. If so, congratulations! You’ve made your first successful Reg-RWS call. If not, contact us for assistance.

Creating a Recipient Customer Record

Once you’ve mastered the GET command, it’s time to move on to creating a recipient customer record. The recipient customer record is the first step in publishing reassignment information. You’ll need the customer’s name and street address. To create a recipient customer record, send a POST command to the following URL:

https://reg.ote.arin.net/rest/net/NET-198-51-100-0-1/customer?apikey=[API Key]

You’ll need to supply a customer payload with the customer’s information. Here’s a sample:

CUSTOMERNAME

UNITED STATES

US

USA

1

Line 1

Chantilly

VA

20151

Line 1

false

You can either use the sample payload or replace it with your own information. You should get a customer payload back very similar to the one you sent, but with some additional system-supplied values (e.g. registration date) added on. The most important field to note is the customer ID. That’s how you’ll associate this customer’s information with a network range in the next step.

Creating a Reassignment

Once you’ve successfully created a recipient customer record, it’s time to publish a reassignment with that customer’s information along with the net range assigned to them. You’ll need to send a network payload using the PUT method and the following URL:

https://reg.ote.arin.net/reg/net/NET-198-51-100-0-1/reassign?apikey=[API Key]

Sample payload:

4

S

198.51.100.0

198.51.100.255

24

C07018091

NET-198-51-100-0-1

NETNAME

Assuming the request is successful, you’ll get a net payload back with a few additional system-generated values such as a registration date. Congratulations – you’ve published a simple reassignment!

Deleting a Simple Reassignment

To delete the simple reassignment you just created, send a DELETE call to this URL:

https://reg.ote.arin.net/rest/net/NET-198-51-100-0-2?apikey=[API Key]

Assuming the request succeeds, you’ve deleted the simple reassignment. There’s one additional step: deleting the associated customer record. It’s not automatically deleted. We have an automated process that cleans up these records, but we always appreciate it when you delete it first. To delete the customer record, send a DELETE call to this URL:

https://reg.ote.arin.net/rest/customer/C07018091?apikey=[API Key]

Once you’ve confirmed deletion, give yourself a pat on the back. You now know the basic calls to create and delete simple reassignments to customers. You can add these calls to any IP Address Management (IPAM) software you’re using to automate interaction with ARIN, or code your own software.

The post Publishing Simple Reassignment Data Via ARIN’s Reg-RWS API appeared first on Team ARIN.

Posted on Leave a comment

EPA Committed to Finding a Workaround for Every IPv6 Challenge

Three Key Standpoints in Implementing IPv6 2

EPA IPv6 Case Study

The Environmental Protection Agency (EPA) has made great progress toward the Office of Management and Budget (OMB) IPv6 goals for federal agencies. Brian Epley, the Office Director for the Office of Information Technology Operations, and his team at the EPA walked me through what it took to make IPv6 deployment a reality.

Key requirements for IPv6 deployment

First things first, Brian told me, “It’s important to understand the scope of our IPv6 effort. It was a multi-year activity, and I’m happy to report that EPA is going to claim a win.”

EPA is comprised of 10 regions and 14 program offices which are interconnected via a high-performance telecommunications network.  Employees utilize and depend on roughly 55 public websites, 1,900 servers, and 21,000 desktops. Because IT is largely decentralized across the agency, IPv6 deployment required senior leadership prioritization, a documented deployment approach, appointment of an IPv6 champion, and active participation from stakeholders in all regions and program offices.  These elements were essential for obtaining buy-in, minimizing re-work, ensuring no impact to daily operations, and maintaining the agency’s IT security posture.

IPv6 deployment requirements

Senior leadership prioritization

“Having a CIO make IPv6 adoption a priority across the agency allowed us to be successful,” said Brian. Strong support from the office of the CIO forced stakeholders to come to the table, to get new equipment installed and servers configured. Management’s keen interest both at a granular level and holistically was imperative for achieving a high level of interest and prioritization across the agency.

Let’s talk budget

Brian and his team recognized they would need to do a realignment related to ongoing initiatives within the existing budget. Despite OMB mandates and full leadership buy in, there was no new money earmarked just for an IPv6 initiative. Furthermore, in achieving the OMB requirements, they found themselves with net new initiatives, programmatic or organizationally driven, that require an additional level of effort and scrutiny. Looking at their as-is state, they made modifications where appropriate to push those things forward in more rapid fashion. For example, when the OMB mandate came out, it aligned with a preplanned telecom equipment hardware refresh at the WAN side for which EPA has a managed service. Due to this fortunate timing, they were able to include IPv6 requirements into that contract without waiting for new funds.

Taking a waterfall approach

EPA took a traditional waterfall approach to accomplish the many tasks required to deploy IPv6 within the agency. They scoped everything out so they could minimize rework and resource expenditure. Brian emphasized, “The planning piece gave us the metrics to show that we were purposefully and deliberately moving forward with the implementation.” A high-level outline for the EPA’s approach included:

  1. Plan, implement, and validate core infrastructure for IPv6 readiness. 
    1. EPA partnered with Department of Labor (DOL) on their IPv6 addressing plan and used it as a template to customize EPA’s approach.  This information-sharing helped them start further along than if they had to do it alone. EPA identified core infrastructure that was not IPv6 ready (EPA-managed and MTIPS-managed) and pursued getting the core infrastructure ready for IPv6.  Their final step was to validate the core IPv6 readiness.
  2. Inventory, fix or replace, and test endpoints IPv6 readiness.
    1. EPA assessed what in-scope IT assets would require reconfiguration, updating, and/or replacing.  A representative sample of assets were used to test and validate IPv6 functionality before deploying agency-wide.
  3. Verify monitoring and compliance tools functionality worked for IPv6.
    1. EPA inventoried all applicable IT tools used to manage and support monitoring functions and verified IPv4 and IPv6 functionality were on par.
  4. Communicate findings, provide training, and report progress.
    1. EPA held weekly meetings with all stakeholders to report on progress, share lessons learned, and to identify training needs.  They prioritized information-sharing by creating a repository for solutions and suggestions.  They also provided periodic progress reports to agency senior leadership as well as OMB.

Technically speaking, the approach EPA took from start to finish was to make the core IPv6-ready and then work back to the end devices. This way, they were able to see the progression and make sure one part was operating appropriately before moving onto the next part. Brian and his team went in phases and used representative samples. They identified subsets that represented the use cases they thought they were going to have. Then they had technically proficient individuals apply IPv6, test out the functionality, and identify any issues. This process allowed them to deploy IPv6 in phases so most of their user base didn’t even notice a change.

EPA IPv6 from core to end devices

Graphic provided by EPA

Challenges and Workarounds

IPv4 IPv6 support issue found workaround

“Whenever we ran into a technology issue that didn’t give the same level of support in IPv6 as IPv4, instead of taking it as a challenge we couldn’t overcome, we found a workaround for it—from the desktop up to the network,” Brian explained. Here are few challenges EPA faced and the workarounds they devised:

Challenge: EPA’s MTIPS provider lacked the ability to monitor and alert on IPv6 protocol failures.  When they first got IPv6 up and running on the network, there weren’t any tools available to identify when one of the two protocols were down. Either the circuit was up or the circuit was down. This was a big problem for EPA because when EPA had a high percentage of its clients operating on IPv6, the network operations team had to depend on user complaints to respond to critical network errors.

  • Workaround: They had to work with their provider to come up with a nonstandard method for monitoring the health of the IPv6 protocol to make IPv6 errors more visible to improve the user’s network experience with IPv6.

Challenge: EPA required a refresh to its network switching hardware to IPv6 compliant devices. The timeline for procurement and deployment of new switching hardware forced the EPA to function with some network switches that were not fully IPv6 capable.

  • Workaround: They suppressed DHCPv6 advertisements to networks that were forced to function on old hardware so the IPv6 deployment could continue while awaiting deployment of the new IPv6 capable switches.

Challenge: In general, EPA was faced with vendor products that did not have full IPv6 parity with IPv4.

  • Workaround: In each situation, they worked with the product vendor for a patch or solution. For example, they worked with the agency’s cloud email service provider extensively to get IPv6 up and running, from doing packet captures to asking them to turn off their IPv6 DNS in order to access email during an IPv6 protocol outage.  “We continually had to push vendors to provide additional IPv6 support,” Brian said. “We had to convince them this was not only beneficial to us, but made a good business case for them. They could utilize our agency’s IPv6 experience to provide a better IPv6 service to other customers.”

Brian mentioned it is important to note that not every IPv6 problem that EPA encountered was an EPA problem.  Many times, they had to partner with technology vendors, external organizations and/or other federal agencies to resolve IPv6 issues.  This was necessary to ensure EPA users relying on that organization’s services were not inclined to disable IPv6 and stymie IPv6 deployment. “The general perception is that IPv6 is a nicety, not a necessity,” said Brian. “In many cases, if there is a problem, the preliminary response may be to turn off IPv6 to resume normal operations under IPv4.  It will take patience and persistence to get IPv6 accepted and adopted by the support community given the pressures of maintaining a 24 x 7 operational network.”

OMB IPv6 Goals Status

For EPA, IPv6 deployment was a multi-year effort that easily took 3-5 years if you include preparatory work required to meet OMB mandates.  The dynamic nature of IT coupled with on-going deployments of multiple initiatives caused fluctuations in EPA’s OMB IPv6 implementation progress metrics.  However, they have made significant progress on each of the three OMB IPv6 goals listed below:

FY2012 Goal: Natively implement IPv6 on public services (websites, DNS, mail, etc).

Intent: The general public is able to access US Government (USG) citizen services regardless of whether they are on IPv4 or IPv6.

  • EPA was once 100% compliant with the 2012 mandate.  However, web failures for cloud-hosted domains occurred because cloud service providers were not yet fully supporting IPv6.

EPA IPv6 DNSSEC Stats

FY2014 Goal: Implement IPv6 on all internal Internet capable systems so that they can natively communicate via IPv6.

Intent: Ensure that the USG is able to do business with the general public regardless of whether they are on IPv4 or IPv6.

  • EPA manages 21,173 desktops of which 21,115 of them are dual-stacked to support IPv6, putting EPA at 99.7% in compliance with the 2014 mandate. Even above and beyond the mandate, EPA implemented IPv6 on 70% of its servers, many of which were not required to have IPv6 on them for the FY2014 mandate.

Ensure IPv6 capabilities in IT acquisitions: Procurement.

Intent:  Leverage technology refreshes to secure IPv6-capable IT infrastructure.

  • EPA scores itself at 92% compliance when it comes to IPv6 IT acquisition readiness. Thus far they have identified points of contact, issued agency IPv6 compliance memos, developed contract clause specification language, determined which forms, tools, and processes require IPv6 compliance, and implemented a procedure that would require a waiver from the CIO should an acquisition not meet IPv6 specifications. Now they are internally reviewing remaining documentation for baseline IPv6 requirement and anticipate full compliance before the end of the 2018 fiscal year.

Life-saving benefits of IPv6

What motivated EPA to adopt IPv6 was realizing not only the necessity for the mandate, but also the real-world application and benefit of IPv6. “We had onsite coordinators and emergency responders that could not deliver the mission without the effective application and use of IPv6. In my opinion, that’s what brought the passion of the team and success of this effort to the forefront,” said Brian.

Three Key Standpoints in Implementing IPv6 3

EPA first responders encountered a problem where they needed to access EPA GIS data but their mobile devices were on networks that only supported IPv6.  Since EPA’s network was fully IPv6 capable, the problem was quickly resolved by configuring EPA’s local proxy device to listen on the IPv6 stack. Without IPv6, the outcome could have been dire. Take for example, the recent wildfires in California or hurricane season last year. Brian said, “We were able to accelerate and increase the number of human resources that were responding to the emergency and deploy mobile devices and other GIS devices to allow them to do their jobs.”

Advice for other federal agencies

Considering the success EPA has had with IPv6, I asked Brian and his team what advice they would give to other federal agencies that are in the process of deploying IPv6. They had several great recommendations including:

  • Spend the time to think through and document an IP address schema that minimizes re-work.
  • Develop an implementation plan that can assist with correctly sequencing activities and progress reporting. Also allow room for refinements.
  • Get senior management (CIO) buy-in and support, because it is critical for success.
  • Keep stakeholders engaged with regular progress reporting to management.
  • Update key documents and procedures to ensure IPv6 becomes part of normal IT operations and maintenance activities.

The post EPA Committed to Finding a Workaround for Every IPv6 Challenge appeared first on Team ARIN.

Posted on Leave a comment

Has Your Company Forgotten About Some of its IPv4 Address Space?

Know Your Corporate History

Updating the registration information for Internet number resources (IP addresses and Autonomous System Numbers) is an item often overlooked when corporations complete a merger or undertake a major corporate restructuring. However, updating the registration information for an organization’s Internet number resources is very important!

Consider this example that uses hypothetical organization names.  Presume the fictitious organization, “Best Widgets, Inc.” was issued a /16 IPv4 address block in 1996 and shortly after was acquired by “Best Dog Holdings, LLC.”  “Best Dog Holdings, LLC” converts to an Inc. under the name “Blue Dog, Inc.”  A few years later “Blue Dog, Inc.” merges with and into “Parents Know Best Corp.”  If the registration information for the address block was not continually updated as the various corporate events took place, then “Parents Know Best Corp.” may, as legal successor to Best Widgets, Inc., hold registration rights to the /16, but registered under one of its earlier legal names.  Please note that a number of factors contribute to the assessment of the proper holder of registration rights to Internet number resources and this is just one of many hypothetical outcomes.

You might be thinking that some of your corporate events happened over 20 years ago and certainly the Internet number resources not updated would be revoked by now, but this may not be the case – particularly with legacy number resources.  Legacy number resources are IPv4 addresses and Autonomous System numbers which were originally issued by one of the predecessor registries prior to ARIN’s inception in December 1997 and those rights, unless transferred to a third party, remain with the original registrant or its legal successor.  At its formation, the ARIN Board of Trustees decided that ARIN would provide basic registration services to legacy number resource holders.  Legacy number resources will often remain in the original registrant entity’s name after a corporate merger or acquisition event unless they are updated to reflect the legal successor of the original registrant.

It is not unusual for an organization to grow or change hands several times as it adapts to an ever-changing business environment.  What is your organization’s corporate history?  How many different names has your organization had?  How many companies has your organization acquired or with whom has it merged since its inception?  You might say “We have been in business for two decades, who has that sort of documentation?” If you have incomplete corporate records, a resource for obtaining additional information/documentation may be available in your company’s province or state of incorporation.  In addition, if your organization (or any of your acquired entities) was ever a reporting entity filing with the Securities and Exchange Commission (SEC) or the Canadian government, the SEC’s website could be a good resource and the Canadian filings can be viewed through SEDAR.

How Do I Find Out if my Organization may have rights to additional address space under an earlier name?

You can search ARIN’s Whois database to see if entities that your organization has acquired currently have Internet number resources directly registered to them.  ARIN’s Whois directory service allows a user to retrieve information about Internet number resources, organizations, and Points of Contact (POCs) registered with ARIN. It pulls this information directly from ARIN’s database.  There are few different ways to get information from ARIN’s Whois database as outlined in our Quick Guide to ARIN’s Whois.

Try any of the following:

1. Web interfaces.  In the upper right-hand corner of our website is a “Search Whois” box.  Enter the first several words of any entity name or POC name followed by an asterisk “*” (the asterisk acts as a wildcard and will pull up all the records in ARIN’s Whois database that begins with the words you entered.) It is likely that not all of the hits from your query will be applicable to your organization.  You can also utilize the Advanced Search function to limit your search results to just organizations by clicking on the words “Advanced Search” directly below the Search Whois box and specify “Organization” or “Name” under your search field.

2. Application Programming Interfaces:  ARIN provides a Whois-RESTful Web Service (Whois-RWS) that allows developers to create their own applications or scripts that retrieve information using Whois-RWS. You can find more information about Whois-RESTful Web Service on our website.  The IETF has standardized a RESTful Whois API called Registration Data Access Protocol (RDAP) that is supported by all Regional Internet Registries (RIRs), including ARIN. More information is available on the RDAP page.

3. Command-Line Interface (CLI) clients: You can access Whois information by connecting to a Whois server using CLI commands entered into a terminal window. To submit a Whois query from a terminal, you will want to structure your search like this: whois -h whois.arin.net “flag search-term This query is broken down in parts:

  • “whois” = the command itself
  • “-h” = specifies the hostname of the Whois server
  • “whois.arin.net” = the name of ARIN’s Whois server
  • “flag” = narrows the search by restricting the results to those that match criteria designated by the flag. (Complete list of Whois flags)
  • “search-term” = the information for which you are searching. To see a complete list of all result fields and their respective descriptions, you’ll want to visit the “Interpreting Whois Results” section of the Quick Guide.

Research your corporate history and search ARIN’s Whois database today!

The post Has Your Company Forgotten About Some of its IPv4 Address Space? appeared first on Team ARIN.

Posted on Leave a comment

10 Reasons to Attend ARIN 42

You may have heard that we’ve opened registration for our next Public Policy and Members Meeting, ARIN 42, in Vancouver, BC 4-5 October. And maybe you’re thinking, “That’s nice, but why should I attend?” Well, there are lots of reasons we think you should attend, but we’ve compiled our top ten reasons for you.

(Not sure what our Public Policy and Members Meetings are about? No worries, just read this first.)

1. Impact the future of the Internet. We are one of five Regional Internet Registries in the world. Your voice can make a big impact on the development of the Internet in our region. Attend ARIN 42 to learn about and participate in the Internet Number resource policy development process.

2. Rub elbows with Internet Influencers. Our friendly community is full of brilliant minds. Expand your knowledge (and your network) by getting to know some of the most influential people in the Internet world.

3. Learn what ARIN can do for YOU. Learn more about our services and see how we may be able to serve you or the organization you represent.

4. Interact with our Board of Trustees, Advisory Council, and staff in person. Our meetings offer a unique opportunity to chat with and get to know all three of these groups in the same place.

5. Did you go to IETF? If not, get the lowdown from our intrepid IETF reporter with her crowd-favorite, IETF report which focuses on topics of interest to the Network Operator community.

6. Exert your influence and share your knowledge. You have a unique perspective and experience – share it at the microphone during policy discussions, or connect with us to see your story in this space! We love sharing stories from our community here on TeamARIN.

7. Get social with us. Join us at our ARIN social on Thursday evening to network and unwind in a fun, casual environment.

8. Attend NANOG 74. Our meeting directly follows NANOG 74 in the same location. Kill two birds with one stone and come early to attend their meeting. Already planning to attend NANOG 74? Stay after their meeting to join ours! Registration is free for everyone if you sign up by 2 October.

9. Get a sneak peek of our new website. We’re working on launching a new ARIN website, and we’re previewing a close to finished product at ARIN 42. See what we’ve done and let us know what you think. We will have a user testing table on-site.

10. Come visit our help desk! Need to check in on your resources or get some assistance with your ARIN Online account? We will have members from our Registration Services team on-site ready to help answer your questions. Pop by the help desk to say hello!

Have I convinced you yet? Great! After registering for ARIN 42, (you know you want to) take a look at these ideas for how to spend your free time in beautiful Vancouver.

  • Wake up early and go for a walk or jog around Stanley Park. Come back by 8:00 AM to enjoy a complimentary breakfast before our meeting starts at 9:00 AM.
  • After the meeting ends on Friday, grab a few friends and spend the afternoon exploring Vancouver’s oldest neighborhood, Gastown.
  • Extending your stay through the weekend? Enjoy views from above by visiting Capilano Suspension Bridge or by embarking on one of these beautiful hikes.

There are so many reasons to join us at ARIN 42. We hope this sheds light on just how impactful our meetings are to advancing the future of the Internet. We look forward to seeing you in Vancouver! And if you can’t join us in person, we look forward to your virtual participation.

Ready? Register now!

The post 10 Reasons to Attend ARIN 42 appeared first on Team ARIN.

Posted on Leave a comment

It’s Simple: Review, Update, or Designate an ARIN Voting Contact Today!

Each year, our Member Services team reminds our Members to review the Voting Contact they have on file in preparation for the annual October ARIN Elections. This year, the voting eligibility deadline is Monday, 20 August. In order to cast an electronic ballot in the ARIN Elections this October, you need to confirm that your organization is an ARIN General Member in Good Standing (GMIGS), and that there is a designated Voting Contact with an ARIN Online account on file before the August deadline.

Here’s how simple it is for Member organizations to view, update, and/or designate a Voting Contact now:

View Your Organization’s Voting Contact:

(Note: Only current Voting Contacts and Admin, Tech, and Abuse Point of Contacts are able to view their organization’s Voting Contact.)

1. Log in to your ARIN Online account.
2. Select Your Account Organization Identifiers from the navigation menu.
3. Select an Organization Handle that is associated with your ARIN Online account.
4. If your organization is an ARIN Member, you may view the Voting Contact that appears in the Voting Contact section.*

*If you wish to update the Voting Contact shown or if one is not listed, please follow the steps listed under Designating a Voting Contact.

Modify a Voting Contact:

You must be an Admin POC or Tech POC for a member organization to modify the Voting Contact in ARIN Online.

1. Log into ARIN Online.
2. Select Your Account Organization Identifiers from the navigation menu.
3. Select an Organization Handle.
4. View the Voting Contact section.
5. Select Manage Voting Contact in the lower right corner.
6. Select one new Voting Contact from one of the following three options:

  • Appoint myself
  • Choose from eligible associated ARIN Online users
  • Appoint an ARIN Online user by email address

7. After entering or selecting the required information, choose Submit.

Designate a Voting Contact:

To designate a Voting Contact for the first time, you must be an Admin POC or Tech POC for a member organization.

1. Log in to ARIN Online.
2. Select Your Account Organization Identifiers from the navigation menu.
3. Select an Organization Handle that is associated with your ARIN Online account.
4. If no Voting Contact is listed, in the Org Info section, select Actions in the lower right corner.
5. Select Manage Voting Contact.
6. Select one new Voting Contact from one of the following three options:

  • Appoint myself
  • Choose from eligible associated ARIN Online users
  • Appoint an ARIN Online user by email address

7. After entering or selecting the required information, choose Submit.

Voting in the ARIN Elections is an important responsibility granted to each ARIN Member organization. Each eligible ARIN Member organization, regardless of size, has one vote– making each ballot equally important. Participation in the ARIN Elections is essential to guiding the future direction of ARIN, it’s community and Members, and the Internet.

This year from 4 – 12 October, voters will help to fill two positions on the ARIN Board of Trustees, five on the ARIN Advisory Council, and one on the Number Resource Organization Number Council (NRO NC).

Don’t be left out this October, take the first step now and make sure your organization has a current Voting Contact on file by Monday, 20 August. You can also submit a nomination now through 31 July by visiting our nominations page.

For question or assistance, please email an ARIN Member Services team member at members@arin.net or call 703.227.9840, x834.

The post It’s Simple: Review, Update, or Designate an ARIN Voting Contact Today! appeared first on Team ARIN.

Posted on Leave a comment

The Path Forward – The Roadmap for ARIN’s New IRR

After receiving multiple ARIN Consultation and Suggestion Process (ACSP) requests to update our existing Internet Routing Registry (IRR), we opened two community consultations last year to see if the community wanted us to take on the project of improving this service and what that would look like. The response was clear. The community would like us to:

  • Improve the validity of the IRR data
  • Work with the other Regional Internet Registries (RIRs) on authorization schemes
  • Provide appropriate proxy registration services
  • Integrate/validate with the registration database

To accomplish these goals, we anticipate a need to work closely with the other RIR communities, IETF, and operational groups such as NANOG, in order to create the appropriate incremental upgrades to the IRR.

Our Current IRR

We initially set up a RIPE-based IRR several years ago. Over the years, we have upgraded it based on ACSP suggestions. While these upgrades did allow for additional functionality, it came at a substantial cost of time and unanticipated functionality issues related to the upgrades.

Some of the issues found in our current IRR include:

  • The RIPE codebase was not modularized, with significant dependencies on RIPE’s environment, and which was not ideal for use in ARIN’s environment.
  • Adjusting to each upgrade from RIPE has been challenging because of innate differences in our database structures.
  • Our Registration Services Department has challenges providing customer support to IRR users. Common problems include: Maintainers not being notified upon changes, Cryptic responses to pgp-validation errors, General lack of customer support features.
  • It was our hope that code re-use would save time and money. Unfortunately, this was not the case, and the result was an awkward, difficult-to-operate, and user-unfriendly system that requires considerable engineering time to maintain.

It should also be noted that the IRR codebase in use by ARIN is no longer supported or maintained by the RIPE NCC, as they have since completely rewritten their IRR software.

Our Proposed Way Forward

Given the past experience with reusing code for IRR software, we propose a “ground-up” implementation of a validated IRR that will better integrate with our current web portal, provisioning system, and other registry functions. This path forward will be a multi-phased approach and will rely on community–defined specifications and global RIR community consensus.

By incrementally introducing a routing registry, we will be able to provide utility to the community much sooner and provide the community an opportunity to give feedback on the features and cost as the project progresses.

We do feel that this effort, once deployed, will help improve the routing coordination that exists on the Internet today. The proposed new ARIN IRR will provide a clear and consistent path to allow ISPs to share their routing policies.

View the full document that contains the proposed changes for the new ARIN IRR.

The post The Path Forward – The Roadmap for ARIN’s New IRR appeared first on Team ARIN.

Posted on Leave a comment

The Path Forward: Introducing ARIN’s New IRR

After receiving multiple ARIN Consultation and Suggestion Process (ACSP) requests to update our existing Internet Routing Registry (IRR), we opened two community consultations last year to see if the community wanted us to take on the project of improving this service and what that would look like. The response was clear. The community would like us to:

  • Improve the validity of the IRR data
  • Work with the other Regional Internet Registries (RIRs) on authorization schemes
  • Provide appropriate proxy registration services
  • Integrate/validate with the registration database

To accomplish these goals, we anticipate a need to work closely with the other RIR communities, IETF, and operational groups such as NANOG, in order to create the appropriate incremental upgrades to the IRR.

Our Current IRR

We initially set up a RIPE-based IRR several years ago. Over the years, we have upgraded it based on ACSP suggestions. While these upgrades did allow for additional functionality, it came at a substantial cost of time and unanticipated functionality issues related to the upgrades.

Some of the issues found in our current IRR include:

  • The RIPE codebase was not modularized, with significant dependencies on RIPE’s environment, and which was not ideal for use in ARIN’s environment.
  • Adjusting to each upgrade from RIPE has been challenging because of innate differences in our database structures.
  • Our Registration Services Department has challenges providing customer support to IRR users. Common problems include: Maintainers not being notified upon changes, Cryptic responses to pgp-validation errors, General lack of customer support features.
  • It was our hope that code re-use would save time and money. Unfortunately, this was not the case, and the result was an awkward, difficult-to-operate, and user-unfriendly system that requires considerable engineering time to maintain.

It should also be noted that the IRR codebase in use by ARIN is no longer supported or maintained by the RIPE NCC, as they have since completely rewritten their IRR software.

Our Proposed Way Forward

Given the past experience with reusing code for IRR software, we propose a “ground-up” implementation of a validated IRR that will better integrate with our current web portal, provisioning system, and other registry functions. This path forward will be a multi-phased approach and will rely on community–defined specifications and global RIR community consensus.

By incrementally introducing a routing registry, we will be able to provide utility to the community much sooner and provide the community an opportunity to give feedback on the features and cost as the project progresses.

We do feel that this effort, once deployed, will help improve the routing coordination that exists on the Internet today. The proposed new ARIN IRR will provide a clear and consistent path to allow ISPs to share their routing policies.

View the full document that contains the proposed changes for the new ARIN IRR.

The post The Path Forward: Introducing ARIN’s New IRR appeared first on Team ARIN.