- ipv6-wg - mailman.ripe.net

2007 IPv4 Address Use Report
by Iljitsch van Beijnum 02 Jan '08

02 Jan '08

2007 IPv4 Address Use Report In 2007, the number of available IPv4 addresses went down from 1300.65 million to 1122.85 million, a difference of 177.8 million addresses. The number of usable addresses is 3706.65 million, so on January 1, 2007 we were at 64.9% utilization and a year later we're at 69.7%. These figures are derived from the records published on the FTP servers of the five Regional Internet Registries (RIRs): AfriNIC, which gives out address space in Africa, APNIC (Asia-Pacific region), ARIN (North America), LACNIC (Latin American and the Caribbean) and the RIPE NCC (Europe, the former Soviet Union and the Middle East). There are two other ways to interpret the same data. The first is simply add up all the address space with a date indicating that it was given out in 2007. That number is 186.93 million addresses. The third method is to compensate for ARIN's record keeping peculiarities (see this Internet Protocol Journal article). This brings the total for 2007 to no less than 196.77 million, the highest number ever. The second-highest was 1991 with 189 million addresses. The 196.77 million figure is approxmately 19% higher than the 2005 and 2006 numbers, which were largely the same. All numbers only include addresses that are still in use. For the first time in many years, in 2007 one of the old class A blocks was returned to IANA: block 46.0.0.0/8, 16.78 million addresses in size, is now part of the global pool of free address space. This accounts for most of the difference between the 177.8 and 196.77 numbers. The status of the 221 usable blocks of 16.78 million address is now as follows: Delegated to Blocks +/- 2007 Addresses (millions) AfriNIC 2 +1 33.55 APNIC 26 +7 436.21 ARIN 27 452.98 LACNIC 6 +2 100.66 RIPE NCC 26 +4 436.21 Various 49 -1 822.08 End-user 42 -1 704.64 Available 43 -12 721.42 In addition to the 43 unused blocks (721.42 million addresses) that IANA holds, there is additional free space in the form of addresses delegated from IANA to the regional internet registries, but not yet further delegated by the RIR in question to an ISP or end-user. 2006-01-01 2007-01-01 delegated delegated free delegated delegated free TO BY TO BY AfriNIC 16.78 6.39 10.39 33.55 11.97 21.58 APNIC 318.77 297.23 21.54 436.21 366.87 69.34 ARIN 452.98 350.48 102.50 452.98 394.08 58.90 LACNIC 67.11 42.71 24.40 100.66 57.52 43.14 RIPE NCC 369.10 317.62 51.48 436.21 378.35 57.86 Total RIRs 1224.74 1014.43 210.31 1459.61 1208.79 250.82 Various 838.86 671.26 167.60 822.08 671.48 150.60 End-user 721.42 704.64 16.78 704.64 671.09 33.55 Available 922.74 16.78 905.96 721.42 16.78 704.64 Total 3707.76 2407.11 1300.65 3707.75 2568.14 1139.61 This view uncovers two inconsistencies: block 7.0.0.0/8 that is part of the free space according to the IANA IPv4 address space overview shows up as delegated to the US Department of Defense in ARIN's records. Net 14.0.0.0/8 is for the "public data net" (see RFCs 3330 and 1700) so it's not part of the regular delegation system. 43.0.0.0/8 is delegated to "Japan Inet" by IANA. Those delegations used to be registered in ARIN's database but this block was transferred to APNIC in 2007, where it does show up in the whois service, but not as part of the delegated address space in the files on the FTP server. The total of 3707.76 (or 3707.75) million addresses is slightly different from the 3706.65 maximum mentioned earlier because the latter excludes all RFC 1918 private address space, the former still includes 192.168.0.0/16 and 172.16.0.0/12. The size of address blocks given out was increasing until 2005, but now shows a downturn. The table below shows the number of delegations for a certain range of block sizes (equal or higher than the first, lower than the second value). (2005 and earlier values from 2006-01-01 data, 2006 and 2007 values from 2007-01-01 data. No correction for the ARIN accounting method.) 2001 2002 2003 2004 2005 2006 2007 < 1000 474 547 745 1022 1309 1507 1830 1000 - 8000 1176 897 1009 1516 1891 2265 2839 8000 - 64k 868 822 1014 1100 1039 1192 1015 64k - 500k 262 163 215 404 309 419 395 500k - 2M 39 29 46 61 60 57 62 > 2M 5 5 6 7 18 17 24 The increase in large blocks has a very dramatic effect while the small blocks are insignificant, when looking at the millions of addresses involved: 2001 2002 2003 2004 2005 2006 2007 < 1000 0.16 0.18 0.25 0.35 0.44 0.51 0.63 1000 - 8000 4.47 3.23 3.45 4.49 5.07 5.83 6.93 8000 - 64k 12.81 11.35 14.00 15.99 15.46 18.01 15.67 64k - 500k 32.19 20.28 25.51 42.01 34.23 50.86 50.83 500k - 2M 24.64 21.30 31.98 44.63 41.63 46.69 45.50 > 2M 14.68 12.58 12.58 20.97 68.62 52.43 67.37 Despite the strong increase in the number of 2 million+ blocks and the amount of address space given out in these blocks, the average block size has been going down because of the very large growth in the numbers of smaller blocks: Year Blocks Addresses (M) Average block size 2000 2794 78.35 28043 2001 2824 88.95 31497 2002 2463 68.93 27985 2003 3035 87.77 28921 2004 4110 128.45 31252 2005 4626 165.45 35765 2006 5457 174.32 31945 2007 6165 186.92 30320 The 2568.14 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: 2007-01-01 2007-01-01 change Country 1 - US 1408.15 M 1366.53 M +3% United States 2 - JP 141.47 M 151.27 M -6% Japan 3 (4) CN 135.31 M 98.02 M +38% China 4 (3) EU 120.35 M 115.83 M +4% Multi-country in Europe 5 - GB 83.50 M 93.91 M -11% United Kingdom 6 - CA 73.20 M 71.32 M +3% Canada 7 - DE 72.46 M 61.59 M +18% Germany 8 - FR 67.79 M 58.23 M +16% France 9 - KR 58.86 M 51.13 M +15% Korea 10 - AU 33.43 M 30.64 M +9% Australia 11 (12) IT 24.04 M 19.14 M +26% Italy 12 (11) BR 23.46 M 19.27 M +22% Brazil 13 (16) MX 21.50 M 16.26 M +32% Mexico 14 (13) ES 20.42 M 18.69 M +9% Spain 15 - NL 19.89 M 18.08 M +10% Netherlands The -6% and -11% figures for the UK and Japan are once again anomalies: the former is the missing 43.0.0.0/8 net and in the latter case, ARIN and RIPE both had a record for 25.0.0.0/8 in the 2007-01-01 data, but this was cleared up in the 2008-01-01 data. Although the US still added more than 40 million new addresses to its immense existing stockpile, its growth was modest percentage-wise and it now holds 55% of the IPv4 address space in use, down from 57%. All of the other countries in the top 15 except for Canada and "EU" saw their address use grow faster than the 7% average. This brings the total for the top 15 excluding the US to 35%, up from 34%. The rest of the world gets the remaining 10%, up from 9%. See http://www.bgpexpert.com/addrspace2007.php for a copy of this report and links to the versions for 2006 and 2005.

