On 4/23/2013 18:04, Leo Bicknell wrote:

In a message written on Tue, Apr 23, 2013 at 05:41:40PM -0400, Valdis Kletnieks wrote:

...

I didn't see any mention of this Tony Hain paper:

http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf

tl;dr: ARIN predicted to run out of IP space to allocate in August this year.

Here's a Geoff Houston report from 2005: https://www.arin.net/participate/meetings/reports/ARIN_XVI/PDF/wednesday/hus...

I point to page 8, and the prediction "RIR Pool Exhaustion, 4 June 2013".

Those of us who paid attention are well prepared.

tl;dr: Real statistical models properly executed in 2005 were remarkably close to the reality 8 years later.

On that note, something Mr. Huston wrote more recently: "A Primer on IPv4, IPv6 and Transition" http://www.potaroo.net/ispcol/2013-04/primer.html Discussion: https://news.ycombinator.com/item?id=5586519 -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post - http://goo.gl/YrmAb Don't CC me! I'm subscribed to whatever list I just posted on.

On 24/04/2013, at 8:10 AM, Andrew Latham <lathama@gmail.com> wrote:

On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks <Valdis.Kletnieks@vt.edu> wrote:

...

I didn't see any mention of this Tony Hain paper:

http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf

ARIN predicted to run out of IP space to allocate in August this year.

Are you ready?

The prediction of runout business is extremely hard. All of these predictions are based on the basic premise that what happened yesterday will most likely happen tomorrow. And in a world of very large populations this is highly likely - the larger the population its often the case that the smaller the impact of individual variations in behaviour. That means that once you get a very large population you'd expect a relatively low level of uncertainty in trend-based predictive models. But the world of addresses is not so well behaved. For some years now we've seen the address world bifurcate into a small number of very large actors and a large number of much smaller actors. In the address world it was observed that less than 1% (its closer to around 0.5%) individual allocations account for more than half of the number of allocated addresses. This becomes a problem in the predictive models, as the dominant factor in address consumption is now the actions of some 20 or so very large entities. If they all fronted at the registry's front doors and asked for a three month allocation, and do so again in 90 days, and so on, then its pretty obvious that ARIN's remaining 40M addresses would not last more than one or two iterations of this cycle. But what has been apparent in the ARIN region since the IANA runout of February 2011 has not been panic, but restraint. If you look at the run-down' of the address pool in ARIN over time (http://www.potaroo.net/tools/ipv4/arin-pool.png), you could certainly make the case that there was a pronounced run on address resources in ARIN in the last quarter of 2010, but it all changed in 2011. The ensuing 14 months following IANA runout, through 2011 and early 2012, saw a pronounced change in the region, and ARIN's address consumption in that period slowed down to a consumption rate that got as low as 1M addresses per month. This coincided in a change in the address allocation policy to reduce the time horizon of "demonstrated need" from 12 months to 3 months, but that factor alone would not account for the entirety of this slow down in the address consumption rates over this 14 month period. Following a single largish allocation in early 2012 we've seen the ARIN address consumption rate increase somewhat, and the average rate of address consumption is currently around 2M addresses per month. If this rate of address consumption continues, the ARIN will reach its last /8 in early 2014, and if this rate persists, then the registry will exhaust its pool around the end of that year, or early 2015. But given the uncertainty factors here as they relate to the distribution of large and small consumers in this area and changing sentiment about whether or not panic is a factor in address demands, I'd have to comment that the uncertainty factor of any prediction is high. Its quite plausible that exhaustion could occur some 6 - 9 months earlier than these dates. However, personally I find it a little hard to place a high probability on Tony's projected exhaustion date of August this year. I also have to qualify that by noting that while I think that a runout of the remaining 40 M addresses within 4 months is improbable, its by no means impossible. If we saw a re-run of the address consumption rates that ARIN experienced in 2010, then it's not outside the bounds of plausibility that ARIN will be handing out its last address later this year. thanks, Geoff

On Wed, Apr 24, 2013 at 10:55:51AM +0200, Mikael Abrahamsson wrote:

I also find it a bit strange that the runout in APNIC and RIPE was very different. APNIC address allocation rate accelerated at the end, whereas RIPE exhaustion date kept creeping forward in time instead of closer in time, giving me the impression that there wasn't any panic there.

RIPE had shrinking allocation windows (12/9/6/3 months) and increasingly strict scrutining of requests. Even in 3 months window period, people showing need for >55k of IPs for that 3 months only got /17+/18 (48k) instead of /16 one would expect - so in fact the windows were even shorter in practise. Geoff pointed out the large alloc players having a huge impact in the end game scenario - this was effectively neutralized by this "soft landing" policy, I'd say. I'm not aware that APNIC also had such a "soft landing" policy in effect, but I didn't monitor closely. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Wed, Apr 24, 2013 at 6:37 AM, Geoff Huston <gih@apnic.net> wrote:

But then again APNIC and RIPE NCC both had last /8 policies in place, which has mitigated some of the impacts of address pool exhaustion. For smaller actors there is still a source of addresses in these regions, albeit a very limited trickle of addresses, but there is still some. As I understand it, ARIN will continue allocating right to the end of their IPv4 address pool and not hold back any addresses for this "last chance" trickle feed, or have I missed something crucial in ARIN's policy handbook?

Nope, you are correct Geoff. There is a /10 reserved for transition technologies (e.g. outside addresses on a CGN) and there is a "critical infrastructure" reserve, but no general purpose reserve like in RIPE and APNIC. ~Chris

Geoff

-- @ChrisGrundemann http://chrisgrundemann.com

On Wed, Apr 24, 2013 at 8:07 AM, Tore Anderson <tore@fud.no> wrote:

* Chris Grundemann

...

Nope, you are correct Geoff. There is a /10 reserved for transition technologies (e.g. outside addresses on a CGN) and there is a "critical infrastructure" reserve, but no general purpose reserve like in RIPE and APNIC.

One interesting thing is that this is dedicated specifically for transition/deployment of *IPv6*. So the way I understand it, you won't get any space from this block to number the outside of a NAT444-style CGN, while you would for a NAT64-style CGN.

https://www.arin.net/policy/nrpm.html#four10

That's a very good clarification, thanks Tore.

Tore

-- @ChrisGrundemann http://chrisgrundemann.com

On 26/04/2013, at 4:27 PM, joel jaeggli <joelja@bogus.com> wrote:

...

I also find it a bit strange that the runout in APNIC and RIPE was very different. APNIC address allocation rate accelerated at the end, whereas RIPE exhaustion date kept creeping forward in time instead of closer in time, giving me the impression that there wasn't any panic there.

apnic allocation reserved the final /8 for /22 maximal allocations. Couple that with some qualifying very large assignments towards the end of stage two e.g between feb 1 and april 14 2011 7 provider assignments combined soaked up more than 2 /8s and you get rapid runout towards the endgame.

