Approaches of Managing IPv4 Exhaustion. We re running out of IPv4 addresses and we still have a lot of use for them even with the

Jose F. Martinez Rivera Advised by: Ashwin Jacob Mathew TRUST REU University of Puerto Rico, Mayaguez Campus July 27 2012 Approaches of Managing IPv4 Exhaustion Abstract: We re running out of IPv4 addresses and we still have a lot of use for them even with the deployment of IPv6. To manage IPv4 remaining resources there are 2 main structures discussed, hierarchical and market models. Reading proposals and discussions in the ARIN (American Registry for Internet Numbers) community showed that the community rejects market models as a way to manage resources. Instead the community prefers the current hierarchal model because of its more administrative aspects. The decisions that the community makes, plays an important part on how the Internet number resources will be managed in the future. 1. Introduction On February 2011, ARIN (American Registry for Internet Numbers) 1 received its last allocation from the IANA (Internet Assigned Number Resources) 2 and currently the ARIN has 3.15 /8s left in its free pool. ARIN is the organization responsible for assigning IP addresses and other number resources to the North American region while the IANA is the global authority concerning number resources, in other words the IANA provides the resources to ARIN and 1 American Regional Internet Registry - https://www.arin.net/ 2 IANA About the Internet Assigned Number Authority - http://www.iana.org/about/

other regional based organizations. The ARIN free pool is the IPv4 address space that hasn t been assigned to any organization and as stated previously, only 3.15 /8s remain in the free pool. Before learning what a /8 is it is crucial to understand the function of an IP address. An IP address is how computers send information to each other. A good analogy would be an IP address as a house address, basically each house has an assigned address by which any person can mail a package to and vice-versa. In other words, with a house address people can communicate with each other through mail, so with IP addresses computers can communicate with each other but instead of mail they use packets which is a unit (package) that carries a form of data. For now think of a /8 as a block that contains 16.7 million IP addresses and we only have 3.15 /8 blocks left. It is clear that we re going to run out of IPv4 addresses a long time before we make the full switch to the IPv6 framework. The question now is how the Internet community, specifically the ARIN community, is going to address the IPv4 exhaustion. As we get closer to exhaustion the community might make decisions that could potentially have dire consequences or good benefits to the overall Internet community and Internet growth. The purpose of this paper is to see how recent events concerning IPv4 exhaustion has influenced the ARIN s PDP (Policy Development Process), which is ARIN s process towards developing policies, in other words how the community writes the proposals and what are the current stands towards market based transfers. The PDP usually begins with members of the community who propose an idea. If the proposal receives enough support it becomes a draft policy and it can eventually be adopted and implemented in ARIN s policies. By learning from our policy process mistakes is how we can establish a good list of policies for the IPv6 framework and see how we can manage our scarce IPv4 address space.

The NRPM (Number Resource Policy Manual) is ARINs policy guideline; it became available for public changes on 2004. Since 2004 there have been plenty of changes made in the NRPM. All the changes made can be seen on the NRPM Change Log 3. In 2006 there were at least 7 modifications to Section 6 IPv6. Transfers to specified recipients were enabled on 2009. Modifications to Section 4 were mostly seen in the policies related to allocations. The most recent change of Section 4 was on January 30 2012; interestingly enough on the same date IPv6 changes were made to policies regarding IPv6 allocations and assignments. Recently the new Section 8.3 has been modified as well. Basically the ARIN community seems to be changing the ways that we are allocating and assigning IPv4 and IPv6 address space as well as what requirements, rules or possibly transfer systems can be applied to Section 8.3 Transfers to Specified Recipients. 2. Background Since its establishment in 1997, ARIN (American Registry for Internet Numbers) has been responsible for managing the distribution of Internet number resources (IPv4 & IPv6 address space and ASNs) in the North American Region. The region covers Canada, United States and parts of the Caribbean. The ARIN is one of the 5 Regional Internet Registries (RIR): AFRINIC, APNIC, ARIN, LACNIC & RIPE NCC. AFRINIC covers the African continent and some parts of the Indian Ocean, APNIC is responsible for portions of Asia (China, India, etc.) and Oceania, LACNIC covers South America as well as portions of the Caribbean, RIPE covers Europe, the Middle East and Central Asia. 3 Number Resource Policy Manual Change Log - https://www.arin.net/policy/nrpm_changelog.html

