1. What Educational & Research Networks Need To Know About ARIN
Jon Worley, Technical Services Lead
I-Light
8 May 2019

2. Topics of Discussion ARIN 101 IPv4 Transfer Market IPv4 Waiting List
Getting IPv6
IPv6 Addressing Plans
RPKI/DNSSEC

3. ARIN 101
Established in 1997 as a nonstock corporation in Virginia, USA
Nonprofit – 100% community funded, fee for services, not number resources
Membership Organization – open, broad-based from private & public sectors and civil society
Community Regulated – Open and transparent, policies developed by community, member-elected executive board

4. Mission Statement
ARIN, a nonprofit, member-based organization, supports the operation of the Internet through the management of Internet number resources throughout its service region; coordinates the development of policies by the community for the management of Internet Protocol number resources; and advances the Internet through informational outreach.

5. ARIN Service Region
Region includes Canada, 25+ Caribbean and North Atlantic economies, & the United States and minor outlying areas

6. ARIN’s Educational/Research Representation
1 member of ARIN’s Board of Trustees
Nancy Carter, Treasurer (CFO of CANARIE Inc.)
1 member of ARIN’s Advisory Council
David Farmer, University of Minnesota
Consider running for office to increase representation!

7. What Does ARIN Do? IP address allocations & assignments
ARIN Online (customer web portal)
ASN assignments
Security (DNSSEC, RPKI)
Transfers
Community Software Project Repository
Reverse DNS
Record Maintenance
Operation Test & Evaluation (OT&E) Environment
Directory services – Whois, Whowas, RDAP…

8. IPv4 Transfer Policies Mergers and Acquisitions (NRPM 8.2)
Traditional transfer resulting from a merger, acquisition, or reorganization supported by legal documentation
Transfers to Specified Recipients (NRPM 8.3)
IPv4 market transfer from one organization to another that it specifies, supported by justified need (within region)
Inter-RIR transfers to Specified Recipients (NRPM 8.4)
IPv4 market transfer from one organization to another that it specifies, supported by justified need (between regions)
For many years, IPv4 addresses could only be transferred based on mergers, acquisitions, or similar – i.e. any situation where the network for which the IPv4 addresses were issued is still operating, there’s just a new name on the front of the building. The community ethic was that if you no longer needed your IPv4 addresses, you should return them to the registry to be issued to someone else.
As I mentioned earlier in the presentation, the community knew IPv4 depletion was coming. The community knew that when depletion occurred, those seeking IPv4 addresses and unable to get them from ARIN would find a way to get IPv4 addresses from organizations that no longer had a need for them. If no policy mechanism were available to recognize those transfers, the end result would be chaos. Whois would no longer be an authoritative way to verify registration information; instead, it would reflect the name of the old registrant, not the organization who obtained them and is now using them. To ensure that didn’t happen, a specified recipient transfer policy was created by the community. In essence, it allows anyone with IPv4 addresses (presumably ones they no longer need) to release them to another organization that needs them, but is unable to get them from ARIN due to IPv4 depletion. It’s important to note that ARIN’s only role in this process is to receive the request, verify it meets all applicable requirements, and record it in Whois. If anything outside that occurs – for example, payment made in exchange for the release of addresses – that’s not something we’re involved in. For that reason, we don’t talk about organizations buying and selling IPv4 addresses, because we have nothing to do with that. All we do is record the transaction.
Initially, specified recipient transfers were allowed only in the ARIN region. Some years after the first policy was implemented, the community created an inter-RIR transfer policy, which in essence is the same as the regular specified recipient transfer policy but for the fact that one of the organizations (either the one releasing the IPv4 addresses or the one receiving them) is located in another region and is working through another RIR.

9. In-Region Market Transfers
Source account submits the source transfer request via ARIN Online and provides:
resources to be transferred
recipient organization name
Recipient account submits a recipient transfer via ARIN Online

10. In-Region Market Transfers
Source and recipient tickets linked
$300 fee paid by source (waived if resources are under RSP)
Due diligence check to verify source is authorized to release the resources
If recipient is not pre-approved, verification of 24 month need done

11. In-Region Market Transfers
Upon approval, the recipient signs a Registration Services Agreement and pays any past due fees
ARIN Financial Services confirms receipt of RSA and any past due fees
Transfer is completed and both source and recipient are notified

12. Inter-RIR Transfers From ARIN
Source submits an inter-RIR source request via ARIN Online
ARIN verifies the source is authorized to transfer the resources
Upon approval, invoice for $300 transfer fee sent to the source organization (waived if under RSP)
Request sent to recipient RIR

13. Inter-RIR Transfers From ARIN
When ARIN receives approval from the recipient RIR, ARIN confirms the transfer date with the recipient RIR and waits for confirmation of completion
Upon receiving confirmation from the recipient RIR, ARIN completes the transfer and updates Whois
Notify the Recipient RIR and the ARIN source organization once the transfer process has been completed