APNIC used a 12 month allocation window right up to the point of exhaustion, while RIPE was operating on a 3 month window, as is ARIN. That may be a contributing factor in explaining the differences in behaviour in the final months / weeks. But its not just that. Other factors include large developing countries with massive DSL deployments underway (China, India) mean that in the APNIC region we were not looking at a wired infrastructure market sector that was already saturated. Quite the opposite. Similarly the wireless market in Asia was / is expanding rapidly for much the same reason (wireless is cheaper to deploy than wired if you have absolutely no pre-installed wireless infrastructure). i.e. the unmet demand overhang as compared to the available address pools was massive in Asia. Now that does not imply that Europe and the Middle East has no demand overhang, but perhaps not on the same scale as was experienced by APNIC in early 2011. Also in September last year the European financial situation was still impacting on the problems of the service industry (and still is in many countries). So the underlying capital-driven demand factors were different between Europe and Asia. Perhaps it was more challenging for European entities to demonstrate an expansion of their Internet service infrastructure over rolling 3 months windows due to a slow down in consumer demand in parts of Europe. What factors will play out in the North American market? It might be interesting to look at address allocations by country by year. One such table of the top 10 countries in terms of IPv4 allocations since 2007 is at http://www.potaroo.net/ispcol/2013-01/2012.html, table 3.The peak US year was 2007 with 48M addresses. in 2011 ARIN introduced the 3 month allocation window, and allocating that year halved from the previous year. Last year they were a little higher at 28M addresses. What drove last year's numbers in ARIN was a total of 16M addresses allocated to Canadian entities. So to what extent is this a saturated market already in terms of the deployment of service infrastructure? To what extent are new devices simply replacing old, and to what extent are the dynamics of the market in that region driven by provider churn as distinct from greenfields expansion? Obviously the answers to such questions have a strong impact on the underlying model of overall demand for more addresses in the region. And of course one of the hardest factors of all: Panic is extremely difficult to model. Most forms of predictive modelling reach back in time and then use that date to push forward. but panic is of course different. It does not drive off past behaviour but feeds off itself. The APNIC runout was exceptionally hard to model at the time because the incidence of large allocations rose very quickly in March. Yes, I'd ascribe that to panic. That reaction was not so evident in RIPE in August / September last year. So it appears that panic, or the level of panic, is not a constant factor. Different regions at different times appear to elicit different responses to impending exhaustion. Geoff

On Apr 26, 2013, at 10:23 AM, Chris Grundemann <cgrundemann@gmail.com> wrote:

One interesting twist in all of this is that several of these new "slow-start" players in the ARIN region seem to be servicing customers outside of the region with equipment and services hosted here inside the ARIN region (see slide 12 on the ARIN 31 "Policy Implementation and Experience Report" https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_...).

NANOG Folks - Please read this slide deck, section noted by Chris. It explains the "situation"... (I would not call the sudden acceleration in IP address issuance a problem, per se, as that is an judgement for the community either way.) FYI, /John John Curran President and CEO ARIN

Lee Howard wrote:

On 4/23/13 7:44 PM, "Geoff Huston" <gih@apnic.net> wrote:

...

On 24/04/2013, at 8:10 AM, Andrew Latham <lathama@gmail.com> wrote:

...

On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks <Valdis.Kletnieks@vt.edu> wrote:

...

I didn't see any mention of this Tony Hain paper:

http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf

ARIN predicted to run out of IP space to allocate in August this year.

Are you ready?

The prediction of runout business is extremely hard. All of these predictions are based on the basic premise that what happened yesterday will most likely happen tomorrow.

If I were any good at predicting things, I would use my powers for evil. Your model and Tony's differ largely on how many "yesterdays" are considered; and, Tony's new model weights yesterday more heavily than yesteryear, on the guess that recent history is more predictive than distant past history.

Indeed, the current set of actors appears to be different than the historical set, with a very different deployment-model/demand-curve.

Meanwhile. . .

...

actors. In the address world it was observed that less than 1% (its closer to around 0.5%) individual allocations account for more than half of the number of allocated addresses. This becomes a problem in the predictive models, as the dominant factor in address consumption is now the actions of some 20 or so very large entities.

Fortunately, very large companies are slow to change. Also, John Curran said during discussion at PPML of extra-regional allocations: "At the current rate, this is the majority of allocations

we're

making." So, a different 0.5% than most people are probably thinking of.

I believe he said this growth trend "Leads to a runout Q4-2013 or Q1-2014, with certainty."

...

Following a single largish allocation in early 2012 we've seen the ARIN address consumption rate increase somewhat, and the average rate of address consumption is currently around 2M addresses per month. If this rate of address consumption continues, the ARIN will reach its last /8 in early 2014, and if this rate persists, then the registry will exhaust its pool around the end of that year, or early 2015.

Sorry, is this to say, "If this rate of consumption continues" or "If this rate of increase continues"? I believe the difference is that several organizations are rapidly progressing through ARIN slow start, using their space in significantly less than three months.

I only looked at organizations that had multiple allocations larger than a /20 in the last 9 months. There may well be as many, or more that have had multiple /22,/21,/20 sequences in that window, but if they are that small at this point, they might never get to a /16 before the pool runs out if the larger ones keep going.

...

However, personally I find it a little hard to place a high probability on Tony's projected exhaustion date of August this year.

I was not trying to place any probability on the outcome, and would tend to agree with you that August 2013 is not particularly likely, but would say it much more likely than having anything left by August 2014. That said, a new set of players showing compound growth in short timeframes is not what the historical-model projections are based on, so we do need to look more at current behavior than the distant past.

...

I also have to qualify that by noting that while I think that a runout of the remaining 40 M addresses within 4 months is improbable, its by no means impossible. If we saw a re-run of the address consumption rates that ARIN experienced in 2010, then it's not outside the bounds of plausibility that ARIN will be handing out its last address later this year.

It largely depends on whether the new organizations getting address space hit a growth ceiling (or plateau). If they do so soon, we return to the nearly linear Potaroo Projection. If they continue to grow (especially if they represent a new business model and others follow suit) then the Hain Hypothesis holds.

There is another open question about the growth rate in the number of new players showing compound growth in deployments. It may not be that any of them individually gets large enough to make a significant dent on their own, but if there is compound growth in the number of new slow-start actors, you still have compound growth in demand, but you may not be looking in the right place to see why the numbers are large enough to matter. The really troubling thing that I don't get is why RR got a pile of little blocks rather than a /12 up front. I don't know if that is an impact of broken policy, internal deployment decisions about 'right size' allocations rather than intentional deaggregation, or trying to 'fly under the radar'. If it is a policy problem it might be worth trying to understand and maybe fix any long term impact on market transfers. Tony

Lee

...

thanks,

Geoff

On Wed, 24 Apr 2013, Fred Baker (fred) wrote:

http://www22.verizon.com/Support/Residential/Internet/HighSpeed/General+Supp...

One minor typo in this one, that I've emailed Verizon's webmasters about in the past. A /56 does not give you 56 LANs... jms

On Apr 24, 2013, at 6:48 PM, "Justin M. Streiner" <streiner@cluebyfour.org> wrote:

On Wed, 24 Apr 2013, Fred Baker (fred) wrote:

...

http://www22.verizon.com/Support/Residential/Internet/HighSpeed/General+Supp...

One minor typo in this one, that I've emailed Verizon's webmasters about in the past.

A /56 does not give you 56 LANs…

LOL… No, it's 256 LANs. I think that's the first time I've ever seen VZ under promise. ;-) Owen

