- ipv6-wg - mailman.ripe.net

Tool for /8 remaining
by Ahmed Abu-Abed 22 Jan '11

22 Jan '11

Greetings, Does RIPE have any tool to indicate the remaining /8s , or portion thereof, in its own pool ? APNIC has a good one with recent history, see http://www.apnic.net/community/ipv4-exhaustion/graphical-information Regards, -Ahmed

1 0

And the IANA ipv4 depletion-day is ... yesterday ????
by Kristoff Bonne 21 Jan '11

21 Jan '11

Hi, An interesting piece of news on the "ipv6depletion" website: http://www.ipv4depletion.com/?p=557#comments Because of two large delegations of the APNIC to two Chinese ISPs, the IANA depletion-day is moving real close. In fact, based on the rumours in the last comment, it has actually already happening but the IANA is holding back the allocation of the two last IANA "non-final" /8 blocks to APNIC for a couple of days to plan for a major media-event. (which - I guess- will not happen on a friday; so probably early next week). So, this leads us to the next question: What about a predection for the RIPE ipv4-depletion day? According the "bye-bye ipv4" applet I have running, the RIPE-pool currently has some 10.7 % still free: 279835 /24 left before the "final-/8" rules become to play. Any prediction how far we are from that point? Cheerio! Kr. Bonne.

1 0

The RIPE NCC's involvement in the World IPv6 Day
by Mirjam Kuehne 19 Jan '11

19 Jan '11

[apologies for duplicates] Dear colleagues, We received some questions about the RIPE NCC's involvement in the World IPv6 Day that is planned for 8 June 2011. Please see some ideas and suggestions on RIPE Labs: http://labs.ripe.net/Members/mirjam/ripe-ncc-and-world-ipv6-day We are looking for feedback and suggestions, especially from subscribers of this working mailing list. Kind Regards, Mirjam Kuehne RIPE NCC

1 1

RIPE 61 - IPv6 WG minutes - draft
by Shane Kerr 18 Jan '11

18 Jan '11

