>> Michel Py a écrit: >> 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.
> Samuel Thibault a écrit : > Mais ils sont moins fragmentés a priori. Dans quelle mesure, il faudrait > mesurer. Combat d'arrière garde; c'est naturel qu'il y ait moins de fragmentation dans la DFZ IPv6 : les allocations initiales ont souvent été faites bien plus généreusement que pour IPv4, donc l'org qui a besoin de s'étendre n'a pas besoin de demander après-coup un autre préfixe. >>> David Ponzone a écrit : >>> Tu verrais une autre solution ? >> Michel Py a écrit : >> 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. > Samuel Thibault a écrit : > Et pour le p2p ? CGNAT / P2P bien conçu, on alloue certains ports à chaque client : Exemple on te donne 100.64.3.200, et automatiquement on forwarde les ports 20000 à 20099 donc tu peux utiliser ces ports pour héberger les services que tu veux. 100.64.3.201 aura les ports 20100 à 20199, quelque chose comme çà. Cà ne t'enlève pas samuel.dynip.com:20000 Michel. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