The way Internet number resources are managed and distributed lies in the form of a hierarchy. The IANA (Internet Assigned Number Authority) is the organization at the top of the hierarchy. Jon Postel founded IANA in 1988 with the purpose of allocating Internet number resources and carrying on the administration of DNS root servers. Eventually the rapid growth of the Internet on a global scale turned out to be too much for just one organization. Consequently the RIRs were established to carry out a similar function of managing number resources but in the 5 main regions of the globe (North America, South America, Europe, Africa and Asia). Technically the IANA allocates Internet number resources to each of the 5 RIRs (ARIN, APNIC, RIPE, LACNIC, AFRINIC). In turn, each RIR distributes or assigns the number resources to an LIR (Local Internet Registry or an Internet Service Provider) and then the LIR to the end user. Before the ARIN was established, some IPv4 address space was assigned to critical infrastructures, important organizations and top universities of the USA. Between these was MIT (Massachusetts Institute of Technology), General Electric Company, Department of Defense, etc. These resources are considered legacy number resources because they were assigned before the ARIN was established. The issue with legacy number resources is the fact that they don t fall under a certain agreement and complete management under the ARIN. For example, every number resource after 1997 is under the management of the ARIN and its policies, but the legacy number resources sometimes are unaffected by policies of the ARIN because they have no direct agreement with the ARIN. Like any other organization that manages resources, the ARIN follows a policy manual. The ARIN s version of a policy manual is the NRPM (Number Resources Policy Manual). ARIN s policies are based on decisions made by the community, decisions which will determine the rules by which the ARIN manages and uses Internet number resources. The ARIN s process for

developing policies is called the PDP (Policy Development Process). The process begins through a policy proposal from anyone in the Internet community (this excludes members of the ARIN Board of Trustees and the ARIN staff). If the policy proposal receives enough support from the community and the ARIN AC it may become a draft policy and eventually it is incorporated into the NRPM. Since the community plays an important part in the policy development process, it is crucial to observe how the nearby IPv4 exhaustion is influencing the community to make these policy changes and figure out consequences that may come from these decisions. 3. Method The way policies are made requires a lot of debating and support from members of the Internet community. Therefore a qualitative approach was taken on the research. Since the goal was to observe the effects of IPv4 exhaustion on the proposal development process a great way to start was reading the ARIN Proposal Archive and picking out specific proposals related to IPv4, IPv6 and Transfers. ARIN s Proposal Archive contains all the formal proposals written by the community. Currently ARIN s Proposal Archive contains 178 proposals written since 2004 and 162 of these proposals had some connection to the IPv4, IPv6 and Transfers. Eventually a spreadsheet was made containing important details of the proposals that were relevant to the research, among these details the title, name of the author, date and proposal number were included. Eventually the goal turned into following the Policy Development Process (PDP). The process begins with a proposal suggested by a member, usually email discussions take place and members pick to support or oppose the proposal. Eventually the proposals are brought up in the ARIN meetings and these can be further developed into draft policies or abandoned completely. After reading all the proposals it was a good idea to read the mailing lists/threads related to each proposal that was related to the research and obtain arguments from the discussions concerning

each proposal. Once the arguments were obtained comparisons between early proposals were made based on recent proposals and the current NRPM to see how the IPv4 exhaustion is affecting how the ARIN Internet community writes and form proposals and what the community aims to do in the future. As mentioned earlier, I only read 162/178 proposals that were relevant to the research. The remaining proposals involved WHOIS and SWIP services which could probably be a good area for research involving ARIN s privacy policies. 4. Evidence Since the introduction of the proposal archive, there have been numerous of trends occurring throughout the years that the archive has been active (2004-present). These trends usually indicate which sections of the NRPM (Number Resource Policy Manual) ARIN members are either attempting change and/or simplify for a clearer understanding of what the NRPM is explaining. Some of these trends include how IPv4 exhaustion and possible market systems influence how ARIN members write and form their proposals. Currently, the main Sections of attention were Section 4 IPv4, Section 6 IPv6 and Section 8 Transfers. 4.1. Section 4 IPv4: Section 4 of the NRPM is about the policies related to IPv4. Among the policies are rules and requirements that organizations must fulfill to receive IPv4 address space. As well as goals that organizations with IPv4 address must meet, such as proper utilization of IPv4 addresses. An IP address is considered utilized if the address is used to send packets/communicate with other computers. Changes to Section 4 were quite common. The areas specifically targeted by authors involved:

