ARIN XVI Public Policy Meeting
Minutes
Day 1 - October 26, 2005

Meeting Called to Order

Speaker: Ray Plzak

Ray Plzak opened the meeting and welcomed those in attendance.

Ray began the first day of the ARIN XVI Public Policy Meeting at 9:09 AM PDT by introducing those present from the ARIN Board of Trustees, the ARIN Advisory Council, and the Number Resource Organization (NRO) Number Council. He also acknowledged those colleagues from the other Regional Internet Registries (RIRs) in attendance and introduced ARIN's directors. Ray noted that David Conrad had resigned from the ARIN Board of Trustees to take a position with the Internet Assigned Number Authority (IANA) as its General Manager.

He continued on with the following announcements:

• 195 total attendees, including approximately 87 first-time attendees.
• ARIN XVI attendees represent 26 U.S. states and the District of Columbia, 4 Canadian provinces, and 16 other countries.
• Thank you, ARIN XVI terminal room and network connectivity sponsor: Equinix

Ray reviewed the meeting agenda and the printed materials given to each attendee.

At the beginning of the meeting, approximately 123 people were in attendance.

John Curran, as Chairman of the Board, moderated discussions throughout the day.

[ARIN offered the opportunity for remote participation throughout the meeting. Comments from remote participants were read aloud at the meeting and are integrated into these meeting minutes.]

Regional Policy Updates

Speaker: Einar Bohlin, ARIN Policy Analyst

Presentation: PDF PPT

Einar Bohlin presented a summary of policy developments and discussions in the other RIR regions. Common policy issues among the regions include:

• IPv6 Allocations – IANA to RIRs
• Changes in IPv6 policy within RIR regions
• Deprecation of ip6.int

Einar provided specific details about policy developments and discussions within each RIR region in his presentation.

Internet Number Resource Status Report

Speaker: Leslie Nobile, ARIN Director of Registration Services

Presentation: PDF PPT

Leslie Nobile presented a joint RIR report on the current status of all IPv4, IPv6, and Autonomous System number resources as of September 30, 2005. This report is updated several times per year by all the RIRs and provides up-to-date statistics on rates of IPv4, IPv6, and AS number consumption.

AfriNIC Report

Speaker: Adiel Akplogan, AfriNIC CEO

Presentation: PDF

Adiel Akplogan presented the report on AfriNIC's activities.

Highlights:

• AfriNIC 2 meeting was held at the end of April this year, and included participation by about 80 people representing areas all around the AfriNIC region and including representatives from the other RIRs, ICANN, and the NRO NC. The meeting included the election of the first AfriNIC representatives to the NRO NC, policy proposal discussions, and the adoption of a fee schedule and budget for 2005.
• Training within the region is proceeding with the development of a bilingual training program that will include ten training sessions during a year. Seven training sessions have taken place so far in 2005, with around 90 participants from more than fifteen countries. There are three more sessions planned this year.
• AfriNIC's international community involvement has increased, with milestones such as full participation in the NRO NC by the elected representatives from the AfriNIC region. AfriNIC now takes part in the NRO as a full member and participates in all NRO activities, and actively participates in WSIS discussions.
• Special AfriNIC initiatives include working with NREN to support some IP-related work in African universities and the launching of the v6Mandela network, which is a project to educate the AfriNIC community about IPv6 and ease the sharing of experiences around the continent.
• Ongoing development of member web interface (MyAfriNIC).
• Working on deployment of WHOIS mirrors in Cairo and Cape Town.
• Next meeting is AfriNIC 3, to be held in Cairo, Egypt from December 11-15, 2005. The meeting will be collocated with AfrIPv6 event.

APNIC Report

Speaker: Paul Wilson, APNIC Director General

Presentation: PDF PPT

Paul Wilson provided an update on APNIC activities.

Highlights:

• Helpdesk now features live text-based chat and extended hours. VOIP will be coming soon.
• Projects include: an effort to “de-bogonise” new and recovered addresses, with the aim of detecting and reducing filtering, blacklisting, etc.; ICONS – an ISP support website.
• New technical services include the addition of online voting to MyAPNIC, a "lite" version of MyAPNIC, implementation of policy proposals, and greylisting of APNIC mail to reduce spam. Additional enhancements include more root server deployments and the collocation of critical services supplied from APNIC offices in Brisbane.
• Other activities include operating a certification authority for member authentication and involvement in issues surrounding Internet governance.
• Next meeting is APNIC 21, to be held with APRICOT 2006 from February 22 to March 3, 2006, in Perth, Australia.

LACNIC Report

Speaker: Raúl Echeberría, LACNIC CEO

Presentation: PDF PPT

Raúl Echeberría presented an update on LACNIC activities.

Highlights:

• The allocation of IPv4 has increased both considerably in the number of allocations and in the amount of addresses allocated.The interpretation is that it shows the growth of the Latin-American market.
• LACNIC leads the work in promotion of IPv6 in the region. Strategy based in 5 keystones: facilitation of adapted policies; fee waivers; research funding; promotion; and training.
• As of September 7th 2005, 44 IPv6 allocations have been made in the LACNIC region since 2001.
• Other recent or upcoming activities include a new cooperation agreement with NIC Brazil, moving into new facilities for 2006, and the publication of a newsletter, LACNIC News. First issue was published June 2005, with the expectation of three issues a year.
• Next meeting is LACNIC IX, taking place May 22-26, 2006. The location has not yet been determined.

RIPE NCC Report

Speaker: Axel Pawlik, RIPE Managing Director

Presentation: PDF PPT

Axel Pawlik presented an update on RIPE NCC activities.

Highlights:

• A new policy development process has been put in place and took effect September 1, 2005. It should be easier to understand where proposals are in the process and all current proposals that were under consideration have been moved into the appropriate slots within the new process.
• RIPE NCC has been developing an online learning portal, which will be available at http://e-learning.ripe.net, and will be launched on November 1, 2005. When launched, it will feature a module on using the WHOIS database, and in the first quarter of 2006, a module explaining the policy development process will be added.
• Overall, training materials have all been revised, including a new LIR course, and new courses on the Routing Registry and DNSSEC. A course titled "DNS for LIRs" is currently under development.
• Membership liaison activities include RIPE NCC Regional Meetings, which feature revised agendas and a more compact, RIPE NCC-centric agenda. One was held in Moscow in mid-September, and another is scheduled for January 2006 in Qatar. Another membership liaison activity was the member survey, where results showed a rating of 5.64 on RIPE services, within a scale of 1 to 7, and additional analysis of the results of this survey will help guide future planning.
• Next meeting will be RIPE 52, taking place in April 2006, in Istanbul, Turkey.

The Future of IPv4 - Roundtable

Moderator: John Curran

Speakers: kc claffy,Tony Hain, Geoff Huston, Thomas Narten

John Curran began by explaining that this roundtable session was intended to get people to "step outside the box" and look at IPv4 overall and discuss if there are any major factors that are close enough on the horizon that we may have to think of new policies or techniques. He added that this is the first of what he sees to be many such sessions. Each of the roundtable participants presented slides.

