- ipv6-wg - mailman.ripe.net

World IPv6 Launch: RIPE NCC Activities
by Paul Rendek 06 Jun '12

06 Jun '12

[Apologies for duplicate emails] Dear Colleagues, World IPv6 Launch takes place today, 6 June 2012, marking a key milestone in the development of the Internet. Major Internet service providers (ISPs), manufacturers and content providers around the world are coming together to permanently enable IPv6 for their products and services. RIPE NCC is heavily involved in both the local and global events surrounding the Launch. Measurements ------------- We will monitor and analyse many of the participating websites from a number of vantage points before, during and after the Launch: http://v6launch.ripe.net/cgi-bin/index.cgi Local Event ----------- We've joined forces with several Dutch organisations to organise the World IPv6 Launch NL event at Science Park Amsterdam. The local technical community and future Internet leaders are attending the RIPE NCC's IPv6 tutorial, various IPv6-related presentations, hands-on workshops and plenary sessions. We'll be tracking the global Launch with live statistics throughout the day and Daniel Karrenberg, Chief Scientist, will give the keynote speech: http://ipv6launch.nl/ Global Activities ----------------- Find out more about our other IPv6 Launch activities, including the RIPEstat World IPv6 Launch Widget, how to test IPv6 reachability using RIPE Atlas and using the IPv6 Eye Chart to find out if you will have problems accessing websites, at: http://www.ripe.net/internet-coordination/ipv6/world-ipv6-launch Regards, Axel Pawlik Managing Director RIPE NCC

1 0

New Document ripe-554 "Requirements for IPv6 in ICT Equipment" published
by Marco Hogewoning 05 Jun '12

05 Jun '12

Dear Colleagues, It is our pleasure to announce we just published a new RIPE Document, called "Requirements for IPv6 in ICT Equipment". This document serves as a replacement of the ripe-501 document, which is now obsoleted. The full text is available via https://www.ripe.net/ripe/docs/current-ripe-documents/ripe-554 If you reference the ripe-501 somewhere, please update your links and refer to this new document. Many thanks to the authors, Jan, Sander, Merike and everybody else in the community who contributed to this new text. We would also like to say thanks to the RIPE NCC staff for their support in text editing and publication. The IPv6 Working Group Chairs, Marco, David and Shane

4 3

RIPE 65 call for content and agenda items
by Marco Hogewoning 04 Jun '12

04 Jun '12

Dear Colleagues, With World IPv6 Launch around the corner we would like to draw your attention to the upcoming RIPE Meeting, which will be held 24 - 28 September in Amsterdam. During this meeting we would love to hear from you about your experiences with the World IPv6 Launch or other IPv6 deployment projects. What did you do and did it work? Or even maybe tell us about the things you didn't do and why you made that decision. The IPv6 Working Group is chartered to exchange all operationally relevant bits of deploying IPv6. So if you are doing something for W6L please consider sharing your results and experiences with the community. Please drop a note to ipv6-wg-chair <at> ripe <dot> net with a short summary of your project and an abstract of your talk. Of course you can also submit your talk for the plenary using the online system. But we kindly request you to only use one of these methods to prevent any double work. Thank you, The IPv6 WG chairs, Marco, David and Shane

1 0

2012 Global IPv6 Deployment Monitoring Survey - Open Now Until 30 June
by Axel Pawlik 01 Jun '12

01 Jun '12