Allocation sizes to subscribers after 12 months. (Section 4.2.4.4) Dedicated IPv4 block to facilitate IPv6 deployment. (Section 4.10) Section 4.2.4.4 currently states that if an organization has been a subscriber of ARIN for at least 12 months, then that organization may request up to a 12-month supply of IPv4 address space. When ARIN receives its last /8 from IANA then the organization may request a 3 month supply. Section 4.2.4.4 basically defines how much IPv4 address space an organization may receive at a time. Section 4.10 describes what actions ARIN will take when it receives its last allocation from IANA. First it will set aside a contiguous /10 IPv4 block for IPv6 deployment. Some of the uses given to this block will include dual-stack technology and NAT464 translators. Dual stack technology is basically a node that uses both an IPv4 address and IPv6 address to communicate between both protocols. The NAT464 translator is basically a node with an assigned IPv4 address and connected to this node are various computers that use IPv6. The NAT464 node will eventually be able to make the connection between IPv6 computers possible with IPv4 computers. The reserved /10 address block will have a minimum size allocation of a /28 (16 IP addresses) and a maximum size allocation of /24 (256 IP addresses). Section 4.2.4.4 originally allowed ARIN subscribers to receive allocation worth a 6- month supply. In 2007 some of the members of the ARIN debated that ARIN s policies for allocations differed from the amount of supply that other RIRs gave to their members, which at the time was a 12-month supply while ARIN only gave a 6-month supply. Proposal #55 4 focused on changing the policy to implement a 12-month supply for subscribers of one year, the intent 4 Expand timeframe of Additional Requests (2007) - http://lists.arin.net/pipermail/arin- ppml/2007- August/008473.html

was to create continuity among RIR allocations and assignments. Nearing 2009, 2 proposals where brought up: Proposal #93 5 and #94 6. Proposal #93 sought to change Section 4.2.4.4 by allowing the time period of supply to decrease dynamically as the IPv4 pool decreased. When ARIN receives it s last /8 from IANA, then the policy would come into effect and the allocation size would become (1/4) of the ARIN s free pool (as the free pool decreases, the allocation size decreases). Meanwhile Proposal #94 suggests that the subscriber time frame of supply should decrease every 6 months. The process starts on July 1, 2010 where the allocation supply is 9- month supply, on January 1, 2011 it becomes a 6-month supply and on July 1, 2011 it becomes a 3-month supply. Discussions lead to the merging of both proposals. Since Proposal #93 would take effect on the last /8 block assigned to the ARIN and the allocation size would keep changing dynamically, a possible consequence to this would be disaggregation, Proposal #94 suggested a steady decrease in the time period supply, but the community disliked the idea of rationing address space at such an early phase. Therefore, from the previous 2 proposals, Policy 2009-8 was formed. Policy 2009-8 states that on the day that last /8 is allocated to the ARIN, subscribers will only be able to receive a 3-month supply of IPv4 addresses. Recently, Martin Hannigan proposed a change to Section 4.2.4.4 in Proposal #162 7. Instead of applying the 3 month supply for allocations when ARIN receives its last /8 from the 5 Predicable IPv4 Run Out by Prefix Size - http://lists.arin.net/pipermail/arin- ppml/2009- June/014392.html 6 Predictable IPv4 Run Out by Allocation Window - http://lists.arin.net/pipermail/arin- ppml/2009- June/014392.html 7 Redefining request window in 4.2.4.4 - http://lists.arin.net/pipermail/arin- ppml/2012- January/024020.html

