Slashdot Mirror

You can get an IPv6 assignment:
https://www.ripe.net/publicati...

You also use the opportunity to no longer need to work with the next ISP to have your addresses routed by using one-to-one NAT (not the far more commom port address translation, which is yucky). With one-to-one NAT, each machine still has a seperate IP, you can just map the network prefix from FF08:x to BEEF:x or whatever at the router. You can change ISPs instantly in an emergency.

And from the RIPE address plan manual

"So a /48 should be used when there is any doubt whether a /56 is sufficient in the long run. ISPs
get much leeway in determining the prefix size they give to their customers up to /48–even in
the case of home users"

I would say there is always a doubt that a /56 may be insufficient. A /56 only allows for 256 networks.

The unusual thing about comcast is they are an insanely large triple play provider with a heavy reliance on IP. Their triple play services ended up using about 8-9 IP addresses per household* . Of these only one (the customer's internet device) needed to be a public IP but comcast's system was so damn large and IP hungry that they ran out of space in net10 and had to start using public IPv4 addresses for internal management.

So while most non-botique access providers were probablly thinking "meh, when the IPv4 crises hits we can keep going almost indefinitely with CGN, lets let someone else be the early adopter of IPv6" comcast didn't have that buffer. They faced a stark choice between stopping expansion of services, federating their network**, or adopting IPv6. They chose IPv6.

That is why comcast is so ahead of the game on IPv6.

* http://meetings.ripe.net/ripe-...
** That is splitting it into multiple sections to allow IP reuse and redesigning their management systems to cope with it.

Replying to the guys that said it is illegal to sell: not only is it legal, but several of the internet registries put up their own marketplace for trading IP address space.

Here is a list of RIPE approved brokers: https://www.ripe.net/manage-ip...

A list of companies still holding an entire /8 block, culled from the Wikipedia article List of assigned /8 IPv4 address blocks and verified against https://www.arin.net/ and https://apps.db.ripe.net/searc... on 7/2/2015:

3 - General Electric
4 - Level 3*
8 - Level 3*
9 - IBM (partially *)
12 - AT&T Services*
15 - Hewlett-Packard
16 - Hewlett-Packard (inherited from Digital Equipment Corporation via Compaq)
17 - Apple
18 - MIT**
19 - Ford
20 - Computer Sciences Corporation
32 - AT&T*
34 - Halliburton
38 - PSINet*
44 - Amateur Radio Digital Communications***
48 - Prudential Securities
53 - Daimler AG (via RIPE)

This list does not include military, postal, or other government entities.

* Network service provider

** Educational institution

** Special-use, mostly unreachable, see Wikipedia's article on AMPRNet for details

More than 1B credentials does not sound implausible to me, though it's on the high end. You may be wondering why my opinion on this is more relevant than anyone else's, so let me explain.

Although I left the company in January, for about 7.5 years I worked at Google and for ~3 of those years I worked on security and anti-spam related matters. Starting around April 2010 we started to see absolutely enormous numbers of compromised accounts sending spam to their contacts. This was not a problem that grew slowly. It went from zero to one gang compromising on the order of 100,000 accounts per day and that happened in the space of, it seemed, a few weeks. We learned about this problem through user complaints and by watching the flow of spam mails being reported to us via the "Report spam" button. We quickly realised this wasn't a Gmail specific problem but was simultaneously impacting Hotmail and Yahoo. Further investigation revealed that although this gang was capable of compromising ~100,000 accounts per day (more than one per second) this was the result of a 10-15% success rate for more like a million attempts per day: most account/password pairs they tried did not work. The reason was they were reversing password hashes stolen from third party websites using GPUs, and it turns out that people who use the same password everywhere make up (surprisingly) only about 10-15% of the user population. People suck less at security than you might imagine.

When this problem first started we believed that such an enormous supply of credentials must surely be some kind of freak one off, the result of compromising an unusually large site. I mean; one million credentials every fucking day was an unimaginably vast pool of stolen passwords. But as the user complaints of being hacked failed to dry up we came to accept the horrible truth - this was not some freak one off but the result of some kind of production line of passwords. Most likely a combination of automated web crawls to discover vulnerable sites, semi-automated popping of those sites, farms of GPUs reversing the passwords and the resulting packages being sold on the black market to spammers who then abused them for bypassing spam filters (mail from contacts is whitelisted by any good spam filter). We only got occasional snapshots of this market, for example we were able to find adverts on Russian blackhat forums by people advertising lists of "washed" vs "unwashed" account/password lists for hotmail, gmail etc, but mostly it was opaque.

Anyway, long story short, we formed a team that built a full blown risk analysis system for every single login (Google has a bajillion logins per second thanks to mail clients that poll Gmail and have to log in each time) and after several years of work managed to block logins with bulk-stolen passwords so successfully that they went away. But the underlying supply of passwords is still out there, and should those defences fall the problem would come back.

I gave a talk about this and various other webmail abuse related topics at the RIPE 64 conference in Ljubljana (video link) in case anyone is interested in this. The slides are also available though lots of info from the talk is missing from them.

More than 1B credentials does not sound implausible to me, though it's on the high end. You may be wondering why my opinion on this is more relevant than anyone else's, so let me explain.

Although I left the company in January, for about 7.5 years I worked at Google and for ~3 of those years I worked on security and anti-spam related matters. Starting around April 2010 we started to see absolutely enormous numbers of compromised accounts sending spam to their contacts. This was not a problem that grew slowly. It went from zero to one gang compromising on the order of 100,000 accounts per day and that happened in the space of, it seemed, a few weeks. We learned about this problem through user complaints and by watching the flow of spam mails being reported to us via the "Report spam" button. We quickly realised this wasn't a Gmail specific problem but was simultaneously impacting Hotmail and Yahoo. Further investigation revealed that although this gang was capable of compromising ~100,000 accounts per day (more than one per second) this was the result of a 10-15% success rate for more like a million attempts per day: most account/password pairs they tried did not work. The reason was they were reversing password hashes stolen from third party websites using GPUs, and it turns out that people who use the same password everywhere make up (surprisingly) only about 10-15% of the user population. People suck less at security than you might imagine.

When this problem first started we believed that such an enormous supply of credentials must surely be some kind of freak one off, the result of compromising an unusually large site. I mean; one million credentials every fucking day was an unimaginably vast pool of stolen passwords. But as the user complaints of being hacked failed to dry up we came to accept the horrible truth - this was not some freak one off but the result of some kind of production line of passwords. Most likely a combination of automated web crawls to discover vulnerable sites, semi-automated popping of those sites, farms of GPUs reversing the passwords and the resulting packages being sold on the black market to spammers who then abused them for bypassing spam filters (mail from contacts is whitelisted by any good spam filter). We only got occasional snapshots of this market, for example we were able to find adverts on Russian blackhat forums by people advertising lists of "washed" vs "unwashed" account/password lists for hotmail, gmail etc, but mostly it was opaque.

Anyway, long story short, we formed a team that built a full blown risk analysis system for every single login (Google has a bajillion logins per second thanks to mail clients that poll Gmail and have to log in each time) and after several years of work managed to block logins with bulk-stolen passwords so successfully that they went away. But the underlying supply of passwords is still out there, and should those defences fall the problem would come back.

I gave a talk about this and various other webmail abuse related topics at the RIPE 64 conference in Ljubljana (video link) in case anyone is interested in this. The slides are also available though lots of info from the talk is missing from them.

For Europe at least, you can get RIPE IP blocks from their web site or through their RIPEstat Text Service. I use it for one of my servers to get daily lists for one country, and feed it to ipset. Maybe others like ARIN etc. also publish lists? Or you can get GeoIP databases. Or you could try a (Perl) module like IP::Country?

Actually it does exist: https://www.ripe.net/lir-servi... Wikipedia article is outdated.

Global RPKI deployment stats can be found here; Europe is doing pretty well, growing at a healthy pace: http://certification-stats.rip... As far as router support goes, Cisco and Juniper are doing a good job with support across the platforms: https://www.ripe.net/lir-servi... But with other vendors, RPKI support is pretty much non-existent. Though it's not a requirements to use RPKI data natively on the router, you can also just use validated ROAs from an API, for example: http://localcert.ripe.net:8088...

Global RPKI deployment stats can be found here; Europe is doing pretty well, growing at a healthy pace: http://certification-stats.rip... As far as router support goes, Cisco and Juniper are doing a good job with support across the platforms: https://www.ripe.net/lir-servi... But with other vendors, RPKI support is pretty much non-existent. Though it's not a requirements to use RPKI data natively on the router, you can also just use validated ROAs from an API, for example: http://localcert.ripe.net:8088...

Global RPKI deployment stats can be found here; Europe is doing pretty well, growing at a healthy pace: http://certification-stats.rip... As far as router support goes, Cisco and Juniper are doing a good job with support across the platforms: https://www.ripe.net/lir-servi... But with other vendors, RPKI support is pretty much non-existent. Though it's not a requirements to use RPKI data natively on the router, you can also just use validated ROAs from an API, for example: http://localcert.ripe.net:8088...

As seen at the abuse workgroup of RIPE (and I have not seen a sane discussion):

>> This is the draft agenda for the RIPE 66 meeting...
> No agenda item about defining (or refining the definition of) "abuse"?
Nope.

> I'd like to just reiterate my view that all other activities of this WG
> will be utterly fruitless until such time as a reasonable, rational, and
> generally accepted definition of "abuse" is in hand.

I genuinely don't think it will be useful to spend time on this.../snip

http://meetings.ripe.net/ripe-55/presentations/bush-ipv6-transition.pdf

It's a presentation I keep coming back to again and again (every single time somebody asks me "why don't people deploy more IPv6?").

Yes, the font and colors used will make your eyes water (I really wonder if he actually chose them that way on purpose :) ). But the actual content is just as accurate now as it was in 2007, and it comes from someone who actually has quite a bit of experience working with this stuff...

