RE: [FRnOG] [TECH] EDF, Opérateur de DataCenter ?

[JCLB]

Bonjour,

Historiquement EDF avait construit un DC dans l'Eure pour rapatrier ses centres 
régionaux, puis a plus tard construit un 2e site un peu plus loin en aval de 
l'Eure et de l'A13 à Val de Reuil.
C'est ce site qui est facilement divisible avec plusieurs salles où il est là 
aussi possible de sous diviser.
EDF en profite pour tester pas mal de choses avec ses filiales, notamment pour 
réduire le PUE.

Orange a construit dans la rue peu après en 2012 et agrandit en 2022. Et le 
dernier arrivé dans la zone est Nation Data Center.


On trouve donc du monde en telco sur Val de Reuil, pour l'elec le DC est 
lui-même soumis aux marchés publics, donc un site EDF n'est pas forcément 
fourni par

Enfin, le secours est testé régulièrement puisque à chaque grève IEG, Enedis 
Normandie vient mettre un BBQ devant l'une des adductions et la coupe


JC Bisecco


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Paul 
Rolland (???·???)
Envoyé : jeudi 16 novembre 2023 07:58
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] EDF, Opérateur de DataCenter ?

Bonjour,

On Wed, 15 Nov 2023 21:00:35 +0100
cem.car...@free.fr wrote:

> Vous allez me dire, Cem, on est pas vendredi, c'est pas le moment ! 
> Mais je pense que ces belles initiatives industrielles pourraient être 
> tellement belles sur le papier et dans la réalité mais à l'image de 
> TDF pour les DC, VNF pour les canaux, la SNCF pour les caniveaux le 
> long des voies ferrées ou du réseau de transport d'électricité comme 
> support de la fibre, on a toujours des grains de sable qui grippent la 
> machine.
> C'est dommage :(

Le courant, c'est bien... c'est une premiere etape. Mais le cote Telecom, ils 
te proposent quoi ces gens ? Du CPL ? (bon, desole.. enfin, non, mais la, j'ai 
pas pu resister a la faire, et je suis sur que d'autres l'auraient faites 
aussi).

Mais la question reste posee : c'est quoi leur proposition en terme de 
raccordement telecom ?

Paul

-- 
Paul RollandE-Mail : rol(at)witbe.net
CTO - Witbe.net SA  Tel. +33 (0)1 47 67 77 77
18 Rue d'Arras, Bat. A11Fax. +33 (0)1 47 67 77 99
F-92000 NanterreRIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur 
"Some people dream of success... while others wake up and work hard at it" 

"I worry about my child and the Internet all the time, even though she's too 
young to have logged on yet. Here's what I worry about. I worry that 10 or 15 
years from now, she will come to me and say 'Daddy, where were you when they 
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [BIZ] Recherche MUX EDFA ou OTN ou transport FC 32gb/s Paris PA3 PA4

[JCLB]

Bonsoir Jérôme,

Si quelqu'un peut faire une quote semaine pro et a du stock,
D'ailleurs y'a un intérêt à acheter le nokia 200 vis-à-vis de l'original 
packetlight PL-2000M ?

Pour la distance ça passe en direct avec des XBR-000478 ou XBR-000479 en ELWL 
25km, mais juste en dessous en LR c'est juste avec 8dB, et l'idée c'est bien 
d'avoir du coloré.
(C'est pour du Brocade G720, pas encore grand monde pour fournir là-dessus, 
juste smartoptics avec leur partenariat)


Cordialement,
Jean-Charles BISECCO
+33 6 67 49 50 30

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Jérôme 
Nicolle
Envoyé : vendredi 3 novembre 2023 20:50
À : frnog@frnog.org
Objet : Re: [FRnOG] [BIZ] Recherche MUX EDFA ou OTN ou transport FC 32gb/s 
Paris PA3 PA4

JC,

Prends donc une paire de Nokia Wavelite Access 200 avec 4 optiques 100G-ER4, ou 
des Wavelite Metro 200 avec leurs CFP2. Mais entre PA3 et
PA4 normalement en LR ça passe.

@+

Le 03/11/2023 à 16:52, JCLB a écrit :
> Bonjour,
> 
> Je recherche assez rapidement une solution de transport de 4 liens Fibre 
> Channel 32gb/s entre PA3 et PA4 à Paris.
> 
> Cela peut-être au choix :
> 
>*   Location ou achat de MUX EDFA DWDM pour 13dB, (location n'importe 
> quelle taille, achat 16 canaux de préférence) je gère les optiques et la dark 
> fiber.
>*   Location ou achat d'OTN (uplink 100G pour loc, 200G+ pour achat) je 
> gère la dark fiber
>*   Offre de transport éclairée pour 6 mois, via raccordement en cross-co 
> equinix de préférence
> 
> L'objectif est de brancher des switchs SAN qui ne supportent pas du ER ou ZR, 
> je peux donc mettre soit des optiques DWDM 10km qu'il faut amplifier en EDFA, 
> soit du local vers châssis OTN.
> 
> 
> La contrainte est de monter ça pour la première semaine de décembre.
> 
> Je suis joignable n'importe quand,
> Jean-Charles BISECCO
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

--
Jérôme Nicolle
+33 6 19 31 27 14


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [BIZ] Recherche MUX EDFA ou OTN ou transport FC 32gb/s Paris PA3 PA4

[JCLB]

Bonjour,

Je recherche assez rapidement une solution de transport de 4 liens Fibre 
Channel 32gb/s entre PA3 et PA4 à Paris.

Cela peut-être au choix :

  *   Location ou achat de MUX EDFA DWDM pour 13dB, (location n'importe quelle 
taille, achat 16 canaux de préférence) je gère les optiques et la dark fiber.
  *   Location ou achat d'OTN (uplink 100G pour loc, 200G+ pour achat) je gère 
la dark fiber
  *   Offre de transport éclairée pour 6 mois, via raccordement en cross-co 
equinix de préférence

L'objectif est de brancher des switchs SAN qui ne supportent pas du ER ou ZR, 
je peux donc mettre soit des optiques DWDM 10km qu'il faut amplifier en EDFA, 
soit du local vers châssis OTN.


La contrainte est de monter ça pour la première semaine de décembre.

Je suis joignable n'importe quand,
Jean-Charles BISECCO


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[TECH] RE: [FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[JCLB]

Tout comme pour les bases GeoIP, les bases de blacklists SMTP ne sont pas 
toutes prêtes à collecter les infos en v6… ça ne semble pas être une priorité 
de leur biz modèle.
Mais si personne ne collecte de stats pour les remonter, et que personne ne 
déploie, c’est l’Ouroboros.
Sans compter les histoires de taille de préfixe à classer, comme le décrit 
l’article du RIPE labs.

Personnellement je suis plus inquiet du volume de machines hébergeant des zones 
DNS ne disposant pas d’IPv6…

Pour rappel Mardi 04/07 matin l’ARCEP présentera son rapport sur l’état de 
l’internet en France.


Jean-Charles BISECCO


De : frnog-requ...@frnog.org  De la part de Louis 
Poidevin via frnog
Envoyé : lundi 26 juin 2023 13:50
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

Bonjour,

En faisant des recherches sur l'état de l'art des infrastructures mail, j'ai 
remarqué que très peu de domaines d'entreprise supportent la réception de mail 
en IPv6.
Que ce soit orange, protonmail, ovh pour n'en citer que quelques uns, aucun 
d'entre eux ne semble avoir d'IPv6 sur leur MX. Le seul que j'ai trouvé jusqu'à 
présent est gmail.

Il aurait pu y avoir du dual-stack, mais rien.
Et en faisant des recherches sur le sujet, je suis tombé sur un article 
expliquant que des outils existent pour ce genre d'infa : 
https://labs.ripe.net/author/mirjam/sending-and-receiving-emails-over-ipv6/

Ma question est donc la suivante : connaissez-vous les raisons pour lesquelles 
les entreprises, même les hébergeurs mail, s'en tiennent à l'IPv4 uniquement ?

Merci d'avance,
Louis Poidevin

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] RE: [FRnOG] [MISC] De l'usage du DPI sur le réseau

[JCLB]

Il y a quelques semaines, j'ai eu le plaisir d'utiliser un opérateur dont le 
nom swahili signifie voyage.
Facturation différenciée, mode Facebook light et whatsapp non décompté de la 
data.

Quelques captures de l'affichage des stats dans l'app de l'opérateur, c'est 
d'une précision redoutable, jugez plutôt
https://jclb.net/res/2022/KDPI/DPI1.jpg
https://jclb.net/res/2022/KDPI/DPI2.jpg
https://jclb.net/res/2022/KDPI/DPI-full.jpg (liste intégrale, looongue)

Les noms semblent être ceux de Forti, quelques erreurs, je n'ai par exemple pas 
fait d'edonkey...
Seul QUIC est bien silencieux sur son contenu, et c'est tant mieux.

En Afrique, de nombreux ISP se préparent à exploiter à fond le slicing offert 
par SRv6 pour différencier encore plus le service.

Jean-Charles BISECCO


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de yoshi
Envoyé : vendredi 24 juin 2022 06:57
À : frnog-m...@frnog.org
Objet : [FRnOG] [MISC] De l'usage du DPI sur le réseau

Bon matin la liste,

Comme nous sommes vendredi, je lance une interrogation qui me titille depuis un 
petit moment en espérant qu'elle puisse égailler, ou au moins animer, votre 
journée.

Dans quelles conditions, finalités, autorisations un opérateur peut il recourir 
au DPI et à l'analyse DNS sur son réseau ?

Sollicité sur la question via l'oiseau bleu, l'ARCEP n'a pas répondu pour 
l'instant.

J'ai néanmoins collecté quelques retours, notamment CPCE L.33.2 et CPCE
L.33.14 qui bornent déjà pas mal la question (merci à Marc Ress et Alexandre 
Archambault).

N'étant pas juriste, ma compréhension des textes de loi est limitée.
De ce que j'en comprends, en dehors du CPCE L.33.14 et du CPCE L.33.2.III, le 
recours au DPI est interdit notamment pour les finalités mentionnées au CPCE 
L.33.2.IV. Mais évidement je peux comprendre de travers et toute précision est 
bienvenue.

Benjamin Bayard à précisé que l'opérateur de réseau ne pouvait pas faire grand 
chose au niveau DNS, contrairement à l'opérateur du résolveur qui dispose d'une 
plus grande latitude et de contraintes légales (notamment obligation de filtrer 
sur décision administrative et/ou judiciaire).

La question sous-jacente était, comment font donc les opérateurs pour affirmer 
que les GAFAM occupent plus de 50% de la bande passante utilisée sur leurs 
réseaux (justifiant de faire du lobbying en vu d'obtenir un financement de 
leurs réseaux en contrepartie de cet usage) ?

Stéphane Bortzmeyer a pointé du doigt qu'il n'était nullement nécessaire de 
recourir au DPI pour cette finalité et que l'usage de NetFlow/IPFix suffisait.

Une recherche sur le site de l'ARCEP ne fourni que peu de résultat.
Le communiqué
https://www.arcep.fr/actualites/les-communiques-de-presse/detail/n/larcep-rend-public-son-avis-augouvernement-sur-la-mesure-de-la-structure-de-lusage-de-la-bande.html
évoque le DPI mais n'en borne pas l'usage qui pourrait en être fait.

Enfin, quelle(s) éventuelle(s) sanction(s) pour les opérateurs qui y 
recourraient quand même ?

Également sollicités sur la question, Bouygues, Free, Numericable, Orange et 
SFR n'ont, sans réelle surprise, pas répondu pour le moment (hors réponses 
automatiques et support client qui ne sait évidement pas répondre à la question 
mais qui de toute façon n'est pas là pour ça).

J'en appelle donc à vos avis respectifs sur le sujet.

Au plaisir de vous lire.
Bonne journée.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] RE: ICMP "Communication Administratively Prohibited" en 4G entre EuroInformation Telecom et Neo Telecoms

[JCLB]

Et quand ils en fournissent, ils en abusent de ce bel IPv6.

Souvent l'APN de hotspot/tethering fournit un DNS qui effectue du DNS64.
Or si cette techno est excellente quand le terminal est conscient de se prendre 
du NAT64 (Android, Iphone iOS), elle ne l'est pas quand c'est un PC, une 
console de jeu, etc.

Et je ne vois pas l'avantage pour les ISP à pousser DNS64+NAT64 sur le 
tethering, ça consomme toujours des sessions NAT stateful sur des boitiers, et 
ça n'empêche pas de devoir fournir une connectivité IPv4 pour les apps qui ne 
font pas de requêtes  ou utilisent une IPv4 littérale.

Si quelqu'un d'Orange et Bouygues me lit, SVP séparez vos APN et arrêtez de 
faire du DNS64 sur le mode hotspot.
Je n'ai pas testé le hotspot de SFR ou Free depuis bien longtemps.

