Khaled, I have never seen over the years, how draft-omar-ipv10 would have seriously added text that reflects and discusses the feedback it did receive over the years. That would have made it become a much more useful document, even if just to show that maybe the solution proposed does not offer sufficient additional value. There are at least 24+ transition solutions between IPv4 and IPv6 (https://en.wikipedia.org/wiki/IPv6_transition_mechanism), each of which targeted for one or more deployment cases where IPv6 needed to be added with the least amount of work/cost/effort and still allow to connect to IPv4. Any new proposal like yours that is primarily attempting to accelerate the adoption of IPv6 would have to present exact, practical deployment examples with topology and explanation which pieces shouldn't be updated to reduce cost, and explain how its approach results in less upgrade work compared to any of those exiting mechanisms. That is almost impossible IMHO given how many solutions there are. There is of course also the much more fundamental issue of there not being enough added value in IPv6 over IPv4 except for address exhaustion. Yes, we have done a long list of smaller enhancements, and to engineers it is quite frustrating to be told "the old is good enough, thank you very much", but to me this is just the motivation to reach further with network layer enhancements than what your IPv10 is proposing - to make it worth the while for more deployments. For example, several more recent proposals in the IETF are loooking into variable length addresses as a tool to achieve a lot more flexibility for future network services, so i think it would be a big waste to stick fixated to only existing IPv4/IPv6 addresses. Those two type of addresses should just be the most important aspects of backward compatibility for any next-generation network layer work - to avoid the forklift upgrade issue we created with IPv6 and/or those 24 transition solutions we then had to introduce to overcome the forklift. Last but not least: None of network layer innovation problems are going to be solved IMHO as long as we do not better understand how we foremost need the ability of actual parties interested in innovation to have the ability to get it deployed. Today, this limits all novel network layer innovation to overlay models in DCs at the edge of domains in VM/software. If we want to get into the underlying networks, we need that underlying network hardware to become as easily programmable by third parties as VMs in DCs are. Alas, the IRTF/COIN has not shown any interest to discuss that topic, even though to me that is the most core "compute in the network" i can think of. And it would be the logical next step beyond the current "configured slices" (programmable slices). Aka: Think beyond IPv6+4 ;-) Cheers Toerless On Tue, Sep 20, 2022 at 05:13:29PM +0000, Khaled Omar wrote: > Hi IETFers, > > I still see no progress happens in the IPv6 deployment all over the world and 5 years ago when we started to do analysis we found out now that the migration process going so slow and now the percentage according to google hits 40% which gives an alarm of the internet division due to finding blocks of IPv6 only hosts and IPv4 only hosts in the internet. > > [cid:image003.png@01D8CD25.0F2F45F0] > > I don't know why till now the IETF didn't take the IPv10 draft seriously into consideration as it would be applied since it was developed and it wouldn't take so much time to be deployed in the internet. > > I still see no better solution, not because I'm the IPv10 I-D author, but because I keep watching what's going on on the internet and I see the red flag case will be raised soon due to the incompatibility between IPv4 and IPv6. > > I hope I get positive replies because of course I'm not aware with everything happening at the IETF. > > Have a good day everyone. > > Best regards, > > Khaled Omar > Senior Service Delivery Engineer > DELL Technologies, Egypt > > -- --- tte@xxxxxxxxx
