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 <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/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
