If the cracking of DRM tech continues at this pace, we'll soon find ourselves living in a strange world where consumers are granted the privilege of PLAYING the content they PAID hard earned cash for! Ridiculous! This must stop while there's still a shred of decency and fairness left in the world! How will the copyright infringing pirates differentiate their loot if the legit stuff become as flexible, reliable and convenient?! What a mess!

I don't foresee ISPs trying to pull off such stupidity in this day and age. Maybe I underestimate their incompetence. It'd be pretty difficult to market such an inferior service policy when home users have become accustomed to having multiple computers, their PS3's, HTPCs, smart phones, etc, etc, etc all sharing their Internet connection over the last decade or so.

I'd switch ISPs instantly if it meant the difference of having a single IPv6 address or a proper /64 prefix for my home LAN. If they all collude and run their network like a bunch of brain damaged idiots, well hey, I can NAT the single IPv6 address and things are no worse than they are now. Though they would have killed the most significant advantage of the new protocol.

Taking the only approach that makes sense (assigning each customer their own global prefix) would give them some advantages in tech support they don't currently have. The ISP I work for often has to suspend accounts with one or more compromised computers that end up as SPAM bots. Currently, in the IPv4 world of NAT, we can't tell them any specifics - only that one or all of their computers have been compromised. With every address globally routable, at least your ISP could shove you in the right direction and say something along the lines of '2610:78:ad:1::3' is infected.

I don't think my default-deny rule was necessarily off-topic. It is there to support my point, that is: if you aren't granted access to my computers, why the hell should I care if you can confirm their existence? In my opinion, hiding my topology isn't worth dealing with the kludge that is NAT. Many protocols embed IP addresses within the protocol and break when they pass through NAT. These tend to have workarounds, but who wants to bother with that?

All that being said if, in your opinion, hiding your topology is worth the drawbacks of NAT all the power to you. There is nothing preventing the use of a similar technique in IPv6. I will choose against NAT, others may strongly disagree with me.

The thing is, in IPv4 I have no choice but to hide everything behind NAT. IPv4 addresses aren't plentiful enough to have a block routed to everyone who wants one. In IPv6, addresses are plentiful and you're free to use whatever strategy you want. This is a good thing!

What merit does topology hiding have in your opinion? Does the default deny rule in the firewall vanish once I know how many hosts you have? The whole topology argument smells like 'security through obscurity.'

NAT breaks end-to-end connectivity. Its main purpose in IPv4 is to deal with the limited address space. In the massive address space of IPv6, NAT is no longer necessary.

You can still NAT everything behind non-routable ULA addresses if you wish, but I see no reason to do so. If one takes this approach and later decides they need a specific port opened to more than one machine, ie) port 80 for a couple new web servers, they won't be able to do this without re-numbering or setting up a a couple new static NAT rules. Note: I specifically say a couple (or more than one) as this is specifically where dynamic NAT based port forwarding breaks down.

A much better approach is to keep everything on globally routable IPs and adding a quick (hopefully default) firewall rule to deny all incoming traffic. This way you still protect your network from undesired incoming connections but still have an easy option later to open ports as needed without any of the limitations. This is exactly how I would set my IPv4 networks up today, if real IPs were actually available.

There MAY be niche scenarios where non-routable IPs are desirable in the IPv6 world, I honestly can't think of any. Can you?

Agreed, brain-finger connection issue, I meant to say 'unique local' but typed 'link-local.'

You caught me on a typo. I did mean *Unique* Local Address (ULA) but force of habit made me type in "link" local. My fingers are often faster than my brain when typing a quick post. :)

With that aside, we are pretty much in agreement.

You and many others desperately need to read more about v6 before regurgitating the same old myths.

* Read up on RFC 4941 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6
* Their is NOTHING in IPv6 that negates a hardware firewall. You get a prefix routed to your 'router' it can have whatever allow or deny rules you like.
* If you want to use NAT and non-routable IPs for whatever reason, however misguided, there is nothing in IPv6 preventing you from doing so, see also FC00::/7 link-local addresses
* Whether a network is routed or switched has as little to do with IPv4 as it does with IPv6, these topology decisions have nothing to do with the protocol.

Um, MS didn't support PNG until IE 7, released in 2006.

Disclaimer: I don't count it as supported when they had a broken implementation from IE4 onwards that completely wrecked the display of any PNG image with an alpha channel.

I have actually found the opposite, Thunderbird 2.x in OS X was dog slow and prone to random periods of non-responsiveness. Thunderbird 3.x on the other hand has been quite snappy.

Exactly...

That or replace your Windows file server with something trustworthy. ;)

Actually, I may have to claim ignorance here as I haven't looked into it recently, is there STILL no crypto available in SMB/CIFS traffic?

If not then perhaps IPSEC between your Windows servers and clients, it's a probably a hassle to setup, but it would give you another layer of security. I've never trusted wireless enough to do sensitive data transfers using non-secure protocols. Guess that's why I don't see this as a big deal. Just business as usual.

M'eh, if you have anything sensitive that you're sending over the network it should be sent securely, period. ie) via SSH, HTTPS, etc... Otherwise, you're just doing it wrong.

Having an additional layer like WPA provided is indeed a nice thing, but this being compromised isn't the end of the world. I'd be far more concerned if there was a vulnerability that allowed someone to bypass WPA all together and connect to a network in which he or she isn't authorized.

The encryption of the traffic itself really isn't that much of a selling point when it'll continue across the wired network in the clear once it hits the router or switch upstream. Encryption that isn't end-to-end really isn't worth the time spent talking about it.

This vulnerability is only useful if the attacker knows your WPA key. In other related news, it has been discovered that those who know your root password can delete all your files.

HTML had far too many ways to do things relative to XHTML

* Uppercase or lower case tags, who cares, they're case insensitive
* Single quote or double quote attributes values, take your pick or mix them, who cares
* Do attributes even have a value? Sometimes...
* Close your tags, don't close your tags... It varies, who cares?
* Etc...

All of these made parsing HTML a pain cause you couldn't make any assumptions about the syntax. Often you would find inconsistencies with the above within one document. XHTML was far stricter. HTML5 seems to have mostly thrown that progress out by making the strict well formed XML syntax 'optional.'