Because there is a difference between spending the time and effort to build a computer that never crashes verses the time/effort to just reboot one.
When you get into the 99.999% or more range, you're basically doing everything you can to keep faults from happening in the first place -- and this is almost exactly the opposite of the Internet design philosophy, which assumes lost packets will be retransmitted, censorship/damage will be routed around, etc. It's a consumer technology -- cheap, low-cost, disposable (i.e. retransmit lost data, retry, reboot, etc.) -- which is why it has been successful in the consumer market. It is a "if something goes wrong, we'll kick it and try again" approach.
The alternative, making sure nothing goes wrong in the first place, starts getting into things like resource reservation. ("Hey, before I send this data over there, let's make sure there's room first, and reserve it, so I know my data will not get blocked/lost." vs. "I'll just send my data packets -- if I don't get a response, I'll just keep retransmitting until I do.")
People like the consumer approach because it lets them be lazy as well as cheap. The other approach scares people off because it starts sounding like a closed network/system, not to mention it puts responsibility on the users, which also scares them off.
(Hey, you want 99.999% uptime? Stop supporting a flat-rate bandwidth model, and start paying by data throughput. The old telecom industry *had* to keep the network up, because they were paid by the minute only while the calls could get through. Right now, if you pay an ISP $30 a month flat rate, it doesn't matter if the network is down for a day, the ISP still gets it's $1/day. Oh, you might get your $1 back if you get down and fight for a refund, but... If you paid per amount of data that got exchanged, and the ISP goes down for a day, it's lost a day of revenue the ISP never gets. Look at the market incentives the current pricing models put on the network providers and how it drives their focus. If you want cheap, flat-rate access, don't be surprised that you get cheap service, flat-rate customer service (i.e. business hours only, not on-call, on-demand, etc.).)
Am I the only one who sees the irony that the response to this censorship/filtering attempt is to... censor/filter the AS/routes of the ISP responsible for it?
What was the saying? "A man with one clock always knows what time it is -- a man with two clocks is never sure"?
I suppose if every one of these systems provides a precise enough location, for most purposes it won't matter if they all conflict with one another by a meter or so.
You missed the part where I referred to website certificates. If someone has to change providers and SSL/TLS certificates are bound to the IP address and therefore to the ISP, then that means a whole new round of certificate creating and revocation. Keep in mind that any internal network security services that were based on IP addresses would also have to change. (i.e. Using SSH between machines.)
I'm considering the security and management issues someone like google.com or amazon.com would face if they got stuck with provider-based IP addresses -- these are exactly the types of places who would want to have multi-homing for redundancy and load management reasons.
You're not convincing me that IPv6 addresses would be 'easy' to switch between providers across an office campus with a couple thousand machines and internal network security and internal firewalls and internal website certificates, etc. Not to mention the 'old' addresses would suddenly available to someone else to use which would require extremely tight security practices to prevent that from becoming a security issue.
So, are there going to be ISP-independent addresses in IPv6, or not? If not, no multi-homing, and hello captive market. If every one of a company's website certificates for online business get stuck bound to non-telecom independent addresses, monopolies are going to flourish because the barriers to switching will be huge.
So, we're losing a nice feature of IPv4 networking -- multi-homing, with automatic live redundancy through multiple providers -- and we're getting told it will be easier to change IP addresses across the network instead? Please, at least tell me all the IPSEC and/or HTTPS still works if you reconfigure the IP addresses like this, otherwise, this new 'feature' is going to be almost worthless.
This is not an improvement.
Does IPv6 == telecom monopoly still?
on
IPv6 Essentials
·
· Score: 1
It's been a while since I've bothered to look at IPv6 -- so, did folks ever work out the multi-homing issues with IPv6, so that companies (like, say the current favorite, Google,) could have multiple simultaneous connections with multiple backbone providers?
(This seemed problematic for a while due to the hierarchial nature of the IPv6 address space forcing a tree-like structure into the routing and preventing the possiblities of having links between branches.)
If you only have a hammer -
on
Own the Last Mile
·
· Score: 3, Interesting
If you ask techies about the issue, they suggest more/bigger/better technology. If you ask business folks about the issue, they suggest pricing and features and rates. If you ask legistlators about the issue, they suggest regulation.
This isn't exactly any of those as much as PEBCAK. We're leaving the world of computer-to-computer communications behind and it's becoming one of people-using-computers-to-other-people-using-compu ters communication.
Let me see if I can offer some food for thought --
Within the realm of automobiles and driving, a driver has immediate feedback from how s/he is driving, can see other drivers and how they are driving, has turn signals, horns, and can also see things like traffic jams, ambulances, etc. Even outside of any legal regulations, a given area can develop certain common behaviors among drivers because they will learn from each other, consciously or not, purposeful or not, about what to do, what not to do.
Within the realm of net-usage, there is no feedback for the end users on whether or not how/when/what they are doing on the network is affecting anyone else or what is going on. It's like everyone is driving bumper cars without vision, hearing, or any sort of feedback, and the only control is the gas pedal. You just floor it and hope you bounce around to where you want to go. Maybe you do, maybe you don't.
Without any sort of feedback, no 'rules of the road' or such things like "slower traffic keep right" (for US drivers) can develop. The users can't tell what's going on and adjust. So, various parties are trying to 'help' the users:
Business: "We will make separate lanes for separate speeds, and people will pay for the speeds they want."
Techies: "We don't want separate lanes - we will make the roads bigger until the problem goes away! Or make roads so cheap the users can have their own!"
Government: "We will regulate the roads to keep the users safe from one another."
In all cases, third parties are trying to 'help' the average user because each of them think they know best. Whether or not any of them actually do know best is a secondary issue to the one that each of them probably does know *more* than the average user about what is going on.
If every user had some sort of feedback as to how they were affecting other users, then I suspect that in most cases the users would manage to work things out one way or the other among themselves. Because the user base cannot, everyone is suggesting solutions to take care of the problem without seeking real input from the major stakeholders -- the users, who are simultaneously the source of the problems from their usage of the network taken as a whole.
Regardless of solution chosen or what actually happens, the lack of feedback to the users and user controls (outside of, say, trying to force a web page to (re)load) would suggest that none of the solutions will truly solve the PEBCAK issue because there's no way to really involve the users as a whole in any of the solutions... or, if you will, we tend to call them 'network users', not, say 'network citizens'. (Heck, few ever refer to them as 'people', they're just faceless 'users'.)
'Citizen' suggests a level of responsiblity and participation within the overall process that is not currently possible because they have been insulated from almost all useful feedback about the results of their own behaviors, so they cannot learn/adapt/take responsibility on their own. So various people (techies, businesses, governments) try to help do it for them. Empowering the people doesn't work because without the feedback they can't learn how to treat the extra power to get along with each other. Charging the people more doesn't work because without feedback people can't easily tell if they're getting what they're paying for. Adding more laws doesn't work, because without feedback people can't tell what they're doing at all, never mind if they're doing something wrong.
As such, I find most of the suggestions from various talking-heads well-meaning but tiresome.
Unfortunately, the unique-address-for-everything zealots have been buggering up the application protocols in the meantime and passing raw IP addresses around: just when you thought passive mode in FTP had fixed that application, some idiot makes exactly the same mistake in SIP.
You said it. Doing SIP from an IPv6 to an IPv4 address is going to be a blasted pain when the IPv6 host sticks raw IPv6 addresses in the SIP message all over the place. Especially when the dead-end-to-dead-enders insist that intermediary proxies should not fiddle with SDP contents.
A lot of folks have confused identifying a service (say, a webserver) with a network identity (IP and port number). (We realllly need to get off this port number == service crud.)
It's the dead-end-to-dead-end architecture mindset at work. Mandating an end-to-end design excludes all other protocols -- including any successors or improvements. Only those egotistical enough to think they'd join the immortals, as you'd put it, would design yet another dead-end -- they would have to believe that IPv6 really would be the end-all-be-all. Anyone who considered that there might be something *after* IPv6 would realize that if you didn't break the end-to-end design and acknowledge that you might have to have a protocol converter in there... well, if you thought the IPv4 to IPv6 conversion is a joke, can you imaging the IPv6 to IPvX conversion, when the network is an order of magnitude larger than this, and people are still cheerfully putting raw IPv6 addresses in their applications, because dead-end-to-dead-end design is so cool?
I suspect the question is not whether the track record of customized-in-house software is bad, but what the track record of companies who do not have good software development skills/project management/methodologies is bad. (i.e. it's not the end product, it's the costs/delays/screwups in trying to get there.)
It sounds like there could be a third branch here between just buying COTS and trying to development something yourself -- work with a consulting company to develop a customized solution for/with you. That is, rent/acquire the necessary software development expertise/experience needed to get a properly done custom solution.
Actually, there was a lot of talk about doing an XML encoding for SIP. (Actually, I think the next-gen SDP specification is in XML.) However, to the best of my recollection, that idea triggered lots of religious schisms and convulsions among the SIP faithful.
I'd go with Jabber and enhance it with some voice signalling specific tweaks/messages, probably, before trying to convince the SIP True Believers about doing an XML conversion.
The audience here is also system and network admins. Setting up SIP may be about as hard as setting up SMTP/POP service (if I can decode your syntax properly), but diagnosing, debugging, and maintaining SIP is far, far harder and less forgiving with the current state of things. It's one thing to 'take it for a ride' for yourself or friend or for an ISP, it's another thing to 'clean up after it, keep it secure, keep it running month after month, and do tech support' for yourself or your friends or an ISP.
The Session Initiation Protocol enables just about anybody with little resources to become their own Real-Time Communications Giant.
And anyone with a hoe and a little water can become a Real Farming Industry Giant! Or, If You Have A Few Bucks, You Can Buy This Bridge I Can Sell You.
The... protocol (sic) does not function as a magic bullet. Just waving the SIP spec at a traditional telcom does not knock them over. (Okay, throwing the entire printed version of all the SIP specs might...) This isn't about anyone with just 'a little resources', this is about people with resources, a lot of technical know-how (SIP is easy only in the sunny day cases), and LOTS OF TIME.
Beyond basing a standard for managing stateful telecommunications sessions on a protocol for stateless bulk data transport, the most blatant silliness in the SIP standard was the original "Alert-Info" header. The Alert-Info header allowed the calling party to specify the ring tone/sound by listing a URL that the receiving device would automatically attempt to fetch and play without waiting on the recipient user to allow/disallow it.
Yes, I just picked up a Fujitsu Stylistic ST5020D a couple of weeks ago to use with Corel Painter IX as a portable digital drawing/painting device.
It's rather nifty. While the handwriting recognition and writing by hand is slower than typing, typing requires both hands and place to put the keyboard whereas with the tablet one can hold the tablet with one hand and write with the other.
Some interesting synchronization/race condition issues just waiting to be found, one suspects, when there are parts of your computer not bounded by speed of light considerations, and parts that are, as well as deterministic parts and quantum parts.
You might want to double check on liability issues. Depending on the exact nature of the business involved, there could be legal issues.
(I.e. if the work involves things like medical or other private information, working on/transmitting those over 'personal' equipment or an ad-hoc telecommuting arrangement may be a legal no-no.)
say you've 2 webservers behind NAT. you can't run them both on port 80 as the port forwarding has to go to one IP address or the other. or if you have 2 apps that use an overlapping port range - big problems.
This problem almost has to get solved regardless for IPv6/IPv4 NAT, if you plan to have legacy IPv4 network devices interoperate with new IPv6 ones. This is probably the most interesting challenge to IPv6 deployment -- if people can solve the interoperability problems between IPv6 and IPv4 to encourage people to start to deploy IPv6 in an IPv4 based world, you solve the interoperability problems between IPv4 NAT'd networks... which would tend to give people even less reason to upgrade to IPv6.
Sigh. You're being very closed minded. Also, you seem to acknowledge that less dependency is a good idea, but then go "Well, this is too hard, so I'm not going to think about how to make things better."
Look, here is how it works.
The applications uses "http://slashdot.org/". That is *ALL* it uses.
When it wants to open up a network connection, it passes the URL to the operating system network stack and gets back, oh, say a socket descriptor. The network stack may *internally* turn this into an IP address (or a MAC address, a GSM cell number, IPv4, IPv6, *whatever*) but since the application is protected from that by only having the socket descriptor as an interface, the application remains independent of whatever happens in the network layer. At this point, the application doesn't care if the URL happens to resolve to an IPv6 address or an IPv4 address or whatever.
Here's a more complex scenario:
User A turns on his network device.
The network device broadcasts on the default network medium a request for a network level address and the address of a router (MAC/DHCP)
The device then sends to the router "I am device "device12.user-a.domain.com", this is my encrypted authentication to use this hostname. Please allow incoming web services and telnet services."
The local router forwards this to the next router up until it reaches a (potentially one of many) global network space. Then the DNS server for "user-a.domain.com" is contacted and the router tells it "A device behind me is requesting to use "device12.user-a.domain.com" with these services. I am "router-1.network.net", this is my authentication information for my hostname. This is the authentication information the device gave me to use the hostname and services it requested. This is the network address for these services." The network address could be a set of IP addresses and ports, but that specific IP addresses and ports are only known to the routers and the DNS servers.
The DNS server accepts the entry, and associates the new network addresses with "device12.user-a.domain.com."
Someone attempts to access "http://device12.user-a.domain.com". Their application passes the URL to the network stack. The network stack sends a look up query on the local network to the router "I need to talk to device12.user-a.domain.com with http". The router forwards the request up its router chain until it finds a global address space that can resolve "device12.user-a.domain.com", where the DNS server hands back a network address which is valid (only) in the global context, saying that at the moment, here is where the service is located.
The connection is made from router to router, though more in the style of switching than routing. As such, it can be NAT all the way, every hop if need be. (The end point requests from router-a a connection to a given URL. router-a says "use address-a:port-a on our shared network". *HOWEVER*, when router-a talks to router-b and says it needs to reach that URL, router-b might say "use address-b:port-b on our shared network." When router-b talks to router-c... etc.
At this point, the networks are separated and independent of one another in terms of protocol and address space (you could be running IPv4 to IPv6 to ATM to IPv4 to IPv6 without any network knowing about it) and the applications are protected from the changes as well. You even solve the damned roaming problem. (Say device-a was connected to the router "point-1.coffeeshop.com", and the DNS entries for the device now pointed to coffeeshop.com's external router. device-a roams from point-1.coffeeshop.com to point-2.coffeeshop.com. The local router(s) inside coffeeshop.com just have to do an internal update to the local NAT to route the traffic to device-a, but since the *external* address, as far as the world is concerned, has not changed (due to NAT), from the external world, no loss of connection has happened. Tweak device-a's n
First off, the internet was BUILT as an end-to-end network. You cannot just sweep this fact aside by saying it's "outdated". This principle is what MADE the internet successful. Without end-to-end, the internet would have gone nowhere. Really.
Rebuttal: First off, the initial gun powder weapons were BUILT as muzzle loading, single shot weapons. I can certainly sweep this fact aside as "outdated". This does not say that the black powder weapons were NOT successful in their time, but now, they would not go anywhere. Really.
But now, in the new system, it requires that the network be AWARE of the application, and configured EXPLICITLY to allow this certain type of data to be transferred.
Well, duh. What else do you call a firewall?
Now you have to ask permission from the people who control the network to run your application.
Well, duh. Ever looked at your Terms of Service agreement? Look closely at the your own statement! "Ask permission from people who CONTROL the network" -- they control it, it isn't YOUR network.
So far, you seem to be building a spammers haven -- no filtering, and no one who can tell a spammer not to run their spamming applications.
Now you have to make configuration changes in the network itself before you can run any new application. Gone is the open development environment of the internet. Gone are new applications that pop up that anyone can use immediately. (This is how the web started. Your NAT support would have made the web so difficult that it wouldn't have gone anywhere. Imagine the millions who would have had to configure their NAT to work with a new system of doubious worth.)
Great. Tell me how to access an IPv6 server from an IPv4 application. Wow! Looks like we need NAT before we can have all these new applications.
AND IT IS! That's the POINT, Bookwyrm. Currently, in the 'obsolete' model, the network is TRANSPARENT to the application. No specific configuration of the network is requried. The network is seperate from the application.
Bull. The application is aware of IPv4 addresses, therefore it is not separate from the network layer.
However, NAT makes the application depend on the network, and thus makes the network and the application once again joined, like the telegraph, phone and cable TV networks of the past. That's a step BACKWARDS.
NAT does NOT make the application dependent on the network. The application was ALREADY dependent on the network. If it wasn't dependent on the network, changing the network would not break the application.
Silly.
IP addresses have no place in the application layer. You can't say that the network is transparent to the application, because if the network was transparent to the application, the application would not break because of NAT! NAT breaks the applications because the applications are dependent on the configuration of the network.
If the applications were not dependent on the network configuration, then I should be able to run the same application across a Bluetooth conneciton, ethernet, GSM, and ATM, without changing one aspect of the application. Instead, all these applications *NEED* IPv4, they are *DEPENDENT* on IPv4 being configured without NAT. They require knowledge of IPv4 address space -- they break with IPv6 addresses.
This is NOT transparency. This is dependency, addiction.
End-to-end addressing the best idea? Great! Let's use MAC addresses instead of IP addresses! Heaven forbid we translate or map IP addresses to MAC address on ethernet! Goodness, those folks who developed ethernet much have been a bunch of idiots then, right, to require another level of translation and mapping? Even if it does allow for people to use IPv4 and IPv6 over top the same med
Bluntly speaking, yes, all VoIP and H323 software is obsolete for these reasons.
People are confusing "end to end" applications with "end to end" mechanisms.
When the telegraph was the latest technology, the 'application' and the 'mechanism' were practically identical -- pulses of electricity sent over a wire. Same with the initial voice and phone system. Over time, though, people started separating the 'application' (voice/information transmission) from the 'mechanism' (eletrical patterns on the wire.) Separating the two layers, now we have the ability to place phone calls that are digitized, sent over wires, over fiber, over radio waves, and coverted back to voice. The application (voice) is still end to end, but the mechanism isn't.
Many protocols today are obsolete because people have and still confuse the 'application' (voice, web access, email) with the 'mechanism' (associated protocols bound to IPv4). We want the application to run end-to-end, because that is what make the application useful -- but folks have confused this with requiring the mechanism to be identical from end to end -- IPv4 without NAT, all the way! That is like saying we should only over end to end copper, with no fiber in between.
End-to-end IPv4 (no NAT) used to be the application -- like in the days of the telegraph, the mechanism and the application were synonymous. That is an obsolete model, though. Our needs and demands have gotten more varied and complex from the point of view of the applications -- the mechanism (IPv4) needs to be separated out from the applications.
Imagine if you could not translate digital information from electronic pulses to optical ones. In order to replace a copper network with a fiber one, you'd have to replace the entire thing at once -- regardless of whether or not that made sense. Fortunately, because we can translate and manipulate the mechanisms, we can use a mix of technologies and capacities and do gradual upgrades and best-fit uses of technology without breaking anything. If people wrote their network protocols and applications *properly*, in a non-obsolete fashion, then the transition to IPv6 would be fairly painless and quick. However, the insistance on end-to-end mechanisms is locking us into IPv4 and makes the upgrade to IPv6 very painful.
Geeze. Isn't it obvious that *mandatory* end-to-end anything is a disaster waiting to happen? If end-to-end lock-in is a good model, why the complaints when companies like Microsoft or such try to make people use nothing but Microsoft products 'end-to-end'? Whenever that happens, people start shouting about open interfaces and needing interoperability between different vendors and products. Yet when it comes down to IPv4, people fall down on their knees and worship the way things have been (badly) designed to *require* end-to-end IPv4. (That is, end-to-end conformity is not a bad thing in and of itself, but the requiring of it is a lock-in that inhibits change and growth, as well as competition.) Modularity, anyone? What next, going to propose that electricty only be made and transmitted as 120V AC end to end, and you can't transform it into DC current or anything else because it breaks the end to end model?
Think a bit more, folks. End-to-end uniformity, conformity, blandness is all well and good, but much of the advancement in technology and industry comes from having standardized *interfaces* and *translations* that allow us to interconnect different mechanisms together to make more interesting things. (No IPv4 is not a standardized *interface* when it is coupled with the requirement to be end-to-end. A good interface should hide the implementation details both sides. The end-to-end requirement violates the hiding principle.)
An interesting problem with this is that the virtual world property now has real world cash-value. If Second Life 'pays' me in virtual money, which I can convert to real dollars, is this a form of employment? If I make a thousand dollars from selling things, will the IRS start hounding me? If some one steals a virtual object from me, can I have them arrested if I can show a monetary loss? As long as it is all play money, there were fewer issues -- but now that they are bringing in real money... well, lots of people and organizations interested in that, for better or worse.
I am rather surprised at the commentary so far on this device, given the usual tone of responses made on slashdot that I have seen.
This device appears to be, at heart, a box that is put in along side the routers to filter out content that the owner of the device does not want to be sent over the network. It is capable of looking for specific patterns of data and blocking the transfer of the data based on that in real time.
Is this not precisely what one would use to filter out, say, unwanted political documents going in/out of China? To, say, spot a specific MP3 file being traded on a P2P network and stop it?
Other comments seem to suggest people think this might actually be a workable, good idea -- guess folks are finally realizing that the Internet cannot route around all forms of censorship after all, if they think this will work.
Slashdot Mirror
Presumably, IPv6 will itself eventually be replaced by something better.
Because there is a difference between spending the time and effort to build a computer that never crashes verses the time/effort to just reboot one.
When you get into the 99.999% or more range, you're basically doing everything you can to keep faults from happening in the first place -- and this is almost exactly the opposite of the Internet design philosophy, which assumes lost packets will be retransmitted, censorship/damage will be routed around, etc. It's a consumer technology -- cheap, low-cost, disposable (i.e. retransmit lost data, retry, reboot, etc.) -- which is why it has been successful in the consumer market. It is a "if something goes wrong, we'll kick it and try again" approach.
The alternative, making sure nothing goes wrong in the first place, starts getting into things like resource reservation. ("Hey, before I send this data over there, let's make sure there's room first, and reserve it, so I know my data will not get blocked/lost." vs. "I'll just send my data packets -- if I don't get a response, I'll just keep retransmitting until I do.")
People like the consumer approach because it lets them be lazy as well as cheap. The other approach scares people off because it starts sounding like a closed network/system, not to mention it puts responsibility on the users, which also scares them off.
(Hey, you want 99.999% uptime? Stop supporting a flat-rate bandwidth model, and start paying by data throughput. The old telecom industry *had* to keep the network up, because they were paid by the minute only while the calls could get through. Right now, if you pay an ISP $30 a month flat rate, it doesn't matter if the network is down for a day, the ISP still gets it's $1/day. Oh, you might get your $1 back if you get down and fight for a refund, but... If you paid per amount of data that got exchanged, and the ISP goes down for a day, it's lost a day of revenue the ISP never gets. Look at the market incentives the current pricing models put on the network providers and how it drives their focus. If you want cheap, flat-rate access, don't be surprised that you get cheap service, flat-rate customer service (i.e. business hours only, not on-call, on-demand, etc.).)
Am I the only one who sees the irony that the response to this censorship/filtering attempt is to... censor/filter the AS/routes of the ISP responsible for it?
What was the saying? "A man with one clock always knows what time it is -- a man with two clocks is never sure"?
I suppose if every one of these systems provides a precise enough location, for most purposes it won't matter if they all conflict with one another by a meter or so.
You missed the part where I referred to website certificates. If someone has to change providers and SSL/TLS certificates are bound to the IP address and therefore to the ISP, then that means a whole new round of certificate creating and revocation. Keep in mind that any internal network security services that were based on IP addresses would also have to change. (i.e. Using SSH between machines.)
I'm considering the security and management issues someone like google.com or amazon.com would face if they got stuck with provider-based IP addresses -- these are exactly the types of places who would want to have multi-homing for redundancy and load management reasons.
You're not convincing me that IPv6 addresses would be 'easy' to switch between providers across an office campus with a couple thousand machines and internal network security and internal firewalls and internal website certificates, etc. Not to mention the 'old' addresses would suddenly available to someone else to use which would require extremely tight security practices to prevent that from becoming a security issue.
So, are there going to be ISP-independent addresses in IPv6, or not? If not, no multi-homing, and hello captive market. If every one of a company's website certificates for online business get stuck bound to non-telecom independent addresses, monopolies are going to flourish because the barriers to switching will be huge.
So, we're losing a nice feature of IPv4 networking -- multi-homing, with automatic live redundancy through multiple providers -- and we're getting told it will be easier to change IP addresses across the network instead? Please, at least tell me all the IPSEC and/or HTTPS still works if you reconfigure the IP addresses like this, otherwise, this new 'feature' is going to be almost worthless.
This is not an improvement.
It's been a while since I've bothered to look at IPv6 -- so, did folks ever work out the multi-homing issues with IPv6, so that companies (like, say the current favorite, Google,) could have multiple simultaneous connections with multiple backbone providers?
(This seemed problematic for a while due to the hierarchial nature of the IPv6 address space forcing a tree-like structure into the routing and preventing the possiblities of having links between branches.)
If you ask techies about the issue, they suggest more/bigger/better technology. If you ask business folks about the issue, they suggest pricing and features and rates. If you ask legistlators about the issue, they suggest regulation.
u ters communication.
This isn't exactly any of those as much as PEBCAK. We're leaving the world of computer-to-computer communications behind and it's becoming one of people-using-computers-to-other-people-using-comp
Let me see if I can offer some food for thought --
Within the realm of automobiles and driving, a driver has immediate feedback from how s/he is driving, can see other drivers and how they are driving, has turn signals, horns, and can also see things like traffic jams, ambulances, etc. Even outside of any legal regulations, a given area can develop certain common behaviors among drivers because they will learn from each other, consciously or not, purposeful or not, about what to do, what not to do.
Within the realm of net-usage, there is no feedback for the end users on whether or not how/when/what they are doing on the network is affecting anyone else or what is going on. It's like everyone is driving bumper cars without vision, hearing, or any sort of feedback, and the only control is the gas pedal. You just floor it and hope you bounce around to where you want to go. Maybe you do, maybe you don't.
Without any sort of feedback, no 'rules of the road' or such things like "slower traffic keep right" (for US drivers) can develop. The users can't tell what's going on and adjust. So, various parties are trying to 'help' the users:
Business: "We will make separate lanes for separate speeds, and people will pay for the speeds they want."
Techies: "We don't want separate lanes - we will make the roads bigger until the problem goes away! Or make roads so cheap the users can have their own!"
Government: "We will regulate the roads to keep the users safe from one another."
In all cases, third parties are trying to 'help' the average user because each of them think they know best. Whether or not any of them actually do know best is a secondary issue to the one that each of them probably does know *more* than the average user about what is going on.
If every user had some sort of feedback as to how they were affecting other users, then I suspect that in most cases the users would manage to work things out one way or the other among themselves. Because the user base cannot, everyone is suggesting solutions to take care of the problem without seeking real input from the major stakeholders -- the users, who are simultaneously the source of the problems from their usage of the network taken as a whole.
Regardless of solution chosen or what actually happens, the lack of feedback to the users and user controls (outside of, say, trying to force a web page to (re)load) would suggest that none of the solutions will truly solve the PEBCAK issue because there's no way to really involve the users as a whole in any of the solutions... or, if you will, we tend to call them 'network users', not, say 'network citizens'. (Heck, few ever refer to them as 'people', they're just faceless 'users'.)
'Citizen' suggests a level of responsiblity and participation within the overall process that is not currently possible because they have been insulated from almost all useful feedback about the results of their own behaviors, so they cannot learn/adapt/take responsibility on their own. So various people (techies, businesses, governments) try to help do it for them. Empowering the people doesn't work because without the feedback they can't learn how to treat the extra power to get along with each other. Charging the people more doesn't work because without feedback people can't easily tell if they're getting what they're paying for. Adding more laws doesn't work, because without feedback people can't tell what they're doing at all, never mind if they're doing something wrong.
As such, I find most of the suggestions from various talking-heads well-meaning but tiresome.
You said it. Doing SIP from an IPv6 to an IPv4 address is going to be a blasted pain when the IPv6 host sticks raw IPv6 addresses in the SIP message all over the place. Especially when the dead-end-to-dead-enders insist that intermediary proxies should not fiddle with SDP contents.
A lot of folks have confused identifying a service (say, a webserver) with a network identity (IP and port number). (We realllly need to get off this port number == service crud.)
It's the dead-end-to-dead-end architecture mindset at work. Mandating an end-to-end design excludes all other protocols -- including any successors or improvements. Only those egotistical enough to think they'd join the immortals, as you'd put it, would design yet another dead-end -- they would have to believe that IPv6 really would be the end-all-be-all. Anyone who considered that there might be something *after* IPv6 would realize that if you didn't break the end-to-end design and acknowledge that you might have to have a protocol converter in there... well, if you thought the IPv4 to IPv6 conversion is a joke, can you imaging the IPv6 to IPvX conversion, when the network is an order of magnitude larger than this, and people are still cheerfully putting raw IPv6 addresses in their applications, because dead-end-to-dead-end design is so cool?
I suspect the question is not whether the track record of customized-in-house software is bad, but what the track record of companies who do not have good software development skills/project management/methodologies is bad. (i.e. it's not the end product, it's the costs/delays/screwups in trying to get there.)
It sounds like there could be a third branch here between just buying COTS and trying to development something yourself -- work with a consulting company to develop a customized solution for/with you. That is, rent/acquire the necessary software development expertise/experience needed to get a properly done custom solution.
Actually, there was a lot of talk about doing an XML encoding for SIP. (Actually, I think the next-gen SDP specification is in XML.) However, to the best of my recollection, that idea triggered lots of religious schisms and convulsions among the SIP faithful.
I'd go with Jabber and enhance it with some voice signalling specific tweaks/messages, probably, before trying to convince the SIP True Believers about doing an XML conversion.
The audience here is also system and network admins. Setting up SIP may be about as hard as setting up SMTP/POP service (if I can decode your syntax properly), but diagnosing, debugging, and maintaining SIP is far, far harder and less forgiving with the current state of things. It's one thing to 'take it for a ride' for yourself or friend or for an ISP, it's another thing to 'clean up after it, keep it secure, keep it running month after month, and do tech support' for yourself or your friends or an ISP.
The Session Initiation Protocol enables just about anybody with little resources to become their own Real-Time Communications Giant.
... protocol (sic) does not function as a magic bullet. Just waving the SIP spec at a traditional telcom does not knock them over. (Okay, throwing the entire printed version of all the SIP specs might...) This isn't about anyone with just 'a little resources', this is about people with resources, a lot of technical know-how (SIP is easy only in the sunny day cases), and LOTS OF TIME.
And anyone with a hoe and a little water can become a Real Farming Industry Giant! Or, If You Have A Few Bucks, You Can Buy This Bridge I Can Sell You.
The
Beyond basing a standard for managing stateful telecommunications sessions on a protocol for stateless bulk data transport, the most blatant silliness in the SIP standard was the original "Alert-Info" header. The Alert-Info header allowed the calling party to specify the ring tone/sound by listing a URL that the receiving device would automatically attempt to fetch and play without waiting on the recipient user to allow/disallow it.
Others:
List of Evil SIP ideas
Oh, and never updating the SIP version string despite syntax changes in the standard is evil.
Yes, I just picked up a Fujitsu Stylistic ST5020D a couple of weeks ago to use with Corel Painter IX as a portable digital drawing/painting device.
It's rather nifty. While the handwriting recognition and writing by hand is slower than typing, typing requires both hands and place to put the keyboard whereas with the tablet one can hold the tablet with one hand and write with the other.
Some interesting synchronization/race condition issues just waiting to be found, one suspects, when there are parts of your computer not bounded by speed of light considerations, and parts that are, as well as deterministic parts and quantum parts.
You might want to double check on liability issues. Depending on the exact nature of the business involved, there could be legal issues.
(I.e. if the work involves things like medical or other private information, working on/transmitting those over 'personal' equipment or an ad-hoc telecommuting arrangement may be a legal no-no.)
This problem almost has to get solved regardless for IPv6/IPv4 NAT, if you plan to have legacy IPv4 network devices interoperate with new IPv6 ones. This is probably the most interesting challenge to IPv6 deployment -- if people can solve the interoperability problems between IPv6 and IPv4 to encourage people to start to deploy IPv6 in an IPv4 based world, you solve the interoperability problems between IPv4 NAT'd networks... which would tend to give people even less reason to upgrade to IPv6.
Ah, well. Live and learn.
Look, here is how it works.
The applications uses "http://slashdot.org/". That is *ALL* it uses.
When it wants to open up a network connection, it passes the URL to the operating system network stack and gets back, oh, say a socket descriptor. The network stack may *internally* turn this into an IP address (or a MAC address, a GSM cell number, IPv4, IPv6, *whatever*) but since the application is protected from that by only having the socket descriptor as an interface, the application remains independent of whatever happens in the network layer. At this point, the application doesn't care if the URL happens to resolve to an IPv6 address or an IPv4 address or whatever.
Here's a more complex scenario:
Rebuttal: First off, the initial gun powder weapons were BUILT as muzzle loading, single shot weapons. I can certainly sweep this fact aside as "outdated". This does not say that the black powder weapons were NOT successful in their time, but now, they would not go anywhere. Really.
Well, duh. What else do you call a firewall?
Well, duh. Ever looked at your Terms of Service agreement? Look closely at the your own statement! "Ask permission from people who CONTROL the network" -- they control it, it isn't YOUR network.
So far, you seem to be building a spammers haven -- no filtering, and no one who can tell a spammer not to run their spamming applications.
Great. Tell me how to access an IPv6 server from an IPv4 application. Wow! Looks like we need NAT before we can have all these new applications.
Bull. The application is aware of IPv4 addresses, therefore it is not separate from the network layer.
NAT does NOT make the application dependent on the network. The application was ALREADY dependent on the network. If it wasn't dependent on the network, changing the network would not break the application.
Silly.
IP addresses have no place in the application layer. You can't say that the network is transparent to the application, because if the network was transparent to the application, the application would not break because of NAT! NAT breaks the applications because the applications are dependent on the configuration of the network.
If the applications were not dependent on the network configuration, then I should be able to run the same application across a Bluetooth conneciton, ethernet, GSM, and ATM, without changing one aspect of the application. Instead, all these applications *NEED* IPv4, they are *DEPENDENT* on IPv4 being configured without NAT. They require knowledge of IPv4 address space -- they break with IPv6 addresses.
This is NOT transparency. This is dependency, addiction.
End-to-end addressing the best idea? Great! Let's use MAC addresses instead of IP addresses! Heaven forbid we translate or map IP addresses to MAC address on ethernet! Goodness, those folks who developed ethernet much have been a bunch of idiots then, right, to require another level of translation and mapping? Even if it does allow for people to use IPv4 and IPv6 over top the same med
Bluntly speaking, yes, all VoIP and H323 software is obsolete for these reasons.
People are confusing "end to end" applications with "end to end" mechanisms.
When the telegraph was the latest technology, the 'application' and the 'mechanism' were practically identical -- pulses of electricity sent over a wire. Same with the initial voice and phone system. Over time, though, people started separating the 'application' (voice/information transmission) from the 'mechanism' (eletrical patterns on the wire.) Separating the two layers, now we have the ability to place phone calls that are digitized, sent over wires, over fiber, over radio waves, and coverted back to voice. The application (voice) is still end to end, but the mechanism isn't.
Many protocols today are obsolete because people have and still confuse the 'application' (voice, web access, email) with the 'mechanism' (associated protocols bound to IPv4). We want the application to run end-to-end, because that is what make the application useful -- but folks have confused this with requiring the mechanism to be identical from end to end -- IPv4 without NAT, all the way! That is like saying we should only over end to end copper, with no fiber in between.
End-to-end IPv4 (no NAT) used to be the application -- like in the days of the telegraph, the mechanism and the application were synonymous. That is an obsolete model, though. Our needs and demands have gotten more varied and complex from the point of view of the applications -- the mechanism (IPv4) needs to be separated out from the applications.
Imagine if you could not translate digital information from electronic pulses to optical ones. In order to replace a copper network with a fiber one, you'd have to replace the entire thing at once -- regardless of whether or not that made sense. Fortunately, because we can translate and manipulate the mechanisms, we can use a mix of technologies and capacities and do gradual upgrades and best-fit uses of technology without breaking anything. If people wrote their network protocols and applications *properly*, in a non-obsolete fashion, then the transition to IPv6 would be fairly painless and quick. However, the insistance on end-to-end mechanisms is locking us into IPv4 and makes the upgrade to IPv6 very painful.
Geeze. Isn't it obvious that *mandatory* end-to-end anything is a disaster waiting to happen? If end-to-end lock-in is a good model, why the complaints when companies like Microsoft or such try to make people use nothing but Microsoft products 'end-to-end'? Whenever that happens, people start shouting about open interfaces and needing interoperability between different vendors and products. Yet when it comes down to IPv4, people fall down on their knees and worship the way things have been (badly) designed to *require* end-to-end IPv4. (That is, end-to-end conformity is not a bad thing in and of itself, but the requiring of it is a lock-in that inhibits change and growth, as well as competition.) Modularity, anyone? What next, going to propose that electricty only be made and transmitted as 120V AC end to end, and you can't transform it into DC current or anything else because it breaks the end to end model?
Think a bit more, folks. End-to-end uniformity, conformity, blandness is all well and good, but much of the advancement in technology and industry comes from having standardized *interfaces* and *translations* that allow us to interconnect different mechanisms together to make more interesting things. (No IPv4 is not a standardized *interface* when it is coupled with the requirement to be end-to-end. A good interface should hide the implementation details both sides. The end-to-end requirement violates the hiding principle.)
An interesting problem with this is that the virtual world property now has real world cash-value. If Second Life 'pays' me in virtual money, which I can convert to real dollars, is this a form of employment? If I make a thousand dollars from selling things, will the IRS start hounding me? If some one steals a virtual object from me, can I have them arrested if I can show a monetary loss? As long as it is all play money, there were fewer issues -- but now that they are bringing in real money... well, lots of people and organizations interested in that, for better or worse.
I am rather surprised at the commentary so far on this device, given the usual tone of responses made on slashdot that I have seen.
This device appears to be, at heart, a box that is put in along side the routers to filter out content that the owner of the device does not want to be sent over the network. It is capable of looking for specific patterns of data and blocking the transfer of the data based on that in real time.
Is this not precisely what one would use to filter out, say, unwanted political documents going in/out of China? To, say, spot a specific MP3 file being traded on a P2P network and stop it?
Other comments seem to suggest people think this might actually be a workable, good idea -- guess folks are finally realizing that the Internet cannot route around all forms of censorship after all, if they think this will work.