4 ms·

"the worse the better" http://en.wikipedia.org/wiki/Nikolay_Chernyshevsky http://en.wikipedia.org/wiki/Nikolay_Chernyshevsky

IgorPartola 12y ago
Sort of. IPv6 adoption is a matter of supply/demand economics. The supply of IPv4 is quickly approaching zero, while the demand is rising fast. At the same time the supply if IPv6 is effectively unlimited, but the demand is not there. At some point, the supply of IPv4 will go so low that its cost will suddenly jump. The cost of IPv6 deployment is still too high (mostly in human labor to set it up, and somewhat in equipment costs since some large legacy networks are not IPv6-ready). However, that jump in the IPv4 cost will price IPv6 deployment at a point much cheaper than alternatives (IPv4 large scale NAT or other workarounds). That's when we'll see a huge jump in IPv6 deployment. I think the next big step for ISP's is to provide IPv6-only native service to their clients, and add IPv6-to-IPv4 gateways to allow access to IPv4-only internet.
- zokier 12y ago
  > I think the next big step for ISP's is to provide IPv6-only native service to their clients, and add IPv6-to-IPv4 gateways to allow access to IPv4-only internet Isn't that pretty much how DS-lite works?
  - IgorPartola 12y ago
    Sort of. DS-Lite involves a Carrier Grade NAT as well. Take a look at http://en.wikipedia.org/wiki/IPv6_transition_mechanisms http://en.wikipedia.org/wiki/IPv6_transition_mechanisms for all the different possible mechanism devised so far. Edit: for my money, NAT64 + DNS64 would get us 90% of the way there. OS support for pseudo-IPv4 would really fix this 100%: if the application wants to talk IPv4, the OS would transparently translate it into an IPv6 address in the 64:ff9b::/96 address prefix.
    - wmf 12y ago
      See T-Mobile's latest presentation for details on 464: https://www.nanog.org/meetings/abstract?id=2359 https://www.nanog.org/meetings/abstract?id=2359 Personally, DS-Lite seems cleaner but I don't think it's worth arguing about.
      - zokier 12y ago
        > See T-Mobile's latest presentation for details on 464: https://www.nanog.org/meetings/abstract?id=2359 https://www.nanog.org/meetings/abstract?id=2359 From slide 8: > Mobile networks don’t use DHCP, so no way to setup MAP or DS-lite without some heavy lifting in protocols and standards Why can't the handset itself do the DS-lite IPv4 NAT/encapsulation, or why is 464XLAT easier to do on handset than DS-lite? edit: found this gold-nugget of a slide: http://i.imgur.com/VhMSA2p.png http://i.imgur.com/VhMSA2p.png ... ugh, just kinda weird/sad that this is still such an open problem.
        wmf 12y ago
        Why can't the handset itself do the DS-lite IPv4 NAT/encapsulation, or why is 464XLAT easier to do on handset than DS-lite? Yeah, I've made exactly the same argument. As you found, there's a lot of history here. As I remember it, T-Mobile was originally pitching NAT64 because it required no support on the phone at all and DS-Lite would require the phone to do encapsulation. People pointed out that DS-Lite supports v4-only apps and NAT64 does not, but it seems like T-Mobile chose not to hear that argument. Then, having already committed to the NAT64 route, they added a stateless NAT46 agent on the phone to fix v4-only apps. I think that agreeing on a standard is more valuable than continually iterating towards perfection, so I wish the industry had just declared DS-Lite "good enough" and stopped, but now we have this menagerie of transition schemes.
    - ay 12y ago
      Take a look at https://github.com/ayourtch/nat46 https://github.com/ayourtch/nat46 - I've coded it primarily for OpenWRT (so it requires forwarding), but the core portion is usable in userland as well - so I have this crude hack (https://github.com/ayourtch/example-nat46/ https://github.com/ayourtch/example-nat46/) to get something-of-a-CLAT running on OS X with zero changes to the nat46-core.[ch] code - I literally sync them between the two repos periodically.

