I mean, seriously. We have networking traffic that moves from optical to wired to wireless, across all sorts of protocols and encapsulations, constantly. No one freaks out, no one complains. Suddenly, if the specter is raised of changing the sacred IP Address, everyone freaks out. NAT only impinges the functionality of software because the software and protocols are badly designed -- i.e. they insist on using IP information inside application level protocols instead of application-level identifiers (i.e. hostnames rather than IP addresses.) If applications had been properly separated from the network information to start with, then the migration from IPv4 to IPv6 would have been even smoother because the applications and protocols would never have had to be re-written.
If the applications never deal with IP addresses and instead have the operating system/network API handle the details, then the applications become independent of the network protocol, just like applications (generally) do not have to care about the difference between wired and wireless ethernet. At that point, it is possible to implement protocol to protocol conversions and translations at the network level that does not impact the applications or their functionality.
If applications do not break or fail to work because my traffic switches from wireless to wired to optical data transport, or because the encapsulation changes (ethernet frames vs. ppp vs. ATM vs. frame relay), then they should also not break because the network protocol changes (i.e. IPv4 to IPv6 and back again.) People blame NAT for the problems, but it is not that NAT *breaks* the applications, it is that the applications were *already broken* in design, and NAT just reveals the flaws.
I am not enthusiastic about how the response to the flaws of badly written applications has been to make a huge address space instead of fixing the design of the application and protocols. That's kind of like saying the answer to a memory leak is to add a petabyte of RAM to a computer.
If we worked on fixing the applications and protocol stack instead (i.e. pushing IP handling completely into the OS layer and keeping it out of the applications), then applications would not have to care about dual stack, triple stack, NAT, etc. at all. This means that it would become much easier to migrate to new network technologies without disrupting the applications. This would also allow people to run specialized or experimental networking protocols on their own networks for their own purposes while still using the same applications.
If applications and protocols continue to be developed where they expect "IPv4 or IPv6 formatted address only", then that locks them in. They have to be rewritten whenever something changes at the network layer (i.e. NAT, new versions of IP, etc.) If the applications stayed out of the network layer, then only the operating system would have to be updated to support new networking technologies, which is easier than updating every application everywhere.
It's not about running out of IPv6 addresses, it's about what comes after IPv6 in terms of protocols.
Unless you believe the IPv6 is the ultimate protocol and there will never ever be anything any better than IPv6, of course. Feel free to inform all the schools and tech companies that there is no point in any further R&D in this field.
If you might happen to believe that maybe some day someone will come up with something that is just an inherently better designed protocol than IPv6, then deploying IPv6 with the anti-NAT zealot brigade is stupid, because should something better come along, doing the network migration from an IPv6 network is going to take forever.
And that is a step backwards for network design. It should be easy to migrate *from* a network to new technologies, not get locked into a dead-end-to-dead-end addressing scheme.
The bigger problem is because of the ideological dead-end-to-dead-end design, when every one's toaster and light bulb have an IPv6 address, and the anti-NAT zealots have one, is that upgrading to the next generation of networks will be impossible. The inertia caused by having to have everyone upgrade every light bulb and toaster to a new standard will block any advancement in networking technology.
I wish I had mod points at the moment to moderate you up, because not many get the problem.
It gets even worse if you imagine that, some day, someone comes up with a protocol that's better than IPv6 (not a bigger address space, for goodness' sake, but *better*). If people compulsively cling to the dead-end-to-dead-end connectivity model with IPv6, trying to migrate that network to the next generation of technologies that come after when every lightbulb has its own IPv6 address will bring network innovation to a stand-still.
Unfortunately, NAP-PT and related do not always work because there is not a clean separation in many applications between network-layer stuff and application-layer stuff. The applications/network services APIs have to be cleaned up first.
Code reviews are certainly not a magic bullet. Maybe they are applicable to a situation, maybe not.
Code reviewers are human, so are subject to all the potential problems there. I've seen code quality dragged down by code reviews because the reviewers either could not or chose not to (for various reasons, including inter-department politics) to understand a piece of code (even when it could be shown that it was the 'standard' or best current practice solution.) Ultimately the code was degraded down to the level the reviewer wanted it at just to get things done.
I looked at the contest, and thought that the design constraints they are putting on the entries are pretty tight. If I recall/interpret things correctly, the vehicle must be designed to use the given frame, the given engine/drive system, and also, the driver position cannot be changed.
That puts a kind of serious limitation on just how creative you can get. If you could at least move the driver around, you could try for some interesting arrangements or variations, but if the driver has to be in the one standard spot, and the wheel position is already determined, and the frame... they are going to get an awful lot of designs which are just variations on a theme, I suspect.
Remaining against IPv4 may be against both our interests and while adopting IPv6 may be in your (commercial) interest, it is against my long term interest because I wish to continue to see the networking technologies evolve. If everyone moves into an IPv6 network and continues to be fixated on having their own IPv6 address (and continuing to embed them into protocols (like SIP, bleah)), then it will be even harder to move on to new technologies.
You are confusing peer-to-peer with IP addressing -- this is a flaw in the current applications models and mind set. Consider that if people actually designed their protocols and applications to deal with NAT without failing (NAT is not the problem -- broken applications are), then we could have had IPv4/IPv6 NAPT, and had an even speedier transition to IPv6! But because of the mind set which says that the sacred IP packet cannot be touched, it allows people to write sloppy code which expects to see and use IP addresses directly (as opposed to host names or URLs). Because applications are badly written and cannot survive even IPv4 NAT, never mind IPv4/IPv6 NAT, the peer-to-peer model risks getting fragmented because there will be IPv4 only hosts and IPv6 only hosts.
I would feel better about privacy extensions if I could trust that they would really be on by default for everyone, not just the technically aware. And, no, browser cookies are less of a threat to personally identifying a specific machine compared to the MAC-address based IPv6 address generation because browser cookies are specific to HTTP(S). If the IPv6 address generation is based on the unique hardware address of the machine's network interface, then that has privacy implications for all network traffic from the machine, not just the HTTP(S) traffic.
You seem to miss my point. It is not about everyone having their own IP address. (Which is really kind of silly when you think about it. We have a broken system where IP address == reachability.) It's about continuing R&D and innovation. Saying "Oh, well, this is good enough! Let's stop thinking." is not a great position.
I do not care if there are enough IPv6 addresses to last until the end of the universe. The address space is not the issue.
Would people adopt IPv6 faster if it resulted in everyone having globally unique and trackable IPv6 addresses (especially if the addresses were generated by using the hardware MAC address) that allowed for easier government and corporate tracking?
Of course there is incentive to work on the next generation of protocols. It's basic R&D and a drive to not sit on your laurels.
This is not about merely having more addresses, but also in dealing with issues like dual or multi-homed routing (last I heard IPv6 dual-homing was still in progress.)
When comparing the pace of innovation in other areas, the glacial pace of IPv4 to IPv6 is actually kind of disturbing. The fact that there is no work going on for developing what might be next is even more so.
Consider a situation where a corporation asks for government funding to develop a deep-packet-inspection system for IPv6 for purposes of monitor and/or censorship. How much more likely is the funding to occur if everyone knows IPv6 is going to be around for decades without replacement? (Of course, many would no doubt fund some level of effort. but if 'IPvX was just around the corner', the investment levels and time frame to develop would be smaller.)
This announcement screams "The network is a sitting duck!" -- things are no longer moving forward. We need to continue to see innovation and change and improvements in this area to keep expanding the frontiers/edges of the network into new technologies and to keep being a moving target.
While it is kind of easy to look back along the history of nearly anything complex and cherry-pick things to support a given point, the article raised some interesting points.
It would be interesting to consider the development of the Internet in the same lines and the subsequent lock-in.
What does making a statement about end-2-end being a good idea have to do with the effort involved in switching address families? Most issues are related to storage and manipulation of address family specific data (sometimes in ASICs) rather than logical layering issues related to bits contained within an actual wire format. At some point you need to enter an IP to connect somewhere.. protocol agility at the application layer was not something people spent much time thinking about.
Argh. Why do you keep coming back to "you need to enter an IP"? You're not getting the point. The point is you should never *NEED* to enter an *IP Address*.
??? Suppose I'm a one-sided UDP packet and I want to be delivered to a certain user at a certain address how do you propose that I get there if there is a many-one NAT in my way and the NAT knows nothing about me, my purpose or even what my final destination should be? Should I embed next hop routing data in the IP header? (Please say no) How do you resolve this without end to end?
If I can't send a single sided message to a destination...the issue isn't IP it is whatever is standing in the way. This has nothing to do with higher layer protocols. Support of NAT actually creates more layering inversions than there otherwise would be.
You're still stuck in IP-land. You're stuck in UDP packets and IP addresses. Just imagine, maybe, a network which did not use UDP and IP packets.
It's like talking to someone who only ever uses Microsoft products, and expects everyone else to use Microsoft products end-to-end -- they only think in.doc extensions.
It is easy to take this argument to absurdity showing others before you were wrong so by extension all statements about practical limits must be wrong regardless of the merits of the specific situation. IPv4 was at no point intended to provide network services to billions of people. I didn't even specify a number of bits. All I said was that the header does virtually nothing and is therefore uninteresting. There are only ~2^32/32's you can hand out.
Given current announced allocation policy when there are roughly 4 billion ISPs connected to the global Internet there will be an address shortage. Unlike IPv4 if we ever get close to seeing this day there are options to address it without renumbering. These are the facts - feel free to interpret them as you wish.
Sigh. You're still stuck in IP-only land. It's NOT about address exhaustion. It's about, maybe, someone, someday, invents something *better* than IPv6, but is not compatible with IPv6.
I guarantee nothing. I do not assert IPv6 will be the last Internet protocol the world will ever see.
And this is why I laugh.
If there is the potential for something *better* than IPv6, then we should be working on making sure that it is easy to transition to that. We should not be painting ourselves into a dead-end-to-dead-end corner.
This is why the E2E mindset fails. If the possibility for something beyond IPv6 exists, then how exactly do we transition to the future without a wholesale replacement of IPv6 software/hardware if we insist on E2E? Otherwise, if one wants to claim the use of protocol translation devices to ease the transition, that violates E2E.
End to end simplifies higher layer protocol development and removes unecessary infustructure dependancies.
That is a mind-boggling statement. If that was truly the case, then there would not be any problem with moving from IPv4 to IPv6 because the higher level protocols (i.e. applications) would not have to be rewritten to handle them.
NAT requires a middle box understand the semantics and state charts associated with higher layer protocols before it can be effectivly translated.
That is *precisely* the problem. If there was actual separation between the network layer and the higher level protocols as you claimed E2E provides, then the NAT middle box would not have to care about higher level protocols.
If I wanted to write a new protocol layered on top of IP... I would be prevented from doing so because all of the NAT servers in the world would have to be updated to understand my new protocol in a many-to-one environment.
...? I think you miss the point. You should not have to care about layering 'on IP'. If E2E really removed 'unnecessary infrastructure dependencies', you wouldn't care that it had to be on IP.
The argument mear existance of E2E somehow promotes crappy design/unecessary dependancies on lower layers is specious in my view.
It's not the 'mere' existence, it's the fact it's become ideology. It's like people have chosen to populate their toolboxes with only a hammer, so that now everything looks like a nail.
Most well written applications don't care. You are confusing IP layer protocol design with socket layer APIs and application design. (See getaddrinfo and getnameinfo) It is easy to write code today which would theoretically work without modification on a unknown future address family without much trouble at all.
No, lazy programmers are writing applications dependent on IP layer protocol because the E2E mindset lets them get away with making bad design assumptions and not actually writing programs in a protocol independent way. Also, for server-side sockets, right now I believe software that used to only open one socket to listen for IPv4 connections must now open two -- one for IPv4, and one for IPv6. This is not a scalable protocol independent API.
How much can you really innovate around a globally unique identifier used for routing? The only question is really "how many bits" IP layer of IPv6 is sparatan and unintersting. Much more so than IPv4 was. At its core IPv6 is really just three things.. a source address, destination address and extensible option header. It would seem to me that any improvement here must be trivial.
And no one will ever need more than 640K of RAM.
The real magic happens by innovating protocols layered on top of IP (TCP,UDP,SCTP,ICMP..etc) where no wholesale infustructure changes are required -- only the two endpoints (E2E) need understand a protocol for it to be useful. IPv6 option header was designed to extend and improve IP without forklift changes.
*laughs*
So, IPv6 is *perfect*? It will never ever need to be replaced? In a hundred years, it will still be good? Two hundred? Five hundred? A thousand?
Wow. After a bare handful of decades of the Internet, and people have already reached perfection in network protocol design! The holy IPv6 has be given unto us to last forever and ever, amen.
Going to a variable-length scheme is one possible (if tricky) solution.
The major problem is that 'end-to-end' has become blind ideology rather than useful design methodology. As a result, people keep fighting tooth and nail against the very idea of NAT and encouraging development of applications that are tightly coupled to the underlying network.
Instead of pushing for IPv6, there should be an effort towards developing against a more abstract network model such that applications do not care if they are using IPv4 or IPv6 or IPv42, such that protocol translation between different network families can be implemented where necessary.
Or, to answer you question, if networks globally all transition to IPv6, it will last forever because it will bring innovation in the network protocol family to a grinding halt. Even if someone came up with a truly amazing and brilliant network protocol that was provably better than IPv6, it would never get implemented in a world were every toaster oven and garage door opener is built with an IPv6 stack and, due to dead-end-to-dead-end ideology, is unable to communicate with anything but IPv6. Just look at the transition from IPv4 to IPv6 and how long "IPv6 has been just around the corner", then imagine the inertia on migrating from IPv6.
Hah. The only way this will work is if they make an extremely good IPv4/IPv6 NAT gateway. Except, if they make one that does a good job such that people are going IPv4->IPv6->IPv4 and everything basically works, then people will wonder why they don't just do an extremely good IPv4 NAT solution and go IPv4->IPv4 and drop the entire IPv6 part.
Obviously, what they need to do is apply this technique to embed the message in spam messages, in the random dictionary garbage or images in the spam. The recipient then just has to know which spam messages to check for the hidden messages.
Now, we just need someone to do this to show how to smuggle information in/out of the major spam-email-producing countries, and perhaps there will suddenly be more interest in shutting down spammers.
My first mental image was a conference room full of bureaucrats and a duel flag dropping down in the middle.
Or two opposing teams of bureaucrats playing a Warsong Gulch match.
Hmm. Does anyone else think this could be the next big MMO? "That's not a red health bar on the boss -- that's how much red tape you have to cut through!"
Well, think about it this way -- why *hasn't* the transition to IPv6 gone smoother/faster? Answer: the current architecture (with its dead-end-to-dead-end philosophy) is not designed to be upgraded. Presumably, some day, some one with ambition will come up with a networking protocol that is *better* than IPv6 (not talking about bigger address space, I mean even better protocol design.) I have problems believing that in a million years we would still be running IPv6 because no one will have come up with anything better. (Maybe because it's been impossible to migrated from, but...) Ideally, IPv6 would have some design elements to make it possible to easily and quickly upgrade to future (non-IPv6) technologies faster.
The problem that making sweeping improvements has such a high cost barrier (or even a decent method for making piecemeal/gradual improvements) is in itself a problem because it slows down the development and deployment of new technologies. Which is why IPv6 has been so slow to be deployed. This is an architectural issue.
Without specifying the scenario, the answers to this question is pointless.
If you have a bunch of professionals working together, their ability to follow processes and perform will be different than if you are managing a bunch of monkeys. If all your programmers only speak Japanese, giving them a bunch programming principles written in English is not going to help. If your programming team is full of people who have been programming in Java for their entire careers in enterprise applications, then toss them into a low-level hard real-time embedded system C-only programming environment, it's going to be interesting. People apply their own perceptions and prejudices (and blind-spots) when following software design principles (or when they *think* they are following principles.)
If the only common language your programming team knows between all of them is BASIC, your application is going to end up in BASIC. If all your programmers are OO folks, your application is going to be built OO. etc. If you have a mixed team of local programming teams in different product groups in a company with different priorities vis-a-vis the project, some contractors, stuff out-sourced to a group in Asia, etc. etc. etc. Theory in software design principles can take a flying leap. Each situation is different and the importance of the skills and experience of the people involved can trump the technology or design principles.
If your vaunted software design theory ends up pounding square people into round software princple holes, things can go amazingly badly. This does not mean that the software design principle is bad. It does not mean that people are bad. It means that the design principles are not being applied properly. A herd of cats is managed and is better at different things than a pack of dogs. If you are trying to manage a group of distributed developers who are more varied than zoo, then software design principles take second stage to management principles. First, you need to figure out roughly what each group is good at, and then you can apply the proper design strategy/development principles to each groups.
This sort of theorizing is only valid in the laboratory or for small target groups in reasonably controlled circumstances. The personnel and personality issues (internal team conflicts, design blind-spots, personnel turn-over, etc.) and outside influences (changing target market/customer requirements, abrupt budget cuts, scheduling changes, etc.) tend to trump design principles in practice. In order to make such design principles work in practice, it takes a combination of constraining the domains being worked on and resources to create a (mostly) controlled environment in which to apply the principles. Few design principles can cope with situations where the outside world (or internal personality issues) are allowed free reign to interfere with the development.
So, first posit a controlled situation and specify your group of developers, and then maybe you could come up with principles that apply. Sometimes, principles that apply to one situation don't actually work in another. (Generally, for instance, commenting the code is a good idea, for instance, but the person writing the comments needs to be able to write *good* comments. If the person doing the commenting is only putting in unimportant stuff, or not aware of what they ought to be documenting, then they product crappy comments. If the person who is then going to be dealing with the comments is not experienced enough to tell good information from bad, this situation can be harmful because it creates the illusion of understanding. So, do you have a team where most of the people are inexperienced? If so, then the group design/management/development principles may need to be organized so that the experienced people are in the path to check on the work of the inexperienced, and you don't have the inexperienced people cross-checking their own code without a sanity check.)
A major issue for end users will be if they use a SIP client/soft phone that actually pays attention to the (rather moronic) Alert-Info (or Call-Info) header. If anyone gets a SIP client out into the wild that actually implements Alert-Info, every hacker and spammer on the planet will be trying to figure out ways to trick the security on the SIP client into paying attention to their Alert-Info.
From RFC 3261 (Session Initiation Protocol):
20.4 Alert-Info
When present in an INVITE request, the Alert-Info header field
specifies an alternative ring tone to the UAS. When present in a 180
(Ringing) response, the Alert-Info header field specifies an
alternative ringback tone to the UAC. A typical usage is for a proxy
to insert this header field to provide a distinctive ring feature.
The Alert-Info header field can introduce security risks. These
risks and the ways to handle them are discussed in Section 20.9,
which discusses the Call-Info header field since the risks are
identical.
In addition, a user SHOULD be able to disable this feature
selectively.
This helps prevent disruptions that could result from the use of
this header field by untrusted elements.
Gah! That's what I get for posting in the morning.
Yeah, I goofed on the math.
Mostly I remember when I was starting out and we were still dealing with modem banks at the job. You could run down to the computer store and buy an individual modem for $X, but the per modem cost in the modem banks was something like 2X. I was boggled because I thought that buying 'in volume' should have been cheaper than buying the same number of modems from CompUSA or something. Except the modem banks were remotely manageable, had T1 or T3 interfaces, redundant power supplies, management software, number pools, etc. etc. Even so, the sticker shock per port was shocking.
Just out of curiousity, just how easy do people think it is to 'upgrade the network'? I see that brought up a lot in the comments (i.e. "AT&T should just upgrade their network" "Given Moore's Law, the network should be cheaper" etc. etc.) It certainly gives the impression that people think that a nation-wide IP network is as easy to upgrade as their personal computer as as proportionally cheap.
When I was working in telecom, network upgrades (and maintenance) could be ferociously hard. If you wanted to upgrade the link between two co-location facilities, besides the problems of running the lines, you could run into issues if you needed to upgrade your networking equipment at either end -- suddenly, you had to stock new on-site spares, make sure the technicians were prepared, deal with power, space, and cooling issues. (If you needed to replace your current router with a newer router that was physically bigger, there had to be rack space available for it. If it needed more power/cooling, that had to be available. If space/power/cooling wasn't there, *someone* had to pay for the upgrades, or you had to move to a new facility and re-home all the network connections there. Not trivial and just the man-hour costs could be huge. (And in some places, the co-locations were subject to union rules, which placed additional restrictions on work.))
(Actually, for some network facilities, the fields would refuse to go without a security escort, because they weren't going to be responsible for driving trucks full of valuable equipment into some areas and leaving them outside while they worked inside. That increased the cost noticeably.)
Most of the business plans (at the time) assumed that equipment would be paid off over a period of years, not months. People would be expensive new telecom gear and plan to pay it off over the course of three or four years so they could set their monthly rate to customers at X, rather than try to pay it off in one year by charging customers more -- the lower prices/competition may have appeared great to the customers, but once the rush of entrants into the ISP business died out and people stopped pumping money in, the equipment upgrades got stalled because business realities demanded that the providers pay off the old equipment first.
So providers had gone in with models saying they would buy equipment for their networks, charge customers X amount, and, say just for kicks, maybe 5% of that amount went to paying off equipment. Of course, every time there was an unexpected cost, or they had to lower their rates to stay competitive, less money could be used to recoup their capital expense in hardware, which meant they couldn't afford to upgrade. (Of course, at a certain point, some couldn't afford to not upgrade, either, and self-destructed.) So the 'life span' of old equipment kept going because no one could raise rates due to the competition, who also couldn't for the same reasons, and new entrants coming in with fresh capital/investments that kept the rates of the moment low. The 'rapid advances' in technology were in part due to the money being poured into the marketplace (investment of one sort or another), *not* the success of the business models. Once the party was over and the reality of the bills hit, a lot of the upgrades stalled pretty hard.
It's not that Moore's Law hasn't affected the cost of providing bandwidth, it's that people are still struggling with buried (sic) infrastructure costs from previous technology. If you feel you are paying 2004 prices for 2004 technology, network-bandwidth-wise, rather than the equivalent 2008 price/performance, it's because you probably are, because the 2004 technology is still getting paid off.
(Let's say that, oh, I could get a 48 port DSLAM for $2400, or $500 a port. So just to recoup my capex on buying that sucker, I need to make $500 per port. If I can throw $10/port a month at the hardware cost, that's 50 months, or over four years until I can justify upgrading it. It can be surprisingly
Slashdot Mirror
The initial move is to stop demonizing NAT.
I mean, seriously. We have networking traffic that moves from optical to wired to wireless, across all sorts of protocols and encapsulations, constantly. No one freaks out, no one complains. Suddenly, if the specter is raised of changing the sacred IP Address, everyone freaks out. NAT only impinges the functionality of software because the software and protocols are badly designed -- i.e. they insist on using IP information inside application level protocols instead of application-level identifiers (i.e. hostnames rather than IP addresses.) If applications had been properly separated from the network information to start with, then the migration from IPv4 to IPv6 would have been even smoother because the applications and protocols would never have had to be re-written.
If the applications never deal with IP addresses and instead have the operating system/network API handle the details, then the applications become independent of the network protocol, just like applications (generally) do not have to care about the difference between wired and wireless ethernet. At that point, it is possible to implement protocol to protocol conversions and translations at the network level that does not impact the applications or their functionality.
If applications do not break or fail to work because my traffic switches from wireless to wired to optical data transport, or because the encapsulation changes (ethernet frames vs. ppp vs. ATM vs. frame relay), then they should also not break because the network protocol changes (i.e. IPv4 to IPv6 and back again.) People blame NAT for the problems, but it is not that NAT *breaks* the applications, it is that the applications were *already broken* in design, and NAT just reveals the flaws.
I am not enthusiastic about how the response to the flaws of badly written applications has been to make a huge address space instead of fixing the design of the application and protocols. That's kind of like saying the answer to a memory leak is to add a petabyte of RAM to a computer.
If we worked on fixing the applications and protocol stack instead (i.e. pushing IP handling completely into the OS layer and keeping it out of the applications), then applications would not have to care about dual stack, triple stack, NAT, etc. at all. This means that it would become much easier to migrate to new network technologies without disrupting the applications. This would also allow people to run specialized or experimental networking protocols on their own networks for their own purposes while still using the same applications.
If applications and protocols continue to be developed where they expect "IPv4 or IPv6 formatted address only", then that locks them in. They have to be rewritten whenever something changes at the network layer (i.e. NAT, new versions of IP, etc.) If the applications stayed out of the network layer, then only the operating system would have to be updated to support new networking technologies, which is easier than updating every application everywhere.
Sigh. It's not about more addresses. It's about better protocols. There's a difference.
So, you are correct. You do suffer from a lack of imagination.
It's not about running out of IPv6 addresses, it's about what comes after IPv6 in terms of protocols.
Unless you believe the IPv6 is the ultimate protocol and there will never ever be anything any better than IPv6, of course. Feel free to inform all the schools and tech companies that there is no point in any further R&D in this field.
If you might happen to believe that maybe some day someone will come up with something that is just an inherently better designed protocol than IPv6, then deploying IPv6 with the anti-NAT zealot brigade is stupid, because should something better come along, doing the network migration from an IPv6 network is going to take forever.
And that is a step backwards for network design. It should be easy to migrate *from* a network to new technologies, not get locked into a dead-end-to-dead-end addressing scheme.
The bigger problem is because of the ideological dead-end-to-dead-end design, when every one's toaster and light bulb have an IPv6 address, and the anti-NAT zealots have one, is that upgrading to the next generation of networks will be impossible. The inertia caused by having to have everyone upgrade every light bulb and toaster to a new standard will block any advancement in networking technology.
I wish I had mod points at the moment to moderate you up, because not many get the problem.
It gets even worse if you imagine that, some day, someone comes up with a protocol that's better than IPv6 (not a bigger address space, for goodness' sake, but *better*). If people compulsively cling to the dead-end-to-dead-end connectivity model with IPv6, trying to migrate that network to the next generation of technologies that come after when every lightbulb has its own IPv6 address will bring network innovation to a stand-still.
Unfortunately, NAP-PT and related do not always work because there is not a clean separation in many applications between network-layer stuff and application-layer stuff. The applications/network services APIs have to be cleaned up first.
Code reviews are certainly not a magic bullet. Maybe they are applicable to a situation, maybe not.
Code reviewers are human, so are subject to all the potential problems there. I've seen code quality dragged down by code reviews because the reviewers either could not or chose not to (for various reasons, including inter-department politics) to understand a piece of code (even when it could be shown that it was the 'standard' or best current practice solution.) Ultimately the code was degraded down to the level the reviewer wanted it at just to get things done.
Agreed. SIP is a particularly bad mess to deal with.
I looked at the contest, and thought that the design constraints they are putting on the entries are pretty tight. If I recall/interpret things correctly, the vehicle must be designed to use the given frame, the given engine/drive system, and also, the driver position cannot be changed.
That puts a kind of serious limitation on just how creative you can get. If you could at least move the driver around, you could try for some interesting arrangements or variations, but if the driver has to be in the one standard spot, and the wheel position is already determined, and the frame... they are going to get an awful lot of designs which are just variations on a theme, I suspect.
Remaining against IPv4 may be against both our interests and while adopting IPv6 may be in your (commercial) interest, it is against my long term interest because I wish to continue to see the networking technologies evolve. If everyone moves into an IPv6 network and continues to be fixated on having their own IPv6 address (and continuing to embed them into protocols (like SIP, bleah)), then it will be even harder to move on to new technologies.
You are confusing peer-to-peer with IP addressing -- this is a flaw in the current applications models and mind set. Consider that if people actually designed their protocols and applications to deal with NAT without failing (NAT is not the problem -- broken applications are), then we could have had IPv4/IPv6 NAPT, and had an even speedier transition to IPv6! But because of the mind set which says that the sacred IP packet cannot be touched, it allows people to write sloppy code which expects to see and use IP addresses directly (as opposed to host names or URLs). Because applications are badly written and cannot survive even IPv4 NAT, never mind IPv4/IPv6 NAT, the peer-to-peer model risks getting fragmented because there will be IPv4 only hosts and IPv6 only hosts.
I would feel better about privacy extensions if I could trust that they would really be on by default for everyone, not just the technically aware. And, no, browser cookies are less of a threat to personally identifying a specific machine compared to the MAC-address based IPv6 address generation because browser cookies are specific to HTTP(S). If the IPv6 address generation is based on the unique hardware address of the machine's network interface, then that has privacy implications for all network traffic from the machine, not just the HTTP(S) traffic.
You seem to miss my point. It is not about everyone having their own IP address. (Which is really kind of silly when you think about it. We have a broken system where IP address == reachability.) It's about continuing R&D and innovation. Saying "Oh, well, this is good enough! Let's stop thinking." is not a great position.
I do not care if there are enough IPv6 addresses to last until the end of the universe. The address space is not the issue.
Would people adopt IPv6 faster if it resulted in everyone having globally unique and trackable IPv6 addresses (especially if the addresses were generated by using the hardware MAC address) that allowed for easier government and corporate tracking?
Of course there is incentive to work on the next generation of protocols. It's basic R&D and a drive to not sit on your laurels.
This is not about merely having more addresses, but also in dealing with issues like dual or multi-homed routing (last I heard IPv6 dual-homing was still in progress.)
When comparing the pace of innovation in other areas, the glacial pace of IPv4 to IPv6 is actually kind of disturbing. The fact that there is no work going on for developing what might be next is even more so.
Consider a situation where a corporation asks for government funding to develop a deep-packet-inspection system for IPv6 for purposes of monitor and/or censorship. How much more likely is the funding to occur if everyone knows IPv6 is going to be around for decades without replacement? (Of course, many would no doubt fund some level of effort. but if 'IPvX was just around the corner', the investment levels and time frame to develop would be smaller.)
This announcement screams "The network is a sitting duck!" -- things are no longer moving forward. We need to continue to see innovation and change and improvements in this area to keep expanding the frontiers/edges of the network into new technologies and to keep being a moving target.
While it is kind of easy to look back along the history of nearly anything complex and cherry-pick things to support a given point, the article raised some interesting points.
It would be interesting to consider the development of the Internet in the same lines and the subsequent lock-in.
What does making a statement about end-2-end being a good idea have to do with the effort involved in switching address families? Most issues are related to storage and manipulation of address family specific data (sometimes in ASICs) rather than logical layering issues related to bits contained within an actual wire format. At some point you need to enter an IP to connect somewhere.. protocol agility at the application layer was not something people spent much time thinking about.
Argh. Why do you keep coming back to "you need to enter an IP"? You're not getting the point. The point is you should never *NEED* to enter an *IP Address*.
??? Suppose I'm a one-sided UDP packet and I want to be delivered to a certain user at a certain address how do you propose that I get there if there is a many-one NAT in my way and the NAT knows nothing about me, my purpose or even what my final destination should be? Should I embed next hop routing data in the IP header? (Please say no) How do you resolve this without end to end?
If I can't send a single sided message to a destination...the issue isn't IP it is whatever is standing in the way. This has nothing to do with higher layer protocols. Support of NAT actually creates more layering inversions than there otherwise would be.
You're still stuck in IP-land. You're stuck in UDP packets and IP addresses. Just imagine, maybe, a network which did not use UDP and IP packets.
It's like talking to someone who only ever uses Microsoft products, and expects everyone else to use Microsoft products end-to-end -- they only think in .doc extensions.
It is easy to take this argument to absurdity showing others before you were wrong so by extension all statements about practical limits must be wrong regardless of the merits of the specific situation. IPv4 was at no point intended to provide network services to billions of people. I didn't even specify a number of bits. All I said was that the header does virtually nothing and is therefore uninteresting. There are only ~2^32 /32's you can hand out.
Given current announced allocation policy when there are roughly 4 billion ISPs connected to the global Internet there will be an address shortage. Unlike IPv4 if we ever get close to seeing this day there are options to address it without renumbering. These are the facts - feel free to interpret them as you wish.
Sigh. You're still stuck in IP-only land. It's NOT about address exhaustion. It's about, maybe, someone, someday, invents something *better* than IPv6, but is not compatible with IPv6.
I guarantee nothing. I do not assert IPv6 will be the last Internet protocol the world will ever see.
And this is why I laugh.
If there is the potential for something *better* than IPv6, then we should be working on making sure that it is easy to transition to that. We should not be painting ourselves into a dead-end-to-dead-end corner.
This is why the E2E mindset fails. If the possibility for something beyond IPv6 exists, then how exactly do we transition to the future without a wholesale replacement of IPv6 software/hardware if we insist on E2E? Otherwise, if one wants to claim the use of protocol translation devices to ease the transition, that violates E2E.
End to end simplifies higher layer protocol development and removes unecessary infustructure dependancies.
That is a mind-boggling statement. If that was truly the case, then there would not be any problem with moving from IPv4 to IPv6 because the higher level protocols (i.e. applications) would not have to be rewritten to handle them.
NAT requires a middle box understand the semantics and state charts associated with higher layer protocols before it can be effectivly translated.
That is *precisely* the problem. If there was actual separation between the network layer and the higher level protocols as you claimed E2E provides, then the NAT middle box would not have to care about higher level protocols.
If I wanted to write a new protocol layered on top of IP ... I would be prevented from doing so because all of the NAT servers in the world would have to be updated to understand my new protocol in a many-to-one environment.
...? I think you miss the point. You should not have to care about layering 'on IP'. If E2E really removed 'unnecessary infrastructure dependencies', you wouldn't care that it had to be on IP.
The argument mear existance of E2E somehow promotes crappy design/unecessary dependancies on lower layers is specious in my view.
It's not the 'mere' existence, it's the fact it's become ideology. It's like people have chosen to populate their toolboxes with only a hammer, so that now everything looks like a nail.
Most well written applications don't care. You are confusing IP layer protocol design with socket layer APIs and application design. (See getaddrinfo and getnameinfo) It is easy to write code today which would theoretically work without modification on a unknown future address family without much trouble at all.
No, lazy programmers are writing applications dependent on IP layer protocol because the E2E mindset lets them get away with making bad design assumptions and not actually writing programs in a protocol independent way. Also, for server-side sockets, right now I believe software that used to only open one socket to listen for IPv4 connections must now open two -- one for IPv4, and one for IPv6. This is not a scalable protocol independent API.
How much can you really innovate around a globally unique identifier used for routing? The only question is really "how many bits" IP layer of IPv6 is sparatan and unintersting. Much more so than IPv4 was. At its core IPv6 is really just three things.. a source address, destination address and extensible option header. It would seem to me that any improvement here must be trivial.
And no one will ever need more than 640K of RAM.
The real magic happens by innovating protocols layered on top of IP (TCP,UDP,SCTP,ICMP..etc) where no wholesale infustructure changes are required -- only the two endpoints (E2E) need understand a protocol for it to be useful. IPv6 option header was designed to extend and improve IP without forklift changes.
*laughs*
So, IPv6 is *perfect*? It will never ever need to be replaced? In a hundred years, it will still be good? Two hundred? Five hundred? A thousand?
Wow. After a bare handful of decades of the Internet, and people have already reached perfection in network protocol design! The holy IPv6 has be given unto us to last forever and ever, amen.
Sorry, I don't buy it.
My guess it will never happen.
Sad, isn't it?
Going to a variable-length scheme is one possible (if tricky) solution.
The major problem is that 'end-to-end' has become blind ideology rather than useful design methodology. As a result, people keep fighting tooth and nail against the very idea of NAT and encouraging development of applications that are tightly coupled to the underlying network.
Instead of pushing for IPv6, there should be an effort towards developing against a more abstract network model such that applications do not care if they are using IPv4 or IPv6 or IPv42, such that protocol translation between different network families can be implemented where necessary.
Or, to answer you question, if networks globally all transition to IPv6, it will last forever because it will bring innovation in the network protocol family to a grinding halt. Even if someone came up with a truly amazing and brilliant network protocol that was provably better than IPv6, it would never get implemented in a world were every toaster oven and garage door opener is built with an IPv6 stack and, due to dead-end-to-dead-end ideology, is unable to communicate with anything but IPv6. Just look at the transition from IPv4 to IPv6 and how long "IPv6 has been just around the corner", then imagine the inertia on migrating from IPv6.
Sorry, but do you mean RFC 2543, RFC 2543-bis02, bis-03, bis-04 bis-05...? It got to RFC 2543-bis09, I think.
Of course, regardless of revision or RFC, it was always SIP/2.0.
Sorry, SIP was never sane. Just look at Alert-Info, particularly in early 2543. That should never have been in there.
Take a look at Session Initiation Protocol (SIP) RFC 3261 if you really want to see crazy.
Hah. The only way this will work is if they make an extremely good IPv4/IPv6 NAT gateway. Except, if they make one that does a good job such that people are going IPv4->IPv6->IPv4 and everything basically works, then people will wonder why they don't just do an extremely good IPv4 NAT solution and go IPv4->IPv4 and drop the entire IPv6 part.
Obviously, what they need to do is apply this technique to embed the message in spam messages, in the random dictionary garbage or images in the spam. The recipient then just has to know which spam messages to check for the hidden messages.
Now, we just need someone to do this to show how to smuggle information in/out of the major spam-email-producing countries, and perhaps there will suddenly be more interest in shutting down spammers.
My first mental image was a conference room full of bureaucrats and a duel flag dropping down in the middle.
Or two opposing teams of bureaucrats playing a Warsong Gulch match.
Hmm. Does anyone else think this could be the next big MMO? "That's not a red health bar on the boss -- that's how much red tape you have to cut through!"
Well, think about it this way -- why *hasn't* the transition to IPv6 gone smoother/faster? Answer: the current architecture (with its dead-end-to-dead-end philosophy) is not designed to be upgraded. Presumably, some day, some one with ambition will come up with a networking protocol that is *better* than IPv6 (not talking about bigger address space, I mean even better protocol design.) I have problems believing that in a million years we would still be running IPv6 because no one will have come up with anything better. (Maybe because it's been impossible to migrated from, but...) Ideally, IPv6 would have some design elements to make it possible to easily and quickly upgrade to future (non-IPv6) technologies faster.
The problem that making sweeping improvements has such a high cost barrier (or even a decent method for making piecemeal/gradual improvements) is in itself a problem because it slows down the development and deployment of new technologies. Which is why IPv6 has been so slow to be deployed. This is an architectural issue.
Without specifying the scenario, the answers to this question is pointless.
If you have a bunch of professionals working together, their ability to follow processes and perform will be different than if you are managing a bunch of monkeys. If all your programmers only speak Japanese, giving them a bunch programming principles written in English is not going to help. If your programming team is full of people who have been programming in Java for their entire careers in enterprise applications, then toss them into a low-level hard real-time embedded system C-only programming environment, it's going to be interesting. People apply their own perceptions and prejudices (and blind-spots) when following software design principles (or when they *think* they are following principles.)
If the only common language your programming team knows between all of them is BASIC, your application is going to end up in BASIC. If all your programmers are OO folks, your application is going to be built OO. etc. If you have a mixed team of local programming teams in different product groups in a company with different priorities vis-a-vis the project, some contractors, stuff out-sourced to a group in Asia, etc. etc. etc. Theory in software design principles can take a flying leap. Each situation is different and the importance of the skills and experience of the people involved can trump the technology or design principles.
If your vaunted software design theory ends up pounding square people into round software princple holes, things can go amazingly badly. This does not mean that the software design principle is bad. It does not mean that people are bad. It means that the design principles are not being applied properly. A herd of cats is managed and is better at different things than a pack of dogs. If you are trying to manage a group of distributed developers who are more varied than zoo, then software design principles take second stage to management principles. First, you need to figure out roughly what each group is good at, and then you can apply the proper design strategy/development principles to each groups.
This sort of theorizing is only valid in the laboratory or for small target groups in reasonably controlled circumstances. The personnel and personality issues (internal team conflicts, design blind-spots, personnel turn-over, etc.) and outside influences (changing target market/customer requirements, abrupt budget cuts, scheduling changes, etc.) tend to trump design principles in practice. In order to make such design principles work in practice, it takes a combination of constraining the domains being worked on and resources to create a (mostly) controlled environment in which to apply the principles. Few design principles can cope with situations where the outside world (or internal personality issues) are allowed free reign to interfere with the development.
So, first posit a controlled situation and specify your group of developers, and then maybe you could come up with principles that apply. Sometimes, principles that apply to one situation don't actually work in another. (Generally, for instance, commenting the code is a good idea, for instance, but the person writing the comments needs to be able to write *good* comments. If the person doing the commenting is only putting in unimportant stuff, or not aware of what they ought to be documenting, then they product crappy comments. If the person who is then going to be dealing with the comments is not experienced enough to tell good information from bad, this situation can be harmful because it creates the illusion of understanding. So, do you have a team where most of the people are inexperienced? If so, then the group design/management/development principles may need to be organized so that the experienced people are in the path to check on the work of the inexperienced, and you don't have the inexperienced people cross-checking their own code without a sanity check.)
From RFC 3261 (Session Initiation Protocol): 20.4 Alert-Info
When present in an INVITE request, the Alert-Info header field
specifies an alternative ring tone to the UAS. When present in a 180
(Ringing) response, the Alert-Info header field specifies an
alternative ringback tone to the UAC. A typical usage is for a proxy
to insert this header field to provide a distinctive ring feature.
The Alert-Info header field can introduce security risks. These
risks and the ways to handle them are discussed in Section 20.9,
which discusses the Call-Info header field since the risks are
identical.
In addition, a user SHOULD be able to disable this feature
selectively.
This helps prevent disruptions that could result from the use of
this header field by untrusted elements.
Example:
Alert-Info: <http://www.example.com/sounds/moo.wav>
Gah! That's what I get for posting in the morning.
Yeah, I goofed on the math.
Mostly I remember when I was starting out and we were still dealing with modem banks at the job. You could run down to the computer store and buy an individual modem for $X, but the per modem cost in the modem banks was something like 2X. I was boggled because I thought that buying 'in volume' should have been cheaper than buying the same number of modems from CompUSA or something. Except the modem banks were remotely manageable, had T1 or T3 interfaces, redundant power supplies, management software, number pools, etc. etc. Even so, the sticker shock per port was shocking.
Just out of curiousity, just how easy do people think it is to 'upgrade the network'? I see that brought up a lot in the comments (i.e. "AT&T should just upgrade their network" "Given Moore's Law, the network should be cheaper" etc. etc.) It certainly gives the impression that people think that a nation-wide IP network is as easy to upgrade as their personal computer as as proportionally cheap.
When I was working in telecom, network upgrades (and maintenance) could be ferociously hard. If you wanted to upgrade the link between two co-location facilities, besides the problems of running the lines, you could run into issues if you needed to upgrade your networking equipment at either end -- suddenly, you had to stock new on-site spares, make sure the technicians were prepared, deal with power, space, and cooling issues. (If you needed to replace your current router with a newer router that was physically bigger, there had to be rack space available for it. If it needed more power/cooling, that had to be available. If space/power/cooling wasn't there, *someone* had to pay for the upgrades, or you had to move to a new facility and re-home all the network connections there. Not trivial and just the man-hour costs could be huge. (And in some places, the co-locations were subject to union rules, which placed additional restrictions on work.))
(Actually, for some network facilities, the fields would refuse to go without a security escort, because they weren't going to be responsible for driving trucks full of valuable equipment into some areas and leaving them outside while they worked inside. That increased the cost noticeably.)
Most of the business plans (at the time) assumed that equipment would be paid off over a period of years, not months. People would be expensive new telecom gear and plan to pay it off over the course of three or four years so they could set their monthly rate to customers at X, rather than try to pay it off in one year by charging customers more -- the lower prices/competition may have appeared great to the customers, but once the rush of entrants into the ISP business died out and people stopped pumping money in, the equipment upgrades got stalled because business realities demanded that the providers pay off the old equipment first.
So providers had gone in with models saying they would buy equipment for their networks, charge customers X amount, and, say just for kicks, maybe 5% of that amount went to paying off equipment. Of course, every time there was an unexpected cost, or they had to lower their rates to stay competitive, less money could be used to recoup their capital expense in hardware, which meant they couldn't afford to upgrade. (Of course, at a certain point, some couldn't afford to not upgrade, either, and self-destructed.) So the 'life span' of old equipment kept going because no one could raise rates due to the competition, who also couldn't for the same reasons, and new entrants coming in with fresh capital/investments that kept the rates of the moment low. The 'rapid advances' in technology were in part due to the money being poured into the marketplace (investment of one sort or another), *not* the success of the business models. Once the party was over and the reality of the bills hit, a lot of the upgrades stalled pretty hard.
It's not that Moore's Law hasn't affected the cost of providing bandwidth, it's that people are still struggling with buried (sic) infrastructure costs from previous technology. If you feel you are paying 2004 prices for 2004 technology, network-bandwidth-wise, rather than the equivalent 2008 price/performance, it's because you probably are, because the 2004 technology is still getting paid off.
(Let's say that, oh, I could get a 48 port DSLAM for $2400, or $500 a port. So just to recoup my capex on buying that sucker, I need to make $500 per port. If I can throw $10/port a month at the hardware cost, that's 50 months, or over four years until I can justify upgrading it. It can be surprisingly