Jean-Charles BISECCO

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Xavier 
Beaudouin via frnog
Envoyé : jeudi 23 juin 2022 12:04
À : frnog 
Objet : Re: [FRnOG] [TECH] ICMP "Communication Administratively Prohibited" en 
4G entre EuroInformation Telecom et Neo Telecoms

Hello,

> Je vais peut être dire une énorme bêtise, mais il me semble que le 
> problème vient du fait que le nombre de connexions actives par client 
> est limité par les routeurs CGNAT de BTBD (ex EIT). Vu le nombre de 
> clients derrière chaque IP, ils "protègent" les ressources en mémoire 
> de leurs équipements en restreignant ces connexions.

Et ces opérateurs ne fournissent pas d'IPv6 aux clients mobiles ?
Parce que ça permettrais de limiter les problèmes liées a la demande de 
ressource stupides pour NATer l'ipv4.

Parce qu'en 2022... voila...

/Xavier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Livebox V4 et VLAN sur switch manageable

[JCLB]

Bonjour,

Il y'a bien un déploiement en cours, ce qui peut expliquer ces changements 
soudains
https://lafibre.info/orange-les-news/nouvelle-mise-a-jour-firmware-livebox5/108/

Globalement, Orange semble travailler au bon fonctionnement de son répétiteur 
wifi, qui lui-même est sensible aux BPDU dans certains cas.
D'autres FAI traitent le même sujet, on se souvient de free et du répétiteur 
pop. (Free demandait au début de désactiver SPT, d'autoriser les BPDU 
traversantes et le multicast inconnu. Je ne sais pas ce qu'il en est maintenant)

À titre personnel, ma LB 4 a coupé son wifi ainsi que celui du répétiteur en 
pleine journée semaine dernière, j'ai dû le réactiver manuellement 2h plus tard.
Il m'arrive de devoir redémarrer le répétiteur, je vois des devices IoT 
disparaitre de mon home assistant alors qu'ils accrochent le répétiteur.

Je pense que malgré l'immense base de clients, l'opérateur ne cherche pas à 
aller au-delà du cas LB > switch non manageable > PC.
Preuve en est l'absence de routes IPv4 privées ou de DHCPv6-PD...

Personnellement j'attends le déploiement d'IPv6 par Bouygues dans ma zone pour 
changer et prendre une solution de routeur et wifi en propre avec du NAT44 DMZ 
+ DHCP-PD pour IPv6.

Je recommanderais également à toute personne voulant utiliser du FTTh en pro de 
prendre un abo qui va avec, il y'a plein de personnes ici ou sur lafibre.info 
qui savent fournir leur service via diverses collectes à un tarif tout à fait 
intéressant.
C'est adapté à l'usage évoqué ici, pas de surprise. D'autant qu'historiquement, 
on sait qui est le FAI le plus farceur.

Après pour le fun on peut se battre à essayer de faire de l'orange sans livebox 
avec aujourd'hui son DHCP custom, demain peut-être un BPDU custom aussi etc. 
Pas idéal pour de la prod mais il y'a des dizaines de pages de gens qui 
adaptent opnsense / pfsense et openwrt aux spécificités orange.

Pour terminer, pour faire du multi WAN propre, il y'a un excellent package pour 
ça dans openWRT, pas pratique pour IPv6 cependant.
Il y a très longtemps j'avais 3*30 mb/s numéricable grâce à la 1re version de 
ce package et 3 modems/décodeurs TV.

Jean-Charles Bisecco


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Steeve 
BEAUVAIS - Société Serinya Telecom
Envoyé : mardi 25 janvier 2022 00:14
À : Pierre LANCASTRE 
Cc : David Ponzone ; Jérome Fretigny 
; Thomas.brenac ; Jérémy DUQUESNE 
; FRnOG 
Objet : Re: [FRnOG] [TECH] Livebox V4 et VLAN sur switch manageable

Bonjour Jérémy,

Comme l'évoque Pierre, s'il t'est possible d'envoyer une capture de trames de 
l'interface du switch connectée à l'une des livebox problématique je dis pas 
non :)

En parallèle, les ref matériel et les versions de firmware sont identiques 
entre les 3 livebox où est ce que tu vois une différence entre la livebox ok et 
les autres?

Cordialement,

Steeve Beauvais

Ce message a été envoyé depuis un appareil mobile.

Le lun. 24 janv. 2022 à 22:07, Pierre LANCASTRE  a 
écrit :

> Hello
>
> +1 on veut bien le modèle des équipements
>
> Ca pourrait être un bpdu stp qui declencherait une feature bpdu block 
> soit côté Switch soit côté livebox, ou le renvoi ou autre d une trame 
> type loopdetect , ou autre truc fun genre un host de l infra qui 
> ferait du arp proxy . Ou encore mieux , déjà vu chez un client, un 
> câble branche sur un boîtier CPL.
>  Le bâtiment du client étant partage avec d autres entreprises, un 
> boîtier CPL d une autre entreprise du bâtiment venait se synchroniser 
> avec le boîtier CPL du client. Le client nous accusait de lui avoir 
> mis une box GP alors qu il devait avoir un accès xxx pro. sympa le 
> trou de sécu et fun a trouver :) Bref, le mieux serait de prendre un 
> pc, lancer un Wireshark pour les trois cas de figure : branchement 
> nominal, branchement sans la box orange (en prenant son port sur le 
> Switch) et une trace direct sur la box orange. Et focus sur le proto 
> arp + les protos L2 (stp etc) Comparer les résolutions arp pour les 2 
> cas où la livebox est sensée être joignable, ça sera un bon début :) 
> côté Switch, voir s il y a des commandes pour virer tout proto proprio 
> et les bpdu stp éventuellement. Avec le modèle des devices on aura 
> peut être d autres pistes
>
> My 2 cents
>
>
>
> Le lun. 24 janv. 2022 à 21:48, David Ponzone  
> a écrit :
>
> > Je comprends bien mais Jérémy a dit qu’avec un petit switch 
> > non-manageable, ça marchait.
> > C’est ce qui me fait penser à des paquets incorrects au niveau 
> > ethernet qu’un switch intelligent droppe, et donc la très majorité 
> > des clients
> n’ont
> > pas été impactés vu que pas de switch.
> >
> > Dans ton cas, c’est quoi le swtich ?
> >
> > > Le 24 janv. 2022 à 20:14, Jérome Fretigny  a
> écrit
> > :
> > >
> > > J ai rencontré un soucis similaire la semaine dernière lié à une 
> > > maj de
> > firmware (reconnu par orange après 3 change de live box )
> > >
> > > Dans mon cas j avais un réseau à plat, 34 postes sur le net, le 
> > > 

[TECH] RE: [FRnOG] [TECH] Guide de déploiement IPv6 en entreprise

[JCLB]

Bonjour,

Je n'ai effectivement pas abordé plus en détail le multihoming.
Avoir plusieurs préfixes, oui, ça fonctionne.
Maintenant, dès qu'on parle d'un petit environnement d'entreprise avec du DNS, 
des ACL, etc. ça devient inexploitable.
Personne n'imagine qu'à la réception d'une renumérotation du réseau dans un 
message RA on mette tout à jour et relance les serveurs dans la seconde.

Donc avoir un PI utilisé sans BGP avec du NPTv6 n'est pas si sale pour une 
structure trop petite pour peerer, mais trop grande pour faire du SOHO simili 
domestique.
Après tout NPT est stateless, donc performant et pas de problème s'il y a de 
l'asymétrie par exemple.
J'aborde NPT avec le local breakout, vu comme indiqué dans les échanges, on ne 
va pas faire du BGP over FTTx et tous remplir la fullview à la vitesse d'un 
générateur de scénarios de Luc Besson.

J'indique par contre que faire du NPTv6 avec de l'ULA pose un problème en 
interne, la précédence standard va privilégier IPv4 à IPv6 ULA. Du coup on ne 
teste pas réellement v6 jusqu'au jour où on supprime v4. Mais il est alors trop 
tard.

Jean-Charles Bisecco


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Denis 
Fondras Envoyé : samedi 18 décembre 2021 20:26 À : frnog@frnog.org Objet : Re: 
[FRnOG] [TECH] Guide de déploiement IPv6 en entreprise

Le Sat, Dec 18, 2021 at 07:35:01PM +0100, Wallace a écrit :
> 
> Du coup comment gérer ce cas?
> 

Plusieurs solutions :
- le plus propre, un préfixe PI et des opérateurs qui font du BGP
- la plus sale, du NPTv6
- la plus dans le vent, des VPN
- le plus (trop?) moderne, un routeur qui applique RFC9096


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[TECH] RE: [FRnOG] [TECH] Guide de déploiement IPv6 en entreprise

[JCLB]

Ça sera dispo en anglais pour le 5 janvier avec une diffusion large.

La bonne résolution 2022:
Toujours pas de silicium, pas d'ASICs, pas de projets de déploiement hardware.
Alors, déployons v6

Jean-Charles BISECCO


-Message d'origine-
De : Phil Regnauld  
Envoyé : samedi 18 décembre 2021 22:41
À : JCLB 
Cc : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Guide de déploiement IPv6 en entreprise

JCLB (JC) writes:
> Vous le trouverez ici en V1.1
> https://www.arcep.fr/uploads/tx_gspublication/guide-entreprises-comment-deployer-IPv6-novembre-2021.pdf

Ouah!

> Vos retours, idées d'ajout et commentaires sont les bienvenus.
> Le document a vocation à être mis à jour au moins 2 fois par an.
> 
> Je travaille en ce moment à la mise en forme de la version anglaise qui sera 
> mise en ligne à la rentrée.

Rentrée - c'est quand ? Y'a une version draft dispo en Anglais ?
Je connais plus d'une personne qui serait intéressée de passer
ça en revue.

Joli travail!

P.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Guide de déploiement IPv6 en entreprise

[JCLB]

Bonjour,

J'ai travaillé avec la taskforce IPv6 ARCEP à la rédaction d'un guide de 
déploiement d'IPV6 destiné aux entreprises.

Vous le trouverez ici en V1.1
https://www.arcep.fr/uploads/tx_gspublication/guide-entreprises-comment-deployer-IPv6-novembre-2021.pdf

https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6/task-force-ipv6.html

Vos retours, idées d'ajout et commentaires sont les bienvenus.
Le document a vocation à être mis à jour au moins 2 fois par an.

Je travaille en ce moment à la mise en forme de la version anglaise qui sera 
mise en ligne à la rentrée.

Jean-Charles BISECCO

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] RE: [FRnOG] [MISC] Dans la série est-ce bien ou pas le draft sur 127/8...

[JCLB]

Tant que c'est stateless avec une plage de port IPv4 attribuée ça reste 
acceptable. (4rd chez Free, MAP-T chez les autres)

Outre Rhin, DS-Lite est légion et c'est tout de suite moins drôle puisque c'est 
stateful, aux dernières nouvelles les opérateurs commencent à supporter PCP 
afin de permettre de "s'ouvrir" des ports en v4 au travers du CG-NAT.

JC Bisecco

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Pierre 
DOLIDON
Envoyé : vendredi 19 novembre 2021 12:45
À : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] Dans la série est-ce bien ou pas le draft sur 
127/8...

c'est pas tout a fait vrai
il y a quelques mois ma connexion qui avait une zoulie IPv4 qui n'avait jamais 
changée en 3 ans s'est vue forcée en CG-NAT, et activation d'IPv6.

donc il y a du mieux, en activant du pire au passage...

Le 19/11/2021 à 11:19, err...@free.fr a écrit :
>
> Ce qui serait pas mal c'est que tous les FAI grand public fournissent 
> de l'ipv6 à leurs clients (au moins pour les accès fibres).
> parce que visiblement SFR-RED ne fait pas beaucoup d'efforts dans la 
> fourniture d'ipv6.
> Ils font pourtant partie des plus gros fournisseurs d'accès à Internet 
> en france, et ils sont à la ramasse pour l'ipv6.
>
>
>
>
>
> ---
> 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/

[MISC] [FRnOG] [MISC] Dans la série est-ce bien ou pas le draft sur 127/8...

[JCLB]

Bonjour,

Le groupe auteur de ce draft en a produit 3 qui updatent toutes les autres 
tentatives. Ça ressemble plus à un troll qu'à une véritable demande.
Voir 
0
https://www.ietf.org/id/draft-schoen-intarea-unicast-0-00.html
240
https://www.ietf.org/id/draft-schoen-intarea-unicast-240-00.html
Et le 127 du sujet
https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html

JC Bisecco

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Guy 
Larrieu via frnog
Envoyé : jeudi 18 novembre 2021 10:56
À : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] Dans la série est-ce bien ou pas le draft sur 
127/8...

Bonjour,

Vivien, du forum lafibre.info, maintient un document avec les stats par pays : 
https://lafibre.info/images/ipv6/statistiques_ipv6.pdf?version=last

La méthode et les sources sont décrites ici : 
https://lafibre.info/ipv6/ipv6-pays/

Guy.


Le 18-11-2021 10:45, Samuel Thibault a écrit :
> Bonjour,
> 
> Dominique Rousseau, le jeu. 18 nov. 2021 09:34:09 +0100, a ecrit:
>> PS: quelqu'un a un pointeur vers des stats actuelles du ratio v4/v6 ?
> 
> J'utilise http://www.google.fr/ipv6/statistics.html pour en parler à 
> mes étudiants.
> 
> Samuel
> 
> 
> ---
> 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/

[TECH] RE: [FRnOG] [TECH] [Help]Problème d'OSPF cisco

[JCLB]

Bonjour,

L'usage du bit DN sur les OSPF de ces 2 sites résoudrait le problème si OSPF 
était également le protocole CE-PE.
Si le client veut profiter de sa FON comme un backup ultime de son accès à ses 
2 sites, il faut déprioriser. Sinon, filtrer.

Un tag OSPF lors de la redistribution dans iBGP, une route map pour faire 
coller ça avec un moyen de déprioriser (au choix)
Ne pas oublier de valider le sens opposé également. (que ton site ne sorte pas 
via l'autre site plutôt qu'en direct)

Si le client ne cherche pas à multiplier la redondance, le filtrage est plus 
simple.

PS: j'ai un bad gateway sur ton URL

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Gregory 
CAUCHIE
Envoyé : lundi 15 novembre 2021 17:28
À : Julien CANAT 
Cc : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] [Help]Problème d'OSPF cisco

Bonjour Julien,

Quelle politique de Local-bref as-tu appliqué sur la redistribution OSPF > iBGP 
?
Peux-tu nous décrire un peu plus la boucle de routage en question ?

--
Greg

> On 15 Nov 2021, at 17:05, Julien CANAT via frnog  wrote:
> 
> Bonjour à tous,
> 
> 
> Nous rencontrons un problème avec l'un de nos clients multi-sites.
> 
> Ce client dispose d'une VRF dans notre MPLS. Les CPE des sites 
> distants
> (~80) annoncent leurs routes au routeur d'infra auquel ils sont 
> connectés en OSPF. Ces routes sont redistribuées en iBGP entre les 
> routeurs d'infra.
> 
> Entre les deux sites primaires du client, le client dispose d'une FON 
> et fait de l'OSPF pour assurer la redondance entre les sites 
> primaires. Sur les sites primaires l'annonce de routes entre CPE et 
> routeur d'infra est en iBGP. Entre le CPE et les routeurs du client il 
> y a de la redistribution en OSPF, la métrique est plus élevée sur le 
> site 2 (1000) au lieu du default (1).
> 
> Le problème que l'on rencontre est que parfois les routes au lieu 
> d'arriver sur le CPE-site1 sont apprises via l'OSPF du client et le
> CPE-site2 ce qui a une tendance a créer une légère boucle de routage. 
> Ce problème se résout par un reset de l'OSPF sur le CPE-site1.
> 
> Les routeurs d'infra sont des ASR920, sur les sites primaires il y a 
> des
> C et l'un d'eux a été remplacé par un 1921 pour écarter le bug 
> matériel.
> 
> Quelqu'un aurait une idée d'où ce problème peut venir ? Serait-ce un 
> bug connu chez Cisco ?
> 
> Comme les pièces jointes sont interdites sur la liste : vous trouverez 
> un schéma ici : https://claude.trinaps.com/s/qx3gY6R5ecPTWAT (mdp: FRnOG).
> 
> J'ai enlevé les détails qui permettraient d'identifier ce client, pour 
> des raisons évidentes de discrétion, mais si certaines choses 
> demandent éclaircissement, je suis bien évidemment prêt à répondre.
> 
> D'avance merci.
> 
> --
> Julien CANAT
> 
> TRINAPS - Ingénierie Réseau
> 
> 
> ---
> 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/

RE: [FRnOG] [TECH] Lociciel de looking-glass

[JCLB]

Bonjour,

Ce projet fournit un dashboard BGP bien rempli:
https://github.com/rhicks/bgp-dashboard

This project uses three Docker containers
GoBGP (osrg/gobgp)
MongoDB (mongo)
Flask (docker-flask)

Fork ici https://github.com/darkorb/bgp-dashboard/tree/migrate-to-alpine
Plus maintenu, le compose de l'image peut nécessiter des modifs.

Jean-Charles BISECCO

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Laurent 
CARON
Envoyé : jeudi 21 octobre 2021 11:42
À : Liste FRnoG 
Objet : Re: [FRnOG] [TECH] Lociciel de looking-glass


Le 21/10/2021 à 03:42, Michel Py via frnog a écrit :
> Bonjour à toutes et à tous,
>
> Je cherche un logiciel pour faire un looking-glass BGP.

Bonjour Michel,

bgplg: https://man.openbsd.org/bgplg.8

Exple: http://lg.ocnet.se/cgi-bin/bgplg

Laurent,


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [BIZ] Recherche Nexus 9K 93108-TC et 93180-YC

[JCLB]

Bonjour,

Je recherche des Nexus 9000 de type :
-93180-YC (SFP+)
-93108-TC (Cuivre)

en EX ou FX(2).

Vous pouvez me proposer d'autres modèles tant qu'ils sont soit cuivre soit SFP+.
Une partie des équipements seront exploités en ACI 5.2, l'autre en NX-OS mais 
là-dessus je peux voir avec Cisco directement, de même je m'occuperais du 
contrôle de la remise sous maintenance à réception des n° de série.

Merci,
Jean-Charles BISECCO







---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [ALERT] Facebook Whatsapp Instagram down

[JCLB]

Et entre l'entrée de l'AS et les Serveurs il doit y'avoir une flopée de load 
balancers virtuels, possiblement gérés avec la même config synchronisée...
Un Tier 1 a fait le coup de RTBH aussi y'a quelques mois si je me souviens bien.

Plus efficace que prévu cette nouvelle autorité ARCOM en tout cas... 

En parlant de mettre tous ses œufs dans le même panier, les inscriptions signal 
et telegram devraient grimper.

JC Bisecco

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Vincent 
Habchi
Envoyé : lundi 4 octobre 2021 19:03
À : Liste FRnoG 
Objet : Re: [FRnOG] [ALERT] Facebook Whatsapp Instagram down


> On 4 Oct 2021, at 18:28, Stephane Bortzmeyer  wrote:
> 
> On Mon, Oct 04, 2021 at 06:23:54PM +0200, Stephane Bortzmeyer 
>  wrote a message of 23 lines which said:
> 
>>> Qu'en pensez vous ? (outre le fait que c'est du travail d'amateur 
>>> d'avoir mis les 4 NS sous le même TLD)
>> 
>> Ce point de vue est très discuté (cf. les recommandations ANSSI sur 
>> la gestion sécurisée de noms de domaine).

Je vais peut-être parler au travers de mon chapeau, comme disent les Anglais, 
mais de toute façon, à quoi bon héberger les DNS ailleurs si tous les serveurs 
dépendent d’un unique AS ? Si cet AS tombe, l’intérêt que les DNS soient 
toujours disponibles me paraît assez maigre.

V.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] RFC 9075: Report from the IAB COVID-19 Network Impacts Workshop 2020

[JCLB]

L'ICANN avait publié un rapport intéressant sur un autre aspect, la flopée de 
.home, .corp et autre TLD qui finissaient tout en haut en requête:
https://www.icann.org/en/system/files/files/octo-008-15apr20-en.pdf

JC Bisecco

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Stephane 
Bortzmeyer
Envoyé : vendredi 23 juillet 2021 09:44
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] RFC 9075: Report from the IAB COVID-19 Network Impacts 
Workshop 2020

Premier « RFC Covid », ce RFC 9075 est le compte-rendu d'un atelier de l'IAB 
sur les conséquenecs concrètes de la pandémie et des confinements sur les 
réseaux informatiques et notamment l'Internet. Bisous aux technicien·nes grâce 
à qui tout a finalement bien tenu.

https://www.bortzmeyer.org/9075.html

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[TECH] RE: [FRnOG] [TECH] Fwd: Jarretières pour Turris Omnia, was [FRsAG] [Matos] La jarretière suivi de ?

[JCLB]

Et n'oublie pas de demander à ton opérateur R=D une IPv4 dédiée, histoire de ne 
pas avoir à jouer avec MAP-T ou autre approche A+P qu'utilise SFR.
Bien qu'openwrt servant de base à turris OS, il y'a tous les paquets 
nécessaires pour traiter ce cas si on aime se compliquer la vie.

JC Bisecco

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Michel Py 
via frnog
Envoyé : jeudi 15 juillet 2021 23:42
À : Paul MARCHAND ; N R ; 
frnog-tech 
Objet : RE: [FRnOG] [TECH] Fwd: Jarretières pour Turris Omnia, was [FRsAG] 
[Matos] La jarretière suivi de ?

Je me corrige moi-même :

> Michel Py a écrit :
> - La GPON est 1490nmTx/1310nmRx, l'Ethernet est 1310nm-TX/1550nm-RX là déjà 
> pas glop, si c'est pas identique aucune chance.
>  Pour avoir une chance, faudrait celle-ci : 
> https://www.fs.com/fr/products/75342.html

Ces longueurs d'onde, c'est du côté opérateur, je pense. Comme toutes les 
optiques bidi, les deux cotés ne sont pas les mêmes.

Coté opérateur :
En descendant (opérateur -> client) 1490nm Tx 2.5G Tx. En montant (client -> 
opérateur) 1310nm Rx 1.25G Rx.
Cette optique : https://www.fs.com/products/64169.html c'est donc une optique 
pour le coté opérateur, ce qui pourrait expliquer le prix; je pense que le 
laser de transmission doit patater plus à cause des divisions de la fibre.

Du coté CPE, c'est l'inverse.
En montant (client -> opérateur) 1310nm Tx 1.25G Tx. En descendant (opérateur 
-> client) 1490nm Rx 2.5G Rx.

Si tu veux essayer de bidouiller une optique Ethernet en GPON coté client, 
c'est donc celle-ci qu'il faut essayer :
https://www.fs.com/products/15535.html
La codage couleur me plait nettement plus : bleu, coté client. Celle que 
j'avais suggérée avant était violet, coté opérateur. J'avais pas percuté tout 
de suite.

Tout ça c'est à vérifier, bien entendu.

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] 2 Default gateway sur un VM Win2019 dans Azure

[JCLB]

Bonjour,

RDP utilise une config particulière, cf cette KB 
https://docs.microsoft.com/en-us/troubleshoot/windows-server/remote/cant-establish-remote-desktop-session


  1.  Select Start, Run, type tscc.msc /s (without quotation marks and select 
OK).
  2.  In the Terminal Services Configuration snap-in, double-click Connections, 
then RDP-Tcp in the right pane.
  3.  Select the Network Adapter tab, select the correct network adapter, and 
select OK.
  4.  Make sure that you can establish an RDP connection to the server.

JC Bisecco



De : frnog-requ...@frnog.org  de la part de David 
Ponzone 
Envoyé : Friday, July 2, 2021 2:02:42 PM
À : frnog-tech 
Objet : [FRnOG] [TECH] 2 Default gateway sur un VM Win2019 dans Azure

Ami(e)s certifié(e)s Azure,

Je crois constater des choses bizarres sur une VM Azure avec Win2019.
Elle a 2 cartes réseau, celle par défaut et une autre.
On a une route par défaut de metric 100 par la carte par défaut (et l’IP 
publique de la VM), et une route par défaut de metric 10 par la seconde carte.
route print confirme que ça devrait sortir par la seconde.

Sur un accès à Internet depuis la VM c’est bon.
Mais pour d’autres choses (traffic RDP qui arrive par la seconde carte), ça 
semble repartir par la première sans raison (donc RDP ne passe mais si on 
désactive la première carte, ça marche).

Comme j’ai pas envie de mourir idiot, c’est juste que:
-Win2019 fait vraiment n’importe quoi avec les paquets et faut pas se fier à sa 
table de routage
-Azure fait des trucs bizarres sous la table avec le trafic sortant
-autre idée ?

Merci

David


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Modem GSM USB

[JCLB]

Une option peu coûteuse est un petit routeur domestique flashé sous openWRT 
avec le module suivant 
https://forum.openwrt.org/t/luci-app-luci-app-sms-tool-sms-ussd-codes-at-commands/69451

Avec une clé 4g en mode modem (pas de huawei hilink par exemple)

L'avantage du sms est qu'on peut potentiellement scripter l'envoie de commandes 
à un équipement derrière.