IANA the limit should be placed when the ARIN has exactly a /8 in their free pool. This idea emerged because of discussions in the community that revolved on how a previous policy (2009-8) forced rationing of the IPv4 address when there wasn t really a need for it. Stated in the thread of Proposal #162, the community does not like the idea of rationing IPv4 space while there was still a relatively large amount of space left in the ARIN pool. Since the proposal suggested rationing address space at the last /8, it was supported by most of the ARIN AC and the community. Shortly after, in 2012 the ARIN AC implemented the policy 2012-4. These proposals show the drastic changes being made in order to enable continuity among RIRs and to find ways to prevent IPv4 exhaustion and possibly extend the lifetime of IPv4, which may be an unwanted effect for Ipv6 deployment. Due to the IPv4 exhaustion and market system arguments, there is no doubt there will be more policies concerning how we ration our remaining IPv4 address space. It strikes me as odd that proposals directed towards the Section 4.10 (Dedicated IPv4 block to facilitate IPv6 deployment) are written in 2009; it is a long time to wait since IPv4 exhaustion was predicted years before 2009. It is probably one of the hardest sections to change because of the various opinions towards IPv4 exhaustion. The community and the ARIN Council agree that there has to be some reserved IPv4 space for critical infrastructures and for IPv6 deployment, but there s a continuous debate concerning reserved IPv4 address space for NAT translators. NAT is praised for enabling a considerably large number of users to access the internet, but NAT has some serious consequences, in some sense makes it harder for applications and software to be developed for NAT. NAT also opposes the end to end principle, because it serves as an intermediary node between the two users who are communicating with each other. A portion of the community supports the use of NAT64 translators because it could ease the

transition, but the main technology for transition that its widely supported is the dual stack technology, which could be used with NAT64 translators. The transformations concerning Section 4.2.4.4 and Section 4.10 makes it clear that IPv4 exhaustion is playing a key role in how members write and form their proposals. 4.2. Section 8 Transfers Section 8 of the NRPM describes the requirements of transfers and other possible events that may require number resource transfers. The main principle behind this policy is that number resources are not transferable to any other organization unless ARIN has approved the request for a transfer. It is also important to notice that number resources are never sold ; number resources are only assigned and therefore cannot be treated as property. In other words every transfer will be made under ARIN s supervision and approval, if the ARIN happens to see number resources assigned to an organization not previously registered then they can reclaim the number resource from the original holder. Recently Section 8 has been targeted by multiple proposals because of its very nature. It might be possible that the recent surge of proposal attempts might be due to the possible crucial role that transfers will play pre and post IPv4 exhaustion. The main subsection targeted is Section 8.3 (Transfers to Specified Recipients). Proposals and changes to Section 8.3 began around May 2011. Few changes were made to include ASN and other number resources as transferrable resources. One of the main arguments was concerned with legacy number resources and how they should be handled during transfers. Ted Mittelstaedt, in Proposal #148 8, suggests 8 LRSA resources must not be transferred to LRSA - http://lists.arin.net/pipermail/arin- ppml/2011- May/021861.html

that legacy number resources that are transferred should be placed under an RSA. Once the legacy number resource has been transferred then it becomes a common number resource and it falls under ARIN policies. The reason for this is that organizations, which weren t in the Legacy status, could obtain Legacy Resources and eventually contain number resources that don t fall under ARIN policies, it is technically a loophole. Since legacy number resources were assigned before the ARIN was established they currently have a status of having few policies that apply to this type of resource. The reason why Section 8.3 is so valuable is because of the function it can provide. Authors like Edelman (2010), discuss markets based on paid transfers, which can be regulated by ARIN. By slowly changing Section 8.3 it can eventually turn into a market system based on transfers, which could potentially be useful for IPv6 deployment and help ease the IPv4 exhaustion. The author, Scott Leibrand, in proposal #156 9, proposed inter-rir transfers, a technique that would be useful because each RIR is nearing IPv4 exhaustion at different rates. There are various proposals that received serious attention and sometimes even resulted in heated debates concerning how organizations could abuse the policies and about movements pro and anti market-based transfer systems. One of the discussions that came up involved Proposal #147 10. Proposal #147 enables any organization that participated in a transfer (this includes Specified Transfers and mergers & acquisitions) to receive a 24-month supply instead of the original 12-month supply. As with any argument there are 2 sides, Kaufman s rational 9 Update 8.3 to allow inter- RIR transfers - http://lists.arin.net/pipermail/arin- ppml/2011- August/022845.html 10 Set Transfer Need to 24 months - http://lists.arin.net/pipermail/arin- ppml/2011- May/021419.html

