Grosso modo, voilà la vision que j’en ai : PA : Destiné aux opérateurs assignant des blocs sur leur propre AS et avec un routage cohérent et agrégé, donc normalement pas fait pour être désagrégé dans la DFZ (enfin, c’est mon avis) PI : Destiné aux clients finaux désireux d’être multihomés. Le RIPE assigne les plus petits ranges possibles (/48)
Pour toi, a mon sens, tant que tu ne désagrèges pas tes préfixes comme un cochon, ça devrait bien se passer. Je ne sais pas si des gens filtrent les désagrégations de PA, dans la vraie vie, ni même si c’est une bonne pratique. PS : Il existe des manières propres de régionaliser ses préfixes sans faire d’update dans la DFZ, si besoin. Hugues AS57199 - AS50628 > On 15 Mar 2019, at 19:35, Alexis <a...@gen-ip.fr> wrote: > > Mmmm > > Vous me faites peur, à parler de filtrer certaines IPv6 PA mais pas PI. > > Lorsque nous avons commandé notre lot d'IPv6 à RIPE, on avait demandé une > tranche IPv6 PI et on nous avait répondu "vous avez demandé un PI. Si vous > prenez un PA ce sera exactement pareil mais vous aurez un /29 au lieu d'un > /32. On est gentil donc on annule votre demande de PI, refaites une demande > de PA svp.". > > Je n'avais pas les compétences pour savoir ce que ça impliquait à l'époque, > donc j'ai juste demandé le PA au lieu du PI (je n'ai toujours pas ces > compétances :)). Et puis comme c'est RIPE qui me l'a dit, j'ai fait confiance. > J'étais parti du principe qu'au final, un PI et un PA sont identiques > "techniquement", à partir du moment où on a son propre ASN et qu'on annonce > son propre préfixe IPv6 pour son propre réseau d'entreprise. > > Me serais-je trompé ? > > (j'en profite pour saluer ce thread. Y'a beaucoup de bruit et de > chamailleries, mais la quantité d'infos apportées reste fantastique. > D'ailleurs, si un wiki voit le jour, je serai le premier à y lire tout le > contenu. Pour l'instant, avec la quantité d'adresses qu'on a, j'ai déjà du > mal à savoir comment je peux faire mon plan d'adressage v6 efficacement sans > me tirer une balle dans le pied et avoir à me trainer, dans 10 ans, un boulet > pénible). > > Alexis > > Le 15/03/2019 à 19:14, Hugues Voiturier a écrit : >>> 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/ > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