1 0

RIPE NCC Makes Record Number of IPv6 Allocations
by Alex Le Heux 14 Dec '07

14 Dec '07

This announcement was posted on the RIPE NCC News & Announcements webpage yesterday: RIPE NCC Makes Record Number of IPv6 Allocations The months of October and November 2007 set new records for the number of IPv6 allocations made in a single month by the RIPE NCC. 24 allocations were made to RIPE NCC members in October, arecord immediately broken by the 31 allocations made in November. The previous peak was 19 allocations in a single month, which was achieved on three separate occasions in 2003, 2004 and 2007. This surge in demand for IPv6 address space follows recent changes in the IPv6 allocation policy, which made it easier to get IPv6 allocations. The increase also comes in the wake of the publication of the RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6. This statement, released immediately after the RIPE 55 meeting in Amsterdam in October, urged all Internet industry stakeholders, including ISPs, governments and regulators, to take steps to foster the accelerating deployment of IPv6. The text of this resolution can be found at: http://www.ripe.net/news/community-statement.html The deployment of IPv6 across the Internet has been a subject of growing global interest, particularly as it relates to the diminishing pool of free IPv4 address space, and the impact that this will have on the ongoing growth and future stability of the Internet. For more information on this, please send an email to <ncc(a)ripe.net>. Best regards, Alex Le Heux Policy Implementation and Coordination, RIPE NCC

14 16

[Fwd: need help with global ipv6 topology measurement]
by Henk Uijterwaal 28 Nov '07

28 Nov '07

-------- Original Message -------- Subject: need help with global ipv6 topology measurement Date: Tue, 27 Nov 2007 15:55:42 -0800 From: k claffy <kc(a)caida.org> To: nanog(a)merit.edu if you have ipv6 connectivity and are willing to volunteer some (low bandwidth) v6 traceroute data to a good cause (== a topology map of observed ipv6 connectivity), please help us out for a few ( estimated < 15) min with: http://www.caida.org/data/how-to/scamper/ipv6-collection-2007/ please share w all your ipv6friends, k -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Is one of the choices leaving the office open? Alan Greenspan on the next elections

1 0

IPv6 policies & BGP announcements
by Clement Cavadore 28 Nov '07

28 Nov '07

Hi, I have a few question regarding IPv6, and policies. I am not LIR, so I cannot get any /32 for my network usage. I got from my LIR a /48 for my internal network needs, and another /48 for another end-user, routed through my network. The two /48 are consecutive, and aggregable as a single /47. - Am I allowed to announce a prefix more specific than my LIR's /32 (originated from my ASN, not the LIR's one) ? - If I can announce a more specific prefix, do I have to announce a couple of /48s, or may I announce a single /47, originated from my AS ? If I can announce the /47, I assume the LIR has to create a route: object ? - Is there any recommendations I'd need to know for such a situation (except becoming LIR, which is not possible for us at the moment) ? Thank you for your help -- Clément Cavadore

5 7

Few questions about IPv6
by Marcin Gondek 15 Nov '07

15 Nov '07

Hello All , I have few question about IPv6 and maybe someone can explain this. Sorry if those information can be found on RIPE page or I'm sending it to wrong mailing list, I'm not able to find it. 1. Do I have to be a LIR to request /32 subnet from RIPE, can be it done by another LIR which will request subnet for me (as its customer)? 2. Do I have to be a LIR to request AS number from RIPE, can be it done by another LIR which will request AS number for me (as its customer)? Thanks in advance. -- Marcin Gondek / Drixter e-utp.net NIP: PL1181589645 REGON: 140584662 Tel. +48602159929 Fax. +48222012418 <mailto:office@e-utp.net> office(a)e-utp.net <http://www.e-utp.net> http://www.e-utp.net

6 9

Commercial IPv6 firewall support
by michael.dillon＠bt.com 08 Nov '07

08 Nov '07

Some people have claimed that they cannot yet sell IPv6 Internet access because there is no IPv6 firewall support. According to this ICANN study: http://www.icann.org/committees/security/sac021.pdf this is not quite true. At least 30% of the 42 vendors surveyed, had IPv6 support. According to this talk <http://www.guug.de/veranstaltungen/ecai6-2007/slides/2007-ECA-I6-Status -IPv6-Firewalling-PeterBieringer-Talk.pdf> many open-source and commercial firewalls supporting IPv6 are available. IPCop is based on Linux <http://www.ipcop.org/index.php?module=pnWikka&tag=IPCopScreenshots> m0n0wall is based on FreeBSD <http://m0n0.ch/wall/screenshots.php> pfSense is also based on FreeBSD <http://pfsense.com/index.php?id=26> FWBuilder is a management tool that builds filter setups for several different firewalls. <http://www.fwbuilder.org/archives/cat_screenshots.html> Checkpoint FW1 NGX R65 on SecurePlatform supports IPv6 FortiGate supports IPv6 in FortiOS 3.0 and up. Juniper SSG (formerly Netscreen) supports IPv6 in ScreenOS 6.0 and up. Cisco ASA (formerly PIX) supports IPv6 in version 7.0 and up. I suspect that the people complaining about IPv6 support are partially complaining because they have older hardware that the vendor does not plan to upgrade to IPv6 support until they have all features implemented in their newer products, and partially complaining because their vendor has not implemented some feature which they happen to use. Commercial firewall support may be lagging behind OS and router support, but not by much. And if commercial vendors are not responsive, maybe you should try pricing out an open source solution with a consultant. I believe there is a gap here that startup firewall companies could fill if they understand the enterprise market. --Michael Dillon

5 5

OT? Ripe NCC posting on youtube
by ed 07 Nov '07

07 Nov '07

Sorry if this is off topic or old news, but I saw this on the SCLUG mailing list. Truly excellent: http://uk.youtube.com/user/RIPENCC -- The 14.4 dialup to the PS2 is doing the twist because of a power outage. AOL is playing way too much Diablo II. :: http://www.s5h.net/ :: http://www.s5h.net/gpg

1 0

Re: [address-policy-wg] Commercial IPv6 firewall support
by jwkckid1＠ix.netcom.com 29 Oct '07

29 Oct '07

Nick and all, Chiming in here as a kinda unusual occurance. I agree with Nicks assessment here unfortunately. Seems across a broad business spectrum a disinterest in IPv6 remains or presists. Given, what I believe to be an accurate essesment by Nick below, it would seem that a more concerted effort to make IPv6 more palatable in very short order is advisable. As to how to accomplish that, I do not know. -----Original Message----- >From: Nick Hilliard <nick(a)inex.ie> >Sent: Oct 27, 2007 9:25 AM >To: michael.dillon(a)bt.com >Cc: address-policy-wg(a)ripe.net, ipv6-wg(a)ripe.net >Subject: Re: [address-policy-wg] Commercial IPv6 firewall support > >> Some people have claimed that they cannot yet sell >> IPv6 Internet access because there is no IPv6 firewall >> support. According to this ICANN study: >> http://www.icann.org/committees/security/sac021.pdf >> this is not quite true. At least 30% of the 42 vendors >> surveyed, had IPv6 support. > >There is, of course, "support" and support when talking about any feature, >whether ipv6 related or not. > >As a useful example of what "support" implies, the "support" from one of my >firewall vendors includes basic support for ipv6 packet forwarding and >filtering, but no support for configuring this from the GUI. And no support >for failover / failback on ipv6. And no support for ospfv3. Or DHCPv6. Or >v6 support for VPNs. And so on - you get the idea. There are piles more >features which just aren't there if you use v6. In fact, I would suggest >that there is such a large functionality gap between their ipv4 and ipv6 >support right now, that even if they invested heavily between now and the >current expected dates for ipv4 exhaustion, I seriously doubt that they >would achieve feature parity, not to mind stability parity for these >features. > >I have talked to them about this, and their opinion is that there is no >commercial demand for ipv6, and therefore ipv6 feature parity is on the >feature roadmap. And indeed, it is difficult for the organisation I work >for to demand ipv6 support, when other companies can talk to their vendors >with a EUR100m firewall / networking contract going a-begging. I have >little doubt that this is the reason that MOP got re-enabled by default on a >certain router vendor's products. > > >Them: "We have EUR200m to spend and we want MOP enabled by default". >Vendor: "Three bags full, sir". > >Me: "I want to you spend $50m in development costs to support ipv6, and > then i'll buy some low end kit from you" >Vendor: <laughs hysterically> > >Open source solutions tend to fare better in this regard. Lots of people >may end up using them in a future ipv6 world, but you're not going to end up >seeing F500 companies stampeding to replace their current high-end solutions >with m0n0wall installations, just because they have more-or-less parity >support for ipv4 and ipv6. > >There's a more interesting discussion of this of this linked from: > >http://www.arin.net/meetings/minutes/ARIN_XX/ppm.html > >See the talk entitled "IPv6 Support Among Commercial Firewalls", by Dave >Piscitello. > >Nick > >-- >Network Ability Ltd. | Technical Operations | Tel: +353 1 6169698 >3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 >Dublin 2, Ireland | Exchange Association | Email: nick(a)inex.ie > 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com

1 0

Re: [ipv6-wg] RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
by Andy Davidson 27 Oct '07

27 Oct '07

On 25 Oct 2007, at 10:55, JORDI PALET MARTINEZ wrote: > 1) Network operators and Internet Service Providers (ISPs) are > called to the urgent deployment of IPv6 across their networks as > soon as possible. This deployment must include providing IPv6 > access to End Users and ensuring services are accessible by IPv6. I thought that yesterday's session was useful (I watched via the webcast), and that the publication of this resolution will send the right signals to decision makers - well done everyone. We have to remember that a lot of networks use only v4 PI, as this is the model typically deployed by end sites who rely on multihoming for performance or reliability reasons. Unless and until 2006-01 becomes approved, there is no migration path to v6 for these networks. We must ratify 2006-01 in order to strengthen the impact of the publication of this resolution. Best wishes, Andy Davidson -- :: http://www.localphone.com/ - Call Global, Pay Local :: /* opinions and thoughts expressed here are my own */

2 1

RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
by JORDI PALET MARTINEZ 25 Oct '07

25 Oct '07

I don't think my comment was well understood today in the session, so I drafted how I think the community resolution should look. See below. English nits should be reviewed, but the main idea is that we start with a short kind of intro of the situation (those points from the original 5 that are generic), staying focus, keeping it short, but at the same time help each "kind of reader" to identify what is the paragraph that is *more* relevant to him. I also added a specific action for policy makers/regulators and one for users. I hope that, as very few people (in the list and session) has provided input on this, we are allowed to participate in the final drafting of the document. Not being a big group is possible to do it, as otherwise, will not really be a community resolution. Regards, Jordi At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point, this event will have a significant influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet. We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space. We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority. In addition to that, other sectors must take their own measures in order to success on this mission: 1) Network operators and Internet Service Providers (ISPs) are called to the urgent deployment of IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. 2) Vendors (hardware and software) are called to the urgent support of IPv6 support in their products, to make it possible for network operators and Internet Service Providers to provide these services. 3) Regulators and policy makers are called to make sure the relevance of the IPv6 support is considered in all their decisions, including as an immediate condition for public procurements. 4) Users must ensure, when acquiring new services, hardware or software, that it supports IPv6 (natively or by means of transition mechanisms). ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

3 3