explains that organizations that participate in these transfers usually experience financial losses due to the transfer requirements and overall use of the addresses. In order to compensate the losses from the transfer, Kaufman suggests that the organization should receive a 24-month supply of transfer for planned growth. Owen DeLong argues that the 24-month time frame enhances fraudulent transfers and abuse. DeLong also states that organizations that use of transfers from 8.2 (Mergers & Acquisitions) should not be under the effect of this policy because the resources transferred would already be in use and these resources should ve already have justified need. Technically the problem here is the fear that the policy could be abused, but the ARIN AC found that the uses of this proposal would benefit the community and organizations with future planning of growth; consequently the proposal was made into a policy (2011-12), but in this version organizations that applied for a 24 month supply need to justify the need for it and show how the address space will be used. Possibly one of the earliest appearances of market-based systems in proposal threads was in Proposal #70 11 (2008), written by the ARIN AC. The proposal sought to establish a formal transfer policy that included requirements of both the transferor and the transferee. The main goal of this proposal is to enable transfers of swamp IPv4 space. Swamp IPv4 space is address space that organizations are holding and currently not using. The transfer of swamp space would be the only means of assigning IPv4 addresses to new organizations or to the ones who need the space after IPv4 exhaustion. 11 IPv4 Transfer Policy Proposal - http://lists.arin.net/pipermail/arin- ppml/2008- February/009978.html

One of the main fears among the community was ARIN s role after IPv4 exhaustion; Proposal #70 would make ARIN the central hub for transfers, which would mark a major change in ARIN s role in the Internet community. Even if the proposal originally didn t mean to establish a market, it would seem that if a market system based on transfers were to start, it would begin with this proposal. Since there is no actual incentive to return IPv4 address blocks, it would eventually force organizations into paying money for address space that belongs to other organizations, which would effectively lead to an IPv4 transfer market. Some of the authors in the threads discussed that organizations who return IPv4 address space for a decrease in the annual fee would be a possible incentive, but near the end of the IPv4 lifetime, keeping IPv4 address space and selling it later in a market scenario would be a bigger profit and incentive than a reduction of an annual fee. Other problems concerning the transfer policies appeared in the threads. Some of these issues concerned inter-rir transfer. It was argued that the North American region has a relatively large amount of legacy number resources and this should be transferred among RIRs. The main issue with inter-rir transfer is that Proposal #70 wouldn t be able to carry out such complicated transfers. From a perspective it d be applying local policies to a global policy, in other words the policy might work on a micro-scale but it is highly doubted that it would work on a macro-scale. Even if Proposal #70 might spark a market system based on transfers, all the authors agree that the needs based justification must be required because it promotes aggregation and reduces BGP routing table growth. Technically everything discussed up to now can be summed up in 2 arguments Leibrand: This policy proposal allows organizations to choose what's best for

them, rather than forcing a one-size-fits-all solution. 12 & Dillon: I disagree that this policy does what you say. In fact this policy is trying to set up a market for buying and selling IP addresses. 13 Leibrand appears to support market systems because they create incentive for organizations to return their space and at the same time it can maintain the requirements from the current NRPM. Dillon on the other hand is against the market system because he feels it will make the current policies a lot more complicated than it should be. He mentions that as organizations migrate there will be space for new organizations and possibly overextend the lifespan of IPv4. Eventually Proposal #70 was chosen for further debate and discussion and was labeled Policy 2008-2, but as a result of continuous debate it was abandoned on October 22, 2008. One of the biggest examples of how IPv4 exhaustion and market systems influence the proposals is Proposal #165 14 (2012), Eliminate Needs-Based Justification on 8.3 Specified Transfers. As the name states it would remove the requirement for organizations to prove how they will use transferred IPv4 address space within 24 months and if they have need for it or not. Jeff Mehlenbacher, the author of the proposal, suggests that the proposal would enable a free market economy. Mehlenbacher argues that current transfer policies create no incentive for companies/organizations to return IPv4 address space, so he turns to the free market economy and explains that it creates financial incentive for organizations to sell their space to other organizations. In the proposal s rationale it is also argued that the ARIN will continue its role as 12 http://lists.arin.net/pipermail/arin- ppml/2008- February/010005.html 13 http://lists.arin.net/pipermail/arin- ppml/2008- February/010008.html 14 Eliminate Needs- Based Justification on 8.3 Specified Transfers - http://lists.arin.net/pipermail/arin- ppml/2012- February/024118.html

