Je ne savais pas que lafibre.info, c'était ton blog...

C'est plutôt twitter !

Je ne savais pas que lafibre.info, c'était ton blog...

Je confirme que ça ressemble beaucoup à un monologue, je ne vois pas beaucoup l'intérêt ici.
Ca n'est pas le principe d'un forum.
Mais bon...

Leon.

Note de Moi-même 2025-11-03 : Je me suis fais page d'accueil pour mon serveur au Canada chez OVHCloud : SRV.🇨🇦.◕‿◕.ST 89::1/64

$ dig -x 2607:5300:60:9389::1 @dns.google +short
srv.🇨🇦.◕‿◕.st.



### Microsoft Ignite - Configure Network Policies

Networking documentation > Network Policy Server (NPS) > Manage NPS > Configure Network Policies

Applies to: ✅ Windows Server 2025, 2022, 2019, 2016, ✅ Azure Local 2311.2 and later

---

My 🪟 Windows Server Configuration WinSrv IPv4 : « `10.106.0.1/10`» Tests « http://[2a01:cb1d:813:4a00:1ab3:136:0:1] » 😉

---

Note de Moi-même 2025-11-05 : Je me suis fais page d'accueil pour mon serveur en France chez Hostinger :  HST.🇫🇷.◕‿◕.ST 95::1/128

$ dig -x 2a02:4780:28:5295::1 @dns.google +short
hst.🇫🇷.◕‿◕.st.

Greets,
Romain.

Bonjour,

Je crois que depuis ce weekend ; Orange a changé quelque chose sur les Liveboxes.

J'avais/J'ai plusieurs IPv6 autorisées à entrer et sortir (je vous avez expliquer en Réponse 15 de cette discussion) - des adresses de voisinage ; sur mon bloc IPv6::/64 par default.

J'ai mon IPv6 principale avec laquelle j'arrive à entrer et sortir :

La machine fait office de routeur :

2a01:cb1d:813:4a00::1  prefixlen 64

J'ai une autre machine serveur connectée à ma "gateway" avec l'adresse IPv6 - Pour parler comme vous ; celle-ci représente "le bâtiment lab3" dans lequel j'ai 2 salles.

2a01:cb1d:813:4a00:1ab3::1  prefixlen 70

Mon "sysctl.conf" qui autorise l'Association du routeur (la Livebox) et les "transfert" entre les cartes - pour que sur les autres machines, on puisse re-suivre l'association des routeurs en Amont.

# Interface vers la Livebox
net.ipv6.conf.netbr0.forwarding = 1
net.ipv6.conf.netbr0.autoconf = 0
net.ipv6.conf.netbr0.accept_redirects = 1
net.ipv6.conf.netbr0.accept_ra = 2
net.ipv6.conf.netbr0.proxy_ndp = 0
net.ipv6.conf.netbr0.accept_source_route = 0

# Interface vers le serveur
net.ipv6.conf.srvbr0.forwarding = 1
net.ipv6.conf.srvbr0.autoconf = 0
net.ipv6.conf.srvbr0.accept_redirects = 1
net.ipv6.conf.srvbr0.accept_ra = 2
net.ipv6.conf.srvbr0.proxy_ndp = 1
net.ipv6.conf.srvbr0.accept_source_route = 0

On voit que sur l'interface "srvbr0" j'ai activé le NDP pour envoyer (grâce à RaDvD) à mon tour des Annonces de voisinage pour mes blocs "IPv6" que j'ai configuré sur mon serveur.

Je me suis fait un alias pour visualiser la configuration IPv6 de mes interfaces réseaux si cela peut vous servir : "~/.bash_aliases"

