Hi Roland, Let's take it step by step, first I'm not asking the IETF to publish the document as an RFC as version 01, there are more to add.
> This is simply wrong: "IPv4 only" and "IPv6 only" hosts would not be able to > speak IPmix by definition of "only". This is a fundamental contradiction in > your proposal. "Only" means the assigned IP address for the host is either IPv4 only or IPv6 only. > If an IPv4 host would be upgraded with IPmix, there is no reason to not let > it upgrade to IPv6 and be it a dual stack host. Problem solved. IPmix is not an address as IPv6 to be assigned, the host will not be upgraded but it will be updated. IPv6 requires efforts from the client side that's why IPv6 took more than 23 years and until now no full action are taken, IPmix does not, clients are not required to do anything, if you are using IPv4 only, keep using it, but the "system" should be updated to support IPmix, which is easier than deploying IPv6. > Introducing something like IPmix would be more difficult than simply > deploying IPv6. For now, these are the requirements to call a host an IPmix host: For IPv4-only hosts --> The only requirement is that the IPv4 packet be replaced by the IPv6 packet and the IPv4 address be replaced by the IPv4-embedded IPv6 address and the host can understand an IPv6 address and insert it in the destination IP address (system update). For IPv6-only hosts --> The only requirement is that the host can understand an IPv4 address and replace it by an IPv4-embedded IPv6 address and the host can handle the packet normally (system update). All these two requirements requires no efforts from the client side, they don't have to do anything more than accepting the updates. > IPv4 only hosts would never be able to reach the whole IPv6 address space. Who said never, it is achieved in this I-D, it is true without modification to the IPv4 host. > For IPv6 only hosts we have NAT64/DNS64 to let them talk to the IPv4 world. Does this support communication using IP address rather than hostnames? Does this requires a "public IPv4 address" on the external interface of the NAT64 device? > BTW: There are still remnants of IPv.. in the document (sections 4.2 and 7). > Please remove them in any future versions as it will confuse people outside > the IETF. Modified. Regards, Khaled Omar -----Original Message----- From: Bless, Roland (TM) [mailto:[email protected]] Sent: Wednesday, November 14, 2018 10:38 AM To: Khaled Omar <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: IPmix I-D version 01. Hi Omar, > Your feedback will be appreciated for the submitted version of the > IPmix I-D. I couldn't see any substantial changes, so there are still the same issues with this proposal: - The draft states: "It solves the issue of allowing IPv6 only hosts to communicate to IPv4 only hosts and vice versa in a simple and very efficient way." => This is simply wrong: "IPv4 only" and "IPv6 only" hosts would not be able to speak IPmix by definition of "only". This is a fundamental contradiction in your proposal. If an IPv4 host would be upgraded with IPmix, there is no reason to not let it upgrade to IPv6 and be it a dual stack host. Problem solved. - Introducing something like IPmix would be more difficult than simply deploying IPv6. - IPv4 only hosts would never be able to reach the whole IPv6 address space - For IPv6 only hosts we have NAT64/DNS64 to let them talk to the IPv4 world All these issues have been mentioned before. If you don't consider them, don't expect any more comments. BTW: There are still remnants of IPv.. in the document (sections 4.2 and 7). Please remove them in any future versions as it will confuse people outside the IETF. Regards Roland _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