En prime un VPN wireguard qui pointe vers un serveur ailleurs (qui peut être 
allumé en cas d'incident, tant que le script watchdog wireguard est mis dans le 
cron d'openwrt)

Ne pas oublier les routes statiques vers des ip de serveurs ntp en plus de 
l'hostname du wireguard et des dns, sinon au boot ça ne monte pas et ne refait 
pas de tentative (de nombreux posts traitent du problème sur le forum openwrt)

Coût total 60€ de matos

Et pour du dépannage low level en remote, un pi kvm 4 qui arrive en vente cet 
automne en europe, avec le switch kvm hdmi qui va bien.

Personnellement pour du simple monitoring je préfère comme déjà cité ici une 
attaque par le wan depuis une machine externe.

Jean-Charles Bisecco

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [BIZ] Boitier Multi-ISP

[JCLB]

L'option la moins onéreuse doit être OpenWRT avec le paquet mwan3

Permet de faire du load balancing et du failover.
Supporte des règles basées sur IP, port, source et destination, et surtout 
enregistrement DNS cible.

Le mode sticky permet de conserver les sessions longtemps, pratique pour ne pas 
se pointer sur un site avec une autre IP à chaque chargement de page.

Attention à UPnP/NAT-PMP/PCP avec le multi wan, lorsqu'une app demandera 
l'ouverture d'un pour  pour un P2P (visio par exemple) je ne sais plus si le 
paquet effectuera l'ouverture sur l'ensemble des WAN. Sinon spécifier des 
règles pour les ports de cette app et la mettre en mode failover.

J'ai utilisé la 1ère version du multiwan il y'a fort longtemps avec 3 modems 
numéricable à 30mb/s. Les torrents filaient à 83 mb/s

JC Bisecco

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Lucas 
Viallon
Envoyé : mardi 4 mai 2021 12:03
À : frnog-...@frnog.org
Objet : [FRnOG] [BIZ] Boitier Multi-ISP

Bonjour,

Je recherche un bon boitier pour faire du routage/équilibrage de charge sur 
deux accès internet.
Quelqu'un pourrait me conseiller ?

En gros, j'ai deux routeurs:

192.168.0.250 et 192.168.0.251
je voudrais que le boitier soit en 192.168.0.254 et fasse un équilibrage de 
charge entre les deux passerelles.

merci
Lucas

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [BIZ] RE: Seeking Rural Data Centres 47.83201 1.95368

[JCLB]

Obviously, even for a starlink site !
240m2, let's see

https://www.francebleu.fr/infos/societe/le-maire-de-gravelines-refuse-le-permis-de-construire-pour-les-antennes-relais-1619636498
not a coincidence

JC Bisecco

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Raphaël 
Jacquot
Envoyé : vendredi 30 avril 2021 17:14
À : frnog@frnog.org
Objet : Re: [FRnOG] [BIZ] RE: Seeking Rural Data Centres 47.83201 1.95368



Le 30/04/2021 à 16:17, JCLB a écrit :
> Hi Rod,

> FYI, there is a known quiet radio area close to Orleans, see 
> https://en.wikipedia.org/wiki/Nan%C3%A7ay_Radio_Observatory
> Still no DC in the area obviously...

obviously there's no way you'll get authorisation to install any radio 
equipment in said quiet area...

Raphael


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [BIZ] RE: Seeking Rural Data Centres 47.83201 1.95368

[JCLB]

Hi Rod,

Living at 2.5 km from your requested position, I can confirm there is no DC in 
the area. (Unless you want to buy Hitachi's former SAN factory...)
Half of the town of St-Cyr-en-Val is in Loiret+Loire Submersible area > 
https://www.orleans-metropole.fr/fileadmin/orleans/MEDIA/document/environnement/risques_majeurs/hauteur_eau_agglo.pdf

You can check for radio towers on 
https://www.cartoradio.fr/index.html#/cartographie/all/lonlat/1.951169/47.834729

FYI, there is a known quiet radio area close to Orleans, see 
https://en.wikipedia.org/wiki/Nan%C3%A7ay_Radio_Observatory
Still no DC in the area obviously...

Jean-Charles BISECCO

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de FRENEAUX 
Vincent
Envoyé : vendredi 30 avril 2021 15:22
À : Rod Beck ; frnog-...@frnog.org
Objet : [FRnOG] [BIZ] RE: Seeking Rural Data Centres 47.83201 1.95368

Hi Roderick,

I'm near Orleans and as far as I know there is no local DC on the area.

The closest one is Tours with Cyrès https://datacenter.cyres.fr/ Or Paris with 
different actors.

If you have any question (specially on the "Val de Loire" with seems to be the 
area you are seeking), please feel free to respond to me.    

Vincent FRENEAUX
Network Administrator
Hexatel

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Rod Beck 
Envoyé : vendredi 30 avril 2021 15:02 À : frnog-...@frnog.org Objet : [FRnOG] 
[BIZ] Seeking Rural Data Centres 47.83201 1.95368

Salut,

Any data centres within 50-75 kilometers of these coordinates? For an earth 
station project. Data centre should be in a sparsely populated area at least a 
half kilometer from nearest cellular tower. Good line of sight. At least 240 m2 
of flat ground or rooftop.

Merci,

Roderick.


Roderick Beck

Global Network Capacity Procurement

United Cable Company

www.unitedcablecompany.com
https://unitedcablecompany.com/video/
New York City & Budapest

rod.b...@unitedcablecompany.com

Budapest: 36-70-605-5144

NJ: 908-452-8183



[1467221477350_image005.png]

---
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/

[TECH] RE: [FRnOG] [TECH] Une announce BGP inhabituelle (armée étatsunienne)

[JCLB]

La projet de migration IPv6 du DoD étant bien lent, ils se sont surement dit 
qu'ils allaient commencer à vendre des IPv4 plus rapidement que ce que 
prévoyait la bill non validée évoquée dans l'article.

Pour ce faire ils doivent s'assurer de la totale étanchéité de l'espace 
d'adressage sur les équipements frontières (chainage proxy, double NAT,...)
Et le meilleur moyen de vérifier que tout est prêt c'est d'annoncer soit même 
les préfixes avec un kill switch.

Auparavant ils devaient logiquement filtrer leurs blocs DoD en annonce de WAN, 
comme toute liste de bogon l'impose.
Maintenant ils veulent voir si les échanges entre leur réseau interne et de 
véritables machines publiques portant les mêmes IP ne posent aucun problème.

Et si le pilote passe, qu'aucun effet de bord ou repérage d'élément mal 
configuré n'est à déplorer, alors les enchères pourront démarrer.

Personnellement je ne crois pas une seule seconde aux histoires de collecte de 
trafic, c'est pour ne pas parler de vente.
Les pays listés sont tous membres NATO ou ANZUS pour la petite histoire.

Jean-Charles Bisecco

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Michel Py 
via frnog
Envoyé : samedi 24 avril 2021 20:52
À : 'Stephane Bortzmeyer' ; frnog-t...@frnog.org
Objet : RE: [FRnOG] [TECH] Une announce BGP inhabituelle (armée étatsunienne)

> Stephane Bortzmeyer a écrit :
> Si vous voulez regarder l'AS 8003 sur stat.ripe.net, prenez une machine 
> costaud, le navigateur Web va souffrir.

En faisant quoi ? Je ne vois que 625 préfixes, c'est pas la mer à boire.


> thomas brenac a écrit :
je me demande pourquoi il y a des geolocalisations en Espagne, Belgique, 
Australie, Norvege.

Moi aussi, mais je suis sur que c'est legit.

> et 'que' 379 /24 sur un total de 625 prefixes.

Oui je suis surpris aussi, je m'attendais à bien plus.
Analyse détaillée à suivre.

Michel.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] RE: [MISC] APC Network Shutdown

[JCLB]

Quelques pistes:

Si l'onduleur fait partie du réseau SCADA, il existe des alternatives au client 
APC,
par exemple https://networkupstools.org/stable-hcl.html et 
https://www.nextups.eu/software/winpower/#featuresummary
Pas de support constructeur évidement...

De façon manuelle il est aussi possible de faire tourner un bon vieux script 
qui va poller périodiquement l'onduleur via SNMP, même sur un Windows en 
gériatrie. Plus léger et on peut alors échapper à la requalification du système 
pour la chaine de prod.


Autre voie, via la commande ATX du PC:

En se basant sur les travaux du projet Pi-KVM, avec ce genre de carte vers les 
pins power et led des serveurs 
https://lestronics.co.uk/product/pi-kvm-atx-controller-module/ à base de relai 
SSR/optocoupleur
Ça permet de savoir si la machine est allumée et d'envoyer l'impulsion d'arrêt, 
en plus pas de réseau et donc possibilité d'avoir l'UPS et ça sur un réseau 
"routé" et non sur le SCADA.
Pas besoin d'avoir la main sur l'OS en plus.

Il est aussi envisageable d'exploiter un ESP nu ou tout prêt comme des sonoff;
y mettre tasmota ou ESPhome et contrôler ça depuis une machine qui peut lire 
l'état de l'UPS.

Un POC rapide peut être mis en place avec Home Assistant HASSIO, l'addon 
Network UPS Tool et un module ESP.


Enfin on peut tout faire sur un ESP ou un raspberry pico (python) autonome
Exemple de librairie arduino SNMP 
https://github.com/shortbloke/Arduino_SNMP_Manager
En bonus l'ESP peut-même être programmé pour aller vérifier via modbus que tel 
ou tel élément de la chaine est bien injoignable avant d'initier l'arrêt du 
serveur. (ne pas oublier le FW SCADA Modbus)

J'ai aussi connu la joie de voir arriver des machines neuves à 7 chiffres avec 
un OS désuet: des équipements d'imagerie médicale.

Jean-Charles BISECCO


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Subnet ip publique sur LAN

[JCLB]

C'est courant dans les grandes structures, exemple : en dehors de CA, 
l'ensemble des grandes banques utilisent des IP publiques de tiers en France 
sur une partie de leur réseau privé local.


Voilà ce que j'en dis dans un document sur le déploiement d'IPv6 à publier 
prochainement:

La RFC 1918 offre 17 891 328 IPv4, cela ne représente jamais que 70 000 réseaux 
en /24. De nombreuses organisations ont déjà atteint la limite du stock, pour 
de multiples raisons.
Affectation par entité, gaspillage et surallocation, non récupération des 
adresses lors du décommissionnement d’équipements ou de sites, volonté 
d’agréger les routes remontant à une
époque où les routeurs ne supportaient qu’un faible nombre de routes, 
transmission à des filiales revendues mais avec lesquelles des liens 
persistent, …

Si le NAT44 peut répondre de façon inconfortable aux liaisons vers des 
partenaires et des entités fraichement acquises, il est souvent impensable de 
découper son entreprise en différents périmètres se recouvrant ; bien que ce 
cas de figure existe aussi.
D’autres prennent la voie de l’usurpation, et exploitent sur leur réseau 
interne des IP qui appartiennent à autrui avec plus ou moins de tact. On 
retrouve 2 camps :

-Les prudents, qui mettent en œuvre du double NAT44 et créent un véritable sas 
compartimentant le routage en bordure d’internet.
Le trafic est natté 2 fois et peut sans problème avoir la même IP en source et 
en destination, le NAT masquant un autre NAT, l’écran est total.
Ces prudents se retrouvent bien dépourvus quand un fournisseur cloud leur 
recommande d’annoncer l’IP public d’un service sur leur backbone interne.
Que faire si jamais cette vraie IP publique en recouvre une usurpée du LAN ? 
D’autant plus qu’un fournisseur peut imposer de nouvelles IP avec seulement 
quelques semaines de prévenance.
Scénario de SF ? Du tout ! Un exemple concret parfait est l’utilisation de la 
solution de communication de Microsoft, TEAMS. Ce dernier recommande en effet 
de limiter les traitements intermédiaires à un seul NAT, pour des raisons 
expliquées plus haut dans ce document.


-Les confiants, qui exploitent des IP qui ne seront jamais annoncées sur 
internet comme celles du département Américain de la Défense (DoD) :
6.0.0.0/8 7.0.0.0/8 11.0.0.0/8 21.0.0.0/8 22.0.0.0/8 26.0.0.0/8 28.0.0.0/8 
29.0.0.0/8 30.0.0.0/8 33.0.0.0/8 55.0.0.0/8 214.0.0.0/8 215.0.0.0/8

Enfin, ça c’est la théorie car fin 2019 la section 1088 de la loi de budget du 
DoD prévoyait de vendre ces plages dans les 10 ans. Cependant l’article n’a pas 
passé le Sénat. Mais qu’en est-il si une copie revient un jour ?
Rien à craindre dans le 117e congrès de fin 2020.
https://www.congress.gov/bill/116th-congress/senate-bill/1790/text/eah#toc-H3733C370A69A4095B62B213B52530170
Si jamais ces adresses se retrouvaient en vente, nul doute qu’une partie 
finirait dans les mains des principaux fournisseurs cloud.

Si vous approchez de la fin de la RFC 1918, vous pouvez étudier l’usage de la 
plage RFC 6598 100.64/10 réservée au NAT44 opérateur afin de partager des IPv4 
entre abonnés avec un Carrier Grade Nat.
Reste qu’il est recommandé de ne pas assigner ces adresses à des équipements 
opérateurs comme des routeurs MPLS ou de les exploiter sur des infrastructures 
cloud, sauf après validation du fournisseur.
Aucun problème en revanche à exploiter cette plage pour ses campus utilisateurs 
par exemple. Certaines entreprises le font déjà, y compris en France.

Enfin, si vous êtes joueur, vous pouvez tenter d’utiliser l’ex classe E 
(240/4). Celle située aux confins d’IPv4, après la section multicast.
Réservée pour un usage futur qui ne viendra jamais et inutilisable chez les 
équipementiers qui reconnaissent d’ailleurs que le travail nécessaire pour
normaliser cette plage mettrait plus de temps à atteindre l’ensemble des parcs 
déployés que de migrer vers IPv6.
En vrai n’essayez pas, sauf en lab par pure curiosité.

---
Il y'a aussi les riches qui s'ignorent et ont des millions de vraies IPv4 
publiques, ne les annoncent pas et les utilisent en interne (oui oui ça existe 
encore)

Jean-Charles BISECCO



-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Richard 
MATOS
Envoyé : mardi 16 mars 2021 11:16
À : frnog-tech 
Objet : [FRnOG] [TECH] Subnet ip publique sur LAN

Salut la liste,

J'ai un client qui utilise un plage d'adresse ip publique sur son LAN, est-ce 
que certains parmi vous ont rencontré ce cas de figure ?
Si oui quelle solution avez-vous implémenté?

Merci


--
Richard MATOS

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Supervision latence et traceroute tout en un

[JCLB]

Bonjour,
En complément :

Route explorer de ciena, commercial
https://www.ciena.com/insights/data-sheets/Route-Explorer.html

le netpath de solarwind et route explorer peuvent faire du traceroute mais 
surtout récupérer des infos de routage.


Voilà 2 projets libres s'approchant du besoin mais uniquement  côté BGP
SNAS.io
https://www.snas.io/demo/demo-grafana/

BGPalerter
https://github.com/nttgin/BGPalerter

Je suis sûr que beaucoup ici ne manqueront pas de tester ces 2 liens sur leur 
docker ce week-end.

Jean-Charles BISECCO

De : frnog-requ...@frnog.org  de la part de Sébastien 
65 
Envoyé : Friday, March 12, 2021 9:53:38 AM
À : Denis Fondras ; frnog@frnog.org 
Objet : RE: [FRnOG] [TECH] Supervision latence et traceroute tout en un

Oui ce n'est pas libre mais exactement ce que je cherche 

Par contre le prix woua ça pique !!! En plus Solarwinds en ce moment n'est pas 
en pleine forme... Sunburst !!!

De : frnog-requ...@frnog.org  de la part de Denis 
Fondras 
Envoyé : vendredi 12 mars 2021 08:43
À : frnog@frnog.org 
Objet : Re: [FRnOG] [TECH] Supervision latence et traceroute tout en un

Le Fri, Mar 12, 2021 at 07:06:20AM +, Sébastien 65 a écrit :
> Bonjour à tous,
>
> Existe-t-il un outil avec une interface web permettant de visualiser la 
> latence et le chemin emprunté pour joindre une destination ?
>
> Je cherche une interface capable de me donner la variation sur la latence 
> ainsi que le changement de chemin.
>
> J'utilise SmokePing mais je n'ai pas l'historique du chemin utilisé (style 
> traceroute).
>
> Une idée d'un produit si possible open-source ?
>

Sapuspalibre :
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.solarwinds.com%2Ffr%2Fnetwork-performance-monitor%2Fuse-cases%2Fnetpathdata=04%7C01%7C%7Cc462d6d8765a46894b5c08d8e52aa7c0%7C84df9e7fe9f640afb435%7C1%7C0%7C637511318646510668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=dpx7wYftx%2FqVVIPpGojUWlEFYxofQ1uG4Uv%2B3hTrUMw%3Dreserved=0

Mais ca fonctionne bien :po


---
Liste de diffusion du FRnOG
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Cc462d6d8765a46894b5c08d8e52aa7c0%7C84df9e7fe9f640afb435%7C1%7C0%7C637511318646510668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oqpZ8PKW7x01InGYXomONEA%2FmHWeFo2LngA3qqFXQ%2FA%3Dreserved=0

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] Re: [FRnOG] [MISC] Comment AWS implémentent-tils 169.254.169.254?

[JCLB]

Dans le pays où je suis actuellement un grand opérateur utilise cette plage 
pour sa collecte du backbone jusqu'à l'IP du modem. Avec du double NAT44 
donc... ils doivent pas connaître le 100.64/10

En fait les seules IP qui vont bloquer techniquement ce sont les loopback 127.0 
, les multicast 224+ et la classe anciennement dite E située après le multicast 
et inutilisée 240+.
Encore que sur certains systèmes il est possible d'utiliser la classe E mais ça 
n'est jamais officiellement supporté.

Le risque avec le 169.254 c'est que sans configuration préalable et sans DHCP 
elle s'affecte automatiquement sur une NIC.
Prenons une VM avec une carte dans un réseau 169.254.x /24. Tu ajoutes une 
carte à la VM et elle se met en lien local le temps que tu la configure si elle 
croit avoir du lien "physique". Ta carte va prendre une 169.254/16 et du coup 
tout le trafic destiné à du 169.254 autre que le /24 de la 1ere carte va finir 
blackholé sur la nouvelle NIC.

Ça rend ce réseau exploitable uniquement sur un ensemble orchestré où le 
système n'a aucune chance de tomber en autoconf.

Jean-Charles Bisecco



De : frnog-requ...@frnog.org  de la part de Philippe 
Bourcier 
Envoyé : mardi, février 23, 2021 11:08 AM
À : frnog-m...@frnog.org
Objet : Re: [FRnOG] [MISC] Comment AWS implémentent-tils 169.254.169.254?

Re,

Pour compléter...

> Les adresses 169.254 sont en fait comme les autres.
> Tu peux numéroter des interfaces avec, ça marche parfaitement.

Tout à fait, c'est même un de leurs objectifs...
La seule spécificité de ces adresses c'est leur méthode d'attribution.
L'idée originale était d'avoir des IPs automatiquement assignées aux machines 
en cas de panne du service DHCP sur un réseau.
Microsoft à appelé cela APIPA : 
https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing

Du coup c'est un réseau routable, etc... comme les autres, vu que l'objectif 
est de faire fonctionner des machines, même si DHCP est par terre. Bref, c'est 
juste son cas d'usage et d'attribution initial qui diffère d'un autre réseau.
Cela dit, tu peux aussi faire un réseau entièrement static en adressage 
APIPA... comme si c'était une autre plage d'IPs privées (192.168/16, 10/8, 
etc.) et c'est ce que semble faire AWS.


Cordialement,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Outils pour surveillance ping

[JCLB]

Bonjour Lucas,

En complément de l'outillage, le plus précis à mon sens est de mettre en place 
une session BFD sans forcément avoir de process de routage client de celle-ci.
Avec des timers agressifs et le bon regex sur le serveur syslog rien ne 
t'échappe.

D'ailleurs, quand tu as un problème sur un chemin de plusieurs routeurs tu peux 
faire du bfd multihop itératif avec plusieurs sessions, ça permet de voir si le 
problème ne vient pas également de "l'intérieur" d'un routeur et pas d'un lien.

Enfin, pour revenir en centralisé les sondes compatibles IP SLA peuvent 
également être une piste si les routeurs supportent la fonction de responder.

Jean-Charles BISECCO


De : frnog-requ...@frnog.org  de la part de Lucas 
Viallon 
Envoyé : Tuesday, February 16, 2021 8:29:07 AM
À : frnog-m...@frnog.org 
Objet : [FRnOG] [MISC] Outils pour surveillance ping

Bonjour,

Comme tous le monde, nous devons de temps en temps placer une liaison en
surveillence car nos clients on des "micro coupures".

Le genre de micro coupure que quand vous testez vous ne voyez rien car il
faut le faire sur 24 a 48h.

Jusqu'ici on lance un ping sur une machine et on regarde 24h plus tard
combien on a perdu de ping. Pas tres fiable et pratique.

Notre supervision Centreon fait un test de quelques pings toutes les 5mn
donc on ne peut pas voir.

Quelqu'un sait si il y a un outils opensource style une interface web, on
indique l'ip a surveiller, cela lance un ping permanent (ou qui ce
renouvelle toutes les x minutes sans periode de blanc)  et ou l'on peut
retrouver dans l'interface un mini compte rendu  ?

merci

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] Re : [BIZ] Re: [FRnOG][MISC] Présentation Orchestration (NSO)

[JCLB]

Bonjour,

On parle ici d'API et pas de réseau sur l'aspect nord / sud.

Le sud c'est le contrôle des équipements par NSO, le nord c'est le parent qui 
contrôle NSO (par exemple openstack, un portail de demande de service maison, 
vmware vrealize,...)

Sur une carte mère le northbridge traite les bus rapides et le south les lents 
comme l'audio.
Ceci étant beaucoup de choses passent directement en pci-e maintenant.

Tout ça pour dire que nord et sud peuvent avoir différentes définitions selon 
qu'on parle de contrôle, de flux, de hardware,...

C'est à en perdre le n

Bon week-end

De : frnog-requ...@frnog.org  de la part de Wallace 

Envoyé : vendredi 12 février 2021 15:52
À : frnog@frnog.org 
Objet : Re: [BIZ] Re: [FRnOG] [MISC] Présentation Orchestration (NSO)

De ma compréhension est ouest ce sont les données internes qui doivent
aller au plus vite et avec une latence la plus faible possible. Le nord
sud c'est la sortie du réseau et il faut faire en sorte de limiter ce
trafic dans une archi edge spine leaf.

Le zéro trust est une autre approche, qui consiste à avoir une seule
source de vérité (ipam, git, fichiers) et de ne pas considérer ses
équipements comme étant fiables mais au contraire toujours faire les
réglages et actions en pensant qu'ils sont compromis de fait.

Le 12/02/2021 à 15:38, Adrien Rivas a écrit :
> Oui, le trafic Nord / Sud correspond aux flux entrants / sortants, Est /
> Ouest aux déplacements latéraux dans le réseau.
>
> Il me semble que c'est une notion assez récente, (et si je ne me trompe
> pas) qui vient du design zéro trust (je laisse les colistiers corriger si
> besoin).
>
> Le ven. 12 févr. 2021 à 11:45, Remi Desgrange 
> a écrit :
>
>> Comme c'est vendredi je passe en MISC.
>>
>> Veuillez pardonner mon ignorance mais API nord et sud c'est quoi ? Y'a
>> aussi Est et Ouest ?
>>
>> On Fri, Feb 12, 2021 at 9:43 AM Clément THERY 
>> wrote:
>>
>>> Bonjour à tous,
>>>
>>> Comme c'est vendredi, je me permets de vous envoyer ce mail rapide.
>>> L'idée, n'est pas de lancer un grand débat, mais plutôt d'inviter ceux
>> qui
>>> le désire à une présentation en ligne. (La date reste à définir, mais ce
>>> sera courant Mars)
>>>
>>> Aujourd'hui, de nombreux outils existent pour automatiser la livraison de
>>> services (L2VPN, L3VPN, ...) sur les réseaux opérateurs. Avec plus ou
>> moins
>>> d'efficacité, beaucoup sont capables de créer un service : ajouter toutes
>>> les commandes nécessaires à partir d'une configuration vierge. Moins sont
>>> capables de le mettre à jour ou encore de le supprimer. Très peu sont
>>> capables de le réparer : retour arrière ou remise en conformité des
>>> configurations. Combien sont capables de faire tout ça à la fois ?
>>>
>>> Nous vous proposons d'assister à une présentation de la solution Cisco
>> NSO
>>> (Network Services Orchestrator). NSO est une plateforme de développement
>>> agnostique au constructeur disposant de nombreuses API Nord (REST,
>>> NETCONF...) et Sud (RESTCONF, NETCONF, SSH...). Nous verrons qu'il est
>>> capable de créer, mettre à jour, supprimer et réparer un service ; mais
>>> qu'il est aussi capable de gérer des équipements de plusieurs domaines
>> (IP,
>>> Optique) et de plus de 100 OS différents !
>>>
>>> Si assister à cette présentation en ligne vous intéresse, faites-moi un
>>> mail avec vos coordonnées.
>>>
>>> Bonne journée
>>>
>>> Clément THERY
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>
>> --
>> Cordialement, Rémi Desgrange
>>
>> ---
>> 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/

[MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent

[JCLB]

DNS64 / NAT64 est déjà une réalité sur la plupart des smartphones récents chez 
les opérateurs en dehors de Free.
Les utilisateurs subissent donc un NAT PAT stateful.

Il faut toutefois relativiser, auparavant 100% de la data mobile subissait du 
NAT PAT 44.
Aujourd'hui le trafic IPv6 natif sort en direct, et on peut supposer que 20 à 
30% du trafic échappe donc à NAT64.

Sur le fixe les mécanismes sont stateless avec des approches Adress+Port (4rd, 
MAP T/E,...)

Au besoin la précédence des OS se configure si on a besoin de conserver la 
priorité IPv4 et d'outrepasser la RFC 6724.
Voir ici pour Windows http://support.microsoft.com/kb/929852
Et pour Linux GetAddressInfo /etc/gai.conf

Attention, certaines applications comme les navigateurs implémentent leur 
propre priorisation de v6 sur v4, indépendante de la configuration du stack de 
l’OS. De plus l’implémentation du mécanisme Happy eyeballs 2 (RFC 8305) peut 
également varier. (Délai entre les requête DNS A et , temps d’attente du 
retour, délai de timeout du socket distant avec bascule…)

Jean-Charles BISECCO


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Daniel 
Caillibaud
Envoyé : lundi 1 février 2021 12:33
À : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent

Le 29/01/21 à 22h29, Laurent Barme <5...@barme.fr> a écrit :
> Ce n'est par le client qui est en cause.

Je parlais du client réseau, au sens client / serveur…

> Aujourd'hui je constate que c'est déjà l'IPv6 qui est prioritaire, 
> demain j'anticipe que ce sera, parfois d'abord et toujours ensuite, la 
> seule disponible par défaut... et là, il faudra bien y passer.

Je pense que ce sera peut-être après-demain, et je serai sûrement à la retraite 
avant ;-)

Ce qui risque d'arriver un peu plus tôt, c'est des client "only v6" qui devront 
passer par une translation v6-v4 qui va devenir plus pénalisante qu'aujourd'hui 
(parce que des acteurs qui peuvent l'imposer l'auront décidé), et qu'on devra 
s'y mettre pour éviter de trop détériorer leur accès, mais même ça je pense que 
c'est pas pour tout de suite, on a le temps de changer de génération d'infra 
plusieurs fois avant.

--
Daniel

Si le temps vous semble long, prenez-le dans le sens de la largeur.
Grégoire Lacroix


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] RE: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent

[JCLB]

Bien sûr, je cite celui qui est probablement le plus répandu.
Mais le stateful n'en est pas pour autant nécessaire.

Ce qui obligatoire c'est soit d'avoir un mécanisme de traversée de NAT comme il 
en existe sur les applications grands public.
Ou en entreprise d'utiliser des Application Layer Gateway (ALG) qui truandent 
le payload à la volée à la condition qu'il ne soit pas chiffré.

Le stateful ou stateless ne joue que sur la consommation d'adresse VS le besoin 
de maintenir une table de session.

Quand 2 sociétés A et B exploitent le même plan d'adressage interne et que A 
doit accéder à des serveurs de B il est facile de faire du stateful comme ça on 
ne se pose plus de question. On peut aussi "publier" les serveurs de B avec des 
IP du plan de A, du masquerading statique.

Dans les 2 cas si le trafic est du SIP il faudra une ALG.

On a l'habitude du stateful en raison de l'accès à internet où on est limité en 
nombre d'IPv4 publiques.

L'ALG reste indépendante de ce choix.

Jean-Charles BISECCO

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Erwan David
Envoyé : vendredi 29 janvier 2021 20:10
À : frnog@frnog.org
Objet : Re: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous 
racontent

Le 29/01/2021 à 18:22, JCLB a écrit :
> Grâce à NAT PT v6, cette entreprise peut changer d'ISP sans rien changer en 
> interne, ça ne casse pas PMTU-D et en dehors du SIP ça ne pose pas vraiment 
> de problème.


Y'a pas que SIP comme protocole qui met des adresses dans la payload :
rsh, ftp, h323 par exemple...

Et tous ces protocoles demanderont que la traduction soit stateful


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent

[JCLB]

La Translation de préfixe ne change que les 1ers bits de l'adresse.
Le port ne change pas et c'est stateless, quand même autre chose que le NAT44 
IPv4

1er cas d'usage
Imaginons une PME, elle se donne un adressage privé IPv6 (équivalent RFC 1918 
IPv4 car elle est trop petite pour demander ses IP au RIPE et faire du BGP, de 
plus elle ne veut pas dépendre du /48 que lui fourni son FAI et tout distribuer 
à coup de DHCPv6-Prefix Delegation car elle veut avoir des assets en fixe.

Grâce à NAT PT v6, cette entreprise peut changer d'ISP sans rien changer en 
interne, ça ne casse pas PMTU-D et en dehors du SIP ça ne pose pas vraiment de 
problème.

2e cas d'usage
La multinationale "Bob a family company" déploie une solution campus 
permettant la sortie vers internet local pour des applications SaaS comme 
Office 365 sans repasser par le datacenter.
La société annonce en BGP un /32 IPv6 depuis ses datacenter.
Ses campus disposent tous d'un accès MPLS vers les DC et d'un accès internet 
local pro.
L'accès internet de chaque campus dispose d'un /48 qui appartient à l'opérateur.

Si un client du campus joint un site web "non sûr" il traverse le MPLS puis le 
proxy datacenter et sort via une IP appartenant à Bob
Si le client se connecte à MS Teams ou autre SaaS, son IP publique interne se 
fait NAT PT vers celle de l'opérateur local du site. Il sort donc avec une 
autre IP publique mais qui est directement routée depuis le site.

Jean-Charles BISECCO

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Stéphane 
Rivière Envoyé : vendredi 29 janvier 2021 18:13 À : frnog@frnog.org Objet : Re: 
[FRnOG] [MISC] Les âneries que les vendeurs nous racontent

>> Mais cette magie existe déjà (rfc6296) et le pire c'est que c'est
> probablement le genre de bazar qui risque d'être utilisé justement 
> dans la catégorie que tu cible :)

Parcouru https://tools.ietf.org/html/rfc6296

D'ailleurs ils appellent ça NPTv6 histoire de pas le nommer NATv6 :)

Selon https://tools.ietf.org/html/rfc6296#section-5 on dirait même que c'est à 
ne pas utiliser sans pince-nez pour l'odeur. Ça semble aller à l'envers de 
l'esprit ipv6 mais je suis un basique en réseau donc je dois pas comprendre 
l'intérêt d'un tel bidule.

Déjà qu'on a réussi à éviter le NAT sur notre infra ipv4 multi-DC, pas question 
que d'en avoir en ipv6.

--
Be Seeing You
Number Six


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Re: Cisco ASR, Arista 7150, OSPF et MTU

[JCLB]

Bonsoir,

Afin d'être plus propre que MTU ignore, il est possible de définir la taille 
max des LSA OSPF avec "packet-size" sur le routeur qui a la plus grosse MTU. 
(commande à ne pas confondre avec celle qui limite la taille de la LSDB, 
max-lsa chez certains...)
MTU ignore ne devrait idéalement servir qu'à débuguer une adjacence qui ne se 
forme pas.

JC Bisecco

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Kevin Thiou
Envoyé : mardi 5 janvier 2021 15:08
À : frnog-tech 
Objet : [FRnOG] [TECH] Re: Cisco ASR, Arista 7150, OSPF et MTU

Pour info, après de l'aide en privé, il manquait la mtu sur l'interface vlan 
des arista.

avec ca :

interface Vlan86
   mtu 9214
   ip address 172.16.70.77/31
   ip ospf network point-to-point
   ip ospf mtu-ignore

c'est bon.

Le mar. 5 janv. 2021 à 13:57, Kevin Thiou  a écrit :

> Bonjour,
>
> toujours dans mes problèmes de collecte sur cisco ASR.
>
> J'essaie de faire en sorte de respecter les stas par exemple pour SFR 
> REFLEX il me faut une MTU à 2000 sur toute la chaîne.
>
> Je collecte sur un Arista 7150, sur lequel la MTU est à 9124.
> Le trafic est envoyé vers mes Cisco ASR (interco 10G entre Arista et 
> CIsco)
>
> J'ai essayé de passer la MTU entre le cisco et le arista à 9124.
>
> Mais OSPF n'est pas content :
>
> *DD MTU is too large*
>
> La solution c'est de faire un *ip ospf ignore mtu*.
> !! Si quelqu'un a une autre solution je suis preneur !!
>
> et là j'ai un autre message d'erreur que je ne comprends pas trop :
>
> adjacency dropped: nbr did not list our router ID, state was: EXCH 
> START
>
>
> Conf Cisco :
> interface TenGigabitEthernet0/2/0
>  mtu 9214
>  no ip address
> interface TenGigabitEthernet0/2/0.86
>  encapsulation dot1Q 86
>  ip address 172.16.70.76 255.255.255.254  ip ospf network 
> point-to-point  no lldp transmit  no lldp receive !
> router ospf 1
>  router-id 2.2.2.2
>  auto-cost reference-bandwidth 1000
>  passive-interface default
>  no passive-interface TenGigabitEthernet0/2/0.86  network 172.16.70.76 
> 0.0.0.1 area 0
>
> Conf arista:
> interface Vlan86
>ip address 172.16.70.77/31
>ip ospf network point-to-point
> !
> router ospf 1
>router-id 1.1.1.1
>auto-cost reference-bandwidth 1000
>passive-interface default
>no passive-interface Vlan86
>network 172.16.70.76/31 area 0.0.0.0
>max-lsa 12000
>graceful-restart
> interface Ethernet39
>switchport trunk allowed vlan 14,86,88,216,221-222
>switchport mode trunk
>ip ospf mtu-ignore
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] OpenVPN / Orange et 4G

[JCLB]

Bonjour,

Les opérateurs mobiles font la même chose que sur le fixe. Ils déploient IPv6 
et cherchent à retirer rapidement IPv4 du réseau interne afin de ne pas tourner 
en dual stack partout.

La technique retenue est logiquement celle du DNS64+NAT64, elle est implémentée 
par Google et Apple depuis plusieurs années dans les OS mobiles.
Lorsqu'une application joint un serveur IPv4 only, le DNS de l'opérateur crée à 
la volée un enregistrement  sous la forme d'un WKP (well known prefixe IPv6 
64:ff9b::/96 + l'IPv4 en hexadécimal).
L'opérateur peut aussi utiliser un Network Specific Prefixe mais il faut alors 
un moyen de le configurer sur les clients, une RFC rend cela possible via PCP 
(le remplaçant de PMP qui fournit uPnP) et c'est donc plutôt destiné aux boxs 
domestiques.

Par exemple si ton serveur est en IP 1.1.1.1, le DNS va retourner un  
64:ff9b::101:101

Un équipement de NAT64 stateful va ensuite mapper ton paquet avec l'IPv4 
correspondante et un port aléatoire. Chez Orange cette fonctionnalité est 
portée par des châssis SLB F5.

Enfin, lorsque la connexion du smartphone est partagée en wifi, IPv4 est 
supporté via du XLAT464. Le téléphone traite donc la partie cliente de la 
double translation (CLAT) pour passer de v4 à v6, puis le NAT64 chez 
l'opérateur le retour à v4 sur internet.

Android fournit également XLAT464 aux applications qui utiliseraient une 
adresse IPv4 en littéral, sans requête DNS donc.
De son côté, Apple étant maitre plus en profondeur des middlewares utilisés, il 
gère de son côté la transformation d'une adresse IPv4 saisie en littéral en une 
IPv6 avec le préfixe WKP. C'est pour cette raison qu'Apple force depuis 2016 
les app à supporter IPv6 au sens code. Les fonctions utilisées doivent 
permettre d'ouvrir un socket en v6 comme en v4.


J'exposais ça ici https://lafibre.info/ipv6/ipv6-iphonex/msg689495/#msg689495

Cette RFC d'aide au déploiement peut aider à la compréhension 
https://www.rfc-editor.org/rfc/rfc8683.html

Le revers est que cette technique force à utiliser le DNS opérateur, à ma 
connaissance il n'est pas encore possible de spécifier soi-même un serveur DNS 
et traiter le DNS64 avec une configuration côté smartphone.

Si vous souhaitez tester l'implémentation sur votre terminal, vous pouvez 
ouvrir une page web TLS avec l'adresse littérale et voir ce qui se passe.

Ouvrez https://1.1.1.1/ , aucun soucis
Ouvrez https://[64:ff9b::101:101]/ vous recevrez une erreur de certificat, sauf 
sous Safari avec IOS13 où les librairies Apple truandent la conversion jusqu'au 
contrôle du certificat, et modifient à la volée les adresses pour assurer la 
compatibilité avec NAT64. Sous IOS14 ça semble avoir disparu.

Une en-tête IPv6 étant plus longue, et IPv6 ne fragmentant que sur les 
extrémités, il en résulte qu'un NAT64 mal configuré produira des paquets IPv6 
trop gros...
Tu indiques que ça marche en partage de connexion, et donc en XLAT464, peux-tu 
vérifier que pour un paquet émis au MTU max sur le laptop, le serveur reçoit 1 
ou 2 paquets avec fragmentation ?

En dehors de ça NAT64 ne pose problème que quand l'application effectue un 
contrôle de l'adresse littérale.
Tu peux créer une conf OpenVPN "WKP" où tu spécifies l'IPv6 WKP générée avec 
l'IPv4 de ton serveur au lieu de son FQDN, ça permet généralement de démonter 
ou non ce genre de comportement de validation littérale.


Jean-Charles BISECCO


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Jérôme 
Quintard
Envoyé : mercredi 30 décembre 2020 01:39
À : Jérôme Quintard 
Cc : frnog-t...@frnog.org
Objet : RE: [FRnOG] [TECH] OpenVPN / Orange et 4G

Bon... on a avancé dans la compréhension du soucis et il n'est pas lié à la 
configuration d'OpenVPN.

Pour faire simple :

Android + 4G orange -> le client OpenVPN obtient pour adresse publique du 
serveur une IPv4 Android + 4G SFR -> IPv4 Apple + 4G SFR -> IPv4 Apple + 4G 
Orange -> IPv6

Pourquoi une IPv6 aucune explication d'autant qu'elle inexistante sur le net... 
Que ce soit OpenVPN, la VM, l'EIP associée c'est IPv4 uniquement...

Côté client forcé la conf en IPv4 n'a aucun effet.

Orange ne trouve, pour le moment, aucune origine ce lien avec les terminaux 
Apple. Dans tous les cas, aucun rapport avec notre conf.

Une idée de votre côté ? Ou une modification de la conf du client pour 
"contourner" ?

Jérôme

De : frnog-requ...@frnog.org  de la part de Jérôme 
Quintard  Envoyé : mardi 22 décembre 2020 14:44 À : 
Baptiste Chappe ; Benoît Grangé 
 Cc : frnog-t...@frnog.org  
Objet : RE: [FRnOG] [TECH] OpenVPN / Orange et 4G

Bah non MTU changé rien y fait. Une autre idée ??

De : Baptiste Chappe  Envoyé : lundi 21 décembre 
2020 15:05 À : Benoît Grangé  Cc : Jérôme Quintard 
; frnog-t...@frnog.org  Objet : 
Re: [FRnOG] [TECH] OpenVPN / Orange et 4G

Hello,

Je pense aussi à un sujet de MTU Je ne compte plus les réseaux 
"présta/marketing" et les services de TPE 

RE: [FRnOG] [TECH] CISCO REP vs LACP

[JCLB]

Bonjour Fabien,

REP est conçu principalement pour le ferroviaire, il permet de faire une boucle 
pour connecter la signalisation, la téléphonie d'urgence, les panneaux 
d'attente etc. On retrouve cette technologie et ses concurrentes de loop L2 sur 
la plupart des lignes de métro avec une double boucle optique.
On le voit aussi sur des boucles de pylônes radio. Pour ces 2 cas d'usage on 
trouve aussi souvent la présence de PTP, qui n'a rien à voir avec REP mais est 
souvent demandé par la signalisation en ferroviaire comme en radio.


Le stretch L2 pose beaucoup de problèmes, effectivement en PCA/PRA on veut 
pouvoir tout migrer sans réadresser et sans basculer les subnets de façon 
binaire. Parfois on veut même cette flexibilité en prod tout court pour faire 
du VMotion inter-site par exemple.
Les technos de fabric type TRILL / SPB comme FabricPath ont permis de faire du 
stretch doit disant scalable, en vérité les incidents sont fréquents et 
fortement impactant.

On en vient à VxLAN + EVPN où l'usage de MAC-VRF permet d'étendre des réseaux 
proprement, sans avoir les risques de la génération précédente de fabric.
Bien sûr quelqu'un de plus orienté WAN peut aussi faire du L2 en MPLS EVPN ou 
PBB s'il a besoin de peu de ports.

Pendant longtemps on a cru que la résilience était l'affaire du réseau, si on 
regarde ce qu'on fait maintenant sur les architectures applicatives modernes à 
base de conteneur notamment, on se fou de l'IP et on cherche à remonter la 
résilience dans l'application. Et pas sur un load balancer couplé à des VLAN 
étendus avec FW qui synchronisent les sessions etc...

Reste qu'il faut bien pouvoir gérer les applications existantes qui ont besoin 
de ce modèle vieillissant, qu'on nomme le "METRO DATACENTER" et qui a fortement 
percé au début de la dernière décennie en faisant tout synchroniser entre 2 
sites (SAN, SGBD, ...)

Si tu peux fais du VxLAN, si ton réseau est important utilise des équipements 
dédiés hors fabric pour porter les HA des FW.
Enfin, incite les équipes système à gérer la redondance dans l'app, et à 
utiliser un 3e site comme quorum de vote pour les SGBD et autres clusters (ça 
évite le split brain et sauve des grains de café)

Jean-Charles BISECCO


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Michel Py
Envoyé : samedi 21 novembre 2020 20:25
À : 'Fabien H' 
Cc : Liste FRnoG 
Objet : RE: [FRnOG] [TECH] CISCO REP vs LACP

> Fabien H
> Certes. (Bon sur un ASA, quand le L2 remonte, c'est pas trop grave, ça se 
> passe assez bien).

Sauf quand ton réseau est coupé et devient actif/actif car les deux cotés 
pensent que l'autre coté est mort. Quand çà remonte, tes deux ASA vont 
re-synchroniser, çà va être laid non pas pour les ASA mais pour tout le reste 
de l'infrastructure non seulement va se retrouver avec des sessions TCP qui 
perdent les pédales mais en plus qui a continué a faire des transactions en 
ignorant que l'autre coté faisait pareil.

> Mais du coup ça veut dire qu'on abandonne les archis redondantes de FW ou 
> autres ?

Bien sur que non. La redondance à l'intérieur du même datacenter, même si çà 
coute cher il faut être con pour ne pas le faire. Alim redondantes hot swap, 
disques en RAID, firewalls actif/standby avec heartbeat et synchronisation, 
tout çà c'est nécéssaire. Mais çà reste de la redondance LOCALE; a moins 
d'avoir de la fibre noire en chemin séparé entre les deux cotés, c'est 
fondamentalement pas bon d'étendre le L2 au-delà du campus.

> Ou alors il faut le faire en L3 ?

Non seulement en L3 mais probablement dans les couches plus hautes aussi, 
suivant l'application.

Michel.

 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] IPV6 autoconfiguration stateful

[JCLB]

En effet tu peux écrire à ce cher Lorenzo, responsable de la stack network 
d'Android.

Non content d'avoir travaillé sur SLAAC puis sur rddns, il s'est dit 
"qu'abuser" du monopole de l'OS serait pas mal pour supprimer DHCPv6. Et tant 
pis pour ceux qui veulent tracer les terminaux, ils n'ont qu'à faire du zero 
trust avec un VPN...

En entreprise c'est galère, par exemple si tu veux migrer un wifi guest en dual 
stack pour te faire la main, commencer à tester tes équipements etc. Tu te 
retrouves vite confronter à ce problème.
Si tu as une passerelle "lourde" sur place qui porte le vlan et traque 
directement les NA et DAD ça passe, mais on sait tous que le déploiement 
courant en entreprise c'est plutôt un cluster d'authentification centralisé qui 
gère aussi le guest. Et lui en général il se contente du radius et ensuite fait 
une corrélation avec les logs d'un proxy transparent. Forcément avec SLAAC ou 
tu changes d'IP chaque X minute et où rien hormis les ND te permet de suivre 
ça, c'est perdu.

Et Android va plus loin que les téléphones, tu veux passer des imprimantes 
Lexmark ou des tablettes de réservation de salle de réunion en IPv6 avec une 
réservation DHCP ? L'éditeur l'intègre parfois lui-même comme Lexmark.

Peut-être que les outils de MDM permettront bientôt de tracer un terminal en v6 
à partir du moment où il récupère une IP dans ton /32 par exemple, mais ça ne 
répond pas aux guests qui ne sont pas gérés.

L'idéal serait que les AP Wifi remontent instantanément tout changement de 
Neighbor pour pouvoir continuer à effectuer la corrélation de logs, ou comment 
forcer la télémétrie pour un truc qui fonctionnait très bien sans. Ou encore 
collecter les tables de snooping.

En 2019 quelqu'un posait la question chez aruba 
https://community.arubanetworks.com/community-home/digestviewer/viewthread?MID=26189#bm595048c3-ffc7-4993-9981-374f189676fa

https://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-frustrates-enterprise-network-admins/
https://www.reddit.com/r/ipv6/comments/3wfpn2/i_am_getting_sick_of_lorenzos_attitude_to_ipv6/