On Apr 24, 2013, at 4:50 PM, Michael Thomas <mike@mtcc.com> wrote:

On 04/24/2013 03:26 PM, Fred Baker (fred) wrote:

...

Frankly, the ISPs likely to be tracking this list aren't the people holding back there. To pick on one that is fairly public, Verizon Wireline is running dual stack for at least its FIOS customers, and also deploying CGN, and being pretty up front about the impacts of CGN. Verizon Wireless, if I understand the statistics available, is estimated to have about 1/4 of its client handsets accessing Google/Yahoo/Facebook using IPv6.

Fred, isn't the larger problem those enterprise's outward facing web presence, etc? As great as it is that vzw is deploying on handsets, don't they also need to dual-stack and by inference cgn (eventually) so that their customers can get at the long tail of non-v6 sites?

Kind of my point. I hear a lot of complaining of the form "I don't need to deploy IPv6 because there is relatively little traffic out there." Well, surprise surprise. That's a little like me saying that I don't need to learn Chinese because nobody speaks to me in Chinese. There are a lot of Chinese speakers; they don't speak to me in Chinese, which they often prefer to speak among themselves, because I wouldn't have a clue what they were saying. The Verizon Wireless numbers, and a list of others on the same page, tell me that if offered a AAAA record, networks and the equipment that use them will in fact use IPv6. What is in the way is the residential gateway, which is often IPv4-only, and the enterprise web and email service, which is often IPv4 only. You want to fix that, fix the residential gateway, the enterprise load balancer, and the connectivity between them and their respective upstreams.

Frankly, the ISPs likely to be tracking this list aren't the people holding back there. To pick on one that is fairly public, Verizon Wireline is running dual stack for at least its FIOS customers, and also deploying CGN, and being pretty up front about the impacts of CGN. Verizon Wireless, if I understand the statistics available, is estimated to have about 1/4 of its client handsets accessing Google/Yahoo/Facebook using IPv6.

http://www.verizon.com/support/residential/internet/highspeedinternet/networ... http://www22.verizon.com/Support/Residential/Internet/HighSpeed/General+Supp... http://www.worldipv6launch.org/measurements/

As an iPhone 5 user on VZW, I can say that they have done a really good job of deploying IPv6 on both 3GPP and LTE networks. My phone runs dual-stack everywhere I'm not roaming so far. Performance over IPv6 has been at least as good as performance over IPv4. While I'm not a huge VZW fan, they really have done this well and other carriers should look to them as a model for IPv6 deployment on cellular. The one unfortunate aspect is that if you are on an IPv4-only WiFi network, you will be unable to access any IPv6 sites via the carrier network and they will, instead, fail. For the moment, while there are not many IPv6-only websites, this is probably not a significant drawback. It's probably intended as a workaround for the "IPv6 Unexpected Data Bill" problem.

Where we're having trouble is in enterprise and residential deployments. Enterprise tends to view the address space run-out as Somebody Else's Problem - behind their NATs, they generally have enough address space to work with. On the residential side, the X-Box is still IPv4-only, Skype is still IPv4-only, the vast majority of residential gateways used by broadband subscribers are IPv4-only.

"We have enough address space" doesn't really take into account the fact that you probably aren't on the internet only to talk to yourself. If you want the users behind your NAT to be able to talk to the InterNET and not just the IPv4 InterNAT, then you're going to need to give them some form of IPv6 capability. The residential side is a problem which I believe will solve itself relatively quickly over the next 5-7 years. The cost of maintaining residential IPv4 service beyond that point (indeed, even to that point) is going to result in costs per subscriber that exceed current billing rates. Just to break even, most providers will have to convince their subscribers to pay approximately double what they currently pay while accepting progressively more degraded IPv4 service. Indeed, there are some models emerging that show that the cost of lost customers by switching residential to IPv6-only is likely less than the cost of maintaining customers on IPv4.

Some broadband ISPs are taking steps toward a managed service offering, by selling their customers a replacement router. If the router is IPv6-capable, that helps.

This is becoming more popular. Other ISPs are also specifying IPv6-compatible equipment that their customers can upgrade to.

If we really want to help the cause, I suspect that focusing attention on enterprise, and finding ways to convince them that address shortages are also their problem, will help the most.

Actually, if you want to have the biggest and best impact, it's getting the rest of the Alexa 1,000 onto IPv6. Eyeball and Enterprise conversion will happen soon enough out of necessity. However, if content is still not available on IPv6 at that point, it will drive strange contortions to attempt to keep IPv4 on progressively more complex and delicate forms of life support. If the content is all available on IPv6, then it will be mostly a non-event to start turning up IPv6-only end-users. Owen

So here is the question I have: when we run out, is there *anything* that will reasonably allow an ISP to *not* deploy carrier grade NAT? Assuming that it's death for the ISP to just say no to the long tail of legacy v4-only sites? One thing that occurs to me though is that it's sort of in an ISP's interest to deploy v6 on the client side because each new v6 site that lights up on the internet side is less traffic forced through the CGN gear which is ultimately a cost down. So maybe an alternative to a death penalty is a molasses penalty: make the CGN experience operable but bad/congested/slow :) Mike On 04/25/2013 07:12 AM, Arturo Servin wrote:

Yes.

We figured this out and we are starting a program (or a set of activities) to promote the deployment of IPv6 in what we call "End-users organizations" (basically enterprises, universities). We are seeing much lower adoption numbers than our ISP's categories.

One basic problem that we have found when talking with enterprises is that the perceived value of deploy v6 is near to zero as they have v4 addresses (universities) or NAT.

Regards, as

On 4/24/13 6:26 PM, Fred Baker (fred) wrote:

...

If we really want to help the cause, I suspect that focusing attention on enterprise, and finding ways to convince them that address shortages are also their problem, will help the most.

On Thu, 25 Apr 2013, John Levine wrote:

Once people realize that there's no more free v4 space to be had, or only little bits, that the market will develop and a lot of space will appear for sale. For example, there's an educational insitution near Boston that's sitting on a /8. If the price for a clean /12 turns out to be $5M, which I don't think is implausible, it'll be mighty tempting for them to renumber into one /12 and sell off the others for a quick $75 million.

There is a lot of speculation what IPv4 addresses are worth, I've been hearing everything from a few USD to 20 EUR per address. If it's 20 EUR per address, then I agree with you that there will be a lot of addresses available for sale because it'll now all of a sudden be worthwile to renumber, start using IPv6 with NAT64, or something else, and get rid of your now excess IPv4 addresses. Most organisations will probably be able to do this with costs ranging in 0.1 - a few million dollars. I like this because it makes the incentive to move to IPv6 so much higher. IPv4 is a dead end, the stone is bled dry, the earlier people realise this and move on, the better.

I entirely realize that the sound of people yelling that it's totally unfair that other people got their space for free and now they have to pay will be deafening. Too bad. Back in the early 90s I missed the cutoff to get my own unjustified /24 by about six months, but I've been able to deal with it.

If there is no upside for people holding addresses to spend time/money to free them up, these addresses won't get freed up and transferred. -- Mikael Abrahamsson email: swmike@swm.pp.se

