Inbound and Outbound traffic is an important concept to understand even if all devices were with public IP addresses but behind a firewall.
True. Blocking outbound SMTP is good. But with a NAT, the equivalent firewall configuration is allowing all outbound by default, and allowing nothing inbound. Allowing some inbound traffic makes life easier for everyone.
It'd be better if some inbound traffic were also allowed.
[NAT] just adds some hurdles I have to jump over.
For you and the rest of the world. The sum of all these hurdles is a significant amount of frustration, wasted effort, and projects that could have worked abandoned.
To the GP, one of the problems that I have with the grocery store having access to my dear Frigidaire is that if they have access, so does everyone else.
Have you heard of a firewall? Blocking packets has nothing to do with NAT.
NAT'ing does many things... (1) save on IP space and (2) increase security...
We wouldn't need to skimp on IP space if IPv6 were deployed. And we've already established that security has nothing to do with NAT.
Right. There are workarounds. It's reasonable to use them. But as George Barnard Shaw once said, "the reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
Sure, in the same sense that crushing an airliner into a cube makes it useless for terrorists. NAT breaks the internet, and when you break something, it's useless because it's broken.
You can filter packets with a firewall without doing any NAT at all. In fact, your life would be a lot easier without NAT. There would be no need for configuring ports. There would be no need for mapping and configuring and making and unmaking.
You'd plug things in, and they'd just work. Globally. You can allow connections to your fridge from work, or from anywhere. A firewall could do that. The fridge itself could do it. But you'd still be connecting to your fridge, and not some random port on some arbitrary gateway machine somewhere.
Going with your fridge analogy, why should it be a bad thing for a grocery store to connect to all the fridges it knows about in order to tell them about new products? Why this artificial distinction between "inbound" and "outbound" traffic?
TCP headers don't contain domain names. What on earth are you talking about?
If you're talking about application-level multiplexing, well, that's part of the problem. Not part of the solution. You yourself identified part of the problem with this scheme: finding the network-level address of the thing you're talking to isn't good enough to identify the particular thing you're talking to.
*sigh* With people like you, who needs strawmen? Did you read my post?
Dividing the internet between "public, static" servers and "public, transient" ones results in a whole host of problems that I've mentioned. Even if you could make UPnP work reliable, and even if you could avoid running out of port numbers as well as IP numbers, you'd still be left with the problems I mentioned.
FTP is only legacy because it dates from a better, vanished time when simple, direct, bidirectional connection is possible. There's nothing wrong with FTP: there's something disturbingly wrong with UPnP!
Let's ignore in-band multiplexing being messy a hack. Let's ignore the lack of consistency between multiplexing schemes. Let's ignore the immense complexity of making routers understand every stupid little application-level protocol. Let's ignore the latency introduced by waiting for a connection to open before knowing where the next hop goes.
Even after all that ignoring, your proposal won't work. Not with anything resembling today's equipment anyway.
I'm Bob, you're Alice. (We can switch; I'm flexible.) You want to initiate a call to me. Let's say we've registered with a central directory, and the directory tells you that I'm at address A.B.C.D:12345.
But wait -- back up. What right do I have to use A.B.C.D:P? As far as I'm concerned, I'm at 192.168.1.1. So I connect to the directory and tell it I'm at 192.168.1.1, listening on port 12345.
The directory replies "what the hell are you talking about? That's not a public IP. Your public IP is A.B.C.D.". If you, Alice, try to connect to me at 192.168.1.1, the connection will fail, or go to your annoying friend Carol, whom you really don't want to talk to. OTOH, if the directory replies with A.B.C.D, how are you supposed to connect to me? Remember, I'm listening at 192.168.1.1 at port 12345.
Either I have to talk to my ISP and tell it "give me an external port and forward traffic on that port to 192.168.1.1 port 12345", or the directory server has to talk to A.B.C.D and tell it "Oh yeah. Your client 192.168.1.1. He's listening on port 12345. He told me so. Give me a port I can connect to you on that will have traffic go there."
The second scheme is clearly a security problem. The first requires cooperation from ISPs. UPNP sort-of addresses the issue, but not really very well at all.
Basically, you're reinventing an entire routing protocol. Poorly.
You need to upgrade ISP equipment to allow this sort of chit-chat to go on whenever somebody wants to listen for a connection.
What happens if your ISP is itself behind a NAT? What happens when you run out of ports?
The way you propose, it's turtles all the way down. It'd still be cheaper to just adopt IPv6 in the first place.
Or, you know, you could just firewall off the parts of your/64 that you don't want publicly reachable. The concept of a "DMZ" is obsolete in a NATless world, and the vast, vast majority of IPv6 users won't need NAT.
(Though I do agree with your post otherwise. If you're a business andy our/64 is too small, you can just get another/64. That should last another geologic aeon or two.)
The single most pressing problem for IPv6 right now, though, is getting provider-independent addresses for everyone who wants them. We need to solve the route table size problem for that. One interesting proposal I read was to use DNS for routing information.
NAT is not a solution. It's a huge, gigantic clusterfuck of a problem. Some people only started their careers after NAT was widespread, so they can't imagine how wonderful the world is without it. The internet is much simpler when you can assume that all nodes can directly address all other nodes.
Look: this is what we've done.
In the beginning, each endpoint of a TCP (or UDP) connection looked like this:
This change didn't hurt anything, aside from an increase in router complexity. Allowed the 32-bit address space to be used much more efficiently.
Now with the IP address shortage, the situation looks like this:
[48-bit address] (----?---------)
Note how we've lost the distinction between host and service and smushed them all together into one huge opaque number. We've caused ourself lots of problems with this:
One can no longer tell which service is being used based on part of an endpoint address (i.e., the port.). Firewalls, proxies, and so on become much more complicated.
Only part of the endpoint address is provided by DNS. (I'm ignoring SVR records, which nobody uses.) Thus, part of the address needs to be hardcoded:
Every damn piece of software has to have a knob to control what port to use.
When software is too much trouble to configure, we use hardcoded port-parts. Consider SMTP and HTTP. When the port-portion of the big smushed address is hardcoded, Herculean efforts have to be made to route these services through NAT. Good luck if you want to run more than one SMTP server behind a given NAT gateway.
48 bits still isn't enough to satisfy growing demand. What happens when you can't address the endpoint you want even if you use all the address bits and all the port bits? Do we start piling on in-band multiplexing? Should every protocol necessitate something like HTTP 1.1's host header?
Getting a publicly-routable endpoint address involves talked to one or more routers, which may or may not allocate a port for you. And this portion of the endpoint address is highly dynamic.
Because of the last reason, protocols that involve callbacks are complicated. FTP, for example, made perfect sense in the days before NAT. Now, it's viewed as a problematic pain in the ass that always needs special NAT rules and connection tracking to accommodate it.
These days, instead of saying "connect to mydomain.foo.cx", for example, you have to say "connect to mydomain.foo.cx at port 12345". That's out of band address information, and should never be needed. Imagine if DNS only gave you the first three octets an IP address, and every application requires you type in the last one in manually. That's what the world is like today!
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 seriously entertained the idea that the CRA might have something to do with our present crisis, but after doing some research, I don't find it very likely.
The number of CRA loans was too small to seriously upset the financial market, accounting for only a tiny number of the subprime mortgages unwisely made by banks. The worst sin involving the CRA was a decision to allow CRA loans to be securitized into the same bundles other subprime mortgages were put in: that's not too much regulation. It's too little.
I do oppose the CRA in principle. Banning racial and geographic targeting is okay. Requiring banks to make riskier loans than they would otherwise is very, very bad. But either way, it's just too small to have caused the present crisis, and repealing the CRA is certainly not enough to prevent this from happening again.
Seriously, if you sign a mortgage and don't understand what you're signing, you're a fucking idiot, and I have absolutely no sympathy for you.
If one idiot defaults, it's his own problem. But if a hundred million idiots default, it's a problem for us all. Yes, people taking out these mortgages may be stupid and even greedy. But calling them names won't help the situation one fucking bit. We need good solutions. We need to deal with the present crisis, and we need to make sure it never, ever happens again.
I'd rather adopt a solution that helped a hundred people who made a mistake even if it means helping a few freeloaders too. Are you really so callous that you'd torpedo the whole economy just to punish a few people you don't like?
We can agree that these mortgages shouldn't have been created in the first place. But history has shown that threat of foreclosure just isn't a good enough deterrent for lots of people. That's a shame, but it's true. If we want to avoid another bubble, we need to ensure that banks don't lend at these irresistible terms anymore. That requires regulation. If you have a better idea, go ahead and argue for it.
If you want to assign blame, sure, some part of it rests with homeowners. You should know that a zero-down adjustable rate mortgage with a five-year teaser is a seriously bad idea. But being suckered into one of these is understandable, especially given the seriously deceptive advertising during the height of the housing bubble targeted at our most ignorant and vulnerable citizens.
On the other hand, we have the brokers who received massive commissions on mortgages they knew their clients couldn't afford. We have the banks who collected mortgages they knew couldn't be repaid into big packages, and we have credit raters who rated these steaming piles of bad mortgages as AAA-investment-grade-super-plus-plus-good like some kind of retarded eBay user.
While homeowners may be guilty of ignorance and shortsightedness, the financial industry in its unfathomable greed knew perfectly well what would happen and manipulated the market anyway; that's a far greater crime. Equitably, in a bailout, the financial industry should bear the greatest burden and the common homeowner the least. Both are unfair to those of us who lived within our means, but bailing out homeowners is less unfair, and better for our society as a whole.
We must not allow the Treasure Secretary to receive $700 billion to spend with no oversight whatsoever. The current plan creates a gigantic moral hazard, is inflationary, rewards reckless risk-taking by CEOs, and still results in common people being foreclosed upon. We need to re-institute the Glass-Steagall act, allow highly leveraged firms to fail, insulate common people from the effects of these failing institutions, and regulate the market to prevent this catastrophe from happening again.
But how can what you're saying be true if Google blocks by domain name, not IP address? Why would Google care whether your friend's site was on the same physical server if it doesn't look at IP addresses and your friend's site had its own domain?
You missed the OP's point. You can get isolation just as well with a public address. And you avoid having to set up port forwarding and for everything. We can go back to living in a world where port numbers correspond to services and addresses to computers. It's simpler and no less safe than address translation.
IANACL, but I believe this law as written is unconstitutional and will be struck down. Why? Not the coordination provisions, but the seizure ones. We still have a constitutional requirement for due process and a presumption of innocence, and I believe that as long as we don't have any more whackjobs appointed to the Supreme Court, we'll see these blatant power grabs struck down.
Yes and no. There's no actual protection, correct, but the program under normal operation must act as if there were. Both you and the OP are correct. Threads provide no memory protection, and they impose most of the overhead of multiprocessing in a correct program.
You're saying that you heard that they will market a product that hides ads while making it look like they're being shown. There's no way that's even remotely legal (most likely fraud or deceptive business practices; IANAL).
There is actually no reason an ad-blocking product would be illegal. The developers of adblock and adblock plus haven't been sued, after all.
It's a sad reflection of the sorry state of our society that people assume that anything contrary to corporate interests must be illegal somehow.
Slashdot Mirror
True. Blocking outbound SMTP is good. But with a NAT, the equivalent firewall configuration is allowing all outbound by default, and allowing nothing inbound. Allowing some inbound traffic makes life easier for everyone.
It'd be better if some inbound traffic were also allowed.
For you and the rest of the world. The sum of all these hurdles is a significant amount of frustration, wasted effort, and projects that could have worked abandoned.
Have you heard of a firewall? Blocking packets has nothing to do with NAT.
We wouldn't need to skimp on IP space if IPv6 were deployed. And we've already established that security has nothing to do with NAT.
These problems exist with or without NAT.
Also, the next generation of cell phone network will be based on IPv6.
Right. There are workarounds. It's reasonable to use them. But as George Barnard Shaw once said, "the reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
Sure, in the same sense that crushing an airliner into a cube makes it useless for terrorists. NAT breaks the internet, and when you break something, it's useless because it's broken.
You can filter packets with a firewall without doing any NAT at all. In fact, your life would be a lot easier without NAT. There would be no need for configuring ports. There would be no need for mapping and configuring and making and unmaking.
You'd plug things in, and they'd just work. Globally. You can allow connections to your fridge from work, or from anywhere. A firewall could do that. The fridge itself could do it. But you'd still be connecting to your fridge, and not some random port on some arbitrary gateway machine somewhere.
Going with your fridge analogy, why should it be a bad thing for a grocery store to connect to all the fridges it knows about in order to tell them about new products? Why this artificial distinction between "inbound" and "outbound" traffic?
TCP headers don't contain domain names. What on earth are you talking about?
If you're talking about application-level multiplexing, well, that's part of the problem. Not part of the solution. You yourself identified part of the problem with this scheme: finding the network-level address of the thing you're talking to isn't good enough to identify the particular thing you're talking to.
*sigh* With people like you, who needs strawmen? Did you read my post?
Dividing the internet between "public, static" servers and "public, transient" ones results in a whole host of problems that I've mentioned. Even if you could make UPnP work reliable, and even if you could avoid running out of port numbers as well as IP numbers, you'd still be left with the problems I mentioned.
FTP is only legacy because it dates from a better, vanished time when simple, direct, bidirectional connection is possible. There's nothing wrong with FTP: there's something disturbingly wrong with UPnP!
Let's ignore in-band multiplexing being messy a hack. Let's ignore the lack of consistency between multiplexing schemes. Let's ignore the immense complexity of making routers understand every stupid little application-level protocol. Let's ignore the latency introduced by waiting for a connection to open before knowing where the next hop goes.
Even after all that ignoring, your proposal won't work. Not with anything resembling today's equipment anyway.
I'm Bob, you're Alice. (We can switch; I'm flexible.) You want to initiate a call to me. Let's say we've registered with a central directory, and the directory tells you that I'm at address A.B.C.D:12345.
But wait -- back up. What right do I have to use A.B.C.D:P? As far as I'm concerned, I'm at 192.168.1.1. So I connect to the directory and tell it I'm at 192.168.1.1, listening on port 12345.
The directory replies "what the hell are you talking about? That's not a public IP. Your public IP is A.B.C.D.". If you, Alice, try to connect to me at 192.168.1.1, the connection will fail, or go to your annoying friend Carol, whom you really don't want to talk to. OTOH, if the directory replies with A.B.C.D, how are you supposed to connect to me? Remember, I'm listening at 192.168.1.1 at port 12345.
Either I have to talk to my ISP and tell it "give me an external port and forward traffic on that port to 192.168.1.1 port 12345", or the directory server has to talk to A.B.C.D and tell it "Oh yeah. Your client 192.168.1.1. He's listening on port 12345. He told me so. Give me a port I can connect to you on that will have traffic go there."
The second scheme is clearly a security problem. The first requires cooperation from ISPs. UPNP sort-of addresses the issue, but not really very well at all.
Basically, you're reinventing an entire routing protocol. Poorly.
You need to upgrade ISP equipment to allow this sort of chit-chat to go on whenever somebody wants to listen for a connection.
What happens if your ISP is itself behind a NAT? What happens when you run out of ports?
The way you propose, it's turtles all the way down. It'd still be cheaper to just adopt IPv6 in the first place.
Or, you know, you could just firewall off the parts of your /64 that you don't want publicly reachable. The concept of a "DMZ" is obsolete in a NATless world, and the vast, vast majority of IPv6 users won't need NAT.
(Though I do agree with your post otherwise. If you're a business andy our /64 is too small, you can just get another /64. That should last another geologic aeon or two.)
The single most pressing problem for IPv6 right now, though, is getting provider-independent addresses for everyone who wants them. We need to solve the route table size problem for that. One interesting proposal I read was to use DNS for routing information.
NAT is not a solution. It's a huge, gigantic clusterfuck of a problem. Some people only started their careers after NAT was widespread, so they can't imagine how wonderful the world is without it. The internet is much simpler when you can assume that all nodes can directly address all other nodes.
Look: this is what we've done.
In the beginning, each endpoint of a TCP (or UDP) connection looked like this:
[octet][octet][octet][octet][16-bit port]
[(------- host-------------)(--service--)
Each octet was routed hierarchically, and the port acted as an additional level of routing within a single node.
With CIDR, the model moved to this:
[32-bit opaque address][16-bit port]
(-------host----------)(--service--)
This change didn't hurt anything, aside from an increase in router complexity. Allowed the 32-bit address space to be used much more efficiently.
Now with the IP address shortage, the situation looks like this:
[48-bit address]
(----?---------)
Note how we've lost the distinction between host and service and smushed them all together into one huge opaque number. We've caused ourself lots of problems with this:
These days, instead of saying "connect to mydomain.foo.cx", for example, you have to say "connect to mydomain.foo.cx at port 12345". That's out of band address information, and should never be needed. Imagine if DNS only gave you the first three octets an IP address, and every application requires you type in the last one in manually. That's what the world is like today!
I predict that we'll see China begin to use IPv6 addresses before most other people. Why?
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 seriously entertained the idea that the CRA might have something to do with our present crisis, but after doing some research, I don't find it very likely.
See this Reuters story.
The number of CRA loans was too small to seriously upset the financial market, accounting for only a tiny number of the subprime mortgages unwisely made by banks. The worst sin involving the CRA was a decision to allow CRA loans to be securitized into the same bundles other subprime mortgages were put in: that's not too much regulation. It's too little.
I do oppose the CRA in principle. Banning racial and geographic targeting is okay. Requiring banks to make riskier loans than they would otherwise is very, very bad. But either way, it's just too small to have caused the present crisis, and repealing the CRA is certainly not enough to prevent this from happening again.
If one idiot defaults, it's his own problem. But if a hundred million idiots default, it's a problem for us all. Yes, people taking out these mortgages may be stupid and even greedy. But calling them names won't help the situation one fucking bit. We need good solutions. We need to deal with the present crisis, and we need to make sure it never, ever happens again.
I'd rather adopt a solution that helped a hundred people who made a mistake even if it means helping a few freeloaders too. Are you really so callous that you'd torpedo the whole economy just to punish a few people you don't like?
We can agree that these mortgages shouldn't have been created in the first place. But history has shown that threat of foreclosure just isn't a good enough deterrent for lots of people. That's a shame, but it's true. If we want to avoid another bubble, we need to ensure that banks don't lend at these irresistible terms anymore. That requires regulation. If you have a better idea, go ahead and argue for it.
If you want to assign blame, sure, some part of it rests with homeowners. You should know that a zero-down adjustable rate mortgage with a five-year teaser is a seriously bad idea. But being suckered into one of these is understandable, especially given the seriously deceptive advertising during the height of the housing bubble targeted at our most ignorant and vulnerable citizens.
On the other hand, we have the brokers who received massive commissions on mortgages they knew their clients couldn't afford. We have the banks who collected mortgages they knew couldn't be repaid into big packages, and we have credit raters who rated these steaming piles of bad mortgages as AAA-investment-grade-super-plus-plus-good like some kind of retarded eBay user.
While homeowners may be guilty of ignorance and shortsightedness, the financial industry in its unfathomable greed knew perfectly well what would happen and manipulated the market anyway; that's a far greater crime. Equitably, in a bailout, the financial industry should bear the greatest burden and the common homeowner the least. Both are unfair to those of us who lived within our means, but bailing out homeowners is less unfair, and better for our society as a whole.
We must not allow the Treasure Secretary to receive $700 billion to spend with no oversight whatsoever. The current plan creates a gigantic moral hazard, is inflationary, rewards reckless risk-taking by CEOs, and still results in common people being foreclosed upon. We need to re-institute the Glass-Steagall act, allow highly leveraged firms to fail, insulate common people from the effects of these failing institutions, and regulate the market to prevent this catastrophe from happening again.
Legality does not define morality. Rules should flow the other way. A 17-year old drinking beer is not immoral, and therefore should not be illegal.
As Thoreau said, we have not only a right, but a duty to disobey unjust laws.
But how can what you're saying be true if Google blocks by domain name, not IP address? Why would Google care whether your friend's site was on the same physical server if it doesn't look at IP addresses and your friend's site had its own domain?
You missed the OP's point. You can get isolation just as well with a public address. And you avoid having to set up port forwarding and for everything. We can go back to living in a world where port numbers correspond to services and addresses to computers. It's simpler and no less safe than address translation.
RTFA. Spectra were taken in three separate instances, and it's nothing like what we've seen.
No! The very concept of a EULA is what's offensive. In the free world, we should be doing everything we can to oppose this contemptible practice.
Around the turn of the last century, books had EULAs. Then the first sale doctrine came along. Precisely the same principles apply to today.
EULAs are wrong. Just say no.
IANACL, but I believe this law as written is unconstitutional and will be struck down. Why? Not the coordination provisions, but the seizure ones. We still have a constitutional requirement for due process and a presumption of innocence, and I believe that as long as we don't have any more whackjobs appointed to the Supreme Court, we'll see these blatant power grabs struck down.
Yes and no. There's no actual protection, correct, but the program under normal operation must act as if there were. Both you and the OP are correct. Threads provide no memory protection, and they impose most of the overhead of multiprocessing in a correct program.
Ah, the Microsoft Paint school of user interface design.
There is actually no reason an ad-blocking product would be illegal. The developers of adblock and adblock plus haven't been sued, after all.
It's a sad reflection of the sorry state of our society that people assume that anything contrary to corporate interests must be illegal somehow.
Modifying a value more than once in a single sequence point is undefined behavior.