Re: [v6ops] IPv6 mostly for DS-Lite

[Mark Andrews <[e-mail]>]

The market has picked both DS-lite and DNS64/NAT64. Both are deployed by ISPs.  One actually worked. The other required a series of corrections to be put out making it more visible to the IETF.

Daisy chaining DS-lite and 464XLAT will be a real mess as both use the same IPv4 address rage for source addresses.  Or are you saying only those that can get full dual stack can deploy IPv6-mostly. 
-- 
Mark Andrews

> On 22 Mar 2024, at 06:11, Brian E Carpenter <[e-mail]> wrote:
> 
> On 21-Mar-24 22:53, Ondřej Caletka wrote:
>>    DHCPv4 option 108 is tied to 464XLAT.  DS-Lite is already has per host support defined.  DS-Lite only needs an equivalent DHCPv4 option that specifies DS-Lite is supported by the node rather than 464XLAT as is indicated by 108.
>> I see the point here. I was about to point out that NAT64 stands out from all other transition mechanisms because it allows unmodified hosts to work on an IPv6-only network, while the rest of transition mechanisms require some sort of software running in each host to support the transition mechanism.
>> However, the practice shows us that running unmodified hosts on a NAT64 network is not sufficient anyway. Switching to 464XLAT with a piece of software required to run on every single host eliminates this key feature of NAT64. In that sense, 464XLAT is not in any way better or worse than DS-Lite, MAP-* or anything else.
>> Network operators should be able to choose different IPv4aaS mechanisms to use in IPv6-mostly networks. I think it would be nice if DHCP option 108 had a bit field with transition mechanisms supported by the network. Upon receiving the option, the client would decide whether it supports that particular transition mechanism and either stopped DHCP transaction, if the offered transition mechanism is supported, or continued further with native IPv4 otherwise.
>> We are probably too late to extend option 108 without interoperability issues. What could be done though would be another option with just this bitfield of supported IPv4aaS mechanisms.
> 
> Hmm. I don't think the world needs Betamax or Blu-Ray. I really think the picture is too confused and this actively damages IPv6 adoption, so please pick one, and the market seems to have picked 464XLAT.
> (It wouldn't have been my preferred choice either. The dogs bark, but the caravan moves on.)
> 
>   Brian
> 
>> Personally, I would really like to have IPv6-mostly with MAP-* so I could get a proper public IPv4 address even when running IPv6-only :)
>> --
>> Ondřej Caletka
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops