Slashdot Mirror

The article refers to IANA, but I think it means ICANN.

The article's author apparently did not read IANA's About page, which states what every Internet geek already knows:

IANA executes policy; it does not create policy. Policy-making is left to working groups within ICANN and elsewhere.

The article refers to IANA, but I think it means ICANN.

The article's author apparently did not read IANA's About page, which states what every Internet geek already knows:

IANA executes policy; it does not create policy. Policy-making is left to working groups within ICANN and elsewhere.

Also, for the near future at least, most IPv6 addresses will have "2001" as their first 16 bit prefix

False. Off the top of my head, I've seen at least 2001, 2a01, and 2620.

For reference:
http://www.iana.org/assignments/ipv6-unicast-address-assignments

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml is a bit easier to parse mechanically. There were 9 /8 allocations to RIRs in 2008. Not 12-14. 2007 was 13 allocations. 2006: 10. 2005: 11. 2004: 9. 2003: 5. 2002: 4. 2001: 7. So far in 2009: 4.

So, yeah, 12-14 is hyperbole. Not by so much as to fundamentally change the point, which is, it would take more effort to convince those holders of a precious and dwindling resource that they should just give it up out of the goodness of their steel-and-concrete hearts, than you could justify by the amount of time you'd gain. Spend that time and money on IPv6 promotion and education, instead.

Go ahead, yank 'em all back. Worldwide, the five RIRs (AfriNIC, ARIN, APNIC, LACNIC, RIPE) go through 12-14 /8s per year. Don't give yourself a charley-horse patting yourself on the back because you managed to move out the exhaustion date by 8 months.

[citation needed]

Actually, the citation should point to IANA's master list, but that disproves your statement, not supports it.

There are a number of corporations and organizations that own /8's

Here is a list

Here's a few from the list:

016/8 Digital Equipment Corporation

Must be an old list. DEC was purchased by Compaq a decade ago. Compaq has since been purchased by HP.

There are a number of corporations and organizations that own /8's

Here is a list

Here's a few from the list:

003/8 General Electric Company
004/8 Level 3 Communications, Inc.
008/8 Level 3 Communications, Inc.
012/8 AT&T Bell Laboratories
013/8 Xerox Corporation
015/8 Hewlett-Packard Company
016/8 Digital Equipment Corporation
017/8 Apple Computer Inc.
019/8 Ford Motor Company
034/8 Halliburton Company

Seriously... why does Ford Motor company need a /8?

The US government also owns a whole bunch of /8's

Instead of hogging these, they should just give them up. They don't need all these addresses.

Use SSH keys in addition to passwords. Disable ssh root logins. Use the AllowUsers command in sshd_config to restrict what accounts can log in with ssh. Edit /etc/hosts.deny and add IP ranges for where you are unlikely to login from. Use iptables rules to block people who are hammering your ssh server from the same address. Use tools like Fail2ban and DenyHosts to block other abusers and share abuser information with other victims.

To quote myself from a post I made on another site:

According to IANA, of the 256 /8 IPv4 blocks, there are 31 Unallocated blocks and 16 Reserved for Future Use. Those 47 blocks means that approximately 18.36% of the IPv4 space is currently sitting empty. That's not even counting the the 16 /8 blocks reserved for Multicast, the 127/8 block reserved for a single IP (127.0.0.1), or counting any unallocated blocks in the CIDR networks.

Anyone who says we're running out of IPv4 addresses needs to go back and look at what is actually allocated and what isn't. Since nearly 20% of the IPv4 space is currently empty, I can't see how they can make the claim that we're running out of addresses with a straight face.

Thank you, jeaton. You have taught me a little more about the specs. To think that I'm a network admin, running a mail server (with a policy requiring port 465 but accepting 587) for a decently large company, and I didn't know that.

The funny thing is that MS Outlook doesn't know about 465 (when you push to SSL + authentication on outgoing mail, the port doesn't change from 25) whereas Mozilla Thunderbird changes the port to 465 automatically. Also, running grep 465 /etc/services in Debian returns "ssmtp" with alternate name "smtps" and description "SMTP over SSL" rather than your correctly cited official IANA "URL Rendesvous Directory for SSM," implying that at least Debian, FreeBSD, and others who maintain their own lists are also propagating this issue.

I had learned anecdotally (from the above sources and others) that 465 requires SSL (rather than STARTTLS, which makes it optional), and that it was therefore an easier way to require encryption in addition to authentication. Very interesting.

That said, I still find it unacceptable that most ISPs fail to offer SSL encryption for mail over HTTPS, POP3S/IMAPS, and Submission/SMTP/SMTPS.