The request has already been sent out by some lobby group:

RIPE NCC Receives Communication from United Against Nuclear Iran (UANI)

I think this should have been reported some more, as it can have very serious consequences.

You mean something like this?

RIPE NCC Receives Communication from United Against Nuclear Iran (UANI)

Business of buying and selling of IPv4-addresses, you mean ?:

http://addrex.net/ http://tradeipv4.com/ http://www.ipaddressbroker.net/

But all it will do is slow down adoption:

http://it.slashdot.org/story/12/07/18/1852243/sale-of-ipv4-addresses-hindering-ipv6-adoption

https://ripe64.ripe.net/archives/video/28/ https://ripe64.ripe.net/presentations/24-2012-04-16-internet-futures-a.pdf

I was merely joshing. I agree with you, extending availability of ipv4 in any way will slow down ipv6 and is (in my opinion) therefore bad.

Business of buying and selling of IPv4-addresses, you mean ?:

http://addrex.net/ http://tradeipv4.com/ http://www.ipaddressbroker.net/

But all it will do is slow down adoption:

http://it.slashdot.org/story/12/07/18/1852243/sale-of-ipv4-addresses-hindering-ipv6-adoption

https://ripe64.ripe.net/archives/video/28/ https://ripe64.ripe.net/presentations/24-2012-04-16-internet-futures-a.pdf