There was some good information shared at the recent INET Denver on value vs. price and how to determine value of an IPv4 address, you can watch the panel discussion on YouTube: http://youtu.be/v43CGqq70rM.

amusing how much curran is interested in asserting his/arin's power and rights and how little he speaks to the interest of the internet and the isps. randy

...

amusing how much curran is interested in asserting his/arin's power and rights and how little he speaks to the interest of the internet and the isps. The power is in the hands of this community

what bollocks

sorry, bug in .procmailrc. bye.

On Thu, 25 Apr 2013, Michael Thomas wrote:

So here is the question I have: when we run out, is there *anything* that will reasonably allow an ISP to *not* deploy carrier grade NAT?

Do you count NAT64 or MAP as carrier grade NAT?

One thing that occurs to me though is that it's sort of in an ISP's interest to deploy v6 on the client side because each new v6 site that lights up on the internet side is less traffic forced through the CGN gear which is ultimately a cost down. So maybe an alternative to a death penalty is a molasses penalty: make the CGN experience operable but bad/congested/slow :)

Hm, sounds like NAT64 or MAP to me (although, honestly, we may end up making MAP "too good".) -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross

On Thu, 25 Apr 2013, Michael Thomas wrote:

On 04/25/2013 10:10 AM, Brandon Ross wrote:

...

On Thu, 25 Apr 2013, Michael Thomas wrote:

...

So here is the question I have: when we run out, is there *anything* that will reasonably allow an ISP to *not* deploy carrier grade NAT?

Do you count NAT64 or MAP as carrier grade NAT?

I suppose that the way to frame this as: does it require the ISP to carry flow statefulness in their network in places where they didn't have to before. That to my mind is the big hit.

NAT64 sure does. Take a look at MAP and be your own judge of weather it counts or not.

I was going to say that NAT64 could be helpful, but thought better of it because it may have its own set of issues. For example, are all of the resources *within* the ISP v6 available?

Um, yes, why wouldn't they be?

They may be a part of the problem as well as a part of the solution too. I would think that just the prospect of having a less expensive/complex infrastructure would be appealing as v6 adoption ramps up, and gives ISP's an incentive to give the laggards an incentive.

It's no longer clear to me what your problem statement is. If the problem is that you want something that does NATish things so that v4 still works, but v6 works better, I think NAT64 is worthy of your scrutiny. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross

On 04/25/2013 11:09 AM, Owen DeLong wrote:

On Apr 25, 2013, at 11:24 AM, Michael Thomas <mike@mtcc.com> wrote:

...

So here is the question I have: when we run out, is there *anything* that will reasonably allow an ISP to *not* deploy carrier grade NAT? Assuming that it's death for the ISP to just say no to the long tail of legacy v4-only sites? This assumes facts not in evidence. However, given that assumption, it's not so much a question of whether to CGN, but how. It looks like it may be far better, for example, to do something like 464xlat with an all IPv6 network than to run dual-stack with NAT444 or DS-LITE.

There's no shortage of possible ways to run IPv4 life support, but they're all life support. You have all the same risks as human life support…

Intracranial pressure, diverse intravascular coagulopathy (DIC), stroke (CVA), embolisms, etc. In the network, we refer to these as router instability, state table overflow, packet loss, bottlenecks, etc.

Other options include NAT64/DNS64, A+P, etc.

Bottom line… The more IPv6 gets deployed on the content side, the less this is going to hurt. Eyeballs will be forced to deploy soon enough. It's content and consumer electronics that are going to be the most painful laggards.

At some level, I wonder how much the feedback loop of "providers won't deploy ipv6 because everybody says they won't deploy ipv6" has caused this self-fulfilling prophecy :/ On the other hand, there is The Cloud. I assume that aws and all of the other major vm farms have native v6 networks by now (?). I hooked up v6 support on linode in, oh, less than an hour for my site. Maybe part of this just evangelizing with the Cloud folks to get the word out that v6 is both supported *and* beneficial for your site? And it might give them a leg up with "legacy" web infrastructure data centers to lure them? "Oh, your corpro IT guys won't light up v6? let me show you how easy it is on $MEGACLOUD". Mike

On 04/25/2013 07:27 PM, Owen DeLong wrote:

...

At some level, I wonder how much the feedback loop of "providers won't deploy ipv6 because everybody says they won't deploy ipv6" has caused this self-fulfilling prophecy :/ It's a definite issue. The bigger issue is the financial incentives are all in the wrong direction.

Eyeball networks have an incentive not to deploy IPv6 until content providers have done so or until they have no other choice.

Yet, eyeball networks are the ones being asked to pony up all of the cost to put in place the hacks to keep v4 running so they don't get support center calls. That's a pretty asymmetric, and a potential opportunity.

...

On the other hand, there is The Cloud. I assume that aws and all of the other major vm farms have native v6 networks by now (?). I hooked up You again assume facts not in evidence. Many cloud providers have done IPv6. Rackspace stands out as exemplary in this regard. Linode has done some good work in this space.

AWS stands out as a complete laggard in this area.

Heh... that's why I put all kinds of question marks and hedges :) That's disappointing about aws. On the other hand, if aws lights up v6, a huge amount of content will be v6 capable in one swell-foop. Which is a different problem of death by a thousand cuts of corpro data centers, and racked up servers in no-name cages.

...

v6 support on linode in, oh, less than an hour for my site. Maybe part of this just evangelizing with the Cloud folks to get the word out that v6 is both supported *and* beneficial for your site? And it might give them a leg up with "legacy" web infrastructure data centers to lure them? "Oh, your corpro IT guys won't light up v6? let me show you how easy it is on $MEGACLOUD". +1 -- I encourage people to seek providers that support IPv6.

Name. and. shame. At some level, some amount of bs is probably useful to scare the suits: "OMG, VZW'S PHONES SUPPORT V6, DO WE DO THAT????". Roll your eyes, but, well, remember they're suits. Mike

On 4/25/13 10:16 PM, Matt Palmer wrote:

On Thu, Apr 25, 2013 at 07:49:03PM -0700, Michael Thomas wrote:

...

On 04/25/2013 07:27 PM, Owen DeLong wrote:

...

AWS stands out as a complete laggard in this area. Heh... that's why I put all kinds of question marks and hedges :) That's disappointing about aws. On the other hand, if aws lights up v6, a huge amount of content will be v6 capable in one swell-foop. Even if the only thing that supported IPv6 was ELB, and everything else was still IPv4 internally, that'd put a lot of traffic on IPv6 very quickly, and ELB is something *entirely* controlled by AWS (you CNAME to an ELB FQDN, AWS takes care of resolution and proxies a TCP connection to your instance). elb ipv6 support has been in place for some time (may 2011 for us east and ireland)

"IPv6 support is currently available in the following Amazon EC2 regions: US East (Northern Virginia), US West (Northern California), US West (Oregon), EU (Ireland), Asia Pacific (Tokyo), and Asia Pacific (Singapore).?

- Matt

On Apr 25, 2013 10:29 PM, "joel jaeggli" <joelja@bogus.com> wrote:

On 4/25/13 10:16 PM, Matt Palmer wrote:

...

On Thu, Apr 25, 2013 at 07:49:03PM -0700, Michael Thomas wrote:

...

On 04/25/2013 07:27 PM, Owen DeLong wrote:

