From mir at ripe.net Mon Mar 5 16:15:16 2012 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 05 Mar 2012 16:15:16 +0100 Subject: [ipv6-wg] New on RIPE Labs: ASes Announcing IPv6 - One Year Later Message-ID: <4F54D884.2040308@ripe.net> 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 From mir at ripe.net Thu Mar 8 12:05:33 2012 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 08 Mar 2012 12:05:33 +0100 Subject: [ipv6-wg] New on RIPE Labs: IPv6 Deployment: Trends and Tidbits of 4, 800 Dual-stack ASes Message-ID: <4F58927D.2040109@ripe.net> 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 From mir at ripe.net Mon Mar 19 16:00:11 2012 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 19 Mar 2012 16:00:11 +0100 Subject: [ipv6-wg] New on RIPE Labs: Growth in IPv6 Capable Infrastructure Message-ID: <4F6749FB.8080907@ripe.net> 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-infrastructure Kind regards, Mirjam Kuehne RIPE NCC From jan at go6.si Tue Mar 20 19:18:31 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 20 Mar 2012 19:18:31 +0100 Subject: [ipv6-wg] RIPE-501bis: Some additional IPsec comments from Tero Kivinen Message-ID: <4F68C9F7.8090402@go6.si> 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 From ip at ioshints.info Tue Mar 20 20:27:21 2012 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 20 Mar 2012 20:27:21 +0100 Subject: [ipv6-wg] RIPE-501bis: Some additional IPsec comments from Tero Kivinen In-Reply-To: <4F68C9F7.8090402@go6.si> References: <4F68C9F7.8090402@go6.si> Message-ID: <003b01cd06cf$7c23cb90$746b62b0$@info> I'm absolutely in agreement with IPsec-v3+IKEv2 being preferred over IPsec-v2+IKEv1 and both being explicitly spelled out. I honestly don't know what IPsec, ISAKMP and IKE are doing in the "Load balancer" section (which is a total embarrassment because I contributed some text to that section ;). IPsec/VPN functions are usually handled by other devices, not by load balancers. If someone thinks IPsec suite should be listed in that section, then please make it OPTIONAL and use the same set of protocols/RFCs as everywhere else (for example, in "Routers and switches" section). I can't imagine why load balancers would have other IPsec/IKE requirements than other networking devices (but then I'm often ignorant and like to be corrected ;). Would that make sense? Ivan > -----Original Message----- > From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf > Of Jan Zorz @ go6.si > Sent: Tuesday, March 20, 2012 7:19 PM > To: ipv6-wg at ripe.net > Cc: Tero Kivinen > Subject: [ipv6-wg] RIPE-501bis: Some additional IPsec comments from Tero > Kivinen > > 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 From merike at doubleshotsecurity.com Tue Mar 20 23:35:00 2012 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Tue, 20 Mar 2012 15:35:00 -0700 Subject: [ipv6-wg] RIPE-501bis: Some additional IPsec comments from Tero Kivinen In-Reply-To: <003b01cd06cf$7c23cb90$746b62b0$@info> References: <4F68C9F7.8090402@go6.si> <003b01cd06cf$7c23cb90$746b62b0$@info> Message-ID: <5FC46D32-791D-41C9-8A3A-EC2AE8A7ADE4@doubleshotsecurity.com> Sigh. As I mentioned to Jan separately after seeing his post, the comments from Tero were based on an older version of RIPE-501bis and I (and Jan) pointed him to the newer version. I think Jan got a bit eager to distribute Tero's comments and I fear they could cause some confusion since we DID take out all reference to IKEv1 and updated to all the updated RFCs. Also, as per the last ditch at consensus on IPsec, it was all moved to optional. - merike On Mar 20, 2012, at 12:27 PM, Ivan Pepelnjak wrote: > I'm absolutely in agreement with IPsec-v3+IKEv2 being preferred over IPsec-v2+IKEv1 and both being explicitly spelled out. > > I honestly don't know what IPsec, ISAKMP and IKE are doing in the "Load balancer" section (which is a total embarrassment because I contributed some text to that section ;). IPsec/VPN functions are usually handled by other devices, not by load balancers. If someone thinks IPsec suite should be listed in that section, then please make it OPTIONAL and use the same set of protocols/RFCs as everywhere else (for example, in "Routers and switches" section). > > I can't imagine why load balancers would have other IPsec/IKE requirements than other networking devices (but then I'm often ignorant and like to be corrected ;). > > Would that make sense? > Ivan > >> -----Original Message----- >> From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf >> Of Jan Zorz @ go6.si >> Sent: Tuesday, March 20, 2012 7:19 PM >> To: ipv6-wg at ripe.net >> Cc: Tero Kivinen >> Subject: [ipv6-wg] RIPE-501bis: Some additional IPsec comments from Tero >> Kivinen >> >> 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 > > > From jan at go6.si Wed Mar 21 07:27:11 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 21 Mar 2012 07:27:11 +0100 Subject: [ipv6-wg] RIPE-501bis: Some additional IPsec comments from Tero Kivinen In-Reply-To: <5FC46D32-791D-41C9-8A3A-EC2AE8A7ADE4@doubleshotsecurity.com> References: <4F68C9F7.8090402@go6.si> <003b01cd06cf$7c23cb90$746b62b0$@info> <5FC46D32-791D-41C9-8A3A-EC2AE8A7ADE4@doubleshotsecurity.com> Message-ID: <4F6974BF.4060400@go6.si> On 3/20/12 11:35 PM, Merike Kaeo wrote: > Sigh. As I mentioned to Jan separately after seeing his post, the > comments from Tero were based on an older version of RIPE-501bis and > I (and Jan) pointed him to the newer version. I think Jan got a bit > eager to distribute Tero's comments and I fear they could cause some > confusion since we DID take out all reference to IKEv1 and updated to > all the updated RFCs. Hi, I copy/pasted comments from Tero's latest email, after redirect to newest draft of intended replacement doc. Let's find out relevant parts and see what we can use. Cheers, Jan From merike at doubleshotsecurity.com Wed Mar 21 12:10:55 2012 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Wed, 21 Mar 2012 04:10:55 -0700 Subject: [ipv6-wg] RIPE-501bis: Some additional IPsec comments from Tero Kivinen In-Reply-To: <4F6974BF.4060400@go6.si> References: <4F68C9F7.8090402@go6.si> <003b01cd06cf$7c23cb90$746b62b0$@info> <5FC46D32-791D-41C9-8A3A-EC2AE8A7ADE4@doubleshotsecurity.com> <4F6974BF.4060400@go6.si> Message-ID: On Mar 20, 2012, at 11:27 PM, Jan Zorz @ go6.si wrote: > On 3/20/12 11:35 PM, Merike Kaeo wrote: >> Sigh. As I mentioned to Jan separately after seeing his post, the >> comments from Tero were based on an older version of RIPE-501bis and >> I (and Jan) pointed him to the newer version. I think Jan got a bit >> eager to distribute Tero's comments and I fear they could cause some >> confusion since we DID take out all reference to IKEv1 and updated to >> all the updated RFCs. > > Hi, > > I copy/pasted comments from Tero's latest email, after redirect to newest draft of intended replacement doc. You are right!! Mea culpa. Too much multi-tasking. > Let's find out relevant parts and see what we can use. All of what Tero sais is relevant - the one aspect I would like input from community is whether they still want IKEv1 in recommendations, even optional. The ISAKMP references should be taken out if IKEv2 is the only requirement the RIPE community wants to make for tender input. For rest of community - Tero initially sent me his comments when he saw the document in a Finnish IPv6 Forum meeting a few weeks ago - I've known him through IPsec wg in IETF for years. He is an implementor and primary standards contributor so he is well aware of what folks are actively deploying wrt IPsec. He has implemented IPsec in IPv6 environments for well over 6 years (if not longer). - merike From shagen at sunny.ch Mon Mar 26 13:27:32 2012 From: shagen at sunny.ch (Silvia Hagen) Date: Mon, 26 Mar 2012 13:27:32 +0200 Subject: [ipv6-wg] 2010 IPv4 (and IPv6) Address Use Report In-Reply-To: 1294140857.14092.igel,S=11608 References: 1294140857.14092.igel,S=11608 Message-ID: <4F706EC4.8D74.0096.1@sunny.ch> Hi Iljitsch Are you updating these for 2011? Thanks Silvia Sunny Connection AG www.sunny.ch +41 (0)44 887 62 10 shagen at 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 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 really 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 space 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iljitsch at muada.com Tue Mar 27 13:10:57 2012 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 27 Mar 2012 13:10:57 +0200 Subject: [ipv6-wg] 2010 IPv4 (and IPv6) Address Use Report In-Reply-To: <4F706EC4.8D74.0096.1@sunny.ch> References: 1294140857.14092.igel,S=11608 <4F706EC4.8D74.0096.1@sunny.ch> Message-ID: <90DF58BF-18A4-414B-87D0-915FBF5EE013@muada.com> On 26 Mar 2012, at 13:27 , Silvia Hagen wrote: > Are you updating these for 2011? You know, I really should. Maybe a delay until April first is appropriate this year anyway. :-) I'll do this in the next few days. Iljitsch