Dear IPv6 working group, These are the draft minutes from the IPv6 working group session at the RIPE 61 meeting in Rome. Please send any comments/corrections within the next 4 weeks. Thanks! -- Shane, Marco, and David IPv6-wg chairs ------- Minutes from RIPE 61 Working Group: IPv6 Status: Draft Revision Number: 1 RIPE 61 IPv6 Working Group Rome, 16 November 2010, 16:00 – 18:00 Co-Chairs: David Kessens, Marco Hogewoning, Shane Kerr A: Administrative Matters The session started on time. Shane Kerr welcomed the attendees and mentioned that it was his first time as co-chair of the IPv6 Working Group, while also introducing his co-chairs David Kessens and Marco Hogewoning. Since there were quite a few items on the agenda and the session could be running late, he proposed to go ahead and start with the first presentation. There were no questions or comments from the audience. B. Experiences From an IPv6-only World Ari Keränen from Ericsson presented the work he conducted together with his colleague Jari Arkko about measurements in an IPv6-only environment, with IPv4 connectivity switched off completely. The presentation is available at: http://ripe61.ripe.net/presentations/140-ripe_rome_jari.pdf A speaker from the audience commented on the fact that their company had tried an IPv6-only setup on the server side and they encountered several issues, the biggest being DNS. Investigating the problem, it turned out that a certain percentage of the visitors could not resolve IPv6 addresses when that was the only option, therefore being unable to access the site even though the connection was fine. Ari found the problem interesting, and replied that whether on the client or the server side, it was important to enable communication between the old and the new Internet on all levels. Also, trying to force a specific technology on the users would not be feasible; having only Google and Facebook work for them may go unnoticed by half but would certainly make the others unhappy. Shank Kerr asked whether all the traffic for the experiment was directed through NAT64. Ari replied that there were only a handful of people involved, and they had used his particular home network as one part of the setup, which meant that not everything could be switched over since some devices did not support IPv6. Shane explained that the reason for his question was that since everything ended up translated to IPv4, it would be difficult to discern how much of the traffic was intended for the v4 or the v6 network. Ari answered that there are different configurations of NAT64, so v4 could be deployed only on the outside. A lot of their users were actually in this mode when accessing v4 destinations, however on the v6 Internet they could attain end-to-end IPv6 connectivity. It worked well for their purposes, but perhaps that had something to do with their years of experience running dual-stack configurations. Shane agreed and thanked Ari for his presentation. C. Detecting (and fixing!), IPv6 Dualstack Brokenness Tore Anderson from Redpill Linpro gave a presentation about his company's experience providing networking for customers and testing for broken IPv6 clients. The presentation is available at: http://ripe61.ripe.net/presentations/162-ripe61.pdf Shane Kerr commented he had been following their work for a few months and it was very cool. D. The Results on Introducing Native IPv6 at XS4ALL Marco Hogewoning introduced himself as one of the co-chairs of the Working Group, and then presented an experiment his company, XS4ALL, is conducting running native IPv6 on a residential DSL network. The presentation is available at: http://ripe61.ripe.net/presentations/128-MH-RIPE61-IPv6-XS4ALL.pdf Lorenzo Colitti from Google commented that the results were interesting, especially the fact that only ten percent of the users actually managed to get online using IPv6 -- probably the router firmware was to blame and an upgrade would have fixed it. However, the more important question, seeing as this was only a small-scale residential deployment, was how would this scale from 300 to 300,000 users -- since that is what the industry will have to do in the next couple of years. Marco answered that at a certain point they will probably feel confident enough to have it on by default for all customers, and that that would be the biggest hurdle. The major block that prevents them from doing that is currently the amount of CPE's with broken (non-IPv6-ready) firmware, and those have a lifespan of around two to three years. That would mean that in the next three years most of that installed base would be replaced, and if they were confident enough that it wouldn't break anything they would "push the button" and turn it on for all their 250,000 customers. Henk Uijterwaal from the RIPE NCC commented that he was actually one of the 300 users involved in the experiment, and he had the system working but then the rest of his family started to complain about things not working, like the telephone. The conclusion would be that not every combination of hardware, modems and phones would work. Marco replied that since the firmware they used on the modems in order to facilitate the experiment was new, it fixed some things -- like IPv6 functionality -- but broke others in the process, like the VoIP system used by the phone. He also added that there was a benefit there, when people at home that can't do much about fixing the technical problems will push their vendors to do it and they in turn will start taking IPv6 seriously. Lorenzo Colitti was interested to find out how long it took for the whole project to be implemented, from the design phase onwards. Marco answered that the design phase was completed in 2008. It took some time, mostly because they needed to test things properly. From a man-hour point of view it was pretty low, however they ran into issues with lawful requirements for interception under Dutch law -- they had to stall the project while waiting for the government systems to be fixed. Lorenzo rephrased the question to ask how long it would take if someone was in Marco's position and was asked by their manager to implement IPv6 on their network as soon as possible for all users. Marco answered that without checks and in a hurry it could be done in a week, but in order to do a proper job it could take anywhere from three to six months. Since more and more vendors are implementing IPv6 in their equipment, the problem remains having enough deployment to iron out all the bugs, since there is very little feedback on what breaks. When the deployment will reach a lot of people, it will be a lot harder for the vendor to ignore bugs and more pressure to fix things. Lorenzo concluded that it would then take around six months plus some time to make sure everything runs fine, and then asked if Marco's team was still pursuing this project. Marco said that indeed they keep working on it, the technical infrastructure and basics being taken care of, but things like reverse delegation, for example, needs to be fixed. They also have some services that are not yet deployed on IPv6, but mostly what they do now is wait for the vendors to come up with quality firmware -- the network side is pretty much done. There were no more questions or comments. E. RIPE NCC Stats Emile Aben from the RIPE NCC presented various statistics compiled using the data available to the NCC. The presentation is available at: http://ripe61.ripe.net/presentations/145-2010-11.ripe-61.ipv6-where-are-we.… Emile also demonstrated a new service offered by the RIPE NCC where anyone can compare the penetration of IPv6 in specific countries or regions: http://v6asns.ripe.net/v/6 Randy Bush inquired whether there were any privacy issues with the new service, since it included data about people visiting the website. Emile answered that since the IP addresses of visitors would not be published there should be no concerns, but legal advice will be sought regarding that just in case. Emile continued by presenting the current status of the "RIPEness" project and associated statistics. A member of the audience asked if suggestions for the fifth star were still being accepted. Emile replied yes, and the audience member said that his suggestion would be to call the helpdesk of the ISP and ask "I have an IPv6 question", and if the answer would be "Yes, how can I help you?", then the fifth star should be awarded. An audience speaker commented that this was the kind of material that decision makers like to look at, and asked if there was a disclaimer that this was easily measured external behaviour and of course being IPv6 ready, included lots of things that usually are not externally visible so that no new project will go along if it doesn't come with an explanation about how it would work with IPv6 or what the transition was. Emile answered that they didn't currently have such a disclaimer, but it was a good suggestion to put it on; however it would be hard to get the necessary data. Lorenzo Colitti from Google commented that the 2% figure of IPv6 penetration was ten times higher than the number Google had derived from their own measurement -- which was 0.2%. They had also measured 0.1% in the beginning of January, which coincided with the 100% growth seen on the RIPE NCC statistics. Therefore, he asked that a very big disclaimer be put on these results since it was the kind of thing decision makers look at, and the population visiting the ripe.net site was highly self-selecting and far more likely to have IPv6 than the average user. Emile agreed, mentioning that the ripe.net measurement was actually just one of several conducted, and the other sites had results closer to the Google number, far below 1%. Lorenzo expressed his concern that the people seeing higher numbers would become complacent while ignoring the far worse reality. Geoff Huston from APNIC commented that APNIC had been doing similar measurements, and their website presented the same bias towards technical visitors. Also, their services tended to be accessed by the same people repeatedly, so the measurement would have a very limited base. On the other hand, they had recently run the same measurement on a gaming site, which resulted in numbers that made the 0.2% seem extremely low. He then urged entities making measurements not to keep them closed, but open them towards the community, as biased or incomplete as they may be, since it is the only way to understand what is truly happening and the more data published, the better. He than shared the interesting fact that of the v6 visitors coming to their site, around 70% were running 6to4, so whether the technical community liked 6to4 or not it was very widely used and a simple routing addition like routing 2002/16 through a local relay would help those users. Another surprising discovery was the very low usage rates of Teredo, it's slow speed compared to the alternatives and the fact that it broke connectivity when installed locally. Shane Kerr intervened to announce that the discussion was running a little late and urged the participants to hurry up. A member of the audience commented that they had checked their RIPEness status and they did not have the fourth star because they were not advertising EU blocks since they had no EU customers. They were however advertising US blocks, which meant they had a fully working v6 network that was not counted properly, and there probably were quite a few others in the community in the same situation. Emile responded that the issue would be looked into. Tore Anderson from Redpill Linpro commented in response to Geoff Huston that their numbers were available on their website, all that was needed was for someone to take them and create a graphic or statistic. Talking about Teredo, he explained that it is only done by Windows by default, some CPE implementing it but only a few. Also, Windows Internet Connection Sharing does not share it out using RA's, which means only applications running on Windows will try and use Teredo. As a final note, newer versions of Windows implement RFC3484, which de-preferred Teredo, so that would be one reason for the very low Teredo traffic measured. Geoff Huston replied that the test they did targeted Teredo hosts by being IPv6 only -- even if it was de-preferred in dual-stack, if a resource would only advertise AAAA records then it would force IPv6 usage and that's why they saw some answers rather than none at all. Lorenzo Colitti added one final comment that when it came to numbers, it would be easy to publish statistics and graphs if that is what the community needs. He also expressed the fact that many in the industry are secretly hoping for 6to4 to go away, but the situation is not decided yet. There were no more questions or comments. F. Native IPv6 via xDSL – How to Tweak Your LNS The following presentation was by Fredy Künzler from Init Seven AG, with practical examples and technical details about implementing IPv6 on a xDSL infrastructure. The presentation is available here: http://ripe61.ripe.net/presentations/160-Native-IPv6-via-xdsl-how-to-tweak-… Martin Levy from Hurricane Electric asked what the response of the telecom provider was when they asked for v6 support. Fredy replied that they did not ask, since the telecom was not needed. Martin asked for confirmation that the provider's collaboration was not required for such a setup on DSL, and Fredy confirmed that it was completely transparent. Martin then continued by inquiring as to what the average telecom answer was when asking for v6. Fredy could not answer that question and requested members of the public to respond. A member of the audience commented that the usual response was that they mistake it for a question about TV and try to sell a TV bundle. Lorenzo Colitti asked the same question he posed to Marco earlier -- how would they scale the setup from the 12 current users to the total number of supported users. Fredy could not answer, explaining that was not their main focus in their business, and they did not have the high number of users as to have a scaling issue. Marco Hogewoning intervened to answer Martin's previous question. He said the response from their telecom provider was "Cool, let us know how it works so we can copy it off". Martin asked whether the telecom actually owned Marco's company, to which he replied affirmative. A member of the audience gave another response to Martin, keeping in mind that the situation was probably different in the European compared to the US market. He explained that the telecom provides the copper and a PPPoE service, which is then switched over L2TP to the ISP, so the layer 3 protocol is usually transparent; there were some bugs in equipment that prevented things from functioning correctly, but for the most part it was transparent for the telecom. Another member of the audience noted that there was an issue with BT in the UK and the previously mentioned bugs, which was still not corrected because officially they do not support IPv6. Because of that such a deployment would be difficult in the UK, at least with BT as the provider. A member of the audience commented that while he was a core network expert with expertise into the architectural aspects and less with the access network issues, he was quite positive there were large spots where actually transparent access was not available. There were no further questions or comments. G. Requirements for IPv6 in ICT Equipment Jan Žorž and Sander Steffann gave a presentation about their proposal for a formal document published by the RIPE community that would help governments and other institutions to select IPv6-capable devices and to devise tenders and auctions in a way that would ensure future equipment procured would be IPv6 capable. The presentation is available at: http://ripe61.ripe.net/presentations/307-Jan_Zorz-IPv6WG-requirements-in-IC… After Jan presented the proposal, he mentioned that there had been two consecutive versions of the draft and some response from the community. While items were added, the last call for discussion would end the following day, then the Chairs would decide if a new last-call was needed. He asked the audience if they thought the idea was useful and needed as a recommendation. David Kessens introduced himself as one of the co-chairs of the Working Group and noted that the current thinking of the IPv6 Co-Chairs was that the following day they would have more information from the comments gathered after the session and then they would be better able to make a decision. Jan thanked David and then asked Sander to present his own view on the issue. Sander commented that he had heard from a lot of organisations wanting to deploy v6 but lacking the experience in the field that such a proposal would be appreciated. The recommendation was clear in what a device should support, by making it a requirement for v6 to perform on par with v4, while also including a section about the knowledge and skills necessary of the integrator. As such, it would constitute a good document to standardise v6 requests around. Constanze Bürger from the German Ministry of the Interior commented in support of the proposal that from a Government point of view it was much appreciated and welcome since the vendors do not provide the necessary information, while Governments themselves do not know what to ask for. She also proposed improvements to the requirements, by going into more details than the RFC level, like a matrix that would match legal requirements and policies in the EU. David Kessens intervened to ask for brevity since the time was already short, and proposed that further discussion regarding improvements should be continued on the mailing list or in person after the session ended. Constanze reiterated their support and the necessity of the proposal. Sander thanked her for the support and the input received and mentioned that he would like to see the proposal go through the process as quickly as possible, and perhaps implement further changes in a second version, since this was an open, ongoing process. There were no further questions or comments. This proposal is now a published RIPE Document: http://www.ripe.net/ripe/docs/ripe-501.html H. Update on Policy Proposal 2010-06 For the last presentation in the session, Marco Hogewoning returned to the stage together with Remco van Mook to present a policy proposal currently in the draft stage. The presentation is available at: http://ripe61.ripe.net/presentations/309-MH-RIPE61-2010-006.pdf After giving the presentation, Marco explained that since he was one of the proposers, he would not do any Chair processing in this case, leaving it to David and Shane to make all the decisions. Wilfried Woeber from ACOnet/Vienna University asked if there was any reason for doing the same statistics that were done on IPv4 with IPv6 (like percentage of the usage of a block of addresses compared to the number of consumers or end points). He expressed the opinion that something like that would not be needed with IPv6 since there would be no real shortage. Marco answered that at a certain point HD ratios need to be calculated, but it's more a matter of implementation. Since in the v4 case the statistics were not part of the policy and just a means of showing the usage of addresses, it was a good idea to copy that over to v6. Of course, if the consensus would be that there was no such need it could be amended. Wilfried explained that he was referring to the dynamic component of DSL addresses and other surrounding issues, while admitting he had not studied the policy in detail. Marco said that on the v4 version it was specifically stated "broadband user", and that implied 24/7 usage since a provider could not assign 2,000 addresses with only 500 customers unless making another assignment. While such a policy was reasonable with IPv4, it would still work with IPv6, since a procedure was needed to have someone who was running out of a /32 be able to justify another one instead of simply asking for a /28 -- otherwise everyone could simply be assigned a /28 from the beginning. Wilfried commented that at the time he was working on an address plan for a large customer, and it looked like they would not use the same size for all end points but instead define three sized groups. He would have liked to see a mechanism to document such issues within the framework of the proposal. Marco answered that the proposal text was only finished in that afternoon and it should be coming out, they were just waiting for the RIPE NCC to conduct an impact analysis. Afterwards it would be pushed to the mailing list. In the proposed version, it stated that one can nest objects but only up to one level -- that was to prevent people from going into the /128 level while allowing for instance a number of /48's to be grouped and another separate /48 to be split up in /64's. David Kessens reiterated that Marco would not be involved in the discussions and decisions regarding this proposal, and that the current status was waiting for the RIPE NCC to conduct an impact analysis and then the document should be published, since it was already discussed quite a bit and it did not stir too many controversies. There would be a two-week review phase and another last call after that before the process will be finalised. Marco remarked that they would involve multiple Working Groups and their Chairs in the discussion, the Database WG and Address Policy WG since it concerned them as well. There were no other questions or comments. As the presentations ended at 18:05, Shane Kerr thanked everyone present and asked for an open mike session. He also reminded the attendees that the session was already overtime. Marco Hogewoning reminded the attendees of the mailing list for the IPv6 Working Group: http://www.ripe.net/mailman/listinfo/ipv6-wg The address to contact the Working Group Co-Chairs: ipv6-wg-chairs(a)ripe.net Randy Bush commented that for the ones that have been around Internet technology for a while to notice the progress, things have really changed in the past few months, and even though we may not see 80% deployment of IPv6 it is on people's minds and the next months should be very interesting. He also praised Marco for his presentation. Shane Kerr officially ended the session at 18:09 by wishing everyone a good night.