14. Transfers Are Increasing
# Completed Transfers
1,104

15. Transfer Facilitators
ARIN allows registration of transfer facilitators (aka brokers)
ARIN does not provide any information other than contact info
Consider checking with other orgs if you want information about the broker

16. Most Specified Transfer Blocks Are Small

17. IPv4 Waiting List Requesters have the waiting list option
Initial /21 (ISP) or /24 (EU) with no justification
Larger blocks based on 24 month need
Requester may specify a smaller acceptable size
One request per org on the list at a time
Oldest requests filled first
Requests met by transfer are removed
We do get IPv4 addresses back via several methods, specifics of which we’ll discuss shortly. Ahead of IPv4 depletion, the community was aware ARIN would get IPv4 addresses back and created a waiting list policy to ensure we had an orderly way to hand out these blocks. To be added to the waiting list, you need to qualify for IPv4 addresses under one of ARIN’s current policies (meaning you can’t just ask to be added). Assuming you qualify, you’ll be added to the waiting list with the maximum block size you qualify for. You’ll have the option to specify the smallest block you’ll accept. As an example, if you qualify for a /22, you’d be able to tell us you’ll accept anything from a /24 to a /22. It’s important to remember you’ll only get one block to complete your request. Specifying a smaller acceptable block size will increase both the likelihood you’ll get a block via the waiting list and the likelihood it will be smaller than the block size you qualified for. Each organization may have only one request on the waiting list at a time. The oldest requests are filled first. We do break up blocks to fill requests; as an example, if the oldest waiting list request is a /24 and we get a /16 back, we don’t skip over the oldest request and keep going until we find someone who will accept a /16. We fill the oldest request with a /24 from the /16, then continue distributing what remains to the waiting list, and so on.
Just before the waiting list was implemented in July 2015, we decided it was important to make sure the whole waiting list process was very transparent. We didn’t want someone on the waiting list to think there was any possibility for someone to skip over them. For that reason, we decided to publish the entire waiting list, which is updated daily. We remove organization information (we can’t let the public know exactly who’s where on the waiting list) but each organization will be able to verify their request is on the waiting list with the appropriate maximum/minimum block sizes and track it as it moves up the list.
Now, the obvious question: will there be anything to fill waiting list requests, and if so, how much?

18. IPv4 Waiting List Growth
This chart shows the number of requests on the IPv4 Waiting List at the end of each month, starting with the time the first request was added to the waiting list in July Requests are removed from the waiting list either when they’re filled or when the requester gets IPv4 addresses via the transfer market, which automatically removes them from the waiting list. Again, the dashed red line represents IPv4 depletion. Note that the rate at which requests were added to the waiting list was fairly steady until we reached approximately 400, at which point it started to level out. We can theorize that just like most waiting lists, there’s a certain point at which people say “that’s too long to wait” and for us it appears to be around Note also that we’ve managed to reduce the size of the waiting list over the past few months. Much of that is due to returned and revoked blocks being made available to the waiting list and fulfilling requests. As we discussed earlier, our team is trying to get as much IPv4 space out there as possible, so while we can’t predict whether we’ll continue to fill waiting list requests at this rate, any positive movement is undoubtedly a good thing to the folks waiting patiently for a block.
Total size of the waiting list is one thing, but the key question remains: how long will it take me to get a block?

19. Waiting List Statistics
635 (55%) have been filled
Last request filled waited ~9 months
275 (24%) dropped off
Most got IPv4 via the transfer market
237 (21%) still waiting
Oldest added 23 Aug 2017
Of the 1,147 requests added:
Here are some statistics that may help guide your decision. Of the 563 requests that have opted to be added to the waiting list:
18% received a block. The most recent requests filled waited approximately 14 months to get a block. We don’t know whether that will change going forward, so if you’re opting for the waiting list, you need to be prepared for an indefinite wait. If you can’t wait that long, we’ll discuss other options later in this presentation.
20% dropped off the waiting list, mostly because they opted to get IPv4 addresses via the transfer market. As you might expect, when it’s taking about 14 months to fill requests from the waiting list, there are folks who decide it’s taking too long and go another route. The good news is that when those folks get space on the transfer market, our policies require them to be removed from the waiting list, which moves everyone else up a spot.
61% are still waiting for a block. The oldest of those was added 23 July 2015, meaning 18+ months spent waiting.
Here’s the bottom line: the IPv4 waiting list might be a good option if you can defer your need for IPv4 addresses indefinitely. If you can’t do that, you might want to look at the other options.

20. Requesting IPv6 - ISPs
Have a previous IPv4 allocation from ARIN or predecessor registry
Provide a plan which details at least 50 assignments made within 5 years
Intend to IPv6 multi-home OR
Simple policy – intended to allow anyone to qualify for a block OR