Couldn't you just not do that? Why do the Feds have to roll out a $600k program because of you? That is taxpayers money for gods sake!

I wouldn't do it (I don't even have an AS to play with anymore), and it's rather more complicated than my explination made out...

I think a possible way to implement this would be a Hierarchical model where IANA has a top-level certificate for the trust and then it signs each regional NICs certificate, and they sign AS's which sign their subnets, then IANA could ask various NICs to revoke the Certificates of AS's that do dodgy things (like advertise subnets that aren't theirs), still it would require alot more overheads in terms of processing and memory than BGP currently requires.

I should also mention, I haven't worked with BGP in around 7 years now.

IPv6 may well not be the last protocol on the web, but it won't be for lack of addresses.

O RLY? 640k should be enough for anybody, right? (And no, Bill Gates never said that, I know.)

Let's consider e.g. all household items getting IP addresses, IP addresses used like EAN or ISBN... even without imagining billions of medical nanites with unique IP addresses one can guess that wasteful use of IP addresses (or assignment thereof) can exhaust the address pool pretty quickly. Just imagine what would happen if the IP6 address space were so mindboggingly stupidly partitioned as is the IP4 address space. Given that everybody seems to think IP6 addresses are "infinite", that's actually quite a probability.

Just FYI: The IANA is the Internet Assigned Numbers Authority, which maintains the IP address allotments and can be found at http://www.iana.org/ .

There's a fuller list here. Whole blocks are unallocated, held by IANA. I know that, in the case of Compaq, it didn't have its own range originally, but acquired 16.x.x.x with DEC. That was absorbed by HP (15.x.x.x) and is still used internally.

Everything on public IPs?

According to the IANA*, 19.0.0.0/8 is allocated to Ford. If my calculations are correct, which they rarely are, Ford has a total of 16,777,214 available addresses. This also applied to anybody else who uses a Class A /8 subnet. I don't see any reason for a company to need that many, of course I'm just using Ford as an example, there's many others including Halliburton, AT&T, Level 3, Xerox, etc.

* http://www.iana.org/assignments/ipv4-address-space/

See http://www.iana.org/assignments/ipv4-address-space/

019/8 Ford Motor Company 1995-05 LEGACY
marvin@tribble:~$ host www.ford.com
www.ford.com is an alias for
www.ford.com.edgesuite.net.
www.ford.com.edgesuite.net is an alias for a1200.g.akamai.net.
a1200.g.akamai.net has address 96.17.109.74
a1200.g.akamai.net has address 96.17.109.18

013/8 Xerox Corporation 1991-09 LEGACY
marvin@tribble:~$ host www.xerox.com
www.xerox.com is an alias for www.xerox.com.edgekey.net.
www.xerox.com.edgekey.net is an alias for
e82.c.akamaiedge.net.
e82.c.akamaiedge.net has address 72.246.128.108

009/8 IBM 1992-08 LEGACY
marvin@tribble:~$ host www.ibm.com
www.ibm.com is an alias for www.ibm.com.cs186.net.
www.ibm.com.cs186.net has address 129.42.58.216

003/8 General Electric Company 1994-05 LEGACY
marvin@tribble:~$ host www.ge.com
www.ge.com has address 192.131.227.156

048/8 Prudential Securities Inc. 1995-05 LEGACY
marvin@tribble:~$ host www.prudential.com
www.prudential.com is an alias for web.prudential.com.
web.prudential.com has address 12.34.100.148

Apple (17) and HP (15) have their public website within their allocation. Eli Lil(l)y (40) appears also has their public website within their allocation, but I have a hard time believing that they could ever need that many public IP addresses.

So there... I just found an extra quarter million addresses. (5 x 2^16) Y'all can pay me by giving me my own /24.

Probably because Canada is not part of the US yet, eh?

I'm British, and as such, can't really hear a difference between Canada and the US. However, I am trying to learn, so I can continue to mock those North Americans who can't tell the difference between Australian and Scouse. So, whenever I hear a Canadian speaking, I try to look for things that distinguish. And I can't hear any. 'Specially not any 'eh' at the end of the sentence. Please advise.

uhh 172.18.0.0/16 falls under 172.16.0.0/12, which is the 1918 reserved network I guess you're referring to. then there are the class E addresses, the multicast addresses, and a multitude of /8s that haven't been allocated since the inception of the internet and may not be any time soon. you can find a list here. also, several /8s in between 1-10 are not reserved, and have been allocated ages ago. 4/16 notoriously belongs to bbn (now assimilated by level 3), 3/8 belongs to GE, 8 also belongs to Level 3, and 9 is owned by IBM.

your numbers on how many IP addresses have been wasted are way off as well. 10/8, for instance, wastes 2^24 - 2 or 256^3 - 2 or 16,777,214 addresses. the maximal decimal value per octet in an IPv4 address is 255, excepting the first octet, but we count from zero -- there are 256 values represented by eight bits. we subtract two for the network number and broadcast address which default in a classful system.

They are worth exactly zero dollars. HP does not own those IP addresses. HP was allocated the ability to use that IP address space.

Why can't some of the owners of /8 address spaces return them back to be re-allocated?

For example, HP owns 15.0.0.0 through 16.0.0.0 (~33m ip addresses) can't they get by on just ONE class A network?
Apple owns 17/8
MIT own 18/8
US Postal Service 56/8.
http://www.iana.org/assignments/ipv4-address-space/

Do all these companies need to have ALL of their devices on publicly routable IP addresses? From a security standpoint, I would hope not. Odd since IBM, a company much larger than MIT and Apple can get by on just one /8, and I'm having trouble believing that HP requires 2 /8 networks.

We talk about making our datacenters "green" by consuming less power, there's got to be an equivalent for consuming fewer public IP addresses.

I've just finished re-IPing our datacenter (~5000 servers), not to 'release IP addresses back, but to undo the damage done by years of seemingly randomly assigning IP addresses to servers in our datacenter. Yes it's a pain, but so is any form of cleaning up your datacenter (cabling for example).

From http://www.iana.org/assignments/ipv4-address-space/ I count 39 /8 blocks assigned to individual companies or organizations. That's purely wasteful, since it is highly unlikely that any of these companies actually need the 16 million or so addresses in those blocks. If those blocks were reallocated, which will likely occur if we reach "X-day" ( http://entne.jp/tool/toollist/index_en.html ) before IPv6 becomes widespread, we will have gained approximately 500 million IP addresses. That will probably be sufficient to buy us another two years, since we currently have about 566 million free and two years to go (again according to the IPv4 exhaustion counter).

So, we should have another four years if IANA pushes for reallocation of the /8 blocks by 2010.

It's still something of a virtual problem, and the biggest problem is usually that there are a few companies that has allocated large number of addresses for internal use - and they should be able to use NAT gateways (which I suspect they already do for security reasons).

It will of course be a big job for those companies to migrate addresses, but it will be worth it. A few companies that allocated those large series aren't even large enough to really be able to use them.

And many A address series aren't even used today:
IPv4 Global Unicast Address Assignments

So it's not really a critical problem yet.

I predict that we'll see China begin to use IPv6 addresses before most other people. Why?

• Extreme scarcity of IPv4 addresses: China gained internet access well after the era of enourmously wasteful address assignment ended.
• The great firewall is always set up as a traffic relay. Not only does it provide a natural point to set up an IPv6->IPv4 NAT gateway, but running IPv6 internally makes it that much more difficult for dissidents to bypass the firewall.
• China's strong central state would allow mandating of IPv6 and near-instantaneous implementation.
• Chinese sites are accessed by relatively few non-Chinese. Therefore, the penalty for running an IPv6-only site inside China would not be very great.

Granted, I'm no fan of China's human rights policies. But it definitely has an advantage in terms of adopting IPv6. Hopefully, when China switches protocols, it'll catalyze the rest of the world to do so as well.

I confess my geek-fu is not strong enough to understand what he does, can someone shed some light for the networksavvy-impared?

Well...

wget -o /dev/null -O - http://www.iana.org/assignments/ipv4-address-space/

He's asking IANA for the netblocks... (click the link to see what does get returned)

grep whois.apnic.net

administerd by APNIC (Asia-Pacific)

grep ALLOCATED

currently in use (not legacy ones)

cut -d " " -f 1

culling everything from each line except the IP/mask (the first item)

xargs

and strips the carriage returns to generate a list of IP blocks in the AP region.

# need to add in .0.0.0 though

Of course he has to manually add in the .0.0.0 for each block for the next to work

for asia in 58.0.0.0/8 59.0.0.0/8
do
$fw -A INPUT -s $asia -j DROP
done

He then sets up his firewall to instantly drop any packets coming from any of those IP blocks so he can't hear them.

It's a bit sledgehammer/nut IMO.

Sorry dude. I block whole netblocks that I/we don't have any business with, and that fill up my logs with annoying connection attempts, and portscans, etc. I'll show you my method for blocking about 80% of probes, scans, password guessing bots, etc:

# wget -o /dev/null -O - http://www.iana.org/assignments/ipv4-address-space/ | grep whois.apnic.net | grep ALLOCATED | cut -d " " -f 1 | xargs # need to add in .0.0.0 though for asia in 58.0.0.0/8 59.0.0.0/8 60.0.0.0/8 61.0.0.0/8 112.0.0.0/8 113.0.0.0/8 114.0.0.0/8 115.0.0.0/8 116.0.0.0/8 117.0.0.0/8 118.0.0.0/8 119.0.0.0/8 120.0.0.0/8 121.0.0.0/8 122.0.0.0/8 123.0.0.0/8 124.0.0.0/8 125.0.0.0/8 126.0.0.0/8 202.0.0.0/8 203.0.0.0/8 210.0.0.0/8 211.0.0.0/8 218.0.0.0/8 219.0.0.0/8 220.0.0.0/8 221.0.0.0/8 222.0.0.0/8 do $fw -A INPUT -s $asia -j DROP done

I don't get why you are getting annoyed that I (and probably many others) do things like this?

Your rule blocks most Australian IP addresses, for starters.

This wouldn't be possible in the switching system you advocate for.

Sure it would. The telnet protocol allows both ends to specify requirements, and results in a disconnect if the other end doesn't support it. (In fact, it appears to already support SSL, but I suspect that doesn't include certs.)