IgorPartola 12y ago

Sort of. IPv6 adoption is a matter of supply/demand economics. The supply of IPv4 is quickly approaching zero, while the demand is rising fast. At the same time the supply if IPv6 is effectively unlimited, but the demand is not there. At some point, the supply of IPv4 will go so low that its cost will suddenly jump. The cost of IPv6 deployment is still too high (mostly in human labor to set it up, and somewhat in equipment costs since some large legacy networks are not IPv6-ready). However, that jump in the IPv4 cost will price IPv6 deployment at a point much cheaper than alternatives (IPv4 large scale NAT or other workarounds). That's when we'll see a huge jump in IPv6 deployment. I think the next big step for ISP's is to provide IPv6-only native service to their clients, and add IPv6-to-IPv4 gateways to allow access to IPv4-only internet.

zokier 12y ago
> I think the next big step for ISP's is to provide IPv6-only native service to their clients, and add IPv6-to-IPv4 gateways to allow access to IPv4-only internet Isn't that pretty much how DS-lite works?
- IgorPartola 12y ago
  Sort of. DS-Lite involves a Carrier Grade NAT as well. Take a look at http://en.wikipedia.org/wiki/IPv6_transition_mechanisms http://en.wikipedia.org/wiki/IPv6_transition_mechanisms for all the different possible mechanism devised so far. Edit: for my money, NAT64 + DNS64 would get us 90% of the way there. OS support for pseudo-IPv4 would really fix this 100%: if the application wants to talk IPv4, the OS would transparently translate it into an IPv6 address in the 64:ff9b::/96 address prefix.
  - wmf 12y ago
    See T-Mobile's latest presentation for details on 464: https://www.nanog.org/meetings/abstract?id=2359 https://www.nanog.org/meetings/abstract?id=2359 Personally, DS-Lite seems cleaner but I don't think it's worth arguing about.
    - zokier 12y ago
      > See T-Mobile's latest presentation for details on 464: https://www.nanog.org/meetings/abstract?id=2359 https://www.nanog.org/meetings/abstract?id=2359 From slide 8: > Mobile networks don’t use DHCP, so no way to setup MAP or DS-lite without some heavy lifting in protocols and standards Why can't the handset itself do the DS-lite IPv4 NAT/encapsulation, or why is 464XLAT easier to do on handset than DS-lite? edit: found this gold-nugget of a slide: http://i.imgur.com/VhMSA2p.png http://i.imgur.com/VhMSA2p.png ... ugh, just kinda weird/sad that this is still such an open problem.
      - wmf 12y ago
        Why can't the handset itself do the DS-lite IPv4 NAT/encapsulation, or why is 464XLAT easier to do on handset than DS-lite? Yeah, I've made exactly the same argument. As you found, there's a lot of history here. As I remember it, T-Mobile was originally pitching NAT64 because it required no support on the phone at all and DS-Lite would require the phone to do encapsulation. People pointed out that DS-Lite supports v4-only apps and NAT64 does not, but it seems like T-Mobile chose not to hear that argument. Then, having already committed to the NAT64 route, they added a stateless NAT46 agent on the phone to fix v4-only apps. I think that agreeing on a standard is more valuable than continually iterating towards perfection, so I wish the industry had just declared DS-Lite "good enough" and stopped, but now we have this menagerie of transition schemes.
  - ay 12y ago
    Take a look at https://github.com/ayourtch/nat46 https://github.com/ayourtch/nat46 - I've coded it primarily for OpenWRT (so it requires forwarding), but the core portion is usable in userland as well - so I have this crude hack (https://github.com/ayourtch/example-nat46/ https://github.com/ayourtch/example-nat46/) to get something-of-a-CLAT running on OS X with zero changes to the nat46-core.[ch] code - I literally sync them between the two repos periodically.