Deutsch   English   Français   Italiano  
<6506c4ac$0$7473$426a74cc@news.free.fr>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!cleanfeed3-b.proxad.net!nnrp2-1.free.fr!not-for-mail
Newsgroups: fr.comp.reseaux.ip
From: JKB <JKB@hilbert.invalid>
Subject: Re: Souci IPv6
References: <64fae9bf$0$7527$426a74cc@news.free.fr>
 <6506af99$0$6460$426a74cc@news.free.fr>
Reply-To: <jkb@invalid>
User-Agent: slrn/1.0.3 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Date: 17 Sep 2023 09:19:40 GMT
Lines: 119
Message-ID: <6506c4ac$0$7473$426a74cc@news.free.fr>
Organization: Guest of ProXad - France
NNTP-Posting-Date: 17 Sep 2023 11:19:40 CEST
NNTP-Posting-Host: 188.231.16.145
X-Trace: 1694942380 news-1.free.fr 7473 188.231.16.145:9572
X-Complaints-To: abuse@proxad.net
Bytes: 6527

Le 17-09-2023, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
> Bonjour,
>
> Le 08/09/2023 à 11:30, JKB a écrit :
>> 
>> 	Je viens de changer de FAI après une série de déboires dus au rachat
>> 	de Nerim par Keyyo.
>
> Lequel, si ce n'est pas indiscret, car je commence aussi à me poser la 
> question.

	Le_s_quels_s_.

	Liste non exhaustive :
	- coupure de mon compte partenaire en quatre (l'un pour les accès
	  avec TVA, l'autre pour les accès sans TVA, le troisième pour la
	  téléphonie et le quatrième à la suite d'une erreur interne).
	  Problème : j'avais donc quatre numéros de client et je ne
	  recevais que les factures pour un seul. Comme ces types ont
	  extirpé des archives Nerim un compte d'une entreprise _fermée
	  depuis 1996_ mais que je gardais ouvert en raison d'une erreur de
	  ma banque (un NNE), je virais sur ce compte le montant des
	  factures qui ne correspondait _jamais_ à ce qui était prélevé ;
	- liens résiliés par erreur (parce que sur le lot, j'ai eu deux
	  liens payés durant six mois par des tiers). Le premier ne s'en est
	  pas rendu compte, le second a demandé une résiliation que personne
	  n'a voulu arrêter. J'ai donc perdu au passage l'IPv6 parce que si
	  Nerim fournissait l'IPv6, Keyyo s'en tamponne ;
	- techniquement : depuis le rachat, je n'ai eu que des merdes. La
	  téléphonie échouait en appel entrant à peu près une fois sur dix.
	  Les dégroupages (dans mon cas, FT et Nerim) sont passés sur du
	  Bouygues sans me demander mon accord. J'ai eu des instabilités
	  délirantes en ADSL (Paris intra-muros) mais je devais être content
	  puisque le débit est passé en IP de 18 à 19 Mbps (sic le service
	  technique !). À l'autre bout de la France, je suis passé de 9 Mbps
	  à 3,5 Mbps à la suite d'un dégroupage sauvage de FT à Bouygues. Et
	  encore, avec des problèmes de pertes de paquets (20% en moyenne).

	J'ai résilié tous les accès le 30 juin dernier par courrier
	recommandé (rupture unilatérale des contrats par manque de leur
	obligation de moyens, il y a un article du code civil). Ils n'en ont
	rien eu à faire et j'ai eu des nouvelles du service recouvrement (le seul
	truc qui fonctionne à peu près chez eux). Parmi ce qu'ils me
	demandaient figuraient des factures des trois autres numéros de
	clients que je leur ai demandé par LRAR depuis mars 2023 sans
	obtenir de réponse. Eh oui, parce que malgré mes relances, je n'ai
	_jamais_ eu ces factures.
	
	Chose exceptionnelle, le recouvrement s'adressait à ma société
	actuelle (alors que les factures émises l'étaient à une autre société,
	fermée depuis 7 ans). J'ai donc appelé le N°2 de la boîte pour lui
	demander s'il par hasard Keyyo ne me prendrait pas pour une bille.
	Je lui ai indiqué qu'on était assez proche de ce qu'on pourrait
	appeler en étant malveillant une fausse facture (puisque le tiers
	mis en demeure n'était pas le destinataire des factures et que seul
	le fisc a ce pouvoir en France).

	J'ai eu un retour écrit comme quoi le recouvrement a été annulé et le
	compte soldé.

	Bref, depuis la disparition de Nerim, techniquement, tout est la
	ramasse (dans mon cas), le service s'est dégradé (puisque le service
	technique est ouvert de 9h00 à 18h00 du lundi au vendredi contre
	24h/24 chez Nerim même pour l'ADSL de base) tant techniquement que
	commercialement.

	Les emmerdes ont commencées trois mois après le rachat. J'ai mis du
	temps à les quitter parce que j'avais une infra complète et que ça
	m'obligeait à tout revoir (y compris déménager une salle serveur).

	Je dois rajouter que parmi tous les dinosaures Nerim, je fus l'un
	des derniers à quitter le navire.

>> 	J'ai donc utilisé un sous-réseau en /64 (et non/56) côté passerelle.
>> 	Les autres /64 sont utilisés côté DMZ/LAN.
>
> Toujours utiliser des /64, c'est la seule taille qui marche avec 
> l'autoconf. Avec une route reject/unreachable pour le préfixe complet 
> afin de ne pas créer de boucle de routage.

	La question est de savoir comment on met en place cette route sous
	NetBSD. Je n'ai pas trouvé dans la doc.

>> 	Dans le fichier /etc/network/interfaces, j'ai une déclaration IPv6
>> 	statique :
>> 
>> iface wan0 inet6 static
>>          address PREFIX:a00::2
>>          netmask 64
>
> Note : la notation moderne "address PREFIX:a00::2/64" est supportée.
>
>> 	Mais les machines du LAN n'ont pas d'accès. Si je lance un ping sur
>> 	par exemple www.google.fr, je vois passer côté WAN de la machine
>> 	NetBSD les paquets à destination de www.google.fr. Mais aucun
>> 	retour.
>> 
>> 	Je suppose que le problème est que j'ai un /64 sur le WAN du NetBSD
>> 	et un /56 côté passerelle du FAI (ce qui est corrigé côté Linux par
>> 	le réseau /56 en unreachable). Comment corriger ce problème ?
>
> J'arrive après la bataille, mais faire une capture de trafic côté WAN 
> pour vérifier s'il y a des requêtes ICMPv6 "Neighbor Solicitation" 
> (équivalentes des requêtes ARP) pour les adresses IPv6 du LAN. Dans ce 
> cas le routeur amont est mal configuré, il devrait router le préfixe du 
> LAN via l'adresse WAN du NetBSD.
>
> Contournement possible (hack) : mettre en place un proxy-ND sur le 
> NetBSD qui va répondre à la place des machines du LAN. Ou bien faire du 
> NAT IPv6, mais si c'est pour en arriver là, on se demande à quoi l'IPv6 
> a servi...

	Le problème a été résolu, c'était un souci côté fournisseur d'accès.

	JKB

-- 
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.