I was merely joshing. I agree with you, extending availability of ipv4 in any way will slow down ipv6 and is (in my opinion) therefore bad.

Business of buying and selling of IPv4-addresses, you mean ?:

http://addrex.net/
http://tradeipv4.com/
http://www.ipaddressbroker.net/

But all it will do is slow down adoption:

http://it.slashdot.org/story/12/07/18/1852243/sale-of-ipv4-addresses-hindering-ipv6-adoption

https://ripe64.ripe.net/archives/video/28/
https://ripe64.ripe.net/presentations/24-2012-04-16-internet-futures-a.pdf

Business of buying and selling of IPv4-addresses, you mean ?:

http://addrex.net/
http://tradeipv4.com/
http://www.ipaddressbroker.net/

But all it will do is slow down adoption:

http://it.slashdot.org/story/12/07/18/1852243/sale-of-ipv4-addresses-hindering-ipv6-adoption

https://ripe64.ripe.net/archives/video/28/
https://ripe64.ripe.net/presentations/24-2012-04-16-internet-futures-a.pdf

The biggest barrier to my deployment of IPv6 is the edge switches and the wireless controllers. Support for first-hop security features for IPv6 is going to have to wait until we get around to paying for some rather substantial hardware upgrades, and IPv6 by itself does not justify that cost. Even if we had the money now, the actual feature sets are still not mature in the wired edge switches yet. In a competently secured campus network one does not allow old ARP/IP spoofing tricks to work, and doing so relies on the switch hardware and the wireless platform which must integrate with the DHCP servers by snooping traffic and using it to build port level access lists. IPv6 has analogous tricks that also need to be sqashed at the switchport/AP level, and while self-service address autoconfiguration seemed like a good idea to the IPv6 standards community they just don't cut it in a security-aware environment, so this support must include DHCPv6 snooping, which is still rare to find in switch feature sets these days. These are the features campus administrators will block on.