...

AWS stands out as a complete laggard in this area.

Heh... that's why I put all kinds of question marks and hedges :) That's disappointing about aws. On the other hand, if aws lights up v6, a huge amount of content will be v6 capable in one swell-foop.

Even if the only thing that supported IPv6 was ELB, and everything else

was

...

still IPv4 internally, that'd put a lot of traffic on IPv6 very quickly, and ELB is something *entirely* controlled by AWS (you CNAME to an ELB FQDN, AWS takes care of resolution and proxies a TCP connection to your instance).

elb ipv6 support has been in place for some time (may 2011 for us east and ireland)

"IPv6 support is currently available in the following Amazon EC2 regions: US East (Northern Virginia), US West (Northern California), US West (Oregon), EU (Ireland), Asia Pacific (Tokyo), and Asia Pacific (Singapore).?

Yeah, I thought AWS ELB supported ipv6 too. But if your ELB is tied to a VPC, that is NOT supported. I learned that one the hard way, and now that is one less site that would be ipv6 but is not. CB.

...

- Matt

* Owen DeLong

Quite the contrary… I personally think that the abysmal rate of IPv6 adoption among some content providers (Are you listening, Amazon, Xbox, BING?) is just plain shameful.

FWIW, www.bing.com resolves to IPv6 addresses from where I'm sitting (Oslo), and the page seems to load over IPv6 as well. Also, Amazon provides some form of IPv6 (I believe it's based on 6RD or something similar though). At least, the NLNOG RING has six Amazon-hosted nodes, all with IPv6 enabled (amazon0{1..6}.ring.nlnog.net). All of them respond to ICMPv6 pings from here. Whether or not the average Amazon customer chooses to enable IPv6 or not is another story, though.. Tore

Once upon a time, Owen DeLong <owen@delong.com> said:

As I understand it you can get some funky level of IPv6 on some of the older AWS products. I'm glad to hear that BING is now on IPv6. Guess they were getting scroogled for that failure. ;-)

I believe Bing is Akamaized (it is for me anyway), so whether you see Bing on IPv6 is based on whether the Akamai cluster you are pointed to has IPv6 (it does for me). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

On 04/26/2013 05:37 AM, Tore Anderson wrote:

* Owen DeLong

...

Quite the contrary… I personally think that the abysmal rate of IPv6 adoption among some content providers (Are you listening, Amazon, Xbox, BING?) is just plain shameful.

FWIW, www.bing.com resolves to IPv6 addresses from where I'm sitting (Oslo), and the page seems to load over IPv6 as well.

If you use firefox, the sixornot plugin will tell you that for sure. About 10 of the resources loaded are over IPv6, about 9 are not. Doug

Bing supports IPv6: http://www.worldipv6launch.org/

Noted.

The site www.xbox.com supports IPv6 (ditto), but the Xbox device does not.

Noted.

My favorite place to see what content supports IPv6 is Eric Vyncke's site: http://www.vyncke.org/ipv6status/detailed.php?country=us

An excellent resource.

Thus, Microsoft points off for live.com, msn.com, microsoft.com, etc.

Similarly, partial credit to Amazon for ELB on AWS [1], but points off for amazon.com, ebay.com, and for pity's sake, aws.amazon.com and amazonaws.com.

[1] http://aws.amazon.com/about-aws/whats-new/2011/05/24/elb-ipv6-zoneapex-secu ritygroups/

But to see the rest, you have come to NANOG58 in New Orleans!

Thanks for providing those links, Lee. Definitely worth watching.

...

Actually, if Amazon.com lit up IPv6, it would dramatically change the IPv6-only client landscape. I believe they are the single largest IPv4-only content provider remaining. IIRC from Lee's statistics, Amazon + any 2 other members of the Alexa 100 would make it possible for 70% or more of web traffic to go over IPv6.

Not mine; Alain Fiocco's numbers at http://6lab.cisco.com/stats/ It's not quite that positive, either, but you can see in the Information page of that site that there's a very sharp bend in which sites get the most hits. The top 15-20 are disproportionate; after that, in many cases substitute web sites are available.

Thanks… Thanks for the reference as well.

...

I've been doing just that. Interestingly, I got a great deal of criticism for doing so recently.

Where do you name and shame suits? Hint: it isn't NANOG.

In the case to which I refer, it was Facebook.

Lee, who has been known to wear a suit

And who I occasionally attempt to shame for the slow pace of IPv6 deployment at TW Cable. ;-) Owen

I find it more entertaining that I recognized no less than three organizations on that list that we've seen come up a lot recently in our spam scanning systems.

-----Original Message----- From: Andrew Latham [mailto:lathama@gmail.com] Sent: Tuesday, April 23, 2013 6:11 PM To: Valdis Kletnieks Cc: nanog@nanog.org Subject: Re: "It's the end of the world as we know it" -- REM

...

I didn't see any mention of this Tony Hain paper:

http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf

tl;dr: ARIN predicted to run out of IP space to allocate in August

On Tue, Apr 23, 2013 at 5:41 PM, Valdis Kletnieks <Valdis.Kletnieks@vt.edu> wrote: this year.

...

Are you ready?

I have sadly witnessed a growing number of businesses with /24s moving to colocation/aws networks and not giving up their unused network space. I assume this will come into play soon. I have already read the news of blackmarket sales of network allocations in Europe.

-- ~ Andrew "lathama" Latham lathama@gmail.com http://lathama.net ~

On Tue, 23 Apr 2013, Andrew Latham wrote:

...

http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf

tl;dr: ARIN predicted to run out of IP space to allocate in August this year.

http://www.potaroo.net/tools/ipv4/ says April 2014. That page worked well for the RIPE region.

I assume this will come into play soon. I have already read the news of blackmarket sales of network allocations in Europe.

It's not black market anymore, it's official. RIPE even has a web site where one can advertise that one wants to buy or sell. -- Mikael Abrahamsson email: swmike@swm.pp.se

On Wed, 24 Apr 2013, Tore Anderson wrote:

...

I have already read the news of blackmarket sales of network allocations in Europe.

Interesting. Do you have a link or some other kind of reference?

<http://www.ripe.net/lir-services/resource-management/listing> is a "white market sales" place. Perhaps that's what the previous poster meant. Searching for "IPv4 broker" yields a lot of results as well, that might be the "black market" though. -- Mikael Abrahamsson email: swmike@swm.pp.se

* Tore On Wed, Apr 24, 2013 at 1:46 AM, Tore Anderson <tore@fud.no> wrote:

* Andrew Latham

...

I have sadly witnessed a growing number of businesses with /24s moving to colocation/aws networks and not giving up their unused network space. I assume this will come into play soon.

A couple of /24s being returned wouldn't make a significant difference when it comes to IPv4 depletion. Heck, not even a couple of /8s would. Trying to reclaim and redistribute unused space would be a tremendous waste of effort.

If I can walk around a smallish town and point at 5 businesses like this its a possible solution. I am not claiming a few /24s will do, I am claiming that there are many (for larger values of many) companies like this.

...

I have already read the news of blackmarket sales of network allocations in Europe.

Interesting. Do you have a link or some other kind of reference?

