From ipv6-ops at inet6.ca Thu Aug 14 17:17:50 2008 From: ipv6-ops at inet6.ca (Ross West) Date: Thu Aug 14 17:17:38 2008 Subject: utorrent app now supports IPv6/teredo directly Message-ID: <451572579.20080814111750@inet6.ca> Well, expect your IPv6 traffic to start increasing quickly soon. One of the most (the most?) popular torrent applications for windows just released a new version of the software. It now supports IPv6, along with direct Teredo support. So for those people running public relays, take this as a warning. :) SW Release notes: http://forum.utorrent.com/viewtopic.php?id=44003 -- Best regards, Ross mailto:ipv6-ops@inet6.ca From iljitsch at muada.com Thu Aug 14 17:21:24 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu Aug 14 17:21:49 2008 Subject: utorrent app now supports IPv6/teredo directly In-Reply-To: <451572579.20080814111750@inet6.ca> References: <451572579.20080814111750@inet6.ca> Message-ID: <21962CD6-CF7A-41D9-AACB-9513DD722C74@muada.com> On 14 aug 2008, at 17:17, Ross West wrote: > It now supports IPv6, along with direct Teredo support. Is this different from the IPv6 support in Azureus? From ipv6-ops at inet6.ca Thu Aug 14 17:55:58 2008 From: ipv6-ops at inet6.ca (Ross West) Date: Thu Aug 14 17:55:35 2008 Subject: utorrent app now supports IPv6/teredo directly In-Reply-To: <21962CD6-CF7A-41D9-AACB-9513DD722C74@muada.com> References: <451572579.20080814111750@inet6.ca> <21962CD6-CF7A-41D9-AACB-9513DD722C74@muada.com> Message-ID: <1523892318.20080814115558@inet6.ca> >> It now supports IPv6, along with direct Teredo support. > Is this different from the IPv6 support in Azureus? While I don't use Azureus - utorrent makes it extremely simple to activate IPv6 on systems by providing a simple button that says "Install IPv6/Teredo" for end users to hit. So my message is more of a heads up to those people that run Teredo relays that traffic levels might be increasing soon. So my subject line should read "utorrent app now activates Ipv6/teredo directly" or something similar. Cheers, Ross. -- Ross West - doin' ipv6 in Canada. From berni at birkenwald.de Thu Aug 14 20:59:36 2008 From: berni at birkenwald.de (Bernhard Schmidt) Date: Thu Aug 14 20:59:41 2008 Subject: utorrent app now supports IPv6/teredo directly In-Reply-To: <21962CD6-CF7A-41D9-AACB-9513DD722C74@muada.com> References: <451572579.20080814111750@inet6.ca> <21962CD6-CF7A-41D9-AACB-9513DD722C74@muada.com> Message-ID: <48A48098.6080709@birkenwald.de> Iljitsch van Beijnum wrote: >> It now supports IPv6, along with direct Teredo support. > Is this different from the IPv6 support in Azureus? The most important difference is probably that while Azureus/Vuze does not seem to work with IPv6 on Windows at all (due to a Java bug - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6230761), ?Torrent has been designed to work on Windows which is still the most dominant OS around. Note that I write "seem to", I did not get it to work with medium effort but I have been seeing Azureus peers with the typical Windows form of an autogenerated 6to4 address (2002:ip:addr::ip:addr) for at least a year now. The other major difference is the way they find their peers when the tracker is not IPv6-enabled, as I expect them to be for at least one more year. Azureus does run a DHT (distributed hash table) on IPv6 and can actually find peers for popular content on an IPv6-only network, while ?Torrent relies on PEX (PeerEXchange) to propagate IPv6 peers (means when ?Torrent connects to a new peer it got from the Tracker or DHT, it asks the new peer for all its existing peers for this torrent and tries to connect to them). IIRC ?Torrent advertises it's own IPv6 address in PEX, which might shift traffic more easily. And, of course, as Ross said ?Torrent has a 1-click button to enable Teredo (actually, to my knowledge, to enable the IPv6 stack, nothing Teredo specific in there), so I expect this to increase the number of IPv6-enabled Windows XP boxes. The amount of Teredo traffic on the relay in AS12816 has taken a steep and unusual rise (baseline doubled within the last 24h), but it is too early to be sure this is caused by ?Torrent. Most of it is between Teredo and 6to4 anyway. Bernhard From pekkas at netcore.fi Tue Aug 19 20:22:29 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Tue Aug 19 20:22:53 2008 Subject: IPv6 big packet blackhole in Teleglobe/TATA backbone? Message-ID: I and Remi have been trying to figure out an IPv6 big packet blackhole that seems to be occurring in Teleglobe network, specifically around IP addresses 2001:5a0:200::5 and 2001:5a0:200::10. I suspect MTU is not properly configured. This can be seen by a big packet ping or "http://www.remlab.net" if the traffic seems to hit the link in Teleglobe network. I've tried , but they keep asking for circuit ID and whether I'm their customer. Is anyone with Teleglobe/TATA on the list, or know a better contact? [Btw: interesting thing is that Telia seems to be exposing 1480B MTU in at least some parts of their backbone, but at least they're generating ICMPv6 packet too bigs and PMTUD has a chance of working..] ---------- Forwarded message ---------- Date: Mon, 18 Aug 2008 18:55:21 +0300 From: R?mi Denis-Courmont To: Pekka Savola Subject: Re: remlab.net v6 PMTU problem? Sorry for the delay, I overlooked this email. Le mardi 22 juillet 2008 12:45:00 Pekka Savola, vous avez ?crit?: > Maybe I could raise this problem on the ipv6-ops list. > > Could you send the full traceroute/tracepath output from your end, and > confirm up to which router ping6 with 1500 sized packets works, and > where it fails? With not too big packets: % rltraceroute6 -I csc0-ws.ipv6.funet.fi 1000 traceroute to 2001:708:0:f000::7100:2 (2001:708:0:f000::7100:2) from 2001:41d0:1:a0d6::401:1983, 30 hops max, 1000 byte packets 1 * 2001:41d0:1:a0ff:ff:ff:ff:ff (2001:41d0:1:a0ff:ff:ff:ff:ff) 1.717 ms * 2 2001:41d0::592 (2001:41d0::592) 6.330 ms * 5.331 ms 3 2001:5a0:1900::9 (2001:5a0:1900::9) 4.869 ms 4.754 ms 4.686 ms 4 2001:5a0:1900::2 (2001:5a0:1900::2) 4.669 ms 4.576 ms 4.675 ms 5 2001:5a0:0:100::a (2001:5a0:0:100::a) 10.508 ms 10.328 ms 10.316 ms 6 if-6-0.core1.b1d-brussels.ipv6.teleglobe.net (2001:5a0:1400::1) 10.553 ms 10.451 ms 10.400 ms 7 if-6-0.core2.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:200::1) 216.493 ms 94.318 ms 49.794 ms 8 if-0-0.core1.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:100::1) 18.189 ms 18.332 ms 18.095 ms 9 2001:5a0:200::5 (2001:5a0:200::5) 18.232 ms 18.247 ms 18.279 ms 10 2001:5a0:200::10 (2001:5a0:200::10) 19.794 ms 19.355 ms 19.623 ms 11 ldn-ipv6-b1-link.ipv6.telia.net (2001:2000:3010:1::1) 29.447 ms 29.534 ms 29.316 ms 12 ldn-ipv6-b1-link.ipv6.telia.net (2001:2000:3010::1) 60.893 ms 61.063 ms 60.760 ms 13 2001:2000:3080:d::2 (2001:2000:3080:d::2) 45.984 ms 45.987 ms 45.714 ms 14 helsinki0-rtr.funet.fi (2001:948:0:f035::2) 56.706 ms 56.023 ms 56.185 ms 15 csc0-x0000-helsinki0.ipv6.funet.fi (2001:708:0:f000::1:2) 52.700 ms 52.646 ms 52.587 ms 16 csc3-g0000-csc0.ipv6.funet.fi (2001:708:0:f000::30:2) 53.087 ms 53.001 ms 52.810 ms 17 2001:708:0:f000::7100:2 (2001:708:0:f000::7100:2) 52.578 ms 56.028 ms 56.005 ms With MTU packets: % rltraceroute6 -I csc0-ws.ipv6.funet.fi 1460 traceroute to 2001:708:0:f000::7100:2 (2001:708:0:f000::7100:2) from 2001:41d0:1:a0d6::401:1983, 30 hops max, 1460 byte packets 1 2001:41d0:1:a0ff:ff:ff:ff:ff (2001:41d0:1:a0ff:ff:ff:ff:ff) 2.004 ms * 2.275 ms 2 2001:41d0::592 (2001:41d0::592) 5.445 ms * 11.539 ms 3 2001:5a0:1900::9 (2001:5a0:1900::9) 5.044 ms 4.888 ms 5.176 ms 4 2001:5a0:1900::2 (2001:5a0:1900::2) 4.764 ms 4.710 ms 4.745 ms 5 2001:5a0:0:100::a (2001:5a0:0:100::a) 10.437 ms * 10.568 ms 6 if-6-0.core1.b1d-brussels.ipv6.teleglobe.net (2001:5a0:1400::1) 10.563 ms * 10.720 ms 7 if-6-0.core2.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:200::1) 18.265 ms * 18.143 ms 8 if-0-0.core1.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:100::1) 18.783 ms * 18.122 ms 9 2001:5a0:200::5 (2001:5a0:200::5) 186.237 ms 215.084 ms 212.344 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * As for PMTUD: % tracepath6 csc0-ws.ipv6.funet.fi -n 1?: [LOCALHOST] pmtu 1500 1: 2001:41d0:1:a0ff:ff:ff:ff:ff 4.198ms 2: 2001:41d0::592 5. 8ms 3: 2001:5a0:1900::9 4.995ms 4: 2001:5a0:1900::2 4.733ms 5: 2001:5a0:0:100::a 10.408ms 6: 2001:5a0:1400::1 10.532ms 7: 2001:5a0:200:200::1 18.147ms 8: 2001:5a0:200:100::1 18.193ms 9: 2001:5a0:200::5 18.281ms 10: no reply 11: no reply 12: no reply 13: no reply 14: no reply 15: no reply 16: no reply 17: no reply 18: no reply I got an interesting response here: % ping6 -n csc0-ws.ipv6.funet.fi -s 1436 PING csc0-ws.ipv6.funet.fi(2001:708:0:f000::7100:2) 1436 data bytes >From 2001:2000:3010::1 icmp_seq=1 Packet too big: mtu=1480 1444 bytes from 2001:708:0:f000::7100:2: icmp_seq=2 ttl=54 time=58.3 ms 1444 bytes from 2001:708:0:f000::7100:2: icmp_seq=3 ttl=54 time=59.7 ms --- csc0-ws.ipv6.funet.fi ping statistics --- 3 packets transmitted, 2 received, +1 errors, 33% packet loss, time 2001ms rtt min/avg/max/mdev = 58.321/59.019/59.717/0.698 ms After lots of pings (and resets of PMTU cache), it seems that: - packets over 40+8+1438 bytes get lost, - packets over 40+8+1432 bytes get a Too Big error from Telia, - other packets go through -- R?mi Denis-Courmont http://www.remlab.net/ From nuno.vieira at nfsi.pt Tue Aug 19 20:22:00 2008 From: nuno.vieira at nfsi.pt (Nuno Vieira) Date: Tue Aug 19 20:24:24 2008 Subject: IPv6 big packet blackhole in Teleglobe/TATA backbone? In-Reply-To: References: Message-ID: <48AB0F48.8060209@nfsi.pt> We are tata customers. We can open a TT about this. cheers, --nvieira Pekka Savola wrote: > I and Remi have been trying to figure out an IPv6 big packet blackhole > that seems to be occurring in Teleglobe network, specifically around IP > addresses 2001:5a0:200::5 and 2001:5a0:200::10. I suspect MTU is not > properly configured. > > This can be seen by a big packet ping or "http://www.remlab.net" if the > traffic seems to hit the link in Teleglobe network. > > I've tried , but they keep asking for > circuit ID and whether I'm their customer. > > Is anyone with Teleglobe/TATA on the list, or know a better contact? > > [Btw: interesting thing is that Telia seems to be exposing 1480B MTU in > at least some parts of their backbone, but at least they're generating > ICMPv6 packet too bigs and PMTUD has a chance of working..] > > ---------- Forwarded message ---------- > Date: Mon, 18 Aug 2008 18:55:21 +0300 > From: R?mi Denis-Courmont > To: Pekka Savola > Subject: Re: remlab.net v6 PMTU problem? > > Sorry for the delay, I overlooked this email. > > Le mardi 22 juillet 2008 12:45:00 Pekka Savola, vous avez ?crit : >> Maybe I could raise this problem on the ipv6-ops list. >> >> Could you send the full traceroute/tracepath output from your end, and >> confirm up to which router ping6 with 1500 sized packets works, and >> where it fails? > > With not too big packets: > > % rltraceroute6 -I csc0-ws.ipv6.funet.fi 1000 > traceroute to 2001:708:0:f000::7100:2 (2001:708:0:f000::7100:2) from > 2001:41d0:1:a0d6::401:1983, 30 hops max, 1000 > byte packets > 1 * 2001:41d0:1:a0ff:ff:ff:ff:ff (2001:41d0:1:a0ff:ff:ff:ff:ff) > 1.717 ms > * > 2 2001:41d0::592 (2001:41d0::592) 6.330 ms * 5.331 ms > 3 2001:5a0:1900::9 (2001:5a0:1900::9) 4.869 ms 4.754 ms 4.686 ms > 4 2001:5a0:1900::2 (2001:5a0:1900::2) 4.669 ms 4.576 ms 4.675 ms > 5 2001:5a0:0:100::a (2001:5a0:0:100::a) 10.508 ms 10.328 ms > 10.316 ms > 6 if-6-0.core1.b1d-brussels.ipv6.teleglobe.net (2001:5a0:1400::1) > 10.553 > ms > 10.451 ms 10.400 ms > 7 if-6-0.core2.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:200::1) > 216.493 ms 94.318 ms 49.794 ms > 8 if-0-0.core1.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:100::1) > 18.189 ms 18.332 ms 18.095 ms > 9 2001:5a0:200::5 (2001:5a0:200::5) 18.232 ms 18.247 ms 18.279 ms > 10 2001:5a0:200::10 (2001:5a0:200::10) 19.794 ms 19.355 ms 19.623 ms > 11 ldn-ipv6-b1-link.ipv6.telia.net (2001:2000:3010:1::1) 29.447 ms > 29.534 ms 29.316 ms > 12 ldn-ipv6-b1-link.ipv6.telia.net (2001:2000:3010::1) 60.893 ms > 61.063 ms 60.760 ms > 13 2001:2000:3080:d::2 (2001:2000:3080:d::2) 45.984 ms 45.987 ms > 45.714 ms > 14 helsinki0-rtr.funet.fi (2001:948:0:f035::2) 56.706 ms 56.023 ms > 56.185 ms > 15 csc0-x0000-helsinki0.ipv6.funet.fi (2001:708:0:f000::1:2) 52.700 ms > 52.646 ms 52.587 ms > 16 csc3-g0000-csc0.ipv6.funet.fi (2001:708:0:f000::30:2) 53.087 ms > 53.001 ms 52.810 ms > 17 2001:708:0:f000::7100:2 (2001:708:0:f000::7100:2) 52.578 ms 56.028 > ms 56.005 ms > > With MTU packets: > % rltraceroute6 -I csc0-ws.ipv6.funet.fi 1460 > traceroute to 2001:708:0:f000::7100:2 (2001:708:0:f000::7100:2) from > 2001:41d0:1:a0d6::401:1983, 30 hops max, 1460 > byte packets > 1 2001:41d0:1:a0ff:ff:ff:ff:ff (2001:41d0:1:a0ff:ff:ff:ff:ff) 2.004 > ms * > 2.275 ms > 2 2001:41d0::592 (2001:41d0::592) 5.445 ms * 11.539 ms > 3 2001:5a0:1900::9 (2001:5a0:1900::9) 5.044 ms 4.888 ms 5.176 ms > 4 2001:5a0:1900::2 (2001:5a0:1900::2) 4.764 ms 4.710 ms 4.745 ms > 5 2001:5a0:0:100::a (2001:5a0:0:100::a) 10.437 ms * 10.568 ms > 6 if-6-0.core1.b1d-brussels.ipv6.teleglobe.net (2001:5a0:1400::1) > 10.563 > ms > * 10.720 ms > 7 if-6-0.core2.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:200::1) > 18.265 ms * 18.143 ms > 8 if-0-0.core1.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:100::1) > 18.783 ms * 18.122 ms > 9 2001:5a0:200::5 (2001:5a0:200::5) 186.237 ms 215.084 ms 212.344 ms > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > > As for PMTUD: > > % tracepath6 csc0-ws.ipv6.funet.fi -n > 1?: [LOCALHOST] pmtu 1500 > 1: 2001:41d0:1:a0ff:ff:ff:ff:ff 4.198ms > 2: 2001:41d0::592 5. 8ms > 3: 2001:5a0:1900::9 4.995ms > 4: 2001:5a0:1900::2 4.733ms > 5: 2001:5a0:0:100::a 10.408ms > 6: 2001:5a0:1400::1 10.532ms > 7: 2001:5a0:200:200::1 18.147ms > 8: 2001:5a0:200:100::1 18.193ms > 9: 2001:5a0:200::5 18.281ms > 10: no reply > 11: no reply > 12: no reply > 13: no reply > 14: no reply > 15: no reply > 16: no reply > 17: no reply > 18: no reply > > I got an interesting response here: > > % ping6 -n csc0-ws.ipv6.funet.fi -s 1436 > PING csc0-ws.ipv6.funet.fi(2001:708:0:f000::7100:2) 1436 data bytes >> From 2001:2000:3010::1 icmp_seq=1 Packet too big: mtu=1480 > 1444 bytes from 2001:708:0:f000::7100:2: icmp_seq=2 ttl=54 time=58.3 ms > 1444 bytes from 2001:708:0:f000::7100:2: icmp_seq=3 ttl=54 time=59.7 ms > > --- csc0-ws.ipv6.funet.fi ping statistics --- > 3 packets transmitted, 2 received, +1 errors, 33% packet loss, time 2001ms > rtt min/avg/max/mdev = 58.321/59.019/59.717/0.698 ms > > After lots of pings (and resets of PMTU cache), it seems that: > - packets over 40+8+1438 bytes get lost, > - packets over 40+8+1432 bytes get a Too Big error from Telia, > - other packets go through > From nuno.vieira at nfsi.pt Tue Aug 19 20:24:36 2008 From: nuno.vieira at nfsi.pt (Nuno Vieira) Date: Tue Aug 19 20:27:00 2008 Subject: IPv6 big packet blackhole in Teleglobe/TATA backbone? In-Reply-To: References: Message-ID: <48AB0FE4.4020008@nfsi.pt> humm... here goes a traceroute from here. traceroute to poy.remlab.net (2001:41d0:1:a0d6::401:1983) from 2001:b18::211:43ff:fefd:90f6, 30 hops max, 16 byte packets 1 ge-1.Edge1.ip6.Lisbon.NFSi.pt (2001:b18::ffff) 0.229 ms 0.205 ms 0.111 ms 2 2001:5a0:1500::1 (2001:5a0:1500::1) 31.96 ms 1.723 ms 0.613 ms 3 2001:5a0:2a00:100::5 (2001:5a0:2a00:100::5) 13.349 ms 13.094 ms 13.23 ms 4 2001:5a0:1a00::1d (2001:5a0:1a00::1d) 32.589 ms 32.583 ms 32.593 ms 5 2001:5a0:1a00::3e (2001:5a0:1a00::3e) 32.34 ms 32.459 ms 32.469 ms 6 2001:5a0:1900::a (2001:5a0:1900::a) 32.838 ms * 36.727 ms 7 * 2001:41d0::591 (2001:41d0::591) 36.362 ms * 8 2001:41d0:1:a0d6::401:1983 (2001:41d0:1:a0d6::401:1983) 36.24 ms 36.197 ms 36.212 ms Pekka Savola wrote: > I and Remi have been trying to figure out an IPv6 big packet blackhole > that seems to be occurring in Teleglobe network, specifically around IP > addresses 2001:5a0:200::5 and 2001:5a0:200::10. I suspect MTU is not > properly configured. > > This can be seen by a big packet ping or "http://www.remlab.net" if the > traffic seems to hit the link in Teleglobe network. > > I've tried , but they keep asking for > circuit ID and whether I'm their customer. > > Is anyone with Teleglobe/TATA on the list, or know a better contact? > > [Btw: interesting thing is that Telia seems to be exposing 1480B MTU in > at least some parts of their backbone, but at least they're generating > ICMPv6 packet too bigs and PMTUD has a chance of working..] > > ---------- Forwarded message ---------- > Date: Mon, 18 Aug 2008 18:55:21 +0300 > From: R?mi Denis-Courmont > To: Pekka Savola > Subject: Re: remlab.net v6 PMTU problem? > > Sorry for the delay, I overlooked this email. > > Le mardi 22 juillet 2008 12:45:00 Pekka Savola, vous avez ?crit : >> Maybe I could raise this problem on the ipv6-ops list. >> >> Could you send the full traceroute/tracepath output from your end, and >> confirm up to which router ping6 with 1500 sized packets works, and >> where it fails? > > With not too big packets: > > % rltraceroute6 -I csc0-ws.ipv6.funet.fi 1000 > traceroute to 2001:708:0:f000::7100:2 (2001:708:0:f000::7100:2) from > 2001:41d0:1:a0d6::401:1983, 30 hops max, 1000 > byte packets > 1 * 2001:41d0:1:a0ff:ff:ff:ff:ff (2001:41d0:1:a0ff:ff:ff:ff:ff) > 1.717 ms > * > 2 2001:41d0::592 (2001:41d0::592) 6.330 ms * 5.331 ms > 3 2001:5a0:1900::9 (2001:5a0:1900::9) 4.869 ms 4.754 ms 4.686 ms > 4 2001:5a0:1900::2 (2001:5a0:1900::2) 4.669 ms 4.576 ms 4.675 ms > 5 2001:5a0:0:100::a (2001:5a0:0:100::a) 10.508 ms 10.328 ms > 10.316 ms > 6 if-6-0.core1.b1d-brussels.ipv6.teleglobe.net (2001:5a0:1400::1) > 10.553 > ms > 10.451 ms 10.400 ms > 7 if-6-0.core2.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:200::1) > 216.493 ms 94.318 ms 49.794 ms > 8 if-0-0.core1.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:100::1) > 18.189 ms 18.332 ms 18.095 ms > 9 2001:5a0:200::5 (2001:5a0:200::5) 18.232 ms 18.247 ms 18.279 ms > 10 2001:5a0:200::10 (2001:5a0:200::10) 19.794 ms 19.355 ms 19.623 ms > 11 ldn-ipv6-b1-link.ipv6.telia.net (2001:2000:3010:1::1) 29.447 ms > 29.534 ms 29.316 ms > 12 ldn-ipv6-b1-link.ipv6.telia.net (2001:2000:3010::1) 60.893 ms > 61.063 ms 60.760 ms > 13 2001:2000:3080:d::2 (2001:2000:3080:d::2) 45.984 ms 45.987 ms > 45.714 ms > 14 helsinki0-rtr.funet.fi (2001:948:0:f035::2) 56.706 ms 56.023 ms > 56.185 ms > 15 csc0-x0000-helsinki0.ipv6.funet.fi (2001:708:0:f000::1:2) 52.700 ms > 52.646 ms 52.587 ms > 16 csc3-g0000-csc0.ipv6.funet.fi (2001:708:0:f000::30:2) 53.087 ms > 53.001 ms 52.810 ms > 17 2001:708:0:f000::7100:2 (2001:708:0:f000::7100:2) 52.578 ms 56.028 > ms 56.005 ms > > With MTU packets: > % rltraceroute6 -I csc0-ws.ipv6.funet.fi 1460 > traceroute to 2001:708:0:f000::7100:2 (2001:708:0:f000::7100:2) from > 2001:41d0:1:a0d6::401:1983, 30 hops max, 1460 > byte packets > 1 2001:41d0:1:a0ff:ff:ff:ff:ff (2001:41d0:1:a0ff:ff:ff:ff:ff) 2.004 > ms * > 2.275 ms > 2 2001:41d0::592 (2001:41d0::592) 5.445 ms * 11.539 ms > 3 2001:5a0:1900::9 (2001:5a0:1900::9) 5.044 ms 4.888 ms 5.176 ms > 4 2001:5a0:1900::2 (2001:5a0:1900::2) 4.764 ms 4.710 ms 4.745 ms > 5 2001:5a0:0:100::a (2001:5a0:0:100::a) 10.437 ms * 10.568 ms > 6 if-6-0.core1.b1d-brussels.ipv6.teleglobe.net (2001:5a0:1400::1) > 10.563 > ms > * 10.720 ms > 7 if-6-0.core2.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:200::1) > 18.265 ms * 18.143 ms > 8 if-0-0.core1.ad1-amsterdam.ipv6.teleglobe.net (2001:5a0:200:100::1) > 18.783 ms * 18.122 ms > 9 2001:5a0:200::5 (2001:5a0:200::5) 186.237 ms 215.084 ms 212.344 ms > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > > As for PMTUD: > > % tracepath6 csc0-ws.ipv6.funet.fi -n > 1?: [LOCALHOST] pmtu 1500 > 1: 2001:41d0:1:a0ff:ff:ff:ff:ff 4.198ms > 2: 2001:41d0::592 5. 8ms > 3: 2001:5a0:1900::9 4.995ms > 4: 2001:5a0:1900::2 4.733ms > 5: 2001:5a0:0:100::a 10.408ms > 6: 2001:5a0:1400::1 10.532ms > 7: 2001:5a0:200:200::1 18.147ms > 8: 2001:5a0:200:100::1 18.193ms > 9: 2001:5a0:200::5 18.281ms > 10: no reply > 11: no reply > 12: no reply > 13: no reply > 14: no reply > 15: no reply > 16: no reply > 17: no reply > 18: no reply > > I got an interesting response here: > > % ping6 -n csc0-ws.ipv6.funet.fi -s 1436 > PING csc0-ws.ipv6.funet.fi(2001:708:0:f000::7100:2) 1436 data bytes >> From 2001:2000:3010::1 icmp_seq=1 Packet too big: mtu=1480 > 1444 bytes from 2001:708:0:f000::7100:2: icmp_seq=2 ttl=54 time=58.3 ms > 1444 bytes from 2001:708:0:f000::7100:2: icmp_seq=3 ttl=54 time=59.7 ms > > --- csc0-ws.ipv6.funet.fi ping statistics --- > 3 packets transmitted, 2 received, +1 errors, 33% packet loss, time 2001ms > rtt min/avg/max/mdev = 58.321/59.019/59.717/0.698 ms > > After lots of pings (and resets of PMTU cache), it seems that: > - packets over 40+8+1438 bytes get lost, > - packets over 40+8+1432 bytes get a Too Big error from Telia, > - other packets go through > From ipv6-ops at inet6.ca Tue Aug 19 20:37:01 2008 From: ipv6-ops at inet6.ca (Ross West) Date: Tue Aug 19 20:37:33 2008 Subject: IPv6 big packet blackhole in Teleglobe/TATA backbone? In-Reply-To: References: Message-ID: <34585615.20080819143701@inet6.ca> > I and Remi have been trying to figure out an IPv6 big packet blackhole > that seems to be occurring in Teleglobe network, specifically around > IP addresses 2001:5a0:200::5 and 2001:5a0:200::10. I suspect MTU is > not properly configured. I'm a Tata customer, and here's what I see: -= [westr@faraday ~]$ traceroute6 -v www.remlab.net traceroute6 to poy.remlab.net (2001:41d0:1:a0d6::401:1983) from 2610:38::2, 64 hops max, 12 byte packets 1 2610:38::1 68 bytes of data to 2610:38::2 0.490 ms 0.304 ms 0.293 ms 2 tunnel13.6bb1.nyy-newyork.ipv6.teleglobe.net 68 bytes of data to 2610:38::2 20.039 ms 19.984 ms 19.725 ms 3 2001:5a0:400:300::1 68 bytes of data to 2610:38::2 19.995 ms 19.903 ms 19.934 ms 4 2001:5a0:0:300::2d 68 bytes of data to 2610:38::2 96.759 ms 97.458 ms 96.809 ms 5 2001:5a0:1900::d 68 bytes of data to 2610:38::2 96.947 ms 97.003 ms 96.882 ms 6 2001:5a0:1900::a 68 bytes of data to 2610:38::2 97.347 ms 97.042 ms 97.104 ms 7 2001:41d0::591 68 bytes of data to 2610:38::2 100.780 ms 157 bytes from 2001:41d0:1:4a86::1 to 2610:38::2: icmp type 1 (Destination Unreachable) code 4 0000: 60000000 006d1139 26100038 00000000 0010: 00000000 00000002 200141d0 00014a86 0020: 00000000 00000001 c0000035 006d1c87 0030: b4580000 00010000 00000001 01310139 0040: 01350130 01300130 01300130 01300130 0050: 01300130 01300130 01300130 01300130 0060: 01300130 01300130 01300130 01300164 0070: 01310134 01310130 01300132 03697036 0080: 04617270 6100000c 00010000 29100000 0090: 00800000 00000000 00000000 00 100.811 ms 101.340 ms 8 2001:41d0:1:a0d6::401:1983 68 bytes of data to 2610:38::2 101.103 ms 100.715 ms 100.754 ms -= Not sure if hop #7 output helps - here's what I normally get: -= -- Ross West - doin' ipv6 in Canada. From ipv6-ops at inet6.ca Tue Aug 19 20:40:12 2008 From: ipv6-ops at inet6.ca (Ross West) Date: Tue Aug 19 20:40:38 2008 Subject: IPv6 big packet blackhole in Teleglobe/TATA backbone? Message-ID: <169765772.20080819144012@inet6.ca> (Let's try this again!) > I and Remi have been trying to figure out an IPv6 big packet blackhole > that seems to be occurring in Teleglobe network, specifically around > IP addresses 2001:5a0:200::5 and 2001:5a0:200::10. I suspect MTU is > not properly configured. Here's what I see (I'm a Tata customer in Canada, via tunnel to NY/USA) Got this weird one once: -= [westr@faraday ~]$ traceroute6 -v www.remlab.net traceroute6 to poy.remlab.net (2001:41d0:1:a0d6::401:1983) from 2610:38::2, 64 hops max, 12 byte packets 1 2610:38::1 68 bytes of data to 2610:38::2 0.490 ms 0.304 ms 0.293 ms 2 tunnel13.6bb1.nyy-newyork.ipv6.teleglobe.net 68 bytes of data to 2610:38::2 20.039 ms 19.984 ms 19.725 ms 3 2001:5a0:400:300::1 68 bytes of data to 2610:38::2 19.995 ms 19.903 ms 19.934 ms 4 2001:5a0:0:300::2d 68 bytes of data to 2610:38::2 96.759 ms 97.458 ms 96.809 ms 5 2001:5a0:1900::d 68 bytes of data to 2610:38::2 96.947 ms 97.003 ms 96.882 ms 6 2001:5a0:1900::a 68 bytes of data to 2610:38::2 97.347 ms 97.042 ms 97.104 ms 7 2001:41d0::591 68 bytes of data to 2610:38::2 100.780 ms 157 bytes from 2001:41d0:1:4a86::1 to 2610:38::2: icmp type 1 (Destination Unreachable) code 4 0000: 60000000 006d1139 26100038 00000000 0010: 00000000 00000002 200141d0 00014a86 0020: 00000000 00000001 c0000035 006d1c87 0030: b4580000 00010000 00000001 01310139 0040: 01350130 01300130 01300130 01300130 0050: 01300130 01300130 01300130 01300130 0060: 01300130 01300130 01300130 01300164 0070: 01310134 01310130 01300132 03697036 0080: 04617270 6100000c 00010000 29100000 0090: 00800000 00000000 00000000 00 100.811 ms 101.340 ms 8 2001:41d0:1:a0d6::401:1983 68 bytes of data to 2610:38::2 101.103 ms 100.715 ms 100.754 ms -= Not sure if hop #7 output helps, it seems to be a one off - here's what I normally get: -= [westr@faraday ~]$ traceroute6 -v www.remlab.net traceroute6 to poy.remlab.net (2001:41d0:1:a0d6::401:1983) from 2610:38::2, 64 hops max, 12 byte packets 1 2610:38::1 68 bytes of data to 2610:38::2 0.519 ms 0.327 ms 0.303 ms 2 tunnel13.6bb1.nyy-newyork.ipv6.teleglobe.net 68 bytes of data to 2610:38::2 19.914 ms 19.797 ms 19.803 ms 3 2001:5a0:400:300::1 68 bytes of data to 2610:38::2 19.960 ms 19.865 ms 19.931 ms 4 2001:5a0:0:300::2d 68 bytes of data to 2610:38::2 96.978 ms 96.758 ms 96.934 ms 5 2001:5a0:1900::d 68 bytes of data to 2610:38::2 96.970 ms 96.993 ms 96.885 ms 6 2001:5a0:1900::a 68 bytes of data to 2610:38::2 97.142 ms 97.059 ms 97.030 ms 7 2001:41d0::591 68 bytes of data to 2610:38::2 100.777 ms 101.015 ms 100.654 ms 8 2001:41d0:1:a0d6::401:1983 68 bytes of data to 2610:38::2 100.761 ms 100.674 ms 100.622 ms -= Pings/icmp of any size go through normally. Cheers, Ross. -- Ross West - doin' ipv6 in Canada. From steve at ibctech.ca Thu Aug 21 07:48:54 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Aug 21 07:47:52 2008 Subject: L2 VLANs, intermediate network and L3 management (LONG) Message-ID: <48AD01C6.3040508@ibctech.ca> Hi all, It seems as of the last couple of months or so that I've been nearly the only one to ask questions on this list, so I hope I'm breaking the silence with a very winded but reasonable, and hopefully simple question. Please bear with me if you will, with the understanding that I've read, numerous times, and understand the RFC4861 and RFC4862 specifications, but have never had the need to use them with any implementation as of yet. I'm now in a position where I *think* I'd like to, but to me, it's a new territory. --- Scenario (IN == Intermediary Network that does not allow q-in-q and provides a tagged VLAN for each CP): vlan 501 -- CPE 1 / / CO -- IN -- vlan 502 -- CPE 2 \ \ vlan 503 -- CPE 3 CO is a Catalyst switch that has a Cisco .1q trunk port that carries all VLANs via a single fibre converter from the intermediary network (PUC). Another port on the switch then trunks to a single Cisco router interface, where each VLAN has its own sub-int. My network is small, but I would classify this router to be in the 'access layer'. For political and logistical purposes, the 'default-gateway' of most client device that connects to this portion of our network is the router at the CO side as mentioned above. Each CPE has its own prefix which has its own sub int on the router. --- Problem: The Cat switch is in place so that we can administratively put one of the ports into 'sw ac vlan xxx' to trace problems. That said, if we need to reach portions of the client network via Layer 3, we need to manually configure an IP address within their VLANs scope in order to do anything useful. I don't want to do this. -- Question: With a very good understanding of the specifications, but with no experience whatsoever, could anyone provide pros/cons and/or configuration examples on what I'm thinking? I was thinking that I could almost leave all the v4 info statically set/routed and left alone, so I don't have to ask the client for (or reserve) addresses for management purposes. (A couple of clients are Layer-2 with 1918 in-and-out, and a couple others I have eBGP with private ASs as they connect to multiple physical ingress methods to our network). In this regard, with the lack of CPE that our (and I believe most other SP) clients have that comply with 4861 and 4862 (or IPv6 in general), I'm thinking I could use this to my advantage. Perhaps I can tune the router to provide us with dynamic management layer-3 info without any manual configuration, and without the IPv4 space the client has been assigned interfered with. -- Thoughts: - set each VLAN sub-int on the router a EUI-64 address - inform the router that each sub-int needs to perform on-link prefix advertisement - I enable VLAN access on a switchport, plug in a laptop, and immediately am on link with CO and CP ends, L2 *and* L3 (we have equipment at the client prem for this purpose, another Cisco switch) -- Summary: Will this work? Will using IPv6 as a dynamic management 'hack' work in this regard? Can someone introduce to me a config from a Cisco that displays portions of the 4861 and 4862 specs? If you've read this far, I appreciate it. Honestly, I'm typing with a high fever and without having slept properly for a few days due to being very ill. Without being able to sleep, I really have nothing better to do at this time than to poke the people who breath IPv6 for information ;) Thanks all, Steve From david.freedman at uk.clara.net Thu Aug 21 11:05:00 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Thu Aug 21 11:05:06 2008 Subject: L2 VLANs, intermediate network and L3 management (LONG) References: <48AD01C6.3040508@ibctech.ca> Message-ID: >Summary: > >Will this work? > >Will using IPv6 as a dynamic management 'hack' work in this regard? Sure, if you have access to all the kit, you can manage via link local, no need to configure anything specific. This would mean though that you have to be on the router in order to reach the CPE. The alternative is to use ULA (RFC4193) as global but this could be problematic as you deploy v6 authentic global addresses to your clients, they will want real addressing, you would have to overlap. Now, if we hadn't deprecated the site local scope....... >If you've read this far, I appreciate it. Honestly, I'm typing with a >high fever and without having slept properly for a few days due to being >very ill. Good luck, and hope you get better :) Dave. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20080821/a23405cc/attachment.htm From steve at ibctech.ca Thu Aug 21 14:14:23 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Aug 21 14:12:59 2008 Subject: L2 VLANs, intermediate network and L3 management (LONG) In-Reply-To: References: <48AD01C6.3040508@ibctech.ca> Message-ID: <48AD5C1F.90602@ibctech.ca> David Freedman wrote: > >Will using IPv6 as a dynamic management 'hack' work in this regard? > > Sure, if you have access to all the kit, you can manage via link local, > no need > to configure anything specific. Thanks for the feedback David. The thought of using link local addresses never even crossed my mind. > This would mean though that you have to be on the router in order to > reach the CPE. Not very feasible. > The alternative is to use ULA (RFC4193) as global but this could be > problematic as you deploy > v6 authentic global addresses to your clients, they will want real > addressing, you would have to overlap. This method does not appear to be scalable. My handful of fibre clients is going to grow too rapidly to have to go back and re-organize/manage ULAs just for management purposes. > Now, if we hadn't deprecated the site local scope....... LOL, most of the RFCs, BCPs and drafts I've read have included the deprecated site local scope, but since I've hopped on the IPv6 train after the fact, I've never contemplated a scenario where it would be used. This would be a perfect example... With the comments you made, I'm thinking it makes the most sense simply to overlap the IPv4 with a proper IPv6 /48 to each VLAN, even though the clients will not be using it yet. I can get my management requirements resolved, and when my providers finally provide native IPv6, then things will already be in place. I guess today I'll be finding out how auto configuration works in practice. It's a great piece of the specification, I've just not had the need for it until now. Cheers, Steve From pekkas at netcore.fi Thu Aug 21 20:24:06 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Thu Aug 21 20:24:09 2008 Subject: IPv6 big packet blackhole in Teleglobe/TATA backbone? In-Reply-To: <169765772.20080819144012@inet6.ca> References: <169765772.20080819144012@inet6.ca> Message-ID: FYI, the issue has been resolved, with the help of a contact provided off-list. >From the last mail, "... MTU applied at the wrong layer of the config." On Tue, 19 Aug 2008, Ross West wrote: >> I and Remi have been trying to figure out an IPv6 big packet blackhole >> that seems to be occurring in Teleglobe network, specifically around >> IP addresses 2001:5a0:200::5 and 2001:5a0:200::10. I suspect MTU is >> not properly configured. > > Here's what I see (I'm a Tata customer in Canada, via tunnel to NY/USA) > > Got this weird one once: > > -= > [westr@faraday ~]$ traceroute6 -v www.remlab.net > traceroute6 to poy.remlab.net (2001:41d0:1:a0d6::401:1983) from 2610:38::2, 64 hops max, 12 byte packets > 1 2610:38::1 68 bytes of data to 2610:38::2 0.490 ms 0.304 ms 0.293 ms > 2 tunnel13.6bb1.nyy-newyork.ipv6.teleglobe.net 68 bytes of data to 2610:38::2 20.039 ms 19.984 ms 19.725 ms > 3 2001:5a0:400:300::1 68 bytes of data to 2610:38::2 19.995 ms 19.903 ms 19.934 ms > 4 2001:5a0:0:300::2d 68 bytes of data to 2610:38::2 96.759 ms 97.458 ms 96.809 ms > 5 2001:5a0:1900::d 68 bytes of data to 2610:38::2 96.947 ms 97.003 ms 96.882 ms > 6 2001:5a0:1900::a 68 bytes of data to 2610:38::2 97.347 ms 97.042 ms 97.104 ms > 7 2001:41d0::591 68 bytes of data to 2610:38::2 100.780 ms > 157 bytes from 2001:41d0:1:4a86::1 to 2610:38::2: icmp type 1 (Destination Unreachable) code 4 > 0000: 60000000 006d1139 26100038 00000000 > 0010: 00000000 00000002 200141d0 00014a86 > 0020: 00000000 00000001 c0000035 006d1c87 > 0030: b4580000 00010000 00000001 01310139 > 0040: 01350130 01300130 01300130 01300130 > 0050: 01300130 01300130 01300130 01300130 > 0060: 01300130 01300130 01300130 01300164 > 0070: 01310134 01310130 01300132 03697036 > 0080: 04617270 6100000c 00010000 29100000 > 0090: 00800000 00000000 00000000 00 > 100.811 ms 101.340 ms > 8 2001:41d0:1:a0d6::401:1983 68 bytes of data to 2610:38::2 101.103 ms 100.715 ms 100.754 ms > -= > > Not sure if hop #7 output helps, it seems to be a one off - here's what I normally get: > > -= > [westr@faraday ~]$ traceroute6 -v www.remlab.net > traceroute6 to poy.remlab.net (2001:41d0:1:a0d6::401:1983) from 2610:38::2, 64 hops max, 12 byte packets > 1 2610:38::1 68 bytes of data to 2610:38::2 0.519 ms 0.327 ms 0.303 ms > 2 tunnel13.6bb1.nyy-newyork.ipv6.teleglobe.net 68 bytes of data to 2610:38::2 19.914 ms 19.797 ms 19.803 ms > 3 2001:5a0:400:300::1 68 bytes of data to 2610:38::2 19.960 ms 19.865 ms 19.931 ms > 4 2001:5a0:0:300::2d 68 bytes of data to 2610:38::2 96.978 ms 96.758 ms 96.934 ms > 5 2001:5a0:1900::d 68 bytes of data to 2610:38::2 96.970 ms 96.993 ms 96.885 ms > 6 2001:5a0:1900::a 68 bytes of data to 2610:38::2 97.142 ms 97.059 ms 97.030 ms > 7 2001:41d0::591 68 bytes of data to 2610:38::2 100.777 ms 101.015 ms 100.654 ms > 8 2001:41d0:1:a0d6::401:1983 68 bytes of data to 2610:38::2 100.761 ms 100.674 ms 100.622 ms > -= > > Pings/icmp of any size go through normally. > > Cheers, > Ross. > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From iljitsch at muada.com Fri Aug 22 21:01:01 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri Aug 22 21:01:09 2008 Subject: IPv6 traffic on DE-CIX, LINX and others? Message-ID: Apparently on AMS-IX IPv6 is an average of 450Mbps out of a total average 370Gbps traffic = 0.12%. I couldn't find this info for DE-CIX and on LINX you need to be logged in to see sflow stats... Anyone know any more? From arnold at nipper.de Fri Aug 22 21:55:25 2008 From: arnold at nipper.de (Arnold Nipper) Date: Fri Aug 22 21:55:32 2008 Subject: IPv6 traffic on DE-CIX, LINX and others? In-Reply-To: References: Message-ID: <48AF19AD.6060104@nipper.de> On 22.08.2008 21:01 Iljitsch van Beijnum wrote > Apparently on AMS-IX IPv6 is an average of 450Mbps out of a total > average 370Gbps traffic = 0.12%. I couldn't find this info for DE-CIX > and on LINX you need to be logged in to see sflow stats... > > Anyone know any more? Still an order of magnitude less @ DE-CIX. As you may know Google turned on IPv6 at DE-CIX a couple of days ago. Maybe that helps. As it did @ AMS-IX? Traffic increased tenfold since then. Arnold -- Arnold Nipper, AN45 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20080822/466f5a67/signature.bin From stevewilcox at google.com Fri Aug 22 22:08:04 2008 From: stevewilcox at google.com (Steve Wilcox) Date: Fri Aug 22 22:08:12 2008 Subject: IPv6 traffic on DE-CIX, LINX and others? In-Reply-To: <48AF19AD.6060104@nipper.de> References: <48AF19AD.6060104@nipper.de> Message-ID: <922f6670808221308q18b9dce1o6fd1a984b6f55093@mail.gmail.com> On Fri, Aug 22, 2008 at 8:55 PM, Arnold Nipper wrote: > On 22.08.2008 21:01 Iljitsch van Beijnum wrote > >> Apparently on AMS-IX IPv6 is an average of 450Mbps out of a total >> average 370Gbps traffic = 0.12%. I couldn't find this info for DE-CIX >> and on LINX you need to be logged in to see sflow stats... >> >> Anyone know any more? > > Still an order of magnitude less @ DE-CIX. As you may know Google turned > on IPv6 at DE-CIX a couple of days ago. Maybe that helps. As it did @ > AMS-IX? Traffic increased tenfold since then. Struggling to see any jump on our port graphs (since DECIX is a dual stack) .. so its definitely sub-gigabit :) Btw, of that 450Mb on AMSIX we're not any significant part of it.. I heard on the grapevine its either news or p2p traffic but not sure if thats accurate. Arnold, any ideas what the bulk of the v6 on DECIX is, presumably its of a similar make up to AMSIX..? Steve > > > > Arnold > -- > Arnold Nipper, AN45 > > -- Global Infrastructure Google Inc. From arnold at nipper.de Fri Aug 22 22:54:44 2008 From: arnold at nipper.de (Arnold Nipper) Date: Fri Aug 22 22:54:51 2008 Subject: IPv6 traffic on DE-CIX, LINX and others? In-Reply-To: <922f6670808221308q18b9dce1o6fd1a984b6f55093@mail.gmail.com> References: <48AF19AD.6060104@nipper.de> <922f6670808221308q18b9dce1o6fd1a984b6f55093@mail.gmail.com> Message-ID: <48AF2794.4080902@nipper.de> On 22.08.2008 22:08 Steve Wilcox wrote > Btw, of that 450Mb on AMSIX we're not any significant part of it.. I > heard on the grapevine its either news or p2p traffic but not sure if > thats accurate. > > Arnold, any ideas what the bulk of the v6 on DECIX is, presumably its > of a similar make up to AMSIX..? > nntp as well. Arnold -- Arnold Nipper, AN45 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20080822/23cf64c1/signature.bin From taveira at rnl.ist.utl.pt Fri Aug 29 01:46:13 2008 From: taveira at rnl.ist.utl.pt (=?ISO-8859-1?Q?Jo=E3o_Pedro_Taveira?=) Date: Fri Aug 29 01:46:41 2008 Subject: IPv6 QoS and Traffic Shaping Message-ID: <48B738C5.1010102@rnl.ist.utl.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I've searched in google for some articles that explains how to implement QoS and Traffic Shaping policies with linux but I can only find information about cisco systems implementations and theoretical informations about mechanisms. How can I apply a simple shaping rule to a IPv6 flow and classify the traffic to achieve QoS in IPv6 like is done with tc tool to IPv4? I just need some hints to get in track to start to understand the similarities and differences between IPv4 and IPv6 QoS/TS mechanisms and settings with GNU tools. Thanks in Advance Jo?o Pedro Taveira - -- ________________________________________ Jo?o Pedro Taveira taveira@rnl.ist.utl.pt Administra??o de Sistemas da Rede das Novas Licenciaturas Instituto Superior T?cnico web: http://www.rnl.ist.utl.pt email: rnl@rnl.ist.utl.pt telefone: +351 218 41 77 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki3OMUACgkQxe2dX8/qXILL6ACgn66uxrS1iXVYUdm3dGhb2fP4 6ikAnAhzV6fonsYAHHIqy1DZQgbqF3a2 =gknv -----END PGP SIGNATURE----- From LLE at dk.ibm.com Fri Aug 29 12:04:55 2008 From: LLE at dk.ibm.com (Lasse Leegaard) Date: Fri Aug 29 12:05:05 2008 Subject: AUTO: Lasse Leegaard is out of the office. (returning 01-09-2008) Message-ID: I am out of the office until 01-09-2008. For changes, incidents and problems contact SDDK infrastructure (dm129core@dk.ibm.com) For management escalations contact Michael Claus Hansen (hansenmi@dk.ibm.com) Note: This is an automated response to your message "ipv6-ops Digest, Vol 41, Issue 6" sent on 29/8/08 12:00:05. This is the only notification you will receive while this person is away. From berni at birkenwald.de Fri Aug 29 14:14:31 2008 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri Aug 29 14:14:34 2008 Subject: IPv6 QoS and Traffic Shaping In-Reply-To: <48B738C5.1010102@rnl.ist.utl.pt> References: <48B738C5.1010102@rnl.ist.utl.pt> Message-ID: <48B7E827.7010905@birkenwald.de> Hi, > I've searched in google for some articles that explains how to implement > QoS and Traffic Shaping policies with linux but I can only find > information about cisco systems implementations and theoretical > informations about mechanisms. > > How can I apply a simple shaping rule to a IPv6 flow and classify the > traffic to achieve QoS in IPv6 like is done with tc tool to IPv4? > > I just need some hints to get in track to start to understand the > similarities and differences between IPv4 and IPv6 QoS/TS mechanisms and > settings with GNU tools. It's the same, but apparently you cannot use the ip6tables CLASSIFY target and probably not fwmark as well, but the u32 match. I use the following tc filters to put 6to4 traffic into special queues. # 6to4, TCP-ACK (0x10), <= 256 Bytes IPv6 Payload /sbin/tc filter add dev eth0 protocol ipv6 parent 1:0 pref 1 u32 match ip6 dst 2002::/16 match u32 0x00000600 0xff00ff00 at 4 match u8 0x10 0xff at 53 flowid 1:2004 # 6to4, TCP /sbin/tc filter add dev eth0 protocol ipv6 parent 1:0 pref 2 u32 match ip6 dst 2002::/16 match ip6 protocol 6 0xff flowid 1:2003 especially the first one was more trial-and-error though :-\ Regards, Bernhard From berni at birkenwald.de Fri Aug 29 14:22:32 2008 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri Aug 29 14:22:34 2008 Subject: Paging Consulintel/Neosky Message-ID: <48B7EA08.8080106@birkenwald.de> Hello, would anyone from Consulintel/Neosky (AS16206) please contact me offlist? All my attempts to contact you regarding your broken/totally overloaded Teredo relay privately have lead to no response. Regards, Bernhard From taveira at rnl.ist.utl.pt Fri Aug 29 14:29:23 2008 From: taveira at rnl.ist.utl.pt (=?ISO-8859-1?Q?Jo=E3o_Pedro_Taveira?=) Date: Fri Aug 29 14:27:45 2008 Subject: IPv6 QoS and Traffic Shaping In-Reply-To: <48B7E827.7010905@birkenwald.de> References: <48B738C5.1010102@rnl.ist.utl.pt> <48B7E827.7010905@birkenwald.de> Message-ID: <48B7EBA3.2020608@rnl.ist.utl.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you for the quick response. I've already read about tc filters and 6to4, but I don't use IPv6 tunnels. Fortunately I have native IPv6 to the world but I don't know how to filter it. That's the reason why I need some help. I suppose that can be made with u32 match as well, but I thought there was a simpler way to do it. Regards Jo?o Pedro Taveira Bernhard Schmidt wrote: > Hi, > >> I've searched in google for some articles that explains how to implement >> QoS and Traffic Shaping policies with linux but I can only find >> information about cisco systems implementations and theoretical >> informations about mechanisms. >> >> How can I apply a simple shaping rule to a IPv6 flow and classify the >> traffic to achieve QoS in IPv6 like is done with tc tool to IPv4? >> >> I just need some hints to get in track to start to understand the >> similarities and differences between IPv4 and IPv6 QoS/TS mechanisms and >> settings with GNU tools. > > It's the same, but apparently you cannot use the ip6tables CLASSIFY > target and probably not fwmark as well, but the u32 match. > > I use the following tc filters to put 6to4 traffic into special queues. > > # 6to4, TCP-ACK (0x10), <= 256 Bytes IPv6 Payload > /sbin/tc filter add dev eth0 protocol ipv6 parent 1:0 pref 1 u32 match > ip6 dst 2002::/16 match u32 0x00000600 0xff00ff00 at 4 match u8 0x10 > 0xff at 53 flowid 1:2004 > > # 6to4, TCP > /sbin/tc filter add dev eth0 protocol ipv6 parent 1:0 pref 2 u32 match > ip6 dst 2002::/16 match ip6 protocol 6 0xff flowid 1:2003 > > especially the first one was more trial-and-error though :-\ > > Regards, > Bernhard > - -- ________________________________________ Jo?o Pedro Taveira taveira@rnl.ist.utl.pt Administra??o de Sistemas da Rede das Novas Licenciaturas Instituto Superior T?cnico web: http://www.rnl.ist.utl.pt email: rnl@rnl.ist.utl.pt telefone: +351 218 41 77 71 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki366MACgkQxe2dX8/qXIJzmgCdFFCgon2KveHELqisiQYCuIZl 1BYAn2ymlTx3xiBL6VlXgRvonQC+PD/4 =ys0o -----END PGP SIGNATURE----- From berni at birkenwald.de Fri Aug 29 14:33:04 2008 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri Aug 29 14:33:06 2008 Subject: IPv6 QoS and Traffic Shaping In-Reply-To: <48B7EBA3.2020608@rnl.ist.utl.pt> References: <48B738C5.1010102@rnl.ist.utl.pt> <48B7E827.7010905@birkenwald.de> <48B7EBA3.2020608@rnl.ist.utl.pt> Message-ID: <48B7EC80.2080301@birkenwald.de> Hallo, > Thank you for the quick response. > > I've already read about tc filters and 6to4, but I don't use IPv6 > tunnels. Fortunately I have native IPv6 to the world but I don't know > how to filter it. That's the reason why I need some help. I suppose that > can be made with u32 match as well, but I thought there was a simpler > way to do it. This is native (tc filter add dev _eth0_). I use it to limit the amount of traffic sent by my natively connected box to 6to4 addresses, which are encapsulated into IPv4 on _another_ box (the 6to4 relay) in the same ASN. And thus don't appear as IPv6 in my edge stats which is all I care about :-) You can match arbitrary things with u32 if you know the offsets. tc understands a few offsets by itself (see "match ip6 dst" and "match ip6 protocol"), but the more sophisticated things need to be done by hand. Bernhard