21. IPv6 ISP Block Size /48 typically assigned to customers
Might be smaller, e.g. /56, for residential
/48 typically assigned to customers
Enough to number 65k+ customers
May request /36 to keep fees low
/32 default generally sufficient
# of serving sites (PoPs, datacenters)
# of customers at largest serving site
Block size to be assigned
Larger blocks based on:
Policy removed the difficulties, qualifying is the easy part. You already know how many customers are served by each site.

22. Requesting IPv6 – End Users
Have an IPv4 assignment from ARIN
Intend to IPv6 multi-home
2000 IPv6 addresses or /200 IPv6 subnets used
Have 13+ active sites within 12 months
Technical justification showing ISP-assigned IPs are unsuitable OR OR OR OR

23. IPv6 End User Block Size 1 /48 2-12 /44 13-192 /40 193-3,072 /36
Number of Sites
Block Size 1
/48
2-12
/44
13-192
/40
193-3,072
/36
3,073-49,152
/32

24. Subnetting: IPv4 vs IPv6
The IPv4 mindset: think in terms of IP addresses
“If a site has 50 devices, I give it a /26”
The IPv6 mindset does not work for IPv6
Last 64 bits used for device autoconfiguration
…and we have a ton of IPv6 addresses
The correct IPv6 mindset: think in terms of subnets, not addresses

25. IPv6 Subnetting – NANOG BCOP
Each individual network segment gets a /64
A /64 can hold a near-infinite number of devices
Subnet on nibble boundaries for DNS
/48, /44, /40, etc.
Addressing plans should be hierarchical, with each level using subnets of the same size
Each site gets a /48
Customers generally get a /48
PoPs/aggregation points sized based on largest

26. IPv4 Address Plan: End User
Enterprise
Network
/23
/19
/24
/24
SJC Hub
14 sites
/27 for each
448 IPs
CHI Hub
15 sites
/28 for each
240 IPs
DAL Hub
8 sites
/28 for each
128 IPs
ASH Hub
156 sites
/27 for each
4,992 IPs

27. IPv6 Address Plan: End User
Enterprise
Network
/40
/40 (256 /48s)
/40
/40
SJC Hub
14 sites
/48 for each site
CHI Hub
15 sites
/48 for each site
DAL Hub
8 sites
/48 for each site
ASH Hub
156 sites
/48 for each site

28. (1 IP each) 4 biz customers (/29-/24)
IPv4 Address Plan: ISP
FTTH ISP Network
/22
/21
/23
/24
Saskatoon Hub
952 home users (1 IP each)
5 biz customers (/29-/24)
= 1,952 IPs
Prince Albert Hub
214 home users
(1 IP each)
= 214 IPs
Moose Jaw Hub
497 home users
(1 IP each)
= 497 IPs
Regina Hub
497 home users
(1 IP each) 4 biz customers (/29-/24)
= 997 IPs

29. IPv6 Address Plan: ISP FTTH ISP Network Saskatoon Hub
/36
/36
/36
Saskatoon Hub
1,027 total users (home + business)
= 1,027 /48s
Prince Albert Hub
214 total users (home + business)
= 214 /48s
Moose Jaw Hub
497 total users (home + business)
= 497 /48s
Regina Hub
506 total users (home + business
= 506 /48s

30. Anatomy of an IPv6 Address
2001:0DB8:3007:000A:B9D3:284A:83E2:90DB
/32 from ARIN
Hub /36
0 = Saskatoon
1 = Pr. Albert
2 = Moose Jaw
3 = Regina
4 = Future Hub
... etc
Site /48
001 = Regina Site 1
002 = Regina Site 2
....
007 = Regina Site 7
Subnet /64
0001 = Subnet 1
0002 = Subnet 2
....
000A = Subnet 10
Device /128
Autoconfigured
with MAC Address

31. Resource Public Key Infrastructure (RPKI)
Functionally similar to an Internet Routing Registry (IRR)
IRRs contain route objects which associate a given IP block with an origin AS
RPKI equivalent: route origin authorization (ROA)
Adds cryptographic authentication to ensure the data hasn’t been tampered with

32. Using RPKI Hosted RPKI recommended Generate a ROA request key pair
Submit your public key to ARIN
Generate ROAs via the website

33. DNSSEC Increases DNS security
Cryptographically verifies the response from the DNS server hasn’t been tampered with
More useful for forward DNS, but why not add reverse while you’re at it?
DS records you provide to ARIN point to DNSKEY records in your nameserver

34. Using DNSSEC
Make sure you have access to your organization’s records via ARIN’s website
Use your DNS software to generate the required records
Upload the DS records to ARIN via our website

35. Questions?