"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... …
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 ;)
...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.
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.
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.
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
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.
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.
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
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.
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. ...
Biting the hand that feeds IT © 1998–2019