Re: Market forces

[Ted Lemon <[e-mail]>]

Alex, nothing would prevent someone coding it, other than a wish to do what requires the least work and maintenance. 

If I didn’t think IPv4 would be required, maybe I’d do ULA+NAT66. But nobody who is actually deploying a product in a home or commercial setting is going to have that illusion. 

Your situation is a bit different: you are thinking of vehicular networking, IIRC. There it may be the case that you do not need to care about IPv4. But you probably also don’t want your brakes to be reachable from the internet, so ULA is probably fine. 

> On Nov 10, 2020, at 05:39, Alexandre Petrescu <[e-mail]> wrote:
> 
> 
> 
>> Le 09/11/2020 à 22:47, Ted Lemon a écrit :
>>> On Nov 9, 2020, at 4:29 PM, Gyan Mishra <[e-mail] <mailto:[e-mail]>> wrote:
>>> Or if the IID 64 bit boundary is eliminated the /64 would be sufficient and could be sub divided.  Now there is not any dependency on PD and even today broadband operators are still giving out /64 and not /56 or larger.  Without going down the painful NAT ULA path it makes sense to easily solve the single /64 allocation issue which exists for 3GPP PDP but also exists for wired broadband only getting a /64 via PD.  Now they wont have to wait for providers to make a change as they can now can autonomously do their own segmentation.
>> Right, but I’m certainly not going to code that up. I’m perfectly happy to stick with NAT64 for sites that don’t support IPv6 prefix delegation. As an implementor, what do I gain by splitting the IID for more subnet bits compared to just using NAT64? When I was
>> working on an open source Thread border router implementation, I
>> considered this exact thing, and concluded that supporting
>> IPv6-to-the-cloud for the case where the ISP doesn’t provide at least
>> a /60 and where the CE router doesn’t do internal PD is just a bunch
>> of unnecessary code I’d have to maintain. I _have_ to support NAT64,
>> and I get no added value when I also do NAT66 or whatever weird
>> prefix-sharing hack.
> 
> I think this brings in the reason of why it might be too early for
> Variable SLAAC with non-64 IIDs - because onne _has_ to support NAT64,
> which means one _has_ to think about IPv4 first.
> 
> While I tend to agree one has to keep IPv4 in mind for a long time when
> designing things, the question of precedence - which one is more
> important - influences how things are designed.
> 
>> I have limited time—I’m not going to code something I don’t need.
> 
> I can understand.
> 
> But would one prevent something else coding it?
> 
> Alex
> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list [e-mail] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------