[Apologies for duplicate emails] Dear colleagues, The Number Resource Organization (NRO), on behalf of all the Regional Internet Registries, invites you to participate in the 3rd consecutive Global IPv6 Deployment Monitoring Survey on the current and future use of IPv6. The purpose of the survey is to better understand where the community is moving, and what can be done to ensure that the Internet community is ready and moving toward widespread adoption of IPv6. As it is mostly the same as the survey carried out globally in 2010 and 2011, comparison of progress will be possible. The IPv6 Deployment Monitoring Survey is now online, and we encourage all members of our community to participate: https://www.surveymonkey.com/s/GlobalIPv6survey2012 The survey will be open for a month and will close on 30 June 2012. We anticipate a good response rate as 94% of last year's over 1600 respondents from around the globe indicated that they were interested in participating again. We encourage all organisations to participate in order for the results to establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. The survey is composed of 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. For those interested, the results of last year's survey are available: http://www.nro.net/wp-content/uploads/ipv6_deployment_survey.pdf. Results of this year's survey will be presented and discussed widely. Please provide your name and contact information on the survey form if you wish to receive the draft survey analysis when available. Please also indicate whether you are willing to share additional data with the TNO and GNKS Consult IPv6 Deployment Monitoring team. We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to info(a)gnksconsult.com. Regards, Axel Pawlik Managing Director RIPE NCC

1 0

New on RIPE Labs: Measuring World IPv6 Launch
by Mirjam Kuehne 29 May '12

29 May '12

Dear colleagues, Similar to last years World IPv6 Day, this year we're measuring selected World IPv6 Launch participants from over 50 vantage points all over the world. We're measuring DNS, ping, traceroute and HTTP and show results at http://v6launch.ripe.net/ . For more information, please read on RIPE Labs: https://labs.ripe.net/Members/emileaben/measuring-world-ipv6-launch-partici… Kind Regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 security: New IETF I-Ds, slideware and videos of recent presentations, trainings, etc...
by Fernando Gont 29 May '12

29 May '12

Folks, * We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like protection against rogue DHCPv6 servers. The I-D is available at: <http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt> Other IPv6 security I-Ds (such as, draft-ietf-v6ops-ra-guard-implementation) have been revised. Please check them out at: <http://www.si6networks.com/publications/ietf.html> * The slideware (and some videos!) of some of our recent presentations about IPv6 security are now available online. You can find them at: <http://www.si6networks.com/presentations/index.html> * We have also scheduled IPv6 hacking trainings in Paris (France) and Ghent (Belgium). You can find more details at: <http://www.si6networks.com/index.html#conferences> Our Twitter: @SI6Networks Thanks, - -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

Status update replacing ripe-501
by Marco Hogewoning 23 May '12

23 May '12

Dear working group, In case anybody is wondering what happened to this. The working group chairs and authors are pretty confident that all issues have been addressed and the document in its current form is the one that will published. At the moment we are in the process of doing a final review for spelling and grammar, after which we will ask the RIPE NCC to assign a number and publish the document. Grtx, Marco

1 0

New article on RIPE Labs: Measuring IPv6 at Network and Customer Level
by Mirjam Kuehne 16 May '12

16 May '12

Dear all, Please find a new article "Measuring IPv6 at the Network and the Customer Level" on RIPE Labs. It has been contributed by George Michaelson from APNIC: https://labs.ripe.net/Members/ggm/measuring-ipv6-at-the-network-and-the-cus… Kind regards, Mirjam Kuehne RIPE Labs

1 0

6to4 and teredo pingables?
by Aleksi Suhonen 13 May '12

13 May '12

Hi, We run 6to4 and Teredo relay routers and in order to monitor the service our network monitoring system has been pinging a handful of 6to4 and Teredo addresses elsewhere. If more than one of those addresses fail to answer pings, an alarm is raised. Now I'm looking for a few more addresses I could ping, so I could raise the alert threshold a bit. Any volunteers? And in case anyone else wants to ping some of our hosts, here's a couple of candidates: (sorry, no Teredo hosts) ns.trex.fi. IN AAAA 2002:c38c:c38c:15::35 mail.trex.fi. IN AAAA 2002:c38c:c38c:14:203:baff:fe0f:d68b Yours sincerely, -- Aleksi Suhonen / TREX

1 0

New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas
by Mirjam Kuehne 09 May '12

09 May '12

