"Steve's Infeasible Third Coming"
IPv4 addresses are a rapidly dwindling commodity [...] ICANN distributed the last big chunks of available IPv4 addresses to the five continental Regional Internet Registries earlier this year. The RIRs in turn are running out of supplies to allocate to ISPs and other network operators - El Reg Somewhere in the near future... …
Erm, I think you'll find it was Assange's coming and it was all a conspiracy (whilst you slept)
I just hear they want to question him because of repeated coming in Sweden.
Actually that work pretty well in Swedglish, maybe adopt a slight accent when you tell folks that one ;)
I lost it at 255 Shades of Grey.
You can only have 254 shades of grey. #ffffff is white and #000000 is black.
Double plus Grey and Double minus Grey I think you'll find.
That's how the guy knew she was faking the story. A minor error from being forced to think on the spot.
White is a particularly bright type of grey, and black a very dark version.
BTW, you have no idea just how many colours white and black there are until you have worked in a colour lab.
Okay. Now we have 256 shades of grey. Either way, 255 was off by one.
Only if you're using standard RGB encoding. Numbers have this really cool property where you can map them to anything you want. Besides, both black and white can be argued to be shades of grey.
...so the nerd war ensues. Before long someone will have to bring up whether or not the light being emitted is a wave or particle and then someone will take another point of view and the whole thing will go all to hell in a slit experiment. Eventually the density of the argument will reach singularity and it will all circle in upon itself with little more than hawking radiation leaking out of the thread. Time will stop. The universe will freeze. Hope will be gone. Eternity itself will become infinitely infinite. Blackless black. Deathless death. Meaningless meaningless.
Thus a new Internet is born.
Meow... Meow... Meow...
Can you get 50 Shades of Grey on a Kindle? Sort of, with dithering.
But is it Ocean Grey or Military Grey?
So for us analogue meatbags (no offence), how many? OK I realise there may be limits on how many different colour a human eye can tell apart, and therefore want to pay for ;) And how come you allowed B&W into a colour lab, wasn't it slightly greenish, like on 3-colour plus no black cartridge printers ;)
Reminds me of when I tried to convince a fellow hifi nut that although when you buy speakers, you may well be able to buy them with digital input, but .......well, you know ;)
Can you get 50 Shades of Grey on a Kindle? Sort of, with dithering.
I haven't read the book, but I hear it's full of dithering.
As my old boss and world authority on colour vision would have pointed out, it's not what you can measure, it's what you perceive.
He has astonished many people over the years by turning a "red" piece of paper into a "green" piece of paper by doing nothing more than holding up a larger piece of multi-coloured paper behind it, thus demonstrating that what they had been taught in school about "coloured light" was patently wrong or at best a misleading over-simplification.
Title says it all.
And then you'll come to the same conclusion as everyone else - this would just delay the inevitable by a few months at best.
you dirty communist baby eater!
Top quality sub nets, know what I mean G'vnor.
You cannot be serious. Trash the 'intranet' of each and every kindergarten, District level government office and business with more than 2 employees in the United States?
That's fighting talk boy.
Just watch how the use of Class A addresses (most of which are owned by American entities) are used to bolster the US economy because US companies will have access to Ipv4 well beyond the rest of the world (Class A addresses account for HALF of the 4 billion Ipv4 address available).
You can forget this bulls**t about not monetising IP addresses, selling them maybe difficult (but not impossible) so they'll lease them out instead.
shades of grey.
Of course there is gray code encoded grey!
should definitely collaborate on an issue or 2 of the BOFH!
> should definitely collaborate on an issue or 2 of the BOFH!
Noooo!! I stopped reading BOFH many years ago when it stopped being funny. Many *many* years ago.
Just wondering, has the PFY ever mentioned his parents?
Classic: "That's a malformed MAC address with extra rivets."
It's good to be alive! In 1985.
Wonderful, I'll have to get my tape out.
Excellently on message Ms Stob. Now please excuse me, it's time for my ttwo minutes of hate against the packet rewriter-general.
Literally spat my coffee out laughing. Wonderful.
I "got" a copy of "Fifty Shades" but you know, by golly it was unsexy. Probably Guantanamo is more sexy.
Is it for the American market, dressed up as "English teatime afternoon light bondage" , but, not too many corpses... so clearly no CSI tie-in possible :P
I would actually recommend this instead: - http://www.goodreads.com/book/show/14060248-fifty-shames-of-earl-grey
Now I'm off to the obligatory Two Minutes of Hate against RFC 2663.
ICANN has always been at war with Eastasia.
Are you insane? NAT does not provide security. Please move on ...
Pff. NAT in the sense of address hiding(*) provides one very specific form of security. With a couple of exceptions in the UDP space, connection initiation is outbound only, since the translator doesn't know what to do with an inbound connection. This prevents an external attacker from reaching in directly to an internal machine.
So, no, there are no security aids in NAT, except in one specific but very, very, very common case.
(*) NAT can be used in various ways. The most common is where you hide an RFC1918 privately-numbered network behind a single public (or "less private" - see "Carrier-Grade NAT") IP address, although as I hope you know, those in the know sometimes call this NAPT or PAT. Less common are methods for renumbering IP networks without renumbering them, and also for hiding a private-numbered host behind one port of a public IP (port forwardiing) so that only the intended port can be reached.
It bears repeating: NAT != security; NAT == borked protocols.
Even in your very specific example it is not NAT that is providing the security: it is the firewall that is preventing an inbound connection just like the lock on my front door (mostly) prevents you from entering my flat. NAT is not the security, the firewall is. Any firewall will provide this exact same level of security whether or not NAT is being employed. (ever hear of transparent mode: no NAT, same security)
What NAT does do is allow you to obscure your assigned IP from the heathens at large. However as everyone on this board knows, there is no security through obscurity.
Kirbin: I didn't mention a firewall. NAT / PAT / NAPT is a separate function from firewalls, and a box might do one, the other, or even both. The point is that the translator (note, to repeat myself, not the firewall) doesn't know how to handle an incoming packet that doesn't match an outgoing connection profile, so it drops it.
There are exceptions, in that for certain UDP situations, a (dynamically created) translation may say "from this internal IP/port, use this external IP/port, wherever it is going, and allow anyone who sends to that external port to hit the internal IP/port". This is called "cone NAT", and severely weakens the coincidental security model of NAPT. Restricted cone NAT uses the same external port for all communications from a given internal IP/port, but only allows external packets from previous destinations.
Restricted cone is less protective than fully-restrictive NAPT that uses a separate external port for each IP/port quad-tuple, but more protective than fully-open cone NAT. The trade-off, as usual, is that open cone NAT is less unfriendly to protocols with a peer-to-peer element, but also less protective.
But once again, none of this has anything to do with firewalls, except in so far as devices that do either often do both.
Relevant note: I work in the IPS engine of a firewall-with-UTM-and-NAT-and-stuff, and I'm specifically responsible for, among other things, the code that handles all the various NAT modes. Some people might think this qualifies me to talk knowledgeably about this subject.
FAIL for you, sorry.
No, you try again! Any router, server and host that performs PAT or port forwarding is offering the feature of preventing external hosts directly connecting to inside hosts, all this without any additional packet filtering. We all know this can be defeated but it is still useful as an added layer of protection which I'm not ready to give up for the sake of the beauty of IPv6 protocol.
And you know what, some bunch of Linux guys will come up with NAT6 and it will be a success, everybody else will adopt it no matter if those who created IPv6 will like it or not. And best of all, you're free not to use it.
It's nice you can do cool stuff with NAT and IPS. Tell me, in a network with enough public IPs for every internal need, what can you do with NAT that I can't do with stateful ACLs?
Relevant note: I've been building packet filters since the late '80s. I had a hand in developing the early ip masquerade code in Linux-386 and worked closely with a large firewall vendor on their early NAT implementations. Some believe this qualifies me as a subject matter expert. ymmv
I'm afraid you're confusing firewallness with NATness. Pray tell, how is "preventing external hosts directly connecting to inside hosts" a function of NAT at all? NAT simply creates a temporary ACL that says: a trusted host sent a packet to host A on port Z; allow return traffic from that host and port; drop everything else. Once the connection is torn down that temporary ACL goes away. How is that different than a reflexive or stateful ACL other than there's NAT to muck things up.
Give me a stateful packet filter and I can do everything your NAT can do and then some. Give you a NAT only box, even with packet filtering, and you can't come close unless you include fixes for IPSEC, FTP, RSTP, SIP, IM, etc..
The thing about ACLs is(are?) that they are not likely to appear on any consumer grade kit (out of the box) any time soon.
Add to the mix wide open windows/SMB shares, and the usual disable-every-security-feature-to-get-it-to-work-itus, and im a bit worried. Many home networks security consists of "if you've got the wifi password, you can access everything. What do you mean its your address/surname?". Unless the belkin (et al) routers are going to be a drop-in replacement, with the ACL features there is going to be quite interesting times ahead.
Im not exactly comfortable with the idea that my potentially buggy code will be addressable from anywhere on the internet. If i was confident it was secure, i wouldn't call it a test server. While i might be able to cobble something together myself, its not something im going to be proficient at, because its something have never had to do before. (and my first hello world was decades ago :s)
Sorry to ramble, but there is a lot of FUD about IPv6, and that needs to be rectified before the article (however good) starts to hit a little too close to home...
I'm pretty sure *DSL routers from Zyxel et al have included stateful firewalls for years. Netfiliter is built into the Linux kernel and it's just a matter of building a web GUI. I distinctly remember setting up port forwarding on one of those, and it involved (a) setting up DNAT and (b) opening the firewall from the Internet to the internal host.
Many consumer-grade IPv6-capable home routers do already include "Simple Security" ACLs that provide equivalent blocking for inbound IPv6 traffic as they do for IPv4 traffic.
Described at http://tools.ietf.org/html/rfc6092
With firewalls there is a clear distinction between the more professional units and the models aimed for the residential markets. Most of the residential devices come with an enabled filter that mimics the behaviour of standard IPv4 NAT, blocking incoming connections by default. ...
Good lord man! Easy patting yourself on the back there, least you break an arm and can't share anymore of your wisdom with us via the keyboard.
I'd almost swear Steve Gibson was here...
Biting the hand that feeds IT © 1998–2017