> Pascal PETIT a écrit : > J'ai lu un peu tout et son contraire sur le multihoming IPV6 et je > n'ai toujours pas compris ce qui était prévu pour ce cas de figure.
Le protocole de base n'avait pas la notion de PI. Tout était PA, ce qui en théorie aurait conduit à une DFZ de très petite t'aille, l'agrégation des préfixes étant faite au niveau des FAI. Problème est que la solution n'existait pas; les seuls qui pouvaient être multihomés étaient les FAI. Il y a eu plusieurs propositions, aucune de techniquement viable. Reconnaissant l'échec à délivrer quelque chose qui pourrait marcher, les RIR ont fait un enfant dans le dos à l'IETF, inventé la notion de PI v6, et commencer à déléguer des adresses IPv6 (et un ASN) aux utilisateurs finaux devaient multihomer. On en est donc revenu à faire exactement la même chose que pour IPv4 : pour multihomer , un annonce un préfixe (de plus) dans la DFZ. Donc maintenant il faut non seulement se taper 1 million (dans pas trop longtemps) de préfixes dans la DFZ IPv4 plus la DFZ IPv6, dont les préfixes consomment 2 fois plus de TCAM que les IPv4. Quand j'écris que IPv4 et IPv6 sont en compétition pour les mêmes ressources, voici un bon exemple : la TCAM. Les vendeurs s'en frottent les mains. > Thierry Chich a écrit : > Ce qui est vraiment haïssable, ce sont ces protocoles merdiques > avec des ports dynamiques de partout et dans tous les sens. +1. Les trucs genre portmapper qui demandent un ALG compliqué; a l'opposé, il y a des protocoles qui traversent NAT sans aucun problème. > David Ponzone a écrit : > Tu verrais une autre solution ? Oui, concevoir le protocole simplement. K.I.S.S. Exemple : FTP. Mal conçu, il utilise 2 ports et il y a à l'intérieur du paquet des informations à propos de l'adresse source qui rend nécessaire un ALG NAT qui re-écrit ces infos. Exemple : Telnet. Bien conçu, le serveur se base sur l'IP source qu'il voit, donc qui a déjà été modifiée par NAT, çà marche avec double NAT sans probléme. > Thierry Chich a écrit : > Une autre solution que des protocoles où le client négocie avec le serveur le > numéro de port sur lequel > le serveur va lui envoyer des données ? A la mode tftp ou rsh ? Ben, je pense > qu'il y a d'autres solutions > envisageables. Même si je reconnais humblement ne pas connaître toutes les > problématiques spécifiques de > la VoIP et de la ToIP, ça me parait effectivement inutilement compliqué. Et > surtout, pas pensé dans le > monde IP actuel, mais plutôtpour un monde IP idéal dans lequel tout le monde > peut parler à tout le monde > sans entrave. C'est beau, mais dans la réalité, on s'aperçoit que déléguer > toute la question de la > sécurité à l'application, c'est tout simplement pas jouable. +1 > Oliver varenne a écrit : > Pour la VOIP, il y a bien IAX2 qui permet de ne pas avoir une m(o)ultitude de > ports ouverts... +1 > Stéphane Rivière a écrit : > Pour répondre à la question posée : peut-on faire autrement ? IAX (vs > SIP/RDP) en VOIP l'a démontré. > La plupart des pb d'IAX étaient plus à voir du coté de l'implémentation que > du protocole. Les bénéfices > d'IAX (efficacité, NAT traversal) étaient évidents. Mais SIP/RDP (bidule IETF > de mémoire, c'est vieux) > a gagné. Les voies de Darwin sont parfois impénétrables (BETAMAX vs VHS)... +1000 > Kevin CHAILLY a écrit : > SIP a été le super-protocole-ouvert-qui-fait-le-café quand en face il y avait > SCCP, le méchiant proctocole de Cisco C'est pour çà que je ne regrette pas IAX, la vie continue. > Toussaint OTTAVI a écrit : > Pour moi qui ne suis pas téléphoniste, mais juste firewalliste, > un port unique et fixe, c'est déjà plus que parfait :-) +1 > Je ne pense pas que les gens qui ont conçu SIP et RTSP aient eu en tête les > problématiques de NAT et de > sécurisation que çà allait générer (certes, ailleurs que chez eux). On > retombe sur la discussion d'un > protocole conçu par une catégorie d'utilisateurs pour répondre à ses besoins > propres, sans forcément > tenir compte des difficultés que cela allait engendrer pour d'autres > catégories d'utilisateurs. +1. Ou de gens qui connaissent peut-être très bien la téléphonie de MaBell, qui pensent en tant que circuit et pas paquet, et qui ne comprennent pas vraiment grand-chose au réseau. > Du coup, je me demande s'il existe un protocole qui m'exaspèrerait plus que > SIP et IPv6 réunis :-D T'as qu'à demander à tous ceux qui ont essayé de faire du SIP sous IPv6 ;-) > Philippe ASTIER a écrit : > Pour autant que je sache, à part IPv6, on n’a rien dans les tuyaux comme > alternative, Pas aujourd'hui. > donc il n’y a juste pas le choix. Pas encore. > Ce qui est effrayant, c’est le nombre de protocoles bricolés qu’on a ajouté > entre les deux, qui > ralentissent la mise en place d’un IPv6 propre, et complexifie encore plus > l’infrastructure. C'est bien là le problème : l'acharnement thérapeutique à déployer IPv6 conduit à faire quelque chose qui est 3 fois plus compliqué que l'usine à gaz qu'on a déjà en IPv4. Les gens qui disent que l'acharnement thérapeutique c'est IPv4, ils devraient regarder autour d'eux. IPv4 est de très loin LE protocole de l'Internet, et il n'est pas en train de mourir. > En fait, on n’a plus le choix. Et on devrait profiter de l’expérience > ceux qui ont participé à bâtir les protocoles précédents. Le choix, c'est d'admettre que le déploiement d'IPv6 est un échec et de repenser quelque chose de déployable. Et çà veut dire qu'on va continuer à faire des bidouillages immondes pendant encore 20 ans. > Samuel Thibault a écrit : > J'avais vu une étude qui estimait qu'on a déjà dépensé du genre 2x plus de > fric à bricoler > NAT etc. que ce qu'on aurait eu à dépenser pour juste mettre en œuvre IPv6. Il y a de la vérité dans ceci, mais çà n'enlève rien au fait que IPv6 n'est pas déployé. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