[apologies for duplicate mails] Dear colleagues, You can now use RIPE Atlas to test your IPv6 reachability. This also works if you do not host a RIPE Atlas probe yourself. However, please note that this is only available to RIPE NCC members. Please find the details on RIPE Labs: https://labs.ripe.net/Members/becha/test-your-ipv6-reachability-using-ripe-… If you have any comments or questions, please let us know. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

IETF I-D: Security Implications of IPv6 on IPv4 Networks
by Fernando Gont 02 May '12

02 May '12

Folks, A couple of weeks ago we published a new IETF I-D entitled "Security Implications of IPv6 on IPv4 networks". The I-D is available at: <http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets> The Abstract of the I-D is: ---- cut here ---- This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. ---- cut here ---- We're currently working on a revision of the document, so any comments will be really appreciated. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

New on RIPE Labs: Update on IPv6 Address Distribution
by Mirjam Kuehne 02 May '12

02 May '12

Dear colleagues, At the recent RIPE Meeting we presented some IPv6 address distribution statistics. In this RIPE Labs article, you can find statistics on IPv6 allocations and assignments. In particular, the article details what affect the removal of the requirement to be multihomed had on the number of assignments and the relationship between the age of an LIR and the number of IPv6 addresses they have received. https://labs.ripe.net/Members/mirjam/update-on-ipv6-address-distribution Kind regards, Mirjam Kuehne RIPE NCC

1 0

Last Call for publication of RIPE-501bis (reply by 20120426)
by David Kessens 02 May '12

02 May '12

In the IPv6 working session at the RIPE meeting in Slovenia, we discussed: http://go6.si/docs/Requirements-for-IPv6-in-ICT-equipment-v.9.pdf The meeting participants felt that the document is now ready for publication. Therefore, I would like to give everybody a final chance to bring up major issues that must be resolved before publication. Please comment by Thu 20120426 if you have major issues that require a delay in publication. We will ask the RIPE NCC to publish the document after the Last Call ends if no serious issues are uncovered by that date. The RIPE NCC will do an editorial pass for spelling, grammar and minor issues before it will publish the document. Feel free to contact the working group chairs directly <ipv6-wg-chairs(a)ripe.net> if you find anything minor that doesn't need working group review and we will make sure that it gets fixed in the final document. Thanks, David, Shane & Marco ---

3 3

RIPE 64 Working Group session
by Marco Hogewoning 18 Apr '12

18 Apr '12

Hi all, This is to remind you that the IPv6 Working Group will meet here in Ljubljana, tomorrow Thursday the 19th. We have 2 sessions, starting at 11:00 after the first coffee break in the main room. With a lunch break in between we continue at 14:00 in the same room for the second half. The agenda is posted to the website and available via https://ripe64.ripe.net/programme/meeting-plan/ipv6-wg/ We hope to see you all there. In case you couldn't make it to Slovenia, as always these sessions will be broadcasted and recorded for the archives. For remote participants feedback channels using IRC/Jabber will be available. More information can be found on the RIPE 64 meeting website, the stream is available via https://ripe64.ripe.net/live/ (Grant Union Hall). In case you want to join remote, Slovenian local time is UTC +0200. See you tomorrow, Marco, David and Shane

1 0

Fw: WG Review: sunset4 (sunset4)
by Shane Kerr 18 Apr '12

18 Apr '12

