Re: [FRnOG] RFC 6301: A Survey of Mobility Support In the Internet
Le 10 juillet 2011 22:40, Stephane Bortzmeyer bortzme...@nic.fr a écrit : Quelqu'un ici a-t-il une offre Mobile IP à son catalogue ? Je suis presque sûr que non. Moi ! http://www.swisscom.ch/res/internet/mobile-unlimited/index.htm?languageId=fr (oui c'est bien du Mobile IP, il y a seamless handover entre Wifi (EAP-SIM) et 3G.) Guillaume
Re: [FRnOG] RFC 6301: A Survey of Mobility Support In the Internet
Bonjour, Le 10 juil. 2011 à 23:12, Guillaume Barrot a écrit : Tous les opérateurs de téléphonie mobile implémentent de la mobilité via Gtp (3Gpp oblige), d'où les S et Ggsn. Ok, admettons, mais comment tu fais: - La mobilité inter-domaines (entre plusieurs opérateurs), bon, admettons, c'est peut être possible, je ne connais pas le protocole - La mobilité inter-technos (entre WiFi et 3g par exemple) - La gestion d'interfaces multiples (MCoA pour Mobile IP par exemple), pour par exemple balancer ta connexion IP sur WiFi et WiMAX ... sans de la mobilité au niveau IP ? Le 10 juil. 2011 à 22:40, Stephane Bortzmeyer a écrit : D'où ce RFC qui évalue l'état actuel du déploiement des techniques de mobilité sur l'Internet. (Disons-le tout de suite, il est très faible.) Déjà les implémentations sont aussi très faibles, et les protocoles (du moins Mobile IP), très complexes (si ce n'est pire :) ). Bien sûr, une telle gestion par l'application ne couvre pas tous les cas. Un gros transfert de fichiers avec curl ou wget ne peut pas fonctionner ainsi, puisque ce transfert utilise une seule connexion TCP, donc dépend de l'adresse IP source utilisée au départ (cf. section 6.2). (Avec rsync, et un script qui le relance jusqu'à complétion, ça marcherait.) Et, évidemment, les sessions SSH ne peuvent pas être maintenues lorsqu'on change d'adresse. Mais il reste quand même énormément de cas où il n'y a *pas* de vrai problème lié à la mobilité et cela explique largement, à mon avis, pourquoi les techniques de mobilité IP sont si peu déployées. J'arrête là les opinions personnelles et je reviens au RFC. Oui, enfin la killer app de la mobilité, ce n'est pas nécessairement le gros transfert de fichiers. J'ai un meilleur exemple : Tu te balades sur une route nationale (pas trop vite quand même, il faut que tu puisses capter correctement les réseaux alentours ! ;)), avec moults réseaux, très changeants. Tu veux discuter par skype sur ton téléphone, soit tu te mets sur des réseaux WiFi communautaires pour avoir un meilleur débit, mais tu seras coupé toutes les cinq minutes, soit tu te mets en 3g, tu n'auras pas de déconnexions, mais tu vas avoir un débit médiocre, voire racker sur ton forfait 3g si tu n'as pas le forfait iphoune à 60€. La mobilité, ce n'est pas pour garder son adresse IP de chez soi au bureau, ou dans le train pour pouvoir s'y connecter en SSH. Ca c'est une demandes de quelques geeks boutonneux. La mobilité c'est pour optimiser l'utilisation de ses ressources et de sa connectivité. Enfin, si tu regardes dans les auteurs de la RFC, il y a quelqu'un de chez ... Toyota (tiens, un constructeur automobile ! :) ). L'une des killer app de la mobilité, et un gros sujet de recherche (c'est grâce à ça que j'ai pu avoir un poste dans la recherche française au passage :) ), c'est la mobilité dans les ITS. De nos jours, on cherche à installer un routeur mobile dans la voiture de Mr et Mme Michu, de la même manière qu'ils ont leur machinbox à la maison. D'un point de vue technique, envoyer des RAs avec une IP stable aux ordis qui vont se connecter au routeur mobile, c'est tout de même plus solide qu'implémenter le très propre NPT66 que tu nous as présenté il y a quelques jours ! Si tu proposes une techno qui va engendrer un changement de préfixe (donc une déconnexion) toutes les deux minutes, Mr et Mme Michu ne diront qu'une seule chose : ça ne marche pas ! Et ils vont inonder les SAV des opérateurs de routeur mobile... Donc c'est justement lorsque la mobilité ne devient plus un souhait pour l'utilisateur mais qu'elle devient juste naturelle qu'on aura gagné ! Dans le futur, toutefois, de plus en plus de machines seront mobiles et il est possible que le premier choix (rendre le CN conscient que son partenaire se déplace) redevienne attirant. Si on prend toujours l'exemple de Mobile IP, je doute que cela soit intéressant. Il suffit de regarder la signalisation que cela engendre d'une part, et surtout le cache. Si Google devait mettre en cache l'adresse IP de chaque mobile, il lui faudrait juste doubler son parc de serveur. Faire gérer la mobilité par les correspondants, cela revient a faire du routage en bout de réseau... Emmanuel THIERRY --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] RFC 6301: A Survey of Mobility Support In the Internet
Quelqu'un ici a-t-il une offre Mobile IP à son catalogue ? Je suis presque sûr que non. Pourquoi, se demande ce RFC. http://www.bortzmeyer.org/6301.html Auteur(s) du RFC: Z. Zhu (UCLA), R. Wakikawa (TOYOTA ITC), L. Zhang (UCLA) Dans le monde des réseaux informatiques, on distingue en général le *nomadisme* (pouvoir changer d'endroit et avoir à peu près les mêmes services) et la *mobilité* (pouvoir changer d'endroit en maintenant les sessions existantes, comme si on n'avait pas bougé). Aujourd'hui, où beaucoup d'équipements sont mobiles (smartphone, tablette, ...), la mobilité suscite beaucoup d'intérêt. D'où ce RFC qui évalue l'état actuel du déploiement des techniques de mobilité sur l'Internet. (Disons-le tout de suite, il est très faible.) Je vais me permettre de commencer par une polémique et des opinions personnelles : dans la famille de protocoles TCP/IP, la mobilité, c'est comme le multicast. Beaucoup de RFC, très peu de paquets. Le sujet passionne les experts, pose plein de problèmes techniques amusants, permet d'écrire des algorithmes rigolos... mais touche très peu les utilisateurs. Comment cela, les utilisateurs ne veulent pas se connecter à l'Internet depuis leur maison, puis continuer au bureau ? Si, ils le veulent, mais il n'est pas du tout évident que la mobilité au niveau IP soit nécessaire pour cela. Aujourd'hui, la technique de mobilité la plus courante est DHCP... La machine reçoit une nouvelle adresse IP et ce sont les applications qui gèrent les déconnexions/reconnexions. Prenons l'exemple du client de messagerie instantanée Pidgin et supposons que je me promène avec mon ordinateur portable, connecté via clé USB 3G dans le train, via le Wifi au Starbucks, puis via un câble Ethernet au bureau. J'aurai une adresse IP différente à chaque fois et les sessions IRC ou XMPP seront donc coupées lors des changements. Est-ce grave ? Pas tellement. Pidgin se reconnectera automatiquement à chaque fois et la seule conséquence pratique sera les messages de déconnexion et de reconnexion que verront les abonnés de chaque canal IRC / pièce XMPP. On a là un bon exemple du fait qu'une gestion de la mobilité par l'application cliente (section 5.5 de notre RFC) est suffisante et qu'il n'y a pas besoin d'un service réseau (compliqué et amenant des problèmes de sécurité) pour cela. Même chose avec une application Web : chaque requête HTTP peut utiliser une adresse source différente, l'utilisateur ne s'en rendra pas compte (à part éventuellement une obligation de se réauthentifier si le cookie est lié à l'adresse IP, ce qui se fait parfois pour limiter la réutilisation d'un cookie volé). Les applications qui reposent sur HTTP (les clients Twitter, par exemple) arrivent également à maintenir une « session » lors de changements d'adresse IP. Bien sûr, une telle gestion par l'application ne couvre pas tous les cas. Un gros transfert de fichiers avec curl ou wget ne peut pas fonctionner ainsi, puisque ce transfert utilise une seule connexion TCP, donc dépend de l'adresse IP source utilisée au départ (cf. section 6.2). (Avec rsync, et un script qui le relance jusqu'à complétion, ça marcherait.) Et, évidemment, les sessions SSH ne peuvent pas être maintenues lorsqu'on change d'adresse. Mais il reste quand même énormément de cas où il n'y a *pas* de vrai problème lié à la mobilité et cela explique largement, à mon avis, pourquoi les techniques de mobilité IP sont si peu déployées. J'arrête là les opinions personnelles et je reviens au RFC. La section 1 explique que ce RFC est motivé par le fait que la mobilité est depuis longtemps un sujet de recherche actif à l'IETF et que, depuis quelques années, le déploiement des engins mobiles a explosé (smartphones, tablettes, etc). Le besoin est donc nettement plus marqué maintenant que dix ans auparavant, lorsqu'un ordinateur portable était un machin encombrant et lent. Pourtant, les solutions normalisées par l'IETF ont été peu déployées. Ces solutions utilisent un vocabulaire rappelé en section 2 et dans le RFC 3753. Notons notamment les termes d'*identificateur* (identifier) qui indique une valeur qui ne change pas lors des déplacements, de *localisateur* (locator), qui, lui, change lorsqu'on se déplace (en IP classique, c'est le cas de l'adresse IP), de *correspondance* (mapping), la fonction qui permet de trouver un localisateur en connaissant l'identificateur, de *correspondant* (CN pour Correspondent Node, la machine avec laquelle l'engin mobile communique), etc. La section 3 expose les principes de base de la gestion de la mobilité. Le CN doit pouvoir, dans l'Internet actuel : * trouver l'adresse IP actuelle du mobile (solutions dites de type 1), * ou bien connaître un identificateur du mobile et pouvoir lui envoyer des données en utilisant cet identificateur (solutions de type 2), nettement plus fréquentes. Un exemple de solution de
Re: [FRnOG] RFC 6301: A Survey of Mobility Support In the Internet
Three (hutchison 3G - UK) fournit une terminaison L2TP a certains FAI - entre autre nous. La session vous suit donc on peut avoir une IP statique et un block d'IP route lors d'un voyage dans un train sans aucun problème. Adrian Kennard de AAISP a parle de l'implementation du point de vu de l'ISP a UKNOF 19 (mais la video n'est pas - encore ?? - disponible sur le site). Il y a beaucoup de tour de magie car évidement la session PPP n'est pas vraiment du dongle a l'ISP. Alors cette RFC c'est pour quoi au fait :p Thomas On 10 Jul 2011, at 21:40, Stephane Bortzmeyer wrote: Quelqu'un ici a-t-il une offre Mobile IP à son catalogue ? Je suis presque sûr que non. Pourquoi, se demande ce RFC. http://www.bortzmeyer.org/6301.html Auteur(s) du RFC: Z. Zhu (UCLA), R. Wakikawa (TOYOTA ITC), L. Zhang (UCLA) Dans le monde des réseaux informatiques, on distingue en général le *nomadisme* (pouvoir changer d'endroit et avoir à peu près les mêmes services) et la *mobilité* (pouvoir changer d'endroit en maintenant les sessions existantes, comme si on n'avait pas bougé). Aujourd'hui, où beaucoup d'équipements sont mobiles (smartphone, tablette, ...), la mobilité suscite beaucoup d'intérêt. D'où ce RFC qui évalue l'état actuel du déploiement des techniques de mobilité sur l'Internet. (Disons-le tout de suite, il est très faible.) Je vais me permettre de commencer par une polémique et des opinions personnelles : dans la famille de protocoles TCP/IP, la mobilité, c'est comme le multicast. Beaucoup de RFC, très peu de paquets. Le sujet passionne les experts, pose plein de problèmes techniques amusants, permet d'écrire des algorithmes rigolos... mais touche très peu les utilisateurs. Comment cela, les utilisateurs ne veulent pas se connecter à l'Internet depuis leur maison, puis continuer au bureau ? Si, ils le veulent, mais il n'est pas du tout évident que la mobilité au niveau IP soit nécessaire pour cela. Aujourd'hui, la technique de mobilité la plus courante est DHCP... La machine reçoit une nouvelle adresse IP et ce sont les applications qui gèrent les déconnexions/reconnexions. Prenons l'exemple du client de messagerie instantanée Pidgin et supposons que je me promène avec mon ordinateur portable, connecté via clé USB 3G dans le train, via le Wifi au Starbucks, puis via un câble Ethernet au bureau. J'aurai une adresse IP différente à chaque fois et les sessions IRC ou XMPP seront donc coupées lors des changements. Est-ce grave ? Pas tellement. Pidgin se reconnectera automatiquement à chaque fois et la seule conséquence pratique sera les messages de déconnexion et de reconnexion que verront les abonnés de chaque canal IRC / pièce XMPP. On a là un bon exemple du fait qu'une gestion de la mobilité par l'application cliente (section 5.5 de notre RFC) est suffisante et qu'il n'y a pas besoin d'un service réseau (compliqué et amenant des problèmes de sécurité) pour cela. Même chose avec une application Web : chaque requête HTTP peut utiliser une adresse source différente, l'utilisateur ne s'en rendra pas compte (à part éventuellement une obligation de se réauthentifier si le cookie est lié à l'adresse IP, ce qui se fait parfois pour limiter la réutilisation d'un cookie volé). Les applications qui reposent sur HTTP (les clients Twitter, par exemple) arrivent également à maintenir une « session » lors de changements d'adresse IP. Bien sûr, une telle gestion par l'application ne couvre pas tous les cas. Un gros transfert de fichiers avec curl ou wget ne peut pas fonctionner ainsi, puisque ce transfert utilise une seule connexion TCP, donc dépend de l'adresse IP source utilisée au départ (cf. section 6.2). (Avec rsync, et un script qui le relance jusqu'à complétion, ça marcherait.) Et, évidemment, les sessions SSH ne peuvent pas être maintenues lorsqu'on change d'adresse. Mais il reste quand même énormément de cas où il n'y a *pas* de vrai problème lié à la mobilité et cela explique largement, à mon avis, pourquoi les techniques de mobilité IP sont si peu déployées. J'arrête là les opinions personnelles et je reviens au RFC. La section 1 explique que ce RFC est motivé par le fait que la mobilité est depuis longtemps un sujet de recherche actif à l'IETF et que, depuis quelques années, le déploiement des engins mobiles a explosé (smartphones, tablettes, etc). Le besoin est donc nettement plus marqué maintenant que dix ans auparavant, lorsqu'un ordinateur portable était un machin encombrant et lent. Pourtant, les solutions normalisées par l'IETF ont été peu déployées. Ces solutions utilisent un vocabulaire rappelé en section 2 et dans le RFC 3753. Notons notamment les termes d'*identificateur* (identifier) qui indique une valeur qui ne change pas lors des déplacements, de *localisateur* (locator), qui, lui, change lorsqu'on se déplace
Re: [FRnOG] RFC 6301: A Survey of Mobility Support In the Internet
Tous les opérateurs de téléphonie mobile implémentent de la mobilité via Gtp (3Gpp oblige), d'où les S et Ggsn. Des études pour implémenter mobile ip ont été faites il y à quelques années chez nous, avec comme conclusion qu'on ne déploierait pas mais j'ai pas le détail du pourquoi la, si ce n'est que Gtp étant le standard de facto pour les telcos (3gpp), être le premier (voire le seul) à partir sur mobile ip doit poser des problèmes sur la gestion du roaming. Sur un réseau fixe (adsl, ftth) la question ne s'est jamais posée à ma connaissance (je parle bien de mobilité pas d'ip fixe). Le 10 juil. 2011 22:43, Stephane Bortzmeyer bortzme...@nic.fr a écrit : Quelqu'un ici a-t-il une offre Mobile IP à son catalogue ? Je suis presque sûr que non. Pourquoi, se demande ce RFC. http://www.bortzmeyer.org/6301.html Auteur(s) du RFC: Z. Zhu (UCLA), R. Wakikawa (TOYOTA ITC), L. Zhang (UCLA) Dans le monde des réseaux informatiques, on distingue en général le *nomadisme* (pouvoir changer d'endroit et avoir à peu près les mêmes services) et la *mobilité* (pouvoir changer d'endroit en maintenant les sessions existantes, comme si on n'avait pas bougé). Aujourd'hui, où beaucoup d'équipements sont mobiles (smartphone, tablette, ...), la mobilité suscite beaucoup d'intérêt. D'où ce RFC qui évalue l'état actuel du déploiement des techniques de mobilité sur l'Internet. (Disons-le tout de suite, il est très faible.) Je vais me permettre de commencer par une polémique et des opinions personnelles : dans la famille de protocoles TCP/IP, la mobilité, c'est comme le multicast. Beaucoup de RFC, très peu de paquets. Le sujet passionne les experts, pose plein de problèmes techniques amusants, permet d'écrire des algorithmes rigolos... mais touche très peu les utilisateurs. Comment cela, les utilisateurs ne veulent pas se connecter à l'Internet depuis leur maison, puis continuer au bureau ? Si, ils le veulent, mais il n'est pas du tout évident que la mobilité au niveau IP soit nécessaire pour cela. Aujourd'hui, la technique de mobilité la plus courante est DHCP... La machine reçoit une nouvelle adresse IP et ce sont les applications qui gèrent les déconnexions/reconnexions. Prenons l'exemple du client de messagerie instantanée Pidgin et supposons que je me promène avec mon ordinateur portable, connecté via clé USB 3G dans le train, via le Wifi au Starbucks, puis via un câble Ethernet au bureau. J'aurai une adresse IP différente à chaque fois et les sessions IRC ou XMPP seront donc coupées lors des changements. Est-ce grave ? Pas tellement. Pidgin se reconnectera automatiquement à chaque fois et la seule conséquence pratique sera les messages de déconnexion et de reconnexion que verront les abonnés de chaque canal IRC / pièce XMPP. On a là un bon exemple du fait qu'une gestion de la mobilité par l'application cliente (section 5.5 de notre RFC) est suffisante et qu'il n'y a pas besoin d'un service réseau (compliqué et amenant des problèmes de sécurité) pour cela. Même chose avec une application Web : chaque requête HTTP peut utiliser une adresse source différente, l'utilisateur ne s'en rendra pas compte (à part éventuellement une obligation de se réauthentifier si le cookie est lié à l'adresse IP, ce qui se fait parfois pour limiter la réutilisation d'un cookie volé). Les applications qui reposent sur HTTP (les clients Twitter, par exemple) arrivent également à maintenir une « session » lors de changements d'adresse IP. Bien sûr, une telle gestion par l'application ne couvre pas tous les cas. Un gros transfert de fichiers avec curl ou wget ne peut pas fonctionner ainsi, puisque ce transfert utilise une seule connexion TCP, donc dépend de l'adresse IP source utilisée au départ (cf. section 6.2). (Avec rsync, et un script qui le relance jusqu'à complétion, ça marcherait.) Et, évidemment, les sessions SSH ne peuvent pas être maintenues lorsqu'on change d'adresse. Mais il reste quand même énormément de cas où il n'y a *pas* de vrai problème lié à la mobilité et cela explique largement, à mon avis, pourquoi les techniques de mobilité IP sont si peu déployées. J'arrête là les opinions personnelles et je reviens au RFC. La section 1 explique que ce RFC est motivé par le fait que la mobilité est depuis longtemps un sujet de recherche actif à l'IETF et que, depuis quelques années, le déploiement des engins mobiles a explosé (smartphones, tablettes, etc). Le besoin est donc nettement plus marqué maintenant que dix ans auparavant, lorsqu'un ordinateur portable était un machin encombrant et lent. Pourtant, les solutions normalisées par l'IETF ont été peu déployées. Ces solutions utilisent un vocabulaire rappelé en section 2 et dans le RFC 3753. Notons notamment les termes d'*identificateur* (identifier) qui indique une valeur qui ne change pas lors des déplacements, de *localisateur* (locator), qui, lui, change