the custodian of IPv4 addresses, but also as the main overseer of transfers carried out between organizations. In order to enable the participation of small organizations in the IPv4 community, the ARIN will use the free resource pool to assign resources to small organizations and encourage large corporations to participate in the transfers. Proposal #165 received a lot of negative feedback from the community because the needs based justification is highly regarded and thought as a needed tool to guarantee that an organization will use the assigned IPv4 space efficiently. In fact in the thread discussion, Owen DeLong stated We have asked this same question of the community several times over the last 5 years and each and every time, the community has expressed a clear desire to preserve needsbased justification 15, this quote explains how much the community opposes the market based system. Other members of the ARIN explained how the needs based justification helps keep the distribution of IPv4 address leveled instead of having large corporations controlling all of the addresses which would eventually happen if a market scenario were to take place. Since we haven t reached IPv4 exhaustion, we won t be sure if/when a market system is to be implemented, but up until now the majority of the community is opposed to market systems, meaning we won t be seeing a market anytime soon. 4.3. Section 6 IPv6: Section 6 deals with policies related to the IPv6 framework. It s a guideline to how the ARIN will allocate, assign and manage IPv6 address space. Issues and trends related to IPv6 tend to revolve around assignment sizes and HD ratio. The main issue related to the IPv6 framework policy involves the non-conservative approach that the ARIN is taking at assigning IP address 15 http://lists.arin.net/pipermail/arin- ppml/2012- February/024160.html

blocks. One of the problems concerning this non-conservative approach is the HD ratio requirement for additional assignments. In Proposal #15 16, Andrew Dul recommends that the HD ratio should be increased from 0.80 to 0.94 because it would require LIRs to have higher utilization of the assignments made to them. Dul explained: This policy would change the threshold for an LIR holding a /32 from approximately 11% to 51%. Basically it would require the LIRs to utilize their space at a greater ratio. The main goal is to stop large organizations from hoarding IPv6 addresses, the problem with large organizations hoarding all the IPv6 addresses may not be seen as a problem due to the enormous amount of IPv6 addresses available but eventually if the Internet community were to reach IPv6 exhaustion, they would come to realize that the past policies made a huge impact on the lifetime of IPv6. When it comes to IPv6 allocation a lot of proposals have been made, one of the first is Proposal #10 17, which sought too allow organizations who are eligible for ASN to be able to request an IPv6 allocation. If the same organization wants to receive more IPv6 address space then it should return its current block to receive a larger contiguous block. The proposal provides a great way to maintain aggregation and to make it easy for organizations to receive Ipv6 addresses. Proposal #18 18 had similar intentions but overall wanted to promote a more conservative approach by adding more requirements for organizations. Basically organizations under Proposal #18 needed to be an end-site, not an LIR and advertise 2 or more separate LIRs (or ISPs). It also turned the allocation size to a /48. Since the need for allocation requirements 16 IPv6 HD ratio - http://lists.arin.net/pipermail/arin- ppml/2005- May/003594.html 17 PI assignments for v6 - http://lists.arin.net/pipermail/arin- ppml/2004- December/003025.html 18 IPv6 Direct assignments to end sites - http://lists.arin.net/pipermail/arin- ppml/2005- August/003983.html

weren t needed for IPv6 back in 2004-2005, Proposal #10 and Proposal #18 were combined into Policy 2005-1 19. One of the recent proposals, Proposal #159 20, involved reserving tie down blocks for organizations that are planning to execute a long-term plan. If an organization explains and justifies the need for a long term plan with the use of IPv6 address, then the ARIN will reserve a /36 block for that organization and then it will assign a /48 to the organization from the same block. It seems like the intent is to keep maximum aggregation and to prevent the routing table growth that occurred with the IPv4 21 system. Discussions involving this proposal revolved around how users can abuse the current IPv6 policy in order to obtain an extreme amount of addresses. The way in which IPv6 policies are written and adopted are affected by the IPv4 exhaustion, but not in the same way that IPv4 and transfers are affected. In other words the effect of IPv4 exhaustion is more of an indirect approach. All the changes made to IPv4 will have some effect to IPv6 policies, for example if we add a market system to IPv4 addresses could this system eventually get adopted to IPv6? Only if it resulted in a successful manner to distribute IPv4 addresses. It s changes like the previous one that might have been directed to IPv4 policies but may also have an effect on IPv6 as well. One of the proposals that will have an effect on 19 Policy 2005-1: Provider- Independent IPv6 Assignments For End Sites - https://www.arin.net/policy/proposals/2005_1.html 20 I Pv6 Subsequent Allocations Utilization Requirement - http://lists.arin.net/pipermail/arin- ppml/2011- November/023762.html 21 Meng, X., Xu, Z., Zhang, B., Huston, G., Lu, S., Zhang, L.: IPv4 Address Allocation and the BGP Routing Table Evolution.

