Ipv6 help

Thu Aug 27 08:33:55 UTC 2020

Great Write-up Mark. I have some points in-line...

> On Aug 27, 2020, at 3:12 AM, Mark Tinka <mark.tinka at seacom.com> wrote:
> 
> 
> 
> On 27/Aug/20 09:33, Brian Johnson 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?
> 
> While modern OS's prefer IPv6, it doesn't mean the end-service supports
> IPv6 yet. If the end-service only supports IPv4, the OS won't try to
> connect on IPv6.
> 

Agree and understand this.

> More importantly, a customer assigned a public IPv4 address will never
> need to use the ISP's CGN nodes. NAT44(4) will only be required for
> customers that are unfortunate enough to require connectivity at a time
> when the ISP can no longer provide a public IPv4 address to them.
> 

Let’s just say that this is happening now for a large number of regional providers.

> You can't dynamically cycle customers between public and private IPv4
> addresses based on demand. It's either they have a public IPv4 address,
> or a private IPv4 address. Not both. Yes, there are way you can do this,
> but it's not worth anyone's time and headache.
> 

Let’s say that we switch to a model of all NAT444 for IPv4, with an exception for paid static IPv4 customers and that rate is linked to the current going rate for an IP address on the market. :)

This is easily doable with any of the access platforms and routing vendors I have worked with.

> 464XLAT means customers can only live on IPv6. The ISP can put aside a
> small amount of IPv4 to bridge connectivity between an IPv6-only
> customer to an IPv4-only service for as long as that end-service is
> IPv4-only. Once that IPv4-only services wakes up, gets some clue and
> turns on IPv6 (Sony and PSN, that means you), that is one online
> resources less that the IPv6-only customers requires the 464XLAT
> translation to reach.
> 
> As more end-services turn on IPv6, there is nothing the ISP needs to do
> on the customer side, as they are already on IPv6, which was the biggest
> advantage of the NAT64/DNS64 transition mechanism, and is the biggest
> advantage of 464XLAT.
> 
> Thus, the ISP's demand for 464XLAT reduces (and eventually goes away),
> as does their need to retain whatever amount of IPv4 space they required
> to support the 464XLAT nodes.
> 

If I do dual-stack, but provide private IPv4 to the customer and NAT444 them, isn’t this accomplishing the same thing?

> Transitions mechanisms that seek to maintain IPv4 at the customer side
> expose themselves to additional migration work when the majority of the
> world is on IPv6. This is why I generally recommend ISP's (with the
> exception of my competitors, of course) to focus on 464XLAT, as when we
> get to that point, nothing needs to be done with the customer. There is
> value in that!
> 

So for 464XLAT I will need to install a PLAT capable device(s) as well as replace all CPE with CLAT capable devices ($$$$). I will also need to deal with the infancy period as I will GUARANTEE that the CPE will break badly and will create additional cost ($$$$).

For NAT444 I just need to install NAT444 router(s) . No additional cost for CPE or added troubleshooting as the existing CPE is fully baked. Agreed that customers will need help with IPv6, but that will be required either way. Also, the customer maintains a native IPv4 service (all be it NATed) until IPv4 does the dodo dance. In the end, the provider turns-off the NAT444 and disables IPv4 on their core, which has already been enabled for IPv6 when deploying dual-stack.

> Mark.
> 