All, FYI, the IETF may be starting some (more) work of interest to IPv6 folks. Perhaps this will inspire us to change the IPv6 working group to the IPv4 CGN/NAT working group. ;) Cheers, -- Shane Begin forwarded message: Date: Tue, 17 Apr 2012 09:41:57 -0700 From: IESG Secretary <iesg-secretary(a)ietf.org> To: IETF Announcement List <ietf-announce(a)ietf.org> Subject: WG Review: sunset4 (sunset4) A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg(a)ietf.org) by Tuesday, April 24, 2012. sunset4 (sunset4) ----------------------------------------- Status: Proposed Working Group Last Updated: 2012-04-13 Chairs: TBD Internet Area Directors: Ralph Droms <rdroms.ietf(a)gmail.com> Brian Haberman <brian(a)innovationslab.net> <TBD> Internet Area Advisor: <TBD> Area Advisors: OPS: <TBD> TSV: <TBD> RTG: <TBD> Mailing Lists: <TBD, pending final WG name> Description of Working Group: The IETF is committed to the deployment of IPv6 to ensure the evolution of the Internet. However, the IPv4-only components of the Internet must continue to operate as much as possible during the transition from IPv4 to IPv6. The Working Group will standardize technologies that facilitate the graceful sunsetting of the IPv4 Internet in the context of the exhaustion of IPv4 address space while IPv6 is deployed. These technologies will likely be less optimal than equivalent technologies for IPv6-only and dual-stack networks. The Working Group works only on IPv4 protocols to facilitate IPv4 sunsetting. The Working Group may work on fixing security bugs in existing IPv4-specific protocols but is not chartered to add new security functionality to those protocols. The working group will provide a single venue for the consideration of IPv4 sunsetting, while ensuring that any such technologies do not impede the deployment of IPv6 and do not duplicate functions and capabilities already available in existing technologies. Therefore, along the lines of draft-george-ipv6-support, before the working group adopts any technology, it must: 1) describe the problem to be solved and show that there is widespread demand for a solution 2) demonstrate that the problem can not be solved with existing technologies 3) provide a description of the proposed solution along with the impact on current IPv4-only use and its ability to promote the deployment of IPv6 These steps will likely be described in the form of a use case and requirements document. Only after the above mentioned steps have been completed and the results accepted by the community will the IETF consider adding new work items to the Working Group charter. This new work may include protocol specifications. The work spans over multiple IETF areas including as Internet, Operations, Transport and Routing. Therefore, cross-area coordination and support is essential and required. Any work on IPv4 to IPv6 transition methods is out of scope. The initial work items are: * Review current CGN documents, including requirements for standardization, and determine is CGN is a suitable sunsetting technology to become a work item * Gap analysis of IPv4 features to facilitate IPv4 sunsetting Milestones 2012-09 Complete review of CGN and, if necessary, propose CGN work items 2013-06 Send gap analysis on IPv4 sunsetting to IESG

1 0

Slides for "Recent Advances in IPv6 Security" at Hackito Ergo Sum 2012
by Fernando Gont 16 Apr '12

16 Apr '12

Folks, The slides for my presentation entitled "Recent Advances in IPv6 Security" at Hackito Ergo Sum 2012 (http://2012.hackitoergosum.org/) are available at: <http://www.si6networks.com/presentations/HES2012/fgont-hes2012-recent-advan…> The same slides are available in other formats at: <http://www.si6networks.com/presentations/index.html> Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

Slovenian IPv6 study for government - now available in English language
by Jan Zorz ＠ go6.si 11 Apr '12

11 Apr '12

Dear @IPv6 WG Long time promised Slo IPv6 study, done for our government in 2010 is now available in English language. The authors did a revision and added few changes just in order to make document more "current". All in all, many things that we wrote is 2010 still holds. You can download the PDF from following page: http://go6.si/en/2012/04/slovenian-ipv6-study-english-version/ In the doc there are 11 key questions from governmental point of view and many answers to them. Hope that this work can help some governments in their way towards IPv6. See you all in few days, Jan Zorz Go6 Institute.

1 0

Preview of the final RIPE-501bis.
by Jan Zorz ＠ go6.si 10 Apr '12

10 Apr '12

Dear IPv6 WG. After long and exhausting IETF week, where we met with some great experts from the industry and did some sanity checks and corrected some mistakes and misunderstandings in the RIPE-501-replacement document, we are issuing next (9th) version of the draft, that is in our opinion really final one. I mean it. Last one. There was lot's of time, efforts and work put into this document and I think we are done. This replacement document is also meant as a some kind of input or initial template for EU IPv6 profile, so we wanted it to be very solid and accurate. Thanks to all of you involved, you know who you are (you are all in Acknowledgements section ;) ) and thnx to this WG and their co-chairs for support, help and all good comments. We already set the last version to RIPE-NCC for grammar checks and conversion into HTML in order to appear in RIPE Documents section as a draft, but meantime, we are publishing the last version also in PDF in order for you, community, to read it prior to RIPE64 meeting. http://go6.si/docs/Requirements-for-IPv6-in-ICT-equipment-v.9.pdf Please, those of you who are interested and have time, read it and express you r opinions and possible comments. Rumor has it, that we'll have "review" period over the RIPE64 meeting and Last call shortly after that. As this is not an official PDP, we can also propose chairs to change the procedure, if there is any need for that. Track of the progress and different versions of the draft can be found at: http://go6.si/ripe501bis/ Cheers from co-authors: Merike, Sander and Jan

3 3

IPv6 stable privacy addresses
by Fernando Gont 10 Apr '12

10 Apr '12

Folks, We've posted a revision of our IETF Internet-Draft entitled "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)". The document is available at: <http://tools.ietf.org/id/draft-gont-6man-stable-privacy-addresses-01.txt> The abstract of the document is: ---- cut here ---- This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. ---- cut here ---- Interested in IPv6 security? -- Follow us on Twitter: @SI6Networks Interested in discussing IPv6 security topics? -- Join the ipv6hackers@ mailing-list at: <http://www.si6networks.com/community/mailing-lists.html> Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

IPv6 SIM cards at RIPE64
by Jan Zorz ＠ go6.si 03 Apr '12

03 Apr '12

Dear IPv6 WG :) For those who are attending RIPE64 meeting in Ljubljana: We just got confirmation from Simobil, one of mobile operators that deployed IPv6 in their mobile network, that they will provide 100 SIM cards for RIPE64 attendees. The cards will be pre-provisioned with IPv6 APN and IPv6 traffic for free. Of course, don't misuse them as they might throttle you if they see any abuse or misuse. For those, who will need also to make phone calls and SMS-es or IPv4 traffic, 5EUR vouchers will be available. Official announcement will go out on a general mailing list, just wante to give you heads-up :) So, fellow IPv6-ers, bring your IPv6 capable devices and enjoy the "IPv6 is in the air" feeling during the RIPE64 meeting in Ljubljana. FYI: Nokia phones works, Android 4 phones usually works, etc... See you in less than two weeks, Jan Zorz, Go6.si

1 0

Re: [ipv6-wg] 2010 IPv4 (and IPv6) Address Use Report
by Silvia Hagen 27 Mar '12

27 Mar '12

Hi Iljitsch Are you updating these for 2011? Thanks Silvia Sunny Connection AG www.sunny.ch +41 (0)44 887 62 10 shagen(a)sunny.ch **************************************************** The new book "Planning for IPv6" has been published with O'Reilly in September 2011. **************************************************** Our website is dual-stack and can be accessed with IPv4 and IPv6 **************************************************** >>> Iljitsch van Beijnum<iljitsch(a)muada.com> 04.01.2011 12:30 >>> [ (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.

2 1

RIPE-501bis: Some additional IPsec comments from Tero Kivinen
by Jan Zorz ＠ go6.si 21 Mar '12

21 Mar '12