Granted, the client could lie, but that would be a protocol violation, and if we're considering those, nothing stops a client from spewing plaintext into a SSL connection either.

That said, the problem there is poorly designed protocols that allow one greeting unparsed message from the server and then the client instantly sends the login. This was yet another protocol stupidity, right up there without allowing switching to SSL via telnet negotiation. (Although if we'd used the latter, we wouldn't have worry about the former...telnet negotiation happens before any communications at all.)

SMTP, interestingly, doesn't have this problem, because SMTP wasn't designed with authentication in the first place. The server has to state the ability to login, via ESMTP options. IMAP, being a late designed protocol, doesn't have this problem either.

With both IMAP and SMTP, you connect, and get a message from the server, but that message has to state the various methods you are allowed to login.(Along with various other options.) The server can, in fact, state no login methods at all, and just present the 'I can switch to SSL' option. After the switch, it can present the login methods again.

Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.

I don't know what you mean by that. SSL negotiates itself quite well between different versions. A lot of SMTP traffic already magically switches itself to SSL. I myself have let my mail server switch to SSL (Well, TLS) on demand, and have had over 500 TLS connections the last two days. (Which is actually absurdly high for the amount of mail we get, so either spammers are using SSL or my grep failed.)

Although obviously, looking at it from that direction is stupid. Our mail server (postfix) also attempts to negotiate SSL connections for outgoing mail, and I've never seen mail bounce because it couldn't negotiate a connection.