Tony Hain, Cisco Systems, Technical Leader
"IPv6 Deployment – IPv4 lifetime Exhaustion sooner than expected?"
Presentation: PDF PPT

Highlights:

• Looked at data and predicts IPv4 space will be depleted sooner than Geoff Huston predicts. Tony’s predictions are based on different data than Geoff uses.
• Since 2000, the number of /8s per month has been on a steady accelerating curve. IANA allocated 22 /8s in the 18 months between January 1, 2004, and July 1, 2005.
• If you go to a flat rate of three-quarters of a /8 per month, seven years of IPv4 space remains. If you hold at the inbound rate to the RIRs and the outbound rates from IANA, it’s about one /8 per month and five years of IPv4 space remaining. A compound consumption growth rate depends on the compounding factor.

kc claffy , Cooperative Association for Internet Data Analysis (CAIDA)
"apocalypse then”: ipv4 address space depletion
Presentation: PDF

Highlights:

• Asked how we innovate architecturally and how we leave the Internet better than we found it.
• If allocations continue at the current rates, IPv4 space will be depleted in 2008. However, it is unwise to assume the current rates would continue.
• The data being used isn’t what’s needed to predict the future of IPv6 uptake in the U.S., where there hasn’t yet been a strong policy focused on moving to IPv6.
• Other regions are already using IPv6 and therefore aren’t as concerned with the problem of IPv4 depletion.
• Innovation requires capital. Ironically, the capital for innovation comes from where innovation is happening. In order to make the world safe for innovating, the ones who need to innovate don’t have the capital.
• The community has several choices on how to deal with the problem.

Geoff Huston, APNIC, Internet Research Scientist
A look at the IPv4 consumption data
Presentation: PDF PPT

Highlights:

• This is an area that Geoff has been looking at for some years, and part of the difference in the way that Tony and he have looked at this material is in trying to understand what the drivers are.
• Any examination of the IPv4 consumption data should include the following:
  • Use a fundamental assumption that the driver for address consumption is the public Internet, and that the growth of the Internet is reflected in address consumption demands
  • Adjust the model to include each individual RIR’s allocation behaviour over time
  • Set the ‘exhaustion’ date at the point when any RIR cannot honour an address request
• Some projections from the analysis include:
  • IANA Pool exhaustion - March 15, 2012
  • RIR Pool exhaustion - June 4, 2013
• These address consumption models assumes an orderly procession right up to the point of effective exhaustion of the unallocated IPv4 address pool, but that is highly unlikely. Within the current policy framework a more likely industry response will be accelerating demands as imminent exhaustion of the unallocated address pool becomes more visible. It is not easy to model such “last chance run” behaviours based purely on the historical address allocation and BGP data. Some other form of modelling of social and market behaviour of a last chance run would be better positioned to make some guesstimates here

Thomas Narten, IBM
Routing and Addressing: Differences Between IPv4 & IPv6
Presentation: PDF PPT

Highlights:

• IPv6 Routing/Addressing Architecture are essentially the same as IPv4, but bigger addresses.
• We have 2**64 networks, not 2**128 addresses. And we can number 500 million /32s, but we can't route them.
• In IPv6, the scaling of the routing system concern is the same as it is in IPv4, but we can tradeoff lower utilization in favor of better aggregation

A discussion period then took place.

Comments and questions:

• To put the first item into context, a lot of folks have suggested that if we get to IPv6 we don't have to worry about any of this, it's solved. However, the last time I checked, in order to use IPv6 addresses with that good old existing Internet you need to have an IPv4 address to make your appearance. In other words you needed to have IPv4 address for transition purposes. Is that still the case, Thomas? In other words if a new organization comes on 2015 will they be able to access IPv4 hosts unless they have at least one unique IPv4 address? Thomas Narten responded the answer is somewhat complicated. The question is if you're a IPv6 host and you want to talk to a IPv4 host something's got to give and you can do translation which is essentially NAT, but it's a NAT IPv4 to IPv6 version and if you're happy with that and it works "reasonably well" for you then no, you do not need an IPv4 address at all. He added that he thought one of the questions is will those that need to talk to IPv4 hosts enough go through the trouble of doing that, or whether there is enough of a critical mass of who they want to talk to.
  • Presuming they want to talk to the existing IPv4 Internet will they need to be able to get an IPv4 address when they come on using IPv6 for all of their internal infrastructure? Thomas responded that yes they would, because they need to still be using IPv4 to talk to those IPv4 destinations.
• Geoff Huston commented that no matter how you do it if a IPv6 host wants to talk to IPv4 it needs a IPv4 address to present to the IPv4 host. And the NAT might be close to you, it might be close to the other end, but there's still a NAT and there's still IPv4 involved in this. It seems to me that the industry has got very, very sticky on IPv4 and the transition is far more traumatic than merely extending out, like with AS numbers, the bit set.
• A question was asked of Geoff: on your slides,you noted that there's a property of uniqueness which is very important. Can you elaborate with respect to this? Geoff responded that the reason why we have a registry, the reason why we have a point of deliberate collision, is that if you and I both think we have the same IP address, the network won't let us. Someone has to arbitrate. Routing will arbitrate, but perhaps in ways that don't match what you and I believe is history. It's my address, not yours, and I'm going to have to go to the registry to prove that. So the registry's true and lasting contribution, I believe, beyond the distribution of unallocated numbers, is actually the independent and trusted assertion of uniqueness and unique association of that address with someone out there. I'll look at the work that's happened in certification of resources inside our environment across the RIRs and applaud it. To my mind that underpins that lasting value that I think we can offer the community of saying this is a unique association and here are some digital signatures and associated PKI that backs it up. That way either you have the address or I do, but not both of us.
• kc asked for details about the APNIC allocation a /8 or a big chunk of a /8 to Softbank, which is a large bank and access provider in Japan. She noted that Japan was already pushing towards IPv6 for a while in the '90s, and wondered if there was a policy decision change or if it was just realities of the market. John Curran responded that in general, the RIRs don't discuss individual allocations, but to answer the other part of the question, would someone from APNIC answer if they see demand fading away and going to IPv6 very shortly? Geoff Huston replied that no, they did not.
• One of the questions raised is that we have these dates on the tables. 2012 was an interesting date on someone's slide, 2015, and depending on which side you look at, that's either the date of the last block is made available to RIR or that's the date that the last address is available from the RIR to give out. The question is the important one. Geoff asserts in his presentation the date that the RIRs give out their last IPv4 address. Is that your belief, Tony? Your slides have the date that the last block was given by an RIR. Tony Hain responded that was correct and the distinction between the dates is Geoff's assumption that all of those blocks are actually routing systems and in fact at the last policy meeting there was discussion about allowing organizations that have exceeded private address space to come and get space and start advertising it. So in fact there are large organizations out there that are going to start consuming some of the space and it will never show up in the routing system, but actually skew some of the data here. It's a really hard thing to say. We're trying to predict the future based on the past and we know that, as Geoff said, your behavior is not going to be rational. As you see the end of the window closing, you're going to change your behavior and all we can do is keep track of the changes in behavior and keep reporting it and you can keep guessing and trying to outguess what happens. Geoff Huston added that from an ARIN perspective, the date that matters is when you have to say no because you've got nothing in the cupboard. So the critical date that you're trying to look for in terms of policy is the date of the last, if you will, allocation. In fact, to be precise, it's the next one. It's the one where you have to say no that is the real critical one.
• I'm thinking that people are asking ARIN for an address block to number the resources, but at some point, they'd be happy with one unique address just to make sure that they can have an appearance on the IPv4 Internet. They might even be willing to buy it in the black market. I guess the question is whether there is going to be a change in what our model is? Tony Hain replied that it depends. If the architecture is cooperation amongst the end points, the core can continue running IPv4 for a very, very, very long time and be tunneled over the top of by IPv6, just as IPv4 tunneled over ATM and POTS and other stuff, right? So the core can stay where it is, and so the demand curve might actually go down if the end points have made a shift. Since the end points are in a cooperative mode then they can move in a more aggressive state than the core.
  • If, hypothetically, a new organization wants to connect to the Internet in the year 2018, how do they connect? If the core's running IPv4 and the edge is running IPv6, you are saying they don't need IPv4? Tony Hain responded that if the places that they are trying to get to also have IPv6 available to them then all they have to have is the one tunnel end point address and they can tunnel across.
  • So they don't need IPv4 as long as they can tunnel across? Tony replied that they may want it just to be able to have a tunnel end point.
  • Well, where will they get that address from? Tony answered that they would get it from the same place everybody else does.