2 1

"Requirements For IPv6 in ICT Equipment" comment
by Nash, Steve 18 Jan '11

18 Jan '11

Regarding: http://www.ripe.net/ripe/docs/ripe-501.html I find no mention of flow instrumentation in the November 2010 document. I suggest that "router and layer 3 switch" Mandatory support should include maintenance and export of flow records , ideally compliant with rfc 3917, with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device. Regards Steve Nash ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 www.arbornetworks.com<http://www.arbornetworks.com/> How networks grow(tm) ________________________

13 31

[annoucement] changing jobs
by Marco Hogewoning 09 Jan '11

09 Jan '11

Hi All, As some of you may already know, I will be changing jobs. As of January 1st, I will join the RIPE NCC training department. This of course raises the question wether I should stay as co-chair of this working group. After talking with various people, including the NCC management, the RIPE chair and the other WG co-chairs, we concluded that I can stay on as a co-chair. However as the NCC has to remain neutral I will pull out of any discussions regarding address policy or other proposals directly related to the operations of the RIPE NCC. I will leave decisions regarding these proposals up to David and Shane, the other two co-chairs of this working group. If you have any questions or objections to this situation, please post to the IPv6 WG list or to me directly. I would like to thank my former employer, XS4ALL Internet, for the time and money they allowed me to spent on this working group over the past years. Happy new year and hope to see you in 2011, Marco Hogewoning IPv6 working group co-chair

