Re: Some very nice broken IPv6 networks at Google and Akamai
On 2014-11-11 16:00, Emanuel Popa wrote: Hi, Is there anyway to intentionally and immediately get on Google's DNS blacklist in order to avoid similar outages in the future affecting only IPv6 traffic? http://www.google.com/intl/en_ALL/ipv6/statistics/data/no_.txt Or maybe the smart thing to do is building another ISP controllable blacklist of broken domains and tell BIND on the caches to return only A records for blacklisted domains. Or the other way around: only records for IPv4 broken/blacklisted domains... As most modern clients do Happy Eyeballs, you could just null route the destination prefixes and see all clients fall back to IPv6. But it is rather evil to do that especially at an ISP level. Could have done that for SixXS and give people working stuff that way, but that would not have actually resolved the problem, just hidden it. If you expect that they have outages that they cannot quickly see or not, then you should also expect a blacklist like to be broken or not properly update. Hence, better to see the problems and to alert the folks so that they can fix these issues properly (though Google is now just hacking around with MSS clamping...). They typically do not have these issues, they just did not notice it this time around and thus it took a while for them to wake up (timezones :) figure out what it is and fix the issue. I am fairly confident though that Google is now monitoring their stuff correctly. Lots of good folks there, stuff breaks, they fix it. Greets, Jeroen
Re: Some very nice broken IPv6 networks at Google and Akamai
On 11/11/2014 15:00, Emanuel Popa wrote: Is there anyway to intentionally and immediately get on Google's DNS blacklist in order to avoid similar outages in the future affecting only IPv6 traffic? http://www.google.com/intl/en_ALL/ipv6/statistics/data/no_.txt Or maybe the smart thing to do is building another ISP controllable blacklist of broken domains and tell BIND on the caches to return only A records for blacklisted domains. Or the other way around: only records for IPv4 broken/blacklisted domains... ... or alternatively, depend on Google, Akamai and others not breaking. This is what we do for ipv4 and it normally works well, but not always. Bear it in mind that every time a hack is installed to work around a potential future problem, that hack needs maintenance and if it breaks, there's a chance that the resulting damage will be at least as bad as what it was seeking to avoid in the first place. Unless there are persistent reliability problems, hacks tend not to be worth it. Nick
Opt Out (UNCLASSIFIED)
UNCLASSIFIED How do I opt out of this list? Thanks, Victor UNCLASSIFIED
How to unsubscribe (Was: Opt Out (UNCLASSIFIED))
On 2014-11-11 17:25, Deal, Victor T MSG RET wrote: UNCLASSIFIED How do I opt out of this list? By looking at the standardized List headers which show: List-Unsubscribe: http://lists.cluenet.de/mailman/listinfo/ipv6-ops, mailto:ipv6-ops-requ...@lists.cluenet.de?subject=unsubscribe Either go that webpage or mail the address listed. That is btw also the location you signed up... Greets, Jeroen
Re: Opt Out (UNCLASSIFIED)
2014-11-11 8:25 GMT-08:00 Deal, Victor T MSG RET victor.t.d...@us.army.mil: UNCLASSIFIED How do I opt out of this list? You could observe the headers in each e-mail sent by the list server: List-Id: IPv6 operators forum ipv6-ops.lists.cluenet.de List-Unsubscribe: http://lists.cluenet.de/mailman/listinfo/ipv6-ops, mailto:ipv6-ops-requ...@lists.cluenet.de?subject=unsubscribe List-Archive: http://lists.cluenet.de/pipermail/ipv6-ops List-Post: mailto:ipv6-ops@lists.cluenet.de List-Help: mailto:ipv6-ops-requ...@lists.cluenet.de?subject=help List-Subscribe: http://lists.cluenet.de/mailman/listinfo/ipv6-ops, mailto:ipv6-ops-requ...@lists.cluenet.de?subject=subscribe Sender: ipv6-ops-bounces+pim+ipv6=ipng...@lists.cluenet.de Errors-To: ipv6-ops-bounces+pim+ipv6=ipng...@lists.cluenet.de Which suggests that you can take a look at http://lists.cluenet.de/mailman/listinfo/ipv6-ops or send e-mail to ipv6-ops-requ...@lists.cluenet.de with subject unsubscribe from the address with which you registered. groet, Pim -- Pim van Pelt p...@ipng.nl PBVP1-RIPE - http://www.ipng.nl/
Re: RING measurements don't match access-networks (Was: Some very nice broken IPv6 networks...)
On Tue, Nov 11, 2014 at 12:56:06PM +0100, Jeroen Massar wrote: On 2014-11-11 06:38, Matthew Luckie wrote: Also, broken pMTU/traceroute for: 2a02:58:3:110::23:1 2a01:310:8312:1001::19 2a00:1f00:dc06:11::10 2001:48c8:3:2::2 2607:fcc0:2:1:208:70:247:50 2001:67c:2274:4021::101 with that list of IP addresses: scamper -c trace -P udp-paris -M -f file See attached f.out, though I used: (for i in `cat f`; do echo $i; tracepath6 -n $i; scamper -I trace -P udp-paris -M $i; done) f.out This to show the difference between tracepath6 and scamper output, there are some to be seen, some quite scary (eg the 1455 change). Could be that one just gets through the ICMP ratelimits in one run and not the other. Unsure what happened with that one in your file, scamper got an address unreachable response eventually. When I tried it just now it worked and has a 1500 PMTU. traceroute from 2001:48d0:101:501:d267:e5ff:fe14:a701 to 2a01:310:8312:3900::2 1 2001:48d0:101:501::18 0.195 ms [mtu: 1500] 2 2001:468:e00:c48::1 2.592 ms [mtu: 1500] 3 2607:f380::108:9a41:af60 3.132 ms [mtu: 1500] 4 2001:468:f000:2300::1 2.622 ms [mtu: 1500] 5 2001:468:f000:f17::1 11.068 ms [mtu: 1500] 6 2001:504:d::5580:1 20.959 ms [mtu: 1500] 7 2a02:d28:5580:1::d1 69.738 ms [mtu: 1500] 8 2a02:d28:5580::1:c9 75.740 ms [mtu: 1500] 9 2a02:d28:5580:5:1008::5 155.666 ms [mtu: 1500] 10 2a02:d28:5580:1::136 159.654 ms [mtu: 1500] 11 2a02:d28:5580:1::156 159.484 ms [mtu: 1500] 12 2a02:d28:5580:e:1000::136 158.690 ms [mtu: 1500] 13 2a01:310:8312:3900::2 158.653 ms [mtu: 1500] For the rest, those addresses are just unresponsive to traceroute, i.e. no port unreachable response comes back from the destination. I am always surprised to see networks filtering out packets, and especially wonder what they are trying to achieve with such a filter. http://www.caida.org/tools/measurement/scamper/ http://www.caida.org/~mjl/pubs/debugging-pmtud.imc2005.pdf Happy to help anyway I can (I wrote scamper) I am quite aware. Great tool, but not very verbose unfortunately. Hence, typically it just does/outputs nothing. It is designed for doing lots of measurements in parallel, so does not output anything until it is done. To do PMTU debugging, it relies on the end host being responsive to at least some probes, to distinguish between all packets being discarded, and just big ones. If you want the full details on what is going on, output to warts format and use sc_wartsdump or sc_warts2json. Matthew pgpqQvIziFK6m.pgp Description: PGP signature
RE: MTU = 1280 everywhere? / QUIC
Hi, the idea of setting a fixed 1280 MTU everywhere and for all time is silly; the maximum MTU for IPv4 is 64KB, and the maximum MTU for IPv6 is 4GB. One item of follow-up: Also, fragments are evil and there is no real reason to have any fragments at all. IPv4 fragmentation works at slow speeds, but is dangerous at line rates. IPv6 fragmentation works at line rates, but is a pain point that should be avoided and/or tuned out when possible. Neither in and of themselves are evil, however. Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de [mailto:ipv6-ops- bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Jeroen Massar Sent: Tuesday, November 11, 2014 2:06 AM To: Vincent Bernat Cc: IPv6 Ops list Subject: Re: MTU = 1280 everywhere? / QUIC On 2014-11-11 10:55, Vincent Bernat wrote: ❦ 11 novembre 2014 10:42 +0100, Jeroen Massar jer...@massar.ch : From: https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic UDP PACKET FRAGMENTATION but IPv6 dos not fragment... IPv6 routers don't fragment but IPv6 hosts still do. Correct. But that means if you are sending 1350 bytes on a 1280 link you are sending two packets, not one. As they do cool stuff like FEC in QUIC, they assume lossy networks (good thing they think that way), but that also means that you will be sending more data (due to FEC) and also assume you are losing packets. Hence, if your FEC protocol assumes that 1 packet is lost while actually only half the packet was, you got more loss than you are anticipating. Knowing what the MTU is on the link, thus is a smart thing. Hence, why PMTUD is important. Also, fragments are evil and there is no real reason to have any fragments at all. Greets, Jeroen
Re: Some very nice broken IPv6 networks at Google and Akamai
On 2014-11-11 19:09, Andras Toth wrote: On Tue, Nov 11, 2014 at 3:36 PM, Jeroen Massar jer...@massar.ch mailto:jer...@massar.ch wrote: If you expect that they have outages that they cannot quickly see or not, then you should also expect a blacklist like to be broken or not properly update. Hence, better to see the problems and to alert the folks so that they can fix these issues properly (though Google is now just hacking around with MSS clamping...). [de-cloak] Google has been doing MSS clamping for a long time, I've seen this myself in packet captures and Lorenzo also confirmed in his email: ...some Google servers temporarily stopped doing MSS clamping. They do it for a good reason: to prevent PMTUD as it introduces delay and their customers (eyeballs) wouldn't like it. Lorenzo and others explained this too several times. That explanation was seen, at least for me, the first time in this thread. As stated, the MSS clamping is just hiding the real problems. It does not properly resolve anything. The world is not spinning around sixxs and your design ideas. Please turn off write-only. Wow, here come the ad-hominem attacks, stay in lurk mode if you can't handle people raising issues. If I had not commented about this problem, it would never have come to light... maybe in several years when nothing could have been done anymore. But today, we still can fix things. Please realize that the world does have a lot more users than SixXS. Noting problems and properly fixing them are important. Greets, Jeroen
