Hm, so because I am so eager to understand things I know have the task to explain #NeighborDiscoveryProtocol of #IPv6 tomorrow.
From what I understand, I can think of multicast of like topics in MQTT:
One sender and whoever is interested can read from it. New hosts are subscribed to it when they go online.
By setting certain flags in #ICMPv6 their are messages for routers and neighbors. One for request and a matching respond (called solicitation and advertisement).
Now I would love to have a #SysAdmin confirm my understanding.
Le site a 4 adresses IP à ce jour : deux à Paris (143.244.56.49, 185.93.2.248), une à Bruxelles (207.211.214.145), une à New-York (138.199.40.58). Pas d'#ipv6 :(. Poke @aeris (il s'est manifesté !) @bortzmeyer
Ik krijg op de 'Connection test' van https://internet.nl maar een score van 10% terwijl ik toch echt alles op #IPv6 first heb staan.
Mijn eerstgebruikte nameserver is die van @freedominternet mijn internetprovider: 2a10:3780:2:52:185:93:175:43
En als ik internet.nl opvraag krijg ik toch echt ook het IPv6 adres terug:
$ host internet.nl
internet.nl has address 62.204.66.10
internet.nl has IPv6 address 2a00:d00:ff:162:62:204:66:10
internet.nl mail is handled by 10 vmx02.prolocation.nl.
internet.nl mail is handled by 10 vmx01.prolocation.nl.
internet.nl mail is handled by 10 vmx03.prolocation.net.
Beim #Selfhosting der #Nextcloud steht mir gerade #IPv6 im Weg. Da es hier kein #DSL gibt, sind wir mit #Telekom#5g verbunden. Eine öffentliche IPv6 haben wir uns schon geklickt. Es gab aber noch nie Berührungspunkte damit. Herausgefunden haben wir schon, dass es sich um eine /64 IPv6 handelt. Wo und wie fängt man denn jetzt sinnvoll an? Als Router kommt eine Fritzbox 6850 zum Einsatz.
Zastanawiałem się ostatnio, dlaczego po 28 latach od wprowadzenia protokołu #IPv6, nadal tak mało dostawców internetu go oferuje.
No i dzisiaj dostałem olśnienia. Zgodnie z zasadą "Jak działa to nie ruszaj" - dopóki #internet się nie sypie, nikogo nie obchodzi i nie będzie obchodziło jakieś IPv6.
Tak sobie potem pomyślałem, że przecież #IANA (organizacja zajmująca się zarządzeniem adresami IP) mogłaby ogłosić protokoł #IPv4 jako przestarzały. No... ale tego nie zrobią. Dlaczego? Ponieważ trzaskają gigantyczną kasę na dzierżawie bloków IPv4.
Miliony sieciowców w firmach musiałoby się nauczyć IPv6, żeby poprawnie skonfigurować sieć, co generuje dodatkowe koszta. Pomijając już, że wiele z nich to samouki w Januszexach, którzy coś tam potrafią pogrzebać, żeby ostatecznie działało, ale to tyle.
Aktualnie mamy sytuację patową:
brakuje adresów publicznym; ISP przydzielają jeden adres wielu urządzeniom w różnych domach
Has someone here an 464xlat #CLAT daemon running under debian, more or less in production?
I'm looking for the best solution right now, especially with regard to packaging an automation. I'm not really convinced (yet) about clatd though. #ipv6
Currently, #BoxyBSD has #IPv6 networks in DE, CH, DJ and US (East). Which would you prefer and should one of these location get added?
VAE, AUS, JP, CA, PL, SG, ZA could easily be added.
Unfortunately, nothing near India. Trying to have a look for it.
#IPv6 rocks. Flawless physical migration with only a very minor downtime :-).
Thinking about networks as segregated network segments is just SO MUCH easier, this time around, I went #IPv6only and didn't even bother with setting up IPv4.
If you've ever looked at SSH server logs you know what I'm about to say: Any SSH server connected to the public Internet is getting bombarded by constant attempts to log in. Not just a few of them. A lot of them. Sometimes even dozens per second. And this problem is not going away; it is, in fact, getting worse. And attackers' behavior is changing.
The graph attached to this post shows the number of attempted SSH logins per day to one of @cloudlab s clusters over a four-year period. It peaks at about 3.4 million login attempts per day.
This is part of a study we did on our production system, using logs of more than 640 million login attempts, covering more than 1,500 hosts on our side and observing more than 840 thousand incoming IP addresses.
A paper presenting our analysis and a new, highly effective means to block SSH brute force attacks ("Where The Wild Things Are: Brute-Force SSH Attacks In The Wild And How To Stop Them") will be presented next week at #NSDI24 by @sachindhke . The full paper is at https://www.flux.utah.edu/paper/singh-nsdi24
@SoniEx2@cloudlab@sachindhke An excellent question that I can only speculate on right now, in part because our study only covers IPv4, and in part because I expect the landscape to change, but it's hard to predict exactly how.
In the short term, switching ssh and other services to #IPv6 only will likely reduce the brute force attacks you see by a lot. Our data suggests that attackers are hitting the IPv4 space at random, which is a perfectly good strategy for the relatively dense IPv4 space, but a terrible strategy for the gigantic IPv6 space. If I were an attacker doing brute force, I'd stick to the IPv4 space that's easy and has plenty of targets.
However, let's consider more sophisticated attackers, and/or a future world where we've moved entirely to IPv6. There are lots of things you can do to cut down the scanning space. Most IPv6 space is not even allocated, so you can just skip that. You can focus on specific prefixes used by large ISPs and cloud providers to increase your hit rate. You can use information about the way some devices use MAC addresses to generate part of their public address to target popular NIC and or IoT vendors. You can keep track of live IP addresses based on observed connections (eg. scan everyone who connects to your website.) You can try to enumerate DNS domains to look for targets (most DNS servers try to prevent this, but there are all kinds of attacks on DNS). You can share lists of the live addresses you find. And these are just off the top of my head, I'm sure people have come up with plenty more already, and will find plenty more in the future.
So, will we eventually reach a point where IPv6 scanning is as effective as IPv4 scanning is today? It seems unlikely, but scanning the entire IPv4 space in minutes seemed unlikely not too long ago. So in the long term, I wouldn't bet on security that depends on IPv6 being hard to scan. I would expect that we'll all want to keep up the same strategies of using keys, blocking attackers that we detect, etc.
One thing I would expect is for the patterns to change: right now acquiring a target is easy, so attacks that just try once and move on are common. On IPv6 - both now and in the future - I'd expect that the difficulty of finding targets means that once you find one, you're going to try a lot more usernames and passwords on it.
Le saviez-vous : Si votre instance est en dual stack mais que votre enregistrement DNS ne contient qu'enregistrement AAAA (ipv6), alors vous pouvez envoyer des toots à tout le monde mais ne pouvez recevoir que des toots d'instances en ipv6.
Vous vous en fichez mais je découvre qu'il y a un résolveur #DNS public en Inde (apparemment géré par le registre du .in) et il a une bonne adresse #IPv6 (et elle répond aux ICMP echo).
Comme quoi les adresses IPv6 ne sont pas forcément plus longues et plus dures à mémoriser que les adresses IPv4.