What if you have run something that updates the id3 tags, album art or volume levels as I expect most people do. I ran windows media player once ( by mistake ) and I think it wanted to do this by default? Any fiddling with any of the stuff in the header is going to change the hash of the file completely. I guess they could get more sophisticated and just hash the parts of the mp3 that aren't in the header. I'm sure you could get around that by just flipping the least significant bit somewhere in each track. Seems like prosocuting based on that would be getting into voodoo territory for the cops in my country. I reckon equal odds of bringing in a psychic and presenting a 'strong feeling' the mp3's are the estranged child of some RIAA IP. In all seriousness they would just ask you where the originals are and hope that you don't have a plausible story about a house fire or burglary or something.

The range of a wireless link is determined by adding the strengths of the Access Point and Client antennas together. To state it another way, if someone puts a higher gain antenna on their laptop then they can connect to your AP from futher away. Trying to secure something by diffuse or decrease your signal strength at the AP end is a great way of feeling more secure without actually being more secure.

Or a 2 digit one that just turned up to tell everyone to get off his lawn =)

I don't know how to say it better than I did in the post you were replying to. I'll try, but perhaps you should read it again.

You can stop almost everything you don't want coming in with a non-stateful static ACL on the upstream router or something like a 3750 switch. The web server or reverse proxy or whatever you have then only has to handle traffic destined for port 80 ( and perhaps ssh from a couple of IP's ). A switch or a router can run that ACL in hardware at the line rate of the port without operating a state table at all, and it doesn't give the attacker a new easy way of taking your site out.

Theres no reason why the host can't have local firewalling too, but it is pretty well irrelevant at that point.

Well hopefully you aren't going to be consulting on anything important that gets deployed.

A stateless ACL on a switch or router that does it in a hardware path will do just fine dropping packets destined for unintended services, and it won't act as an additional attack vector.

A firewall in front of a server farm is a 'layer' that only does harm, and does not do any good.

The article writer is just a clueless journalist but the guy he is getting the technical content from knows what he is talking about. Look up the NANOG archives for Roland Dobbins if you want to read through the flame wars along these lines before. Any firewall that does stateful filtering is just another attack vector in a big web server deployment. Most firewalls can be either crashed or will start refusing new connections with only a few thousand packets per second of the right stuff. Either way your site is down and the DDOS successful when it happens. If you put in non-stateful ACL's on a router or switch that does them in a hardware path in front of your web farm to filter anything other than port 80 then you can eliminate most of the cruft at line rate without giving the attacker a nice juicy state table to destroy. Your web server has to maintain the connection state to run anyway, so why not just let it do that and have the problem distributed among all your web servers, they deal with it a heap better than any firewall.

How about putting an A or AAAA record in a reverse DNS zone, so your site ends up looking like http://2.0.192.in-addr.arpa/ or whatever. There is no registry involved with the delegation of those reverse zones, so it would be alot more difficult for anyone to interfere with it.

What will make it even more fun is if you have two branch offices of the same company connected to the different ISPs getting 172.16.32.66 and 10.0.65.88, how do you set up a VPN between them?

We have assigned 14 /8's _this year_ so far, so if you magically get all of those back, you don't even get a years delay. I guess when you say 'That's a LOT of unused IP's' the missing information is that 'We go through a LOT of IP's'.

Spend that effort and money on deploying IPv6 instead.

We use up almost 2 /8's every month.

You could go through every one of those and fight the massive legal battle to get them all back ( probably taking us well beyond the date when we are out anyway ), and you have only bought a year or two.

Save yourself the trouble and deploy IPv6, instead of making lawyers rich and then deploying IPv6.

Whoever was telling you that we were going to run out in one year five years ago was probably smoking methamphetamines at the time.

The IANA free pool will run out next year, probably before mid year.

The point at which you can't actually receive any more addresses won't come until the RIRs exhaust the blocks that they have received from IANA which might not be for another year after that.

I don't know where you have been getting your predictions. It is pretty certain that IANA is going to run out of space about the middle of next year.

We have 14 /8's left in the IANA free pool, we use up almost 2 /8's every month.

Are you betting on the ipv4 space usage magically decreasing ( right when everyone will start freaking out about getting their last allocations )?

Where am I supposed to skip to if I'm starting in .nz?

I Hope noone in any sort of IT role reads this article and decides to put off their IPv6 projects.

The IPv6 killer app is IPv4 address space runout. http://www.potaroo.net/tools/ipv4/index.html

Unless you are a person who has actually applied for IPv4 address space for a project ( eg. new ISP broadband product, new co-location room, planning for next years subscriber growth etc. ), you are going to have alot more work to do to imagine what is going to happen when the first bunch of IPv4 space applications are declined ( more likely approved but put on the waiting list ).

People who actually use up big wads of IPv4 space are either going to have to decide that you have to push IPv6 into the project in some form, or you are going to design up some sort of multi layer NAT monstrosity along with the huge mess that is going to make. The IPv6 doom sayers are just trying to convince people to choose the one off pain of the IPv6 migration over a giant mess of NAT forevermore. If you really love the multilayer NAT and don't want to live without it, then be consoled by the fact that you probably are going to get it along side your IPv6 for at least a while anyway.

If you are the editor of some PC mag, you aren't actually going to get to choose what happens and you probably should just shut up.

Agreed that the general idea would be a good thing.

However, how do you come up with a workable definition of "keep developing"? Would employing a drunk homeless guy to translate the comments in the source code from English to ancient hebrew making releases 6 monthly count?