I sit next to the team that handles bulk account signups at Google. We are quite familiar with sellers like xgcmedia, buyaccs, vebxperts etc. As pointed out by others, Gmail accounts are significantly more expensive than other types of account. The reason is that we are very good at catching bulk attempts and requiring phone verification. This doesn't stop all bulk signup, but it does mean you have to buy a lot of SIM cards and swap them in/out all day, which is a lot of manual effort. Most of these guys are running account sweatshops in places like Pakistan or Bangladesh and just use a lot of manual labour.

The massive price difference means that bulk spam from @gmail.com is not a big problem like it used to be. Small amounts still go out occasionally, but it's rare. I gave a public talk on the topic of account abuse at Google back in April.

I actually expected Czech Republic to do well, I know the ISPs there worked hard on it. I didn't know about Romania. Anyway...

Maybe they have very little ISPs in comparison, but even the Vatican City State has 2 ISP networks.

Here is the list of ISPs in Romania:

https://www.ripe.net/membership/indices/RO.html

Romania has 37 IPv6 "prefixes":

http://bgpmon.net/weathermap.php?inet=6&focus=eu

I saw ROVER presented a couple weeks ago at an Internet conference (RIPE-64) and I hope any engineer that actually looks at the protocol realizes it's hacks upon hacks and doesn't solve anything.

It's really not worth a news article, so I'm just trying to warn anybody before they get their hopes up. I'll just leave you with the slides if you want to check for yourself:

https://ripe64.ripe.net/presentations/57-ROVER_RIPE_Apr_2012.pdf

I think the paragraph that says RPKI is complex and deployment has been slow is a lie, quite frankly. The five Regional Internet Registries (RIRs) have been heavily involved in the RPKI system, because they are the authoritative source on who the legitimate holder of a certain IP address block is. They launched a service to facilitate RPKI on January 1st, 2011 and adoption has been incredibly good for such a cutting edge technology (for example compared to IPv6 and DNSSEC). Since the launch, more than 1500 ISPs and large organizations world-wide have opted-in to the system and requested a resource certificate. The service that the RIRs offer, along with several open source packages by third parties for management, ensure that network operators only have to worry about entering data and not any of the crypto, making it robust and easy to use. With their certificate, an ISP can make a validatable claim – known as a Route Origin Authorisation (ROA) – about their prefixes, stating "As the holder of these IP prefixes, I authorize this Autonomous System to originate them". There are over 800 ROAs in the global system, describing more than 2000 prefixes ranging from /24s to /10s, totaling to almost 80 million IPv4 addresses. All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better. Global deployment statistics can be found here: http://certification-stats.ripe.net/

Yes, no serious web mail service can be compromised by brute force attacks and that is not what happened here.

Almost certainly, the password in question has been re-used at some other third party website that then got hacked, its password database dumped and the hashes reversed using video cards.

I work on account security at Google and have spent the last 2.5 years of my life on Gmail anti-hacking. So I'm all too familiar with this type of problem, where spammers mail your contacts with a link to their online stores (or malware). Really feel for the Hotmail team here - it's a hard problem to solve. That said, we've made a lot of progress over time. We've blocked very large numbers of logins to compromised accounts (often between half a million to a million accounts per week). There are still occasional campaigns that get past us but it's getting rarer all the time. It may well be that this guys password was the same on Gmail (ie, he had one password for everything), and there was an attempt made against his account, but we redirected it to the identity verification quiz and thus it was blocked. It wouldn't be remarkable if so.

I did a public talk at RIPE64 on the topic of signup and login security at Google, for those who are interested. It's about 30 minutes long.

IANA, the top level of organizations which handle the allocation of IP addresses, has run out of IPv4 addresses more than a year ago: http://www.youtube.com/watch?v=orJpEJuZick

The regional registries still have addresses and are going through them at different rates, so they'll run out at different points in the future.

