> 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.
D’ailleurs j’en profite pour hijacker, non pas des préfixes, mais le thread. Amis NetOps, est-ce que vous filtrez au delà de /32 sur les blocs non PI en IPv6 ? Parce que j’ai une certaine quantité de gros sagouins qui m’annoncent une foulitude de /48 continus issus de PA (coucou AS174, on te voit tu sais). Hugues AS57199 - AS50628 > On 15 Mar 2019, at 18:56, Michel Py <mic...@arneill-py.sacramento.ca.us> > wrote: > >>> 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/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
