[swinog] Re: 15% IPv6 drop in Switzerland

2022-04-12 Diskussionsfäden Simon Leinen
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!

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]

2020-02-16 Diskussionsfäden Simon Leinen
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:



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:


swinog mailing list

Re: [swinog] Telegram group

2020-02-13 Diskussionsfäden Simon Leinen
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.


> - 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

Re: [swinog] AS3303 overlapping prefix

2011-04-03 Diskussionsfäden Simon Leinen
Andy Grawehr writes:
 when i check our prefix on www.ris.ripe.net i get an
 overlapping prefix: 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 to customers.
Note how this also overlaps with your

Best regards,

swinog mailing list

Re: [swinog] BÜPF...again ; )

2010-08-21 Diskussionsfäden Simon Leinen
 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:


But just continue to claim this; it makes old people feel better.

swinog mailing list

Re: [swinog] Urgent request to clear DNS cache for cablecom.net

2010-06-11 Diskussionsfäden Simon Leinen
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.

swinog mailing list

[swinog] IPv6 deployment questionnaire for ISPs

2010-01-31 Diskussionsfäden Simon Leinen
As part of the work of the IETF v6ops WG, Brian Carpenter is
soliciting input from ISPs on IPv6 deployment:


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,

swinog mailing list

[swinog] SWITCH Sourceforge mirror available again

2009-02-21 Diskussionsfäden Simon Leinen
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 :-)

swinog mailing list

Re: [swinog] Bluewin SMTP Policy

2008-06-13 Diskussionsfäden Simon Leinen
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:

swinog mailing list

Rant about DNS and TCP [was: Re: [swinog] Has Bluewin a DNS Problem]

2008-03-27 Diskussionsfäden Simon Leinen
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.
(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

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

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.

$ dig @www.multipop.ch. +edns=0 ptr -x

;  DiG 9.5.0a6  @www.multipop.ch. +edns=0 ptr -x
; (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

; EDNS: version: 0, flags:; udp: 4096
;   IN  PTR

;; ANSWER SECTION: 38400 IN   PTR mailhost.spacebbs.ch. 38400 IN   PTR mailhost.amigaland.ch. 38400 IN   PTR mailhost.augsauger.ch. 38400 IN   PTR mailhost.begegnung.ch. 38400 IN   PTR mailhost.satvision.ch. 38400 IN   PTR mailhost.hackernews.ch.ch. 38400 IN   PTR mailhost.natel-news.ch. 38400 IN   PTR mailhost.satanlagen.ch. 38400 IN   PTR mailhost.satantennen.ch. 38400 IN   PTR mailhost.wiso-schoch.ch. 38400 IN   PTR mailhost.xariffusion.ch. 38400 IN   PTR mailhost.sat-receiver.ch. 38400 IN   PTR mailhost.estherundpetr.ch. 38400 IN   PTR mailhost.luisenstrasse.ch. 38400 IN   PTR mailhost.arthurandersen.ch. 38400 IN   PTR mailhost.elektronik-news.ch. 38400 IN   PTR mailhost.zuerichsee-gastro.ch. 38400 IN   PTR mailhost.pop.ch. 38400 IN   PTR mailhost.rtv.ch. 38400 IN   PTR mailhost.dsng.ch.

Re: [swinog] Update

2007-05-01 Diskussionsfäden Simon Leinen
 hm.. do i miss something here?  what is this about? 

In order to embarrass/amuse susbcribers, this mailing list adds a


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.
swinog mailing list

Re: [swinog] BGP problems at Cablecom?

2006-12-04 Diskussionsfäden Simon Leinen
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. 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.)
swinog mailing list

Re: [swinog] CIXP power outage this morning ?

2006-02-08 Diskussionsfäden Simon Leinen
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

Can we please get rid of this?

swinog mailing list

[swinog] TIX flapping this afternoon?

2005-12-12 Diskussionsfäden Simon Leinen
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

Re: [swinog] NetFlow

2005-08-30 Diskussionsfäden Simon Leinen
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?

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:


swinog mailing list

Re: [swinog] [Fwd: [Full-disclosure] DNS Smurf revisited]

2005-05-27 Diskussionsfäden Simon Leinen
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.

[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.
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