prochaine action

• passer *plus* de machines et service en ipv6 pure
  • refaire un joli script xen, compatible ipv6 pure
• résoudre le soucis de parefeu
• revoir l'archi du script de parefeu

• voir le reverse ipv6 avec la sonatel : mail envoyé, mais... (faites un dig ns 8.7.2.4.1.0.0.2.ip6.arpa, pour voir)

• faire des stats d'usage des services ipv6 (%ipv4/ipv6)
• passer le réseau bacàsable en ipv6 pure
• créer un shell6.sn.auf.org sur bas2 en ipv6 pure pour les collègues qui tentent l'experience de leur côté (pour avoir une base de test extérieure à leur réseau)
• squid / proxy transparent en ipv6 ?
• ndpmon ?

Configuration sur fw.refer.sn

• radvd vers eth1 (dmz) et eth4 (bacasable)
  • étape suivante : eth4 en ipv6 *seulement*
• desactivé sur eth2 tant que le problème du conntrack ipv6 n'est pas résolu : les postes doivent être configurés en statique
• configuration filtrage de paquet : à reprendre completement, en intégrant ipv6 à la base
  • baser sur un fichier de configuration pour chaque serveur, listant, de manière optionnelle
    • son ipv4
    • son ipv6
    • services udp
    • services tcp

Serveurs accessibles en ipv6

DNS

tini@bas2:~$ cat /etc/resolv.conf
search bas.sn.auf.org sn.auf.org refer.sn
nameserver 2001:4278:1002:b01:204:75ff:feed:e9e

Status des applications par rapport à ipv6

soucis et questions

• un peu paradoxal : pour avoir une configuration ipv6 seule, sans ipv4, automatique, je n'ai pas trouvé plus simple que :

allow-hotplug eth0
iface eth0 inet6 manual
        up ifconfig eth0 up

c'est pas un bug, c'est "comme ça" : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205583

• bug logcheck-database à signaler : conf par défaut sur /etc/logcheck/violations.ignore.d/logcheck-postfix, signale ça : (erreur dans le format "adresse ip"

Nov 30 06:39:02 www-dakar postfix/smtp[28977]: 9D12348250: to=<XXXX@refer.sn>, relay=smtp.refer.sn[2001:4278:1002:b01:204:75ff:feed:e9e], delay=0, status=bounced (host smtp.refer.sn[2001:4278:1002:b01:204:75ff:feed:e9e] said: 550 <XXXX@refer.sn>: Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command))

• des adresses > 2002:FF... allouées dans les derniers mois. Accessibles ou pas depuis la sonatel ? www.ietf.org (2610:a0:c779:b::d1ad:35b4) non accessible en ipv6 depuis la sonatel, ok depuis ovh !?!? vérifier avec d'autres ip > 2002:FF...

• pas beaucoup de correspondant ipv6. quasi rien dans les logs apache. par contre, côté mail, il y en a un peu :

# (cat mail.log;zcat mail.log*gz)|perl -ne 'print "$1\n" if(/\W(2[0-9a-f]{3}:[a-f0-9:]{1,34})\W/);' |egrep -v '^2(001:4278:1002:|002:ac4:3c9:)'|sort | uniq|wc -l
27

en regardant plus en détail : quasiment que des universités françaises

Avancement

• début de configuration reverse ipv6
  • en place sur ns.refer.sn et ns1.ca.auf.org

  • toutes nos ipv6 attribuées sont configurées (c'est allé vite :-D)

    • note : sipcalc -r 2001:4278:1002:b01:204:75ff:feed:e9e rend bien service, les fautes de frappes sont facile à faire

  • mail de demande envoyé à sonatel, pour la mise en place.

---

Bilan par mail envoyé le 25/11/2006 aux techs de la Sonatel concernés par la question.

Bonjour

Ci-joint un petit point sur notre avancement au niveau de la configuration ipv6 sur notre réseau Sénégal :

- une branche séparée de notre réseau dédiée aux expérimentations ipv6 - quelques serveurs (miroirs.refer.sn, trac.sn.auf.org) accessibles en ipv6, nous pensons basculer les autres dans un futur trés proche - quelques postes utilisateurs en ipv6 - les adresses '6to4' fonctionnent sans soucis, en entrée et sortie

Les problèmes rencontrés : - l'instabilité actuelle de notre liaison nous gêne considérablement dans nos tests, difficile d'évaluer réellement la connexion ipv6 quand à chaque fois, nous avons des doutes quant à la connexion ipv4 qui nous sert de reference - un problème avec le parefeu de la sonatel ? lorsque nous tentons d'accéder à une ipv6 de notre réseau qui n'a pas encore générés de traffic vers l'exterieur, le trafic semble être bloqué dans le sens exterieur->sonatel. toutefois, dès que l'ip génère du trafic vers l'extérieur, le problème semble résolu. est-ce une configuration volontaire à votre niveau ? - nous avons des difficultés à bien configurer notre parefeu en ipv6 : c'est le principal facteur bloquant, mais nous espérons régler cela très rapidement.

Les étapes suivantes, pour nous, d'ici la mi-décembre : - ajouter des adresses ipv6 au niveau de notre DNS - ajouter des adresses ipv6 au niveau de notre service mail - déployer à st-louis (nous avons rapidement tester le tunnel et le routage jeudi soir, et cela semblait fonctionnel sans soucis) - début 2007 : acheter des cartes "serial" sangoma, afin de faire aboutir nos LS Sonatel directement sur nos routeurs linux, et demander une connexion ipv6 native, sans tunnel.

Comme je vous l'avais signalé par téléphone : je dois me rendre à Bamako à la mi-décembre pour travailler sur notre réseau sur place. Nous sommes actuellement connecté via ikatel. Pourriez-vous me donner les contacts appropriés chez ikatel Mali pour évoquer ce sujet avec eux ? J'aimerai éventuellement pouvoir contacter les personnes dès maintenant.

Cordialement,