From stefan.winter at restena.lu Wed Sep 18 06:01:15 2013 From: stefan.winter at restena.lu (Stefan Winter) Date: Wed, 18 Sep 2013 15:01:15 +0200 Subject: [Netalyzr] IPv6 fragmentation problem reported - but why? Message-ID: <5239A41B.2000703@restena.lu> Hello, I've just run netalyzr checks on our network. We are an ISP, and have a pretty good grasp of all technology involved, and are rather proud of our well-implemented and double-checked IPv6 connectivity. That's why I was very baffled to see an IPv6 fragmentation problem being reported. It's test 44 of this client-side transcript: http://n1.netalyzr.icsi.berkeley.edu/transcript/id=43ca253f-2716-4ddc7253-7ffa-40c8-87ef/side=client/sort It shows that IPv6 fragments can be sent and received between my host and Netalyzr just fine. The tool then goes on to try and find the MTU on the IPv6 link and its binary search goes down to MTU = 0. ?!? Given that we're able to send and receive packets at all, the 0 looks rather impossible to me. The log is not verbose enough for me to figure out *what* exactly this test is doing though, and if there's anything we might need to fix. I did, of course, check the obvious candidate: yes, ICMPv6 packet-too-big is allowed bidirectionally on both of the firewalls this test traverses. After those comes the backbone, which is out of my reach. If someone cares enough to take a look at this, I'd very happy. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R?seau T?l?informatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x8A39DC66.asc Type: application/pgp-keys Size: 3243 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20130918/6cc1a1dd/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20130918/6cc1a1dd/attachment-0001.bin From stefan.winter at restena.lu Wed Sep 18 06:14:58 2013 From: stefan.winter at restena.lu (Stefan Winter) Date: Wed, 18 Sep 2013 15:14:58 +0200 Subject: [Netalyzr] Netalyzr wrongly reports that we're redirecting traffic Message-ID: <5239A752.3040308@restena.lu> Hi, Netalyzr spits out some very uneasy WARNINGs when it comes to resolving www.google.com, claiming that we unrightfully redirect traffic. This is incorrect, and does not look very nice to people running Netalyzr on our network. http://n3.netalyzr.icsi.berkeley.edu/restore/id=36ea240d-13492-492bd4a9-1271-44ad-877b/rd "We received unexpected and possibly dangerous results when looking up important names Your ISP is using DNS to redirect specific sites " and "3 popular names have a significant anomaly. The ownership suggested by the reverse name lookup does not match our understanding of the original name. This could be caused by an error somewhere in the domain information, deliberate blocking or redirection of a site using DNS, or it could be that your ISP's DNS Server is acting as a DNS "Man-in-the-Middle". We attempted to download HTTP content from the IP addresses that your ISP's DNS server returned to you for these names. Where the download succeeded, you can click on the IP address in the table below to download a compressed file containing an HTTP session transcript. Note! The session content is potentially harmful to your computer when viewed in a browser, so use caution when examining it. Name IP Address Reverse Name/SOA encrypted.google.com 188.93.174.42 SOA: pri.authdns.ripe.net www.google.com 188.93.174.26 SOA: pri.authdns.ripe.net www.google-analytics.com 188.93.174.16 SOA: pri.authdns.ripe.net " This is very likely due to our peering setup. I'd like to report it here, wondering if there's anything you can do on the code side to detect the condition as being harmless. We're connected to an internet exchange point, LU-CIX in Luxembourg. LU-CIX hosts a Google Cache. Our resolvers do not interfere with any name resolution requests for www.google.com and friends; the resolver passes them on to Google as it should. Google however knows that our network is in the LU-CIX peering setup, and will answer to any requests for google names coming from our resolvers only with IP addresses of the cache in LU-CIX; not with its "normal" IP addresses. Using a "host www.google.com", this looks like: > host www.google.com www.google.com has address 188.93.174.53 www.google.com has address 188.93.174.48 www.google.com has address 188.93.174.35 www.google.com has address 188.93.174.57 www.google.com has address 188.93.174.38 www.google.com has address 188.93.174.24 www.google.com has address 188.93.174.31 www.google.com has address 188.93.174.42 www.google.com has address 188.93.174.27 www.google.com has address 188.93.174.49 www.google.com has address 188.93.174.16 www.google.com has address 188.93.174.37 www.google.com has address 188.93.174.46 www.google.com has address 188.93.174.20 www.google.com has address 188.93.174.26 www.google.com has address 188.93.174.59 www.google.com has IPv6 address 2a00:1450:4001:800::1011 (Funny enough, the Google Cache is IPv4-only, so the v6 result goes another way) I find it an important distinction to make that the non-expected IPs in resolver response come from the authoritative name server; not from our resolver. I wouldn't know immediately how your code would detect this condition in a proper way; but then I'm just the reporter :-) Please don't accuse us of things we don't do :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R?seau T?l?informatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x8A39DC66.asc Type: application/pgp-keys Size: 3243 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20130918/cd98680d/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20130918/cd98680d/attachment-0001.bin From nweaver at ICSI.Berkeley.EDU Wed Sep 18 07:52:27 2013 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Wed, 18 Sep 2013 10:52:27 -0400 Subject: [Netalyzr] IPv6 fragmentation problem reported - but why? In-Reply-To: <5239A41B.2000703@restena.lu> References: <5239A41B.2000703@restena.lu> Message-ID: Thanks. This suggests a bug in our V6 server, such as the MTU discovery server having crashed. I will attempt to debug this in the next couple of hours. On Sep 18, 2013, at 9:01 AM, Stefan Winter wrote: > Hello, > > I've just run netalyzr checks on our network. We are an ISP, and have a > pretty good grasp of all technology involved, and are rather proud of > our well-implemented and double-checked IPv6 connectivity. > > That's why I was very baffled to see an IPv6 fragmentation problem being > reported. It's test 44 of this client-side transcript: > > http://n1.netalyzr.icsi.berkeley.edu/transcript/id=43ca253f-2716-4ddc7253-7ffa-40c8-87ef/side=client/sort > > It shows that IPv6 fragments can be sent and received between my host > and Netalyzr just fine. The tool then goes on to try and find the MTU on > the IPv6 link and its binary search goes down to MTU = 0. ?!? > > Given that we're able to send and receive packets at all, the 0 looks > rather impossible to me. > > The log is not verbose enough for me to figure out *what* exactly this > test is doing though, and if there's anything we might need to fix. > > I did, of course, check the obvious candidate: yes, ICMPv6 > packet-too-big is allowed bidirectionally on both of the firewalls this > test traverses. After those comes the backbone, which is out of my reach. > > If someone cares enough to take a look at this, I'd very happy. > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R?seau T?l?informatique de l'Education Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 > <0x8A39DC66.asc>_______________________________________________ > Netalyzr mailing list > Netalyzr at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/netalyzr -- Nicholas Weaver it is a tale, told by an idiot, nweaver at icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20130918/656b0be6/attachment.bin From nweaver at ICSI.Berkeley.EDU Wed Sep 18 07:55:34 2013 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Wed, 18 Sep 2013 10:55:34 -0400 Subject: [Netalyzr] Netalyzr wrongly reports that we're redirecting traffic In-Reply-To: <5239A752.3040308@restena.lu> References: <5239A752.3040308@restena.lu> Message-ID: This is a recent change on the part of Google (I only noticed it myself yesterday) where their reverse is no longer clean. (It used to be clean: a reverse of a google name referred to "google" or "1e100" etc. But their recent shift to a much more CDN-centric structure has changed things considerably.) I just push out a minor update to fix this problem. http://n3.netalyzr.icsi.berkeley.edu/restore/id=36ea240d-13492-492bd4a9-1271-44ad-877b/ Thanks for the report. On Sep 18, 2013, at 9:14 AM, Stefan Winter wrote: > Hi, > > Netalyzr spits out some very uneasy WARNINGs when it comes to resolving > www.google.com, claiming that we unrightfully redirect traffic. This is > incorrect, and does not look very nice to people running Netalyzr on our > network. -- Nicholas Weaver it is a tale, told by an idiot, nweaver at icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20130918/37810699/attachment.bin