IPv6 are Proposal #123 22 and Proposal #127 23, these two proposals target Section 4.10. Since Section 4.10 plays a crucial role in the deployment of IPv6 it has a direct effect on how we will use IPv6 for the following years. For example Proposal #127 suggests reserving a /10 for NAT464 translators while Proposal #123 suggests reserving a /20 for critical infrastructures. The issue here is that part of the community favors Proposal #123 because it respects the end-to-end principle but it might not be a good path of action for overall transition. Proposal #127 has its pros and cons as well, the NAT464 makes it possible to maintain connectivity between IPv4 and IPv6, but it goes against the end-to-end principle and overall NAT systems have been considered as a mechanism to delay the real goal, which is make the transition to IPv6 as quickly and smoothly as possible. 5. Discussion Throughout the proposals there are various patterns concerning the changes in the NRPM (Number Resource Policy Manual) of the ARIN. For example in Section 4.1 of the paper, it can be seen that ARIN community originally tended to be non-conservative with assigning and allocating IPv4 addresses because of the large amount of space that was available back in 1997, but recently, 2010, they changed to a more conservative approach due to the IPv4 exhaustion and the diminishing ARIN free pool. The ARIN was founded in 1997 and the original version of the NRPM was incorporated in 2004, but it wasn t until 2009 that policies actually suggested transfers between organizations (that weren t related to a merge or acquisition). ARIN members 22 Reserved Pool for Critical Infrastructure - http://lists.arin.net/pipermail/arin- ppml/2010- November/018835.html 23 Shared Transition Space for IPv4 Address Extension - http://lists.arin.net/pipermail/arin- ppml/2011- January/019278.html

seem eager to establish good IPv6 policies based on what we learned from the IPv4 deployment, such as trying to maintain a reasonable amount of aggregation to avoid BGP routing table growth. It s the details like this that will have a noticeable change in how ARIN manages and distributes number resources. The current problem is IPv4 exhaustion; authors like Mueller (2010) and Dell (2010) argue how a market system can successfully ease the transition to IPv6. They decide to view IPv4 addresses as an exhaustible resource, meaning not everyone can have an IPv4 address (because of a low amount of addresses) but it is accessible to almost anyone who wants to, making it a common pool good. A common pool good is a resource that causes a sort of a competition between organizations because it is limited and exhaustible, it is also of low excludability meaning anyone can obtain an IP address. Furthermore like any good or resource it can be traded for incentive, in this case a market system based on transfers, which essentially lets organizations to trade IP address space for incentive because as IPv4 addresses are becoming scarce, organizations will want the space for Internet growth. The market system can be good because it creates incentive for organizations to actually return or sell their IPv4 address space but on the other side of the argument, large corporations would be able to buy off smaller organizations in order to obtain IPv4 address space. The problem with having just one corporation controlling all the IP address space is the fear of a monopoly of a resource that s supposed to be free and easily accessible to everyone who wants to become a part of the Internet. Perhaps one of the biggest surprises was how much the majority of ARIN s community has strongly disagreed with a market based approach to IPv4 exhaustion. In one of the email discussions, DeLong quoted: We have asked this same question of the community several times over the last 5 years and each and every time, the community has expressed a clear desire to

preserve needs-based justification 24 This clearly explains the Internet community s standpoint on market systems. When discussing organizations we must not forget the fact that in the community there are people who represent or work for these organizations. At times these members can speak on behalf of themselves or their company, which at times can be confusing because of possible underlying intentions. Basically, members of the ARIN community can either write proposals for the benefit of a particular group of people (organizations) or they can write proposals for the overall growth and well being of the Internet and community. Market systems are probably one of the major systems that could change the way we manage and distribute number resources. It would also change the entire structure of the Internet community. The author, Powell (1990) gave an insight of how a market system is one of the three models for management over resources. The other two forms are hierarchal, which is our current one and the network model. The Internet framework currently uses a hierarchal organization. ARIN allocates IP address space to ISPs & organizations, and the ISPs allocate these to end-users. Basically organizations that lie under the ARIN request resources only to ARIN and no other source. Even though ARIN s process of allocation might be a hierarchy, the ARIN s Policy Development Process works as a network model. The reason the PDP is a form of a network is because it requires support from the Internet community to actually carry out this process; this is sort of a cooperative and social structure. The reason why ARIN s PDP is so successful is due to the social and debatable aspect, it allows for flexibility of topics and ideas as well as discussion between different points of view to work on policies that the community can agree on. If the PDP was based on a hierarchy then practically only one person decides what 24 http://lists.arin.net/pipermail/arin- ppml/2012- February/024160.html

