[ipv6-wg] Have we failed as IPv6 Working Group?
- Previous message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
- Next message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sander Steffann
sander at steffann.nl
Wed Oct 9 17:06:09 CEST 2019
Hi Philip, > In contrast NAT64 breaks existing systems in lots of subtle (and not so > subtle) ways. We cannot use NAT64 if we expect IPv4-only devices. I would expect such devices mostly in a home network (gaming consoles etc). On a business meeting network like RIPE the number of IPv4-only devices is negligible. > We cannot use DNS64 if we expect IPv4 literals or local DNSSEC validation. I am sure the few of us who run local DNSSEC validation would love the opportunity to make it work. Finding IPv4 literals and fixing them is a feature :) > The > 464XLAT component is complicated did cause signficant operational problems > in the past. > > The net result is that with dual stack and NAT64 we now have two options of > providing IPv6+IPv4 on a network. This is confusing to everybody who is not > a network engineer. This _is_ a RIPE meeting... > Does dual stack require more IPv4 addresses? No, there are (of course multiple) > ways to provide dual stack on wifi without consuming additional public IPv4 > addresses. Plenty of ISPs provide consumers with dual stack wifi at home > while maintaining an IPv6-only access network. There is also more and more live deployment of IPv6-only with NAT64. I am honestly surprised by the back pressure in the RIPE community. If production networks can deploy this for millions of users, why should a small conference network with a huge number of network engineers be any problem? Cheers, Sander
- Previous message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
- Next message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]