alias ipv6_options="sysctl net.ipv6.conf.default.forwarding && sysctl net.ipv6.conf.default.autoconf && sysctl net.ipv6.conf.default.accept_redirects && sysctl net.ipv6.conf.default.accept_ra && sysctl net.ipv6.conf.default.proxy_ndp && sysctl net.ipv6.conf.default.accept_source_route \
        && echo '' && sysctl net.ipv6.conf.all.forwarding && sysctl net.ipv6.conf.all.autoconf && sysctl net.ipv6.conf.all.accept_redirects && sysctl net.ipv6.conf.all.accept_ra && sysctl net.ipv6.conf.all.proxy_ndp && sysctl net.ipv6.conf.all.accept_source_route \
        && echo '' && sysctl net.ipv6.conf.netbr0.forwarding && sysctl net.ipv6.conf.netbr0.autoconf && sysctl net.ipv6.conf.netbr0.accept_redirects && sysctl net.ipv6.conf.netbr0.accept_ra && sysctl net.ipv6.conf.netbr0.proxy_ndp && sysctl net.ipv6.conf.netbr0.accept_source_route \
        && echo '' && sysctl net.ipv6.conf.lanbr0.forwarding && sysctl net.ipv6.conf.lanbr0.autoconf && sysctl net.ipv6.conf.lanbr0.accept_redirects && sysctl net.ipv6.conf.lanbr0.accept_ra && sysctl net.ipv6.conf.lanbr0.proxy_ndp && sysctl net.ipv6.conf.lanbr0.accept_source_route \
        && echo '' && sysctl net.ipv6.conf.srvbr0.forwarding && sysctl net.ipv6.conf.srvbr0.autoconf && sysctl net.ipv6.conf.srvbr0.accept_redirects && sysctl net.ipv6.conf.srvbr0.accept_ra && sysctl net.ipv6.conf.srvbr0.proxy_ndp && sysctl net.ipv6.conf.srvbr0.accept_source_route"

# ----------

Sur ma machine routeur "2a01:cb1d:813:4a00::1" ; j'ai donc ajouté depuis plusieurs mois ; l'adresse de mon serveur "2a01:cb1d:813:4a00:1ab3::1" au "neighbor proxy" pour que l'on puisse utiliser cette addresse IPv6 pour rentrer directement sur le serveur et en sortir par son adresse IPv6 (service Web, DNS).

root@gate-fr:~ # ip -6 neighbor show proxy
# Batiment "1ab3"
2a01:cb1d:813:4a00:1ab3::1 dev netbr0 proxy
# ---------------------------------------
# je vous ajoute cela pour que vous compreniez l'importance des IPv6 de voisinage.
# Batiment "1ab3" - salle "1"
2a01:cb1d:813:4a00:1ab3:116:0:1 dev netbr0 proxy
# Batiment "1ab3" - salle "2"
2a01:cb1d:813:4a00:1ab3:126:0:1 dev netbr0 proxy
[...]

Les professeurs connectés à leur ordinateur en "salle 1" sont sur un réseau ULA fc00::/7 et utilisent l'adresse IPv6 GUA "1ab3:116:0:1" pour naviguer sur Internet.
Les mômes connectés à leur ordinateur en "salle 2" sont sur un réseau ULA fc00::/7 et utilisent l'adresse IPv6 GUA "1ab3:126:0:1" pour naviguer sur Internet.

Cette configuration ; d'adresses voisines "neighbor proxy" ; Est la façon de faire pour utiliser plusieurs adresses IPv6 ; selon le protocole IPv6 et cela depuis plusieurs dizaine d'années.

# ----------

Test depuis le Canada du port 80 sur l'adresse principale de ma connexion Orange_FR - OK

root@srv-ca:~ # curl -I -L -6 http://[2a01:cb1d:813:4a00::1]
HTTP/1.1 200 OK
Date: Sun, 07 Dec 2025 19:55:50 GMT
Server: Apache/2.4.65 (Debian)
Last-Modified: Sun, 30 Nov 2025 03:47:07 GMT
ETag: "8b3b-644c7b771f7fb"
Accept-Ranges: bytes
Content-Length: 35643
Vary: Accept-Encoding
Content-Type: text/html

Test depuis le Canada du port 80 sur l'adresse du serveur de ma connexion Orange_FR - KO

root@srv-ca:~ # curl -I -L -6 http://[2a01:cb1d:813:4a00:1ab3::1]
curl: (7) Failed to connect to 2a01:cb1d:813:4a00:1ab3::1 port 80: Aucun chemin d'accès pour atteindre l'hôte cible

De mon Local ; j'arrive bien à Apache port 80 sur l'Ipv6 du serveur :