Certificates change regularly for legitimate reasons. I see no reason to confuse users by alerting them when this happens.

Let me restate: Users should be alerted when an self-signed cert changes to another self-signed cert, or when a CA-signed cert changes to a self-signed cert.

Yes, what specific problem are you talking about? HTTP is for anything that doesn't require a secret (mod Digest auth); HTTPS is for everything else. What's the problem?

The problem is that negotiation happens before any other communications, so that clients cannot state what website they are actually connecting to, so the server cannot present the correct certificate for that web site. Which is why HTTPS sites need their own IP.

This actually would be a problem in other protocols, except no email client expect signed-by-the-email-domain in email SSL connections.

When I first read this news several days ago, I thought it was referring to the root servers ...

What most don't know is that the TLDs (ie. com, .net, etc) themselves are registered in much the same manner as 2nd level domains are ... see the TLD Whois: http://whois.iana.org/

The major TLDs (.com, .net, etc) are relatively safe, since any changes would likely be difficult to get through - with any changes quickly noticed ... as in within minutes, or even seconds; likely wouldn't even be that effective, since the most popular TLDs zone dns entries are heavily cached.

However, ccTLDs are a different story completely, since ccTLD zone name server changes are more common and thus such change requests would be far less scrutinized.

I've never heard of any TLD being hijacked, but could likely be easily done, since the social engineering involved would be very similar. A frightening prospect.

Ron

Hey IANNA, why not free up some of the "LEGACY" Class-A allocations (see below) That would free some 650 MILLION addresses!!! Some 15% of the address space.

http://www.iana.org/assignments/ipv4-address-space [iana.org].

That'll do us for what? Another 10-15 years or so? Plus if the US gov wants to release a bunch too since they are going IPv6.

