Auteur Sujet: Mars 2020 à Octobre 2021: Free coupe le peering IPv6 avec Hurricane Electric (Lu 79577 fois)

vivien · « **Réponse #96 le:** 09 avril 2020 à 15:50:25 »

Citation de: alarig le 09 avril 2020 à 14:18:38

Je ne connais pas par cœur le réseau de Free, mais j’ose espérer que s’il y avait un peering en IPv6 sur le LINX, il y en avait aussi en IPv4.

Pour une raison que j’ignore Free a déjà fait des séparations avec il y a quelques années, des PNI Google dédiés IPv6 et d'autres dédiés IPv4.

Je n'ai jamais trop compris cette volonté de faire des chemins séparés IPv4 / IPv6 que l'on trouvait aussi avec Hurricane Electric avant la coupure.

Oyodo · « **Réponse #97 le:** 09 avril 2020 à 18:48:39 »

Citation de: Hugues le 09 avril 2020 à 15:33:13

Non, le peering était Côte Est :

Je me permet de te répondre en te quotant

Citation de: Hugues le 04 février 2016 à 08:57:27

Voilà :

Code: [Sélectionner]
hugues@Discovery:~$ mtr -rwc10 216.66.84.42 Start: Thu Feb 4 08:56:43 2016 HOST: Discovery Loss% Snt Last Avg Best Wrst StDev 1. AS??? Jupiter.MilkyWay 0.0% 10 0.5 0.5 0.5 0.6 0.0 2. AS12322 cxr69-6-82-230-133-254.fbx.proxad.net 0.0% 10 5.5 5.8 5.4 7.3 0.0 3. AS12322 213.228.21.254 0.0% 10 6.2 6.2 5.9 7.1 0.0 4. AS??? p11-crs16-1-be1118.intf.routers.proxad.net 0.0% 10 19.5 16.6 12.7 19.5 2.2 5. AS12322 th2-9k-1-be1001.intf.routers.proxad.net 0.0% 10 13.2 13.7 12.8 19.5 1.9 6. AS12322 yankee-6k-1-po1.intf.routers.proxad.net 0.0% 10 94.9 95.3 94.8 97.0 0.5 7. AS12322 newyork-6k-1-po2.intf.routers.proxad.net 0.0% 10 126.1 112.0 100.5 186.9 27.5 8. AS12322 paloalto-6k-1-po1.intf.routers.proxad.net 0.0% 10 169.4 217.2 169.4 362.8 73.5 9. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 10. AS6939 10ge7-5.core1.sjc2.he.net 0.0% 10 161.0 163.2 160.9 167.0 2.2 11. AS6939 100ge1-2.core1.nyc4.he.net 0.0% 10 161.1 162.7 157.6 167.6 3.5 12. AS6939 100ge11-1.core1.par2.he.net 0.0% 10 161.2 161.5 157.1 167.0 3.8 13. AS6939 10ge3-1.core1.par1.he.net 10.0% 10 157.2 159.0 157.2 167.8 3.3 14. AS6939 tserv1.par1.he.net 10.0% 10 157.8 157.7 157.2 158.0 0.0

https://lafibre.info/ipv6/utiliser-tunnelbroker-par-defaut-linux/msg303563/#msg303563

C'est ce que j'avais il y a encore quelques semaines.

aplufr · « **Réponse #98 le:** 15 avril 2020 à 10:08:22 »

Citation de: vivien le 06 avril 2020 à 17:12:42

Non, tu peut sélectionner un autre serveur miroir, mais si le serveur par défaut ne fonctionne plus, pas de solution, sauf a demander au projet Debian de sélectionner un autre serveur que celui de Free par défaut. Là le serveur fonctionne bien, il y a juste pas de connectivité vers HE en IPv6

Sur une nouvelle installation de Debian, peut importe le pays choisi le serveur par défaut est deb.debian.org.
Ensuite ça utilise le DNS pour rediriger vers un serveur, actuellement tout par chez Fastly, c’est expliqué là : http://deb.debian.org/.
Par contre ça ne change pas les anciennes configurations…

