2005 IPv4 Address Use Report
According to AfriNIC, APNIC, ARIN, LACNIC and RIPE NCC statistics as published on their respective FTP servers, they gave out 165.45 million IPv4 addresses in 2005. Out of 3706.65 million usable IPv4 addresses, 1468.61 million are still available as of januari 1, 2006. Breakdown by Regional Internet Registry over the past few years: 200020012002200320042005 AfriNIC 0.560.380.250.210.511.89 APNIC 21.08 28.84 27.08 33.08 42.92 53.97 ARIN 30.96 32.76 21.02 22.14 33.51 36.30 LACNIC 0.881.570.652.623.77 11.04 RIPE NCC 24.88 25.39 19.94 29.72 47.75 62.25 Total 78.35 88.95 68.93 87.77 128.45 165.45 AfriNIC gives out address space in Africa, APNIC in the Asia-Pacific region, ARIN in North America, LACNIC in Latin American and the Caribbean and the RIPE NCC in Europe, the former Soviet Union and the Middle East. Note that the RIRs tend to change their records retroactively from time to time. For instance, the januari 1, 2005 records show that only 117.3 million addresses were given out in 2004. Also, reclaimed address space isn't listed explicitly. From the fact that the 1-1-2005 records show 1939 million addresses given out before 2004 but the 1-1-2006 records show 1928.48 million addresses for the same period, we can conclude that 11.15 million addresses given out before 2004 have been reclaimed in 2005. The Internet Assigned Numbers Authority (IANA, part of ICANN) keeps an overview of the IPv4 address space at http://www.iana.org/ assignments/ipv4-address-space. The list consists of 256 blocks of 16.78 million addresses. Breakdown: Delegated to Blocks Addresses (millions) AfriNIC 1 16.78 APNIC 16 268.44 ARIN 23 385.88 LACNIC 4 67.11 RIPE NCC 19 318.77 Various50 838.86 End-user 43 721.42 Available 65 1090.52 Of the 1895.83 million addresses delegated to the five Regional Internet Registries, 1517.74 million have been delegated to end-users or ISPs by the RIRs, and 378.09 million are still available. Along with the 1090.52 million addresses still available in the IANA global pool this makes the total number of available addresses 1468.61 million. The size of address blocks given follows an interesting trend. The table below shows the number of requests for a certain range of block sizes (equal or higher than the first, lower than the second value). 200020012002200320042005 < 1000 326 474 547 74510221309 1000 - 8000 6521176 897100915161891 8000 - 64k 1440 868 822101411001039 64k - 500k 354 262 163 215 404 309 500k - 2M 19 39 29 46 61 60 > 2M 3 5 5 6 7 18 The number of blocks in the two smallest categories have increased rapidly, but not as fast as the number of blocks in the largest category, in relative numbers at least. However, the increase in large blocks has a very dramatic effect while the small blocks are insignificant, when looking at the millions of addresses involved: 200020012002200320042005 < 1000 0.100.160.180.250.350.44 1000 - 8000 2.424.473.233.454.495.07 8000 - 64k 18.79 12.81 11.35 14.00 15.99 15.46 64k - 500k 35.98 32.19 20.28 25.51 42.01 34.23 500k - 2M 12.68 24.64 21.30 31.98 44.63 41.63 > 2M8.39 14.68 12.58 12.58 20.97 68.62 The medium-sized blocks seem most affected by the burst of the internet bubble. Another way to look at the same data: YearBlocksAddresses (M) Average block size 2000 279478.3528043 2001 282488.9531497 2002 246368.9327985 2003 303587.7728921 2004 4110 128.4531252 2005 4626 165.4535765 The .38 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: Country Addresses US 1324.93 MUnited States JP 143.00 MJapan EU 113.87 MMulti-country in Europe CN74.39 MChina CA67.43 MCanada DE51.13 MGermany FR45.16 MFrance KR41.91 MKorea UK40.18 MUnited Kingdom GB33.63 MGreat Britain AU26.87 MAustralia IT18.39 MItaly BR
Re: Gmail Contact and Gmail bugs
On 1/1/06, Joe Shen <[EMAIL PROTECTED]> wrote: > Is there way to contact Gmail? Message in my gmail > account could not be access for three days. I'm sure you'll find at least some links for tech support on http://www.gmail.com -srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Gmail Contact and Gmail bugs
Hi, Is there way to contact Gmail? Message in my gmail account could not be access for three days. When I tried to click on any message ( or search, move to othe folder .. ) it always pop up with " Ooops, the system was unable to perform your operation.Please try again in a few seconds". Joe __ Do you Yahoo!? New and Improved Yahoo! Mail - 1GB free storage! http://sg.whatsnew.mail.yahoo.com
Re: Leap second reminder
On (2005-12-31 17:18 -0500), Deepak Jain wrote: Linux seemed to survive happily too [EMAIL PROTECTED] ~]% dmesg|tail -n1 Clock: inserting leap second 23:59:60 UTC Curious though that not so many people who've I asked got these messages, only explanation I can think of is that their NTP peers weren't telling it. Without much NTP clues, could someone explain what steps NTP takes to protect itself from attackers spoofing packets and forcing you to leap? Probably sane implementation would restrict leaping to happen only at 23:59:59, so you'd drift maximum of 1s/d? But crappy implementation might allow you to leap every second. This http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN2950 just tells Most users of NTP do not need authentication as the protocol contains several filters against bad time. So I guess it's pretty implementation spesific how the input is sanitized. > Cisco seems happy as well. (adding leap second, leap second occurs at), etc. > > >sh ntp status > Clock is synchronized (adding leap second), stratum 2, reference is > xxx.xxx.xxx.xxx > nominal freq is 250. Hz, actual freq is 249.9975 Hz, precision is 2**18 > reference time is C7617E39.3A0B3D8C (17:01:29.226 EST Sat Dec 31 2005) > clock offset is 0.5332 msec, root delay is 5.11 msec > root dispersion is 7.72 msec, peer dispersion is 7.14 msec > Leap second occurs at C7619A00. (19:00:00.000 EST Sat Dec 31 2005) > > Happy New Year! > > Deepak > > Gerry Boudreaux wrote: > > > > > >On Dec 31, 2005, at 11:58 AM, Kevin Day wrote: > > > >> > >> > >>Just a reminder, at midnight UTC there's a leap second added to most > >>time systems. > >> > >>Some time systems will stop the clock at 23:59:59.99 for 1 > >>second, some will display 23:59:60 for a second. > >> > >>Since the last leap second (1998), "leap second aware" time keeping > >>systems(NTP, GPS, etc) have become much more prevalent, so it's much > >>more likely this time that applications and NTP sync'ed devices will > >>see a leap second happen(rather than have them manually corrected > >>later, or not corrected at all). But, I'm not too sure how well > >>everyone has tested applications and devices for how they handle the > >>clock stopping for a second OR an "invalid" time of 23:59:60. > >> > >>If anyone sees anything die at 00:00:00UTC I'd be interested to know. > >> > >>-- Kevin > > > > > >My Juniper seems to be aware: > > > >[EMAIL PROTECTED]> show ntp status > >status=4694 leap_add_sec, sync_ntp, 9 events, event_peer/strat_chg, > >version="ntpd 4.1.0-a Thu Jul 14 23:46:40 GMT 2005 (1)", > >processor="i386", system="JUNOS7.3R1.5", leap=01, stratum=3, > >precision=-30, rootdelay=40.669, rootdispersion=49.522, peer=35302, > >refid=ntpx.xxx.xxx, > >reftime=c7615c1c.65f78359 Sat, Dec 31 2005 13:35:56.398, poll=10, > >clock=c7615d8e.d66d698f Sat, Dec 31 2005 13:42:06.837, state=4, > >offset=-2.649, frequency=73.810, jitter=5.194, stability=0.024 > > > >note the leap=01 and leap_add_sec > > > > > > > > > -- ++ytti