I did a quick search and they are easy to find. Many news articles about Microsoft buying network allocations at auction to set a price of ~$11USD per IP. One tangent article that I liked was http://www.datacenterknowledge.com/archives/2012/07/16/ipv4-addresses-now-dr...

Tore

-- ~ Andrew "lathama" Latham lathama@gmail.com http://lathama.net ~

On Wed, Apr 24, 2013 at 12:55 PM, Lee Howard <Lee@asgard.org> wrote:

On 4/24/13 10:18 AM, "Andrew Latham" <lathama@gmail.com> wrote:

...

* Tore

On Wed, Apr 24, 2013 at 1:46 AM, Tore Anderson <tore@fud.no> wrote:

...

* Andrew Latham

...

I have sadly witnessed a growing number of businesses with /24s moving to colocation/aws networks and not giving up their unused network space. I assume this will come into play soon.

A couple of /24s being returned wouldn't make a significant difference when it comes to IPv4 depletion. Heck, not even a couple of /8s would. Trying to reclaim and redistribute unused space would be a tremendous waste of effort.

If I can walk around a smallish town and point at 5 businesses like this its a possible solution. I am not claiming a few /24s will do, I am claiming that there are many (for larger values of many) companies like this.

Look at NRO statistics prior to APNIC and RIPE final /8 (runout). It's pretty linear growth. Is that the real demand for IPv4 addresses? In the last couple of years it was 10-15 /8 equivalents.

How many addresses do you think can be released (whether reclaimed or, as is more likely, brought into the market)? A /8? Five /8s? Say it's a billion addresses made available to a market. That only feeds demand for 18-30 months.

A demand curve would show that as prices increase, there is demand for fewer IPv4 addresses. However, nobody knows the slope of the curve (other than my speculation about cost of IPv6 and TCO of CGN as points where the demand shifts). A supply curve would show that as prices increase, more addresses become available (transfers, renumbering, eventually substitution). I'm working on ideas about that slope.

Lee

Lee Totally agree, your point is the larger issue at hand, just pointing out and ugly issue that I witnessed recently. Corporate networks and ASNs totally off and not in use. But don't worry, they will use them if someone tries to take them away. -- ~ Andrew "lathama" Latham lathama@gmail.com http://lathama.net ~

CGN "works" for eyeball networks, but not for hosting. From the remarks at this week's ARIN meeting, that's where ARIN has seen an uptick in requests. So those who sell virtual machines, IPv4 addresses are critical if they want make their offering viable in the near-term. Frank -----Original Message----- From: David Conrad [mailto:drc@virtualized.org] Sent: Wednesday, April 24, 2013 12:27 PM To: Andrew Latham Cc: nanog@nanog.org Subject: Re: "It's the end of the world as we know it" -- REM On Apr 24, 2013, at 9:59 AM, Andrew Latham <lathama@gmail.com> wrote:

...

A demand curve would show that as prices increase, there is demand for fewer IPv4 addresses.

