La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: Marin le 14 mars 2014 à 18:56:49
-
Bonjour,
Voici quelques sites web ou services avec lequels j'ai rencontré des problèmes récemment, uniquement en IPv6 (tout fonctionne normalement en IPv4) :
- Whois AFNIC : les longs whois sont tronqués aux 1024 premiers octets. Les paquets de données suivants sont perdus, à l'exception du dernier qui contient le FIN, mais il manque des choses au milieu, ce qui fait que la commande se bloque puis timeout après avoir affiché le début seulement du contenu.
- Orange Business : le site (http://www.orange-business.com/fr) est inaccessible, la connexion TCP s'effectue mais aucune réponse n'est reçue après l'envoi de la requête HTTP, même pas un ACK. À l'exception, bizarrement, de quelques contenus statiques (fichiers JS), qui passent en IPv6, bien qu'ils soient sur le même domaine et la même adresse IP.
- CDN Facebook : des serveurs tels que fbstatic-a.akamaihd.net, fbcdn-sphotos-e-a.akamaihd.net sont inaccessibles, je ne reçois aucune réponse à mon SYN.
Arrivez-vous à reproduire ces différents problèmes ? N'oubliez pas de préciser votre FAI et votre système d'exploitation (je suis chez SFR ADSL sous Archlinux, connecté à une Neufbox 6).
Si vous rencontrez des problèmes avec d'autres sites uniquement en IPv6, ça m'intéresse également.
-
Configuration:
- LAN uniquement en IPv4
- Linux Slackware en router IPv4/IPv6 à la place de la Freebox
- Un squid qui sait utiliser les deux stacks
- les PC du LAN (Windows ou Linux) pointent sur le squid
Bilan: site OBS et Facebook sans problèmes. Google/Youtube sans problème non plus. AFNIC peux-tu préciser ?
-
Tu es chez Free, qui n'utilise pas la même technologie de tunnel bizarroïde au MTU réduit que SFR, donc ça ne m'étonne pas tellement s'il y a des différences.
Pour le whois AFNIC, je veux dire qu'un whois sur le nom de domaine google.fr par exemple, ça donne ça :
$ whois google.fr
%%
%% This is the AFNIC Whois server.
%%
%% complete date format : DD/MM/YYYY
%% short date format : DD/MM
%% version : FRNIC-2.5
%%
%% Rights restricted by copyright.
%% See http://www.afnic.fr/afnic/web/mentions-legales-whois_en
%%
%% Use '-h' option to obtain more information about this service.
%%
%% [2a00:5e80:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX REQUEST] >> -V Md5.1 google.fr
%%
%% RL Net [##########] - RL IP [#########.]
%%
domain: google.fr
status: ACTIVE
hold: NO
holder-c: GIH6-FRNIC
admin-c: TT599-FRNIC
tech-c: CP4370-FRNIC
zone-c: NFC1-FRNIC
nsl-id: NSL4386-FRNIC
registrar: MARKMONITOR Inc.
anniversary: 30/12
created: 27/07/2000
last-update: 30/12/2011
source: FRNIC
ns-list: NSL4386-FRNIC
nserver: ns1.google.com
nserver: ns2.google.com
nserver: ns3.google.com
nserver: ns4.google.com
source: FRNIC
registrar: MARKMONITOR Inc.
type: Isp Option 1
address: 391 N. Ancestor Place
Timeout.
Et le timeout met du temps à apparaître. J'obtiens un résultat normal en forçant l'IPv4 pour whois.nic.fr via le fichier hosts.
-
Réponse instantanée sur le whois.
-
Oui, ça marche de chez moi.
Et Free utilise un tunnel, d'où le MTU réduit!
-
Mais pas aussi réduit que chez SFR il me semble ? C'est 1450 chez SFR.
-
Chez Free : 1480 pour cause de 6in4.
-
Problème de MSS ?
-
il serait intéressant de voir si le réseau modifie bien la MSS comme il le devrait.
Il faut donc le paquet [SYN] , [SYN, ACK] coté client et coté serveur.
A ta disposition pour faire la capture avec http://ipv6.lafibre.info (http://ipv6.lafibre.info)
-
Le MSS du client devrait être correct, la box l'ayant informé de son MTU, non?
-
Ben ma Freebox V5 est en bridge et l'interface de mon Linux est à 1500.
Donc si modif il y a ça serait "à la volée". Ou alors elle gère les fragments au niveau tunnel (Cisco sait le faire en GRE).
-
Déjà, il n'y a pas de bridge ni mode routeur. La Freebox est un routeur, point. Ce n'est pas configurable.
Ensuite, je ne comprends pas pourquoi linux croit que le MTU est 1500. Tu es bien en configuration auto?
-
Je suis en mode bridge c'est à dire que mon IPv4 publique est sur mon Linux.
Sinon truc intéressant:
# ping6 ipv6.lafibre.info -c 1 -s 1480 -M do
PING ipv6.lafibre.info(2a01:6e00:10:410::2) 1480 data bytes
From 2a01:e34:ee4f:5220:20c:29ff:fe7a:8131 icmp_seq=1 Packet too big: mtu=1480
--- ipv6.lafibre.info ping statistics ---
0 packets transmitted, 0 received, +1 errors
-
Chez moi aussi l'interface réseau est configurée avec un MTU de 1500 :
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 192.168.1.35/24 brd 192.168.1.255 scope global eth0
inet6 2a00:5e80:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX/64 scope global dynamic
valid_lft 604549sec preferred_lft 604549sec
inet6 fe80::XXXX:XXXX:XXXX:XXXX/64 scope link
valid_lft forever preferred_lft forever
Et je tiens aussi la valeur de la commande ping6 :
$ ping6 -s 1470 [url=https://www.google.com]www.google.com[/url]
PING [url=https://www.google.com(we-in-x69.1e100.net]www.google.com(we-in-x69.1e100.net[/url]) 1470 data bytes
From 2a00-5e80-XXXX-XXXX-0000-0000-0000-0001.rev.sfr.net icmp_seq=1 Packet too big: mtu=1450
-
Je suis en mode bridge c'est à dire que mon IPv4 publique est sur mon Linux.
Je suis en mode bridge c'est à dire que mon IPv4 publique est sur mon Windows.
Mais là on parlait d'IPv6.
-
J'ai compris, la MTU est apprise via la route, pas via l'interface :
# ip -f inet6 route
2a01:e34:ee4f:5220::/64 dev eth2 proto kernel metric 256 expires 85908sec mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth2 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev eth3 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 hoplimit 0
ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1440 hoplimit 0
ff00::/8 dev eth2 metric 256 mtu 1480 advmss 1420 hoplimit 0
ff00::/8 dev eth3 metric 256 mtu 1500 advmss 1440 hoplimit 0
default via fe80::224:d4ff:febd:759a dev eth2 proto kernel metric 1024 expires 1320sec mtu 1480 advmss 1420 hoplimit 64
-
Chez moi aussi l'interface réseau est configurée avec un MTU de 1500 :
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
C'est normal, c'est le MTU de l'interface Ethernet.
J'ai compris, la MTU est apprise via la route, pas via l'interface :
# ip -f inet6 route
2a01:e34:ee4f:5220::/64 dev eth2 proto kernel metric 256 expires 85908sec mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth2 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev eth3 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 hoplimit 0
ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1440 hoplimit 0
ff00::/8 dev eth2 metric 256 mtu 1480 advmss 1420 hoplimit 0
ff00::/8 dev eth3 metric 256 mtu 1500 advmss 1440 hoplimit 0
default via fe80::224:d4ff:febd:759a dev eth2 proto kernel metric 1024 expires 1320sec mtu 1480 advmss 1420 hoplimit 64
Bien sûr, puisque le MTU est associé à la route par défaut proposée par la box.
-
Donc si modif il y a ça serait "à la volée".
En IPv4, toutes les box font ses modificaiotns à la volée. C'est nécessaire quand on est sur le réseau France Telecom (non dégroupé).
-
Sauf que le réseau France Télécom ne travaille pas au niveau IP!
-
En IPv4, toutes les box font ses modificaiotns à la volée. C'est nécessaire quand on est sur le réseau France Telecom (non dégroupé).
Quand j'avais mon modem Netissimo ou mon Alicebox modifiée en modem, je gérais le MSS sur mon Linux sans quoi ça ne marchait pas.
-
Un des problèmes a été identifié ! La route était configurée comme ça :
default via fe80::XXXX:XXXX:XXXX:XXXX dev eth0 proto kernel metric 1024 expires 1503sec mtu 1480 rtt 73ms rttvar 32ms cwnd 10
Après un :
$ sudo ip route del default via fe80::XXXX:XXXX:XXXX:XXXX dev eth0 mtu 1480
$ sudo ip route add default via fe80::XXXX:XXXX:XXXX:XXXX dev eth0 mtu 1450
Je peux accéder à Orange Business et au whois AFNIC. Je vais essayer de faire remonter le problème à Efixo.
...cependant, le CDN Facebook n'est toujours pas accessible en IPv6. Une idée ?
-
J'ai testé le CDN Facebook, il marche bien, tant en TCP (logs de squid) qu'en ping.
Tu viens chez Free ? ;)
-
Non merci, je préfère avoir une connexion à internet correcte en soirée que de l'IPv6 qui fonctionne. :)
-
Ta box annonce quel MTU en IPv6?
-
Apparemment, ma box annonce un MTU de 1453, via un paquet ICMPv6 router advertisement. Ce matin la commande « ip -f inet6 route » affiche bien 1453 avec la configuration par défaut, je ne sais pas trop pourquoi elle affichait 1480 hier (sûrement parce que je me suis connecté à la Freebox d'un voisin pour tester un truc, mais je pensais que ça n'affectait que l'interface wlan0).
Le problème se pose donc bien quand la route est configurée avec un MTU de 1453, et modifier le MTU de la route de 1453 à 1450 résout là aussi le problème pour Orange Business et le whois AFNIC.
-
Quelques questions :
- Que donne un « ping6 fbstatic-a.akamaihd.net » chez vous ?
- Que donne un « traceroute -6 fbstatic-a.akamaihd.net » chez vous ?
- Que donne un « curl -v6 fbstatic-a.akamaihd.net » chez vous ?
Voici le résultat de ces commandes chez moi :
$ ping6 fbstatic-a.akamaihd.net
PING fbstatic-a.akamaihd.net(2001:668:108:12::d5fe:f898) 56 data bytes
^C
--- fbstatic-a.akamaihd.net ping statistics ---
50 packets transmitted, 0 received, 100% packet loss, time 49013ms
$ traceroute -6 fbstatic-a.akamaihd.net
traceroute to fbstatic-a.akamaihd.net (2001:668:108:12::d5fe:f898), 30 hops max, 80 byte packets
1 2a00-5e80-XXXX-XXXX-0000-0000-0000-0001.rev.sfr.net (2a00:5e80:XXXX:XXXX::1) 9.069 ms 9.036 ms 9.029 ms
2 * * *
3 2a02-8400-0000-0003-0000-0000-0000-0009.rev.sfr.net (2a02:8400:0:3::9) 34.049 ms 34.054 ms 36.079 ms
4 * * *
5 * 2001:978::19 (2001:978::19) 46.103 ms *
6 2001:978:4::e (2001:978:4::e) 51.010 ms 32.880 ms 32.865 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 2001:668:108:12::d5fe:f898 (2001:668:108:12::d5fe:f898) 46.863 ms * *
$ curl -v6 fbstatic-a.akamaihd.net
* Rebuilt URL to: fbstatic-a.akamaihd.net/
* Hostname was NOT found in DNS cache
* Trying 2001:668:108:12::d5fe:f8ab...
-
Voici mes résultats, avec Free ADSL dégroupé, sur PHA75, on voit que le tunnel ipv6 aboutit à Bezons(on fait un détour à bzn pour revenir au TH2).
janismarks-gailis@janismarks-gailis-ubuntu-Satellite-Pro-C660:~$ ping6 fbstatic-a.akamaihd.net
PING fbstatic-a.akamaihd.net(2a02:26f0:8b::210:7581) 56 data bytes
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=1 ttl=60 time=25.9 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=2 ttl=60 time=25.8 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=3 ttl=60 time=25.8 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=4 ttl=60 time=25.6 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=5 ttl=60 time=25.9 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=6 ttl=60 time=26.2 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=7 ttl=60 time=25.2 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=8 ttl=60 time=25.6 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=9 ttl=60 time=25.9 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=10 ttl=60 time=26.0 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=11 ttl=60 time=25.7 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=12 ttl=60 time=25.9 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=13 ttl=60 time=26.2 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=14 ttl=60 time=26.1 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=15 ttl=60 time=25.9 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=16 ttl=60 time=26.3 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=17 ttl=60 time=25.7 ms
64 bytes from 2a02:26f0:8b::210:7581: icmp_seq=18 ttl=60 time=25.5 ms
^C
--- fbstatic-a.akamaihd.net ping statistics ---
18 packets transmitted, 18 received, 0% packet loss, time 17024ms
rtt min/avg/max/mdev = 25.207/25.889/26.351/0.322 ms
traceroute -6 fbstatic-a.akamaihd.net
traceroute to fbstatic-a.akamaihd.net (2a02:26f0:8b::210:7581), 30 hops max, 80 byte packets
1 2a01:e35:8a28:7e60:: (2a01:e35:8a28:7e60::) 0.362 ms 0.350 ms 0.424 ms
2 2a01:e00:1b::1 (2a01:e00:1b::1) 26.000 ms * *
3 bzn-crs16-2-be1002.intf.routers.proxad.net (2a01:e00:17::1) 28.890 ms 32.550 ms 32.802 ms
4 th2-9k-1-be1003.intf.routers.proxad.net (2a01:e00:17:2::2) 32.789 ms 33.714 ms 34.924 ms
5 2a02:26f0:8b::210:7581 (2a02:26f0:8b::210:7581) 35.406 ms 36.383 ms 37.108 ms
janismarks-gailis@janismarks-gailis-ubuntu-Satellite-Pro-C660:~$ curl -v6 fbstatic-a.akamaihd.net
* Rebuilt URL to: fbstatic-a.akamaihd.net/
* Adding handle: conn: 0x8d35238
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x8d35238) send_pipe: 1, recv_pipe: 0
* About to connect() to fbstatic-a.akamaihd.net port 80 (#0)
* Trying 2a02:26f0:8b::210:7590...
* Connected to fbstatic-a.akamaihd.net (2a02:26f0:8b::210:7590) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.32.0
> Host: fbstatic-a.akamaihd.net
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< X-Rejecting-Non-Resource:
< Content-Type: text/html; charset=utf-8
< X-FB-Debug: xCKk/8htXPVF4QOAm7LP+wKsZa88OQPfeT3REVZGx2Q=
< Content-Length: 0
< Expires: Sat, 15 Mar 2014 11:49:00 GMT
< Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
< Date: Sat, 15 Mar 2014 11:49:00 GMT
< Connection: keep-alive
<
* Connection #0 to host fbstatic-a.akamaihd.net left intact
-
J'obtiens les mêmes résultats que toi si je fais des tests sur l'adresse IP 2a02:26f0:8b::210:7581 ou 2a02:26f0:8b::210:7590, mais ce n'est pas ce que donnent les DNS de SFR !
$ host fbstatic-a.akamaihd.net
fbstatic-a.akamaihd.net is an alias for fbstatic-a.akamaihd.net.edgesuite.net.
fbstatic-a.akamaihd.net.edgesuite.net is an alias for a1168.dsw4.akamai.net.
a1168.dsw4.akamai.net has address 5.178.43.32
a1168.dsw4.akamai.net has address 5.178.43.49
a1168.dsw4.akamai.net has address 5.178.43.42
a1168.dsw4.akamai.net has address 5.178.43.43
a1168.dsw4.akamai.net has IPv6 address 2001:668:108:12::d5fe:f898
a1168.dsw4.akamai.net has IPv6 address 2001:668:108:12::d5fe:f89a
a1168.dsw4.akamai.net has IPv6 address 2001:668:108:12::d5fe:f8aa
C'est peut-être un problème qui se situe plus du côté de Akamai/SFR du coup ?
-
Anefé.
badmax@batou:~$ host fbstatic-a.akamaihd.net
fbstatic-a.akamaihd.net is an alias for fbstatic-a.akamaihd.net.edgesuite.net.
fbstatic-a.akamaihd.net.edgesuite.net is an alias for a1168.dsw4.akamai.net.
a1168.dsw4.akamai.net has address 88.221.83.74
a1168.dsw4.akamai.net has address 88.221.83.56
a1168.dsw4.akamai.net has address 88.221.83.67
a1168.dsw4.akamai.net has IPv6 address 2a02:26f0:8b::210:7590
a1168.dsw4.akamai.net has IPv6 address 2a02:26f0:8b::210:7581
EDIT: j'ai mon propre resolver, je n'utilise pas les DNS de Free.
-
Je viens d'envoyer un rapport de bug détaillé à l'assistance mail de SFR, concernant les deux problèmes.
-
Voici chez free avec les DNS par défaut (j'ai bientôt prévu d'en changer, pour un serveur DNS perso, mais il faut que je m'achète mon serveur):
janismarks-gailis@janismarks-gailis-ubuntu-Satellite-Pro-C660:~$ host fbstatic-a.akamaihd.net
fbstatic-a.akamaihd.net is an alias for fbstatic-a.akamaihd.net.edgesuite.net.
fbstatic-a.akamaihd.net.edgesuite.net is an alias for a1168.dsw4.akamai.net.
a1168.dsw4.akamai.net has address 2.16.117.99
a1168.dsw4.akamai.net has address 2.16.117.90
a1168.dsw4.akamai.net has IPv6 address 2a02:26f0:8b::210:7590
a1168.dsw4.akamai.net has IPv6 address 2a02:26f0:8b::210:7581
-
Je viens de recevoir une réponse prédéfinie de l'assistance mail... On me demande de « contacter notre Service Technique par téléphone au 1023 afin de pouvoir faire des vérifications sur la ligne et au niveau de vos équipements »... ???
-
Si je résume :
- Problème de MTU qui est à 1480 au lieu d'être à 1453
- Certains cache Akamai sont injoignable en IPv6
Normalement en cas d'échec en IPv6, la navigateur ne bascule pas en IPv4 ?
-
Si je résume :
- Problème de MTU qui est à 1480 au lieu d'être à 1453
- Certains cache Akamai sont injoignable en IPv6
Pour le MTU, c'est qu'il est à 1453 au lieu de 1450.
Pour Akamai, c'est ça.
Normalement en cas d'échec en IPv6, la navigateur ne bascule pas en IPv4 ?
Ça dépend du problème et du navigateur. Pas dans le cas d'Orange-Business avec Firefox en tous cas.
-
Bonjour,
il y avait le même soucis avec le groupe M6web: voici le lien du sujet : http://www.clubic.com/forum/courrier-des-lecteurs/clubic-v2-remarques-bug-id712604-page304.html#1803053289 (http://www.clubic.com/forum/courrier-des-lecteurs/clubic-v2-remarques-bug-id712604-page304.html#1803053289)
çà serait bien le mtu SFR qui serait "bugant".
apparement réglé par un modif chez m6web ..
-
Normalement en cas d'échec en IPv6, la navigateur ne bascule pas en IPv4 ?
Je sais pas pour les autres navigateurs mais pour Chrome si un site a les 2 IP (reponse DNS en v4 et v6) le navigateur donne 250ms (anciennement 300ms) d'avance a une connexion v6 avant d'ouvrir la meme en v4. Ca fait donc un fallback en v4 si ca repond pas en v6 OU si ca met trop de temps a repondre.
C'est leur implementation d' 'Happy Eyeballs (https://en.wikipedia.org/wiki/Happy_Eyeballs)'
ps: Firefox supporte ca aussi a priori (j'ai pas vérifié).
-
le soucis qu'il y avait avec le groupe M6web, la connexion s'ouvrait bien mais tombait en timeout en attendant les headers après requête http, depuis une connexion ipv6 sfr, du coup le navigateur ne basculait pas, il attendait. Ou basculait très très tardivement (plusieurs minutes)
-
Le même problème qu'avec orange-business donc.
-
Vous avez compris si la non conformité était coté M6-web et son load balancer ou coté SFR et une mauvaise gestion des MTU ?
C'est pour savoir a qui il faut envoyer le problème...
-
Quelqu'un peut me donner une IPv6 de chez M6Web ? Je ne trouve aucun enregistrement AAAA....
-
Vous avez compris si la non conformité étais coté M6-web et son load balancer ou coté SFR et une mauvaise gestion des MTU ?
Je dirais que c'est toujours le même problème qui se trouve côté SFR avec son MTU, mais que M6Web s'est adapté pour pallier à ce bug sans attendre une correction côté SFR.
Quelqu'un peut me donner une IPv6 de chez M6Web ? Je ne trouve aucun enregistrement AAAA....
L'info se trouve dans le sujet sur le forum Clubic indiqué par buddy, le serveur impacté est img.clubic.com :
$ host img.clubic.com
img.clubic.com has address 141.138.91.59
img.clubic.com has address 141.138.91.60
img.clubic.com has IPv6 address 2a01:a580:6:1972::60
img.clubic.com has IPv6 address 2a01:a580:6:1972::59
Qui s'est donc adapté au problème.
-
Procédure de test qui met en évidence des soucis chez M6 :
$ curl http://www.clubic.com > index.html
$ grep "img.clubic" index.html | awk -F// '{print $2}' | awk -F\" '{print $1}' | while read IMG; do wget -6 -O /dev/null http://$IMG; done
On voit wget se bloquer de temps à autre sur le chargement des images. En forçant IPv4 (option -4 au lieu de -6), aucun problème.