RIPE (Europe) is down to about 40 million addresses, including the last 16 million which will be assigned under a different, more stringent policy: http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph

APNIC (Asia) is already on the last /8 block: http://www.apnic.net/community/ipv4-exhaustion/graphical-information

ARIN (North America): http://www.compusophia.com/en/ipaddrstat/ipv4_arin_pool.html

LACNIC (South America): http://www.lacnic.net/en/registro/espacio-disponible-ipv4.html

AfriNIC (Africa):
http://www.compusophia.com/en/ipaddrstat/ipv4_afrinic_pool.html

When those are depleted, it's going to be NAT all the way down.

For example, with IPv6, there isn't really provider independent address space.

Uh.

Yes there is. See for example this and this/this.

For example, with IPv6, there isn't really provider independent address space.

Uh.

Yes there is. See for example this and this/this.

I thought there was an announcement that the IPv4 address space is now totally exhausted. Or at least there are no new blocks to be assigned. The tunnel broker, Hurricane Electric indicates that IPv4 is exahusted.

The original such announcement came from APNIC I think a year ago, when they indicated that they were out of IPv4 address assignments to their ISPs. More recently, they changed their transfer policy so that even if 2 organizations want to undergo a transfer of IPv4 addresses from one to the other, the recipient has to justify their requirement for IPv4. In short, getting IPv4 is getting more difficult in this region.

ARIN so far seems to have pretty much the same policy that it had months ago - nothing has changed, even if Comcast and HE are indicating that they are out of IPv4 addresses. RIPE will be distributing /22s, while AfriNIC was supposed to have run out by August 11 but their status is unclear and not current. LACNIC too seems to be @ an end of its allocations.

Given all that, there is no reason why any ISP shouldn't start forcing the move to IPv6, since that's the only place where all the addresses really are.

Although it's probably too late to get this comment prominent - just this month a US judge ordered IPv4 assets frozen.

And the Dutch police happily sent a police order to the RIPE NCC, the registry in charge of internet numbers in Europe, which immediately followed it.

They will probably just block entire /56 since this is the kind of assignment a customer can get. See here: ripe ncc ipv6 training material, page 8.

The funny thing is that the hotmails of the world do not have a AAAA records for their mail servers. That means no ipv6 spam server can reach them.

While there is such a thing as a "legitimate trading and auction sites,"

While I'm not aware of any auction sites, I do believe it is possible to do trading in Asia/Pacific region:

"APNIC transfer, merger, acquisition, and takeover policy"

http://www.apnic.net/policy/transfer-policy

Which came from this:

"prop-050: IPv4 address transfers"

"Current status Implemented on 10 February 2010"

http://www.apnic.net/policy/proposals/prop-050

And I know there is a proposal for doing simialir things in Europe:

"Post-depletion IPv4 address recycling"

"Current Phase:
Concluding Phase: Awaiting Decision from Working Group Chairs"

http://www.ripe.net/ripe/policies/proposals/2011-03

4b10 is allocated to RIPE - see here

Yes it is allocated to RIPE as part of the much larger block 2001:4A00::/23.

So RIPE apparently gave BBC 2001:4b10:bbc::/48

I see no evidence to back up this claim, whois clearly states that 2001:4b10::/32 is allocated to bogons limited. The allocation below that is not registered in whois but it seems most likely that bogons limited gave the BBC 2001:4b10:bbc::/48

In that case, RIPE would have given bogons 2001:4b10::/32, and bogons in turn would have given BBC 2001:4b10:bbc::/48. In other words, it's hierarchical - IANA gives 2nd 2 bytes to RIPE, who then gives the next 2 bytes to BBC. Maybe the whois tables have not been updated?

But this time, the IETF is pretty conservative about how it's distributed the addresses

I've heard the opposite, for example free.fr got a /26 (64 times larger than the default ISP allocation of a /32) to support the highly address space inefficiant technology (at least in the form free deployed it in) known as 6rd.

http://ripe58.ripe.net/content/presentations/ipv6-free.pdf

What I meant above was that only 2000::/3 has been given to the IANA, and everything else has been reserved. In other words, IANA can't touch 4000::, 6000::, 8000::, until the IETF releases it.

only 2001::/16 has been given to the IANA so far [iana.org]

BS that page has no mention of 2001::/16 and indeed your first link already shows allocations to the RIRs outside that range.