And the other side of the coin: where there is demand and excess supply (e.g., allocated but unused addresses), the price increase would create an incentive to sell off the excess (i.e., what we're seeing in the IPv4 trading markets).

Totally agree, your point is the larger issue at hand, just pointing out and ugly issue that I witnessed recently. Corporate networks and ASNs totally off and not in use. But don't worry, they will use them if someone tries to take them away.

Or they'll sell/lease them. The prospective address consumer then can figure out whether paying the buy/rent price for new IPv4 addresses makes sense compared to moving to IPv6+translation or buying (more) CGN. Regards, -drc

*Tore <snip>

That said - such speculation may well turn out to be correct, of course, and being involved in the RIPE community I'm genuinely interested in the topic. Therefore I was hoping you'd point me in the direction of "the news of blackmarket sales of network allocations in Europe" you mentioned you have read.

Tore

I am digging though the some old posts. I seam to remember the article was not in English and I posted it with a link/via Google Translate. Sorry for being so slow. -- ~ Andrew "lathama" Latham lathama@gmail.com http://lathama.net ~

On Wed, Apr 24, 2013 at 1:42 PM, Andrew Latham <lathama@gmail.com> wrote:

FYI, What can ARIN, RIPE et al do to reclaim http://www.spamhaus.org/drop/drop.txt networks?

nothing since they don't control routability of the prefixes in question?

Black market is probably not the best phrase for the sources I have dug up today but here goes. Market Places http://addrex.net/ http://www.hilcostreambank.com/IPv4.asp http://www.kalorama.com/en/IPv4-IPv6-Advisory/IPv4-Acquisition-and-Divestitu... News http://www.networkworld.com/news/2011/041411-apnic-ipv4-gone.html http://paritynews.com/network/item/325-department-of-work-and-pensions-uk-in... http://www.networkworld.com/news/2011/042511-ipv4-sales.html http://www.forbes.com/sites/ciocentral/2011/09/15/pssst-rare-ipv4-addresses-... http://www.internetgovernance.org/2012/02/14/a-whole-8-for-sale/ http://www.prweb.com/releases/ipv4-ip-address/sale/prweb9552646.htm http://isc.sans.edu/diary/What's+Your+(IP)+Address+Worth%3F++/10765 -- ~ Andrew "lathama" Latham lathama@gmail.com http://lathama.net ~

On 4/29/13, Jérôme Nicolle <jerome@ceriz.fr> wrote:

Therefore it is inevitable to reclaim unused address space as long as there's a demand for IPv4, wich will still be strong as long as major players refuse to do their jobs.

The RIRs are very limited in what unused resources they could seek to reclaim; therefore, even if there are efforts, there are not likely to be a large number of resources reclaimed for the forseeable future -- not within 12 months. Such policy methods as transfer to specified recipient rules, and the ARIN STLS, for example, are the most likely path towards address "reclamation". The addresses that cannot be reclaimed in that manner, are probably uneconomical to reclaim, due to the resources, and long amount of time it would take a RIR to implement.

Moreover, I think it's necessary for all responsible LIR and RIRs to take a stand and vote policies to reclaim address space from networks who are still not deploying IPv6 as those obviously don't want to be a part of the Internet anymore.

The RIRs policy making authority is limited by certain contractual obligations, to resource holders, and to the community, and the RIRs cannot arbitrarily reclaim resources. They also cannot force a holder of a resource to release or abandon it, and attempts to do so for lack of V6 deployment, would only serve to reduce the legitimacy of the RIR, and result in network instability. The registration services agreements, at least in North American region say that the RIRs cannot revoke resources solely for lack of use. And some effort of the sort would more likely wind up in the courts. Tthe RIRs are not permitted or don't have authority to reclaim any IPv4 resources based on solely non-deployment of IPv6, even if there was some policy to that effect.

Jérôme Nicolle -- -JH

On Apr 29, 2013, at 2:46 PM, Lee Howard <lee@asgard.org> wrote:

On 4/29/13 1:03 AM, "Jérôme Nicolle" <jerome@ceriz.fr> wrote:

...

It is necessary to keep an acceptable churn and still allocate small blocks to newcomers, merely to deploy CGNs.

Not doing so would end up in courts for entry barrier enforced by a monopoly (the RIRs).

There is a /10 reserved to facilitate IPv6 deployment: https://www.arin.net/policy/nrpm.html#four10 "Reclamation" is facilitated by offering a financial benefit, i.e., selling underused addresses.

Note that under the "slow start" IPv4 address allocation policies, small ISPs do not qualify for an initial allocation from ARIN until they have utilized a provider-assigned block of the minimum size specified (based on being singly-homed or multi-homed.) These same criteria now apply to receipt of an address block via transfer, so at regional IPv4 free pool depletion may be _very_ difficult to satisfy. There are a number of ways of addressing this (changing initial ISP allocation policy, changing dependence on allocation policies for transfer approvals, establishing a reserved block for new entrants, etc.) but if left unaddressed will leave circumstances such that new entrants are precluded from participating in the transfer market as a recipient. This is the type of outcome that is generally frowned upon by governments for obvious reasons, and should be very carefully considered by the community. FYI, /John John Curran President and CEO ARIN

On 4/29/13, John Curran <jcurran@arin.net> wrote:

On Apr 29, 2013, at 2:46 PM, Lee Howard <lee@asgard.org> wrote:

...

On 4/29/13 1:03 AM, "Jérôme Nicolle" <jerome@ceriz.fr> wrote: specified (based on being singly-homed or multi-homed.) These same criteria now apply to receipt of an address block via transfer, so at regional IPv4 free pool depletion may be _very_ difficult to satisfy.

Huh? Where did that concept come from? There is no slow start criterion in the transfer rule, and a transfer is by definition not an initial allocation or assignment activity, even if the ISP is new, 4.2 is not shown to apply; there is a movement of an existing allocation, assignment, or part of one; between organizations, a movement of resources due to merger or acquisition or due to specified transfer does not create an initial allocation; And the transfer policy both 8.2 and 8.3 are very clear in that the minimum size is /24, and not the standard minimums for allocations with or without multihoming. Would you expect ARIN to ask the ISP to receive their first /24 by specified transfer, to show how they will use a /20 in 3 months too? Should there be any ambiguity, the transfer applicant will certainly demand the straightforward interpretation of the transfer rule, that does not require their first receipt of IPv4 resources to require slow start or holding a /20, prior to receiving their /24 through specified transfer, or their initial /16 or whatever through 8.3 merger & acquisition. Such restrictions would very obviously defeat the intent of 8.3; that resources may be transferred. But since conditions are listed on the recipiient of transfer, any conditions not listed are clearly excluded... -- -JH

On Tuesday, April 30, 2013, John Curran wrote:

On Apr 30, 2013, at 1:46 AM, Jimmy Hess <mysidia@gmail.com <javascript:;>> wrote:

...

On 4/29/13, John Curran <jcurran@arin.net <javascript:;>> wrote:

...

On Apr 29, 2013, at 2:46 PM, Lee Howard <lee@asgard.org <javascript:;>> wrote:

...

On 4/29/13 1:03 AM, "Jérôme Nicolle" <jerome@ceriz.fr <javascript:;>> wrote: specified (based on being singly-homed or multi-homed.) These same criteria now apply to receipt of an address block via transfer, so at regional IPv4 free pool depletion may be _very_ difficult to satisfy.

Huh? Where did that concept come from?

Alas, NRPM 8.3 requires that "the recipient must demonstrate the need for up to a 24-month supply of IP address resources _under current ARIN policies_ ..."

This says demonstrate the need for resources. The "under current policies" bit is redundant, because the transfer policy is referring to itself. Of course the current policies always apply; so this is some strange infinitely recursive oddity.

It doesn't say the qualifications and requirements will be the same as if the transfer request was a request for a /20 allocation from the free pool, or as if the transfer were an assignment (things that it is not); only that the transfer policy asserts the requirement to demonstrate need, As long as the need can be demonstrated as explained in 4.1, then any 8.3 transfer should be approved, even if the criteria given in 4.2 for initial allocations are not met. Since there is not yet a policy there that addresses or places specific requirements for need determination for transferred resources, as-opposed to allocation requests The initial allocation rule should not be getting applied to 8.3 transfers in any case... -- -JH -- -Mysid

...

This says demonstrate the need for resources. The "under current policies" bit is redundant, because the transfer policy is referring to itself. Of course the current policies always apply; so this is some strange infinitely recursive oddity.

Jimmy, With all due respect, this is a reference in section 8.3 to call out that the policies in section 4 regarding qualification of recipients are to be followed when determining eligibility for an 8.3 transfer. This is understood by the AC and by ARIN staff. I believe it is also well understood by the majority of the community. I would be happy to submit clarifying text as an editorial amendment if you feel it would be helpful. I would suggest that considering the expressed intent of the policy is more useful than attempting to nit-pick the most nonsensical possible interpretations of the particular wording.

It doesn't say the qualifications and requirements will be the same as if the transfer request was a request for a /20 allocation from the free pool, or as if the transfer were an assignment (things that it is not); only that the transfer policy asserts the requirement to demonstrate need,

That is the express intent of that clause in the rationale and according to the authors during discussions of the policy text prior to its adoption. Further, it is (correctly, IMHO), the ARIN staff interpretation of the policy.

As long as the need can be demonstrated as explained in 4.1, then any 8.3 transfer should be approved, even if the criteria given in 4.2 for initial allocations are not met.

4.1 provides only general principles. In and of itself it is not a complete set of policies. In addition to the guidance provided by 4.1, one must qualify under 4.2 if one is an ISP/LIR or 4.3 if one is an end-user. There are exceptions provided in 4.4 et. seq. for certain special cases.

Since there is not yet a policy there that addresses or places specific requirements for need determination for transferred resources, as-opposed to allocation requests

The text in section 8.3 effectively incorporates 4.2 et. seq. by reference, whether you like that fact or not.

The initial allocation rule should not be getting applied to 8.3 transfers in any case...

IMHO, your interpretation is contrary to the text and the intent of NRPM 8.3. It appears that staff agrees with me. The proposal that later became 8.3 was discussed in the community as it is currently interpreted by staff. At no point prior to your current objection was anything like your intended interpretation ever expressed as a viable outcome of the text in question. Owen

On 4/30/2013 10:36 PM, Jimmy Hess wrote:

On 4/30/13, Owen DeLong <owen@delong.com> wrote:

...

With all due respect, this is a reference in section 8.3 to call out that the policies in section 4 regarding qualification of recipients are to be followed when determining eligibility for an 8.3 transfer. I don't read a reference to section 4 there. don't think it's a reasonable belief, that a network operator supplicating for transfer of IPv4 resources, would come to this conclusion -- there is no reason to select a specific section to apply because no section is mentioned, reading the policy on their own, and what you are seeing there -- may be a result of bias from your prior exposure to another interpretation of the language.

Its also possible, that all of us who were reviewing the proposed transfer policy language read some rationale statement at one time or another, and just (incorrectly) assumed that the final language accomplished our intended effect.

I don't think this issue should effect any network operators at this time, but nonetheless i'm concerned about the RIR policy having confusing, surprising, or hidden ramifications built into it, which are problematic and not previously considered.

I was the original policy modification author. The first version I submitted said: "Add a subsection to Section 8 (Transfers) of the NRPM: "Justified Need" for resources associated with a transfer shall be determined using the "4.2.4 ISP Additional Requests" criteria applied as though the recipient has been a subscriber member of ARIN for at least one year (whether or not that is the case)." Then In a followup email I pointed out: "... Section 8.3 has NO language exempting itself from the 3 month rule. That's what I hear on the list, but I looked it up, and it isn't there. That's how I ended up writing this proposal, after all. The only exemption is in 4.2.4.4. That exemption ONLY works if you are not getting an initial assignment through transfer (a likely scenario for new orgs post-runout) AND you are not a new member who only recently got their initial 3 month supply (where you'd be restricted to using transfer in 3-month increments for the first year in order to grow). AND there's other bugs in that 4.2.2.1.1 and 4.2.2.1.3 and 4.2.2.2 (at the very least) call out specific block sizes that might be *smaller* than the block you're trying to qualify under transfer." I then followed up to that with some specific scenarios... "A. My hypothetical ISP provides service to a small town. I presently get two /24s of IPv4 space from my upstream provider and I'm using them at about 85%. ARIN has run completely out of addresses. A benefactor arrives and offers to transfer a /22 to me and pay for me to multihome. I attempt to use 4.2.2.2 (Initial Allocation to ISPs, Multihomed) for my justification. I need to demonstrate that I am efficiently using the two /24s. Done. I comply with 4.2.2.2.1 (SWIP). I attempt to comply with 4.2.2.2.2, but my growth shows that I won't really need more than a /23 for about 7 months. Transfer would be denied because 4.2.2.2.2 has a three month rule (as I claimed above). Benefactor takes his space elsewhere, and I lose out. B. My hypothetical ISP provides service to a single data center. I presently have a /20 that I was able to obtain from ARIN a few months ago, and I wasn't an ARIN subscriber member prior to this. I have the opportunity to acquire another ISP in town which has a /20 of its own, but which it isn't using very well because their growth plans failed after I opened up. I can demonstrate that my /20 and the second /20 from the acquisition would be filled within a year if I complete this transfer under section 8.2, but I'll only be able to fill out my existing /20 over the next three months. However, because I am under 4.2.4.3 (Subscriber Members Less Than One Year) my 8.2 transfer is denied, again because 4.2.4.3 has a three month rule (as I claimed above). on the flip side... C. My hypothetical ISP provides service to a small city that is served by only one transit provider, so I cannot multihome. It has been using a /20 from the upstream ISP and is efficiently using 16 /24s worth of space with reassignment documentation (satisfying 4.2.2.1.1 and 4.2.2.1.2). I provide detailed information showing that I can use a /20 within the next three months (satisfying 4.2.2.1.3). Now that I have met all the tests, I complete a section 8.3 transfer for a /14 worth of space (because I have loads of money I won in the lottery). As far as I can tell, there's nothing in the NRPM that blocks that transfer... because I've met all the tests in 4.2.2.1. " Then, after a bunch of comment and feedback (particularly around how end-users shouldn't be judged by the ISP criteria during a transfer), I created the simplified language: "Add to Section 8.3 "...they can justify under current ARIN policies showing how the addresses will be utilized within 12 months." Remove from 4.2.4.4: "This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12-month supply of IP addresses." The *intent* of the Section 8.3 language was that it mean "can justify (using current ARIN policy for testing what 'need' means) showing how the addresses will be utilized within 12 months" and *not* "can justify (including all of the various gotchas in Section 4 that apply to allocation operations)" It was never my intent to, for instance, require the recipient of a specified transfer under 8.3 to be required to comply with 4.2.2.1.4 "Renumber and return" for instance. Now, the actual language that is in the NRPM says "The recipient must demonstrate the need for up to a 24-month supply* of IP address resources under current ARIN policies and sign an RSA." ... if someone thinks that "demonstrate the need...under current ARIN policies" means not just "demonstrate the need" but also "fall into compliance with every nuance of section 4 that might be applied if they were getting the addresses from ARIN" (ex. 4.2.1.5 requiring a /20 minimum for ISPs) then I guess we need another policy modification. Is that really how ARIN staff is interpreting it? And why is this discussion here and not on arin-ppml? Matthew Kaufman (* note that it is 24 months because I submitted another policy proposal that was considered at the same time to bump the 12 months up to 24, and both passed)

I believe Jimmy's confusion results primarily as follows: From NRPM 8.3:

8.3. Transfers between Specified Recipients within the ARIN Region

In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions. Conditions on source of the transfer: The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. The minimum transfer size is a /24 Conditions on recipient of the transfer: The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA. The resources transferred will be subject to current ARIN policies.

Note that the minimum /24 restriction he so often references is a restriction on the minimum that a transferor can provide. It does not mean that there are not more specific restrictions on recipients. It is quite clear in the policy, as quoted above, that the only reference to a /24 is in the section controlling the source of the transfer. The only exception to the rest of ARIN policy for the recipient is that it allows a 24 month supply rather than the current 3 month (ISP) or 12 month (End-User) limitation when obtaining resources from the free pool. Owen

On Apr 24, 2013, at 2:45 PM, ML <ml@kenweb.org> wrote:

On 4/23/2013 5:41 PM, Valdis Kletnieks wrote:

...

I didn't see any mention of this Tony Hain paper:

http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf

tl;dr: ARIN predicted to run out of IP space to allocate in August this year.

Are you ready?

Where do the startup ISPs whom didn't qualify for PI IPv4 in the past fit into a post-run out world where they would qualify? I am speaking in generics but also about a real ISP that is in this situation today.

In my example This ISP could show need for a /22 but wasn't multihoming at the time and likely will not until after run-out. How does such an ISP begin to address their backbone and customers facing interfaces without tying themselves to an ISP and their PA space?

I don't imagine they will be open to paying extortion prices for IPs that other people never bothered to use.

As it currently stands in the ARIN region, the qualifications for transfer and for obtaining space from the free pool are identical. Currently, the only difference is that they could obtain 24 months worth of address space via transfer and only 3 months from the free pool. Bottom line, anyone building a business today depending on the continued availability of an IPv4 free pool from an RIR is taking on a very high degree of risk. IMHO, such a business plan would be ill-advised, to say the least. Owen

Le 24/04/2013 21:35, Lee Howard a écrit :

On 4/24/13 2:45 PM, "ML" <ml@kenweb.org> wrote:

...

On 4/23/2013 5:41 PM, Valdis Kletnieks wrote:

...

I didn't see any mention of this Tony Hain paper:

http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf

tl;dr: ARIN predicted to run out of IP space to allocate in August this year.

Are you ready?

Where do the startup ISPs whom didn't qualify for PI IPv4 in the past fit into a post-run out world where they would qualify? I am speaking in generics but also about a real ISP that is in this situation today.

In my example This ISP could show need for a /22 but wasn't multihoming at the time and likely will not until after run-out. How does such an ISP begin to address their backbone and customers facing interfaces without tying themselves to an ISP and their PA space?

I don't imagine they will be open to paying extortion prices for IPs that other people never bothered to use.

Once ARIN is unable to meet an organization's justified need, they can't get addresses from ARIN. They can beg, borrow or buy addresses from someone else. They can try AfriNIC's or LACNIC's policies. They can do CGN. They can do IPv6.

Might be that IPv6would be their currently best bet... ;) mh

Lee