9 8

RE: [address-policy-wg] 2010-06 is going to Last Call
by kpn-ip-office＠kpn.com 07 Jan '11

07 Jan '11

I support the proposal. With kind regards, ir. A.W. (Andries) Hettema KPN OZM KS&O B&I Internet +31 70 34 38290 andries.hettema(a)kpn.com -----Oorspronkelijk bericht----- Van: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] Namens Shane Kerr Verzonden: donderdag 6 januari 2011 14:20 Aan: db-wg(a)ripe.net; 'address-policy-wg(a)ripe.net' Onderwerp: [address-policy-wg] 2010-06 is going to Last Call Hello, [ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010). You can see the policy proposal here: http://ripe.net/ripe/policies/proposals/2010-06.html There were some clarifications during the Review Phase, but nothing indicating changes needed. David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.) The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg(a)ripe.net before then. Thanks, -- Shane

1 0

AUTO: Nicht erreichbar bis 11.1.2011 / Out of Office until 11.1.2011
by Joachim Strohbach 06 Jan '11

06 Jan '11

Ich bin abwesend und kehre am 12.01.2011 zurück. Danke für Ihre E-Mail-Nachricht. Ich bin bis 11. Januar 2011 nicht im Büro. In dringenden Angelegenheiten kontaktieren Sie bitte DENIC IT-Services (E-Mail: its(a)denic.de, Tel: (069) 27235-160 oder -250). ----- Thank you for your email message. I am not in the office until 11 January 2011. In urgent cases please contact DENIC IT-Services (e-mail: its(a)denic.de, Tel: +49 69 27235-160 or -250). -- Joachim Strohbach Leiter IT-Services / Head of IT-Services DENIC eG Kaiserstraße 75-77 60329 Frankfurt am Main GERMANY E-Mail: strohbach(a)denic.de Fon: +49 69 27235-123 Fon: +49 69 27235-160 (Assistance) Fon: +49 69 27235-250 (IT-Services) Fax: +49 69 27235-239 SIP-URI: sip:123@denic.de http://www.denic.de PGP-KeyID: 0x7A8A00FF, Fingerprint: 30AB 0F15 17D3 995F CA50 F0A8 EA30 B915 7A8A 00FF Angaben nach § 25a Absatz 1 GenG: DENIC Domain Verwaltungs- und Betriebsgesellschaft eG (Sitz: Frankfurt am Main) Vorstand: Sabine Dolderer, Helga Krüger, Carsten Schiefner, Dr. Jörg Schweiger Vorsitzender des Aufsichtsrats: Elmar Knipp Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "[db-wg] 2010-06 is going to Last Call" gesendet am 6.1.11 14:20:25. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist.