vivien · « **Réponse #99 le:** 15 avril 2020 à 17:09:58 »

Effectivement, voici l'installation de Debian 10.3 : Lors de l'installation, il demande toujours le pays pour sélectionner le miroir le plus proche :

Mais ensuite deb.debian.org est sélectionne par défaut et non ftp.fr.debian.org :

J'ai séparé le hors-sujet sur le peering avec Fastly, l'hébergeur de deb.debian.org, dans un nouveau sujet : AS54113 Fastly: pourquoi si peu de peering en France ?

vivien · « **Réponse #100 le:** 15 avril 2020 à 18:29:50 »

Voici l'installation de Debian 9 : Lors de l'installation, c'est bien Free qui est recommandé comme miroir :

deb.debian.org est proposé mais c'est ftp.fr.debian.org qui est recommandé :

Voici le fichier source.list en suivant l'installation par défaut :

Code: [Sélectionner]

# 

# deb cdrom:[Debian GNU/Linux 9.0.0 _Stretch_ - Official amd64 DVD Binary-1 20170617-13:08]/ stretch main

deb cdrom:[Debian GNU/Linux 9.0.0 _Stretch_ - Official amd64 DVD Binary-1 20170617-13:08]/ stretch main

deb http://ftp.fr.debian.org/debian/ stretch main
deb-src http://ftp.fr.debian.org/debian/ stretch main

deb http://security.debian.org/debian-security stretch/updates main
deb-src http://security.debian.org/debian-security stretch/updates main

# stretch-updates, previously known as 'volatile'
deb http://ftp.fr.debian.org/debian/ stretch-updates main
deb-src http://ftp.fr.debian.org/debian/ stretch-updates main

dash · « **Réponse #101 le:** 30 novembre 2020 à 17:20:42 »

Citation de: Optix le 09 avril 2020 à 14:42:29

Quelle est la position de l'ARCEP là dessus ?

Citation de: FloBaoti le 09 avril 2020 à 14:45:39

Ils analysent la situation et regardent ce qu'ils peuvent faire.

Le sujet date et l' ARCEP n'a toujours pas analysé et agit. Pauvre French Tech ...

vivien · « **Réponse #102 le:** 30 novembre 2020 à 20:56:12 »

L'Arcep ne fait pas ce quelle veut et sur chaque sujet, il faut trouver une base juridique.

Depuis 2016, le législateur européen protège la neutralité du net, en reconnaissant dans son règlement sur l’internet ouvert :

- Le droit des utilisateurs « d’accéder aux informations et aux contenus et de les diffuser, d’utiliser et de fournir des applications et des services et d’utiliser les équipements terminaux de leur choix, quel que soit le lieu où se trouve l’utilisateur final ou le fournisseur, et quels que soient le lieu, l’origine ou la destination de l’information, du contenu, de l’application ou du service, par l’intermédiaire de leur service d’accès à l’internet » .

- Le devoir des fournisseurs d’accès internet de traiter « tout le trafic de façon égale et sans discrimination, restriction ou interférence, quels que soient l’expéditeur et le destinataire, les contenus consultés ou diffusés, les applications ou les services utilisés ou fournis ou les équipements terminaux utilisés ».

En France, c'est l'Arcep qui est chargée de sa mise en œuvre, et veille à son respect par les FAI.

Source: Arcep

Si un opérateur bloque l'utilisation d'un port TCP, l'Arcep n'a pas besoin d'une plainte, et va demander à l'opérateur de corriger la situation. Ce dernier y est contraint, car l'Arcep a un pouvoir de sanction si la situation n'est pas corrigée dans un délai raisonnable.

La difficulté ici est de faire rentrer la coupure du peering avec Hurricane Electric dans ce cadre juridique: Cela semble plus relever de l'interconnexion que de la neutralité.

Sur l'interconnexion, l'Arcep a des compétences pour surveiller ce qui se passe :
- Décision n°2012-0366 de l’Autorité de régulation des communications électroniques et des postes en date du 29 mars 2012 relative à la mise en place d’une collecte d’informations sur les conditions techniques et tarifaires de l’interconnexion et de l’acheminement de données
- Décision no2014-0433-RDPI de l’Autorité de régulation des communications électroniques et des postes en date du 8 avril 2014 modifiant la décision n°2012-0366 relative à la mise en place d’une collecte d’informations sur les conditions techniques et tarifaires de l’interconnexion et de l’acheminement de données

Cela a pour but de pouvoir répondre à des règlements des différends sur l'interconnexion.

Pour prendre un exemple récent de règlement de différend, l'Arcep à récemment imposé à SFR de baisser le prix de gros du FTTH, on en parle dans le sujet SFR : Hausse des prix de gros de la fibre. L'Arcep a demander à SFR de baisser le tarif de location de ligne de 16,40 € HT/mois/ligne à savoir 13,20 € HT/mois/ligne (SFR FTTH conservant néanmoins la possibilité d’ajuster ce tarif au titre et dans la limite de l’indexation pour l’année courante). Cette demande fait suite à un règlement de différend lancé par Bouygues Telecom.

Pour mener à bien ses missions, le régulateur postal dispose d’un pouvoir de règlement des différends entre opérateurs postaux et de pouvoirs d’enquête assortis d’une panoplie graduée de sanctions pouvant être appliquées à des opérateurs qui ne respecteraient pas le cadre de fonctionnement du marché des activités postales.
Le règlement des différends

La loi prévoit deux types de litiges :

- les différends nés dans le cadre de la conclusion ou de l’exécution des contrats dérogeant aux conditions du service universel (contrats sur les envois en nombre passés par exemple avec des grands émetteurs, des routeurs) ;

- les litiges relatifs aux conventions d’accès aux moyens indispensables à l’exercice des activités postales, détenus par La Poste (service de distribution dans les boîtes postales installées dans les bureaux de poste, répertoire des codes postaux, informations collectées par La Poste sur les changements d’adresse du destinataire, service de réexpédition en cas de changement d’adresse)
Source : Arcep

FloBaoti · « **Réponse #103 le:** 30 novembre 2020 à 21:17:18 »

Les clients ne peuvent pas saisir l'arcep à ce sujet ? Si oui, des procédures/aides sont prévues ?
Le problème est qu'il faudrait trouver une ressource réelle, ipv6 only qui n'est pas joignable depuis free, pour pouvoir se plaindre...

underground78 · « **Réponse #104 le:** 30 novembre 2020 à 21:27:52 »

C'est le cas de dash à priori : https://lafibre.info/free-espace-technique/asn-ipv6-non-joignable/.

FloBaoti · « **Réponse #105 le:** 30 novembre 2020 à 22:01:05 »

Oui mais ça c'est difficilement défendable devant l'arcep.. . C'est facile de mettre un réseau derrière HE uniquement mais s'il ne sert à rien derrière, tu ne peux pas dire à l'arcep : je n'arrive pas à accéder à ce réseau qui ne contient rien.

underground78 · « **Réponse #106 le:** 01 décembre 2020 à 08:05:42 »

Citation de: vivien le 30 novembre 2020 à 20:56:12

La difficulté ici est de faire rentrer la coupure du peering avec Hurricane Electric dans ce cadre juridique: Cela semble plus relever de l'interconnexion que de la neutralité.

Hmm, là on parle d'une coupure totale, il me semble que ça impacte la capacité des abonnés à utiliser les services de leur choix.

Optix · « **Réponse #107 le:** 01 décembre 2020 à 08:14:43 »

Vivien a donné tous les outils pour pouvoir régler ce problème, aux gens de s'en saisir à présent.