[swinog] Re: 15% IPv6 drop in Switzerland
Nico Schottelius writes: > Salut everyone, > on this sunny Sunday, is anyone else wondering why we had a drop of > about 15% points from 2021 to 2022 of detected IPv6 usage? > I am referring to https://stats.labs.apnic.net/ipv6/CH which shows it > quite impressive. My guess would be that this is because in 2022, people spend relatively more time in the office/at schools/universities/traveling compared to 2021, and less time at home. And in Switzerland, IPv6 connectivity is still heavily biased to home users. Enterprises generally don't care, universities have some IPv6 but have a hard time rolling it out campus-wide, mobile carriers in Switzerland - unlike some other countries - haven't rolled out IPv6 on a large scale yet. (Anybody knows what's cooking in that department? Will some IPv6 come with 5G or do we have to wait for 6G? ;-) But that's really just a guess! > Is this due to UPC/Sunrise merger? It seems lise AS6730 "lost" a lot of > IPv6 traffic since end of May 2021: > https://stats.labs.apnic.net/ipv6/AS6730?c=CH=1=1=30=1 Would be interesting to overlay these graphs with data that shows mobility or other effects of anti-COVID-19 measures to corroborate or refute my hypothesis. > Best regards and enjoy your Sunday, > Nico > p.s.: This drop finally places Switzerland BEHIND Austria, which > historically lagged behind Switzerland in terms of IPv6 traffic for > many, many years. Congratulations, Austria! Cheers, -- Simon. ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] NEW: Matrix group! Let 1000 flowers bloom [was: Re: Telegram group]
jma writes:
> I usually remain silent and read interesting threads but on this
> topic I would like to express a few things.
Sincere thanks from me for your contribution.
> I'm part of those to conceive Internet concepts such as distributed
> and federated protocols as the core values of the system. [...]
For what it's worth: I violently agree with your analysis and your
values/preferences (mostly). And certainly that such values matter.
> I won't argue for a specific project or protocol, but I would like to
> express that I wish people favor interop, decentralized, and help
> supporting such Internet strengh.
Well said. So in the spirit of experimentation ("just do it"), I have
created a group on Matrix:
#swinog:swinot.ch
https://matrix.to/#/!emivqjAwXhILUrtwFM:swinot.ch?via=swinot.ch=matrix.org
I also started a small VM and installed a Matrix "homeserver" and Web UI
on it. For now it's running under
matrix.swinot.ch (server)
https://riot.swinot.ch (Web UI, no good way to get accounts yet)
Sorry for the stupid domain name! I'll happily move everything to
swinog.ch (and save a few Francs by not renewing the domain name :-)
Didn't want to bother the swinog.ch DNS admins over the weekend...
Further reading for background/motivation:
https://swinot.ch/post-irc/
--
Simon.
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Telegram group
Ralph Krämer writes: > why telegram and not signal or threema? Why not all! And fivema and sixma as well!! Seriously, what was wrong with irc.swinog.ch? Is IRC considered a boomer thing that millenials won't touch? Just curious - I'm happy to follow everyone everywhere, but not everybody does, and I worry about fragmenting the community. Cheers, -- Simon. > - Am 11. Feb 2020 um 17:46 schrieb Massimiliano Stucchi m...@stucchi.ch: >> Hi everyone, >> >> I created a telegram group for Swinog. It is meant to be a place to >> have discussions that are more informal than what you could have on the >> mailing list or simply for something more interactive. >> >> The link to join is https://t.me/SWINOG >> >> I've created a similar group for ITNOG almost two years ago and it >> proved to be a good initiative, now with about 450 members and with >> daily discussion on different topics. Maybe we can make it happen also >> for Swinog. >> >> Keep in mind this is just a personal initiative and not an official one >> from Swinog. If it works out and it's positive, we'll see if we can >> make it more official. >> >> If you have any question or comment, please feel free to approach me. >> >> Ciao! >> -- >> Massimiliano Stucchi >> MS16801-RIPE >> Twitter/Telegram: @stucchimax >> >> >> >> >> >> ___ >> swinog mailing list >> swinog@lists.swinog.ch >> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] AS3303 overlapping prefix
Andy Grawehr writes: when i check our prefix 193.105.5.0/24 on www.ris.ripe.net i get an overlapping prefix: 192.0.0.0/3 announced by AS3303. Google AS3303 semi-default. AS3303 announces this /3 to their customers and possibly use it internally. It's part of an elaborate mechanism to trade off routing table size against path quality. Some ISPs (including ourselves) even announce 0.0.0.0/0 to customers. Note how this also overlaps with your 193.105.5.0/24. Best regards, -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] BÜPF...again ; )
Privacy is something, only old people seem to care about. I hear that a lot, but it doesn't seem to hold up to scientific scrutiny: http://www.readwriteweb.com/archives/study_youth_not_only_care_about_facebook_privacy_t.php But just continue to claim this; it makes old people feel better. -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Urgent request to clear DNS cache for cablecom.net
Jerome Tissieres writes:
From behind SWITCH; www.cablecom.ch is not known and www.cablecom.net
goes to a godaddy sponsor page.
Some of our anycast nameservers had cached the temporary delegation and
NXDOMAIN responses for ns{1,2}.cablecom.net. Unfortunately we only
heard about it this morning. Caches have been cleared. But note that
universities usually operate their own DNS caches rather than using ours.
--
Simon.
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] IPv6 deployment questionnaire for ISPs
As part of the work of the IETF v6ops WG, Brian Carpenter is soliciting input from ISPs on IPv6 deployment: http://www.cs.auckland.ac.nz/~brian/ISP-v6-QQ.html If you have a couple of minutes, please consider filling out this ASCII questionnaire and mailing it to Brian. It would be great if you could do this by next Friday (5 February), so that he can integrate your input before the next IETF meeting. Note that the questionnaire addresses both ISPs who already offer IPv6 services and those who don't. Thanks best regards, -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] SWITCH Sourceforge mirror available again
Over the past couple of weeks, you might have noticed that for Sourceforge downloads, Lausanne, Switzerland (SWITCH) (switch.dl.sourceforge.net) was no longer listed as a mirror option. The reason was that the disk array of the server had become too small to hold the entire Sourceforge mirror dataset (because of all the binary stuff I guess - this thing should be called .iso-forge :-). We have now replaced it with a new server with larger disks, so now it should be fully included in the Sourceforge download mirror set. Note that, like mirror.switch.ch and many other of our services, this is reachable over IPv6 in addition to IPv4. Now go and test that thing :-) -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Bluewin SMTP Policy
Jeroen Massar writes: Just display the captcha from the signup on $pornsite, a person will fill it in for you, captcha bypassed. If it is interesting and cheap for then to abuse it, they will. The approach is mentioned in an excellent talk by Louis von Ahn, who invented the CAPTCHA: http://video.google.com/videoplay?docid=-8246463980976635143q=Google+techtalks -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Rant about DNS and TCP [was: Re: [swinog] Has Bluewin a DNS Problem]
Claudio Jeker writes: Until recently only AXFR was using tcp, If you look at the original DNS specs, i.e. RFC 1035, RFC 1123, etc, you will find that the protocol always specified that any DNS queries can be performed over TCP. In particular, this is the normal fallback method when a query over UDP results in a truncated (TC) response. Actually, in the olden days there were even resolver implementations that *only* supported TCP for DNS queries, cf. http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg01855.html (I'm not saying this was a good idea :-) Then people stopped listening to Jon Postel's (may he rest in peace) advice to be liberal in what you expect, conservative in what you send. Instead, concerns of security and short-term optimization and punishing people with stupid (= unexpected) configurations became more important. So IT people and their consultants and ISPs started to block DNS over TCP in many places, often leaving it open only for zone transfers, and felt good about it. Thus the new (you call it old, maybe I'm just an old fart) rule was born: normaly resolver queries had to be udp. Some people tried to evolve the DNS to carry other information, such as IPv6 addresses, digital signatures (actually meta-information to make DNS information more trustable), mail policy information. And some zones (such as the root) wanted to have many nameservers for robustness. So suddenly, the 512 byte (yes, 512 bytes!) limit became a real issue, as fallback to TCP would very often just Not Work. This rule was a bit relaxed because of the increased space needed for IPv6 but many authorative dns servers will only listen to UDP port 53 requests.. I would say, the new rule (if you use TCP for DNS queries other than AXFRs, then you are stupid/up to no good, so I will block you) proved to harm the long-term evolution of the DNS protocol - as is quite often the case with these kinds of security best practices that violate transparency and other design principles. But since such rules are/were best practices, you can never really get rid of them. So what happened instead is that the DNS protocol was extended to support larger-than-512-byte queries over UDP (EDNS0, RFC 2671). While dig doesn't use EDNS0 by default (but see the example below), modern recursive nameservers should normally make use of this, so that fallback to TCP isn't necessary that often. The fact that EDNS0 was added to the DNS is probably a good thing. But I think it would also be good if DNS over TCP generally worked. Although TCP does have higher overhead than UDP for typical DNS usage, it has some security advantage, e.g. it is much harder to spoof requests. So to me this is another example of short-sighted and badly thought-out security thinking that has harmed progress and brought dubious security improvements at best. Note that some people consider EDNS0 a security risk, because it facilitates reflection attacks with UDP DNS requests from spoofed (victim) source addresses that result in very large responses to be sent to the victim. -- Simon. $ dig @www.multipop.ch. +edns=0 ptr -x 195.141.232.78 ; DiG 9.5.0a6 @www.multipop.ch. +edns=0 ptr -x 195.141.232.78 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 895 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;78.232.141.195.in-addr.arpa. IN PTR ;; ANSWER SECTION: 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.spacebbs.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.amigaland.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.augsauger.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.begegnung.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satvision.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.hackernews.ch.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.natel-news.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satanlagen.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satantennen.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.wiso-schoch.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.xariffusion.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.sat-receiver.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.estherundpetr.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.luisenstrasse.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.arthurandersen.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.elektronik-news.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.zuerichsee-gastro.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.pop.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.rtv.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.dsng.ch.
Re: [swinog] Update
hm.. do i miss something here? what is this about? In order to embarrass/amuse susbcribers, this mailing list adds a Reply-To: [EMAIL PROTECTED] header to all messages. It has always been that way. Maybe one day, we can decide that everybody knows when to use reply and when followup/reply to all, and we can remove this... Until we do this, we have to live with the occasional intended unicast response that ends up being sent to the list. -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] BGP problems at Cablecom?
Xaver Aerni writes: Zürich kann auch weit weg sein, von Zürich. Mach mal einen Trace von CC nach Sunrise... Da gehst ja schnell nach Belgien kehren... ??? I'd love to learn how to use trace (route?) thingie, I keep hearing good things about it... mtr from my home gateway on a normal Hispeed connection in Zurich: HostLoss% Snt Last Avg Best Wrst StDev 1. ??? 2. ch-gva01a-ra1-10ge-1-1-0-911.aor 84.2%20 14.8 23.5 14.8 29.7 7.8 3. ch-gva01a-ra1-10ge-1-1-0-911.aor 78.9%20 16.1 15.6 14.0 17.8 1.7 4. ch-zrh01a-ra1-so-0-0-0.aorta.net 60.0%20 14.8 22.6 13.6 48.8 13.2 5. 213.46.171.38 0.0%20 16.3 16.1 13.2 30.2 4.2 6. g5-0.zur01b03.sunrise.ch 0.0%20 14.8 16.2 13.4 38.0 5.2 7. gi10-0-0.ber08d02.sunrise.ch 0.0%20 266.2 40.1 17.1 266.2 58.0 8. v5.ber08s02.sunrise.ch0.0%20 21.0 21.2 17.1 41.2 7.0 9. ??? Zurich-Geneva(oh well)-Zurich-Berne... where do you see Belgium? (real traceroute has trouble with the first three hops, which only send ICMP messages for one in 3-5 packets.) -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] CIXP power outage this morning ?
Jérôme Tissières writes: 2nd, Frederic you send your mails to the whole list :)) This is excusable because the Swinog mailing list has this dreaded Reply-to: swinog@swinog.ch policy, so a reply becomes a followup. Can we please get rid of this? -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] TIX flapping this afternoon?
Anybody else noticed BGP flaps on the TIX? We lost several sessions between 17:46 and 17:47 (MET) today, then sessions coming and going until most stabilized around 20:22. Maybe it was our router, but curiously the other sessions on that router somehow survived (SwissIX and Telia), so I'm suspecting some kind of instability on the TIX fabric. -- Simon (AS559) ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] NetFlow
Raffael Marty writes: I am doing some research on NetFlow and wanted to ask you guys a few things: How are you using NetFlow? For what purposes? Billing? Security? Yes, both billing (and coarse-grained traffic analysis on our upstream and peering connections) and security (detection and localization of malicious traffic, trend analysis, cyberepidemiology research). Do you have NetFlow enabled on all your routers? In our setup we only use data from our border (peering) routers. Do you enable it on all the interfaces or just on the external/internal interface? We have it enabled in the ingress direction on all interfaces, so that we can count all traffic both inbound and outbound through the router. Also our current platform (with current software) cannot enable Netflow selectively. Do you utilize any tool to stitch the NetFlows back together? Why would you do that? In the part I'm responsible for (billing etc.), I don't try to match related unidirectional flows to bidirectional flows. Maybe for security applications this would be more useful. At any rate it's difficult in our network, because the two directions often go through different routers. I guess you can tell that I was never exposed to NetFlow in the ISP world. Any answers or comments are really appreciated. I maintain a page with pointers to Netflow-related software packages - maybe you find it useful: http://www.switch.ch/tf-tant/floma/software.html -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] [Fwd: [Full-disclosure] DNS Smurf revisited]
Fabian Wenk writes: This Mail [1] arrived just over the Full-Disclosure mailinglist [2], but should probably also be of interest to some people here. [1] http://lists.grok.org.uk/pipermail/full-disclosure/2005-May/034342.html [2] https://lists.grok.org.uk/mailman/listinfo/full-disclosure Yes, at least it should remind our community that ingress filtering is important. When I tried the spoofer test software from http://momo.lcs.mit.edu/spoofer/#software , I was shocked to see that I can spoof packets from my home broadband connection (and probably the 299'999 other broadband customers of that Swiss ISP can do so as well :-). Hopefully other Swiss ISPs do this better. I hate to say something in defense of NATs, but at least the problem is somewhat mitigated by the fact that many surfers (especially those with broadband connections) use NATs. They make address spoofing from compromised PCs ineffective. As for enterprise connections, I'm not sure. I assume most small enterprises use NATs as well. Large enterprises use firewalls, but if something behind the firewall does get infected, I'm not sure those firewalls would protect the outside world against spoofed packets (or any other kind of junk) from those machines. -- Simon. PS. SWITCH has ingress filters on all customer access interfaces, so compromised systems inside universities cannot used spoofed source addresses from outside the respective site's address space. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