This whole "OMG! We're going to run out of addresses (and ponies)" scare is starting to be more pathetic and fake than Nostradamus predictions!

Take a read of this blog post to find out what's really happening:

http://blog.icann.org/?p=271

They allocated more than one /8 per month in 2007, so even if they did recover all 650 million addresses from the allocations you mentioned (very unlikely), it would not buy us another 10-15 years. It would buy us about 3 years assuming the demand for IP addresses doesn't increase.

Reclaiming address space doesn't solve the problem, it just delays it. And it doesn't even delay it by that much.

Hey IANNA, why not free up some of the "LEGACY" Class-A allocations (see below) That would free some 650 MILLION addresses!!! Some 15% of the address space.

http://www.iana.org/assignments/ipv4-address-space [iana.org].

That'll do us for what? Another 10-15 years or so?
Plus if the US gov wants to release a bunch too since they are going IPv6.

This whole "OMG! We're going to run out of addresses (and ponies)" scare is starting to be more pathetic and fake than Nostradamus predictions!

003/8 General Electric Company
004/8 Level 3 Communications, Inc.
006/8 Army Information Systems Center
008/8 Level 3 Communications, Inc.
009/8 IBM
011/8 DoD Intel Information Systems
012/8 AT&T Bell Laboratories
013/8 Xerox Corporation
015/8 Hewlett-Packard Company
016/8 Digital Equipment Corporation
017/8 Apple Computer Inc.
018/8 MIT
019/8 Ford Motor Company
020/8 Computer Sciences Corporation
021/8 DDN-RVN
022/8 Defense Information Systems Agency
025/8 UK Ministry of Defence
026/8 Defense Information Systems Agency
028/8 DSI-North
029/8 Defense Information Systems Agency
030/8 Defense Information Systems Agency
032/8 AT&T Global Network Services
033/8 DLA Systems Automation Center
034/8 Halliburton Company
035/8 MERIT Computer Network
038/8 Performance Systems International
040/8 Eli Lily & Company
043/8 Japan Inet
044/8 Amateur Radio Digital Communications
045/8 Interop Show Network
047/8 Bell-Northern Research
048/8 Prudential Securities Inc.
051/8 Deparment of Social Security of UK
052/8 E.I. duPont de Nemours and Co., Inc.
053/8 Cap Debis CCS
054/8 Merck and Co., Inc.
055/8 DoD Network Information Center
056/8 US Postal Service
057/8 SITA

Adeptus

While ARINs web site indicates they were formed in December of 1997, IANA indicates that ARIN was delegated the 134/8 subnet in May of 1993.

IANA is responsible for global coordination the Internet Protocol addressing systems, as well as the Autonomous System Numbers used for routing Internet traffic.

RFC1466, section 4.2.1, states: Organizations applying for a Class B network number must submit an engineering plan that documents its need for a Class B network number. This document must demonstrate that it is unreasonable to engineer its network with a block of class C network numbers. The engineering plan must include how many hosts the network will have within the next 24 months and how many hosts per subnet within the next 24 months. I really doubt a marketing company could honestly come up with such a plan. In addition to this, RFC1466 has many other guidelines regarding allocation of IP addresses -- too many to mention here.

This Wired article says that Mr. Medin served at NASA until 1995. As such, policies enforced by the above mentioned RFCs were already in place, regardless of whether ARIN was conceived in 1993 or 1997. There's a good chance that the 134.17/16 network block was most likely still allocated to his research team up until 1995.

RFC1166, in its Introduction section, states: This Network Working Group Request for Comments documents the currently assigned network numbers and gateway autonomous systems. This RFC will be updated periodically, and in any case current information can be obtained from Hostmaster at the DDN Network Information Center (NIC). It looks like someone has forgotten about this RFC or it's been superseded by another RFC that I'm not aware of, as it has not been updated, as they still think that the IP block is still allocated to BAY-PR-NET. While it may still be allocated to "BAY-PR-NET", it's not the same BAY-PR-NET. There may also be a communication gap between IANA and ARIN, as ARIN is responsible for tracking network block transfers.

In summary, Trudy's shit is looking pretty weak.

While ARINs web site indicates they were formed in December of 1997, IANA indicates that ARIN was delegated the 134/8 subnet in May of 1993.

IANA is responsible for global coordination the Internet Protocol addressing systems, as well as the Autonomous System Numbers used for routing Internet traffic.

