Re: Market forces

[Ted Lemon <[e-mail]>]

On Nov 9, 2020, at 4:29 PM, Gyan Mishra <[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 have limited time—I’m not going to code something I don’t need.