La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: underground78 le 19 octobre 2020 à 20:02:53
-
Bonsoir,
Depuis plusieurs mois je remarque régulièrement que pour une raison que je ne comprends pas, IPv6 est régulièrement HS sur ma machine sous Windows 10.
La machine dispose bien d'une IPv6 :
>ipconfig /all
Configuration IP de Windows
Nom de l’hôte . . . . . . . . . . : PC-1
Suffixe DNS principal . . . . . . :
Type de noeud. . . . . . . . . . : Hybride
Routage IP activé . . . . . . . . : Non
Proxy WINS activé . . . . . . . . : Non
Carte Ethernet Ethernet :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Intel(R) 82579V Gigabit Network Connection
Adresse physique . . . . . . . . . . . : 10-BF-48-80-45-8A
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv6. . . . . . . . . . . . . .: 2a01:e0a:XXXX:XXXX:d022:31ac:3914:5111(préféré)
Adresse IPv6 temporaire . . . . . . . .: 2a01:e0a:XXXX:XXXX:18b5:5741:4bf0:b189(préféré)
Adresse IPv6 temporaire . . . . . . . .: 2a01:e0a:XXXX:XXXX:8441:d408:f7c4:50cc(déprécié)
Adresse IPv6 de liaison locale. . . . .: fe80::d022:31ac:3914:5111%6(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.0.1(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : lundi 19 octobre 2020 19:23:29
Bail expirant. . . . . . . . . . . . . : mardi 20 octobre 2020 07:23:28
Passerelle par défaut. . . . . . . . . : fe80::224:d4ff:fea4:719%6
192.168.0.254
Serveur DHCP . . . . . . . . . . . . . : 192.168.0.254
IAID DHCPv6 . . . . . . . . . . . : 51429192
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-1E-E5-0A-A6-10-BF-48-80-45-8A
Serveurs DNS. . . . . . . . . . . . . : 192.168.0.254
fd0f:ee:b0::1
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Carte Ethernet VirtualBox Host-Only Network :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter
Adresse physique . . . . . . . . . . . : 0A-00-27-00-00-0F
DHCP activé. . . . . . . . . . . . . . : Non
Configuration automatique activée. . . : Oui
Adresse IPv6 de liaison locale. . . . .: fe80::6cf2:396e:b796:8f1b%15(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.56.1(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Passerelle par défaut. . . . . . . . . :
IAID DHCPv6 . . . . . . . . . . . : 302645287
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-1E-E5-0A-A6-10-BF-48-80-45-8A
Serveurs DNS. . . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Carte Ethernet Ethernet 2 :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : TAP-Windows Adapter V9
Adresse physique . . . . . . . . . . . : 00-FF-30-20-F0-F4
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Cependant par défaut la résolution de nom se fait en IPv4 :
>ping ip.lafibre.info
Envoi d’une requête 'ping' sur ip.lafibre.info [89.84.1.194] avec 32 octets de données :
Réponse de 89.84.1.194 : octets=32 temps=3 ms TTL=58
Réponse de 89.84.1.194 : octets=32 temps=3 ms TTL=58
Réponse de 89.84.1.194 : octets=32 temps=2 ms TTL=58
Réponse de 89.84.1.194 : octets=32 temps=3 ms TTL=58
Statistiques Ping pour 89.84.1.194:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 2ms, Maximum = 3ms, Moyenne = 2ms
La résolution d'un nom de domaine uniquement disponible en IPv6 se fait bien mais impossible de faire un ping, les paquets ne semblent même pas aller jusqu'à la box :
>ping ipv6.lafibre.info
Envoi d’une requête 'ping' sur ipv6.lafibre.info [2001:860:de01:1101::2] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 2001:860:de01:1101::2:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
>tracert ipv6.lafibre.info
Détermination de l’itinéraire vers ipv6.lafibre.info [2001:860:de01:1101::2]
avec un maximum de 30 sauts :
1 * * * Délai d’attente de la demande dépassé.
2 * * * Délai d’attente de la demande dépassé.
3 * * * Délai d’attente de la demande dépassé.
...
Le problème disparaît de lui-même au bout d'un moment (le temps que j'écrive ce sujet dans le cas présent).
Qu'est-ce que je pourrais faire la prochaine fois que ça arrive pour essayer de caractériser le problème ?
U78
-
Qu'est-ce que je pourrais faire la prochaine fois que ça arrive pour essayer de caractériser le problème ?
Vérifier si la box répond sur le LAN avec un "ping fe80::224:d4ff:fea4:719".
Si ça dure assez longtemps, capturer le trafic (wireshark ou pktmon), particulièrement les ICMPv6 qui devraient être échangés entre la box et le PC.
-
Cela serait bien de vérifier avec un téléphone en Wi-Fi que la page se charge bien pour être sur que la box n'est pas en cause.
Ton PC a des IPv6, mais ce qui est intéressant c'est de voir la table de routage dans un cas où IPv6 marche et dans un cas où cela ne marche pas.
Exemple sous Linux :
Cas où IPv6 est fonctionne après un reboot :
Voici ce que l'on a quand l'IPv6 est fonctionnel après un reboot (c'est le cas dans 90% des reboot) : On note le Next Hop 2001:860:de01:1102::1 qui correspond à ma configuration.
$ route -6
Table de routage IPv6 du noyau
Destination Next Hop Flag Met Ref Use If
2001:860:de01:1102::/64 :: U 256 2 1 enp1s0f0
2001:860:deff:1002::/64 :: U 256 1 0 enp1s0f0
fe80::/64 :: U 256 1 0 enp1s0f0
::/0 2001:860:de01:1102::1 UG 1024 8 485 enp1s0f0
::/0 :: !n -1 1 488 lo
::1/128 :: Un 0 9 56 lo
2001:860:de01:1102::2/128 :: Un 0 10 121 lo
2001:860:de01:1102::3/128 :: Un 0 2 0 lo
2001:860:deff:1002::2/128 :: Un 0 9 145 lo
fe80::3efd:feff:fe1d:8f00/128 :: Un 0 4 5 lo
ff00::/8 :: U 256 3 7 enp1s0f0
::/0 :: !n -1 1 488 lo
$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:860:de01:1102::2/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:860:deff:1002::2/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 2001:860:de01:1102::3/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 fe80::3efd:feff:fe1d:8f00/64 scope link
valid_lft forever preferred_lft forever
Cas où IPv6 est HS après un reboot :
Voici ce que l'on a quand l'IPv6 est HS après un reboot (c'est le cas dans 10% des reboot) : On note le Next Hop fe80::2a52:61ff:fed7:84c2 qui explique pourquoi nous n'avons pas de connectivité IPv6.
On note la présence d'une IPv6 dynamique alors que ce n'est nullement demandé dans ma configuration.
$ route -6
Table de routage IPv6 du noyau
Destination Next Hop Flag Met Ref Use If
2001:860:de01:1102::/64 :: UA 256 2 1 enp1s0f0
2001:860:deff:1002::/64 :: U 256 1 0 enp1s0f0
fe80::/64 :: U 256 1 0 enp1s0f0
::/0 fe80::2a52:61ff:fed7:84c2 UGDAe 1024 8 557 enp1s0f0
::/0 :: !n -1 1 557 lo
::1/128 :: Un 0 9 62 lo
2001:860:de01:1102::2/128 :: Un 0 9 108 lo
2001:860:de01:1102:3efd:feff:fe1d:8f00/128 :: Un 0 2 0 lo
2001:860:de01:1102::3/128 :: Un 0 2 0 lo
2001:860:deff:1002::2/128 :: Un 0 9 139 lo
fe80::3efd:feff:fe1d:8f00/128 :: Un 0 4 8 lo
ff00::/8 :: U 256 3 8 enp1s0f0
::/0 :: !n -1 1 557 lo
$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:860:de01:1102::2/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:860:deff:1002::2/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 2001:860:de01:1102::3/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 2001:860:de01:1102:3efd:feff:fe1d:8f00/64 scope global mngtmpaddr dynamic
valid_lft 2591700sec preferred_lft 604500sec
inet6 fe80::3efd:feff:fe1d:8f00/64 scope link
valid_lft forever preferred_lft forever
La cause de la parte d'IPv6 était que Ubuntu serveur utilise l'IPv6 HS du RA (Router Advertisement), à la place de celle indiquée dans /etc/network/interfaces si au moment du boot il récupère le RA avant d’appliquer la conf réseau indiquée et que dans mon cas l'IPv6 du RA était pas bonne (Cisco envoi des RA dans sa configuration par défaut et là la partie IPv6 n'avait pas été configuré)
-
@vivien : J'ai essayé de regarder la table de routage hier, je n'ai rien vu de bizarre mais c'est à ce moment là que j'ai réalisé qu'IPv6 refonctionnait. Je regarderai la prochaine fois.
@hwti : Ok pour le ping, pour la capture ça va être un peu plus complexe mais je vais essayer.
-
Bonsoir,
Le problème se produit à nouveau ce soir.
Configuration réseau :
> ipconfig.exe /all
Configuration IP de Windows
Nom de l’hôte . . . . . . . . . . : PC-1
Suffixe DNS principal . . . . . . :
Type de noeud. . . . . . . . . . : Hybride
Routage IP activé . . . . . . . . : Non
Proxy WINS activé . . . . . . . . : Non
Carte Ethernet Ethernet :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Intel(R) 82579V Gigabit Network Connection
Adresse physique . . . . . . . . . . . : 10-BF-48-80-45-8A
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv6. . . . . . . . . . . . . .: 2a01:e0a:xxxx:xxxx:d022:31ac:3914:5111(préféré)
Adresse IPv6 temporaire . . . . . . . .: 2a01:e0a:xxxx:xxxx:564:2a0e:64f8:fe45(déprécié)
Adresse IPv6 temporaire . . . . . . . .: 2a01:e0a:xxxx:xxxx:d9b:b0a6:2238:87bc(déprécié)
Adresse IPv6 temporaire . . . . . . . .: 2a01:e0a:xxxx:xxxx:794f:10e:7264:7f46(préféré)
Adresse IPv6 temporaire . . . . . . . .: 2a01:e0a:xxxx:xxxx:c878:8af:5cd5:2089(déprécié)
Adresse IPv6 de liaison locale. . . . .: fe80::d022:31ac:3914:5111%6(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.0.1(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : mardi 27 octobre 2020 19:24:27
Bail expirant. . . . . . . . . . . . . : mercredi 28 octobre 2020 07:24:25
Passerelle par défaut. . . . . . . . . : fe80::224:d4ff:fea4:719%6
192.168.0.254
Serveur DHCP . . . . . . . . . . . . . : 192.168.0.254
IAID DHCPv6 . . . . . . . . . . . : 51429192
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-1E-E5-0A-A6-10-BF-48-80-45-8A
Serveurs DNS. . . . . . . . . . . . . : 192.168.0.254
fd0f:ee:b0::1
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Carte Ethernet VirtualBox Host-Only Network :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter
Adresse physique . . . . . . . . . . . : 0A-00-27-00-00-0F
DHCP activé. . . . . . . . . . . . . . : Non
Configuration automatique activée. . . : Oui
Adresse IPv6 de liaison locale. . . . .: fe80::6cf2:396e:b796:8f1b%15(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.56.1(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Passerelle par défaut. . . . . . . . . :
IAID DHCPv6 . . . . . . . . . . . : 302645287
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-1E-E5-0A-A6-10-BF-48-80-45-8A
Serveurs DNS. . . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Carte Ethernet Ethernet 2 :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : TAP-Windows Adapter V9
Adresse physique . . . . . . . . . . . : 00-FF-30-20-F0-F4
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Table de routage :
> route PRINT -6
===========================================================================
Liste d'Interfaces
6...10 bf 48 80 45 8a ......Intel(R) 82579V Gigabit Network Connection
15...0a 00 27 00 00 0f ......VirtualBox Host-Only Ethernet Adapter
5...00 ff 30 20 f0 f4 ......TAP-Windows Adapter V9
1...........................Software Loopback Interface 1
===========================================================================
IPv6 Table de routage
===========================================================================
Itinéraires actifs :
If Metric Network Destination Gateway
6 281 ::/0 fe80::224:d4ff:fea4:719
1 331 ::1/128 On-link
6 281 2a01:e0a:xxxx:xxxx::/64 On-link
6 281 2a01:e0a:xxxx:xxxx:564:2a0e:64f8:fe45/128
On-link
6 281 2a01:e0a:xxxx:xxxx:d9b:b0a6:2238:87bc/128
On-link
6 281 2a01:e0a:xxxx:xxxx:794f:10e:7264:7f46/128
On-link
6 281 2a01:e0a:xxxx:xxxx:c878:8af:5cd5:2089/128
On-link
6 281 2a01:e0a:xxxx:xxxx:d022:31ac:3914:5111/128
On-link
15 281 fe80::/64 On-link
6 281 fe80::/64 On-link
15 281 fe80::6cf2:396e:b796:8f1b/128
On-link
6 281 fe80::d022:31ac:3914:5111/128
On-link
1 331 ff00::/8 On-link
15 281 ff00::/8 On-link
6 281 ff00::/8 On-link
===========================================================================
Itinéraires persistants :
Aucun
Tentative de ping de la passerelle (j'ai eu une erreur et ensuite ça a toujours fonctionné) :
> ping fe80::224:d4ff:fea4:719
Envoi d’une requête 'Ping' fe80::224:d4ff:fea4:719 avec 32 octets de données :
Impossible de joindre l’hôte de destination.
Réponse de fe80::224:d4ff:fea4:719 : temps<1ms
Réponse de fe80::224:d4ff:fea4:719 : temps<1ms
Réponse de fe80::224:d4ff:fea4:719 : temps<1ms
Statistiques Ping pour fe80::224:d4ff:fea4:719:
Paquets : envoyés = 4, reçus = 3, perdus = 1 (perte 25%),
Durée approximative des boucles en millisecondes :
Minimum = 0ms, Maximum = 0ms, Moyenne = 0ms
> ping fe80::224:d4ff:fea4:719
Envoi d’une requête 'Ping' fe80::224:d4ff:fea4:719 avec 32 octets de données :
Réponse de fe80::224:d4ff:fea4:719 : temps<1ms
Réponse de fe80::224:d4ff:fea4:719 : temps<1ms
Réponse de fe80::224:d4ff:fea4:719 : temps<1ms
Réponse de fe80::224:d4ff:fea4:719 : temps<1ms
Statistiques Ping pour fe80::224:d4ff:fea4:719:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 0ms, Maximum = 0ms, Moyenne = 0ms
Ping et traceroute depuis ma machine :
> ping ip.lafibre.info
Envoi d’une requête 'ping' sur ip.lafibre.info [89.84.1.194] avec 32 octets de données :
Réponse de 89.84.1.194 : octets=32 temps=3 ms TTL=58
Réponse de 89.84.1.194 : octets=32 temps=2 ms TTL=58
Réponse de 89.84.1.194 : octets=32 temps=3 ms TTL=58
Réponse de 89.84.1.194 : octets=32 temps=3 ms TTL=58
Statistiques Ping pour 89.84.1.194:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 2ms, Maximum = 3ms, Moyenne = 2ms
> ping ipv6.lafibre.info
Envoi d’une requête 'ping' sur ipv6.lafibre.info [2001:860:de01:1101::2] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
> tracert ipv6.lafibre.info
Détermination de l’itinéraire vers ipv6.lafibre.info [2001:860:de01:1101::2]
avec un maximum de 30 sauts :
1 * * * Délai d’attente de la demande dépassé.
2 * * * Délai d’attente de la demande dépassé.
3 * * * Délai d’attente de la demande dépassé.
4 * * * Délai d’attente de la demande dépassé.
5 * * * Délai d’attente de la demande dépassé.
6 * * * Délai d’attente de la demande dépassé.
7 * * * Délai d’attente de la demande dépassé.
8 * * * Délai d’attente de la demande dépassé.
9 * * * Délai d’attente de la demande dépassé.
10 * * * Délai d’attente de la demande dépassé.
...
Traceroute depuis un serveur chez Scaleway vers ma box : la box ne répond pas alors qu'elle devrait :
traceroute -6 xxxx.freeboxos.fr
traceroute to xxxx.freeboxos.fr (2a01:e0a:xxxx:xxxx::1), 30 hops max, 80 byte packets
1 2001:bc8:62c:2038:: (2001:bc8:62c:2038::) 0.877 ms 0.863 ms 0.850 ms
2 * * *
3 * * *
4 2001:bc8:400:1::15a (2001:bc8:400:1::15a) 1.263 ms 2001:bc8:400:1::15e (2001:bc8:400:1::15e) 1.474 ms 2001:bc8:400:1::15a (2001:bc8:400:1::15a) 1.466 ms
5 2001:bc8:400:1::4d (2001:bc8:400:1::4d) 1.516 ms 2001:bc8:400:100::c7 (2001:bc8:400:100::c7) 1.110 ms 1.418 ms
6 bzn-crs16-1-be1500-p.intf.routers.proxad.net (2a01:e00:1:b::1) 1.633 ms * 1.175 ms
7 * * *
8 * * *
9 2a01:e00:2d:1700:fe00::392 (2a01:e00:2d:1700:fe00::392) 3.104 ms * 2.886 ms
10 2a01:e00:2d:1700:fe00::392 (2a01:e00:2d:1700:fe00::392) 3.123 ms 2.811 ms *
11 * * *
...
Je vois voir si j'arrive à faire une capture.
-
Je vois voir si j'arrive à faire une capture.
J'ai voulu réinstaller une version récente de Wireshark et le temps que je le fasse IPv6 refonctionnait.
Traceroute depuis un serveur chez Scaleway vers ma box : la box ne répond pas alors qu'elle devrait
Le traceroute ne se finit toujours pas, je comprends pas trop pourquoi... La box répond bien au ping mais c'était peut-être déjà le cas au moment où je n'avais plus d'IPv6 sur ma machine, je n'ai pas pensé à faire le test à ce moment là.
Edit : Si j'utilise "mtr" plutôt que traceroute, je vois bien un saut final qui est ma box :
mtr -wnc 10 xxxx.freeboxos.fr
Start: 2020-10-27T19:31:30+0000
HOST: gallifrey Loss% Snt Last Avg Best Wrst StDev
1.|-- 2001:bc8:62c:2038:: 0.0% 10 0.4 0.4 0.2 0.6 0.1
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- 2001:bc8:400:1::15a 0.0% 10 1.2 1.2 1.0 1.5 0.1
5.|-- 2001:bc8:400:100::c7 30.0% 10 1.1 1.2 1.0 1.3 0.1
6.|-- 2a01:e00:1:b::1 0.0% 10 1.5 1.5 1.3 1.8 0.1
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- 2a01:e00:2d::d 50.0% 10 2.5 3.0 2.5 4.4 0.8
9.|-- 2a01:e00:2d:1700:fe00::392 0.0% 10 3.3 3.2 3.0 3.5 0.2
10.|-- 2a01:e0a:xxxx:xxxx::1 10.0% 10 3.0 3.3 2.8 3.7 0.3
Edit 2 : Ok, mtr utilise ICMP par défaut mais pas traceroute, c'est juste de là que vient le problème. L'absence de réponse lors du premier test ne veut donc rien dire.
-
Par contre je ne pige pas pourquoi mais je reste en IPv4 sur lafibre.info. Sur ip.lafibre.info, je suis bien détecté en IPv6.
J'ai essayé de vider le cache DNS au niveau de l'OS et de Firefox.
Si j'ouvre lafibre.info dans un autre navigateur je suis bien en IPv6.
Edit : Il a suffit que je poste ce message pour que je repasse en IPv6 dans Firefox aussi, je pige pas trop bien ce qu'il se passe mais bon c'est pas le problème principal...
-
Je remarque aussi que souvent je suis vu en IPv4 sur le site lafibre.info, aussi sous windows 10 avec Firefox, comme en ce moment.
Pourtant, je ping ipv6.lafibre.info, j'ai bien une adresse IPv6, mais d'après ip.lafibre.ifo, j'utilise IPv4 par défaut. Cela fait longtemps que cela me le fait. J'ai testé sous Chrome, c'est pareil
Quelle est mon adresse IPv4 / IPv6 publique ?
Connectivité IP : Attention : Vous n’avez pas de connectivité IPv6 native.
Connectivité IPv4 (via requête DNS) OK : IPv4 publique = 82.64.185.xx
Connectivité IPv4 (via IPv4 littérale) OK : IPv4 publique = 82.64.185.xx
Connectivité IPv6 (via requête DNS) OK : IPv6 publique = 2a01:e0a:21b:xxxx:xxxx:xxxx:770:82c9
La version du protocole IP utilisée par défaut est IPv4
Reverse DNS :
Reverse DNS IPv4 est 82-64-185-xx.subs.proxad.net
Reverse DNS IPv6 est 2a01:e0a:21b:xxxx:xxxx:xxxx:770:82c9
Informations TCP :
Port TCP source utilisé par votre connexion IPv4 : TCP 19184 et TCP 19187 (via IPv4 littérale) (Plus d'informations)
Port TCP source utilisé par votre connexion IPv6 : TCP 19188
Port TCP destination utilisé : TCP 80
-
Tentative de ping de la passerelle (j'ai eu une erreur et ensuite ça a toujours fonctionné) :
Rien que ça, c'est étrange. Même si l'adresse MAC n'est plus dans le cache, la résolution d'adresse via NDP (équivalent d'ARP en IPv4) ne devrait pas beaucoup retarder le ping.
-
Il faudra que je vois si c'est réellement reproductible à chaque fois que le souci ce produit.
-
Je remarque aussi que souvent je suis vu en IPv4 sur le site lafibre.info, aussi sous windows 10 avec Firefox, comme en ce moment.
Un navigateur va choisir entre IPv4 et IPv6 dynamiquement, en fonction de celle qui répond en premier, et mettre le résultat en cache pour un certain temps (algorithme Happy Eyeballs ou similaire).
Un basculement entre les deux n'est pas forcément le signe d'un disfonctionnement, ça peut venir de latences différentes entre les deux par exemple (en plus, pour le forum, suite aux DDoS, IPv4 et IPv6 ne sont pas sur le même réseau).
-
(en plus, pour le forum, suite aux DDoS, IPv4 et IPv6 ne sont pas sur le même réseau).
Exact, j'avais oublié, mais cela date de bien avant. Mais effectivement, je n'ai pas l'impression de perdre IPv6, donc c'est peut-être cette histoire d'IPv4 qui répondrait parfois avant IPv6...
-
J'ai déjà eu un problème de ce genre avec Windows 10. Mais je ne l'ai plus eu depuis un moment, donc j'ai l'impression que c'est parti.
Si jamais ça me le refait, je penserai à passer ici :)
-
Rebelote ce matin, plus d'IPv6.
Cette fois j'ai pu vérifier que ma box continue à bien répondre au ping en IPv6.
J'ai voulu faire une capture mais j'ai l'impression qu'IPv6 a recommencé à fonctionner quand je l'ai démarrée...
-
J'ai le même problème.
Mon Windows 10 perd sa connexion ipv6 très souvent, je dois redémarrer ou désactiver/réactiver la carte réseau pour rétablir la liaison (avec la livebox).
La route par défaut disparait de la table de routage.
Chose curieuse, les paquets ping envoyés par Windows à la box semblent perdus par intermittence (8 reçus, 7 perdus, etc...) voyez :
❯ ping fe80::46a6:1eff:fee5:32e0 -t
Envoi d’une requête 'Ping' fe80::46a6:1eff:fee5:32e0 avec 32 octets de données :
Délai d’attente de la demande dépassé.
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=4 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=4 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=8 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=57 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=6 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=7 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=52 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=48 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=10 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=3 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=48 ms
Réponse de fe80::46a6:1eff:fee5:32e0 : temps=104 ms
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
etc... tel un métronome...
Alors que depuis un poste Linux, 100% des pings sont répondus par la box.
J'incrimine donc Windows (ou la carte réseau) mais je ne sais pas où continuer mes recherches.
edit: les moments où windows ne reçoit pas les retours de ping correspondent aux moments où des Neighbor Solicitation sont envoyés par la box. Aucune idée si c'est normal ou pas.
-
Problème similaire côté W10 noté ici, avec le même comportement que decalage niveau ping.
Windows 10H2 à jour de décembre 2020, pilotes à jour également. Mes tests sont toujours en Wi-Fi, je vais essayer de tester en Ethernet.
-
underground78, decalage et Harvester, c'est possible d'avoir :
- le modèle de votre box
- la version e Windows 10 (ex: 2004)
-
Windows 10 2004 et Freebox Révolution, après je ne sais pas si tous les problèmes sont les mêmes.
Le problème que j'ai décrit initialement n'a l'air d'arriver que lorsque je redémarre complètement le PC. Ces derniers temps je le mets en veille prolongée et je n'ai pas le problème.
Le deuxième problème que j'ai décrit (forum lafibre.info qui m'affiche IPv4 alors que je suis bien en IPv6 sur ip.lafibre.info) ça fait quelques temps que je l'ai pas repéré.
-
Windows 10 famille 2004 en wifi (carte intel DualBand wireless-AC 7265, drivers au 15-sept-2020) et Livebox 4 adsl.
J'ai l'impression que Windows ne lit pas les RA envoyés par la box toutes les x secondes via ff02::1.
Je vois que la durée de vie préférée des adresses ipv6 attribuées à ma carte réseau n'est pas renouvelée. Étant de 10 minutes, je constate qu'à l'instant où ces 10 minutes sont écoulées, elles passent dépréciées et la table de routage perd la route par défaut.
Il faut alors éteindre et rallumer pour obtenir mes 10 minutes d'internet ipv6. ;D
-
Windows 10 famille 2004 (19041.685) en wifi (carte intel DualBand wireless-AC 7265, drivers au 15-sept-2020) et Livebox 4 adsl.
Est-ce qu'il y a des pertes sur un ping IPv4 ?
Le poste linux est aussi en wifi, ou en ethernet ?
-
Est-ce qu'il y a des pertes sur un ping IPv4 ?
Le poste linux est aussi en wifi, ou en ethernet ?
linux en ethernet.
Sur le poste windows ll n'y a pas de pertes sur ipv4. Et d'ailleurs y en a pu sur ipv6 non plus, la box répond parfaitement maintenant, tant mieux mais bizarre.
Avec Wireshark je vois bien les RA passer toutes les 60sec et la box résoud les requêtes DNS envoyées depuis l'adresse link-local donc le dialogue se fait.
Mais les adresses ipv6 restent dépréciées...
J'ai vérifié le pare-feu, y a aucune règle en mode "bloquer ceci". Y a t'il un moyen de vérifier que l'ICMPv6 fonctionne sur Windows ?
edit: je vois la box envoyer ping request à ff02::1 mais mon pc ne répond rien, c'est normal ?
-
J'ai résolu mon problème.
C'était le pare-feu Windows qui par défaut bloque tout le traffic ICMP. Il faut le savoir.
Donc j'ai rajouté une règle (https://noobient.com/2018/08/02/passing-icmpv6-on-windows-defender-firewall/) qui autorise ICMPv6 et c'est bon.
Il y a surement déjà une telle règle dans un pare-feu Windows tout neuf, mais j'ai dû un jour par mégarde lancer un logiciel anti-mouchard windows 10 qui a modifié le pare-feu en y allant un peu trop fort. ;D
-
Moi j'ai toujours des trucs bizarres, des fois je perds complètement IPv6 mais des fois c'est juste sur lafibre.info sur Firefox (probablement parce que c'est là que c'est plus facile à voir pour moi).
Là par exemple ça fait depuis longtemps aujourd'hui (peut-être depuis ce matin, je suis pas sûr) que je suis en IPv4 sur lafibre.info sur Firefox. Si je vais sur ip.lafibre.info, j'ai bien une IPv6 et si j'ouvre lafibre.info dans Chrome je suis bien en IPv6 aussi...
J'ai essayé de virer le cache DNS (aussi bien au niveau de Windows et que de Firefox) mais sans succès.
Edit : Si je passe en navigation privée dans Firefox, je récupère mon IPv6 sur lafibre.info...
-
Et bien j'ai le même "problème". Sur youtube je reste en ipv6 mais sur lafibre.info je suis aléatoirement en ipv4 (j'ai toujours de l'ipv6, mais pas préféré) et sur fierfox aussi donc.
-
Je vais dans les prochaines semaines complexifier ip.lafibre.info pour faire des tests supplémentaires en IPv6.
J'aimerais savoir comment fonctionne ce cache qui va garder l'information IPv4 / IPv6.
-
Je vais dans les prochaines semaines complexifier ip.lafibre.info pour faire des tests supplémentaires en IPv6.
J'aimerais savoir comment fonctionne ce cache qui va garder l'information IPv4 / IPv6.
Je ne sais pas si c'est documenté quelque part (et à jour).
Le navigateurs, comme curl par exemple, implémentent l'algorithme Happy Eyeballs : le protocole préféré (typiquement décidé par l'OS) est tenté d'abord, et 200ms à 300ms après l'autre protocole est tenté.
La première connexion TCP établie gagne (c'est comme ça dans curl, pour les navigateurs je ne sais pas si c'est ce critère, ils pourraient aller jusqu'à faire la requête http si c'est un GET), et les navigateurs gardent probablement le résultat en cache.
Pour lafibre.info, ça voudrait dire que l'IPv6 est parfois plus lente que l'IPv4 (il faudrait des captures réseau pour comprendre).
Si tu veux t'assurer d'une nouvelle tentative qui ignore le cache, je pense qu'utiliser des noms de domaines différents devrait aider.
-
L'IPv4 et l'IPv6 sont sur deux réseaux distincts, cela permet une plus haute disponibilité pour ceux qui ont les deux protocoles, donc pas forcément la même latence, mais normalement il devrait très rare d'avoir plus de 30ms d’écart.
-
Je crois que je viens de voir passer ma connexion sur lafibre.info de IPv6 à IPv4.
Je lisais des sujets et je sais que j'étais en IPv6 parce que j'ai notamment lu vos réponses à ce sujet et à ce moment là j'ai regardé si j'étais en IPv6. Quelques instants plus tard, j'ai répondu à un sujet, j'ai eu l'impression d'une lenteur et quand finalement mon message a été posté, j'étais passé en IPv4.
Je suis toujours en IPv6 sur "ip.lafibre.info" et j'ai une latence très légèrement moins élevée en IPv6 qu'en IPv4 sur lafibre.info :
>ping lafibre.info
Envoi d’une requête 'ping' sur lafibre.info [2a01:6e00:10:410:0:1a:f1b2:e] avec 32 octets de données :
Réponse de 2a01:6e00:10:410:0:1a:f1b2:e : temps=10 ms
Réponse de 2a01:6e00:10:410:0:1a:f1b2:e : temps=10 ms
Réponse de 2a01:6e00:10:410:0:1a:f1b2:e : temps=9 ms
Réponse de 2a01:6e00:10:410:0:1a:f1b2:e : temps=9 ms
Statistiques Ping pour 2a01:6e00:10:410:0:1a:f1b2:e:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 9ms, Maximum = 10ms, Moyenne = 9ms
>ping -4 lafibre.info
Envoi d’une requête 'ping' sur lafibre.info [80.67.167.77] avec 32 octets de données :
Réponse de 80.67.167.77 : octets=32 temps=10 ms TTL=56
Réponse de 80.67.167.77 : octets=32 temps=11 ms TTL=56
Réponse de 80.67.167.77 : octets=32 temps=11 ms TTL=56
Réponse de 80.67.167.77 : octets=32 temps=11 ms TTL=56
Statistiques Ping pour 80.67.167.77:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 10ms, Maximum = 11ms, Moyenne = 10ms
Edit : Il y a des infos dans "about:networking#dns mais je comprends pas bien la colonne "famille". Après avoir cliqué sur "Vider le cache DNS", je suis revenu en IPv6.
-
Pour savoir la connectivité du navigateur, j'utilise l'extension "IPvFoo".
Extrêmement pratique, je la recommande.
J'ai le même symptôme chez moi lorsque mon IPV6 déraille : tout se met à ramer, car tout essaye de se connecter en IPV6, n'y arrive pas (problème réseau), et bascule en IPV4.
C'est l'inconvénient de la double stack.
-
pour Chrome c'est HEv1 (Happy Eyeballs v1) qui est utilisé. A ma connaissance ils n'ont pas pour le moment l'intention d'utiliser HEv2 (rfc8305 origine Apple donc probablement utilisé dans leur produits).
une bonne explication des 2 versions: https://www.slideshare.net/apnic/happy-eyeballs-v2-rfc8305
Apres HE c'est bien pour l'utilisateur mais très mauvais pour les opérateurs de réseaux et serveurs si les chemins IPv6 qui dysfonctionnent ne sont pas remontés / signalés (notamment lors d'utilisation de tunnel et du blocage des icmpv6).
C'était très utile au début d'IPv6 pour pas trop impacter les utilisateurs mais a un moment il faudra ne plus s'en servir pour ne pas trop impacter la qualité d'IPv6 lui-même (trouver les problemes et les corriger pour améliorer les codes sources et les déploiements)
-
Je bascule vraiment très souvent en IPv4 sur lafibre.info. Je me demande comment je pourrais faire pour mieux comprendre la cause (vider le cache DNS suffit à me faire repasser en IPv6).
-
Le cas de la fibre.info est particulier car les 2 chemins sont distincts donc plus souvent sujets a des différences de latence dues aux routeurs intermédiaires.
il faudrait un 'fqdn ipv6 only' (https://www6.lafibre.info/ par exemple) pour voir si vraiment tu bascules pour une bonne raison ou pas.
-
D'apres le code source de Chrome ( https://chromium.googlesource.com/chromium/src/+/master/net/socket/transport_connect_job.h#65 )
il maintient 2 histogrammes globaux:
chrome://histograms/Net.DNS_Resolution_And_TCP_Connection_Latency2
et Net.TCP_Connection_Latency
mais je n'ai jamais creusé ces infos.
Chrome donne 300ms d'avance a IPv6 pour HE: https://source.chromium.org/chromium/chromium/src/+/master:net/socket/transport_connect_job.cc;l=73?q=kIPv6FallbackTimerInMs&sq=
-
il faudrait un 'fqdn ipv6 only' (https://www6.lafibre.info/ par exemple) pour voir si vraiment tu bascules pour une bonne raison ou pas.
Qu'est-ce qu'on appellerait une bonne raison ? Juste après une bascule en IPv4 le site est bien toujours accessible en IPv6 sur un autre navigateur ou en vidant le cache DNS de Firefox.
-
Qu'est-ce qu'on appellerait une bonne raison ? Juste après une bascule en IPv4 le site est bien toujours accessible en IPv6 sur un autre navigateur ou en vidant le cache DNS de Firefox.
justement pour voir si le probleme vient de FF ou pas.
si avec un 'fqdn ipv6 only' de lafibre.info ton expérience d'utilisation est bonne c'est que FF est trop sensible a ce niveau ou qu'il y a un souci dns quelque part ?
-
Tient nouveau soucis depuis quelques jours (et je me souviens qu'il était arrivé dans un contexte similaire aussi). Il y a quelques jours coupure internet pendant a peine 30 secondes (livebox 4 fibre) et depuis mon ordi n'a plus d'ipv6 ??? . Alors que les autres appareils ainsi que la box ont toujours une ipv6. Cela m'étais déjà arrivé après m’être déconnecté du réseau de la livebox manuellement. L'ipv6 de mon pc Windows 10 était revenue plus tard sans explications.
-
Parfois je constate que le forum "bloque".
C'était en IPv6, donc normalement en direct sur le serveur.
Firefox a basculé en IPv4 sur lafibre.info un peu plus tard, alors que ip.lafibre.info est bien en IPv6 par défaut.
J'étais en train de poster une réponse.
Voyant que ça bloquait, j'ai ouvert l'inspecteur de Firefox et j'ai rechargé.
La requête https://lafibre.info/tester-son-debit/mesure-de-debit-nouveau-projet/48/?action=post;last_msg=857822 a pris 12s, pour me retourner une page avec "Attention — une nouvelle réponse a été postée...", indiquant que la première était passée.
-
En regardant de plus près je me suis rendu compte que je perds quasi-systématiquement IPv6 sur lafibre.info quand je poste un message.
-
Idem, je bascule en "ipv4 prioritaire" mais seulement sur lafibre.info, pas sur ip.lafibre.info ni aucun autre site. (la connectivité ipv6 reste présente, mais en "secondaire")
-
J'ai toujours le problème, je me retrouve régulièrement en IPv4 sur lafibre.info. En pratique je ne sais pas si c'est réellement juste sur lafibre.info mais c'est facile à voir sur le forum.
-
j'ai le souci, mais je suis sur macOS...
-
j'ai le souci, mais je suis sur macOS...
Je crois qu'il y a deux problèmes distincts. Initialement il m'arrivait de perdre complètement IPv6 sur ma machine, j'ai l'impression que ce n'est plus le cas dernièrement. Maintenant je me rends compte que j'ai perdu IPv6 sur lafibre.info mais sur ip.lafibre.info je suis bien en IPv6 par exemple. Je pense que le problème n'est pas au même niveau.
-
tout pareil
-
Là je viens de rebasculer en IPv4 par exemple (Vivien doit pouvoir faire des stats en regardant les IP de mes messages).
Si je viens de vider le cache DNS dans "about:networking#dns" et je suis quasi-sûr que je vais bien être en IPv6 lorsque je vais poster ce message. Edit : Je confirme.
-
pareil je suis en v4
Et j'ai des pertes en v6 :
(https://pix.milkywan.fr/yupQJCvg.png)
-
Donc cela serait Adeli ?
ip.lafibre.info n'est pas chez Adeli.
Je vais le modifier pour tester la connectivité IPv4 / IPv6 vers plusieurs destinations.
-
Donc cela serait Adeli ?
Il semblerait. J'imagine qu'avec Happy Eyeballs il suffirait que la connexion IPv6 soit un peu dégradée pour que ça bascule vers IPv4.
-
Je suis encore en v4 là par exemple, alors que j'ai bien de l'ipv6 sans souci ailleurs.
-
Toujours pareil ici, d'après le plugin Firefox (SixOrNot) que j'ai installé, j'ai toujours la connectivité IPV6 sur lafibre.info, mais pas utilisée en priorité (alors que ip.lafibre.info et les autres sites ipv6 continuent à être en v6 par défaut).
-
Tu as une vieille version de Firefox ? J'ai l'impression que SixOrNot n'est plus disponible.
-
Non, mon Firefox est à jour, mais effectivement il semble que ce plugin ne soit plus disponible au téléchargement (le site de sa documentation est toujours en ligne par contre). Et le plugin marche toujours.
-
Je viens de trouver la raison en regardant le Github du projet : https://github.com/ashleybaldock/sixornot/issues/24
Yup. Mozilla de-listed it because of the dependency on knockout.js (which uses unsafe-eval). Needs a UI rewrite using React and I don't currently have time to do that sadly.
-
Aujourd'hui ip.lafibre.info n'est pas chez Adeli.
La nouvelle version testera IPv4 et IPv6 chez plusieurs opérateurs, c'est dans ma todo liste pour les prochaines semaines.
Il testera aussi les IPv6 se terminant par ":0" ce qui ne fonctionne pas systématiquement.