Instructions:
1. This Trip Assessment form will be automatically associated with its related Proposal; therefore, no duplicate traveler identification information is required.
2. You must be logged in to the Community Wiki with a valid Username and Password in order to complete forms within CROP.
3. Trip Assessment must be complete within three (3) weeks of all travelers having returned from the event, no later than the assessment due date which is automatically calculated based on the trip return date.
4. Multiple travelers are asked to collaborate as a team in pulling together the appropriate information.
5. To fill out the the form, click 
(top of the screen).
6. Answer each of the questions that appears within the form. Use the scroll bar (right) to reveal all contents. Click here to read the full instructions
| Assessment Status |
APPROVED |
Trip Assessment Form | |
|---|---|
1) Describe the Trip in sufficient detail | ARIN47 was a meeting of the American Registry for Internet Numbers discussing policies regarding the assignment of IP addresses within ARIN region (which mostly overlap’s with ICANN’s NARALO region). During this meeting, proposals made to the ARIN community (with input of the advisory council) are discussed, and voted upon upon by members attending the sessions before being sent to the board for final resolution. As a NARALO representative, my goals were to familiarize myself with ARIN operation, push for policies supporting Internet End-Users, help define and vote on policies regarding the deployment of IPv6, and help define paths regarding the transition of IPv4 to IPv6. In this role, I spoke on my positions regarding the difficulties deploying IPv6 in the real world, difficulties with end user and SoHo businesses in obtaining provider-independent address space, access to BGP, and other roadblocks regarding v6 allocation. Additionally, I wanted extend awareness of ICANN and NARALO to those new to ARIN, the interdependence of IP address space, and DNS, provide understanding of the differences of IPv6 deployment vs. IPv4 deployment, and make new connections between the NARALO and ARIN communities. |
2) Describe the details of your attendance | ARIN43 was organized as a single track meeting with an initial newcomers orientation, followed by a review of RIR policies across the globe, IP usage statistics, and differences in policies between regions. This was followed up by a review of policies proposed to the ARIN Board (listed below) in which I provided as much input as possible, and closing with a summary on ARIN’s financial status and current state/projects. I attended all sessions and social events at ARIN43 aside from the Women’s Networking Forum. Throughout the conference, I was actively live-tweeting from the sessions under my handle @fossfirefighter with the hashtag #ARIN43. The following policies were discussed over the two days, with my comments and notes following: Starting from the beginning, the following information was covered; these was procedural reports from various ARIN sponsors and community members and did not have panels for discussion. This is summarized from my notes and the ARIN transcripts: Sponsor Updates RIR Updates: Advisory Committee On-Docket Items --- Policy Experience Report: Provides feedback to the ARIN community on policies that may not be working as expected, identified gaps or inconsistencies, customer feedback, and ideas towards new policies. The ARIN community is tasked with deciding if a policy change is necessary, or if things should be listed in place. Questions asked are noted directly below: Two policies were listed in the PER: I did not have a direct opinion on either policy, but asked a clarifying question to better understand the current state of 4.10 address space. From the transcript: “Michael Casadevall: Do we have current statistics on what is currently available in the 4.10 pool and projections towards exhaustion since that, I think, would influence the policy decisions? John Sweeting: Yeah, I'm going to give that in the RSD department update. I believe it's somewhere around 98 percent of that pool is still available.” --- IETF Report Cathy Aronson summarized current work in the IETF regarding IP space developments and discussion. She covered the following topics in brief: During the open floor, I asked if there were any discussions on possibly using Class E address space to help provide new transition methods for IPv4<->IPv6. Transcript below: “Michael Casadevall: This might be a slightly touchy subject, but has there been any discussions on possibly opening up the last remaining blocks of IPv4, the Class E space, for future transition five to ten years down the line? Cathy Aronson: No. Because -- well, there have been discussions. But the thing is that the amount of time it would buy us pitched against the amount of engineering and host changes it would take, it's just not worth it. I mean, that's basically -- Robert Seastrom: What Cathy said, we discussed that even for private space 10 years ago, and it got no traction because too much effort. John Curran: Right. There's been at least two Internet drafts that talk about that that were discussed in the IETF, both of which were panned by that community. There have been drafts suggesting that to the IETF; both were panned in the IETF community.” --- After the initial reports, the conference shifted to covering policy proposes in which I had the most input in. I’ll cover these in the order they were presented, and my votes for each item: Recommended Draft Policy ARIN-2018-2: Clarification to ISP Initial Allocation This policy provides clarification on how ISPs can obtain initial address space up to a /21, the size of their allocation, and guidelines for ISPs that already have blocks. In effect, this policy would make it easier for new ISPs to get their IP space, as well as allowing them to automatically get at least a /24. It also clarified that ISPs receiving blocks via transfer would be treated the same as though it received a direct allocation from ARIN. I voted in favor of this policy as it reduces the bar to entry for new entries into the market. Community votes were 108 present with 40 in favor, and 0 against. --- Recommended Draft Policy: POC Notification and Validation Upon Reassignment or Reallocation Summarized, this policy change is to require that any organization that receives a reassignment or reallocation must both be notified and validated before any such request will be processed by ARIN. The current situation allows for ISPs to assign blocks without validated point of contact information, and has lead to inaccurate or invalid information in WHOIS. I spoke in favor of this policy: “I want to speak in support of this policy because having up-to-date and accurate POC information is incredibly valuable when dealing with network DDoS attacks or bad traffic of determining who owns a block, who to contact and being able to help mitigate issues from point to point. So the Whois is incredibly valuable, and more accuracy goes a long way.” I voted in favor of it, the vote total was total participants 113, in favor: 41 against: 1. --- Recommended Draft Policy ARIN-2018-5: Disallow Third-party Organization Record Creation Summarized, this policy change disallows third-parties to create point-of-contacts for organization that receive simple allocation blocks. Instead, each organization must have an authorized representative create the PoC via ARIN’s tools. The hope is to decrease the number of organization ids in the database, or organizations that have no awareness of holding ARIN resources. I was tentatively supportive of this policy as having accurate WHOIS information is important in contacting networks generating bad traffic, but was concerned for those who operate as contractors or “third-party” helpdesks would have additional barriers to entry. I spoke at the mic to this effect: “I'm tentatively supportive of this policy as written, but I have concerns for companies that manage other companies' properties. For example, it is not uncommon for one company to completely manage all aspects of another customer's networks IP allocations, so forth and so on. And this would create a -- this currently can be an entirely transparent process since organization one can create and manage all the resources for organization two. This would add some burden to that, and while it may be relatively straightforward to create an Org ID, it may adversely impact those that act as a middleware for clients, especially those that are grabbing a bunch of IP blocks and releasing them because of demand scaling up and down. So I have tentative -- I have concerns about this.” Owen DeLong, member of the advisory council directly addressed my concerns as follows: “Owen DeLong, independent contractor and member of the ARIN AC. Yeah, I've done a lot of the kind of contract work he's talking about. And I've got a lot of clients as well. And we discussed this actually on the Mailing List. It was pointed out by ARIN staff that, as written, the policy would be implemented such that if you are able to create the Org ID with the proper documentation showing that the Org in question has authorized you to do that on their behalf, you're fine. So you're going to need some form of documentation from your client that says, yeah, this guy's authorized to interact with ARIN on our behalf, but that should not be hard to obtain if you're legitimately operating with ARIN on their behalf. So I think it's actually a solved problem. I don't think that there's a need for changes to the policy text or acrobatics to address it.” --- ARIN-2018-6: Clarify reassignment requirements in 4.2.3.7.1 The policy in question intends to simplify requirements related to “simple” reassignment vs “complex” reassignment. As policy is currently written, it is unclear when a simple reassignment is sufficient and many transfers are doing complex reassignments when unnecessary. It was also raised During the discussion phase of this proposal, a lengthy discussion followed on how this problem case deals with customers not capable of managing their own IP space. I found the problem statement and that usecase to be invalid, and raise that concern during public discussions: “Michael Casadevall: I dislike the proposal for several reasons. The first one is the example of the [havoc] system that requires a stack IP and only having customer name. For someone to have a block of routable IP addresses, they need to be responsible for it. And the concept of the customer is not smart enough to manage it, I don't think that's a valid argument, because if you're going to have stack IP space, you need to be able to manage it, or have someone manage it for you on your behalf. In addition, limiting the amount of information about transfers could both lead to abuse of people's hoarding IP blocks via shell games and other -- the lack of transparency is extremely concerning. Having more detailed information about how blocks are being assigned to individual customers is very important for dealing with tracking down DDoS, sources, botnets and other information. So moving -- allowing simple transfer, simple reassignment for these sort of things removes clarity into how ISP networks are delegating their networks, and the detailed information should be the standard way to do it, in my personal opinion. Paul Andersen: I understand you're against the policy statement, clearly. Are you also against the problem itself being solved? Michael Casadevall: Personally, I'm not sure I see it as a problem. If anything, I would completely flip this policy on its head and require detailed information for all reallocations except for those that are being directly broadcast and routed by BGP, in which case that organization has the POC and is responsible for that network because they're doing the announcement on BGP.“ --- Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements In short, this policy dealt with fixing the minimum and maximum allocations of an IP allocation; specifically, raising the minimum to a /24, and reducing the max to a /21 for waiting list IP space. Allocations smaller than a /24 are unusual as they’re not BGP routable, and ARIN internally can’t handle these type of requests as of writing (a full /24 for is allocated even if a smaller block is requested). I spoke up to at the mic stating that although smaller blocks are unusual, if a customer is fully aware of the consequences of using said block size, these requests should be allowed in light of IPv4 exhaustion as you can fit in multiple smaller blocks within a /24. --- Economic Factors Affecting IPv6 Deployment This was an open panel going into details about why IPv6 deployment is very slow as looked from an economic point of view. As described, NAT and RFC1918 drastically increased the longevity of IPv4, and many of the unique features of IPv6 such as SLAAC and IPSec were implemented one way or another in IPv4. As such, this helped reduce motivation for deploying IPv6. Things are also further complicated by the fact that one can’t simply just deploy IPv6; backwards compatibility with IPv4 remains essential. I commented on my own experiences in trying to get customers onto IPv6, including difficulties in getting provider independent space, and BGP broadcast announcements. --- Day 2 RPKI RPKI (Reverse Public Key Infrastructure) BGP is designed as a method to verify routes and prevent hijacking via securing announcements through certificate management. All five RIRs run RPKI infrastructure (with the root key known as a TAL, similar to the root key KSK ICANN manages), although ARIN (due to US legal requirements) has a click through license to get it’s public key which has drastically reduced deployment in the region of RPKI deployment. It is an alternative to the BGPSEC proposal (which fully encrypts BGP traffic) Current work is being done to try and lift these legal barriers and allow the ARIN CA to be automatically included with BGP software. Several ISPs such as AT&T and Google are now validating routes according to RPKI. Currently, Penn State has been contracted to determine how to improve the RPKI situation for ARIN. I brought comments relating to liability caused by making the key difficult to access, and also compared the situation to browser CA stores and how they manage liability risk. --- ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers The first policy proposal of the day was discussing aligning IPv6 transfer policies to be in place with those of IPv4. As the rules are written, only RIPE NCC allows for out of region transfer of IPv6 blocks. An argument was also made for RPKI, due to the previously mentioned issues with deploying the ARIN key en-massWhile I was initially neutral on this proposal, the discussion swayed me towards a negative view. Michael Casadevall: Michael Casadevall, NARALO. I'm currently neutral on this policy. While I can see a valid use case for mergers and acquisitions of bringing all IPv6 under a single umbrella, I'm somewhat wondering about the need and logistical overhead, given that most of the IPv4 transfers, especially across regions, is to deal with the fact that exhaustion and moving of v4 blocks -- the v4 blocks are very valued commodity while we have lots of v6 address space. So I'm looking at this and I'm trying to see if there's a real upside versus being able to consolidate because it means that then when you look at the blocks allocated to each RIR, you'll have IP addresses within those blocks that then exist in a different RIR, and it sort of muddles which IPs actually belong to which region. And I worry of opening Pandora's box here. Paul Andersen: I know you're neutral on the policy, but do you have a view on the problem statement, whether it's a problem that should be solved? Michael Casadevall: I'm currently neutral because I'm not hearing a strong use case. I'm not against it, but I'm not for it either. David Farmer: So, hearing you, I think I hear you saying probably those other use cases are important if we're going to further consider this? Michael Casadevall: If it's strongly important that v6 resources need to be transferred and those use cases are valid then I would support the policy as written. I'm hesitant that the use cases are valid. I'm not sure that type of consolidation really is all that important. And you deal with the risk of basically carving up the / -- I don't remember the size of [R1] has and their allocation to /12 becomes very messy instead of having it in organized blocks that we currently have it in. David Farmer: Thank you. Inter-regional transfer was only allowed for IPv4 in light of exhaustion. Furthermore, IPv4 doesn’t support route building so seperating out /48s to different internet point-of-presence would unbundle routes and bloat up the region table. Furthermore, allowing RIR transfers would allow for forum shopping for IP block space and gaming of the RIR policies which made me feel that allowing inter-region transfers was a very ugly can of worms to open. There may be worth an exception for an organization that is entirely leaving the region, but I could not support the policy as written. --- 4.18 Potential Policy Actions ARIN 4.1.8 handles the waitlist of IPv4 blocks and allocations for new blocks (this is separate than 4.10 space used for the allocation of clients that are deploying IPv6 and need blocks to get started). The discussion was framed around weighing various pros/cons of various solutions. Among those described were the following: For my end, I advocated towards moving 4.1.8 space into 4.4/4.10, and then increasing 4.10 allocation space to push up pressure on organizations deploying IPv6. --- ARIN-2019-2: Waiting List Block Size Restriction Discussion on changing the size of the max allocation on the waitlist. Currently one can wait for any size block and be issued it if/when it becomes available; I favored reducing the issuance size with again putting pressure on deploying IPv6. The remainder of the conference covered ARIN’s status and finances, and board elections. I did not actively participate in these sections. |
| 3) Explain the specific plans for follow-up activities to enhance and continue the objectives of the trip for the community structure through which you were approved for the trip: | Following the end of ARIN43, I've become to actively monitor and watch the ARIN policy mailing list in hopes of being able to influence and comment on policies that affect me, and the NARALO region. I'm hoping in early May to start work on a new policy proposal to help focus companies onto moving towards IPv6 by creating greater incentives to move such as limiting the block size that can be received. I also intend to follow this up with demos and documentation at my local infosec groups discussing IPv6, and the differences related to rollout, as well as following up with the contacts I made to help further develop my understanding of ARIN policy and perhaps work within NARALO in helping in providing training and information on why deploying IPv6 matters. |
| 4) Please fill out the date when you have completed this form: | 25-Apr-2019 |
Note: To be completed by a Program Coordinator (PC) designated by this organization/structure.
| Acknowledgements | Confirmed? | Who Confirmed? | Date of Confirmation | Notes |
|---|---|---|---|---|
| The Trip Assessment information has been gathered and properly entered into this form. | Yes | Glenn McKnight | 29-Apr-2019 | I don't see any lists of interested names to followup for NARALO membership |
| The ICANN Organization / Structure's leadership has authorized the submission of this Trip Assessment. | Yes | Eduardo Díaz | 29-Apr-2019 | |
| =============== | ========== | ============================== |
CROP Trip Assessment Template (June 2018)
