- Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.
News:
Welcome to Hurricane Electric's Tunnelbroker.net forums!
Recent posts
#1
General Questions & Suggestions / Re: Support for SVCB and HTTPS...
Last post by jailbird - November 18, 2024, 09:06:35 PMIt looks like the web UI understands these records, but it won't let you add them nor edit them.
It would be awesome if it did!
It would be awesome if it did!
#2
IPv6 on Routing Platforms / Problèmes d'interaction entre ...
Last post by farouq45 - October 15, 2024, 09:30:44 AMBonjour à tous,
Je travaille actuellement sur un réseau qui utilise IPv6 et plusieurs VLANs avec le Spanning Tree Protocol (STP) activé. Cependant, j'ai remarqué que lors de la convergence du STP, le Neighbor Discovery Protocol (NDP) en IPv6 semble être affecté, ce qui entraîne des retards dans la résolution des adresses IPv6.
Est-ce que quelqu'un a déjà rencontré des problèmes similaires où le STP interfère avec le bon fonctionnement d'IPv6 Neighbor Discovery ? Je me demande s'il y a des configurations spécifiques à appliquer pour éviter ce genre de conflit, ou si passer à RSTP ou MSTP pourrait résoudre le problème. Toute suggestion pour améliorer cette interaction serait appréciée.
Je travaille actuellement sur un réseau qui utilise IPv6 et plusieurs VLANs avec le Spanning Tree Protocol (STP) activé. Cependant, j'ai remarqué que lors de la convergence du STP, le Neighbor Discovery Protocol (NDP) en IPv6 semble être affecté, ce qui entraîne des retards dans la résolution des adresses IPv6.
Est-ce que quelqu'un a déjà rencontré des problèmes similaires où le STP interfère avec le bon fonctionnement d'IPv6 Neighbor Discovery ? Je me demande s'il y a des configurations spécifiques à appliquer pour éviter ce genre de conflit, ou si passer à RSTP ou MSTP pourrait résoudre le problème. Toute suggestion pour améliorer cette interaction serait appréciée.
#3
Questions & Answers / I'm getting a HTTP 500 error w...
Last post by noxtu - October 14, 2024, 04:30:54 AMI'm getting a HTTP 500 error when trying to create or edit tunnel.
https://tunnelbroker.net/tunnel_detail.php?tid=938787
https://tunnelbroker.net/tunnel_detail.php?tid=938787
#4
Questions & Answers / Re: Google forcing ReCAPTCHA o...
Last post by jonathanlee571 - October 12, 2024, 09:13:37 PMHello, I am also seeing this with Google, what is weird if I do the challenge it reroutes me to Google .hk or hong kong after. As soon as I turn off the HE tunnel it stops. Blocking AAAA for Google Netflix does fix it. Is there any other solution to this?
#5
General Discussion / Re: Reset Guru test
Last post by ranoca - October 11, 2024, 06:28:34 PMHello, I have the same problem, I can't check the records because the domain is on a hosting, did you manage to solve the problem?
#6
IPv6 on Routing Platforms / Re: Problème avec la sécurisat...
Last post by snarked - September 27, 2024, 12:07:59 PMThere really isn't any way to validate the content of the ND packet itself. If one already knew where his neighbor(s) connect(s), one wouldn't need the ND packet to begin with (and would populate the local route table manually).
I have not used "SEND." I don't know of any way to detect that a neighbor was hacked if the packets comprising the hack did not pass through my system or network. Furthermore, a neighbor could be passing bad routes learnt from its other neighbor(s), so it/they might not be hacked at all.
I simply don't see how the data could be validated. All one can validate is that a neighbor delivered the data.
I have not used "SEND." I don't know of any way to detect that a neighbor was hacked if the packets comprising the hack did not pass through my system or network. Furthermore, a neighbor could be passing bad routes learnt from its other neighbor(s), so it/they might not be hacked at all.
I simply don't see how the data could be validated. All one can validate is that a neighbor delivered the data.
#7
IPv6 on Routing Platforms / Re: Problème avec la sécurisat...
Last post by gabinlm - September 27, 2024, 11:26:14 AMThank you for your detailed response! Your explanation about the trusted FE80::/10 range and the use of TTL 255 to ensure a direct connection makes sense. However, my concern is more about a potential attack vector where a malicious device on the same link might insert false Neighbor Advertisements, which could lead to man-in-the-middle attacks or routing issues.
I understand that IPSec can be a solution for securing ND packets, but in practice, it seems challenging to implement and maintain, especially in large networks. Have you had any experience using Secure Neighbor Discovery (SEND) as an alternative, or do you know of any other lightweight methods to prevent these types of attacks?
I understand that IPSec can be a solution for securing ND packets, but in practice, it seems challenging to implement and maintain, especially in large networks. Have you had any experience using Secure Neighbor Discovery (SEND) as an alternative, or do you know of any other lightweight methods to prevent these types of attacks?
#8
IPv6 on Routing Platforms / Re: Problème avec la sécurisat...
Last post by snarked - September 26, 2024, 11:28:31 AMFrench isn't among my top languages, but as I understand your post, you are concerned about route spoofing. You should be able to trust that the ND packets themselves are authentic as they are required to be link-level, and thus the source address should always be within FE80::/10, the destination within FE80::/10 or FF02::/16 (FF02::1 or FF02::2 specified in the RFC's, except redirect), and a TTL of 255, which makes certain it is from a direct connection. ICMP packets can be IPSec wrapped if further security hardening is needed.
As for the content of the packet, you are correct in that if the neighbor is compromised, bad routes can be inserted. However, if your system cannot trust its immediate neighbors, it should not accept data from them. Does that satisfy your question?
As for the content of the packet, you are correct in that if the neighbor is compromised, bad routes can be inserted. However, if your system cannot trust its immediate neighbors, it should not accept data from them. Does that satisfy your question?
#9
IPv6 on Routing Platforms / Problème avec la sécurisation ...
Last post by gabinlm - September 25, 2024, 12:19:22 PMBonjour à tous,
Je travaille actuellement sur la mise en place d'un réseau avec un support complet d'IPv6, mais je rencontre des difficultés concernant la sécurisation du protocole Neighbor Discovery (ND). Je cherche à protéger le réseau contre les attaques comme le Neighbor Spoofing ou d'autres formes d'usurpation d'adresses, mais je ne suis pas sûr que mes configurations soient optimales.
J'ai lu sur certaines méthodes, comme l'utilisation de SEND (Secure Neighbor Discovery), mais la complexité de sa mise en œuvre me pose problème. Est-ce que vous avez déjà utilisé SEND ou d'autres approches pour sécuriser ND dans un environnement IPv6 ? Quels seraient les meilleurs outils ou configurations pour renforcer la sécurité ? J'ai trouvé un lien sur les solutions que j'ai appliquées en IPv4, qui pourrait être utile pour la transition vers IPv6 contre l'ARP spoofing.
Je travaille actuellement sur la mise en place d'un réseau avec un support complet d'IPv6, mais je rencontre des difficultés concernant la sécurisation du protocole Neighbor Discovery (ND). Je cherche à protéger le réseau contre les attaques comme le Neighbor Spoofing ou d'autres formes d'usurpation d'adresses, mais je ne suis pas sûr que mes configurations soient optimales.
J'ai lu sur certaines méthodes, comme l'utilisation de SEND (Secure Neighbor Discovery), mais la complexité de sa mise en œuvre me pose problème. Est-ce que vous avez déjà utilisé SEND ou d'autres approches pour sécuriser ND dans un environnement IPv6 ? Quels seraient les meilleurs outils ou configurations pour renforcer la sécurité ? J'ai trouvé un lien sur les solutions que j'ai appliquées en IPv4, qui pourrait être utile pour la transition vers IPv6 contre l'ARP spoofing.
#10
Questions & Answers / Re: Native IPv6 configuration ...
Last post by troz - September 24, 2024, 02:32:38 AMFC00::/8 is reserved for currently unspecified use. (basically, no one can agree on how to use it.) FD00::/8 is for non-public use. Technically, you can do whatever you want with it, but there are some "karen" RFC's telling you what to do. (in short, use random prefixes -- "global id" -- to minimize any collisions with other networks, should they ever need to be connected. if you've ever tried to merge to 10/8-using enterprise networks...) Should the IETF ever agree on how to manage "fc", cjdns will have to stop squatting on the space; shame on them for ever doing this in the first place.