RFC1466, section 4.2.1, states: Organizations applying for a Class B network number must submit an engineering plan that documents its need for a Class B network number. This document must demonstrate that it is unreasonable to engineer its network with a block of class C network numbers. The engineering plan must include how many hosts the network will have within the next 24 months and how many hosts per subnet within the next 24 months. I really doubt a marketing company could honestly come up with such a plan. In addition to this, RFC1466 has many other guidelines regarding allocation of IP addresses -- too many to mention here.

This Wired article says that Mr. Medin served at NASA until 1995. As such, policies enforced by the above mentioned RFCs were already in place, regardless of whether ARIN was conceived in 1993 or 1997. There's a good chance that the 134.17/16 network block was most likely still allocated to his research team up until 1995.

RFC1166, in its Introduction section, states: This Network Working Group Request for Comments documents the currently assigned network numbers and gateway autonomous systems. This RFC will be updated periodically, and in any case current information can be obtained from Hostmaster at the DDN Network Information Center (NIC). It looks like someone has forgotten about this RFC or it's been superseded by another RFC that I'm not aware of, as it has not been updated, as they still think that the IP block is still allocated to BAY-PR-NET. While it may still be allocated to "BAY-PR-NET", it's not the same BAY-PR-NET. There may also be a communication gap between IANA and ARIN, as ARIN is responsible for tracking network block transfers.

In summary, Trudy's shit is looking pretty weak.

1. Each interpreter needs a partial or complete standard library.
   
2. Each interpreter needs to be sandboxed or have potentially dangerous functions modified or removed.
   
3. Each interpreter needs to have DOM support added to it.
   
4. Each browser needs a way of adding media types for supported scripting engines.
   
5. For that matter, each scripting engine needs an IANA assigned media type if it doesn't already have one. Java, Perl, PHP, Python, and Ruby are all missing from the application media type list.
   

That'll free up a bunch.

First of all, break up the "LEGACY" Class-A allocations. http://www.iana.org/assignments/ipv4-address-space. That'll free up a bunch.

All of the following companies have a full 16.7 Million addresses assigned to them. Level 3 might use theirs, (they actually have 2 blocks), but Halliburton? DEC? Amateur Radio Digital Communications? Do they all really need more than 16 million IP addresses?

This short list accounts for 654 million IP addresses -- over 15% of the address space.

003/8 General Electric Company
004/8 Level 3 Communications, Inc.
006/8 Army Information Systems Center
008/8 Level 3 Communications, Inc.
009/8 IBM
011/8 DoD Intel Information Systems
012/8 AT&T Bell Laboratories
013/8 Xerox Corporation
015/8 Hewlett-Packard Company
016/8 Digital Equipment Corporation
017/8 Apple Computer Inc.
018/8 MIT
019/8 Ford Motor Company
020/8 Computer Sciences Corporation
021/8 DDN-RVN
022/8 Defense Information Systems Agency
025/8 UK Ministry of Defence
026/8 Defense Information Systems Agency
028/8 DSI-North
029/8 Defense Information Systems Agency
030/8 Defense Information Systems Agency
032/8 AT&T Global Network Services
033/8 DLA Systems Automation Center
034/8 Halliburton Company
035/8 MERIT Computer Network
038/8 Performance Systems International
040/8 Eli Lily & Company
043/8 Japan Inet
044/8 Amateur Radio Digital Communications
045/8 Interop Show Network
047/8 Bell-Northern Research
048/8 Prudential Securities Inc.
051/8 Deparment of Social Security of UK
052/8 E.I. duPont de Nemours and Co., Inc.
053/8 Cap Debis CCS
054/8 Merck and Co., Inc.
055/8 DoD Network Information Center
056/8 US Postal Service
057/8 SITA

And we need to retrieve some from the Vatican as well!

Looking at the information here then the Vatican has far too many IPs per capita. Ditto for the other tiny nations of Gibralta and Monaco. I'm sure it'll buy us at least a week!