root@gate-fr:~ # curl -I -L -6 http://[2a01:cb1d:813:4a00:1ab3::1]
HTTP/1.1 200 OK
Date: Sun, 07 Dec 2025 19:56:32 GMT
Server: Apache
Strict-Transport-Security: max-age=31536000; includeSubDomains;
Upgrade: h2,h2c
Connection: Upgrade
Last-Modified: Sun, 30 Nov 2025 00:16:43 GMT
ETag: "c880-644c4c6fd979a"
Accept-Ranges: bytes
Content-Length: 51328
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8

# ----------

Sur un de mes serveur "SRV-CA" ; je vois bien l'adresse IPv6 de mon serveur AT home arriver et je vois le serveur Canadien répondre normalement.

root@srv-fr:~ # ping6 -n lab3w.fr -c2
PING lab3w.fr(2607:5300:60:9389::1) 56 data bytes

--- lab3w.fr ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1034ms

root@srv-ca:~ # tcpdump -s0 -n 'icmp6 and (ip6[40+0]&0xFE == 128)' -i vmbr0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), capture size 262144 bytes

15:03:32.089483 IP6 2a01:cb1d:813:4a00:1ab3::1 > 2607:5300:60:9389::1: ICMP6, echo request, seq 1, length 64
15:03:32.089520 IP6 2607:5300:60:9389::1 > 2a01:cb1d:813:4a00:1ab3::1: ICMP6, echo reply, seq 1, length 64
15:03:33.142791 IP6 2a01:cb1d:813:4a00:1ab3::1 > 2607:5300:60:9389::1: ICMP6, echo request, seq 2, length 64
15:03:33.142837 IP6 2607:5300:60:9389::1 > 2a01:cb1d:813:4a00:1ab3::1: ICMP6, echo reply, seq 2, length 64

Sur ma passerelle - Aucun reply n'arrive.

root@gate-fr:~ # tcpdump -s0 -n 'icmp6 and (ip6[40+0]&0xFE == 128)' -i netbr0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on netbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

21:03:32.037767 IP6 2a01:cb1d:813:4a00:1ab3::1 > 2607:5300:60:9389::1: ICMP6, echo request, id 37225, seq 1, length 64
21:03:33.091202 IP6 2a01:cb1d:813:4a00:1ab3::1 > 2607:5300:60:9389::1: ICMP6, echo request, id 37225, seq 2, length 64

# RienÀvoir
21:03:59.461815 IP6 fe80::c2d7:aaff:fec0:f839 > ff02::1: ICMP6, echo request, id 823, seq 0, length 64
21:03:59.461926 IP6 fe80::7484:78ff:fee5:41f1 > fe80::c2d7:aaff:fec0:f839: ICMP6, echo reply, id 823, seq 0, length 64

