Re: Market forces

[Alexandre Petrescu <[e-mail]>]

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