Yeah, should have said 2000::/3.

since every organization will need only one /48 global routing prefix

/48 may seem like a lot but assuming standard sized subnets (nessacery for stateless autoconfiguration to work) it's only 65536 subnets, I could easilly see a large organisation exceeding that.

How? I'm thinking of some really large organizations, such as the government of China, or the UN, or the EU or the US government. Do you see them requiring 65536 routable networks, when any single network can house 18 quadrillion members?

I did think that instead of just 2 bytes for the subnets, they could have used 4, and that would have allowed for 4.3 billion networks - about as many unique v4 addresses. But that seems to me like a bit of overkill.

4b10 is allocated to RIPE - see here

Yes it is allocated to RIPE as part of the much larger block 2001:4A00::/23.

So RIPE apparently gave BBC 2001:4b10:bbc::/48

I see no evidence to back up this claim, whois clearly states that 2001:4b10::/32 is allocated to bogons limited. The allocation below that is not registered in whois but it seems most likely that bogons limited gave the BBC 2001:4b10:bbc::/48

But this time, the IETF is pretty conservative about how it's distributed the addresses

I've heard the opposite, for example free.fr got a /26 (64 times larger than the default ISP allocation of a /32) to support the highly address space inefficiant technology (at least in the form free deployed it in) known as 6rd.

http://ripe58.ripe.net/content/presentations/ipv6-free.pdf

only 2001::/16 has been given to the IANA so far [iana.org]

BS that page has no mention of 2001::/16 and indeed your first link already shows allocations to the RIRs outside that range.

since every organization will need only one /48 global routing prefix

/48 may seem like a lot but assuming standard sized subnets (nessacery for stateless autoconfiguration to work) it's only 65536 subnets, I could easilly see a large organisation exceeding that.

ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt

2001:4b10 is allocated to a company named Bogons Ltd, a UK based ISP. BBC is NOT owner of 2001:4b10:bbc::/48. There is no entry for that subnet in the whois database.

Curiously BBC _does_ have an allocation from RIPE. But it is 2001:41c0::/32.

% Information related to '2001:41c0::/32'

inet6num: 2001:41c0::/32
netname: UK-BBC-20041108
descr: British Broadcasting Corporation
country: GB ...
 

The object of the exercise is to discover the endpoints where failover does not properly occur and get them fixed.

If you'd prefer to avoid a nasty surprise on the day, there are ways to test in advance.

The test is aimed squarely at you.

What stops the large content providers from serving over IPv6 right now today is a level of brokenness that affects a fraction of a percent of users. These are computers or networks which are nominally IPv4 only, but have some misconfigured IPv6 setup that is actively causing problems connecting to sites. The proportion of users is tiny, but if you're facebook, that's still a lot of users. Wednesday next will expose these problems on a temporary, scheduled basis.

If you run IT support for an organisation, it would be wise to see the results of, say, the RIPE IPv6 eye chart on your client machines.

Their AS number looks legit. RIPE NCC shows that AS 50066 belongs to a company by that name.

http://www.db.ripe.net/whois?form_type=simple&full_query_string=&searchtext=AS50066&do_search=Search

I'm sure, because I use the IRRToolset extensively and understand that if you have a web of interconnecting servers that deliver the information, you do not NEED to access data in layers that are out of scope. As for seeing a peer's MAC address, that's trivial. Yes you can see it, it's the last 48 bits of any automatic IPv6 address generated using the RADV (Router Advertisment) method. This is how you can move IPv6 devices from network to network, retain your connection through auto-forwarding (since the upper bits identify your current network and are distinct from the lower bits used to identify the machine) and be guaranteed that there will be no address collisions. Ever.

Oh, you mean by IPv4? God, how quaint. I switched over about 17 or 18 years ago.

ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz

I also make good use of this little link. RIPE makes it easy to know who is supposed to be where and how they are supposed to be connected. By being a central source, I can know what should be expected at any given location and can compare that with the reality. (Reality is a term you may not be familiar with, but you can google for it in your own time.)

RIPE uses the same method for its consistency check system, comparing what networks are reporting with what their own authoratitive database says they should be reporting.

You got any arguments with RIPE?

Links to other software dealing with the Internet Routing Registry system (some are also given elsewhere):

IRR Toolset: http://www.isc.org/software/irrtoolset
IRRd: http://www.irrd.net/
Routing Registry Consistency Check (a web form, not the source code - pity): http://www.ripe.net/data-tools/projects/current/rrcc

If you want to use this system to construct your own WHOIS database, please see:

ftp://ftp.ripe.net/ripe/dbase/software/

(This is the WHOIS server used by RIPE.)

Links to other software dealing with the Internet Routing Registry system (some are also given elsewhere):

IRR Toolset: http://www.isc.org/software/irrtoolset
IRRd: http://www.irrd.net/
Routing Registry Consistency Check (a web form, not the source code - pity): http://www.ripe.net/data-tools/projects/current/rrcc

If you want to use this system to construct your own WHOIS database, please see:

ftp://ftp.ripe.net/ripe/dbase/software/

(This is the WHOIS server used by RIPE.)

Very thorough survey here.

http://stat.ripe.net/egypt

Agreed, multihoming will add to the routing table size. However, if you look at the RIPE policy for IPv6 PI space ( http://www.ripe.net/ripe/policies/proposals/2006-01.html ) you'll see that a business will get at least a /48. With 64K networks that will suffice for most. And the big multinationals that do require more will have no problem getting it, in a single prefix. So it stays with about one prefix per business (and in a filterable range for non transit systems too) which means less fragmentation. So I don't agree that the bigger address space will lead to more routes. Only more multihoming organisations will lead to more routes. If anything, the larger address space allows to aggregate better because there is less need to utilize every bit of the space. On the other hand I suspect fragmentation of IPv4 will increase dramatically after the RIR's run out. Because large prefixes will be cut up in smaller ones and sold/transferred to other parties. No, that's not allowed now but I bet it will be after the RIR's run out.

http://www.ripe.net/rs/ipv4/subnets.html

Comcast is well past the "limited trial" phase. They are doing limited trials for their users, but they have been deploying it for their management of the cable modems and their backbone for years.

Last time the Pakistani government told Pakistani ISPs to block YouTube they ended up hijacking their IP prefix for pretty much the entire Internet.

When I wanted static IPs for my cable connection I asked my cable ISP. They said sure, $5/month/each.

If that is for ADDITIONAL IPs, that would be somewhat logical. If it is for the firs IP, then it is not. Cable modems connections are NOT the same as PSTN connections. Cable (and ADSL) will be likely to be connected all the time.

This means that the provider needs at least the amount of IPs as it has customers. This means to have a fixed IP or a Dynamic IP does not make any difference in the number of IPs needed. Providers however use the excuse that IP adresses are rare as an excuse to charge more money from it. There are even providers that force a different IP on you after a certain time.

But even then there is the question of charging for something that they themselves do not need to pay for. In Belgium the average price for a fixed IP is about 50EUR. The provider pays a fixed price for all his IPs. http://www.ripe.net/info/faq/membership/newlir-billing.html and http://www.ripe.net/membership/billing/procedure.html

In that last URL you see that a provider will pay 5.000EUR for its IPs. And as you can see almost all are in that group. I would say that 5.000EUR is more operational cost then a real cost. It also is a fixed cost. So charging 50EUR for an IP address is a bit of black market to me.

When I wanted static IPs for my cable connection I asked my cable ISP. They said sure, $5/month/each.

If that is for ADDITIONAL IPs, that would be somewhat logical. If it is for the firs IP, then it is not. Cable modems connections are NOT the same as PSTN connections. Cable (and ADSL) will be likely to be connected all the time.

This means that the provider needs at least the amount of IPs as it has customers. This means to have a fixed IP or a Dynamic IP does not make any difference in the number of IPs needed. Providers however use the excuse that IP adresses are rare as an excuse to charge more money from it. There are even providers that force a different IP on you after a certain time.

But even then there is the question of charging for something that they themselves do not need to pay for. In Belgium the average price for a fixed IP is about 50EUR. The provider pays a fixed price for all his IPs. http://www.ripe.net/info/faq/membership/newlir-billing.html and http://www.ripe.net/membership/billing/procedure.html

In that last URL you see that a provider will pay 5.000EUR for its IPs. And as you can see almost all are in that group. I would say that 5.000EUR is more operational cost then a real cost. It also is a fixed cost. So charging 50EUR for an IP address is a bit of black market to me.