4 ans sur reddit, ça semble un combat perdu, comme quand Google annonce depuis 
5 ans qu'ils vont empêcher les surcouches et pousser les MAJ comme n'importe 
quel OS avec les drivers. (il y'a eu le débat ici même pour les certificats 
Let's Encrypt qui ne fonctionneront pas sur Android 7) 

L'immense majorité des opérateurs déploie donc SLAAC sur ses box, sur les 
Freebox il est même indiqué que si tu bascules en DHCPv6, au revoir Android.

Pour résumer, sois corrélation de collecte des logs NDP avec un genre 
d'arpwatch en temps réel, sois pour le testeur du dimanche, l'assignation 
d'IPv6 à l'hôte via... roulement de tambours... le serveur radius lui-même 
https://tools.ietf.org/html/rfc6911#section-2.1


Bref, à l'heure où on nous recommande de logguer les ports et pas seulement les 
IP sur internet grâce aux merveilleux CGN qui font du partage d'IPv4 entre 
abonnées (https://tools.ietf.org/html/rfc6302) d'autres nous empêchent de 
tracer une machine facilement sur nos réseaux corporate


Jean-Charles BISECCO


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Artur
Envoyé : jeudi 12 novembre 2020 22:22
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] IPV6 autoconfiguration stateful

Bonsoir à tous,

Je regarde actuellement dhcpv6 pour définir un adressage prévisible à l'avance 
sur un réseau local et permettre un filtrage qui va avec.
Si ça marche bien entre un serveur Debian/radvd/wide-dhcpv6 et une machine 
Windows10 (pas encore testé avec Linux, mais a priori ça doit marcher tout 
seul), ça ne fonctionne pas du tout avec Android.
En faisant quelques recherches j'ai vu que Google ne veut pas de dhcpv6 sur 
Android 
(https://www.nullzero.co.uk/android-does-not-support-dhcpv6-and-google-wont-fix-that/).

C'est presque vendredi, mais je n'ai pas forcément envie de déclencher une 
polémique sur 350 posts.
La question au-delà de la position de Google, c'est : A votre connaissance, 
quelle solution pour cette autoconfiguration IPv6 stateful sur Android, svp ?
Ou encore, si dhcpv6 n'est pas la solution adaptée, comment pourrait-on mettre 
en place un filtrage "par terminal" Android en IPv6?

Merci par avance.

--
Cordialement,
Artur


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] Re: [TECH] NAT et IP hors RFC-1918

[JCLB]

Bonjour Adrien,

Énormément d'entreprises utilisent le double nat sur la chaine d'accès à 
internet.
Exemple Français: la majorité des banques utilisent des IP publiques d'autrui 
en interne. Certaines uniquement pour les agences / campus, d'autres également 
pour leur DC...

En général la majorité des structures de plus de 100k personnes et avec un 
historique lourd (achats, filiales,...) s'est déjà retrouvée au pied du mur.

Faire du double NAT impose de centraliser la chaine d'accès internet pour 
l'ensemble du groupe ou d'obliger à ce que le design de cette chaine soit 
reproduit à l'identique si des filiales veulent leur propre accès par exemple.

Typiquement, on chaine 2 lots de proxy (interne et externe)
Les 2 lots se voient entre eux via des IP 1918
Le lot interne est exposé aux clients via du privé ou du faux public, pas 
d'importance.
Le lot externe exploite de vrais IP publiques pour aller sur le web (sauf si on 
re nat encore l'exposition externe du proxy, ce qui est rare...), ce lot 
externe n'a aucune route vers le réseau interne, en dehors des proxy internes 
et de réseaux de management et supervision.

Pour exposer des serveurs à l'extérieur, même bricolage, on double NAT (par 
exemple FW en entrée DMZ puis 2nde fois sur des SLB)

Certaines entreprises n'ont pas pris de précautions, et ont dû mettre en œuvre 
ce double chainage un beau jour en urgence.
D'ailleurs quand cloudflare a sorti son 1.1.1.1, certains ont découvert qu'ils 
routaient déjà cette IP en interne, car elle a longtemps été hard codé dans les 
WLC wifi Cisco.

Chez les habitués de ce bricolage, on tape souvent dans les IP du DoD US, sauf 
que celui-ci indique dans divers documents passés au congrès qu'ils veulent 
vendre une bonne partie de leur IP publiques dans la dizaine d'année qui vient. 
En vérité ça ne devrait pas se faire beaucoup plus vite que leur nombreuses 
tentatives de migration vers IPv6.

Nouveau problème aujourd'hui, ces grandes entreprises commencent à devoir 
annoncer de vraies IP publiques dans leur backbone interne (par exemple pour 
faire du MS Teams en UDP via des G-IX, ce qui est plus performant qu'en TCP)
Mais si demain MS utilise une IP qui existe en interne ? ... et MS annonce les 
nouvelles IP et URL Office 365 seulement 4 à 6 semaines à l'avance.
Idéalement les adeptes du "bricolage double nat" vont donc devoir lancer un 
script chaque semaine pour vérifier qu'aucune de leur fausse IP publique n'est 
nouvellement affectée dans le monde réel à l'AS de leur provider préféré (MS, 
Amazon, ...) histoire de déclencher l'alerte tsunami à temps (oxymore power)

Et notre ami l'UDP qui force la main pour teams, il arrive à grands pas grâce à 
QUIC, dans quelque temps on interrogera plein d'API publiques ou de ressources 
cloud via QUIC, et bien sûr on naviguera avec, les équipes pare-feu et backbone 
vont alors pouvoir partager l'apéro avec les équipes proxy...
Quic a bien un connection ID, mais il sert à la mobilité et n'est pas visible 
des middlebox... 

Ha, et si tu comptes faire du split tunneling avec le VPN, il faut veiller à 
surveiller le non-recouvrement de la même façon que pour les vraies routes 
publiques apprises en backbone. (pour du SaaS en général)

Une raison plus de s'intéresser à IPv6 dans les grosses structures, sauf si on 
veut garder un réseau qui ressemble à un film de Christopher Nolan.

Concernant le NAT-DNS dont tu parles, il est utile pour exposer un serveur 
d'une entité A à une entité B avec de l'overlapp. Le principal intérêt étant 
que certaines solutions (F5, Palo,..) permettent de tout gérer sur la même 
appliance de façon consistante, car toute la "truanderie" nat et dns hérite de 
la même règle sur la même boite, et qu'il n'y a donc pas besoin de demander à 
l'administrateur DNS et aux équipes FW etc de se synchroniser.
C'est extrêmement utilisé, notamment quand les structures A et B n'ont plus 
trop de comptes à se rendre, mais que la force des choses les oblige à 
collaborer. Ce mode limite fortement les interactions nécessaires et le nombre 
de gestes à droite et gauche.
Reste un cas qui pose problème, le SIP. Il y'a bien des ALG pour natter aussi 
l'intérieur de la signalisation SIP, mais bon...

On va vers un monde où on aura de meilleures performances à la maison (IPv6 + 
QUIC) qu'au bureau (NAT + TCP) pour tout ce qui est web, que ça soit 
application, appels API,... Une sorte d'apartheid protocolaire que certains 
utilisateurs de Saas et leur direction ont déjà noté grâce au confinement.

Jean-Charles Bisecco

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[JCLB]

Bonjour,

Page 57 Jordi parle des mécanismes de transition, ça n'est pas vraiment pour 
remplacer le NAT.

Dans un premier temps pour déployer du v6, on utilisait généralement des 
tunnels Maintenant ça se répand pour économiser des v4 en les partageant, y 
compris sur des abonnées fixes, via d'autres mécanismes plus performants.

Free a inversé son 6rd en 4rd pour partager les IPv4 entre 4 abonnés Le MAP T 
ou E est étudié par Bouygues pour son réseau fixe grand public SFR semble faire 
du NAT444 avec la box (1re fois le NAT de RFC1918 comme partout, seconde fois 
avec le préfixe 100.64/10 RFC6598 et un Carrier Grade NAT centralisé)

Un opérateur mobile faisait déjà du NAT44 en central, il fait maintenant du 
NAT64 avec les mêmes équipements et NAT finalement moins de sessions qu'avant 
vu que certaines s'établissent dès lors en IPv6 (coucou Orange et Bouygues)

Android fait du XLAT464 dans l'OS, l'iPhone le propose en tethering ainsi que 
dans la gestion des URL dans webkit afin d'éviter de casser des URL IPv4 en 
dur, de mêmes webkit sait valider un certificat TLS avec une IPv4 au travers de 
NAT64 (inutile en temps normal puisqu’on utilise le nom de domaine) Reste le 
problème de DNSEC, et le futur proche problème de DoH (un Firefox Android qui 
ferait du DoH casserait le DNS64 nécessaire au NAT64)
https://lafibre.info/ipv6/ipv6-iphonex/msg689355/#msg689355

Tout cela est de la salade interne d'ISP pour économiser les IPv4 d'une part, 
et éviter le surcout du dual stack de bout en bout.
Mais in fine on arrive à des cas où v6 est natif et v4 non, preuve de la 
considérable avancée du sujet.


Pour en revenir au sujet du NAT, un client lamba particulier a besoin qu'un 
logiciel puisse s'ouvrir un port si besoin sans intervention manuelle (skype, 
torrent, jeu en ligne,...) On le fait avec de l'UPnP et sa partie NAT-PMP, PCP 
le remplace et supporte l'ouverture de port IPv6. Cette dernière n'est plus un 
port forward, mais une véritable ACL dynamique

Bien évidemment on doit avoir des routeurs domestiques qui bloquent par défaut 
le trafic entrant en dehors des besoins UPnP et de certains messages ICMP.
Là-dessus, mention spéciale à Free, qui a mis 10 années à implémenter un FW 
dans la feebox ! Et ne permet toujours pas d'ouvrir un port en IPv6  -_- La 
livebox le permet, mais l'implémentation actuelle est boguée. 
https://lafibre.info/orange-internet/firewall-ipv6-livebox/

La seule translation utile en IPv6, c'est NPTv6, pour changer le préfixe à la 
volée Typiquement changer le /56 attribué par son opérateur sur un petit site, 
car on ne veut pas tout reparamétrer si on change d'opérateur, où parce qu'on 
utilise l'adressage privé IPv6 en interne et non du global.
Ou encore, pour une grande entreprise, avec son propre préfixe, permettre à la 
solution SD-WAN ou autre d'utiliser le préfixe de l'opérateur pour faire du 
Local BreakOut vers internet histoire d'aller plus vite vers son CRM ou sa 
suite bureautique préférée en SaaS.


Un problème majeur d'IPv6 pour les particuliers et les PME, est qu'il n'est pas 
facile de reproduire la configuration manuelle IPv4 dans le LAN pour un 
serveur, une imprimante...
"récupère le préfixe opérateur dynamiquement, mais ensuite assigne le reste de 
ton IPv6 avec ces bits que j'ai choisis sur la portion 65 à 128e bit"

Au mieux on peut faire du DHCP, mais Android ne le gère pas, on peut aussi 
utiliser l'adresse EUI-64 à partir de la mac en désactivant les privacy 
extension, mais si on change de carte bah...
On peut enfin utiliser du privé pour le lan et laisser de l'assignation 
automatique pour sortir vers internet, mais ça représente plus de travail et 
peut être source de comportement indésirable notamment avec DNS...

L'idéal serait donc un jour que chaque entreprise puisse annoncer son propre 
/48 de site directement vers l'opérateur et internet, et donc de faire du 
peering.
Utopiste, mais qui sait...

JC Bisecco


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Michel Py 
Envoyé : lundi 11 mai 2020 03:53 À : 'Pierre Emeriaud'  Cc 
: frnog@frnog.org Objet : RE: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: 
Message important concernant les élections du RIPE

Je fais d'une Pierre deux coups :P ou de deux Pierres un coup :P

> Pierre Lagoutte a écrit :
> Hallucinant... On en est à discuter du réalisme d'une proposition  
> "d'extension" et "rétrocompatible"
> pourquoi a-t-on oublié le sens des mots ??? une "extension" n'est 
> JAMAIS rétrocompatible, sauf si elle a été prévue comme telle à la 
> conception, auquel cas, ce n'est pas une "extension", c'est un "phasage".

Exactement, mais c'est trop tard pour en parler. Mea culpa, il y a 20 ans 
j'avais pas vu çà.

> Nous sommes en train de discuter d'un franc délire:
> - OUI, IPv6 est une catastrophe
> - OUI nous avons besoin d'une évolution de l'ARCHITECTURE de 
> l'internet réellement COMPATIBLE
> IPv4 (au moins au niveau des installations terminales; même s'il faut 
> sacrifier des 

[FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[JCLB]

Il y'a des tentatives plus ou moins amusantes pour essayer d'échapper à 
l'inéluctable manque d'espace IPv4.

Ma préférée est l'EzIP 
https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03
On sent que le rédacteur y a mis son énergie... sans se préoccuper une seconde 
de sujets de couche 1 comme l'optimisation des ASICs pour router, quand on voit 
ce qu'il a été nécessaire de faire pour supporter VxLAN/Geneve il est facile 
d'imaginer la charge.

Par le passé il y'a eu la proposition d'utiliser la classe E IPv4 pour gagner 
du temps, 240.0.0.0/4
Ça serait le truc le plus plausible techniquement, et bien rien que ça les 
constructeurs ne sont pas chauds.
Ces mêmes constructeurs qui feraient bien de travailler à implémenter la 
rfc5838 permettant d'annoncer de l'IPv4 address family dans OSPFv3.

Ce monsieur dit "si je suis élu j'offrirais des masques, euh des IP 
gratuitement" c'est un ancien taxi ? il croit que la licence est payante, car 
les gars se la revendent entre eux ?

Je vais voir dès lundi pour faire participer au vote mon entreprise, après tout 
avec une cinquantaine de /16 il serait dommage de ne pas s'exprimer.


IP est mort, vive IP !

JC Bisecco


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Christophe 
PLESSIS
Envoyé : vendredi 8 mai 2020 15:41
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les 
élections du RIPE

 Bonjour,
Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel est 
votre avis ?
A bon entendeur.
Christophe

De : Elad Cohen 
Envoyé : vendredi 8 mai 2020 00:06
À : contact 
Objet : Message important concernant les élections du RIPE

Bonjour,

Je m'appelle Elad Cohen et je suis candidat au conseil d'administration du RIPE 
lors des prochaines élections, qui auront lieu le 13 de ce mois.

J'ai créé une solution technique avec laquelle il y aura plus de 4 294 967 296 
adresses IPv4 pour les 5 registres Internet régionaux, y compris le RIPE, vous 
pouvez en savoir plus à ce sujet ici :
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html

Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre RIPE 
recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu. Personne 
d'autre ne mettra en œuvre ma solution technique, je vous demande votre vote en 
ligne. Sans votre vote en ligne à la prochaine assemblée générale du RIPE, ma 
solution technique ci-dessus ne sera pas mise en œuvre.

Veuillez vous inscrire au vote en ligne pour les élections du RIPE en utilisant 
le lien suivant :
https://www.ripe.net/s/gm-registration-may-2020

Si vous rencontrez un problème pour vous inscrire au vote en ligne, veuillez 
envoyer un courrier électronique à a...@ripe.net

---

Outre la solution technique susmentionnée au problème de « l'épuisement de 
l'IPv4 », il existe deux autres solutions techniques que je m'efforcerai de 
mettre en œuvre si j'ai l'honneur d'être élu :


Une solution technique au problème mondial du spam par courrier électronique :
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html

Une solution technique au problème mondial de l'amplification de l'usurpation 
du DDoS :
https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html

---

Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE devienne :

- Une organisation 100% transparente.

- Une organisation centrée sur le LIR (il y aura un ANS de 24 heures pour 
chaque demande d'assistance, après quoi le membre du RIPE pourra évaluer la 
qualité du service reçu et marquer si la demande d'assistance a été résolue ou 
non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra 
automatiquement la demande d'assistance). Chaque aspect du RIPE changera pour 
être centré sur le LIR et non sur la bureaucratie.

Une organisation efficace en termes de dépenses de RIPE, je veillerai 
personnellement sur chaque dépense de RIPE afin de m'assurer que la RIPE soit 
une organisation efficace. Lorsque RIPE soit devenue une organisation efficace, 
les cotisations annuelles des membres de RIPE seront considérablement réduites.

Je vous demande de vous inscrire pour le vote en ligne en utilisant le lien 
suivant :
https://www.ripe.net/s/gm-registration-may-2020

---

Le RIPE est géré par des personnes qui ne se soucient pas de vos intérêts, vous 
pouvez en voir l'exemple à travers les deux liens suivants :

https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html

Dans ce lien ci-dessus, l'actuelle présidente du conseil d'administration du 
RIPE, Maria Hall, candidate à sa réélection, a soutenu la nomination de 
l'actuel président du conseil d'administration du RIPE, Christian Kaufmann, 
candidat lui aussi à sa réélection. Dans sa « Raison de la nomination du 
candidat : » vous pouvez voir que la ligne « Raison de la nomination du 
candidat: » apparaît deux fois. Il y a une deuxième