Their Captcha system choked, so I couldnt' post my reply.
|
| Author | Content |
|---|---|
| Bob_Robertson Apr 15, 2008 7:14 AM EDT |
> Converting the backbones to IPv6 is a paperchase. Exactly. It is a perfect example of bureaucratic waste. NAT turned out to be a wonderfully elegant and simple answer to the problem of a huge influx of users to the 'Net. The demise of IPv4 has thereby been not just "put off", but practically eliminated. All of AOL behind, what, 62 addresses? Entire companies with a single routable IPv4 address on their public-facing router, and at the same time eliminating the most dangerous attack vector for computer security completely. No incoming sessions, period. IPv6 was developed when IPv4 looked like it was going to crash "any time now". That certainly has not happened, and the "feature bloat" of IPv6 has become obsolete. Stripping out IPv6's cruft, leaving nothing more than the increase in address space and static header size, would be a _real_ improvement. Unfortunately, due to Second System Syndrome, that ain't gonna happen. The "need" for every machine to be directly addressable from every other machine has been shown to be an illusion, a remnant of an "INTERnet" that was little more than a bunch of students and professors all doing the same thing. Even IPv6 has "private" address blocks defined, recognizing this reality that NAT is in fact efficient. I had an IPv6 tunnel for a while, with the same experience of having it deleted for lack of use. The transition from IPv4 to IPv6 is already built into IPv6's feature bloat. There's no need for fancy logical twisting when the "last 4 bytes" of IPv6 can be directly replaced by the entire "4 bytes" of IPv4. So, if it's going to happen, let's just do it already. Where is the Debian package "IPv4_IPv6_Gateway_Proxy_Router-0.1.13-dfsg.deb"? I know I have a spare 500MHz Celeron sitting in the garage I can dedicate to the task... |
| Sander_Marechal Apr 15, 2008 7:25 AM EDT |
Quoting:All of AOL behind, what, 62 addresses? Any you think that's a good idea? |
| tuxchick Apr 15, 2008 7:40 AM EDT |
Gah. I hate NAT, and would not call it "elegant", but a hack born of necessity. Every service in existence requires some kind of NAT hackery. Getting services through NAT is inefficient and hurts performance, because every single packet header must be read and re-written and handled multiple times. You can see this with some simple throughput tests using iperf- a 50% speed loss with NAT is common. Most folks don't understand IPv6, so here is a brief roundup of some of its advantages: -Enough addresses for the galaxy (hey, you never know- when you buy your dream vacation home on Pluto, you'll be glad your personal address space is big enough to include it) -Calculating and managing subnetting is a whole lot easier than v4 -You can still have NAT if you really want it, and it will be an option, not a requirement -There are two separate private addressing spaces. FC00::/7 and FE80::/10. Most Linux distributions automatically create a FE80::/10 (unique local unicast) address for you. -Routing is easier and more efficient, routing tables are smaller -Real QoS that actually works and is way easier than in v4, so streaming multimedia works a lot better -Real, instead of hackish, network autoconfiguration The biggest barriers to adoption are: 1. The United States hogs nearly 60 percent of the usable v4 address space, so the rest of the world is far ahead of us in v6 deployments 2. ISPs make money selling public routable addresses, which they can do only because they are scarce 3. Inertia and not wanting to spend money to upgrade antique equipment, which is outdated in several ways anyway and not just IP addressing, like old and slow Of course the smart owners of the Linux Networking Cookbook know all this already, and understand IPv6 addressing and how to test v6 networking with their own hands :) |
| Bob_Robertson Apr 15, 2008 8:32 AM EDT |
> Any you think that's a good idea? Yes, for all the reasons stated. Putting "consuming" users behind NAT makes them virtually immune to external network attack. > Every service in existence requires some kind of NAT hackery. Haha, might as well call going to IPv6 "hackery". I do find it interesting that with my summation being "Let's get on with it", your reply seems to be starting from the position that I don't want IPv6. Fascinating. > Real QoS Just a perfect example of the feature bloat inherent in IPv6. Design the network adequately, QoS isn't needed. Smart hosts, dumb network. The job of the network is to get packets from here to there. If they don't, then that's a network _fault_ and needs to be fixed. Glossing over problems with QoS is, let me see if I can find the right words... "and would not call it "elegant", but a hack". I don't disagree that NAT introduces complexity. So does QoS. By "efficient" I meant from the standpoint that using it solves more than just one problem. It's negatives are outweighed by its positives. Of course not having to process NAT reduces latency. I consider that just another argument for as dumb a network as possible for maximum packet transmission efficiency. > -Calculating and managing subnetting is a whole lot easier than v4 I only take issue with this comment because the issues with calculating and managing subnetting are _identical_. v6 just has so much address space that creating huge waste making things look pretty doesn't make any difference. |
| softwarejanitor Apr 15, 2008 8:42 AM EDT |
>>All of AOL behind, what, 62 addresses?
>Any you think that's a good idea? I thought it was a bad idea when AOL connected to the Internet at all! It brought along vast numbers of clueless noobs which have wreaked havok on all that was good about it. They really were one of the last straws that ruined USENET. |
| tuxchick Apr 15, 2008 9:13 AM EDT |
Quoting: I do find it interesting that with my summation being "Let's get on with it", your reply seems to be starting from the position that I don't want IPv6. Fascinating. Go back to bed and try getting up on the other side! I didn't even imply that, sheesh! Do I have to start using [friendly tone] tags? Quoting: So, if it's going to happen, let's just do it already. That works for me, and the rest of the civilized world. It's primarily the US that's dragging its feet. Quoting: > Real QoS Just a perfect example of the feature bloat inherent in IPv6. Design the network adequately, QoS isn't needed. How would you do that? Streaming media requires low latency and no queueing. Data traffic does fine with queueing. When they're both sharing the same wires and protocols, it makes sense to me to implement QoS in TCP/IP. Then everyone supports the same protocol, no muss no fuss. QoS is present in v4, but it's mostly ignored. The only place you can use it reliably is on networks you directly control. **edit** oho, which brings us back to making money off fake scarcity- for example, if you want high-quality VoIP, right now your best option is to pay extra wads of money to your telco. Because they control the wires, and will implement good QoS for you. For a price. **yet another edit** You don't need NAT to keep your local private clients hidden from untrusted networks- v6 has other mechanisms for doing this, which I don't understand well enough to explain. But if anyone cares, I'll dig up some links. |
| Bob_Robertson Apr 15, 2008 10:34 AM EDT |
> How would you do that? ... The only place you can use it reliably is on networks you directly control. I don't see any indication of this changing. If you can tell me how IPv6 changes how I can reliably control someone else's network, I'm all ears (eyes, anyway). > Because they control the wires, and will implement good QoS for you. For a price. Again, I don't see this being any different. I can QoS all day long on my network. As soon as it goes onto someone else's, it's prayer and service level agrements. $$. > Streaming media requires low latency and no queueing. Only if you require low latency and no queueing. YouTube and wcpe.org seem to be doing fine. If you mean in real time, then I couldn't agree more. But anyone relying on other people's networks for real time support is either going to be disappointed, pay through the nose, or use dedicated bandwidth pipes. Which are exactly what you give as negative examples as if burdening the core protocol with QoS is going to avoid them. I see no evidence that QoS is going to be any less ignored in v6 than it is in v4. Therefore, I prefer to build the network so as to avoid problems in the first place. I don't see where we disagree except in approach. I prefer my network dumb, reliable and fast. |
| dinotrac Apr 15, 2008 12:46 PM EDT |
Bob - TC: Behave yourselves or I'll send a pickpocket packet to picket. |
| tuxchick Apr 15, 2008 1:04 PM EDT |
But Bob said a nasty word. He said NAT. |
| dinotrac Apr 15, 2008 1:33 PM EDT |
Shame on him. On the other hand, you should remember we need NAT to have King Cole, and that is a beautiful thing. |
| Sander_Marechal Apr 15, 2008 1:50 PM EDT |
Quoting:> Any you think that's a good idea? You sound like you've never ran services at the other end of the network then. Blocking a DDoS or persistent spam bot on AOL is nigh impossible because you'll be blocking all of AOL. No, that's not an error. You'll be blocking 1/62th of AOLs IP addresses, but thanks to AOLs round-robin proxy and NAT two subsequent requests from the same AOL user can use a different IP address. In order to block an AOL user you need to block *all* AOL IP addresses. Quoting:> Real QoS And who will pay for the pipes? There don't exist big enough pipes to route streaming media without some kind of QoS. I don;t care my e-mail shows up a second later. I do care that my audio stream has a 1 second gap in it. IPv6 does have it's share of feature bloat and second-system effect, but QoS isn't one of them. Quoting:Of course not having to process NAT reduces latency. I consider that just another argument for as dumb a network as possible for maximum packet transmission efficiency. That's an argument in favour of IPv6. You can't create that kind of dumb network in IPv4. Not enough addresses to go around. |
| Bob_Robertson Apr 15, 2008 2:14 PM EDT |
> And who will pay for the pipes? There don't exist big enough pipes to route streaming media without some kind of QoS. The same people will pay who want it to work. Why should someone else's network pay any attention to what I flag as "high QoS"? They have their own priorities. So unless I pay them extra, they'll ignore it. ...which is exactly what we have now. > That's an argument in favour of IPv6. You can't create that kind of dumb network in IPv4. Not enough addresses to go around. I didn't say I wasn't in favor of the increased address space. I'm all for it. I'm also in favor of lowering latency. But I also consider NAT to be an excellent tool. I am not going to avoid NAT unless the requirements of the job require it. > You sound like you've never ran services at the other end of the network then. Blocking a DDoS or persistent spam bot on AOL is nigh impossible because you'll be blocking all of AOL. Posting my resume would only prove that I have dealt mostly with the stuff in the middle. Routers, switches, POTS to SS5, a seemingly infinite list of different hardware protocols and standards, everything from RIP1 to BGP4, LAN to world-wide WAN. The way I look at it, if AOL's customers are misbehaving, then blocking AOL is just fine. But at the same time I would be in contact with AOL to tell them why, and help them discover which of their customers is ruining it for everyone else. |
| Sander_Marechal Apr 15, 2008 2:49 PM EDT |
Quoting:The same people will pay who want it to work. You'd pay $1000/month for a 4Mbit/512Kbit ADSL connection? Quoting:...which is exactly what we have now. I'm probably misubderstanding, bur are you arguing the current IPv4 internet doesn't use QoS? Quoting:I am not going to avoid NAT unless the requirements of the job require it. That's designing solutions the wrong way around. With IPv6 you should use NAT when the job at hand requires. Either for technical reasons or because your clients wrote it in the requirements. Implementing stuff because it doesn't say anywhere that you shouldn't is bad designing. IPv6 isn't IPv4 so don't design an IPv6 network like you would and IPv4 network. Quoting:at the same time I would be in contact with AOL to tell them why, and help them discover which of their customers is ruining it for everyone else. You really haven't been on the other end point :-) |
| Bob_Robertson Apr 15, 2008 5:03 PM EDT |
> You'd pay $1000/month for a 4Mbit/512Kbit ADSL connection? Nope. Neither would I expect my QoS tags to be honored by the ISP or their backbone. If you want QoS, expect to pay for it. Having QoS does not avoid the costs of building/maintaining a network that can handle the requirement. It is merely a method of prioritizing the use. Paying for priority might very well cost $1000/mo. When I have such a requirement, then I'll have the money. Until then, buffering 15 seconds of audio/video to cover transit variations is just fine by me. Tuxchick doesn't want that delay, so she'll end up paying for the priority. IPv6 doesn't make any difference. > Implementing stuff because it doesn't say anywhere that you shouldn't is bad designing. All I said was that I wouldn't avoid it. If my judgement as a network engineer is that the situation is best served by using NAT, I will design it that way. If the customer overrides, that's fine. But they hired _me_ so they could get the benefit of 20 years experience. Otherwise, they can go hire some MCSE and save themselves a lot of money. You are correct that IPv6 has much less reason to consider NAT, but again I'm not going to dismiss it out of hand. It is a tool, with good uses. > You really haven't been on the other end point :-) As I said, I'm not a server nerd. I'm a network geek. On the other hand, your reaction reminds me of trying to work with SPRINT's network operations people. Even AT&T were easier to work with. With SPRINT, if they didn't have a prepared menu item for what they thought I called about, they were useless. And worst of all, they wouldn't escalate to someone who _would_ understand unless threatened with hellfire and brimstone (or dropping a Space Shuttle on them). Menu-driven idiots. So when MCSEs arrived on the scene, who cannot do anything without a GUI "wizard", I already had a ready frame of reference with which to understand them. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!