Perhaps I misunderstood parent, but he seemed to be making a blanket statement that the only acceptable internal IPs are RFC1918 addresses (which I assume he meant rather than the actual RFC1819, "Internet stream protocol").
I was not saying that it is ok to use other people's public IPs (which I have seen, and railed about for the reasons you say), I was simply stating that NAT is not a requirement for security or access to the internet. Incidentally, your ISP wont generally shut you down; if you are NATting, you will lose access to some IPs (as your LAN nodes will go local rather than thru the gateway for those IPs), and if you are not your ISP's routers will probably just discard your packets silently. I doubt your ISP would ever know nor care.
I just re-read your post; as chihowa pointed out, I was NOT saying "use someone elses public IPs".
There are a number of organizations who have thousands of public IPs, and use them internally, without NAT. There is nothing inherently wrong with it, and it does not break the internet.
Obviously you would be correct that it is idiotic to use someone else's public IPs, in all but the most niche circumstances.
I never knew that thats what JTAG stood for. Sounds much cooler than "debugging interface", more like its a team of crack hackers who spend their friday nights chilling with the DevGru (Seal Team 6) guys.
You would have a temporary chain fork, and the branch that gets the next block first, wins
This issue of "the mob will occasionally decide that some of your money doesnt exist" seems to be problematic.
Didnt we have a similar issue with the over-sized hash issue recently, where the central authority ("the decentralized network") decided that that money did not exist, sorry?
If they did not own the IPs, one of two things would have happened.
If they were NATting, it would function in most cases identically to using a private range. They would simply lose access to those IPs which they "hijacked". As their ISP would not route traffic to them, there would be no security threat and probably minor loss of functionality.
If they were not NATting, noone would be able to reach them, nor would they be able to reach anyone else. No security threat; their ISP simply would drop incoming (and potentially outgoing) traffic and return traffic would be routed to the proper IP owner.
Thats nothing like whats describe here; while 192.X may not be assigned to you, traffic from the outside would not be able to directly address you since the ISP wont route that traffic to you.
You could merrily assign 1.2.3.0 / 24 to your home network and it would work just fine as long as you NAT, and noone would be able to directly route to you.
I've seen noob admins do this in the past just to avoid an RFC1819 address space internally, usually as a means to avoid a routing error that they didn't understand. Its never justified.
Please explain why it is never justified to use a public IP internally.
What, exactly, do you suppose we're shooting for with IPv6?
The bank used public IP addresses (existing, used elsewhere) for their internal network? The one that designed that should be considered a bigger security threat that any current cyberattack.
You realize that it is possible to firewall without NAT, right?
You realize that a number of very well secured places use public IPs internally right?
Yes, you have that total amount of bandwidth. If you were to have 4 iSCSI connections, each of them would get a full gigabit; if you had 8 connections each would get 500mbps.
However, a single connection from a single TCP port coming out of a single MAC address / IP address is going to get a single gigabit/sec of traffic; theres not really a good workaround for this.
If youve found a way to get 4gbps on a single iSCSI connection using LACP, please do share, as a LOT of people would be interested to get that running.
LACP uses various methods to choose which link to send frames over-- for example sourceport id, source mac, etc. Regardless of what you choose, a single TCP connection will end up using the same link even when LACP is implemented on the switch.
You might try reading the linked articles in my and silas' responses before arguing; particularly as one of them is a link to the IETF spec.
According to both the article which silas linked below (which is the original source for what I said), as well as a whole boatload of other documentation, thats not correct; its an 802.1ad issue.
I did find this on serverfault which indicates that ONLY balance-roundrobin can get you 2gbps on a single tcp connection; and it also notes that some protocols dont like it, which means that its not really a transparant bonding technology. All of the other methods of distributing packets rely on a hash of various values, for instance source mac and destination mac IDs, and regardless of method the hash will ALWAYS be the same on a single TCP connection, which means that the same single link will be used.
Regardless, the Linux Bonding driver is NOT the same thing as LACP, and its not something you implement on the switch.
No, you dont. If I remember correctly, LACP will give you the maximum bandwidth provided by a single link, per connection. You cant just hook up LACP / LAGG / whatever your vendor calls it, fire up iSCSI, and magically have a 2gbps link to your SAN-- because iSCSI does a single connection per LUN, you will get a 1gbps connection even with LACP.
LACP gets you higher total capacity, so if you were running two iSCSI connections you could get 1gbps on each with no contention. If the summary be believed, this would give you a truly multi-gbps link off of aggregated gbit connections.
Security concerns may or may not be relevant. A lot of places have trivial security on their iSCSI between SAN and server, because the security is applied at other levels (segregated switches / airgap, physical security).
I can think of a number of uses (SAN-server connections where you need more than gigabit) where security is irrelevant.
Not if you can mathematically prove that the two sound reproductions are identical; at that point, it isnt the SOUND that is better but the user's perception of it.
To some degree it may be because doing the research to find the best fit is considered hard or tedious. Monster / Pear / whatever are total rip-offs, but im sure they are as good quality as the best "cheap" brands-- that is, that the $1000 Pear cable is as good as the best Monoprice offers. On the other hand the user may not know enough to avoid the crappy uninsulated cables that truly do introduce distortion or crap out or fail or have faulty connectors. Its possible that they (or the person they contracted out to) knows that there is a budget for the "high end", and its easier to simply pay for it and be done with it than stumbling around in ignorance looking for the non-crappy part.
Because people are willing to pay it. If Adobe charged half of what customers were willing to pay, would that make them A) business savvy, or B) incredibly bad at market analysis?
Er, Adobe cant "manipulate the market to prevent competition". Theyre a software company; its the industry with perhaps the lowest conceivable barriers to entry.
If you mean "competitors in the market consisting of Adobe products" then yea, I suppose there are no competitors to Adobe that make Adobe products.
Slashdot Mirror
Ah, OK, we'll protect the first amendment by gutting the second.
Perhaps I misunderstood parent, but he seemed to be making a blanket statement that the only acceptable internal IPs are RFC1918 addresses (which I assume he meant rather than the actual RFC1819, "Internet stream protocol").
I was not saying that it is ok to use other people's public IPs (which I have seen, and railed about for the reasons you say), I was simply stating that NAT is not a requirement for security or access to the internet. Incidentally, your ISP wont generally shut you down; if you are NATting, you will lose access to some IPs (as your LAN nodes will go local rather than thru the gateway for those IPs), and if you are not your ISP's routers will probably just discard your packets silently. I doubt your ISP would ever know nor care.
If you're using your own public IPs, it works just fine.
I just re-read your post; as chihowa pointed out, I was NOT saying "use someone elses public IPs".
There are a number of organizations who have thousands of public IPs, and use them internally, without NAT. There is nothing inherently wrong with it, and it does not break the internet.
Obviously you would be correct that it is idiotic to use someone else's public IPs, in all but the most niche circumstances.
Because when IPv6 comes out, all of your assumptions about "im safe if im non-routable" will go out the window along with NAT.
Why spend all these years growing complacent on something thats similar-to-but-isnt security, when you can just deploy security?
Oh, they promise. Well, Im sold.
I never knew that thats what JTAG stood for. Sounds much cooler than "debugging interface", more like its a team of crack hackers who spend their friday nights chilling with the DevGru (Seal Team 6) guys.
You would have a temporary chain fork, and the branch that gets the next block first, wins
This issue of "the mob will occasionally decide that some of your money doesnt exist" seems to be problematic.
Didnt we have a similar issue with the over-sized hash issue recently, where the central authority ("the decentralized network") decided that that money did not exist, sorry?
If they did not own the IPs, one of two things would have happened.
If they were NATting, it would function in most cases identically to using a private range. They would simply lose access to those IPs which they "hijacked". As their ISP would not route traffic to them, there would be no security threat and probably minor loss of functionality.
If they were not NATting, noone would be able to reach them, nor would they be able to reach anyone else. No security threat; their ISP simply would drop incoming (and potentially outgoing) traffic and return traffic would be routed to the proper IP owner.
Thats nothing like whats describe here; while 192.X may not be assigned to you, traffic from the outside would not be able to directly address you since the ISP wont route that traffic to you.
You could merrily assign 1.2.3.0 / 24 to your home network and it would work just fine as long as you NAT, and noone would be able to directly route to you.
I've seen noob admins do this in the past just to avoid an RFC1819 address space internally, usually as a means to avoid a routing error that they didn't understand. Its never justified.
Please explain why it is never justified to use a public IP internally.
What, exactly, do you suppose we're shooting for with IPv6?
The bank used public IP addresses (existing, used elsewhere) for their internal network? The one that designed that should be considered a bigger security threat that any current cyberattack.
You realize that it is possible to firewall without NAT, right?
You realize that a number of very well secured places use public IPs internally right?
Except that Im a republican and I dont want to be told that, so the above "troll" mod that you got was quite accurate.
But hey, its always worth trying to take shots @ republicans, regardless of reality, right?
GPL doesnt "make the software really free" unless you subscribe to a particular definition of freedom which excludes developer freedom.
Yes, you have that total amount of bandwidth. If you were to have 4 iSCSI connections, each of them would get a full gigabit; if you had 8 connections each would get 500mbps.
However, a single connection from a single TCP port coming out of a single MAC address / IP address is going to get a single gigabit /sec of traffic; theres not really a good workaround for this.
If youve found a way to get 4gbps on a single iSCSI connection using LACP, please do share, as a LOT of people would be interested to get that running.
LACP uses various methods to choose which link to send frames over-- for example sourceport id, source mac, etc. Regardless of what you choose, a single TCP connection will end up using the same link even when LACP is implemented on the switch.
You might try reading the linked articles in my and silas' responses before arguing; particularly as one of them is a link to the IETF spec.
According to both the article which silas linked below (which is the original source for what I said), as well as a whole boatload of other documentation, thats not correct; its an 802.1ad issue.
I did find this on serverfault which indicates that ONLY balance-roundrobin can get you 2gbps on a single tcp connection; and it also notes that some protocols dont like it, which means that its not really a transparant bonding technology. All of the other methods of distributing packets rely on a hash of various values, for instance source mac and destination mac IDs, and regardless of method the hash will ALWAYS be the same on a single TCP connection, which means that the same single link will be used.
Regardless, the Linux Bonding driver is NOT the same thing as LACP, and its not something you implement on the switch.
No, you dont. If I remember correctly, LACP will give you the maximum bandwidth provided by a single link, per connection. You cant just hook up LACP / LAGG / whatever your vendor calls it, fire up iSCSI, and magically have a 2gbps link to your SAN-- because iSCSI does a single connection per LUN, you will get a 1gbps connection even with LACP.
LACP gets you higher total capacity, so if you were running two iSCSI connections you could get 1gbps on each with no contention. If the summary be believed, this would give you a truly multi-gbps link off of aggregated gbit connections.
Security concerns may or may not be relevant. A lot of places have trivial security on their iSCSI between SAN and server, because the security is applied at other levels (segregated switches / airgap, physical security).
I can think of a number of uses (SAN-server connections where you need more than gigabit) where security is irrelevant.
see that slider near "load all comments"? Slide the right-most slider up to 0.
Problem solved.
Not if you can mathematically prove that the two sound reproductions are identical; at that point, it isnt the SOUND that is better but the user's perception of it.
There may be more than ego-stroking to it.
To some degree it may be because doing the research to find the best fit is considered hard or tedious. Monster / Pear / whatever are total rip-offs, but im sure they are as good quality as the best "cheap" brands-- that is, that the $1000 Pear cable is as good as the best Monoprice offers. On the other hand the user may not know enough to avoid the crappy uninsulated cables that truly do introduce distortion or crap out or fail or have faulty connectors. Its possible that they (or the person they contracted out to) knows that there is a budget for the "high end", and its easier to simply pay for it and be done with it than stumbling around in ignorance looking for the non-crappy part.
Because people are willing to pay it. If Adobe charged half of what customers were willing to pay, would that make them A) business savvy, or B) incredibly bad at market analysis?
Er, Adobe cant "manipulate the market to prevent competition". Theyre a software company; its the industry with perhaps the lowest conceivable barriers to entry.
If you mean "competitors in the market consisting of Adobe products" then yea, I suppose there are no competitors to Adobe that make Adobe products.
None of it comes close to explaining their huge markups.
If you want an explanation, its that people are still (excepting those who buy from the US) willing to pay the inflated prices.
If Im selling bread, and I know people will pay $50 /loaf, why would I charge less than that?