Quand je lis les specs du MPTCP je n'arrive pas à me sortir de la tête que c'est juste une façon d'obtenir la même chose qu'avec de l'IPv6 Mobile mais sans passer à IPv4.
Je suis bien conscience qu'il y a des différences au niveau du protocole (je connais la dissociation IP/TCP) mais bon, IPv6 mobile était un truc qui devait permettre de rerouter rapidement (et à la volée) une machine (bon OK une interface) qui se déplace sur différents réseaux. MPTCP permet de faire la même (suivre un déplacement sur différent réseaux) chose au niveau connexion/session plutôt qu'au niveau machine.
Le premier problème que je vois est celui du double emploi - grosso-modo 80% des cas d'application de IPv6 mobile sont couverts par MPTCP (c'est à dire en pas se faire jeter et ne pas avoir à se réauthentifier en cas de changement de réseau).
Après pour les cas suivants (être capable de retrouver une machine ou qu'elle soit sur les réseau) il suffit d'écrire un petit démon qui balance un paquet de temps en temps pour permettre le seuivi. (une fosi qu'on aura les bonnes libs MPTCP ce petit démon devra peser dans les 50 lignes de codes et sera probablement donné en exemple dans la lib elle même).
Le second problème que ca pose est celui du déploiement. Le gros avantage d'IPv6 mobile (connexion continue avec un appareil mobile) est en train de partir à la poubelle. A partir de là on peut légitimement se demander si les opérateurs veront un interêt quelconque à déployer IPv6 mobile :Dans un cas j'achète du matos, je fais des tables de routages dynamiques et modifiées plusieurs fois par seconde si j'ai beaucoup de client, dans l'autre je met à jour le firmware de l'existant et je reste en v4 (Je veux pas être méchant mais le choix est vite fait…) Or si les opérateurs mobiles déploient MPTCP à la place de IPv6 mobile - on peut considérer que la norme IPv6 mobile est morte (non pas qu'elle soit super vivante en ce moment, ni qu'elle l'ait jamais été. Déjà IPv6 tout court…)
Le troisième problème que ca pose est celui du hack TCP pour pas passer en IPv6. Il y a 5 ou 6 ans je racontais en rigolant devant un commité d'experts ( https://linuxfr.org/board ) que les boites ne passeraient jamais en IPv6 (trop couteux et pas rentable du tout pour les premiers à faire le pas) et qu'on aurait à la place des hacks TCP qui permettrait de passer de 65536 ports à 16 millions. Comme ça NAT pour tout le monde et on en parle plus. C'était rigolo à l'époque - mais aujourd'hui ca me fait plus rire.
Donc si quelqu'un peut me dire que je me trompe (avec argument à l'appui - les one-liners "tu te trompes" et les "comment peut-on être assez @"!ù!! pour croire que" s'abstenir) ca me rassurerait. Je souhaite sincèrement être passé à coté d'une fonction IPv6 qui ne soit implémentable en 100 lignes de codes avec mptcp.
# Je sens que je vais me faire traiter de troll mais ...
Posté par Kaane . En réponse à la dépêche MPTCP, TCP dans un monde ultra‐connecté. Évalué à 9.
Quand je lis les specs du MPTCP je n'arrive pas à me sortir de la tête que c'est juste une façon d'obtenir la même chose qu'avec de l'IPv6 Mobile mais sans passer à IPv4.
Je suis bien conscience qu'il y a des différences au niveau du protocole (je connais la dissociation IP/TCP) mais bon, IPv6 mobile était un truc qui devait permettre de rerouter rapidement (et à la volée) une machine (bon OK une interface) qui se déplace sur différents réseaux. MPTCP permet de faire la même (suivre un déplacement sur différent réseaux) chose au niveau connexion/session plutôt qu'au niveau machine.
Le premier problème que je vois est celui du double emploi - grosso-modo 80% des cas d'application de IPv6 mobile sont couverts par MPTCP (c'est à dire en pas se faire jeter et ne pas avoir à se réauthentifier en cas de changement de réseau).
Après pour les cas suivants (être capable de retrouver une machine ou qu'elle soit sur les réseau) il suffit d'écrire un petit démon qui balance un paquet de temps en temps pour permettre le seuivi. (une fosi qu'on aura les bonnes libs MPTCP ce petit démon devra peser dans les 50 lignes de codes et sera probablement donné en exemple dans la lib elle même).
Le second problème que ca pose est celui du déploiement. Le gros avantage d'IPv6 mobile (connexion continue avec un appareil mobile) est en train de partir à la poubelle. A partir de là on peut légitimement se demander si les opérateurs veront un interêt quelconque à déployer IPv6 mobile :Dans un cas j'achète du matos, je fais des tables de routages dynamiques et modifiées plusieurs fois par seconde si j'ai beaucoup de client, dans l'autre je met à jour le firmware de l'existant et je reste en v4 (Je veux pas être méchant mais le choix est vite fait…) Or si les opérateurs mobiles déploient MPTCP à la place de IPv6 mobile - on peut considérer que la norme IPv6 mobile est morte (non pas qu'elle soit super vivante en ce moment, ni qu'elle l'ait jamais été. Déjà IPv6 tout court…)
Le troisième problème que ca pose est celui du hack TCP pour pas passer en IPv6. Il y a 5 ou 6 ans je racontais en rigolant devant un commité d'experts ( https://linuxfr.org/board ) que les boites ne passeraient jamais en IPv6 (trop couteux et pas rentable du tout pour les premiers à faire le pas) et qu'on aurait à la place des hacks TCP qui permettrait de passer de 65536 ports à 16 millions. Comme ça NAT pour tout le monde et on en parle plus. C'était rigolo à l'époque - mais aujourd'hui ca me fait plus rire.
Donc si quelqu'un peut me dire que je me trompe (avec argument à l'appui - les one-liners "tu te trompes" et les "comment peut-on être assez @"!ù!! pour croire que" s'abstenir) ca me rassurerait. Je souhaite sincèrement être passé à coté d'une fonction IPv6 qui ne soit implémentable en 100 lignes de codes avec mptcp.