Ipv6 help

Mark Andrews marka at isc.org
Thu Aug 27 07:50:28 UTC 2020



> On 27 Aug 2020, at 17:33, Brian Johnson <brian.johnson at 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 <marka at isc.org> wrote:
>> 
>> 
>> 
>>> On 27 Aug 2020, at 15:58, Bjørn Mork <bjorn at mork.no> wrote:
>>> 
>>> Brian Johnson <brian.johnson at 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: marka at isc.org
>> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org




More information about the NANOG mailing list