Besides, who would the money for the IP addresses go to? IANA? What would they use it for?
More importantly, what do they do if I respond to their demand for my money by telling them to go Cheney themselves? Oh, wait— I get it. This is some poor deluded child who thinks I should recognize his personal monarchy as the Internet taxing authority.
When you're facing a huge pile of unused nails. Every tool begins to look like a hammer.
Not very bloody likely. What you're likely to see is ISP's charging per DHCP6 lease, with maybe a little bit extra (but probably not) if you want a prefix delegation for your router.
Your ISP has a huge incentive to give you a routable prefix for your network: they want to be able to sell you application services that depend on their ability to communicate with nodes on your network that you put there for them to manage or query.
Except that it is relevant. You don't really need to find an ISP that supports IPv6 over native links. You only need to find one that supports IPv6 at a decent level of reliability full stop. Whether it's native or tunneled IPv6 isn't really that important.
Also, those long RTTs are a problem for everybody on IPv6 today, not just the poor suckers on the end of sketchy/losing tunnels.
"for most of us there are no options other than sketchy/slow tunnels"
Easy there. The tunnel provided by my ISP [sonic.net] is rock solid. Deployed properly, tunnels can be made quite reliable. In fact, there's a pretty good chance your IPv4 service is tunneled over something right now.
"The right way would have been to extend the address space while still obeying to the KISS principle."
The IETF has considered so many proposals along this line that it just produces eye-rolls from the greybeards now. They don't work any better than IPv4 w/ NAPT extensions, they still don't preserve backward compatibility with IPv4, and they don't solve the problems that IPv6 does.
If you think you're smarter than everybody who's tried to do this before, then write up an Internet Draft. What's stopping you?
Sigh. NAT has always been about mitigating localized IPv4 address shortage, i.e. your ISP wants to charge you $20/month for every IP address you use, not for the IPv4 dialtone to your router. It has never been about security, except that most of the functions of a stateful firewall are required to do NAT properly.
Maybe your Network Attached Toaster doesn't need a globally routed IP address. With IPv4, you'd give it an RFC 1918 private address, then configure your NAT/firewall so that it isn't allowed to make outbound connections. Do you know anybody who has ever done that? Most home routers don't even make that possible in the user interface. With IPv6, you'd just give your toaster a non-globally routed address. Full stop. No firewall configuration magick necessary. I can see why that might be a frightening concept to some people.
Me? I get by just fine with a traditional toaster that doesn't have any network ports.
You are confusing the concept of a firewall with the concept of a network address translator. With IPv6, you don't NAT, but you can still firewall. In fact, a NAT makes a firewall weaker, not stronger, because it prevents the interior routing domain from being reflected in the flows that it polices which legitimately originate from the exterior. As a result, applications resort to a host of NAT traversal techniques that firewalls can't police because they don't have enough information to do so. This problem goes away when you get rid of the NAT.
Apple also hasn't been very diligent about updating their IPv6 stack. They've been taking security patches, but that's about it. Most of the useful features of IPv6 are not available on Mac OS X, e.g. MLDv2, DHCP6, source address selection, mobility, etc. Apple also doesn't have a public roadmap for its IPv6 features in future OS X releases.
On the other hand, the emerging consensus in the BEHAVE and SOFTWIRE groups appears to be that port randomization isn't beneficial enough in mitigating the general class of port spoofing attacks to warrant rejecting on that grounds alone the various schemes in play for allowing service providers to aggregate multiple subscribers behind the same public IPv4 address while maintaining the network address translation at the subscriber site by slicing up the public port range available to each site.
Don't worry. I'm sure the robots will save us all in the end.
Yeah, but you say that like it's not as good as the real thing. I'm a Sonic.Net customer, and I use an AirPort base station as my IPv6 tunnel endpoint. My home network is fully dual-stack, and the Sonic.Net tunnel is just as reliable as the rest of their service. I'm a huge fan of Sonic.Net.
A similar issue arises with providers who place their subscribers behind twice-NAT on addresses they aren't stealing from somebody else. The free Wi-Fi service on the commuter shuttles provided by my employer is operated by an ISP that does this. It mostly works, except when it falls over and dies.
Why would you do this? So that you can conserve your own IP address space without having to worry about address realm conflicts between your subscribers and the services you are providing to them. Why does this suck? As you know, Bob, it's because applications quite naturally assume that any IPv4 address outside the RFC 1918 ranges are global scope. (That's because— you know— they are.)
So these applications assume they can stop attempting their NAT traversal strategy because they think they've fixed the public address properly when they really haven't.
I do so dearly love people who refuse to learn the lessons of RFC 3424.
I am so goddamned tired of explaining to people why privacy is important that I've just stopped trying. I'm also up to my eyeballs in karma I never use, so there you go...
Right now, they charge an additional fee for each DHCP lease you consume. Since DHCP6 has an IPv6 prefix delegation option, you can expect that your home gateway will get at least a/64, and probably a/56 or better (depending on the outcome of discussions in IETF around this active Internet Draft currently in the RFC Editor Queue.
"When every lightbulb has an IP address, the vast address range of IPv6 sounds like a pretty good idea."
Sigh. It would be nice of the know-nothings who keep mocking IPv6 for its 128-bit address space would read RFC 4941, and take the time to comprehend what it means, before spouting off.
Wrong wrong wrong. The reason we're turning off the analog television stations is to reclaim the spectrum. There is no need to "reclaim" the IPv4 protocol. We do not need to turn off IPv4 to use IPv6. I certainly didn't.
No, there will just be some hosts that will not get public IPv4 addresses. This is why service providers are moving to carrier-grade NAT solutions. In fact, it remains to be seen whether IPv6 transition will ever overtake the widespread adoption of NAT444.
Oh, and I wouldn't get too wound up about not having a good replacement for NAT-PT. Nobody who needs to communicate with IPv4-only hosts really needs to be IPv6-only. They can just deploy dual-stack and forget about the NAT-PT problem.
It was implemented. Nobody seriously deployed it because it didn't work very well. IETF deprecated it because, if people kept deploying it, then it would be harder— not easier— to deploy another system that works correctly.
Realistically, here's how residential users are going to be transitioned to IPv6...
+ More carriers (some already do this) will start putting their basic service customers behind carrier-grade NAT boxes. They will not allow port forwarding or UPnP. For that you pay extra for a public IPv4 address and run your own NAT box. (How much extra? Probably about US$5.00 to US$10.00 per month.)
+ A few years later, some carriers will be offering IPv6 service to their basic level customers alongside the carrier-grade NAT service. You'll probably get a/56, whether you want one or not (because the carrier will want to put boxes in your house that it can talk to and you can't). To get this service, you'll be using an integrated router provided by your carrier. Again, if you want to run your own router, you pay extra.
+ The IPv6 public Internet will be badly split into three separate domains, none of which will interwork with one another very well at all, and not with any measurable reliability. Those domains will be: A) the native IPv6 internet, B) the 6to4 tunneled internet, and C) the Teredo tunneled internet. Why will there be this split? Because service providers will not deploy relay routers in their networks.
+ At that point, I predict further development will stop. The case for IPv6 is so service providers can have access to the interiors of residential subscriber networks. There is no useful feature of IPv6 that will be provided to subscribers, e.g. origination of source-specific multicast, any kind of participation in embedded-rendezvous any-source multicast, mobility, security, et. al.
+ To address the scaling problem posed by NAT44 and NAT444 architectures, the major web application sites will shift to session layer multiplexing over transport connections. This will stave off the need for them to transition to IPv6.
You know, here in the 21st century, we have these things called domain name servers, and they even work in tandem with address configuration systems to dynamically keep the hostname matched up with the network address as it gets renumbered.
You should look into how they work. They're really quite remarkable, and it sure beats having to copy/etc/hosts around to all your computers by floppy disk.
No. NAT-PT really was a bad idea, because it required the network address translator and the domain name rewriter to be tightly coupled in the same box, and that scales not at all well.
The new proposals in IETF to replace NAT-PT all separate these aspects of the problem into more loosely coupled components. You want to know more about them? See the wiki for the upcoming IETF Internet Area interim meeting.
I'm actually thinking of devices, like phones and other personal mobile gadgets, that need to keep their wireless network interfaces in power-save mode most of the time to keep their battery life in the acceptable range. What this has to do with NAT: if you have to wake up every N seconds to send a bubble packet to keep the NAT from closing your otherwise unused hole to the not-very-scalable rendezvous server, then you can say goodbye to your battery life.
Now tell me how Skype is going to work in an environment where everyone needs for their machine to be asleep— to conserve battery charge— when it's passively waiting for incoming calls.
Slashdot Mirror
Besides, who would the money for the IP addresses go to? IANA? What would they use it for?
More importantly, what do they do if I respond to their demand for my money by telling them to go Cheney themselves? Oh, wait— I get it. This is some poor deluded child who thinks I should recognize his personal monarchy as the Internet taxing authority.
When you're facing a huge pile of unused nails. Every tool begins to look like a hammer.
Not very bloody likely. What you're likely to see is ISP's charging per DHCP6 lease, with maybe a little bit extra (but probably not) if you want a prefix delegation for your router.
Your ISP has a huge incentive to give you a routable prefix for your network: they want to be able to sell you application services that depend on their ability to communicate with nodes on your network that you put there for them to manage or query.
Except that it is relevant. You don't really need to find an ISP that supports IPv6 over native links. You only need to find one that supports IPv6 at a decent level of reliability full stop. Whether it's native or tunneled IPv6 isn't really that important.
Also, those long RTTs are a problem for everybody on IPv6 today, not just the poor suckers on the end of sketchy/losing tunnels.
"for most of us there are no options other than sketchy/slow tunnels"
Easy there. The tunnel provided by my ISP [sonic.net] is rock solid. Deployed properly, tunnels can be made quite reliable. In fact, there's a pretty good chance your IPv4 service is tunneled over something right now.
"The right way would have been to extend the address space while still obeying to the KISS principle."
The IETF has considered so many proposals along this line that it just produces eye-rolls from the greybeards now. They don't work any better than IPv4 w/ NAPT extensions, they still don't preserve backward compatibility with IPv4, and they don't solve the problems that IPv6 does.
If you think you're smarter than everybody who's tried to do this before, then write up an Internet Draft. What's stopping you?
Sigh. NAT has always been about mitigating localized IPv4 address shortage, i.e. your ISP wants to charge you $20/month for every IP address you use, not for the IPv4 dialtone to your router. It has never been about security, except that most of the functions of a stateful firewall are required to do NAT properly.
Maybe your Network Attached Toaster doesn't need a globally routed IP address. With IPv4, you'd give it an RFC 1918 private address, then configure your NAT/firewall so that it isn't allowed to make outbound connections. Do you know anybody who has ever done that? Most home routers don't even make that possible in the user interface. With IPv6, you'd just give your toaster a non-globally routed address. Full stop. No firewall configuration magick necessary. I can see why that might be a frightening concept to some people.
Me? I get by just fine with a traditional toaster that doesn't have any network ports.
You are confusing the concept of a firewall with the concept of a network address translator. With IPv6, you don't NAT, but you can still firewall. In fact, a NAT makes a firewall weaker, not stronger, because it prevents the interior routing domain from being reflected in the flows that it polices which legitimately originate from the exterior. As a result, applications resort to a host of NAT traversal techniques that firewalls can't police because they don't have enough information to do so. This problem goes away when you get rid of the NAT.
Apple also hasn't been very diligent about updating their IPv6 stack. They've been taking security patches, but that's about it. Most of the useful features of IPv6 are not available on Mac OS X, e.g. MLDv2, DHCP6, source address selection, mobility, etc. Apple also doesn't have a public roadmap for its IPv6 features in future OS X releases.
On the other hand, the emerging consensus in the BEHAVE and SOFTWIRE groups appears to be that port randomization isn't beneficial enough in mitigating the general class of port spoofing attacks to warrant rejecting on that grounds alone the various schemes in play for allowing service providers to aggregate multiple subscribers behind the same public IPv4 address while maintaining the network address translation at the subscriber site by slicing up the public port range available to each site.
Don't worry. I'm sure the robots will save us all in the end.
Yeah, but you say that like it's not as good as the real thing. I'm a Sonic.Net customer, and I use an AirPort base station as my IPv6 tunnel endpoint. My home network is fully dual-stack, and the Sonic.Net tunnel is just as reliable as the rest of their service. I'm a huge fan of Sonic.Net.
A similar issue arises with providers who place their subscribers behind twice-NAT on addresses they aren't stealing from somebody else. The free Wi-Fi service on the commuter shuttles provided by my employer is operated by an ISP that does this. It mostly works, except when it falls over and dies.
Why would you do this? So that you can conserve your own IP address space without having to worry about address realm conflicts between your subscribers and the services you are providing to them. Why does this suck? As you know, Bob, it's because applications quite naturally assume that any IPv4 address outside the RFC 1918 ranges are global scope. (That's because— you know— they are.)
So these applications assume they can stop attempting their NAT traversal strategy because they think they've fixed the public address properly when they really haven't.
I do so dearly love people who refuse to learn the lessons of RFC 3424.
I am so goddamned tired of explaining to people why privacy is important that I've just stopped trying. I'm also up to my eyeballs in karma I never use, so there you go...
Right now, they charge an additional fee for each DHCP lease you consume. Since DHCP6 has an IPv6 prefix delegation option, you can expect that your home gateway will get at least a /64, and probably a /56 or better (depending on the outcome of discussions in IETF around this active Internet Draft currently in the RFC Editor Queue.
"When every lightbulb has an IP address, the vast address range of IPv6 sounds like a pretty good idea."
Sigh. It would be nice of the know-nothings who keep mocking IPv6 for its 128-bit address space would read RFC 4941, and take the time to comprehend what it means, before spouting off.
"governments have to mandate IPv6 changeover"
Wrong wrong wrong. The reason we're turning off the analog television stations is to reclaim the spectrum. There is no need to "reclaim" the IPv4 protocol. We do not need to turn off IPv4 to use IPv6. I certainly didn't.
No, there will just be some hosts that will not get public IPv4 addresses. This is why service providers are moving to carrier-grade NAT solutions. In fact, it remains to be seen whether IPv6 transition will ever overtake the widespread adoption of NAT444.
Oh, and I wouldn't get too wound up about not having a good replacement for NAT-PT. Nobody who needs to communicate with IPv4-only hosts really needs to be IPv6-only. They can just deploy dual-stack and forget about the NAT-PT problem.
It was implemented. Nobody seriously deployed it because it didn't work very well. IETF deprecated it because, if people kept deploying it, then it would be harder— not easier— to deploy another system that works correctly.
I'm sorry. I guess I shouldn't have erased those RFCs from the Internet. I'll try to remember not to do that next time.
Realistically, here's how residential users are going to be transitioned to IPv6...
+ More carriers (some already do this) will start putting their basic service customers behind carrier-grade NAT boxes. They will not allow port forwarding or UPnP. For that you pay extra for a public IPv4 address and run your own NAT box. (How much extra? Probably about US$5.00 to US$10.00 per month.)
+ A few years later, some carriers will be offering IPv6 service to their basic level customers alongside the carrier-grade NAT service. You'll probably get a /56, whether you want one or not (because the carrier will want to put boxes in your house that it can talk to and you can't). To get this service, you'll be using an integrated router provided by your carrier. Again, if you want to run your own router, you pay extra.
+ The IPv6 public Internet will be badly split into three separate domains, none of which will interwork with one another very well at all, and not with any measurable reliability. Those domains will be: A) the native IPv6 internet, B) the 6to4 tunneled internet, and C) the Teredo tunneled internet. Why will there be this split? Because service providers will not deploy relay routers in their networks.
+ At that point, I predict further development will stop. The case for IPv6 is so service providers can have access to the interiors of residential subscriber networks. There is no useful feature of IPv6 that will be provided to subscribers, e.g. origination of source-specific multicast, any kind of participation in embedded-rendezvous any-source multicast, mobility, security, et. al.
+ To address the scaling problem posed by NAT44 and NAT444 architectures, the major web application sites will shift to session layer multiplexing over transport connections. This will stave off the need for them to transition to IPv6.
You know, here in the 21st century, we have these things called domain name servers, and they even work in tandem with address configuration systems to dynamically keep the hostname matched up with the network address as it gets renumbered.
You should look into how they work. They're really quite remarkable, and it sure beats having to copy /etc/hosts around to all your computers by floppy disk.
No. NAT-PT really was a bad idea, because it required the network address translator and the domain name rewriter to be tightly coupled in the same box, and that scales not at all well.
The new proposals in IETF to replace NAT-PT all separate these aspects of the problem into more loosely coupled components. You want to know more about them? See the wiki for the upcoming IETF Internet Area interim meeting.
I'm actually thinking of devices, like phones and other personal mobile gadgets, that need to keep their wireless network interfaces in power-save mode most of the time to keep their battery life in the acceptable range. What this has to do with NAT: if you have to wake up every N seconds to send a bubble packet to keep the NAT from closing your otherwise unused hole to the not-very-scalable rendezvous server, then you can say goodbye to your battery life.
More scalability. You can pack more customers behind the same NAT with APD filtering behavior than with EI or AD behavior.
Now tell me how Skype is going to work in an environment where everyone needs for their machine to be asleep— to conserve battery charge— when it's passively waiting for incoming calls.