Re: [v6ops] IPv6 mostly for DS-Lite

[Ole Troan <[e-mail]>]

>> I don???t see why we don???t make it work for every IPV6AAS.  It???s just a DHCPv4 option. We could most probably extend 108 to support it with a list of methods in the payload after the wait timer. No list implies 464XLAT.  The node would set its supported methods and the DHCP server would match against the methods it is configured for.  A registry of methods would be required.
> 
> the way to hell is paved with implementor options

… and operators options. Experience has shown that there will be just enough operators for each mechanism that it’s justified to implement.

Now, if we try to do a merit based evaluation of the options here.
Let me make up some requirements.

1. 64 edge: MUST allow sharing NAPT44 pool and NAT64 IPv4 pool
2. 46 side: MUST be independent of IPv6 addressing
3. Both: Scale, as little state as possible, transparent, possible to troubleshoot

The A+P style solutions fail on 1 and 2. So we’re left with DS-lite and 464XLAT.

464XLAT as commonly implemented also fails on 2.
464XLAT does a loss-less translation while DS-lite does encapsulation up to the 64 edge.
464XLAT hides the IPv4 packet, making it harder to troubleshoot.
Both mechanisms increase the size of the packet and will have MTU issues. RFC6877 doesn’t even have the word MTU in it.

Neither scale well, but large stateful devices can be built. It’s just a matter of cost.

I see David posted a draft trying to improve on 464XLAT troubleshooting-ness.
Would be interesting to hear implementors perspective on implementing 464XLAT CLAT so it supports 2.

DS-lite is the better choice on merit.
464XLAT has enough deployment momentum that it’s the likely winner.
May depend on how willing the 464XLAT proponents are to fix the areas where it has short-comings.

Cheers,
Ole