• Geoff Huston commented that we were trying to solve two problems back in 1991 and they were routing and addressing. This community adopted a set of policies that were biased heavily towards routing. We actually insisted on larger unitary allocations and strong aggregation, provider-based addressing, because it actually had saved the routing system. And we then encouraged the community to come forward with, if you will, requests for as large as they can justify and afford. So big allocations were what we actually encouraged and big allocations are what happened. The routing system has not blown up in our face. So far, that policy, by that particular metric has been successful; however, there is a certain amount of address consumption associated with that policy, and we are now finding that there is a race going on in that space too. I'm not sure that we are good at juggling two balls at once. I think we can throw one up and catch it, but the other one lands on the floor.
  • Do you propose that we only pay attention to one of those two problems? Geoff replied that actually, sorry, yes I do. I think our policies are our policies and they should run out to exhaustion. I don't think a community that makes policies quite slowly and deliberately, where to try and do policy adjustments it takes three years with one every six months, sends reassuring signals to anybody nor will they be effectual. I think our policies are our policies and that will run out at some point. I think we'll serve our community much better to look beyond three months and start looking about five to ten years out and going what will the industry really need from us as registries. So I would run out what we had under our current policies and look beyond it. Our community need from registries at that point will be IPv6 address space from an unallocated pool. Personally, as an observation, as a plan here I believe the industry would be served by having clear title and title transfer to addresses as they get moved around in the market. So I would say that our best role here is to support that distribution. Why? Because if we don't do it, not just one other party would do it, but 50 or 100 or 200. At what point and which routing registry, which title registry, will you believe when you try and buy and sell or have you totally trashed the entire address plant by refusing to play?
• kc said I watched a little bit of this trying to get some level of authentication in the source address of the registries, and at least in the States, the progress that's being made is being coaxed along by the Department of Homeland Security, which has noticed that our BGP layer is completely unauthenticated and unencrypted. They are trying to bring people together and see what we can do with the minimum amount of government involvement, because the truth is I talked to a lot of people at various agencies in DC on a regular basis and of the people who have not wanted the government involved in the Internet the people in the government are way at the top of the list. So they really want to find ways to help the industry help itself right here. However progress is slow and even one of the operators at the last workshop said that you are not going to get the players to do this unless you force it on them. DoD already has a rule that all equipment procured has to be able to be IPv6 by 2008, whatever that means, so what will happen is that they will make any dot-com, any commercial organization, that wants to do business with the government, of which there are a lot of them, follow these procedures. They would have to make sure their addresses are authenticated in an area and they would have to be supporting SBGP, whatever. By the way, the same exact problem happened with the innovation in the DNS layer which is how do you authenticate the naming system.
• Given the point that Geoff made here on all those assigned, but unannounced IPv4 addresses, they will be useful as we transition to IPv6 because each one of them has, if nothing else, the property of being unique and that's valuable. Is that enough or does the IPv6 community want the registries to hold aside some IPv4 addresses so if nothing else you can get your one unique prefix to interoperate with the IPv4 Internet? Tony Hain replied that I don't think you need to hold aside anything. I think there will be sufficient access to the IPv4 space. I'm not overly convinced as Geoff's promoting that a market as a good thing. Geoff Huston added that I'm not saying it's good, I'm saying it's inevitable. Tony continued that he thought it's inevitable in some senses. It raises all kinds of policy issues on a global scale about equity of distribution and things that I think are bad and that we really would want to avoid. At the same time it also plays back into the economic argument that people have against IPv6 deployment in they're saying well, it's going to cost me extra to deploy IPv6 and even if it's just training. I mean, they have to go through at least a training process to bring everybody up to speed. And so there is a cost level and if the market for IPv4 develops sufficiently, but the cost of staying on the IPv4 path is higher than the cost of doing the transition to v6, it drives IPv6 deployment, right? And so in some sense, it's good, but from a public policy perspective it's probably bad.
• Thomas Narten commented that you talked about holding addresses in reserve, used to make sure that there was one address for whoever needs it. The thing that everyone must remember is an address isn't useful if it's not routable to some degree and I think that's where Geoff talked about the two balls in the air.
  • And your advice on that topic is? Thomas responded that we need to be very careful about making any changes of policy that forget that.
• I would like to hear from the panel about how maybe we should look at ourselves as a federal reserve in raising the rates and when things start getting a little bit too loose in money supply and maybe we need to think about that in doing IPv4 space, raising the rates and lowering IPv6 so it creates an economic incentive for those cash-poor companies right now that need to innovate at the core.
• I'm wondering about kc's presentation. I think her capital markets analysis was incredibly interesting and very relevant, but I think one of the things perhaps slightly missing there is that the capital-rich companies are equipment vendors. I think they see that they can't sell equipment to all of the enterprises out there, helping them to connect, so there is a lot of capital flow in one direction and that's not captured on the earning sheets. kc responded that we know that some of those red numbers on that infrastructure slide are Bernie Ebbers' yacht and we don't really have a good insight about what the economic structure of these companies looks like. You can't get the numbers on these companies, since they don't separate IP from all the other stuff that they are doing.
• There are techniques to conserve IPv4 addresses and stop a run on the bank because everybody wants to have them. Once they're out, there are ways to save them and people will use them to extend the life of the IPv4 network. Tony Hain responded that if you go back to the run rate curve that I was showing from my end of the exponential growth since 2000, that's while we were deploying NATS, so we have an example of using adverse conservation techniques and at one point we were heavily into cyber traffic engineering and blowing holes all through that, right? And so we're blowing out the routing system at the same time we're using Ebbers' conservation techniques and we are still blowing through Internet space.
  • Well, but do you think things like NATS are not required today? It's all about people who could do that, but are choosing not to because it's free. Tony replied they're economically required. I mean, it's actually not required unless you want to have more than a few machines connected to your ISP. And the ISP says it's going to cost you $20 per address for whatever the number is and that changes the requirement perspective a whole bunch. I mean, it's not really required, but from a consumer perspective it is.
• When I saw Geoff's slide which showed the blue and the red lines and the growing disparity between them the word in my mind was "porting." And I agree that scarcity becomes just a property of the market economy and I'm starting to really feel that if you're right, and it's a guess, that a market in IP addresses is inevitable. I'm not sure that the registries are going to do a lot of good by trying to create artificial scarcity because the people who are good at scamming the system will continue to get what they want.
• I want to point out KC's comment about who has and who doesn't have the money. A lot of the large corporations that have money in this country and other countries that have the ability to innovate, but currently are unable to get address space through current policy. We have to realize that there are consequences of giving address space to these corporations in terms of the roundtable. That's part of the world we live in. But companies that are large will not be happy with just single IP addresses. It depends on what you think about it, but under the current time frame the alternative we have is the current multi-homing technique. And so with regard to this, that is the key to how IPv6 rollout occurs. And the aggregation techniques or nontechniques depending on how we decide to do it are very keen to this discussion. kc replied that it's two things you need to get to innovate in the core, right? You need capital and you need incentive, in a free market anyway, and I don't think we have either of these from the people that we need.
  • I would agree with that and the question is how do we stave off innovation at the core if innovation occurs at the edge. The core is going to be IP4 for a long time. At some point it becomes an incentive to run IPv6 data even if the core is IPv4 for a very long time. kc added that we should remember what we wanted from the core. When we threw it over the fence in 1994, what we wanted from the core was stability. Customers using the core want that to work. It's become critical infrastructure. So innovating in critical infrastructure is tricky. We don't innovate our highway system very often, or our subway systems. We do sometimes and it's a huge social decision and lots of discussions are had like this.
  • So the question then becomes if we're going to have a IPv4 core for a long period of time just because of the current economics, do we have to change the way we do our policies to make sure that the core can have enough space, or do we feel that the core already has enough address space, or do we go to some sort of market system where the resources can be used. So those are all questions, but we don't have to answer them now. kc responded that the underlying question is what are we building, right? And this comes back to Geoff's talk yesterday, which was it really looks like the way IPv6 happens, is it's water, it's a commodity, it's a utility. My additional thought is that I think that's where the future in IPv4 is too. People want water. The innovation that's happening at the edge, it just needs water from the middle, not fancy stuff.
• I want to ask people to focus on the uniqueness aspect of the addresses. I mean, outside of the world of the public routed network there are people using the IP protocol suite and I feel that's what we're stewards of, not just the public Internet.

Final comments from roundtable panel:

• Thomas Narten: I find the discussion about when the end date is quite interesting on an academic level, but I think, stepping back, the reality is that the end is in sight and we need to deal with that and think sensibly about what our options are, what the world's going to look like going there, and try to make some sensible policies if that's appropriate.
• Geoff Huston: You can state this problem in any set of terms you want. You can make it as large as you want and you can invite as many people as you want and you can take as long as you want. You can invite in governments, the UN, WSIS, the ITU, the lot, and it will take a few decades. Or you can pick a role, maybe it's uniqueness, and work within those limitations and recognize that you, as the RIR community, can't solve everything, but what you can do is work within what you're competent at, what you're trusted to do, and what you can preserve and provide across this entire phase of the Internet.
• kc claffy: So as we can go into these free market discussions, I really think it's important that we look at our history. We've had two inflection points in the history of the Internet where we had to make a decision about a resource and how to provision it, the first being the backbone in 1994. Under pressure from Congress, it was a very reactive move. If it had been in another time in history we might have made a different decision. But we threw an architecture over the fence to the private sector without any consideration of the economics, without any consideration of the security. We're running into some problems right now because of those decisions. We did the same thing I in about 1986 something, with the DNS. We chose free markets, running into some problems now, don't have security in either of these layers, have lots of consolidation, don't really understand the economics too well, lots of stewardship and governance issues. So when we move into what we do about address allocation which is not really analogous anyway because it's a much scarcer resource than bandwidth or letters we should really think about that. It's a new problem, it's a very new problem, that we have. And the other thing is that there is some good news in all of this that maybe we're losing sight of, but that keeps me very optimistic which is that we made something here that everybody wants. Everybody in the world wants this. In fact, it's so good that some of us want it more than once, right? That's what shim6 is about. We want more of this than one instance. Also we want more of it because it wasn't inherently reliable infrastructure. It wasn't a reliable architecture, right? It was built for something completely different and it's being used well outside of its spec. So last comment is that one of the contributions that CAIDA is going to make to this is we're going to have a workshop in January. There's a fellow named Peter Schwartz who wrote a book called the "Art of the Long View." He does a talk on it, it's online, if you look for it. This is not a data analysis problem. This is a scenario planning problem. Peter Schwartz invented a discipline which many other people are using. I'm not saying he's the only one. But he wrote a book on this art called Scenario Planning. And it's really about not predicting the future, but preparing for the future, going into the future better armed, understanding what are the ramifications of certain decisions, what are the exogenous factors that are going to affect different trajectories, and so just being better prepared for what is going to happen and knowing where you can adjust the sails in lieu of being able to change the wind. If you're interested in going to that workshop, there will be homework associated with it. Send me mail. You will be expected to reach, to contribute, to help write a report afterwards, so it's not like a BoF.
• Tony Hain: One of the things that I think was touched on here, but not really very clearly stated was that IPv6 policy and IPv4 policy go hand in hand. To some degree I would think making any changes in the IPv4 policy is actually in the interests of the membership because, if we're taking the I need to do this job now to try to get myself out of red back into black, I need that space now. I don't need it to be in reserve for something that might happen three years from now when the company's gone out of business because we never got out of the red. So changing IPv4 policy is not in the membership's interests, in my view, but we do need to look at the IPv6 policies and make sure that we're not inhibiting people from deploying IPv6 because of the policies. A lot of the enterprises are standing up and saying the policies today don't let me do what I want to do. I would be willing to pay the service provider to get the service, but I can't because the policy doesn't want me to have the address space that I need. So we need to look at all of these pieces collectively and think about that in terms of what the role is going forward. As Geoff said, pick a role and move within that.

IPv6 Activities Report

Speaker: Thomas Narten, IBM

Presentation: PDF PPT

Thomas Narten reported on activities within the IETF relating to IPv6.

Highlights:

• Multi 6 Working Group is all, but done, waiting for RFC publication. No activity since last ARIN meeting.
• shim6 Working group had an interim meeting collocated with RIPE meeting. A set of updated drafts is coming for Vancouver IETF meeting. In general, work is progressing, but still at fairly early stage
• IPv6 Working Group issues include the IESG approval of four documents: draft-ietf-ipv6-addr-arch-v4 (May, 2005); draft-ietf-ipv6-host-load-sharing (June, 2005); draft-ietf-ipv6-link-scoped-mcast (July, 2005); and draft-ietf-ipngwg-icmp-v3 (July, 2005). Also, three new RFCs have been published since the last ARIN meeting.
• v6ops Working Group has had IESG approval of four documents and has published a number of RFCs.
• A miscellaneous activity not related to a specific working group is the deprecation of ip6.int, which is a separate agenda item at this meeting on Thursday afternoon.
• IESG is considering forming a working group on tunnel configurations. A number of meetings and BoFs are being held prior to this. The goal is to set up automatic IPv6 tunnels to ISPs/POPs.
• New or proposed IPv6-related work includes: Mobile Nodes and Multiple Interfaces in IPv6 (monami) WG formed October, 2005; Ad-Hoc Network Autoconfiguration (autoconf) WG formed October, 2005; and a BOF will be held at the upcoming Vancouver IETF meeting to discuss 16ng - IPv6 over IEEE 802.16(e) Networks.

There were no questions or comments from the floor

Where are we with IPv6?

Speaker: Jordi Palet Martinez, Consulintel CTO/CEO

Presentation: PDF

Jordi Palet Martinez gave a presentation touching on the issues surrounding helping people to move to IPv6 and some of the things that have been discovered in the process.

Highlights:

• Debate over whether or not or when we are running out of IPv4 is not helpful. Predictions on this are either inaccurate or misleading, and the focus should be on rolling out IPv6 now.
• For a number of years, we've been involved in doing research in IPv6 with the help of public funding, and now in return for community support, we assist with actual IPv6 deployments through training, network analysis, working with upstream providers, and a number of other methods.
• IPv6 is already deployed in a number of areas and interest globally is increasing, and in fact we are now seeing, through traffic analysis over a number of consumer websites, a measurable and significant amount of IPv6 traffic.
• There are still a lot of myths that need to be combated for widespread IPv6 adoption, and many large networks are not yet ready. More widespread adoption will occur once large companies see the advantage IPv6 provides in terms of improved and more efficient business models and that IPv6 allows for more innovation.
• Adoption is much easier than most people anticipate as long as they plan ahead and take advantage of early adopters, realize that adoption can happen incrementally, and that while native IPv6 is preferred, translation methods work well when set up properly.
• Consulintel is willing to assist anyone with IPv6 adoption at no cost because the more networks with IPv6 enabled, the more it helps our existing customers.
• The cost of not being prepared for IPv6 will be vastly higher than the cost of easing into it.

Questions/Comments:

• What does it mean, "IPv6 happened?" What's the demarcation to say it's happened? Jordi responded that he believed IPv6 happening is having a good level of deployment. I'm not telling you 50-percent in five years. I don't know the numbers, but having IPv6 in most of the networks for me is the demarcation.
  • An attendee from the floor commented that successful deployment is when the endpoints are able to successfully exchange packets between the allocations.
• You asked about what three things that we need in order to do IPv6. The first one is the equipment that supports it , content providers and upstream providers that support v6, and a solution for IPv6 multi-homing.
• I wonder if your statement that IPv6 essentially is fixing a bug in IPv4 could also apply to equipment vendors. We have an equipment vendor, a major router vendor, and we used them to do a recent upgrade of our router hardware to hardware that does support IPv6. The vendor wanted to charge us thousands of dollars more for the image that was capable of actually doing IPv6. We're getting another router vendor which just includes that image that does IPv6 as part of its regular image. And so I was wondering how do you feel about that. Jordi responded that is the reason why some are not moving forward with implementation and my personal opinion is that's not good but, again, it's a market decision. If that router vendor won't do that, maybe it will lose customers sooner or later. Obviously, actions like that would impact the deployment.
• There are few content providers who work only in V6. A lot currently here in the U.S. don't support it. It takes quite a while to get the gear in place to support it, and it doesn't matter until the end-sites are using it and can get a reliable connection. Content providers are in the business of making money and if our customers can't reliably reach us, who will then be providing content to them over the unreliable connection?
• You had some suggestions on your slide that showed one of the ways to get IPv6 and implement it is through the normal refresh cycle as you upgrade your equipment. My stuff is IPv6 capable and that's the way I foresee us proceeding. However, it's very hard for us to go out and purchase all the right equipment that has large enough memory to hold and deaggregate IPv6 routing table based on the fact that's not going to generate a lot of new revenue. But the other point that I have is that I have a very long refresh cycle, on the order of five years, so we're not as flexible as some of the smaller carriers.

Proposal 2005-5: IPv6 HD Ratio

Speaker: Andrew Dul, Proposal Author

Presentation: PDF PPT

Ray Plzak presented an introduction to the proposal. Highlights included:

• Introduced on PPML – May 25, 2005
• Staff Impact Analysis – October 2005
  • ARIN departments - no significant implementation impact
• Legal Review – October 2005
  • "… Does not create legal issues that need disclosure or analysis
• Public Policy Mailing List (PPML) Discussion Summary
  • There were 12 posts by 9 people.
  • Notable responses included:
    • “[At APNIC 20] consensus of the room appeared to be to change the HD ratio from 0.8 to 0.94.”

Andrew Dul, as the proposal presenter, continued with the presentation [Presentation: PDF PPT] of the proposal. He said the proposal stems from two places, the first is that per Geoff Huston's projections we'll run through between a /1 and /4 over a 60-year period and that seemed too short a time for comfort.  And second is the concern about some recent very large allocations to ISPs.  This proposal is a simple change to lengthen the life cycle of IPv6.  If at some point in the future .94 is not the right number, it can be changed.  He acknowledges that ISPs will have to be more efficient with their use of address space.  For example, an ISP with a /20 goes from having to be at 2-percent utilization to having to be at 32-percent.

Statements For and Against:

• I feel strongly about it and we should do it. There were some pros that were listed and I agree with the pros.
• I think it's great to dial a number down like we're doing. I'm a little concerned that with the /32 the percentage utilization is 51-percent.  If you want to use sparse allocations, you end up with every other block full, and you're only at 50-percent and I'm not sure you qualify for a /32 at that point.

Questions/Responses/Clarifications:

• Would this apply to smaller blocks like /48 to /56s? John Curran responded that the policy applies for all size blocks, but how it applies is based on how the HD ratio calculates out. Tony Hain also responded by saying I think at one level the answer to your question is right now as the policy is written, your measurement is based on the number of /48s and the HD ratio applies only to that. So if you're asking how it applies to anything other than that your question is not really relevant to the HD ratio value itself in terms of the current policy.
  • For a /32, it's what, 51-percent utilization? And if you want to be a big Internet player I think that sparse allocation is important. It could be hard to maintain that 51-percent. You're going to have adjacent allocations. Geoff Huston responded this is measuring the end sites and I'm not sure how sparse allocation actually refers to this. Sparse allocation is actually trying to do with RIR allocation to the LIRs and ISPs and the whole idea there of using sparse was to make sure that when they came back using that metric there was a link that decided if you could give them another /32. So this has nothing to do with sparse. This is when you come back how many /48s out of the block have you actually handed to end sites. Once you've achieved that HD metric then the case is there that you can say I need the another allocation.
  • I guess the question I had is at least what I envisioned was ISPs giving out /48s in a sparse manner so that if a customer goes beyond 32,000 subnets, you've got an adjacent place. I mean, we do have some big customers. John Curran replied that there are two answers to that possible. The first answer would be that if you use a sparse allocation philosophy and you did achieve perfection so you had an expansion block then you'd be at the point where you had 50-percent utilization and you wouldn't qualify and you'd face the difficult task of having to go back and use some of the blocks that were set aside for expansion. I would be surprised if you couldn't achieve finding 2-percent of those blocks to reuse in that even though you may have a few entities that will overflow their initial allocation, it's unlikely you're going to have the vast majority of them overflow.
• How does this relate if the /48 is changed to /56? Andrew Dul responded that the way it's written the HD ratio wouldn't change. And if you change the other proposal it changes the method for looking at how you do the utilization numbers, but the HD ratio would not change.
  • You get to a larger discrepancy between the /32 and the/ 48, as that becomes a /20 and a /48 or it becomes a /32 and /56, that changes where on the sliding block curve you are. Do the percentages change in the situation? I know that the HD ratio is still an HD ratio, but do the percentages change significantly if we go to /56 and /48? Should that be considered as part of whether we adopt this policy and the other policy or are they totally independent? Andrew replied that I see them as independent, and then asked Thomas Narten to address the issue. Thomas said I think if we modify the boundary to something else the HD ratio threshold will be the same. But I think if you went in that direction you'd have more bits to play with and the more bits you have, the lower the overall utilization has to be in order to justify you at the next level and that's the way it works.

End of Discussion:

John Curran took a straw poll to determine the consensus of the room. There was consensus to move the policy proposal forward.

Proposal 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement

Speakers: Lea Roberts and Thomas Narten, Proposal Authors

Presentation: PDF PPT

Ray Plzak presented an introduction to the proposal. Highlights included:

• Introduced on PPML – September 1, 2005
• Staff Impact Analysis – October 2005
  • ARIN departments - no significant implementation impact
• Legal Review – October 2005
  • "… Does not create legal issues that need disclosure or analysis
• Public Policy Mailing List (PPML) Discussion Summary
  • Discussion before formal proposal:
    • “Opposed. Does this proposal help with a short term problem, or promote the adoption of IPv6? No.”
    • “It's easier to loosen the belt than tighten it.  If we try to restrict things later, late adopters will cry ‘Foul!’  Could we at least avoid making the mistakes we already know about?“

Lea Roberts and Thomas Narten co-presented [Presentation: PDF PPT].  Lea said the current policy is a result of RFC 3177, which came from the IETF as an IAB recommendation to the RIRs that talked about assignment sizes of /128, /64, and /48 where /64 would be for sites which would only want one and only one subnet and /48 for most others including home users. The RIRs got together and created a global policy document that incorporated the RFC 3177 recommendations and those policies were put in place in the 2001 or 2002 time frame.

General Comments:

• Unclear effect on utilization measurements, somehow they figured out how to measure utilization given a CIDR with 32-bits and should be able to get the research community to work for the next couple of years to be able to do that on 64-bits. I just have a feeling they'll come up with a solution.
• I think we should tell ISPs not to make fixed boundaries in their provisioning systems.
• There is a big difference between discussion of allocation and utilization, they're not the same thing.
• At APNIC, it was proposed that /58 should be assigned based on the subnet size, that is under 255, and this led to some concerns within Japan; however, if the policy is ultimately such that the subnet size is removed and the LIR can decide whether it's appropriate to assign a /48 or a /56, then that would likely be agreeable, that is, there probably would not have been as much opposition against this policy at the last APNIC meeting. 
• Regarding the question of why does ARIN care how I allocate, whether its /56 or /48, the reason is because there needs to be a defined way to measure utilization. As an ISP I, would like the flexibility to be able to give out /56s or /48s, depending on what my customer needs. I don't want ARIN to put down hard and fast rules about what I have to do there, but I also don't want to be stuck with just 48s.  I think having the flexibility to have the ISPs and the customers decide amongst themselves what's needed is the right way to go. In my case, in my house I probably don't need 65,000 subnets.  I definitely need more than one. So if I can agree with my ISP to get a /56, that's acceptable.  I guess my point is flexibility is good.
• For my home I do not need a /48.  Maybe a /56 would be a good thing for residential, but for commercial entities, 255 blocks doesn't seem that many.
• Raúl Echeberría stated that this was discussed at the last LACNIC meeting (it was not a formal proposal) and there was agreement that this is the right track. The concern was that /48 is too much. There is some concern regarding the possibility of repeating some mistakes of the past. There is also concern in the LACNIC region that there will again be unfair distribution of some part of the address space.
• We've moved this boundary before. If you have been playing with IPv6 for a while there was a /35 boundary on a non-nibble thing that was tried earlier on so we've been there. We've done /64s, we've done /48s, so it's moved around a little bit. The bullet points up there, what are we trying to accomplish? One of the promises was that it is fairly easy to renumber. That's a good idea and if IPv6 actually lets us do that then having fixed boundaries and policies about what gets allocated seems to make sense to me.  I'd actually like to see no fixed boundary policy and just say so you get what you can justify. That's what I'd like to see.
• It's true that somehow it should be easier to renumber. Today it seems the /56 will be enough and /48 may be too much but, for example, if a customer gets a /56 and then needs to move to something bigger they will have a problem with renumbering. Also, somebody said they are being charged for IPv4 addresses, I really think we need to avoid that happening again.

Statements For and Against:

• Fear is the real issue here. We just pushed it from 50 years to 500 years with the HD Ratio change and we're talking about taking this out to 50,000 years. /56 is not on the right track. The fear is we're going to waste space and we're going to waste it anyway.  Get over it.
• I don't think the case can really be made for perpetuating what's been admittedly a very clever hack in reverse DNS.  I think we just allocate on nibble boundaries and call it a day.

Questions/Responses/Clarifications:

• John Curran, in seeking a clarification of a statement by an attendee, asked that you talked about variable bit boundaries versus nibble and in particular you don't think nibble allocation is necessary? The attendee replied that no, I would not recommend it.  I can't see any reason why.  It just makes no sense. ISPs are going to allocate 64s to end home users and they won't have a choice, then maybe some of the end home users can go up the chain and easily get the address space they need.
  • If your ISP won't give you a /64, how do you go up the food chain, so to speak? How does that work? The attendee responded that all I'm saying, I can see that being perceived as a problem, I can see that being a problem, and therefore let's solve that, and I just threw out one possible way of solving it. We haven't had the dialogue, we haven't explored it, et cetera, but that's the one place I think we agree there can be a real problem.
• In response to a comment about waste of address space, Thomas Narten replied that you're framing the question in a way that's not particularly helpful by saying we're going to waste space anyway because you can argue we waste space in IP before because we only require 80-percent utilization. The question is to what degree and how much waste are we allowing. That's what needs to be in the discussion, it's not whether there is or isn't going to be waste.
• I still have a clarification question. If I have a current priority for 150 sites, but in 10 years I expect to have 350 sites do I qualify for a /48 or /56? The reason why I asked that is because in point 1 we were expected to receive 256 and point 2 the word "expect" is not there, it's the actual requirement, so is it based it on what I need right now or what I expect to need? Thomas replied that, in fairness, that was a first cut attempt at how to maybe define how these buckets might lay out and how you would justify being in one versus the other. Given where we are in the discussion on this point, I think it's probably not worth looking at that in a whole lot of detail, because it looks like we're not even going in that direction.