And for anyone geeky enough to care (who isn't geeky enough to have it bookmarked already) here is the assignment list. Each of the companies mentioned owns an entire top level block (e.g. Ford own 19.xxx.xxx.xxx) and some like the Defense Information Systems Agency (whoever they are) own multiple blocks! That's an awful lot of addresses.

Its sad to look at the list of class a allocations and know that we're almost out. All this was done before NATs became popular. I think ICANN/IANA should work on wrestling some of those class As back from companies like Ford, Apple, HP, etc. None of those companies are going to ever have 16,000,000 hosts on public IPs. I know some of those companies have already made sub allocations. We could probably buy 5-10 years if they could reclaim just the 3, 9, 13, 17, 19, 20, 34 and 40 class As and get over 130,000,000 IPs back.

I mean, if those companies complain, who cares. They wouldn't get such large and prestigious allocations in an IPv6 network anyways. So what's the difference.

I know, I know, we should move to IPv6 anyways. Just a suggestion. Poor initial planning warrants changes down the road.

A common mistake people make with IPv6 is considering it as only IPv4 with more bits for the address. That is not how the protocol was intended and it will not be used like that. The least significant 64 bits of an IPv6 address are meant only for hosts; the smallest possible subnet you can have in IPv6 consists of 2^64=1,8*10^19 IP addresses. It will never be practicle to have this many devices in a given network segment, in fact, from my experience it is not feasible to have much more than 1000 devices on a given subnet. This results in a great redundancy of the last 64 bits. The idea is that hosts can get a network prefix and then determine their own 64 bits (note that they are not obliged to use their EUI address (in other words the MAC address for most ethernet adapters) for determining the 64 bits). The IPv6 addresses do not replace arp, ICMPv6 does.

Currently, the only unicast IPv6 addresses that are publicly assigned are in the 2000::/3 range (http://www.iana.org/assignments/ipv6-unicast-address-assignments/) - so if you're gonna make jokes about obscure IPv6 addresses, please let them start by 2 or 3 (unless you're talking about multicast/link-local/site-local addresses in which case there are other ranges).

This whole root-servers-going-IPv6 news are not that big news though. More like a milestone on the way to IPv6. In any forseeable future v4 will be used along v6 - the world will probably have destroyed itself before IPv4 vanishes...

.aq

I use two ways:

1. Resources such as http://www.apnic.net/db/ranges.html and http://www.iana.org/assignments/ipv4-address-space

2. Build the list "manually" by checking originating IP addresses through the ARIN datatbase http://www.arin.net/whois/

Using the latter method, simply pasting the originating IP address (example, 116.24.118.9) into the search field yields that the address block 116.0.0.0 - 116.255.255.255 is admintrated by APNIC, and therefore "foreign" (to North America). So, simply block that entire range.

Other foreign registries include AFRINIC (Africa et al), LACNIC (Latin America), and RIPE (Europe).

Trust me, this kind of blocking really does work and is a viable tool for many North American mail servers--Karma be damned.

Check the IANA registry of TLS ciphersuites(http://www.iana.org/assignments/tls-p arameters). Those without "EDH" in their names aren't performing ephemeral diffie-hellman key negotiation.

The SSL and TLS specs allow multiple ways of deriving the master_secret, which is used to derive the symmetric keys. Quoting from RFC 4346 (http://www.ietf.org/rfc/rfc4346.txt), section 8:

8.1.1. RSA When RSA is used for server authentication and key exchange, a 48- byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret, as specified above. RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1. RSA public key encryption is performed using PKCS #1 block type 2. 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret.

If RSA keying is used, then there is no perfect forward secrecy. In English, that means that if an attacker can capture the TLS handshake and if the attacker can compromise the server's private key, then the attacker can decode any data from that session. If ephemeral Diffie-Hellman keying is used, this attack is not feasible, since the server's RSA keypair wasn't used to secure the key exchange (it would only have been used to authenticate the server's identity).

Also note that the client doesn't generate an asymmetric key pair (as you claimed), and that the key negotiation algorithm is independent of protection against replay attacks.

He lies and says we're running out of addresses at a rate of 10-15 /8's per year. ARIN says we're going through about 3-4 a year (see the ipv4-allocation-assignments- this stuff is public even to nonmembers

No, he's not lying. You made the mistake of only looking at ARIN's numbers, which show IP usage in the Americas. Try looking at IANA's numbers instead and you'll see that the allocation of ~10 /8's per year is about right. So far this year, RIPE (covering Europe) has gotten 4 new blocks and APNIC (covering Asia) has gotten 5.

When you say "the way addresses were distributed", you are ignoring the fact that there are millions of unused, un-distribued addresses free for the taking.

Internet Protocol v4 Address Space.

See all those blocks marked "IANA - Reserved"? Those are unused addresses. Any ISP in China can ask APNIC for more addresses, and APNIC will give them addresses. There is no shortage.

Believe it or not the USA, Germany, Japan, and France are not the leaders in this activity

Old News, Two of the better know:
China Titan Rain: http://en.wikipedia.org/wiki/Titan_Rain
US DARPA TIA: http://en.wikipedia.org/wiki/Total_information_awa reness

EU, Russia, Arabs, Israel, UN ... It is the new SOP for CoOp spycraft and cyberwar.
US ain't the only one on the block, globally they are all on pot calling the kettle black.
As I always say, "Reality is self induced hallucination." If you're a politician/idiot it ain't that FUBAR.

Wikipedia blocked the USA Congress IP address block, as to why ....
http://majikthise.typepad.com/majikthise_/2006/01/ wikipedia_block.html

Maybe some folks need to be blocking some top-level domains .cn/203+202..., .mil/199+207..., .gov/216+206+69+209+82+66... ....

IOW, consider the following:
US DOD NIC: 6.0.0.0 - 7.255.255.255
US DOD NIC: 11.0.0.0 - 11.255.255.255
US DOD NIC: 21.0.0.0 - 22.255.255.255
US DOD NIC: 26.0.0.0 - 26.255.255.255
US DOD NIC: 28.0.0.0 - 30.255.255.255
US DOD NIC: 33.0.0.0 - 33.255.255.255
US DOD NIC: 55.0.0.0 - 55.255.255.255
Halliburton Company 34.0.0.0 - 34.255.255.255
Computer Sciences Corporation 20.0.0.0 - 20.255.255.255
USPS: 56.0.0.0 - 56.255.255.255

You can do your own homework:
IANA: http://www.iana.org/
ARIN: http://www.arin.net/index.shtml

!HAVEFUN!

Get em while they're hot!

thegameiam,

NATing was a temp stop gap. Also, if you just look around, almost every home with broadband uses NAT, every company uses NAT and many companies have the operation hell of traffic being NATed multiple times throughout an Enterprise. So wide spread adoption of NAT already happened. NAT is not the answer. For a home user with a dinky network, it works. If you have a huge network with MILLIONS of endpoints, it just does not from an ROI perspective. Try tracing and capturing packets whose addresses change multiple times in both directions on a global network for an application that is not functioning and your company is losing money for every minutes (second) it is out.

Remember that there are billions of people with millions coming online in some form or fashion for the first time every year with many new companies springing up to serve them. A simple thing like an address gets important. The more private addressing you use, the less interoperable and supportable things become. Just something to think about as you play with the hair on your arm.

To the point of address exhaustion; here is a quote from an ARIN meeting last October 2006:

"....And then you see each of the RIRs, the amount of space that we currently have in /8s, ARIN having at this point the most IPv4 blocks from the IANA and, of course, the available space. It says the IANA reserved is right now 59 /8s. That number changed last week. There are now 55 /8s remaining. ARIN was issued four /8 blocks by the IANA last week, last Wednesday I think. So there really are 55 /8s remaining in the entire v4 space pool...."

http://www.arin.net/meetings/minutes/ARIN_XVIII/pp m1_transcript.html#anchor_4

I have seen estimates of practical allocatable address exhaustion in 2008 or 2009. Pretty darn soon! This does not mean the Internet or commerce will stop. Just new services and deployments will increasingly need to use IPv6 because there will not be IPv4 addresses for them.

Getting back to IPv6 in space.....it is good it is being tested now in space because it will certainly be used in the future. Also, I hope every router in space is Cisco, then they should work. :-)

Suggested links:
http://www.arin.net/
http://www.iana.org/ipaddress/ip-addresses.htm
http://www.arin.net/meetings/minutes/ARIN_XVIII/pp m.html

Best regards,

Andy

well, since you'd need to move off port 80, the solution is just use the trivial FTP protocol rather than http - heck, what more can you ask than anonymous, UDP packets and no security?

Here's a list of Assigned port numbers, since /etc/services doesn't usually have them all (the company I work for has assigned ports in the iana list, but not in /etc/services for my mac or linux boxes, for instance).

Hopefully before they start implementing this strategy, they will take the huge Class A addresses from those who don't necessarily need all of it:

MIT (I know they make use of public IPs, but 16 million addresses?)
Haliburton (!)
Bolt Beranek and Newman Inc (?)
Ford Motor Company ....

This website has an updated list. There are a lot more on the list who have waste space, I just don't feel like going through all of them.

Okay, so they've been dropping some ccTLDs, but IANA has Procedures for Establishing ccTLDs. So, when was the last time they created a new ccTLD?

June 2006

Okay, so they've been dropping some ccTLDs, but IANA has Procedures for Establishing ccTLDs. So, when was the last time they created a new ccTLD?

WTF? There's no way to ensure a TLD is valid other than whitelisting and a web app needs to catch user typos.

> So basically, every time a new TLD arrives, you have to update all your web apps?

A monthly cron job is a wonderful thing. I suppose in light of this article that the URL may return a 404 at some point. Then my deployed web apps would simply maintain the last version.