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/