End of Discussion:

John Curran stated that we have a challenge in that we have a number of topics that are imbedded in this and, as was already noted, the proposal itself may have already been overtaken by discussion.  The proposal calls for adding /56 as the default assignment and allowing folks to use that or /48s for large organizations. The challenge is that we've had discussion about the additional /56 general allocation size, the addition of other nibble boundary allocation sizes, whether these should be  fixed or whether they should be set to allow, for example, ease of configuration portability between providers.

John Curran took a straw poll to determine the consensus of the room. There was consensus to revise the proposal, that is, revising policy to something other than what it presently is (which is the /48), and for exploring variable assignment sizes for IPv6.

Allocation & Announcement: How long before allocated prefixes are used? And who announces them?

Speaker: Randy Bush

Presentation: PDF

Randy Bush presented on the topic of how much delay exists from when an RIR allocates IP space to when it's announced in BGP. Using WHOIS data from ARIN, and BGP data from Route Views RIB dumps from 1997 to present, Randy provided data and analysis with highlights including:

• Holders of resources are identified in ARIN's database by an Org Name and by an Org ID. Using first Org ID then Org Name for each network, a match was sought to any ASs held by that organization. The matching attempted to identify what were most probably legitimate announcements of a network by an AS where both the network and the AS are held by the same organization in ARIN's database.
• Some LIRs tend to announce pretty quickly once they get an allocation, however some don’t register sub-allocations until they need more space from ARIN. This data and analysis involved when allocations were announced, not when announced prefixes were allocated or by whom.

Comments and Questions:

• What's going on with the stuff to the left of many of the charts? Randy replied that was showing people who were announcing the suballocation before it was SWIP'd. The ISP was giving out all these pieces, the multi-homers are announcing in the BGP, but nobody SWIP'd it yet.
• Is this just SWIP data or does this also include RWhois information that we would have done and referrals to look up as well? Randy asked Tim Christensen, ARIN's Database Administrator, if it was correct that the data from ARIN only showed SWIPs. Tim replied that was correct.
• Since this data is organized backwards from the SWIP, it's not like stuff that never got SWIP'd is somehow showing up, correct? Randy replied that yes, it's not that these are BGP announcements and we're missing the RWhois data. What's driving the data is the WHOIS data and we are looking for matching BGP announcements. So if there is a BGP whose announcement has no matching WHOIS record, this is about what we thought was happening. What makes it much more stark is the CDF, cumulative distribution function, so we can see that with the direct allocations nothing interesting happens until SWIP time and then they tail out and the suballocations indeed cross the Y-axis.
• Cathy Aronson stated that she did something similar a while back and presented it here and the thing that somebody was commenting on, the allocation that's not in the routing table, I mean, we found that there was a little bit of negative there, but it wasn't anything like 400 weeks. And the reason that it was negative was because people were just speculating about what the reserve space was and starting to use it before it was allocated to them. And sometimes the ARIN staff would give it to them before they actually put it in the database. There was like a week, maybe, but it was never that big. And I'm wondering if we have to look at what the difference in the data was. Randy replied that the variance could also be partly attributed to ERX data.

Proposal 2005-6: Micro-allocations for anycast services

Speaker: David Williamson, Proposal Author

Presentation: PDF PPT

Ray Plzak presented an introduction to the proposal. Highlights included:

• Introduced on PPML – August 22, 2005
• Staff Impact Analysis – October 2005
• ARIN departments - no significant implementation impact
• Legal Review – October 2005
  • "… Does not create legal issues that need disclosure or analysis
• Public Policy Mailing List (PPML) Discussion Summary
  • Discussion before formal proposal:
    • Several posts in favor
    • Author clarified intent that proposal pertains to IPv4 only

The author of the proposal, David Williamson, presented on the reasons for putting forward the proposal and the issues involved [Presentation: PDF PPT].

General Comments:

• I just would like to suggest as we consider this policy that we consider the precedent being set. The justification as written for micro-allocation here is that this is an e-technology and it makes sense in a certain business context. That's true. I'm all for anycast, I'm a great advocate for it, and it's a wonderful idea. But I do have some concern about whether we want a micro-allocation policy justified strictly in terms of it's an e-technology and there are business uses for it because I'm not sure how that scales. Eventually we'll just end up revisiting the micro-allocation policy piecemeal. The other micro-allocation policies do have a public benefit justification. I'm not sure that's the only or the right criterion. I'm not sure it's necessary or sufficient, but I suggest considering the scalability of this kind of action.
• We use anycast and I thought I would share some stories, because I think it makes a cautionary tale. When we started doing it a lot of people came out of the woodwork and asked if we'd gotten permission, who gave us permission, why didn't we get permission. I didn't consider it dangerous and it turned out not to be dangerous, but the concerns that were coming out at that time were not all irrational.
• Now we're talking about filtering and we all remember the days when if your netblock was not large enough it would not be routable and so there is no point in getting it. ISPs respect each other's allocations and they route each other's traffic because there is mutual benefit to doing so. We advertised the f-root prefix, and I note that that causes more people to burn more RAM and more routers because it's the paths that kill you, not the routes. We use more bandwidth for my prefix than if we were not anycasting it.
• If you say anyone who can do this can simply go down the list of qualifications, fill out the form, and get it I'm concerned that you will have maybe a disaster on your hands.  I'd like the policy to be very experimental.  Maybe the first 20 of these and we grant them and we wait and see how it goes or something like that.
• Hoarding is a concern.  I'm thinking that the penalty that I ask the world to pay in order to support the anycast of f-root was worthwhile because f-root is important to the world. But I would not expect the world to look kindly upon me if I anycasted vixie.com, because it's not very important to the world. It's not important in fair comparison to the penalty I'm asking the world to pay. So I would also like the policy to have some sort of weasel wording in it that said this has to be a public benefit that is commensurate with public cost. Note, I would not want ARIN or the staff to have the liability of saying no based on the fact that they saw a public benefit so I don't know quite what I mean by adding that to the policy.

Statements For and Against:

• As someone who has built more anycast networks than anybody else, this is a great thing, and I heartily support it. One fairly obvious concern is that we're making policy here that will definitely extend outside the region in that many or most anycast networks operate across the region. So if we do this policy, and this policy has not yet existed in other regions, we will get people requesting address space in this region because they have a branch business office, or mailboxes, et cetera, or something here. I'm not sure that's a problem, but it's something.
• I support the idea. I'm just lacking empirical data showing the reachability you need for coming out of the micro-allocation block as opposed to coming out of any other area.

Questions/Responses/Clarifications:

• We do have existing micro-allocation policies that cover root servers, critical infrastructure, exchange points, so I'm not sure that using those as examples of where it's needed would work. I question that the policy as written is for ARIN to make direct assignments of /24s for this specific use. Would it be sufficient to do what we do for multi-homing micro-allocations and allow ISPs to just consider anycast service as justification for /24, therefore potentially allowing allocation, but still permitting anycast service? David Williamson responded that I think the driver from our point of view, I mean, we're obviously a commercial service, is we prefer it to be a direct assignment. We have direct assignments already for our own data center space. We play games with which providers we're using at any given time. I don't think I'd want to be locked into a provider available in a multi-home space. That's certainly an option, but I think having a policy available where enterprises such as ours could approach ARIN for a direct allocation really makes a lot of sense from our point of view.
• You've got anycast, you took part of our aggregates and you took /24 out of it and that didn't work. My question is if I'm the target audience for this and if so what's the driver for getting a /24 from ARIN as opposed to breaking out a /24 from one of my ISP aggregates? David replied that I think you are the target audience in part. I'm definitely the target audience which is why I wrote it. I'm interested that you have a /24 that you just pull out of your existing block and it was in fact globally routable and there are certainly ISPs out there that will filter anything longer than a /22. Personally I don't want to take chances on that. I want global reachability. I'd like to have a policy that says I can get an allocation I know will be globally routable. I certainly could pull a /24 out of an existing /22, but I'd rather have the direct allocation for reachability.
• I'm wondering if this is supposed to be supporting people that have a home office network and their regular building office and those are their two multi-homed networks, is that really what you're trying to allow to happen? David answered that is definitely not the intent. The intent is, for example, we have three data centers, each has a /20 allocated. We already have direct end user allocations from ARIN.  We thought about writing in that you should already have direct end user allocations or ISP allocations in order to make a bar, a minimum bar of entry. There was some discussion about that on the mailing list. We've tried to find the right balance and we may not have found the exact right one yet, but there's certainly some concern about that.
  • How would you verify that someone intends to use them for anycast? David rephrased the question more generally, asking how ARIN verifies the data supplied on submitted templates, such as if someone is multi-homed. John Curran asked Leslie Nobile, ARIN Director of Registration Services to respond. Leslie answered that in the case of multihoming, ARIN Registration Services actually asks for some sort of proof, such as if they have contracts from two service providers.
  • If this policy was implemented, and there was a possibility of getting anycast assignments or applications, how would you verify that someone intends to use them for anycast? An attendee responded that the only difference between anycast and regular multihoming is whether there is an internal network interconnecting the AS and that by definition is not visible from the outside or there may be an internal network that won't pass external traffic, for instance, right?  And so that's not really a meaningful point of discrimination. What's interesting here is that there is a stand-alone service that's being advertised in a multi-homed fashion, essentially you've got a single IP address that needs to be advertised somehow where you can't advertise it as part of an aggregate. Who cares what your internal network engineering looks like if the net effect is a single service on a single IP address being advertised in a single net block where the block should be as small as possible for conservation purposes, but at /24 so that it's routable?
• How many applications are really using anycast; are opportunities really being missed out on, and does that lead to revenue loss to these people? An attendee replied that I don't have great empirical data on that, but from what I heard from a person who has an anycast service and has one rate offer we think demand is probably not huge. In fact we hope it's not real huge. It shouldn't be. But we do think there's real demand. It's probably one of the small number of companies that have a service that anycast is applicable for and to actually have a business case that is going to be useful and profitable for them would have to be in one of those. But we expect the number's relatively small, but very real.
• Should ARIN need to be responsible for evaluating the service, and its feasibility, that would be using these addresses? If someone is using anycast for something that isn't stable, should they be getting a direct allocation? David responded that we have the sense that if you're going to do anycast, you've got to know what you're doing.  If you don't know what you're doing, and somehow can convince someone to give you space for it, you're welcome to hang yourself.
• Given the concern for the effect on global routing stability, slots on people's BGP tables and things like that would an appropriate alternative approach to this be slightly widening the scope of what's currently considered critical infrastructure in our current micro-allocation policy rather than throwing it wide open to the world and then we can revisit that after a certain period of time and open it up perhaps further yet? David answered that the service that I wish to provide is critical to my company and our revenue, but I can't honestly say it's key to network infrastructure or anything like that. As for softening the restriction on exchange points and critical infrastructure, I don't see how that really jives well with commercial interest.
• I just have a question about the second bullet point in the criteria, the organization must have multiple (at least two) discrete points on the networks. I can envision situations, let's say, public entities would want to do some sort of anycasting with critical  infrastructure that they may have where they would own networks or have possession of networks in multiple places, but they would work together. Say, for example, the City of San Francisco might have space in the City of New York's data center and use its network and want to announce an anycast prefix out of the City of New York and vice versa.  You may have two organizations that want one anycast block that they'll use between them, or you may have each organization want its own anycast block, but it then uses another organization's infrastructure to announce. It seems this policy as written doesn't include that possibility. Do you intend for it to include that possibility? David replied that you need to define the organization at that point. If you're sharing some sort of service, you could create effectively from ARIN's point of view, an umbrella organization that's in the cities of San Francisco and New York some service they're sharing.  I think that's open to interpretation. The intent is very much that you have multiple sites that are hosting your service and they're discrete and at least in some ways associated with your organization in some broader sense.  It could be a partner. It could be some other relationship. The government entities clearly have different types of relationships from commercial entities.
• In answer to a question from the floor, Leslie Nobile, ARIN Director of Registration Services, said we've been tracking anycast  for about a year and we've had eight requests specifically for anycast services. We filled six of them. Two were rejected. They couldn't qualify for the /22. They could only qualify for a /24 and in fact the four that we actually approved did qualify for at least a /22, some of them for a /20, but they didn't necessarily need as much space as they qualified for.

End of Discussion:

John Curran took a straw poll to determine the consensus of the room. There was not consensus in the room to move the policy forward.

John posed a second question for consensus, to provide additional data to the Advisory Council. The question asked was "Does the use of a /24 out of an existing block adequately address this under existing policy, understanding that ARIN will not penalize you for underutilization of the /24 on future requests?" There was consensus in the room that this was true.

Closing Announcements and Meeting Adjournment

Speaker: Ray Plzak, ARIN President and CEO

Ray Plzak reminded attendees that the ARIN RSD and Billing Help Desks and the Terminal Room were open until 5:30 PM PDT. He encouraged all attendees to complete the meeting survey available on ARIN's website. He reminded the audience about the ARIN social that evening, and that day 2 of the ARIN Public Policy Meeting tomorrow would begin at 9:00 AM PDT. Ray concluded by thanking Equinix, which sponsored the Terminal Room and the meeting's network connectivity.

Day 1 of the ARIN Public Policy Meeting was adjourned at 5:22 PM PDT.

Relevant Navigation

• ARIN XVI Main Page

ARIN XVI Report

• Pre-meeting Tutorial
• Pre-meeting IPv6 Workshop
• Public Policy Meeting Minutes
• Member Meeting Minutes
• Meeting Attendees
• All Meeting Report

NANOG

• NANOG 35 Information

---

Search ARIN.net
Advanced Search
Search Tips

© 1997 - 2008
American Registry for Internet Numbers,
All Rights Reserved.