I hope I’m not adding to any confusion. I find this conversation to be interesting and want it to be productive. I have not deployed 464XLAT and am only aware of android phones having a proper client. I have worked with so many CPE devices and know that most have solid deployments of the required CLAT client. I also predict this will not change any time soon. I live in “actually works and is solid” world. Not in “I wish this would work” world.
> On Aug 27, 2020, at 2:50 AM, Mark Andrews <ma...@isc.org> wrote: > > > >> On 27 Aug 2020, at 17:33, Brian Johnson <brian.john...@netgeek.us> wrote: >> >> If an ISP provides dual-stack to the customer, then the customer only uses >> IPv4 when required and then will only use NAT444 to compensate for a lack of >> IPv4 address space when an IPv4 connection is required. What am I missing? > > Lots of assumptions people are making about how equipment is configured which > is causing people to talk past each other. > >>> On Aug 27, 2020, at 1:20 AM, Mark Andrews <ma...@isc.org> wrote: >>> >>> >>> >>>> On 27 Aug 2020, at 15:58, Bjørn Mork <bj...@mork.no> wrote: >>>> >>>> Brian Johnson <brian.john...@netgeek.us> writes: >>>> >>>>>> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same >>>>>> number of customers. >>>>> >>>>> I cannot see how this is even possible. If I use private space >>>>> internally to the CGN, then the available external space is the same >>>>> and the internal customers are the same and I can do the same over sub >>>>> ratio under both circumstance. Tell me how the math is different. >>>> >>>> Because NAT64 implies DNS64, which avoids NATing any dual stack service. >>>> This makes a major difference today. >>> >>> Only if you don’t have a CLAT installed and for home users that is suicide >>> at there is too much IPv4 only equipment. >>> >>> What really pushes traffic to IPv6 is that hosts prefer IPv6 by default. >>> This >>> works as long as the clients see a dual stack network. >>> >>> And no NAT64 does not imply DNS64. You can publish a ipv4only.arpa zone >>> with >>> the mappings for the NAT64. There are now also RA options for publishing >>> these >>> mappings. There are also DHCPv6 options. >>> >>> Mark >>> >>>> Bjørn >>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>> >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >