Re: [v6ops] IPv6 mostly for DS-Lite

["Kawashima Masanobu(川島 正伸)" <[e-mail]>]

Hi Ole, 

I'd like to share my CLAT experience. 

>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.

As one of the implementors and as a co-author of 464XLAT(RFC 6877), 
I have enough CLAT experience with CE router. 
That's why I think 464XLAT is simpler than DS-Lite at troubleshooting 
perspective. 

I've shared my experience on the chat while v6ops WG session. 
We implemented IPv4/IPv6 mixed traceroute. Please see slide 13. 
https://conference.apnic.net/34/pdf/34th_apnic_464xlat.pdf 

If host OS also implement similar IPv4/IPv6 mixed traceroute, 
we can do more simple troubleshooting. 
IPv4 address is embedded on CLAT IPv6 address. It is also simple. 

On the other hand, DS-Lite is encapsulation solution. 
So, troubleshooting is a bit hard. Because tunnel hop is black box. 

However, I know there's pros/cons with both mechanisms. 
So, I think it depends on ISP's choice. I prefer 464XLAT though. 

Regards, 
Masanobu 


-----Original Message-----
From: v6ops <[e-mail]> On Behalf Of Ole Troan
Sent: Friday, March 22, 2024 4:19 PM
To: Gert Doering <[e-mail]>
Cc: v6ops <[e-mail]>
Subject: Re: [v6ops] IPv6 mostly for DS-Lite

>> 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





_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops