Re: IPV4 as a Commodity for Profit
Thus spake "Tom Vest" <[EMAIL PROTECTED]> I agree, to a point. My prediction is that when the handful of mega-ISPs are unable to get the massive quantities of IPv4 addresses they need (a few dozen account for 90% of all consumption in the ARIN region)... I keep reading assertions like this. Is there any public, authoritative evidence to support this claim? Rechecking my own post to PPML, 73 Xtra Large orgs held 79.28% of ARIN's address space as of May 07; my apology for a faulty memory, but it's not off by enough to invalidate the point. The statistics came from ARIN Member Services in response to an email inquiry. I don't believe they publish such things anywhere (other than what's in WHOIS), but you can verify yourself if you wish; they were quite willing to give me any stats I asked for if they had the necessary data available. If there is, is this 90% figure a new development, or rather the product of changes in ownership (e.g., MCI-VZ-UU, SBC-ATT, etc.), changes in behavior (a run on the bank), some combination of the two, or something else altogether? Most of the orgs in the Xtra Large class were already there before the mega-mergers started; after all, you only need >/14 to be Xtra Large. Given how most tend to operate in silos, they might still be separate orgs as far as ARIN is concerned... S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: IPV4 as a Commodity for Profit
Hi Iljitsch, Thanks for your response. On Feb 23, 2008, at 1:38 AM, Iljitsch van Beijnum wrote: On 22 feb 2008, at 16:41, Tom Vest wrote: You can download files with all the delegation info from ftp.arin.net. You mean the stats files, which provide delegation date, type, starting number, length, etc.? Yes. Which one of the published fields is the key field that enables you to identify the common recipient(s) of successive delegations over time? There is no such field. I didn't think so. So there is no accurate way to get anything like a sum of IP address per LIR at any point in time, now or in the the past, at least not using publicly available data. Given that impossibility, I still don't see how anyone can make the (increasingly oft repeated) claim that 90% (or any specific share) of address space is now going to some subset of the LIRs... no? No, simply because large ISPs need lots of addresses, everyone else can make do with just a few. But in the absence of some other metric for largeness, that sounds like a tautology. Large ISPs are the ones that demand lots of addresses... ergo to demand a lot of addresses is to be large... You've got a point there. However, I think many of us will be able to judge ISP size from other factors and observe that the correlation by the such determined ISP size and address use is quite high. I agree that many of us can estimate ISP size even more accurately, by looking at the sum of address space originated by well-known ASes associated with those ISPs. I think many of us will recognize that there may be other, less well-known ASes associated with some of these, and so an accounting of the well-known ones is incomplete, perhaps a lower bound. I agree that some of us can correlate the contents of the routing table over time with the entries in the delegated files, to get very loose inter-temporal (delegation- origination) associations, which have been shaped over time in opaque ways by M&A, multihoming, customer management and traffic engineering engineering practices, etc. However, I still haven't seen anything that enables one to penetrate this fog of largely unknowable commercial and operational details sufficiently to justify the 90% claim -- or any other claim. If there is some known method for doing this, and hence some defensible way to derive the actual (maybe 90%?) ratio, then I'd still be very interested to hear about it! I think all of the academics who spent several years trying (with mixed results) to come up with algorithms for inferring inter-AS relationships, etc. would be very interested too! Thanks, TV
Re: IPV4 as a Commodity for Profit
On 22 feb 2008, at 16:41, Tom Vest wrote: You can download files with all the delegation info from ftp.arin.net. You mean the stats files, which provide delegation date, type, starting number, length, etc.? Yes. Which one of the published fields is the key field that enables you to identify the common recipient(s) of successive delegations over time? There is no such field. No, simply because large ISPs need lots of addresses, everyone else can make do with just a few. But in the absence of some other metric for largeness, that sounds like a tautology. Large ISPs are the ones that demand lots of addresses... ergo to demand a lot of addresses is to be large... You've got a point there. However, I think many of us will be able to judge ISP size from other factors and observe that the correlation by the such determined ISP size and address use is quite high. To turn things around: does anyone know about a significant amount of address space (say, a block of a million or so or more) going to an entity that isn't an ISP of some sort in the past 5 years?
Re: IPV4 as a Commodity for Profit
In article <[EMAIL PROTECTED]>, Tony Finch <[EMAIL PROTECTED]> writes I would not be surprised to learn that "consumption in the ARIN region" includes all the legacy assignments. Many legacy assignments are now administered by the other RIRs http://www.iana.org/assignments/ipv4-address-space I should have said: "...includes all the legacy assignments in the ARIN region". -- Roland Perry
Re: IPV4 as a Commodity for Profit
On Fri, 22 Feb 2008, Roland Perry wrote: > > I would not be surprised to learn that "consumption in the ARIN region" > includes all the legacy assignments. Many legacy assignments are now administered by the other RIRs http://www.iana.org/assignments/ipv4-address-space Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ WIGHT PORTLAND PLYMOUTH: SOUTHWEST 5 OR 6, OCCASIONALLY 7 IN WIGHT, DECREASING 4 AT TIMES. MODERATE OR ROUGH. OCCASIONAL DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: IPV4 as a Commodity for Profit
On Feb 22, 2008, at 7:54 PM, Iljitsch van Beijnum wrote: On 22 feb 2008, at 0:55, Tom Vest wrote: I agree, to a point. My prediction is that when the handful of mega-ISPs are unable to get the massive quantities of IPv4 addresses they need (a few dozen account for 90% of all consumption in the ARIN region)... I keep reading assertions like this. Is there any public, authoritative evidence to support this claim? You can download files with all the delegation info from ftp.arin.net. You mean the stats files, which provide delegation date, type, starting number, length, etc.? Which one of the published fields is the key field that enables you to identify the common recipient(s) of successive delegations over time? I'm assuming that the quoted 90% figure is some kind of aggregate (anything else would be pretty arbitrary), but I don't see anything in the public record that suggests how that aggregate might be produced...? If there is, is this 90% figure a new development, or rather the product of changes in ownership (e.g., MCI-VZ-UU, SBC-ATT, etc.), changes in behavior (a run on the bank), some combination of the two, or something else altogether? No, simply because large ISPs need lots of addresses, everyone else can make do with just a few. But in the absence of some other metric for largeness, that sounds like a tautology. Large ISPs are the ones that demand lots of addresses... ergo to demand a lot of addresses is to be large... My question is not an entirely uninformed one. I'm quite familiar with the public stats. I just don't see how they transparently support this claim. Clarification would be greatly appreciated, TV On 22 feb 2008, at 10:24, Roland Perry wrote: I would not be surprised to learn that "consumption in the ARIN region" includes all the legacy assignments. By definition, no new legacy assignments are given out. :-) So simply looking at recent data will correct for this. So the quoted metric may well be true, but as unhelpful as claiming that "MIT has more address space than the whole of China" (as some people do from time to time). Which is complete nonsense. MIT has 18/8, which is a little under 17 million addresses. I'm assuming that whatever else on top of that they have doesn't amount to a significant number. China is eating up IPv4 address space like it's going out of style (hm...) and they're now the third largest holder with 140 million IPv4 addresses, a hair shy of Japan's 142 million and 1/10th of the US's 1411 million. On 22 feb 2008, at 10:31, Randy Bush wrote: dear arin hostfolk. could we please have the histogram for the last few years where the Y axis is the amount of allocation and the X axis is the number of organizations with that total size of new allocations during the period? you'll have to bucket alloc size in some useful way, probably a /16 or shorter or something. I can't see organizations in ARIN's delegation records, but simply counting delegations and rounding sizes to the closest power of 2 results this for 20070101 - now: +--+-++ | size | delegations | Maddrs | +--+-++ | 10 | 2 | 6.82 | | 11 | 5 | 11.27 | | 12 | 6 | 6.14 | | 13 | 6 | 2.96 | | 14 | 5 | 1.14 | | 15 | 12 | 1.58 | | 16 | 24 | 1.53 | | 17 | 27 | 0.87 | | 18 | 51 | 0.82 | | 19 | 110 | 0.90 | | 20 | 474 | 1.94 | | 21 | 227 | 0.46 | | 22 | 415 | 0.42 | | 23 | 1 | 0.00 | | 24 | 11 | 0.00 | +--+-++ Totals: +-++ | delegations | Maddrs | +-++ |1376 | 36.86 | +-++ I.e., /18 or shorter is 134 delegations (10%) and 33.08 million addresses (90%). However, ARIN has the unfortunate practice of backdating delegations when people come back for more address space and the new and old blocks can form a bigger block. Below the same numbers but with logic that tries to correct for this, which makes it impossible to easily show the correct numbers of delegations and addresses in one table: +--+-+ | size | delegations | +--+-+ |8 | 1 | | 10 | 4 | | 11 | 13 | | 12 | 12 | | 13 | 12 | | 14 | 17 | | 15 | 35 | | 16 | 38 | | 17 | 61 | | 18 | 95 | | 19 | 222 | | 20 | 440 | | 21 | 231 | | 22 | 425 | | 23 | 5 | | 24 | 13 | +--+-+ +--++ | size | Maddrs | +--++ |8 | 3.15 | | 10 | 7.34 | | 11 | 16.58 | | 12 | 8.37 | | 13 | 2.74 | | 14 | 1.39 | | 15 | 3.31 | | 16 | 0.14 | | 17 | 1.12 | | 18 | 0.
Re: IPV4 as a Commodity for Profit
On 22 feb 2008, at 0:55, Tom Vest wrote: I agree, to a point. My prediction is that when the handful of mega-ISPs are unable to get the massive quantities of IPv4 addresses they need (a few dozen account for 90% of all consumption in the ARIN region)... I keep reading assertions like this. Is there any public, authoritative evidence to support this claim? You can download files with all the delegation info from ftp.arin.net. If there is, is this 90% figure a new development, or rather the product of changes in ownership (e.g., MCI-VZ-UU, SBC-ATT, etc.), changes in behavior (a run on the bank), some combination of the two, or something else altogether? No, simply because large ISPs need lots of addresses, everyone else can make do with just a few. On 22 feb 2008, at 10:24, Roland Perry wrote: I would not be surprised to learn that "consumption in the ARIN region" includes all the legacy assignments. By definition, no new legacy assignments are given out. :-) So simply looking at recent data will correct for this. So the quoted metric may well be true, but as unhelpful as claiming that "MIT has more address space than the whole of China" (as some people do from time to time). Which is complete nonsense. MIT has 18/8, which is a little under 17 million addresses. I'm assuming that whatever else on top of that they have doesn't amount to a significant number. China is eating up IPv4 address space like it's going out of style (hm...) and they're now the third largest holder with 140 million IPv4 addresses, a hair shy of Japan's 142 million and 1/10th of the US's 1411 million. On 22 feb 2008, at 10:31, Randy Bush wrote: dear arin hostfolk. could we please have the histogram for the last few years where the Y axis is the amount of allocation and the X axis is the number of organizations with that total size of new allocations during the period? you'll have to bucket alloc size in some useful way, probably a /16 or shorter or something. I can't see organizations in ARIN's delegation records, but simply counting delegations and rounding sizes to the closest power of 2 results this for 20070101 - now: +--+-++ | size | delegations | Maddrs | +--+-++ | 10 | 2 | 6.82 | | 11 | 5 | 11.27 | | 12 | 6 | 6.14 | | 13 | 6 | 2.96 | | 14 | 5 | 1.14 | | 15 | 12 | 1.58 | | 16 | 24 | 1.53 | | 17 | 27 | 0.87 | | 18 | 51 | 0.82 | | 19 | 110 | 0.90 | | 20 | 474 | 1.94 | | 21 | 227 | 0.46 | | 22 | 415 | 0.42 | | 23 | 1 | 0.00 | | 24 | 11 | 0.00 | +--+-++ Totals: +-++ | delegations | Maddrs | +-++ |1376 | 36.86 | +-++ I.e., /18 or shorter is 134 delegations (10%) and 33.08 million addresses (90%). However, ARIN has the unfortunate practice of backdating delegations when people come back for more address space and the new and old blocks can form a bigger block. Below the same numbers but with logic that tries to correct for this, which makes it impossible to easily show the correct numbers of delegations and addresses in one table: +--+-+ | size | delegations | +--+-+ |8 | 1 | | 10 | 4 | | 11 | 13 | | 12 | 12 | | 13 | 12 | | 14 | 17 | | 15 | 35 | | 16 | 38 | | 17 | 61 | | 18 | 95 | | 19 | 222 | | 20 | 440 | | 21 | 231 | | 22 | 425 | | 23 | 5 | | 24 | 13 | +--+-+ +--++ | size | Maddrs | +--++ |8 | 3.15 | | 10 | 7.34 | | 11 | 16.58 | | 12 | 8.37 | | 13 | 2.74 | | 14 | 1.39 | | 15 | 3.31 | | 16 | 0.14 | | 17 | 1.12 | | 18 | 0.84 | | 19 | 1.39 | | 20 | 1.27 | | 21 | 0.47 | | 22 | 0.43 | | 23 | 0.00 | | 24 | 0.00 | +--++ Total delegations: 1624, millions of addresses: 48.55. /18 or more: 195 (12%), 44.16 (91%).
The Cidr Report
This report has been generated at Fri Feb 22 21:14:25 2008 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
15-02-08250364 161071
16-02-08250469 161143
17-02-08250593 161385
18-02-08250576 161638
19-02-08250779 162145
20-02-08250973 162448
21-02-08250931 162098
22-02-08251555 162482
AS Summary
27568 Number of ASes in routing system
11593 Number of ASes announcing only one prefix
1578 Largest number of prefixes announced by an AS
AS4755 : VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System
88763904 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 22Feb08 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 251770 1624638930735.5% All ASes
AS4755 1578 408 117074.1% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS9498 1163 111 105290.5% BBIL-AP BHARTI BT INTERNET
LTD.
AS4323 1372 511 86162.8% TWTC - Time Warner Telecom,
Inc.
AS18566 1042 253 78975.7% COVAD - Covad Communications
Co.
AS22773 873 94 77989.2% CCINET-2 - Cox Communications
Inc.
AS11492 1207 456 75162.2% CABLEONE - CABLE ONE
AS19262 884 152 73282.8% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS8151 1171 482 68958.8% Uninet S.A. de C.V.
AS17488 992 336 65666.1% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS15270 641 55 58691.4% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS6478 928 381 54758.9% ATT-INTERNET3 - AT&T WorldNet
Services
AS2386 1368 858 51037.3% INS-AS - AT&T Data
Communications Services
AS18101 712 225 48768.4% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS6197 1034 551 48346.7% BATI-ATL - BellSouth Network
Solutions, Inc
AS4766 855 397 45853.6% KIXS-AS-KR Korea Telecom
AS4812 553 95 45882.8% CHINANET-SH-AP China Telecom
(Group)
AS19916 556 100 45682.0% ASTRUM-0001 - OLM LLC
AS7011 1060 614 44642.1% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS7018 1448 1007 44130.5% ATT-INTERNET4 - AT&T WorldNet
Services
AS855554 136 41875.5% CANET-ASN-4 - Bell Aliant
AS7545 497 115 38276.9% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS4808 513 136 37773.5% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS6389 667 294 37355.9% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS9443 451 78 37382.7% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS17676 506 134 37273.5% GIGAINFRA BB TECHNOLOGY Corp.
AS6140 608 238 37060.9% IMPSAT-USA - ImpSat USA, Inc.
AS6198 645 277 36857.1% BATI-MIA - BellSouth Network
Solutions, Inc
AS4668 524 173 35167.0% LGNET-AS-KR LG CNS
AS16814 426 80 34681.2% NSS S.A.
AS5668 675 330 34551.1% AS-5668 - CenturyTel Internet
Holdings, Inc.
Total
BGP Update Report
BGP Update Report Interval: 21-Jan-08 -to- 21-Feb-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS949877065 1.3% 63.7 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - AS24731 58209 1.0%1119.4 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 3 - AS815151119 0.9% 43.3 -- Uninet S.A. de C.V. 4 - AS958351004 0.9% 42.4 -- SIFY-AS-IN Sify Limited 5 - AS480249666 0.9% 95.7 -- ASN-IINET iiNet Limited 6 - AS20214 42564 0.7% 9.2 -- CCCH-AS6 - Comcast Cable Communications Holdings, Inc 7 - AS702937990 0.7% 105.2 -- WINDSTREAM - Windstream Communications Inc 8 - AS26829 37340 0.7% 37340.0 -- YKK-USA - YKK USA,INC 9 - AS33783 37196 0.6% 273.5 -- EEPAD 10 - AS845236257 0.6% 29.9 -- TEDATA TEDATA 11 - AS462127660 0.5% 179.6 -- UNSPECIFIED UNINET-TH 12 - AS983527231 0.5% 214.4 -- GITS-TH-AS-AP Government Information Technology Services 13 - AS982926727 0.5% 33.0 -- BSNL-NIB National Internet Backbone 14 - AS473925606 0.4% 110.8 -- CIX-ADELAIDE-AS Internode Systems Pty Ltd 15 - AS21332 24839 0.4% 955.3 -- NTC-AS New Telephone Company 16 - AS17488 23944 0.4% 23.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 17 - AS238622351 0.4% 15.8 -- INS-AS - AT&T Data Communications Services 18 - AS24863 22031 0.4% 23.7 -- LINKdotNET-AS 19 - AS20858 21433 0.4% 94.4 -- EGYNET-AS 20 - AS461820555 0.4% 337.0 -- INET-TH-AS Internet Thailand Company Limited TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS26829 37340 0.7% 37340.0 -- YKK-USA - YKK USA,INC 2 - AS19334 18498 0.3% 18498.0 -- SPORTLINE-DBC - SPORTLINE 3 - AS404749552 0.2%9552.0 -- ABML-2 - Advantage Business Media, LLC 4 - AS309297453 0.1%7453.0 -- HUTCB Hidrotechnical Faculty - Technical University 5 - AS22629 13496 0.2%6748.0 -- NORWORLD - NORTHWESTERN CORPORATION 6 - AS414825819 0.1%5819.0 -- CLUEAG-AS Clue AG IT Solutions 7 - AS134955737 0.1%5737.0 -- NTT do Brasil Telecomunicaoes Ltda 8 - AS322075637 0.1%5637.0 -- 9 - AS212915029 0.1%5029.0 -- OMEGABANK 8 Dragatsaniou str 10 - AS193898847 0.1%4423.5 -- GOLUB - GOLUB CORPORATION 11 - AS190174027 0.1%4027.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 12 - AS289778020 0.1%4010.0 -- UN-UNLB United Nations Logistics Base Brindisi, Italy 13 - AS292253808 0.1%3808.0 -- TAIF-TELCOM-AS JSC TAIF-TELCOM 14 - AS9179 9417 0.2%3139.0 -- KNOWTION-LONDON Knowtion Ltd. 15 - AS27197 12306 0.2%3076.5 -- 16 - AS32913 0.1%2913.0 -- BUSINESSUNITY-AS Business Unity Ltd. 17 - AS145765802 0.1%2901.0 -- RHNL-NET - Righthosting.com 18 - AS797410849 0.2%2712.2 -- Instituto Mexicano del Petroleo 19 - AS404882708 0.1%2708.0 -- NII-RICHFIELD - National Interstate Insurance Company 20 - AS286462617 0.1%2617.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.101.87.0/24 52509 0.8% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - 203.55.229.160/2 47153 0.8% AS4802 -- ASN-IINET iiNet Limited 3 - 12.108.254.0/24 37340 0.6% AS26829 -- YKK-USA - YKK USA,INC 4 - 124.7.35.0/24 28991 0.5% AS9583 -- SIFY-AS-IN Sify Limited 5 - 80.243.64.0/2024314 0.4% AS21332 -- NTC-AS New Telephone Company 6 - 203.16.208.0/24 24176 0.4% AS4739 -- CIX-ADELAIDE-AS Internode Systems Pty Ltd 7 - 202.140.63.0/24 19807 0.3% AS17443 -- ESTELCOM-AP International Internet gateway , India AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 8 - 64.79.128.0/1919485 0.3% AS23005 -- SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 9 - 207.181.144.0/24 19299 0.3% AS19750 -- CTI-TX - C2C Fiber, Inc. AS32004 -- BIG-ASN - Business Information Group, Inc. 10 - 63.169.11.0/2418498 0.3% AS19334 -- SPORTLINE-DBC - SPORTLINE 11 - 89.4.130.0/24 14319 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 12 - 89.4.131.0/24 14142 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 13 - 89.4.128.0/24 12558 0.2% AS24731 -- ASN-NESMA National Engineering Services and Market
RE: IPV4 as a Commodity for Profit
> Operational comment: Look on the bright side, they may follow > Comcast's example and deploy ipv6 instead! Or they may not, and their share price will suffer as a result. People making the technical decision to stick with IPv4 for their large network are also making a decision to limit the growth of the network and to limit the growth of the business. As the IPv4 exhaustion issue becomes more widely understood, companies who have not prepared themselves to deploy IPv6 will find themselves under increasing scrutiny by shareholders. Comcast moved to IPv6 because their network was running out of RFC 1918 space. Since DOCSIS 3 includes IPv6 support, they made the decision to go to IPv6 rather than continue to spend money on shoehorning themselves into the limited IPv4 address space. Many people have not yet come to terms with how big the IPv6 space is, even the /32 that an ISP gets or the /48 that a site gets. We probably need to start talking about the number of subnetting bits available. For instance, an IPv4 ISP who assigns a /24 to subnets within their architecture and who has a /16 allocated for their architecture, has 8 bits available to subnet with. If an IPv6 ISP decides to assign a /64 to subnets and allocate a single /48 then they will also have 8 subnet bits available. So you could consider a /48 to be roughly equivalent to an IPv4 /16. Now, if an IPv6 ISP decides to strictly follow the rule of assigning a /48 per site internally, then each PoP or data center will be allocated a /48 meaning that each PoP or data center now has 8 subnet bits available. This amount of legroom allows you to do things like standardize subnet layouts for all sites, regardless of size, including the actual bits used from the 8 subnet bits. For instance, you can predict that if a PoP has 2001:1918:123/48 you know that if there is a switch connecting to a data center at that site, it will have the IPv6 address 2001:1918:123:d033::1 because your standard design has ::d033/64 assigned to the switch filling that role and Interface ID 1 assigned to its management interface. This kind of standardization makes it much easier to deploy PoPs regardless of whether it is in Dubai, where the data center is a half rack of webservers, or The Dalles where it is a 40,000 square foot warehouse. It also simplifies management and troubleshooting of the network. --Michael Dillon
Re: IPV4 as a Commodity for Profit
dear arin hostfolk. could we please have the histogram for the last few years where the Y axis is the amount of allocation and the X axis is the number of organizations with that total size of new allocations during the period? you'll have to bucket alloc size in some useful way, probably a /16 or shorter or something. thanks. randy
Re: IPV4 as a Commodity for Profit
In article <[EMAIL PROTECTED]>, Tom Vest <[EMAIL PROTECTED]> writes My prediction is that when the handful of mega-ISPs are unable to get the massive quantities of IPv4 addresses they need (a few dozen account for 90% of all consumption in the ARIN region)... I keep reading assertions like this. Is there any public, authoritative evidence to support this claim? If there is, is this 90% figure a new development, or rather the product of changes in ownership (e.g., MCI-VZ-UU, SBC-ATT, etc.), changes in behavior (a run on the bank), some combination of the two, or something else altogether? I would not be surprised to learn that "consumption in the ARIN region" includes all the legacy assignments. So the quoted metric may well be true, but as unhelpful as claiming that "MIT has more address space than the whole of China" (as some people do from time to time). In the current context, just because they have received large allocations in the past, does not mean these few dozen ISPs will necessarily need similarly large new ipv4 allocations in future. Operational comment: Look on the bright side, they may follow Comcast's example and deploy ipv6 instead! -- Roland Perry