Dear IPv6 WG... We received some additional comments from Tero Kivinen. Tero is one of THE experts in IPsec and a long-time implementer. He is part of IETF IPsec wg and a key contributor. As he's not on RIPE IPv6 WG mailinglist, I'm adding him to cc: and at the same time encouraging him to subscribe in order to follow and contribute to the discussion: http://www.ripe.net/mailman/listinfo/ipv6-wg So, his comments are listed below. We would like to "measure the heat" in working group and hear some comments, what you think should be implemented and what not. I explained, that we have certification/testing profiles (NIST, USGv6, IPv6 Ready, etc...) and we have RIPE-501 (soon replaced), that is procurement profile, intended solely as a help to procurement people (usually IPv6-clueless) to order equipment, that makes sense. Tero's comments: -------- In section IPsec: mandatory or optional, I would format the end as following: ---------------------------------------------------------------------- Organizations that use IPsec or expect to use it in the future should include the follwoing in the mandatory section when initiating the tender: * IPsec-v3 [RFC4301, RFC4303, RFC4302] * IKE version 2 (IKEv2) [RFC5996 (obsoletes RFC4306 and RFC4718)] and if support for old IPsec is required add following: * IPsec-v2 [RFC2401, RFC2406, RFC2402] * IKE version 1 (IKEv1, ISAKMP) [RFC2407, RFC2408, RFC2409] ---------------------------------------------------------------------- I.e. prefer IKEv2, and move IKEv1 as separate case. Also note that IKEv1 is tied to IPsec-v2 and IKEv2 is tied to IPsec-v3 and you cannot really mix them that well. Note, also that RFC5996 obsoletged both RFC4306 and RFC4718. This same change should also be done for other places. Also I would rather use IKEv1 than ISAKMP for the old obsoleted key management protocol. ISAKMP is the name of framework on which the IKEv1 protocol is based on (and IKEv2 is also based mostly on the same framework, but everything from that framework document got incorporated to the IKEv2 RFC, so thats why it is not referenced anymore). It seems you do not have IPsec-v2 anywhere, even when you do have IKEv1. What is the reason behind that? IKEv1 works with IPsec-v2, and IPsec-v3 do require IKEv2, so am not sure why IKEv1 is included at all... There are multiple cases where you have "if xxx is requested the equipment must support yyy", where that yyy do require IPsec. Should those be spelled out too. For the Requirements for Mobile Devices the optional support list should probably include RFC4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE), as it is something that is really useful in the mobile nodes. Requirements for Load Balancers: Now the mandatory support has only IKEv1 (ISAKMP), and no IPsec-v2/v3 at all. There isn't really that much that can be done using IKEv1 only. IKEv2 + RFC5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2).) would make some sense even without IPsec-v3, but IKEv1 does not even have any such uses. The optional support list should probably have RFC5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2).) and perhaps RFC6311 (Protocol Support for High Availability of IKEv2/IPsec). The optional list has IKEv1 (ISAKMP) again. ----------- (end of Tero's comments) I think we still are in review phase, so we can implement some changes. I hear that Last Call is planned for after RIPE64 meeting, so we still have time for last changes. As usual, comments and suggestions very warmly welcome. Cheers, Jan Zorz (writing for all co-authors) Go6 Institute Slovenia

3 4

New on RIPE Labs: Growth in IPv6 Capable Infrastructure
by Mirjam Kuehne 19 Mar '12

19 Mar '12

Dear colleagues, Please see this new article on RIPE Labs: "Growth in IPv6 Capable DNS Infrastructure: https://labs.ripe.net/Members/emileaben/growth-in-ipv6-capable-dns-infrastr… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: IPv6 Deployment: Trends and Tidbits of 4, 800 Dual-stack ASes
by Mirjam Kuehne 08 Mar '12

08 Mar '12

Dear colleagues, Please find a new article on RIPE Labs, contributed by Matthew Luckie, Amogh Dhamdhere and Brad Huffaker from CAIDA: "IPv6 Deployment: Trends and Tidbits of 4,800 Dual-stack ASes" https://labs.ripe.net/Members/mirjam/ipv6-deployment-trends-and-tidbits Kind Regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: ASes Announcing IPv6 - One Year Later
by Mirjam Kuehne 05 Mar '12

05 Mar '12

Dear colleagues, Please find a new article on RIPE Labs showing the percentage of ASes announcing IPv6: https://labs.ripe.net/Members/mirjam/networks-with-ipv6-one-year-later It is interesting to see what has changed since we presented this graph for the first time about one year ago. Kind regards, Mirjam Kuehne RIPE NCC

1 0