policies are implemented without consent of other members. Of course, other members can influence the opinion of the person on the top, but ultimately it s the group/person at the top that decides the policies that are implemented and adopted. Consequently this could turn into a dictatorship over the NRPM and number resource allocations. The PDP plays a major role in how IPv4 and IPv6 allocations requirements and sizes are decided upon, if the PDP was changed to a different management model it would probably have completely different allocation rules, if a hierarchal process was applied it could take an approach towards allocating IP address space to specific groups rather than fairly and evenly. In the case of a market system, the allocation system would probably benefit large corporations who buyout policy formation processes. Ultimately the Internet community decisions on IPv4 allocation sizes will determine IPv4 exhaustion timespan and the IPv6 deployment. It is possible that if the community decides to decrease IPv4 allocation sizes they might increase IPv6 allocations and supply just to convince organizations to switch to IPv6 where they can have a lot more space. Even though IPv6 might seem unlimited it will come to a point that hypothetical decisions will have consequences on IPv6 framework, consequences like IPv6 routing table growth and having huge amounts of unused IPv6 space owned by organizations that don t need it. This is why it is important to understand the influences that currently drive policy development processes and what approaches ARIN is taking towards IPv4 exhaustion. 6. Conclusion The Internet community plays an extremely important role in the policy development process. Our current system has been a good model because it allows debates between members

that may lead to good proposals and eventually good policies. This is due to the constant discussion and reviews by the community. Essentially the Internet community decides the policies for IPv4 and IPv6 allocations, so it is important to maintain our current model but learn from the mistakes made from IPv4. As we research more about ARIN, its policies and approaches towards IPv4 exhaustion, we will find a way to secure access to the Internet and the growth to the Internet, as well as further develop a trustworthy process to become part of the Internet community. Since this paper was only based on specific proposals, policies and email discussions related to IPv4 and IPv6 allocations and transfers there are a lot of other areas of research. Perhaps research on ARIN s WHOIS privacy proposals and at a larger scale the same process as this paper but with the other RIRs (RIPE, APNIC, LAPNIC, AFRINIC). There is a lot of material that is possible to expand the research.

References: 1. Clark, D. D. (1988). THE DESIGN PHILOSOPHY OF THE DARPA PROTOCOL ~ S The top level goal for the DARPA Internet Architecture, 106 114. 2. Dell, P. (2010). Two economic perspectives on the IPv6 transition. Info, 12(4), 3 14. 3. Denardis, L. (2010). The Emerging Field of Internet Governance, (Hargittai), 1 21. 4. Edelman, B. G. (2009). Running Out of Numbers: Scarcity of IP Addresses and What to Do About It. SSRN Electronic Journal. 5. Hain, T. (2005). A Pragmatic Report on IPv4 Address space consumption. The Internet Protocol Journal, 8(3), 2-9. 6. Hofmann, A., & Gerstner, R. (n.d.). Author Guidelines for the Preparation of Contributions to Springer Computer Science Proceedings. iram2012.org, 1 9. 7. Lehr, W. (2008). Running on empty: The challenge of managing internet addresses. Published on Communication, Information and Internet Policy (1 39). 8. Meng, X., Xu, Z., Zhang, B., Huston, G., Lu, S., & Zhang, L. (2005). IPv4 address allocation and the BGP routing table evolution. ACM SIGCOMM Computer Communication Review, 35(1), 71. 9. Mueller, M. (2010). Critical resource: An institutional economics of the Internet addressing-routing space. Telecommunications Policy, 34(8), 405 416. 10. Perset, K. (2007) Internet address space: Economic considerations in the management of IPv4 and in the deployment of IPv6. 11. Powell, W.W. (1990). Neither Market Nor Hierarchy: Network Forms of Organization. 12. Saltzer, J. (1984). End-to-end arguments in system design. ACM Transactions on Computer.