1 0

2010-06 is going to Last Call
by Shane Kerr 06 Jan '11

06 Jan '11

Hello, The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010). You can see the policy proposal here: http://ripe.net/ripe/policies/proposals/2010-06.html There were some clarifications during the Review Phase, but nothing indicating changes needed. David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.) The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg(a)ripe.net before then. Thanks, -- Shane

1 0

2010 IPv4 (and IPv6) Address Use Report
by Iljitsch van Beijnum 04 Jan '11

04 Jan '11

[ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] On the web: IPv4: http://www.bgpexpert.com/addrspace2010.php IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php The IPv4 one is included below: 2010 IPv4 Address Use Report As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010. 35 of the 256 the /8s that make up the IPv4 address space have the status "reserved". 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are "reserved for future use". With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a "reserved" address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use. This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global pool" consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the "allocated" and "legacy" categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million. Going back to the IANA global pool, these are the changes over the past year: Delegated Blocks +/- 2010 to/status AfriNIC 3 +1 APNIC 42 +8 ARIN 35 +4 LACNIC 8 +2 RIPE NCC 34 +4 LEGACY 92 UNALLOCATED 7 -19 There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this: Delegated Blocks +/- 2010 to/status AfriNIC 4 APNIC 45 ARIN 36 LACNIC 9 RIPE NCC 35 LEGACY 92 UNALLOCATED - At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each "administered" by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR: Legacy Allocated total unused total unused AfriNIC 33.55 24.85 50.33 27.06 APNIC 100.66 22.32 704.64 44.38 ARIN 654.31 60.55 587.20 56.21 LACNIC - - 134.22 37.39 RIPE NCC 67.11 5.77 570.43 67.38 IANA 671.09 16.65 - - AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use <em>really</em> takes off in Africa, AfriNIC will be handing out addresses for at least three or four years. APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven /8s and, it's hard to see how APNIC can avoid having to tell people "no" before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what the underlying reason for these changes is, the actual rate at which APNIC and the other RIRs are giving out address space may be different from what it seems to be at first glance. ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 million addresses, respectively, in 2010. However, ARIN saw 27.24 million addresses returned, including the 16.65 million from Interop, which is administered in the ARIN records even though the IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC the numbers of addresses that came back were 0.31, 0.22, and 22.62 million, respectively. With respect to running out of addresses, it's important to realize that the Pareto principle (the 80/20 rule) applies: out of the 7686 address blocks given out last year, only 392 (5 percent) were blocks larger than 100,000 addresses, but those were responsible for 82 percent of the address <em>space</em> given out. Even when the RIRs are no longer able to give out those large blocks, they may still be able to fulfill the requests for address blocks smaller than 10,000 addresses. Last year, 6425 such blocks were given out, totaling 14.03 million addresses. It really only takes a single address to be in the content business; it's the ISPs that need a continuous supply of new addresses to connect new customers. So the address shortages looming beyond the summer will hit ISPs and their broadband/mobile customers first and foremost, and the content industry to a much lesser degree. The top 15 IPv4 address holding countries: 2011-01-01 2010-01-01 Increase Country 1 - US 1519.53 M 1495.13 M 1.6% United States 2 - CN 277.64 M 232.45 M 19.4% China 3 - JP 186.82 M 177.15 M 5.5% Japan 4 - EU 151.80 M 149.48 M 1.6% Multi-country in Europe 5 (6) KR 103.50 M 77.77 M 33.1% Korea 6 (5) DE 91.61 M 86.51 M 5.9% Germany 7 (9) GB 82.25 M 74.18 M 10.9% United Kingdom 8 - CA 79.53 M 76.96 M 3.3% Canada 9 - FR 79.29 M 75.54 M 5.0% France 10 - AU 49.10 M 39.77 M 23.5% Australia 11 - BR 40.24 M 33.95 M 18.5% Brazil 12 - IT 37.14 M 33.50 M 10.9% Italy 13 - RU 34.66 M 28.47 M 21.7% Russia 14 - TW 31.93 M 27.10 M 17.8% Taiwan 15 (19) IN 28.70 M 19.42 M 47.8% India Because the US holds so much space, the increase of 25 million addresses seems small, but that's still more than 10% of the address space given out in 2010. China's growth is slowing down a little at 45 million addresses last year compared to 50 million in 2009. But other countries in Asia are picking up the slack and then some: Korea keeps using up large amounts of address space, and India is now also picking up the pace. The US now has 47.3% of the address space in use, down from 50.1% a year ago. The other countries in the top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the rest of the world, up from 12%. Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use.

1 0