Re: IPmix.

On 21 Nov. 2016 06:13, "Stephane Bortzmeyer" <bortzmeyer@nic.fr> wrote:
>
> On Sun, Nov 20, 2016 at 05:44:20PM +0000,
>  Khaled Omar <eng.khaled.omar@hotmail.com> wrote
>  a message of 848 lines which said:
>
> > You can find the new modified IPmix text RFC version attached.
>
> Strange UTF-16 encoding... Well, once decoded, I can say that:
>
> * you are very detailed when it comes of describing the current issues
> and much less so when you describe your solution;
>
> * the way I understand it (but there is zero high-level description
> of IPmix, I rely mostly on the schemas):
>
>    * everything is done by new gateways in both networks. What makes
>    you think that IPv4-only networks will deploy these gateways, when
>    they don't even deploy IPv6 (which is typically simpler)?
>
>    * what do you thing will happen to the new IPmix packets in the
>    core? Existing routers won't know what to do with them
>
> Also, your proposal is extremely sketchy and seems to ignore
> completely the issues which were discovered with the transition to
> IPv6. For instance, some applications transmit IP addresses as payload
> (which breaks things like NAT64). How do you address these?
>
> Really, the problems of migrating the Internet to a new L3 protocol
> have been discussed by many people in many years. It is unlikely that
> a 8-pages proposal will suddenly solve them.
>

A number of these sorts of proposals have been popping up in recent years.
They all seem to suffer from a lack of complete understanding about the
nature of the Internet protocols:

- forwarding in the network is stateless, meaning no details of past
forwarded packets are remembered once the packet is forwarded.

- nodes are peers of each other, meaning they can directly send and receive
packets to and from any other node on the network (i.e. *not* via an
intermediary device that translates addresses or adds options etc.),
security permitting, and can refer to themselves, to other nodes, by
providing their own IP address in upper layer protocol payloads.

IPv4 NAT breaks these properties. That's it's limitation. NATs are
vulnerable to state exhaustion (DoS) attacks because they're stateful, and
become performance and availability bottlenecks, because they force
hub-and- spoke communication.

Here's another example that suffers from these problems:

http://www.enhancedip.org

It would be good if IPv4 replacement aspirants who think they can do better
than IPv6 would read the following first:

"The Catenat Model for Internetworking"
RFC1958
RFC2993
RFC4924

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------