RienÀvoir -> fe80::c2d7:aaff:fec0:f839 est la LLU de ma Livebox
RienÀvoir -> fe80::7484:78ff:fee5:41f1 est la LLU de mon routeur "gate-fr"
RienÀvoir -> On dirait que la Livebox me "request" (pour chercher toutes les "nodes") et que la carte connectée à la Livebox "reply" avec son adresse LLU ? Mais PAS l'adresse d'Internet (d'un, du serveur interrogé).
RienÀvoir -> N'importe quoi.

Sur mon serveur - Aucun reply n'arrive.

root@srv-fr:~ # tcpdump -s0 -n 'icmp6 and (ip6[40+0]&0xFE == 128)' -i gatebr0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on gatebr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

21:03:32.035662 IP6 2a01:cb1d:813:4a00:1ab3::1 > 2607:5300:60:9389::1: ICMP6, echo request, id 37225, seq 1, length 64
21:03:33.089082 IP6 2a01:cb1d:813:4a00:1ab3::1 > 2607:5300:60:9389::1: ICMP6, echo request, id 37225, seq 2, length 64

Que s'est-il passé ?!

Avez-vous des infos ; parce que là; on ne peut plus utiliser les adresses IPv6 de notre bloc.

J'ai touché mes firewalls dernièrement mais je ne crois pas que cela soit de ma faute ; d'une erreur dans ma configuration sur mon "firewall".

Bonne soirée.

Cordialement,
Romain (O.Romain.Jaillet-ramey)

ZW3B’s LAB3W : The Web’s Laboratory ; Engineering of the Internet.
Founder ZW3B.FR | TV | EU | COM | NET | BLOG | APP and IP❤10.ws and more.

# ----

Le traceroute depuis le Canada jusqu'à l'adresse IPv6 "gate-fr" par default - celle qui est connecté à la livebox :

root@srv-ca:~ # traceroute 2a01:cb1d:813:4a00::1
traceroute to 2a01:cb1d:813:4a00::1 (2a01:cb1d:813:4a00::1), 30 hops max, 80 byte packets
 1  ovh.ip❤10.ws (2607:5300:60:93ff:ff:ff:ff:fd)  0.624 ms  0.686 ms  0.745 ms
 2  2001:41d0:0:50::2:15e (2001:41d0:0:50::2:15e)  0.765 ms 2001:41d0:0:50::2:162 (2001:41d0:0:50::2:162)  0.872 ms  0.989 ms
 3  2001:41d0:0:50::6:84c (2001:41d0:0:50::6:84c)  0.158 ms 2001:41d0:0:50::6:95e (2001:41d0:0:50::6:95e)  0.284 ms  0.317 ms
 4  * * *
 5  ymq-mtl3-sbb1-8k.qc.ca (2607:5300::2562)  2.986 ms ymq-mtl3-sbb2-8k.qc.ca (2607:5300::2564)  4.022 ms ymq-mtl3-sbb1-8k.qc.ca (2607:5300::2562)  3.002 ms
 6  2001:41d0::2689 (2001:41d0::2689)  3.206 ms be301.ymq-mtl3-pb1-8k.qc.ca (2001:41d0::2693)  3.186 ms be300.ymq-mtl3-pb2-8k.qc.ca (2001:41d0::2691)  4.180 ms
 7  * 2001:550:2:6::3e (2001:550:2:6::3e)  1.759 ms *
 8  * 2001:438:ffff::407d:1575 (2001:438:ffff::407d:1575)  14.047 ms  14.127 ms
 9  zayo-orange.ter1.iad10.us.zip.zayo.com (2001:438:ffff::407e:31e)  100.000 ms 2001:688:0:4::1f1 (2001:688:0:4::1f1)  231.988 ms zayo-orange.ter1.iad10.us.zip.zayo.com (2001:438:ffff::407e:31e)  99.990 ms
10  * * *
11  port-channel8073.ccr91.dca04.atlas.cogentco.com (2001:550:0:1000::9a36:aa45)  13.673 ms port-channel4188.ccr92.dca04.atlas.cogentco.com (2001:550:0:1000::9a36:1e79)  13.986 ms  14.014 ms
12  * * *
13  2a01:cb1d:813:4a00::1 (2a01:cb1d:813:4a00::1)  103.333 ms  108.671 ms *

Le traceroute depuis le Canada jusqu'à l'adresse IPv6 "srv-fr" du serveur - celle qui est connecté à la "gate-fr":

root@srv-ca:~ # traceroute 2a01:cb1d:813:4a00:1ab3::1
traceroute to 2a01:cb1d:813:4a00:1ab3::1 (2a01:cb1d:813:4a00:1ab3::1), 30 hops max, 80 byte packets
 1  ovh.ipv10.net (2607:5300:60:93ff:ff:ff:ff:fe)  0.695 ms  0.908 ms ovh.ip❤10.ws (2607:5300:60:93ff:ff:ff:ff:fd)  0.666 ms
 2  2001:41d0:0:50::2:15c (2001:41d0:0:50::2:15c)  0.708 ms  0.823 ms 2001:41d0:0:50::2:162 (2001:41d0:0:50::2:162)  0.702 ms
 3  2001:41d0:0:50::6:95e (2001:41d0:0:50::6:95e)  0.153 ms 2001:41d0:0:50::6:958 (2001:41d0:0:50::6:958)  0.117 ms 2001:41d0:0:50::6:856 (2001:41d0:0:50::6:856)  0.147 ms
 4  * * *
 5  ymq-mtl3-sbb2-8k.qc.ca (2607:5300::2564)  2.365 ms  2.397 ms  2.383 ms
 6  be300.ymq-mtl3-pb2-8k.qc.ca (2001:41d0::2691)  2.970 ms be301.ymq-mtl3-pb2-8k.qc.ca (2001:41d0::2695)  2.938 ms be301.ymq-mtl3-pb1-8k.qc.ca (2001:41d0::2693)  2.838 ms
 7  * motl-b3-link.ip.twelve99.net (2001:2035:0:2cd3::1)  1.225 ms 2001:438:8000::805 (2001:438:8000::805)  1.074 ms
 8  * * *
 9  be2088.ccr21.alb02.atlas.cogentco.com (2001:550:0:1000::9a36:2b12)  9.361 ms * *
10  2001:688:0:2:1::397 (2001:688:0:2:1::397)  87.418 ms * *
11  2a01:cfc4:0:2100::2 (2a01:cfc4:0:2100::2)  100.584 ms port-channel4188.ccr92.dca04.atlas.cogentco.com (2001:550:0:1000::9a36:1e79)  14.040 ms 2a01:cfc4:0:2100::2 (2a01:cfc4:0:2100::2)  100.556 ms
12  * * *
13  * 2001:550:3::206 (2001:550:3::206)  94.544 ms *
14  * * *
15  2a01:cb1d:813:4a00:c2d7:aaff:fec0:f839 (2a01:cb1d:813:4a00:c2d7:aaff:fec0:f839)  106.306 ms  106.929 ms 2a01:cfc4:0:2100::2 (2a01:cfc4:0:2100::2)  100.939 ms
16  * * *
17  * * *
18  2a01cb08a00402110193025300750144.ipv6.abo.wanadoo.fr (2a01:cb08:a004:211:193:253:75:144)  107.684 ms * *
19  2a01:cb1d:813:4a00:c2d7:aaff:fec0:f839 (2a01:cb1d:813:4a00:c2d7:aaff:fec0:f839)  107.777 ms  106.339 ms  106.721 ms
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * 2a01:cb1d:813:4a00:c2d7:aaff:fec0:f839 (2a01:cb1d:813:4a00:c2d7:aaff:fec0:f839)  3107.612 ms !H  3106.838 ms !H

On s’aperçoit bien que la requête BLOCK sur la Livebox : "2a01:cb1d:813:4a00:c2d7:aaff:fec0:f839"  après le saut 19.

# ----

En passant ; çà fait plusieurs mois qu'il y a un BUG dans l'interface de Livebox > Firewall

Sur l'image 4 : "Screenshot 2025-12-07 at 22-09-16 Réseau - Livebox Orange.png" j'ai configuré les ports UDP et TCP de 1-65535 pour les équipements IPv6 vers la machine DMZ - Et sur l'interface je vois : Port UDP/TCP - Port "1" - Portant tout fonctionnait (accès aux ports sur différentes machines IPv6) ET on ne voit pas le nom de l'équipement (obligatoire pour ajouter un/des régles) ET bien sûr comme tout le mode sait ; les ping/pong (protocole ICMPv6) ne fonctionnent pas sur les adresses IPv6 ; mise à part celle de la Livebox).

