Re: There Might Be An Alternative
1) "How can we be sure routers will honor the option fields since there are already security concerns about the option fields ": Yes, this could be a concern, potentially on purpose due to "political" positions. This is covered in Para. 4. A. Fast Path with a positive tone.
2) "how will the legacy hardware use the system if they aren't able to insert Option fields themselves? ": The proposed SPR (Semi-Public Router) will be designed with CG-NAT equivalent capability to deal with the legacy hardware during the "transition" phase (We know that this could be very long). The IP header transition examples in Appendix A. and descriptive text in Appendix B. detail this process.
3) "why not just use the same location for some kind of proxy server for those instances where an IPv4-only device MUST talk to an IPv6-only device (as a proxy is the only practical approach to bridging the protocols) ": Yes, after working out the basic scheme for extending the address pool under the constraints from the existing Internet structure, one of the deployment configurations is to just take one IPv4 public address to serve an isolated area (like an island) with up to 256M IoTs. In such case, a proxy would be utilized as the gateway to this "sub-Internet". This is mentioned in the Abstract and in Para. 3. C. c. 2. Also, you may see this even more clearly in Slide 10 of the graphic presentation whitepaper that I mentioned previously:
Although the context here is all about staying withing IPv4 domain, there is nothing preventing the WAN facing port of the proxy gateway to operate based on IPv6.
4) "using the option field seems to have incompatibility issues of its own that make it just look like IPv6 in another package": Aside from Pt. 1) above, the EzIP does not run into any baggage issues like IPv6 because we consciously avoided them following backward compatibility discipline. The interesting thing is within the "sub-Internet" as defined above, the 240/4 addresses can be, (and we recommend) used as regular Source and Destination addresses in the IP header since carrying the common external IPv4 public address for the entire island is unnecessary. In fact, it is wastefully meaningless duplication and tends to cause confusion. Please refer to Para. 3. C. c. 3. of the IETF draft. This is where the networking parallelism to PABX becomes vividly clear.
5) Hope the above are clearing up the topics. By the way, I am very grateful for the opportunity to chat with you like this in sorting out technical topics. I am curious of your background and expertise. To start with, allow me to submit you the URL to my LinkeIn profile page.
Abe (2018-07-07 18:04)