"IPv6 eliminates the need for NAT... except NAT is needed so IPv4 legacy hosts/servers/services/devices can still talk to my IPv6 hosts/servers/services/devices. Wait, I can get rid of the need for NAT by making sure that all my IPv6 devices also have an IPv4 address when talking to the legacy equipment! Except I don't have enough IPv4 addresses, so I'll have to use NAT..."
So maybe someone can explain how, either:
All devices everywhere will be magically upgraded to IPv6 simultaneously, and all the nasty legacy IPv4/NAT issues will magically vanish. Or:
People expect to connect IPv6-only devices to IPv4-only devices without using NAT. (Assigning an IPv4 address to the IPv6 device doesn't solve the address shortage problem, now, does it?)
Thing is, if you can figure out a way to make all IPv6/IPv4 NAT connections work transparently, you have also solved the problem for all IPv4/IPv4 NAT connections... which leaves people even less incentive to upgrade.
Well, exactly as you said. They can either pass the signed/encrypted along or just kill it. If they choose to just kill anything signed or encrypted, where does that leave you?
Encryption of all packets is nice, but I suspect in reality it is a pipe dream -- the problem being key management.
How are you going to verify key information without going over the very same unsecure network?
Or, say, you receive an email from Bob with his key/key fingerprint. Great! You can have secure correspondance with Bob. Some time later, you get another email from Bob, with a completely different key. He's wondering why you haven't emailed him yet -- which one is the real Bob?
Do you go out and check against a third party published list, or a certificate authority? Do you trust them? Suppose you visit a friend's place, and find his list of valid certificate authority information is completely different from yours, but yet everything still seems to work.
The ISP has total control over the wire in between you and Bob, and you and any third party key authority or list. How do you securely perform the initial key exchange and are assured that it's really from Bob?
(First person who says "Over the phone" gets the "missed point" award.)
Okay, if Bob is your bestest pal ever since you both were little grubs, then you might be able to do verification based on common secrets/knowledge/behaviors. However, when it's not Bob you are exchanging data with, but a stranger/company/new acquantinance, that sort of outside check is hard. (I.e. the stories of social engineering security attacks when answer a phone at their desk, and the person on the other end claims to be from someone else within the company in a different division, and asks if the called party can send them some information about a project.)
Trying to verify that a new party with whom you have not have had any prior relationship before is who the new party claims to be is non-trivial. Someone shows up at your door in a suit and shows you a badge/ID card claiming to be from the FBI. Great -- is it real? Anyone ever seen what the FBI uses for ID? What do you compare it to? The guy hands you a phone number you can call to verify his identity -- pfft.
At some point, you run into the need to ask a third party "Is this really who it claims to be?" and trust their answer. So, who is this third party going to be when you want to authenticate a website is the company it claims to be, or that person is who he says he is, or that the key is really his? Right now, I believe, say, a lot of SSL certificate authentication is done by... Verisign.
Maybe I am misinformed, but I rather thought that Verisign *was* a big company, that already has ties to big government through the delegation of the root server management.
So how would you routinely encrypt all packets to any/all machines on the Internet while keeping the keys secure and authenticatable?
I like the idea, mind you, I am just not convinced that it can be made to work if the goal is to guard against the people who control the network infrastructure itself -- you're basically struggling against someone who holds all the cards, all the control.
(Protecting your data against other users is a different matter, mind you.)
I mean, suppose you came home, and found the FBI reassembling your computer -- they assure you everything is fine, really, and leave. How do you trust that computer to be secure any more? (Please, no one even start with the idea of running a diagnostic program on a potentially totally compromised computer and trusting the program results.) Short of going in at the hardware level and examining every component to make sure it is running the way it should be, what do you do? Was that USB/keyboard controller soldered like that before? The network is even worse because there is no way to physically verify the thing.
So, how can you do the initial encryption key exchange between your machine and any other machine out on the Internet in a secure, trusted, manageable fashion, if you cannot trust the underlying medium itself?
I can't think of one major TCP/IP program that would work correctly if all computers in the world were NATted. Since universal NAT would destroy the internet, it follows that partial NAT is damaging to it (or so the reasoning goes)
I can't think of one country that would survive if all the people in it were male, therefore, having a partially male population must be bad for the survival of the country.
IP addresses are network layer information. URLs are application level information. If the applications are dependent upon the IP address information, then this is going to break during any IPv4/IPv6 NAT, too. (This is not a matter of native applicaton IPv6 support being needed, but that if the server is on one address version and the client the other going through a NAT between the networks.) (Actually, that there are compile time flags for IPv6 support suggests a lack of modularity -- the application is too tightly coupled to the network, where the network access should be presented through a system library/API that hides the transport layer -- be it Bluetooth, ATM, celluar data, SMS, or whatever.)
Should Apache break just because I replace my ethernet cable with a wireless ethernet link? My 10-Base-T connection with Gig Ethernet? Or even, heaven forbid, change my MAC address? Should I need to include any of that in my Apache config? Why should IP addresses matter, then? From an application level, it should be all hostnames and URLs. Unfortunately, it is not a perfect world -- and we have to sometimes live with badly-designed solutions.
Another tired complaint about how NAT is a terrible evil because it breaks badly designed applications.
At one point in history, there were telephone switches that were these big mechanical things that actually made physical links between the wires of the end points.
People could make a call between two phones, then run a fractional T1 over them. Awesome! End to end connectivity! High speed data! No pesky analog-to-digital converter, no wire-to-fiber convert, and all that nonsense. Just raw connectivity.
Perhaps we should go back to the era of mechanical switches, then, as well as getting rid of NAT.
Or maybe people can work on separating their application layers from the network layers properly.
Re:Lessig said it first
on
Trusted Computing
·
· Score: 2, Insightful
They would need to have control of my connection at the packet level.
You think they don't already? Or rather, can't?
If your packet goes over someone else's wire, that person can do *anything* to that packet they want to. There is you, on one of the wire, sending electrical signals out that represent data -- there is nothing at all that mandates the electrical signals they send back have to be what you want them to be.
Honestly, if you would not believe this:
# traceroute my.server.com
Tracing route to 64.64.64.64
1. 15 ms 16 ms 19 ms my.router.net
2. 35 ms 42 ms 53 ms relay.babylon5.earth.gov
3. 55 ms 90 ms 85 ms comnet.core.ncc1701-e.starfleet.ufp
4. 120 ms 130 ms 115 ms my.server.com
Why in the world would you trust:
# traceroute my.server.com
Tracing route to 64.64.64.64
1. 15 ms 16 ms 19 ms my.router.net
2. 35 ms 42 ms 53 ms rtr1.router.net
3. 55 ms 90 ms 85 ms mae-east.gateway.server.com
4. 120 ms 130 ms 115 ms my.server.com
The person at the other end of your wire has total control over what he/she chooses to send you, be it garbage, data, or 10,000 volts. Once your packet reaches the other end of the wire, they can drop it, mangle it, copy it, etc. (Note that encryption and the like might stop them from decoding it or altering it *in a useful way*, but this doesn't stop them from *trying*)
You have no control over your packets once they leave your own wires, except what you may have contractually negotiated with the owner(s) of the other wire(s). (And any proof of contractually failure is going to be distressingly hard to show, as without hard evidence, the ephemeral/forgeable nature of the electronic medium makes proof tricky. You: "My ISP was forwarding packets to the NSA!" Them: "The paranoid guy forged those logs by manually typing up those files. Here are our logs that show otherwise.")
Other people already have control over your packets. You, at best, can attempt some minimal control over your data via encryption and digital signing, but not a lot beyond that.
It is not a matter of (just) static port mapping, it is more a fundamental problem in the way DNS works with Internet addressing -- or more specifically, the way way applications interact with Internet addressing. (This will no doubt invite flames from those outraged at the idea that there might be a fundamental problem/mistake in the Internet.)
More specifically, what happens when you have multiple machines behind the NAT device? How do you map the ports statically to multiple machines *and* also communicate this information to devices on the outside of the NAT device? (That is, port 80 on the NAT device maps to server1, port 81 on the NAT device maps to server2, etc.)
The key issue is that applications are using network level addressing (IP addresses) rather than application level addresses (URLs) to establish the network connection -- we have network specific information far too embedded in the applications, which is why the transition from IPv4 to IPv6 is such a nuisance. At the moment, the DNS SRV record could help with some of these matters by specifying a port number to use for a specific service and host/domain.
A better design for applications would be for them to be completely unaware of 'IP addresses' and function purely on URLs or hostnames + service name, and link to libraries or network drivers on the machine that handle the network aspects. Really -- excepting network mangement tools, what application bothers about the MAC addresses of machines or PPP negotiation details? IP addresses should not matter to the applications, either -- at that point, much of the arguments against NAT go away.
Honestly, the fact that NAT causes applications to break is more a reflection on mistakes in the architecture/application. IP packets themselves don't fall over and die just because they transition from a PPP link to wireless to ethernet to SONET to etc. The differing layers are independent of one another -- the applications have not yet been weaned off directly diddling with the IP layer.
To be honest, it's hard to say what the payoff is... yet. It's hard to make direct comparisons.
Keep in mind that in many, though not all, cases the 'cheaper' phone service over IP is also of less quality than the PSTN -- or less assured quality. (i.e. codec compression, lack of QoS guarantees, etc.) It's often easy to make a cheaper version of a product by lowering the standards. So, payoff for Sprint and other companies: more calls crammed into less bandwidth over trunk lines giving more efficient use of bandwidth maybe without any 'noticeable' (to most people) sound quality degredation from the extra compression.
Keep in mind that as you said, "Though to run a voice network... the VoIP traffic separated from best effort traffic.)" -- instead of running two parallel networks (SS7+IP), you are now looking at running two parellel networks (IP (VoIP) + IP (data)) -- which is what is happening now with most of the carriers running a separate, private IP backbone for their voice traffic.
Insofar as expensive telco switching equipment goes... a lot of that has been paid for. The IP softswitch market just about died last year (I used to work at a company on a softswitch -- laid off because no one buying them.) When you have a *paid off* 5ESS that has a 99.999% uptime/reliability sitting in the CO quietly making you money, you don't just toss it out the window and go take out loans to buy a whole new set of VoIP gear, train people in new tech, replace everything, etc. Now, for a new phone company or a start-up or CLEC, the VoIP gear is a cheaper route to start up with. Mass replacement of old telco equipment is not likely -- a gradual migration is more likely.
Also, VoIP has a lot of regulatory hurdles left to jump, and some of them are whoppers. Probably the trickiest is a secure, reliable location service for 911 emergency calls. (Note that many countries have their own SS7 variants for call signalling, in many cases often due to local laws/regulations requiring that calls be handled in a certain way. Unless those laws are relaxed for VoIP, it is going to be quite a nuisance to implement.) (i.e. phone calls made from a prison are/can be handled differently than calls made from a pay phone or from calls made from a home phone) This isn't saying that it can't be done, or won't be done, just that at the end of the day, moving everything onto VoIP may not be as cheap as people expected (if it's cheap at all.)
Long term, it's really hard to say. Production on old-style telco gear has started to wind down, if not stopped, so the only way forward is through next-gen products. However...
IPv6 is going to suck, bandwidth utilitization wise, for VoIP calls, because VoIP data packets need to be small -- people might be looking at 30% to 50% IP header bandwidth "tax" -- that 10% ATM cell head "tax" might suddenly start to look better (because ATM was designed with voice in mind more so than data.) Seeing what happens with that will be interesting -- bandwidth may be cheap enough by the time IPv6 hits that it doesn't matter, but we'll see.
(Presonally, I can only hope SIP 2.0 dies a long overdue death and is replaced by a better excuse for a VoIP signalling protocol.)
Probably little to do at this point but kick back and see what actually survives in the real world.
It's very regular, very logically designed, and a single mis-typed character can still yield a valid word -- no way of error detection (i.e. in English, I can type "the color bluu", "the color bleu", "the color "bluo", "the color blu", and people can probably guess what I mean. In Ebubo, "awa" (green) and "awe" (cyan) and "awi" "red" have no such distinctive differences. If I were to refer to the color "aw_", there is no way to guess what I was referring to.)
And of course, there's LogLan (i.e. LOGical LANguage).
I can't off-hand find the paper which discusses the problem of artificial 'logical' languages having problems with error correction/noise, unfortunately. It's probably linked somewhere on langmaker.com, though, which is a fascinating site in itself.
After looking at some of the sample gestures for the keyboard, I have to admit I am somewhat impressed. Some very interesting ideas there. After looking at more of the sample gestures for the touch keyboard, I am still impressed, but wary.
It reminds me of the problems with 'logically designed languages'. (i.e. all words for colors in the language might start with "cro", "crob" is blue, "crog" is green, "cror" is red, etc. The problem being that a single typos in the word might still be a valid word of a similiar type, but not what you meant.) I suspect someone who became a total expert with the keyboard could do just fine, but an intermediate user could get highly frustrated -- forgetting to use/accidently using an extra finger in a gesture might cause some unwanted operation to happen, not merely cause the desired operation to not happen. Maybe the software is smart enough to second guess some of these issues, but...
Go to the company's page and look at the Enhanced Modifier Chords -- if you tap with six fingers on the home row, you get an Enter -- if you tap six fingers on the row above the home row, you get an Esc key press. (Personally, I would immediately redefine those two gestures to have far more difference between the two -- accidently hitting "Enter" when one meant "Escape" in some dialog boxes would be very bad.) Or the shift/control differences.
Of course, one could just not use the gestures, but then why bother with the keyboard?
Nonetheless, very interesting ideas, but it may not be ready for everyone.
Just expanding the pipes is exactly as you said a simple and stupid solution. It works just fine on simple and stupid networks. It becomes much less of a solution on large and complex networks.
If you have only a mesh of six or two T1s, then sure, maybe replacing all those T1s with pairs of T1s or fractional T3s and replacing all the routers with new ones to handle the new bandwidth might be cheaper than playing around with complex protocol design.
But if you have a nation wide network with literally hundreds of network links and hundreds of routers, just 'expanding the pipes' becomes a nightmare operations issue.
You run into the nasty problem of "Well, we need a bigger router to handle the expanded bandwidth, but the colocate we are in has no more rackspace at the moment. The nearest other facility is ten miles down the road, and we would have to see if we could get all the customer and other data lines re-routed and migrated within the same maintenance window."
You have the same problem with physical bandwidth. If you have a link that's running over a physical T1, and you need more bandwidth, do you get another T1 laid, switch to a fractional T3? If you are using a T3 and need more, do you go to OC3? Sonet? Of course, that might require a bigger router...
We'll just throw a bigger router at it! Yeah, right. Who wants to throw the latest greatest model router in without any testing? Of course, those new interface cards for the new expanded bandwidth connections might require a different router software load than what you're running on the other routers... you are paying/spending money on a real test lab, aren't you, before committing your entire network to this? Of course, that's assuming you are staying within one vendor family... we'll skip the issues of CSU/DSUs, and such for now. Oh, yes -- don't forget a larger router means a bigger colocate cost and/or bigger power costs and/or bigger cooling issues (doubling the power supply or AC to a facility is not cheap. Those brand new expanded routers have to live somewhere!)
One hopes the old equipment you are replacing with the new, expanded equipment is paid off, of course. Otherwise you are expanding your debt along with your network... not the way to stay in business/make money. Don't forget the operational cost growth, either! Might have to stock new spares for the new routers, train the techs on the new routers... hope you didn't need a new network monitoring system to handle the new, expanded network. If the expanded network required expansion via new data links through new carriers, better make sure the NOC knows who to call when things go wrong with what lines...
There are other costs, of course. To quote my favorite professor: "Like my old army leutinent used to say, 'Ain't nothin' simple when you're doin' it for real.'"
Consider the phrase "compound interest". With a small amount, in the short term, it's not that impressive. With a large amount, in the long term, it can yield some pretty impressive returns. Just "expanding the pipe" is the same thing -- works fine in the short term, on small networks. Over the long term, it gets exponentially more cost-complex.
(It should be noted that the human race is running around building such things as the Internet precisely because it didn't "add more muscle" or "add more speed" or "add more armor", but because it figured out how to use what it had more intelligently than its competitors. At some point you have to start using your brain.)
Suppose they remove your US citizenship. How do you get a lawyer to represent you? Can you even be represented in a US court? Do they purge your social security number/tax ID? If so, what happens to your bank accounts and property?
Suppose somehow you convince them that it was a mistake -- how do you get your citizenship *back*? What if took months to accomplish and records were purged by various institutions. Do you get your old social security number back, do you get a new one? How would one recover for that?
This is probably the most scary thing here. If they can arbitrarily declare someone a non-citizen and shutdown that person's access to bank accounts (frozen for investigation), work (no longer a US citizen eligible for work), property (siezed for investigation), transportation (no drivers' license -- not a US citizen), and legal representation (good luck finding some without work, money, a car, or a house), what can one do to protest that after the fact? Even if you managed to successfully get your citizenship back, by then, your government confiscated property might have been sold to someone else (nice potential scam for someone there.)
Funny how the term "hack" is a pejorative with regard to NAT.
Isn't it, though? The real 'hack' is replacing IPv4 with IPv6 to 'fix' a problem which is really in the directory services/DNS level. People think that some how static IP addresses will magically make things better, but that's only because they are changing the network protocol to fix a problem in the application layer (i.e. name look-ups).
A better solution would be to fix the directory services at that layer so that IP addresses were not used inside applications. That would also make a transition between IPv4 and IPv6 easier if the applications got their out from being too deep into the network directly. (I.e. get rid of fixed port numbers for specific services, use the equivalent of SRV records or such to let the network layer figure out which port and IP address to send the packets to -- by allowing ports to be looked up as well as IP addresses, that would allow mulitple servers behind NAT behind static port mappings.)
NAT has no effect on transport. You put data in, you get data out. The only reason that NAT seems like a 'hack' is because of bad coding design that has integrated far too much transport-level network information into the applications. If applications and name-look up were written properly, not only would switching applications to IPv6 be trivial because of less internal code dependence on IPv4 rather than a generic network/transport API, but NAT wouldn't be a problem, either.
The static IPv6 address auto-assignment is going to be fun to watch. Suppose the network admin doesn't do DHCP, and just lets all hosts auto-configure. Now, there are a couple things that happen -- the hosts choose random host network values -- makes no sense because the whole point of this is to have a static IPv6 address, right? So, host ABC always chooses the same host part of his IPv6 address (perhaps from his MAC address, which now gives his computer the equivalent of the Intel CPU serial ID number), or some other fixed value. What stops someone else from trying to swipe that same value on the network? Your computer reboots, and when it comes on, there is another host claiming to have that MAC/host address on the network already -- so much for that static IPv6 address. No smart network administrator is going stick their hands into that one -- either things will be dynamically autoconfiguring, and static IPc6 addresses may or may not happen depending on your luck and your neighbors, or the admin is going to assign the addresses specifically rather than letting the network autoconfig.
While an interesting article, it would seem to imply that being able to use a FAX machine at, say, Kinko's should not be possible because people would just have bought their own FAX machines. For a business that sends many FAX machines, buying and maintaining their own FAX machine as opposed to using some one else's may make sense. For personal use, it may not be worth the investment. The article does not seem to take that sort of market segmentation into account.
For example, if one assumes that if you use a phone service heavily and that you can provide it for yourself at a cheaper cost for bulk usage, you would. Businesses already do that for themselves with PBX systems (IP-based or not) -- in a sense, what the article is predicting has already happened, but only as far as the heavy users (i.e. businesses) are concerned.
If one assumes the FAX analogy as gospel, then... nothing will really change. Kinko's and other places will provide FAX services to the consumers that cannot afford or are not interested in buying and operating a FAX machine for casual use. Saying that the next generation of VoIP (bah) products will cause people to stop buying services from the phone companies seems likely to follow the same pattern. For the services which are labelled 'too expensive'... how many people actually use those services? Frequently? Enough to justify the expenditure in setting up and running the services on their own? Maybe the services just aren't worth it, whether provided by the phone companies or by one's self -- perhaps that will be the common sense of the consumer, that maybe some of these 'services' offered by the phone companies, or the new next generation ones hyped by VoIP just aren't worth the money.
Does not the current IPv6 address allocation standard specify using your MAC address as the suffix portion of the IPv6 address? This is merely a taste of things to come if/when IPv6 becomes widely deployed, when your very IPv6 address can uniquely identify the hardware you are on (unless you use IPv6 NAT, of course.)
And yes, presently, you can probably change the MAC address of your system. However, once software vendors and DRM technologies and other things start locking themselves to your computer hardware, I suspect changing the MAC address would cause problems. The only thing this game company has to do is when the game is installed is to lock the licence to the present MAC address so it will not run with a changed IP address without a new licence.
How do you connect an IPv4 network to an IPv6 network without doing Network Address Translation to convert the IPv6 address into some IPv4 address the IPv4 network can handle? You need NAT between the two at least in order to transition from an IPv4 network to an IPv6 network. Of course, if applications break because they have not been properly written to deal with NAT, then they won't work across IPv6 and IPv4 network boundries.
So, if there is no NAT, what good is an IPv6 address? Until the rest of the Internet is converted over to IPv6, it's not going to be able to connect to much that is currently out there. This is not going to encourage most people to convert to IPv6 -- if applications are going to break if you don't have an IPv4 address, so you need to have one anyways, why bother with the IPv6 address at all? Just stay with the IPv4 one.
Neither the DNS system (root servers), or the allocation/control of IP address(ing) is decentralized -- they may be heirarchial, but both still have a root.
It will be interesting to see if IPv6 will use geographic hierarchies for routing, or even relaxes the hierarchial assignment-scheme at all. If your IPv6 suffix is static/fixed (based on your MAC address, say), and your IPv6 prefix is from the current network/area you are in, that will be an interesting tool to let people track devices as they move around/between networks.
Would I be wrong in assuming you feel that you could only run HTTP, SMTP, and such only on IP? If so, then there is not much point in discussing anything more.
Oh, for goodness' sake. You miss the point entirely.
What I said was that for a given URL, which may very well be <http://someplace.com/>, how can you tell if it was IP end to end? You can't. PERIOD. The network is a black box -- you send a stream of bits out, you get a stream of bits back which have only a casual relationship to one another. The back end of the black box could be a webserver farm on an IP network, a bunch of Macs connected on AppleTalk, servers on IPX, or an IBM mainframe. How the heck can you tell what it runs if it only exposes IP to you? It has total control over the stream of bits it sends. It could make a traceroute through its network look like it was going to the moon! And the same URL will work fine for everyone as long as they can reach the gateway or 'server' the URL points to, but it does not require IP end-to-end. If you keep explicit IP addresses out of URLs, then you can have hostname based virtual web hosting, mail domains, and so on.
The point is that by keeping the network address out of the URL, you can be more flexible in what the URL resolves to. Maybe it resolves to IPv6, or maybe it resolves to IPv4, depending on what your system supports -- that is a superior solution, isn't it? That's the problem with using IP addresses as resource specifiers -- it's an inferior solution.
You've confused a single network transport address space with a single application address space.
The value is in a single *directory* address space. Unfortunately, people use IP addresses to refer to resources, rather than, say, hostnames or something that is not bound directly to the network technology. This is precisely the sort of thing which hinders a transition to IPv6.
This is a far more practical and pragmatic engineering idea than tying applications to the network addressing. If you want every machine in the world to have a unique IPv4 address, you're walling yourself into IPv4 forever and ever. What you probably want is a unique identifier for each machine that does not bind you to a specific technology or transport.
Maybe a URL points directly to a machine on the Internet with a static IP address. Maybe it points to a machine behind a firewall with NAT. Maybe it points to an IPX machine on the otherside of a protocol coverter. If you can get the files via that URL, it shouldn't matter, should it? The problem is the current bad engineering practices that make the transport layer addressing entwined with the application layer resource addressing.
I don't care if the data flows over copper, fiber, or wireless, as long as the proper stream of bits get to the right place. Likewise, I shouldn't have to care if it is IP or anything else transporting the bits in particular.
Slashdot Mirror
So maybe someone can explain how, either:
All devices everywhere will be magically upgraded to IPv6 simultaneously, and all the nasty legacy IPv4/NAT issues will magically vanish.
Or:
People expect to connect IPv6-only devices to IPv4-only devices without using NAT. (Assigning an IPv4 address to the IPv6 device doesn't solve the address shortage problem, now, does it?)
Thing is, if you can figure out a way to make all IPv6/IPv4 NAT connections work transparently, you have also solved the problem for all IPv4/IPv4 NAT connections... which leaves people even less incentive to upgrade.
Well, exactly as you said. They can either pass the signed/encrypted along or just kill it. If they choose to just kill anything signed or encrypted, where does that leave you?
Encryption of all packets is nice, but I suspect in reality it is a pipe dream -- the problem being key management.
How are you going to verify key information without going over the very same unsecure network?
Or, say, you receive an email from Bob with his key/key fingerprint. Great! You can have secure correspondance with Bob. Some time later, you get another email from Bob, with a completely different key. He's wondering why you haven't emailed him yet -- which one is the real Bob?
Do you go out and check against a third party published list, or a certificate authority? Do you trust them? Suppose you visit a friend's place, and find his list of valid certificate authority information is completely different from yours, but yet everything still seems to work.
The ISP has total control over the wire in between you and Bob, and you and any third party key authority or list. How do you securely perform the initial key exchange and are assured that it's really from Bob?
(First person who says "Over the phone" gets the "missed point" award.)
Okay, if Bob is your bestest pal ever since you both were little grubs, then you might be able to do verification based on common secrets/knowledge/behaviors. However, when it's not Bob you are exchanging data with, but a stranger/company/new acquantinance, that sort of outside check is hard. (I.e. the stories of social engineering security attacks when answer a phone at their desk, and the person on the other end claims to be from someone else within the company in a different division, and asks if the called party can send them some information about a project.)
Trying to verify that a new party with whom you have not have had any prior relationship before is who the new party claims to be is non-trivial. Someone shows up at your door in a suit and shows you a badge/ID card claiming to be from the FBI. Great -- is it real? Anyone ever seen what the FBI uses for ID? What do you compare it to? The guy hands you a phone number you can call to verify his identity -- pfft.
At some point, you run into the need to ask a third party "Is this really who it claims to be?" and trust their answer. So, who is this third party going to be when you want to authenticate a website is the company it claims to be, or that person is who he says he is, or that the key is really his? Right now, I believe, say, a lot of SSL certificate authentication is done by... Verisign.
Maybe I am misinformed, but I rather thought that Verisign *was* a big company, that already has ties to big government through the delegation of the root server management.
So how would you routinely encrypt all packets to any/all machines on the Internet while keeping the keys secure and authenticatable?
I like the idea, mind you, I am just not convinced that it can be made to work if the goal is to guard against the people who control the network infrastructure itself -- you're basically struggling against someone who holds all the cards, all the control.
(Protecting your data against other users is a different matter, mind you.)
I mean, suppose you came home, and found the FBI reassembling your computer -- they assure you everything is fine, really, and leave. How do you trust that computer to be secure any more? (Please, no one even start with the idea of running a diagnostic program on a potentially totally compromised computer and trusting the program results.) Short of going in at the hardware level and examining every component to make sure it is running the way it should be, what do you do? Was that USB/keyboard controller soldered like that before? The network is even worse because there is no way to physically verify the thing.
So, how can you do the initial encryption key exchange between your machine and any other machine out on the Internet in a secure, trusted, manageable fashion, if you cannot trust the underlying medium itself?
I can't think of one major TCP/IP program that would work correctly if all computers in the world were NATted. Since universal NAT would destroy the internet, it follows that partial NAT is damaging to it (or so the reasoning goes)
I can't think of one country that would survive if all the people in it were male, therefore, having a partially male population must be bad for the survival of the country.
It's poor reasoning.
If the shoe fits, yes.
IP addresses are network layer information. URLs are application level information. If the applications are dependent upon the IP address information, then this is going to break during any IPv4/IPv6 NAT, too. (This is not a matter of native applicaton IPv6 support being needed, but that if the server is on one address version and the client the other going through a NAT between the networks.) (Actually, that there are compile time flags for IPv6 support suggests a lack of modularity -- the application is too tightly coupled to the network, where the network access should be presented through a system library/API that hides the transport layer -- be it Bluetooth, ATM, celluar data, SMS, or whatever.)
Should Apache break just because I replace my ethernet cable with a wireless ethernet link? My 10-Base-T connection with Gig Ethernet? Or even, heaven forbid, change my MAC address? Should I need to include any of that in my Apache config? Why should IP addresses matter, then? From an application level, it should be all hostnames and URLs. Unfortunately, it is not a perfect world -- and we have to sometimes live with badly-designed solutions.
Another tired complaint about how NAT is a terrible evil because it breaks badly designed applications.
At one point in history, there were telephone switches that were these big mechanical things that actually made physical links between the wires of the end points.
People could make a call between two phones, then run a fractional T1 over them. Awesome! End to end connectivity! High speed data! No pesky analog-to-digital converter, no wire-to-fiber convert, and all that nonsense. Just raw connectivity.
Perhaps we should go back to the era of mechanical switches, then, as well as getting rid of NAT.
Or maybe people can work on separating their application layers from the network layers properly.
You think they don't already? Or rather, can't?
If your packet goes over someone else's wire, that person can do *anything* to that packet they want to. There is you, on one of the wire, sending electrical signals out that represent data -- there is nothing at all that mandates the electrical signals they send back have to be what you want them to be.
Honestly, if you would not believe this:
# traceroute my.server.com
Tracing route to 64.64.64.64
1. 15 ms 16 ms 19 ms my.router.net
2. 35 ms 42 ms 53 ms relay.babylon5.earth.gov
3. 55 ms 90 ms 85 ms comnet.core.ncc1701-e.starfleet.ufp
4. 120 ms 130 ms 115 ms my.server.com
Why in the world would you trust:
# traceroute my.server.com
Tracing route to 64.64.64.64
1. 15 ms 16 ms 19 ms my.router.net
2. 35 ms 42 ms 53 ms rtr1.router.net
3. 55 ms 90 ms 85 ms mae-east.gateway.server.com
4. 120 ms 130 ms 115 ms my.server.com
The person at the other end of your wire has total control over what he/she chooses to send you, be it garbage, data, or 10,000 volts. Once your packet reaches the other end of the wire, they can drop it, mangle it, copy it, etc. (Note that encryption and the like might stop them from decoding it or altering it *in a useful way*, but this doesn't stop them from *trying*)
You have no control over your packets once they leave your own wires, except what you may have contractually negotiated with the owner(s) of the other wire(s). (And any proof of contractually failure is going to be distressingly hard to show, as without hard evidence, the ephemeral/forgeable nature of the electronic medium makes proof tricky. You: "My ISP was forwarding packets to the NSA!" Them: "The paranoid guy forged those logs by manually typing up those files. Here are our logs that show otherwise.")
Other people already have control over your packets. You, at best, can attempt some minimal control over your data via encryption and digital signing, but not a lot beyond that.
It is not a matter of (just) static port mapping, it is more a fundamental problem in the way DNS works with Internet addressing -- or more specifically, the way way applications interact with Internet addressing. (This will no doubt invite flames from those outraged at the idea that there might be a fundamental problem/mistake in the Internet.)
More specifically, what happens when you have multiple machines behind the NAT device? How do you map the ports statically to multiple machines *and* also communicate this information to devices on the outside of the NAT device? (That is, port 80 on the NAT device maps to server1, port 81 on the NAT device maps to server2, etc.)
The key issue is that applications are using network level addressing (IP addresses) rather than application level addresses (URLs) to establish the network connection -- we have network specific information far too embedded in the applications, which is why the transition from IPv4 to IPv6 is such a nuisance. At the moment, the DNS SRV record could help with some of these matters by specifying a port number to use for a specific service and host/domain.
A better design for applications would be for them to be completely unaware of 'IP addresses' and function purely on URLs or hostnames + service name, and link to libraries or network drivers on the machine that handle the network aspects. Really -- excepting network mangement tools, what application bothers about the MAC addresses of machines or PPP negotiation details? IP addresses should not matter to the applications, either -- at that point, much of the arguments against NAT go away.
Honestly, the fact that NAT causes applications to break is more a reflection on mistakes in the architecture/application. IP packets themselves don't fall over and die just because they transition from a PPP link to wireless to ethernet to SONET to etc. The differing layers are independent of one another -- the applications have not yet been weaned off directly diddling with the IP layer.
Another good book to read for this situation is:
"Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects"
by Edward Yourdon
I do not think I have seen this posted on Slashdot yet, but then I might have just missed it:
Pirate of Penguinance
Just a bit more humor on the situation.
To be honest, it's hard to say what the payoff is... yet. It's hard to make direct comparisons.
... the VoIP traffic separated from best effort traffic.)" -- instead of running two parallel networks (SS7+IP), you are now looking at running two parellel networks (IP (VoIP) + IP (data)) -- which is what is happening now with most of the carriers running a separate, private IP backbone for their voice traffic.
Keep in mind that in many, though not all, cases the 'cheaper' phone service over IP is also of less quality than the PSTN -- or less assured quality. (i.e. codec compression, lack of QoS guarantees, etc.) It's often easy to make a cheaper version of a product by lowering the standards. So, payoff for Sprint and other companies: more calls crammed into less bandwidth over trunk lines giving more efficient use of bandwidth maybe without any 'noticeable' (to most people) sound quality degredation from the extra compression.
Keep in mind that as you said, "Though to run a voice network
Insofar as expensive telco switching equipment goes... a lot of that has been paid for. The IP softswitch market just about died last year (I used to work at a company on a softswitch -- laid off because no one buying them.) When you have a *paid off* 5ESS that has a 99.999% uptime/reliability sitting in the CO quietly making you money, you don't just toss it out the window and go take out loans to buy a whole new set of VoIP gear, train people in new tech, replace everything, etc. Now, for a new phone company or a start-up or CLEC, the VoIP gear is a cheaper route to start up with. Mass replacement of old telco equipment is not likely -- a gradual migration is more likely.
Also, VoIP has a lot of regulatory hurdles left to jump, and some of them are whoppers. Probably the trickiest is a secure, reliable location service for 911 emergency calls. (Note that many countries have their own SS7 variants for call signalling, in many cases often due to local laws/regulations requiring that calls be handled in a certain way. Unless those laws are relaxed for VoIP, it is going to be quite a nuisance to implement.) (i.e. phone calls made from a prison are/can be handled differently than calls made from a pay phone or from calls made from a home phone) This isn't saying that it can't be done, or won't be done, just that at the end of the day, moving everything onto VoIP may not be as cheap as people expected (if it's cheap at all.)
Long term, it's really hard to say. Production on old-style telco gear has started to wind down, if not stopped, so the only way forward is through next-gen products. However...
IPv6 is going to suck, bandwidth utilitization wise, for VoIP calls, because VoIP data packets need to be small -- people might be looking at 30% to 50% IP header bandwidth "tax" -- that 10% ATM cell head "tax" might suddenly start to look better (because ATM was designed with voice in mind more so than data.) Seeing what happens with that will be interesting -- bandwidth may be cheap enough by the time IPv6 hits that it doesn't matter, but we'll see.
(Presonally, I can only hope SIP 2.0 dies a long overdue death and is replaced by a better excuse for a VoIP signalling protocol.)
Probably little to do at this point but kick back and see what actually survives in the real world.
Try this link for an artificially constructed language to see what I was referring to:
http://www.medianet.pl/~andrew/l/ebubo.htm
It's very regular, very logically designed, and a single mis-typed character can still yield a valid word -- no way of error detection (i.e. in English, I can type "the color bluu", "the color bleu", "the color "bluo", "the color blu", and people can probably guess what I mean. In Ebubo, "awa" (green) and "awe" (cyan) and "awi" "red" have no such distinctive differences. If I were to refer to the color "aw_", there is no way to guess what I was referring to.)
And of course, there's LogLan (i.e. LOGical LANguage).
For artifical languages in general:
http://www.langmaker.com/mlindex.htm
I can't off-hand find the paper which discusses the problem of artificial 'logical' languages having problems with error correction/noise, unfortunately. It's probably linked somewhere on langmaker.com, though, which is a fascinating site in itself.
After looking at some of the sample gestures for the keyboard, I have to admit I am somewhat impressed. Some very interesting ideas there. After looking at more of the sample gestures for the touch keyboard, I am still impressed, but wary.
It reminds me of the problems with 'logically designed languages'. (i.e. all words for colors in the language might start with "cro", "crob" is blue, "crog" is green, "cror" is red, etc. The problem being that a single typos in the word might still be a valid word of a similiar type, but not what you meant.) I suspect someone who became a total expert with the keyboard could do just fine, but an intermediate user could get highly frustrated -- forgetting to use/accidently using an extra finger in a gesture might cause some unwanted operation to happen, not merely cause the desired operation to not happen. Maybe the software is smart enough to second guess some of these issues, but...
Go to the company's page and look at the Enhanced Modifier Chords -- if you tap with six fingers on the home row, you get an Enter -- if you tap six fingers on the row above the home row, you get an Esc key press. (Personally, I would immediately redefine those two gestures to have far more difference between the two -- accidently hitting "Enter" when one meant "Escape" in some dialog boxes would be very bad.) Or the shift/control differences.
Of course, one could just not use the gestures, but then why bother with the keyboard?
Nonetheless, very interesting ideas, but it may not be ready for everyone.
If you have only a mesh of six or two T1s, then sure, maybe replacing all those T1s with pairs of T1s or fractional T3s and replacing all the routers with new ones to handle the new bandwidth might be cheaper than playing around with complex protocol design.
But if you have a nation wide network with literally hundreds of network links and hundreds of routers, just 'expanding the pipes' becomes a nightmare operations issue.
Consider the phrase "compound interest". With a small amount, in the short term, it's not that impressive. With a large amount, in the long term, it can yield some pretty impressive returns. Just "expanding the pipe" is the same thing -- works fine in the short term, on small networks. Over the long term, it gets exponentially more cost-complex.
(It should be noted that the human race is running around building such things as the Internet precisely because it didn't "add more muscle" or "add more speed" or "add more armor", but because it figured out how to use what it had more intelligently than its competitors. At some point you have to start using your brain.)
The bigger question is, how do you appeal?
Suppose they remove your US citizenship. How do you get a lawyer to represent you? Can you even be represented in a US court? Do they purge your social security number/tax ID? If so, what happens to your bank accounts and property?
Suppose somehow you convince them that it was a mistake -- how do you get your citizenship *back*? What if took months to accomplish and records were purged by various institutions. Do you get your old social security number back, do you get a new one? How would one recover for that?
This is probably the most scary thing here. If they can arbitrarily declare someone a non-citizen and shutdown that person's access to bank accounts (frozen for investigation), work (no longer a US citizen eligible for work), property (siezed for investigation), transportation (no drivers' license -- not a US citizen), and legal representation (good luck finding some without work, money, a car, or a house), what can one do to protest that after the fact? Even if you managed to successfully get your citizenship back, by then, your government confiscated property might have been sold to someone else (nice potential scam for someone there.)
Isn't it, though? The real 'hack' is replacing IPv4 with IPv6 to 'fix' a problem which is really in the directory services/DNS level. People think that some how static IP addresses will magically make things better, but that's only because they are changing the network protocol to fix a problem in the application layer (i.e. name look-ups).
A better solution would be to fix the directory services at that layer so that IP addresses were not used inside applications. That would also make a transition between IPv4 and IPv6 easier if the applications got their out from being too deep into the network directly. (I.e. get rid of fixed port numbers for specific services, use the equivalent of SRV records or such to let the network layer figure out which port and IP address to send the packets to -- by allowing ports to be looked up as well as IP addresses, that would allow mulitple servers behind NAT behind static port mappings.)
NAT has no effect on transport. You put data in, you get data out. The only reason that NAT seems like a 'hack' is because of bad coding design that has integrated far too much transport-level network information into the applications. If applications and name-look up were written properly, not only would switching applications to IPv6 be trivial because of less internal code dependence on IPv4 rather than a generic network/transport API, but NAT wouldn't be a problem, either.
The static IPv6 address auto-assignment is going to be fun to watch. Suppose the network admin doesn't do DHCP, and just lets all hosts auto-configure. Now, there are a couple things that happen -- the hosts choose random host network values -- makes no sense because the whole point of this is to have a static IPv6 address, right? So, host ABC always chooses the same host part of his IPv6 address (perhaps from his MAC address, which now gives his computer the equivalent of the Intel CPU serial ID number), or some other fixed value. What stops someone else from trying to swipe that same value on the network? Your computer reboots, and when it comes on, there is another host claiming to have that MAC/host address on the network already -- so much for that static IPv6 address. No smart network administrator is going stick their hands into that one -- either things will be dynamically autoconfiguring, and static IPc6 addresses may or may not happen depending on your luck and your neighbors, or the admin is going to assign the addresses specifically rather than letting the network autoconfig.
The above reply should definitely be modded up.
While an interesting article, it would seem to imply that being able to use a FAX machine at, say, Kinko's should not be possible because people would just have bought their own FAX machines. For a business that sends many FAX machines, buying and maintaining their own FAX machine as opposed to using some one else's may make sense. For personal use, it may not be worth the investment. The article does not seem to take that sort of market segmentation into account.
For example, if one assumes that if you use a phone service heavily and that you can provide it for yourself at a cheaper cost for bulk usage, you would. Businesses already do that for themselves with PBX systems (IP-based or not) -- in a sense, what the article is predicting has already happened, but only as far as the heavy users (i.e. businesses) are concerned.
If one assumes the FAX analogy as gospel, then... nothing will really change. Kinko's and other places will provide FAX services to the consumers that cannot afford or are not interested in buying and operating a FAX machine for casual use. Saying that the next generation of VoIP (bah) products will cause people to stop buying services from the phone companies seems likely to follow the same pattern. For the services which are labelled 'too expensive'... how many people actually use those services? Frequently? Enough to justify the expenditure in setting up and running the services on their own? Maybe the services just aren't worth it, whether provided by the phone companies or by one's self -- perhaps that will be the common sense of the consumer, that maybe some of these 'services' offered by the phone companies, or the new next generation ones hyped by VoIP just aren't worth the money.
Does not the current IPv6 address allocation standard specify using your MAC address as the suffix portion of the IPv6 address? This is merely a taste of things to come if/when IPv6 becomes widely deployed, when your very IPv6 address can uniquely identify the hardware you are on (unless you use IPv6 NAT, of course.)
And yes, presently, you can probably change the MAC address of your system. However, once software vendors and DRM technologies and other things start locking themselves to your computer hardware, I suspect changing the MAC address would cause problems. The only thing this game company has to do is when the game is installed is to lock the licence to the present MAC address so it will not run with a changed IP address without a new licence.
How do you connect an IPv4 network to an IPv6 network without doing Network Address Translation to convert the IPv6 address into some IPv4 address the IPv4 network can handle? You need NAT between the two at least in order to transition from an IPv4 network to an IPv6 network. Of course, if applications break because they have not been properly written to deal with NAT, then they won't work across IPv6 and IPv4 network boundries.
So, if there is no NAT, what good is an IPv6 address? Until the rest of the Internet is converted over to IPv6, it's not going to be able to connect to much that is currently out there. This is not going to encourage most people to convert to IPv6 -- if applications are going to break if you don't have an IPv4 address, so you need to have one anyways, why bother with the IPv6 address at all? Just stay with the IPv4 one.
Neither the DNS system (root servers), or the allocation/control of IP address(ing) is decentralized -- they may be heirarchial, but both still have a root.
It will be interesting to see if IPv6 will use geographic hierarchies for routing, or even relaxes the hierarchial assignment-scheme at all. If your IPv6 suffix is static/fixed (based on your MAC address, say), and your IPv6 prefix is from the current network/area you are in, that will be an interesting tool to let people track devices as they move around/between networks.
Indeed. People seem to be rushing towards making everything networked purely a monoculture -- "Everything on IP".
Sigh.
Would I be wrong in assuming you feel that you could only run HTTP, SMTP, and such only on IP? If so, then there is not much point in discussing anything more.
Oh, for goodness' sake. You miss the point entirely.
What I said was that for a given URL, which may very well be <http://someplace.com/>, how can you tell if it was IP end to end? You can't. PERIOD. The network is a black box -- you send a stream of bits out, you get a stream of bits back which have only a casual relationship to one another. The back end of the black box could be a webserver farm on an IP network, a bunch of Macs connected on AppleTalk, servers on IPX, or an IBM mainframe. How the heck can you tell what it runs if it only exposes IP to you? It has total control over the stream of bits it sends. It could make a traceroute through its network look like it was going to the moon! And the same URL will work fine for everyone as long as they can reach the gateway or 'server' the URL points to, but it does not require IP end-to-end. If you keep explicit IP addresses out of URLs, then you can have hostname based virtual web hosting, mail domains, and so on.
The point is that by keeping the network address out of the URL, you can be more flexible in what the URL resolves to. Maybe it resolves to IPv6, or maybe it resolves to IPv4, depending on what your system supports -- that is a superior solution, isn't it? That's the problem with using IP addresses as resource specifiers -- it's an inferior solution.
You've confused a single network transport address space with a single application address space.
The value is in a single *directory* address space. Unfortunately, people use IP addresses to refer to resources, rather than, say, hostnames or something that is not bound directly to the network technology. This is precisely the sort of thing which hinders a transition to IPv6.
This is a far more practical and pragmatic engineering idea than tying applications to the network addressing. If you want every machine in the world to have a unique IPv4 address, you're walling yourself into IPv4 forever and ever. What you probably want is a unique identifier for each machine that does not bind you to a specific technology or transport.
Maybe a URL points directly to a machine on the Internet with a static IP address. Maybe it points to a machine behind a firewall with NAT. Maybe it points to an IPX machine on the otherside of a protocol coverter. If you can get the files via that URL, it shouldn't matter, should it? The problem is the current bad engineering practices that make the transport layer addressing entwined with the application layer resource addressing.
I don't care if the data flows over copper, fiber, or wireless, as long as the proper stream of bits get to the right place. Likewise, I shouldn't have to care if it is IP or anything else transporting the bits in particular.