Note de Moi-même d'ajourd'hui minuit 37 ; j'ai remis les règles comme elles doivent être dans le Firewall IPv6 ; mais çà ne rentre toujours plus (image 5).

# ----

Il y bien un RFC 9685  de l'Internet Engineering Task Force (IETF) qui date de Novembre 2024 avec des améliorations mais çà ne concerne pas exactement ce mécanisme sur le protocole NDP normal - çà concerne les RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks.

RFC 9685 : Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses

Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
Request for Comments: 9685                                 November 2024
Updates: 4861, 6550, 6553, 8505, 9010                                   
Category: Standards Track                                               
ISSN: 2070-1721

RFC 4861 : Neighbor Discovery for IP version 6 (IPv6)
RFC 6550 : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
RFC 6553 : The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
RFC 8505 : Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
RFC 9010 : Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves

Bonjour,

J'ai récupéré ma connexion Fibre Orange depuis (hier -- en fait) le 03/02/2026 at 17h29 - Je viens de m'en apercevoir aujourd'hui.

La coupure s'est produite le 08/01/2026 et devait être rétablie le 25/02/2026 (photo en bas) ; les supers techniciens du support téléphonique m'ont dit qu'il se pourrait ; qu'il y ait d'autres coupures !oL ^^

J'ai vu la nouvelle option "Réseau > CGN" vous avez ouvert un sujet ici : https://lafibre.info/ipv6/livebox-orange-le-regle-cgn-dual-stack/" -- personnellement je ne souhaite pas partager mon IPv4. (Enfin ; à priori en 7 décembre 2025 il y avait déjà l'onglet CGN (CF le screenshot commentaire du dessus, réponse #54...).

Je viens de m’apercevoir que j'arrive à pinguer depuis l'extérieur mes IPv6 - Avant ; j'arrivais au services "SSH" / "WEB" sur les ardesses IPv6 ; mais nous n'arrivions pas à les "pinguer" de l'extérieur ; maintenant OUI.

Pour vous donner un exemple ; ces adresses IPv6 répondent au ping de l'extérieur :

* Ma gateway (192.168.1.254) : ping 2a01:cb1d:813:4a00::1
* Mon serveur : ping 2a01:cb1d:813:4a00:1ab3::1
* Un Container : ping 2a01:cb1d:813:4a00:1ab3:116:42:10

C'est bien mieux ; c'était très important que les IPv6 répondent au ping.

Les services "WEB" par exemple fonctionnent toujours :

* Ma gateway (192.168.1.254) : http://[2a01:cb1d:813:4a00::1]/
* Mon serveur : http://[2a01:cb1d:813:4a00:1ab3::1]/
* Un Container : http://[2a01:cb1d:813:4a00:1ab3:116:42:10]/

mer. févr. 04 16:06:03 ⛔🔜 root@vps-de:~ # traceroute6 2a01:cb1d:813:4a00:1ab3:126:42:10 -I
traceroute to 2a01:cb1d:813:4a00:1ab3:126:42:10 (2a01:cb1d:813:4a00:1ab3:126:42:10), 30 hops max, 80 byte packets
 1  2001:41d0:701:1100::1 (2001:41d0:701:1100::1)  0.168 ms  0.124 ms  0.109 ms
 2  fd00::ffe (fd00::ffe)  0.094 ms  0.201 ms  0.188 ms
 3  2001:41d0:0:1:3::4dff (2001:41d0:0:1:3::4dff)  0.273 ms  0.313 ms  0.305 ms
 4  2001:41d0:0:1:3::4b7c (2001:41d0:0:1:3::4b7c)  0.347 ms  0.405 ms  0.393 ms
 5  2001:41d0:0:1:3::548a (2001:41d0:0:1:3::548a)  0.288 ms  0.266 ms  0.260 ms
 6  * * *
 7  fdff:f003:18::48 (fdff:f003:18::48)  2.872 ms  2.862 ms  3.190 ms
 8  2001:41d0:20a:600::2d (2001:41d0:20a:600::2d)  1.833 ms  1.820 ms  1.853 ms
 9  * * *
10  * * *
11  2a01:cfc4:0:2000::2 (2a01:cfc4:0:2000::2)  17.703 ms  17.699 ms  17.667 ms
12  * * *
13  * * *
14  2a01cb08a00402110193025300750144.ipv6.abo.wanadoo.fr (2a01:cb08:a004:211:193:253:75:144)  19.917 ms  19.948 ms  19.932 ms
15  2a01:cb1d:813:4a00:c2d7:aaff:fec0:f839 (2a01:cb1d:813:4a00:c2d7:aaff:fec0:f839)  23.141 ms  23.984 ms  24.107 ms
16  * * *
17  2a01:cb1d:813:4a00:1ab3::1 (2a01:cb1d:813:4a00:1ab3::1)  119.759 ms  120.539 ms  120.634 ms
18  2a01:cb1d:813:4a00:1ab3:126:0:1 (2a01:cb1d:813:4a00:1ab3:126:0:1)  120.426 ms  121.281 ms  122.537 ms
19  2a01:cb1d:813:4a00:1ab3:126:42:10 (2a01:cb1d:813:4a00:1ab3:126:42:10)  101.833 ms * *

En passant (bien mieux qu'avec le téléphone) ; j'avais une Airbox Orange de 2020 (suite à la tempête Alex dans les Alpes-Maritimes) ; j'ai mis la SIM de mon téléphone, d'un autre FAI (Free.fr en l’occurrence) dedans et j'ai réussis à avoir le réseau... à 40MS stable pour 120MS/1500MS non stable avec le téléphone.

Exemple tuto : https://communaute.orange.fr/t5/airbox-et-tablette/Utilisation-Airbox-4G-E5573-avec-carte-SIM-d-un-autre-op%C3%A9rateur/td-p/1454344

Sur-ce ; bonne journée.

Romain.

---

Note à 16h13

Sinon ; je n'arrive pas en pinguer et/ou naviguer en IPv6 - très louche (et pourtant comme je le disais plus haut; j'arrive maintenant à pinguer vers mes IPv6 interne depuis l'extérieur (Internet).

Note à 17h09

J'arrive à sortir par les adresses IPv6 Neighbor (voisines) mais pas par ma gateway - celle-ci ("2a01:cb1d:813:4a00::1") le routeur principal ; qui (doit faire) fait sortir tous les postes protégés par le NAT v6 - mes IPv6 ULA "fc00::/7" - ceux qui ne sont pas des serveurs (et qui n'ont (donc) pas besoin de GUA (d'adresse "public" pour pouvoir y entrer) - çà doit être à cause d'une erreur dans MA configuration firewall..

Ma configuration sur la "gateway" pour les IPv6 voisines autorisées EN entrée :

mer. févr. 04 17:08:53 ⛔🔜 root@gate:~ # ip -6 neighbor show proxy
2a01:cb1d:813:4a00:1ab3::1 dev netbr0 proxy
2a01:cb1d:813:4a00:1ab3:126:42:10 dev netbr0 proxy
2a01:cb1d:813:4a00:1ab3:116:42:10 dev netbr0 proxy

mer. févr. 04 17:19:16 ⛔🔜 root@gate:~ # ip -6 r s
2a01:cb1d:813:4a00:1ab3::/80 dev srvbr0 proto kernel metric 256 expires 86395sec pref medium
2a01:cb1d:813:4a00::/64 dev netbr0 proto kernel metric 256 pref medium
fc01::10:106:0:250/124 dev srvbr0 proto kernel metric 256 pref medium
fc01::10:0:0:0/80 via fc01::10:106:0:252 dev srvbr0 metric 1024 pref medium
fc01::172:16:0:0/112 dev lanbr0 proto kernel metric 256 pref medium
fe80::/64 dev netbr0 proto kernel metric 256 pref medium
fe80::/64 dev lanbr0 proto kernel metric 256 pref medium
fe80::/64 dev srvbr0 proto kernel metric 256 pref medium
fe80::/64 dev usbbr0 proto kernel metric 256 linkdown pref medium
fec1::/16 dev netbr0 proto kernel metric 256 pref medium
default via fe80::c2d7:aaff:fec0:f839 dev netbr0 proto ra metric 1024 expires 585sec hoplimit 64 pref high


Note à 17h45

TOUT FONCTIONNE NORMALEMENT -- Et en plus on a la réponse au ping6 sur les adresses IPv6 interne. Merci à Orange_FR ; (bientôt, j'espère ;-) on aura le rDNS (reverse DNS) pour pouvoir configurer des noms (sur un (le nôtre) nom de domaine) pour nos adresses IPv6 dans un serveur DNS (comme Named/Bind9) en service actif sur une IP de notre bloc IPv6 Orange_FR), ce serait classe de pouvoir configurer sois même çà.

Bon courage. Merci encore.

j'ai trouvé ; j'ai l'impression que çà à changer -- il faut activé OBLIGATOIREMENT (même sur la carte ethernet connectée à la LiveBox en DMZ) ; une IPv6 NEIGHBOR (voisine). Enfin, non, Oops, j'ai, j'avais passé mon adresse "::1" en "deprecated (obsolète)" pour pas quelle puisse sortir ^^ celle-ci : "2a01:cb1d:813:4a00::1"

Exemple je souhaite avoir l'adresse principale "::1" disponible en entrée ; mais je ne souhaite pas sortir avec ;-)

mer. févr. 04 17:45:18 ⛔🔜 root@gate:~ # ip -6 address add 2a01:cb1d:813:4a00::1/64 dev netbr0
mer. févr. 04 17:45:20 ⛔🔜 root@gate:~ # ip -6 address change 2a01:cb1d:813:4a00::1/64 dev netbr0 preferred_lft 0

Exemple je souhaite sortir avec l'adresse "beef -- cafe" pour toutes les machines "hors serveurs" derrière le NAT v6 - mon poste : "fc01::172:16:0:142"

mer. févr. 04 17:45:39 ⛔🔜 root@gate:~ # ip -6 address add 2a01:cb1d:813:4a00:bee:eeff:ca:feee/104 dev netbr0
mer. févr. 04 17:45:42 ⛔🔜 root@gate:~ # ip -6 neighbor add proxy 2a01:cb1d:813:4a00:bee:eeff:ca:feee dev netbr0

Ma table NAT v6 :

mer. févr. 04 17:48:49 ⛔🔜 root@gate:~ # ip6tables -L -vn -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  0    --  *      netbr0  fc01::172:16:0:1    !fc00::/7
    0     0 MASQUERADE  0    --  *      netbr0  fc01::172:16:0:140  !fc00::/7
 2212  199K MASQUERADE  0    --  *      netbr0  fc01::172:16:0:142  !fc00::/7
    0     0 MASQUERADE  0    --  *      netbr0  fc01::172:16:0:252  !fc00::/7
    0     0 MASQUERADE  0    --  *      netbr0  fc01::172:16:0:2    !fc00::/7
    0     0 MASQUERADE  0    --  *      netbr0  fc01::10:106:0:252  !fc00::/7
    0     0 MASQUERADE  0    --  *      netbr0  fc01::10:126:0:1    !fc00::/7
    0     0 MASQUERADE  0    --  *      netbr0  fc01::10:136:0:1    !fc00::/7
    0     0 MASQUERADE  0    --  *      netbr0  fd10:6:42::/64      !fc00::/7
    0     0 MASQUERADE  0    --  *      netbr0  fd74:6:42::/64      !fc00::/7

Pour supplément d'informations sur la table NAT v6 ci-dessus :
Les adresses IPv6 ULA sont toutes NATée d'Internet par la carte ethernet "NETBR0" SAUF "!" à destination du/des réseaux locaux "fc00::/7".

Mes IPv6 pour la carte ethernet connectée à la Livebox 5 :

mer. févr. 04 17:48:56 ⛔🔜 root@gate:~ # grc ip -6 address show dev netbr0
7: netbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet6 2a01:cb1d:813:4a00:bee:eeff:ca:feee/104 scope global
       valid_lft forever preferred_lft forever
    inet6 2a01:cb1d:813:4a00::1/64 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fec1::1/16 scope site
       valid_lft forever preferred_lft forever
    inet6 fe80::7484:78ff:fee5:41f1/64 scope link
       valid_lft forever preferred_lft forever

---

Et, puis Extra-ordinaire : NO RESPONSE / ONE.ONE.ONE.ONE

C:\Users\ORJ>ping -t 147.79.115.130

Envoi d’une requête 'Ping'  147.79.115.130 avec 32 octets de données :
Réponse de 147.79.115.130 : octets=32 temps=17 ms TTL=49
Réponse de 147.79.115.130 : octets=32 temps=16 ms TTL=49
Réponse de 147.79.115.130 : octets=32 temps=17 ms TTL=49
Réponse de 147.79.115.130 : octets=32 temps=16 ms TTL=49

Statistiques Ping pour 147.79.115.130:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 16ms, Maximum = 17ms, Moyenne = 16ms

SEULEMENT CÀ QUI BUG :

C:\Users\ORJ>ping -t 1.1.1.1

Envoi d’une requête 'Ping'  1.1.1.1 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 1.1.1.1:
    Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),

C:\Users\ORJ>ping -t 8.8.8.8

Envoi d’une requête 'Ping'  8.8.8.8 avec 32 octets de données :
Réponse de 8.8.8.8 : octets=32 temps=6 ms TTL=116
Réponse de 8.8.8.8 : octets=32 temps=6 ms TTL=116
Réponse de 8.8.8.8 : octets=32 temps=5 ms TTL=116
Réponse de 8.8.8.8 : octets=32 temps=6 ms TTL=116
Réponse de 8.8.8.8 : octets=32 temps=6 ms TTL=116

Statistiques Ping pour 8.8.8.8:
    Paquets : envoyés = 5, reçus = 5, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 5ms, Maximum = 6ms, Moyenne = 5ms

---

@LAB3W/O.Romain.Jaillet-ramey : +33 616****65
Freelance | Consultant LAMP (W3C.Master : Analyste.SSI/Dev.OpS)
ZW3B’s LAB3W : The Web’s Laboratory ; Engineering of the Internet.