En soi il est cohérent, puisque tu es LIR :-)
Hugues AS57199 - AS50628 > On 15 Mar 2019, at 22:40, Alexis <[email protected]> wrote: > > Je vois. Donc dans mon cas, normalement, je ne serai pas embêter par ce > choix, même s'il n'est pas "cohérent" avec ce pour quoi les PI/PA ont été > pensés. > > Merci beaucoup pour l'info, ça m'évitera de mal dormir cette nuit :) > > Alexis > > Le 15/03/2019 à 21:08, Hugues Voiturier a écrit : >> 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 <[email protected]> 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 <[email protected]> >>>>> 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/ > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
