From tore.anderson at redpill-linpro.com Thu Apr 1 01:35:01 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 01 Apr 2010 01:35:01 +0200 Subject: IPv6 brokenness in Norway, March 2010 Message-ID: <4BB3DC25.90008@redpill-linpro.com> Hi list, I'm happy to announce that the client loss is at an all-time low: 0.074% over the whole month, and it's been steadily decreasing. Buggy versions of Opera as well as Mac OS X appears to be responsible for about 95% of all measured client loss. Some noteworthy dates and events: 20100302: Opera 10.50 released, using getaddrinfo() on Windows. Gets an initial boost thanks to the Microsoft browser ballot. 20100322: Opera pushes 10.51 to their auto-update function. 20100324: A-Pressen Interaktiv re-joins the experiment. 20100327: First day of (extended) Easter holiday for many Norwegians. 20100331: The Gathering, a large data-party, kicks off. Provides native IPv6 connectivity to all participants. The numbers show that the release of Opera has helped quite a lot. Before the release of 10.50, the overall client loss was above 0.090%, but already right before Easter holiday it's below 0.065%. Easter holiday shows an interesting effect - both the measured amount of native IPv6 _and_ client loss drop sharply. The reason for this is that there's one particular network here in Norway that is the by far largest deployment of native IPv6 (about 80-85% of all requests over native IPv6 comes from it), but it is at the same time one of the largest causes of client loss, because it aggravates the Mac OS X/Opera problems significantly by filtering 6to4 traffic on ingress for a large number of end users (that have no native IPv6 service). The typical user on this network is also much more likely to take an extended Easter holiday than the the rest of Norway's population, I believe. I've been measuring the uptake of Opera 10.50+ on Windows Vista/7 in the whole period, and it has been steadily increasing even during the extended Easter holiday. About 72.5% of the Win Vista/7 Opera users were using 10.50+ at the end of the month. So while I do expect the client loss number to rebound somewhat when Easter holiday is over (on the 6th of April), I will be very surprised if it stabilises higher than 0.06-0.07%. The Mac OS X problem appears to occur when a client station has internet service using NAT/RFC 1918 numbering for IPv4, and 6to4 for IPv6. The Apple Airport Extreme SOHO router can operate in this way, and did so by default up until recently. In this case, OS X, or more precisely its getaddinfo() implementation, will prioritise 6to4 over IPv4. In addition, GNU libc (therefore all major Linux distributions) behave in the same way, but I'm not able to measure any impact, probably because there's so few Linux users to begin with. The issue is not actually a bug, but a shortcoming of RFC 3484. I've elaborated on it in reports to Apple and the glibc developers here: http://lists.apple.com/archives/Ipv6-dev/2010/Mar/msg00003.html http://sourceware.org/bugzilla/show_bug.cgi?id=11438 As an aside it's a bit fun to see how a relatively small deployment of IPv6 eyeballs like the data party (around 5000 participants I think) can dramatically change the amount of hits coming in from hosts with native IPv6. It more than doubled overnight. There's two reports attached, one generated from the readers of VG Multimedia - the online edition of Norways largest newspaper, and also Norway's largest web site, and the other from the readers of A-Pressen Interaktiv - an umbrella organisation that publishes the online editions of about 70 regional newspapers. When put together, they constitute Norway's fourth largest web site. In addition to the overall calculation, I've done five other calculations so you can see the individual impact of the different problems I've identified: - One that excludes hits from buggy versions of Opera on Windows Vista/7 (which auto-configures 6to4 and Teredo by default) excluded, - one that excludes hits from buggy versions of Opera on other versions of Windows (where a user must explicitly enable 6to4/Teredo), - one that excludes all hits from Mac OS X, - one that excludes all of the above, and - one that excludes all hits from the two significant end-user networks in Norway that filter 6to4 ingress traffic (one of them is the one I discussed above). This calculation does _not_ exclude Opera/OS X; when Opera and OS X are excluded, the two networks have about the same levels of client loss as rest of the internet. The seventh column shows approximately how much of the total client loss would have been avoided (in percentage points and percent), if the software in question didn't prefer 6to4 over IPv4, or, in the last case, if the two end-user networks mentioned didn't filter 6to4 on ingress. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 201003-vg.txt Url: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100401/0c997afe/attachment-0002.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 201003-api.txt Url: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100401/0c997afe/attachment-0003.txt From gert at space.net Thu Apr 1 11:41:31 2010 From: gert at space.net (Gert Doering) Date: Thu, 1 Apr 2010 11:41:31 +0200 Subject: IPv6 equivalent of ARP - possibly dumb question In-Reply-To: References: Message-ID: <20100401094131.GN69383@Space.Net> Hi, On Wed, Mar 31, 2010 at 08:05:07AM -0500, Frank Bulk - iName.com wrote: > It's my understanding that the closest equivalent of ARP in IPv6 is "sh ipv6 > neighbors". When I do that on our Cisco 7206VXR running 12.2(31)SB16 I see > only a few addresses, not nearly all the ones that I know that the PCs > "obtained" via SLAAC. These entries seem to expire fairly quickly. > How do I see which IPv6 hosts are actively sending traffic through/to our > router? By checking "show ipv6 neighbors" - that's the active hosts. Most likely the "unseen rest" is onyl using IPv4... Alternatively, and if your IOS permits (I'm not sure about 12.2SB - 12.2S does not, 12.2SR and 12.4 definitely do) you could use IPv6 netflow. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From frnkblk at iname.com Thu Apr 1 15:16:35 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Thu, 1 Apr 2010 08:16:35 -0500 Subject: IPv6 equivalent of ARP - possibly dumb question In-Reply-To: <20100401094131.GN69383@Space.Net> References: <20100401094131.GN69383@Space.Net> Message-ID: Thanks for the insight. They must expire quickly. I pinged ipv6.google.com from a workstation and that showed up in "sh ipv6 nei" as ACTIVE. Very quickly it showed up as stale. Unfortunately, we don't have any netflow in place today. Frank -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Thursday, April 01, 2010 4:42 AM To: Frank Bulk - iName.com Cc: ipv6-ops at lists.cluenet.de Subject: Re: IPv6 equivalent of ARP - possibly dumb question Hi, On Wed, Mar 31, 2010 at 08:05:07AM -0500, Frank Bulk - iName.com wrote: > It's my understanding that the closest equivalent of ARP in IPv6 is "sh ipv6 > neighbors". When I do that on our Cisco 7206VXR running 12.2(31)SB16 I see > only a few addresses, not nearly all the ones that I know that the PCs > "obtained" via SLAAC. These entries seem to expire fairly quickly. > How do I see which IPv6 hosts are actively sending traffic through/to our > router? By checking "show ipv6 neighbors" - that's the active hosts. Most likely the "unseen rest" is onyl using IPv4... Alternatively, and if your IOS permits (I'm not sure about 12.2SB - 12.2S does not, 12.2SR and 12.4 definitely do) you could use IPv6 netflow. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From Jon.Harald.Bovre at hafslund.no Thu Apr 1 15:32:29 2010 From: Jon.Harald.Bovre at hafslund.no (=?iso-8859-1?Q?B=F8vre_Jon_Harald?=) Date: Thu, 1 Apr 2010 15:32:29 +0200 Subject: SV: IPv6 equivalent of ARP - possibly dumb question In-Reply-To: References: <20100401094131.GN69383@Space.Net>, Message-ID: Expiry timer should be 30 seconds use 'show ipv6 interface' to find exact timers Jon ________________________________________ Fra: ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de [ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de] på vegne av Frank Bulk - iName.com [frnkblk at iname.com] Sendt: 1. april 2010 15:16 Til: 'Gert Doering' Kopi: ipv6-ops at lists.cluenet.de Emne: RE: IPv6 equivalent of ARP - possibly dumb question Thanks for the insight. They must expire quickly. I pinged ipv6.google.com from a workstation and that showed up in "sh ipv6 nei" as ACTIVE. Very quickly it showed up as stale. Unfortunately, we don't have any netflow in place today. Frank -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Thursday, April 01, 2010 4:42 AM To: Frank Bulk - iName.com Cc: ipv6-ops at lists.cluenet.de Subject: Re: IPv6 equivalent of ARP - possibly dumb question Hi, On Wed, Mar 31, 2010 at 08:05:07AM -0500, Frank Bulk - iName.com wrote: > It's my understanding that the closest equivalent of ARP in IPv6 is "sh ipv6 > neighbors". When I do that on our Cisco 7206VXR running 12.2(31)SB16 I see > only a few addresses, not nearly all the ones that I know that the PCs > "obtained" via SLAAC. These entries seem to expire fairly quickly. > How do I see which IPv6 hosts are actively sending traffic through/to our > router? By checking "show ipv6 neighbors" - that's the active hosts. Most likely the "unseen rest" is onyl using IPv4... Alternatively, and if your IOS permits (I'm not sure about 12.2SB - 12.2S does not, 12.2SR and 12.4 definitely do) you could use IPv6 netflow. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From frnkblk at iname.com Thu Apr 1 15:38:31 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Thu, 1 Apr 2010 08:38:31 -0500 Subject: IPv6 equivalent of ARP - possibly dumb question In-Reply-To: References: <20100401094131.GN69383@Space.Net>, Message-ID: Would it be this last line? ICMP error messages limited to one every 100 milliseconds ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds ^^^^ Frank -----Original Message----- From: B?vre Jon Harald [mailto:Jon.Harald.Bovre at hafslund.no] Sent: Thursday, April 01, 2010 8:32 AM To: frnkblk at iname.com; 'Gert Doering' Cc: ipv6-ops at lists.cluenet.de Subject: SV: IPv6 equivalent of ARP - possibly dumb question Expiry timer should be 30 seconds use 'show ipv6 interface' to find exact timers Jon ________________________________________ Fra: ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de [ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de] på vegne av Frank Bulk - iName.com [frnkblk at iname.com] Sendt: 1. april 2010 15:16 Til: 'Gert Doering' Kopi: ipv6-ops at lists.cluenet.de Emne: RE: IPv6 equivalent of ARP - possibly dumb question Thanks for the insight. They must expire quickly. I pinged ipv6.google.com from a workstation and that showed up in "sh ipv6 nei" as ACTIVE. Very quickly it showed up as stale. Unfortunately, we don't have any netflow in place today. Frank -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Thursday, April 01, 2010 4:42 AM To: Frank Bulk - iName.com Cc: ipv6-ops at lists.cluenet.de Subject: Re: IPv6 equivalent of ARP - possibly dumb question Hi, On Wed, Mar 31, 2010 at 08:05:07AM -0500, Frank Bulk - iName.com wrote: > It's my understanding that the closest equivalent of ARP in IPv6 is "sh ipv6 > neighbors". When I do that on our Cisco 7206VXR running 12.2(31)SB16 I see > only a few addresses, not nearly all the ones that I know that the PCs > "obtained" via SLAAC. These entries seem to expire fairly quickly. > How do I see which IPv6 hosts are actively sending traffic through/to our > router? By checking "show ipv6 neighbors" - that's the active hosts. Most likely the "unseen rest" is onyl using IPv4... Alternatively, and if your IOS permits (I'm not sure about 12.2SB - 12.2S does not, 12.2SR and 12.4 definitely do) you could use IPv6 netflow. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From mloftis at wgops.com Thu Apr 1 16:09:09 2010 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 01 Apr 2010 08:09:09 -0600 Subject: IPv6 equivalent of ARP - possibly dumb question In-Reply-To: References: <20100401094131.GN69383@Space.Net> , Message-ID: <0D097704A9E9A9A1135AA1C0@[192.168.1.44]> --On Thursday, April 01, 2010 8:38 AM -0500 "Frank Bulk - iName.com" wrote: > Would it be this last line? First one actually. ND reachable. RA is for received RA's, not reachable neighbors. > > ICMP error messages limited to one every 100 milliseconds > ND reachable time is 30000 milliseconds > ND advertised reachable time is 0 milliseconds > ND advertised retransmit interval is 0 milliseconds > ND router advertisements are sent every 200 seconds > ND router advertisements live for 1800 seconds > ^^^^ > > Frank From Jon.Harald.Bovre at hafslund.no Thu Apr 1 16:10:39 2010 From: Jon.Harald.Bovre at hafslund.no (=?iso-8859-1?Q?B=F8vre_Jon_Harald?=) Date: Thu, 1 Apr 2010 16:10:39 +0200 Subject: SV: IPv6 equivalent of ARP - possibly dumb question In-Reply-To: References: <20100401094131.GN69383@Space.Net>, , Message-ID: No, it is 30 seconds (30000milliseconds) below is from debug ipv6 nd with a ping to neighbour: at 13:31:56.312 goes to REACH 30 seconds later: at 13:32:33.912 goes back to STALE Jon R3#sh ipv6 neighbors *Apr 1 13:31:49.952: ICMPv6-ND: REACH -> STALE: FE80::ping 2a02:270:1::2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2A02:270:1::2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms R3# *Apr 1 13:31:56.312: ICMPv6-ND: STALE -> DELAY: 2A02:270:1::2 *Apr 1 13:31:56.312: ICMPv6-ND: ULP indication 2A02:270:1::2 *Apr 1 13:31:56.312: ICMPv6-ND: DELAY -> REACH: 2A02:270:1::2 *Apr 1 13:32:01.316: ICMPv6-ND: Received NS for 2A02:270:1::3 on FastEthernet0/0.500 from FE80::201:C9FF:FE2B:4408 *Apr 1 13:32:01.316: ICMPv6-ND: Sending NA for 2A02:270:1::3 on FastEthernet0/0.500 *Apr 1 13:32:01.320: ICMPv6-ND: STALE -> DELAY: FE80::201:C9FF:FE2B:4408 *Apr 1 13:32:06.320: ICMPv6-ND: DELAY -> PROBE: FE80::201:C9FF:FE2B:4408 *Apr 1 13:32:06.320: ICMPv6-ND: Sending NS for FE80::201:C9FF:FE2B:4408 on FastEthernet0/0.500 *Apr 1 13:32:06.324: ICMPv6-ND: Received NA for FE80::201:C9FF:FE2B:4408 on FastEthernet0/0.500 from FE80::201:C9FF:FE2B:4408 *Apr 1 13:32:06.324: ICMPv6-ND: PROBE -> REACH: FE80::201:C9FF:FE2B:4408 *Apr 1 13:32:11.328: ICMPv6-ND: Received NS for FE80::205:DCFF:FEB3:4008 on FastEthernet0/0.500 from FE80::201:C9FF:FE2B:4408 *Apr 1 13:32:11.328: ICMPv6-ND: Sending NA for FE80::205:DCFF:FEB3:4008 on FastEthernet0/0.500 *Apr 1 13:32:17.908: ICMPv6-ND: Received RA from FE80::201:C9FF:FE2B:4408 on FastEthernet0/0.500 *Apr 1 13:32:24.064: ICMPv6-ND: Request to send RA for FE80::205:DCFF:FEB3:4008 *Apr 1 13:32:24.064: ICMPv6-ND: Sending RA from FE80::205:DCFF:FEB3:4008 to FF02::1 on FastEthernet0/0.500 *Apr 1 13:32:24.064: ICMPv6-ND: MTU = 1500 *Apr 1 13:32:24.064: ICMPv6-ND: prefix = 2A02:270::/64 onlink autoconfig *Apr 1 13:32:24.064: ICMPv6-ND: 2592000/604800 (valid/preferred) *Apr 1 13:32:24.064: ICMPv6-ND: prefix = 2A02:270:1::/64 onlink autoconfig *Apr 1 13:32:24.064: ICMPv6-ND: 2592000/604800 (valid/preferred) *Apr 1 13:32:33.912: ICMPv6-ND: REACH -> STALE: 2A02:270:1::2 ________________________________________ Fra: ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de [ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de] på vegne av Frank Bulk - iName.com [frnkblk at iname.com] Sendt: 1. april 2010 15:38 Til: B?vre Jon Harald; frnkblk at iname.com; 'Gert Doering' Kopi: ipv6-ops at lists.cluenet.de Emne: RE: IPv6 equivalent of ARP - possibly dumb question Would it be this last line? ICMP error messages limited to one every 100 milliseconds ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds ^^^^ Frank -----Original Message----- From: B?vre Jon Harald [mailto:Jon.Harald.Bovre at hafslund.no] Sent: Thursday, April 01, 2010 8:32 AM To: frnkblk at iname.com; 'Gert Doering' Cc: ipv6-ops at lists.cluenet.de Subject: SV: IPv6 equivalent of ARP - possibly dumb question Expiry timer should be 30 seconds use 'show ipv6 interface' to find exact timers Jon ________________________________________ Fra: ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de [ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de] på vegne av Frank Bulk - iName.com [frnkblk at iname.com] Sendt: 1. april 2010 15:16 Til: 'Gert Doering' Kopi: ipv6-ops at lists.cluenet.de Emne: RE: IPv6 equivalent of ARP - possibly dumb question Thanks for the insight. They must expire quickly. I pinged ipv6.google.com from a workstation and that showed up in "sh ipv6 nei" as ACTIVE. Very quickly it showed up as stale. Unfortunately, we don't have any netflow in place today. Frank -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Thursday, April 01, 2010 4:42 AM To: Frank Bulk - iName.com Cc: ipv6-ops at lists.cluenet.de Subject: Re: IPv6 equivalent of ARP - possibly dumb question Hi, On Wed, Mar 31, 2010 at 08:05:07AM -0500, Frank Bulk - iName.com wrote: > It's my understanding that the closest equivalent of ARP in IPv6 is "sh ipv6 > neighbors". When I do that on our Cisco 7206VXR running 12.2(31)SB16 I see > only a few addresses, not nearly all the ones that I know that the PCs > "obtained" via SLAAC. These entries seem to expire fairly quickly. > How do I see which IPv6 hosts are actively sending traffic through/to our > router? By checking "show ipv6 neighbors" - that's the active hosts. Most likely the "unseen rest" is onyl using IPv4... Alternatively, and if your IOS permits (I'm not sure about 12.2SB - 12.2S does not, 12.2SR and 12.4 definitely do) you could use IPv6 netflow. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From truman at suspicious.org Fri Apr 2 00:58:43 2010 From: truman at suspicious.org (Truman Boyes) Date: Thu, 1 Apr 2010 18:58:43 -0400 Subject: Linux utility for sending unsolicited neighbor advertisements In-Reply-To: <4BB1D50A.5000409@redpill-linpro.com> References: <4BB1D50A.5000409@redpill-linpro.com> Message-ID: Hi Tore, I would use scapy6. http://hg.natisbad.org/scapy6/summary Truman On 30/03/2010, at 6:40 AM, Tore Anderson wrote: > Hi list, > > I'm wondering if any of you know of a utility (for Linux) that can send > unsolicited neighbor advertisements as described in RFC 2461 section > 7.2.6? Something to match the functionality of "arping -U" in IPv4, > that is. > > Unsolicited neighbor advertisements appears necessary to facilitate > rapid service address takeover in a HA cluster, but so far I've had no > luck finding anything that can do it. > > BR, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 > From lists at quux.de Sat Apr 3 20:07:48 2010 From: lists at quux.de (Jens Link) Date: Sat, 03 Apr 2010 20:07:48 +0200 Subject: Which firmware for Linksys WRT54GL 1.1 and IPv6 Message-ID: <87tyrspfyj.fsf@bowmore.quux.de> Hi, I just wanted to flash a WRT54GL 1.1 with OpenWRT (8.09.2) and configure IPv6 with it. This doesn't work (insmod ipv6 insmod: unresolved symbol tcp_destroy_sock This is documented, but the ticket is closed as "works for me".) So which firmware should I try next? Or should I buy a Cisco for my parents? ;-) Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From gert at space.net Sat Apr 3 20:24:15 2010 From: gert at space.net (Gert Doering) Date: Sat, 3 Apr 2010 20:24:15 +0200 Subject: Which firmware for Linksys WRT54GL 1.1 and IPv6 In-Reply-To: <87tyrspfyj.fsf@bowmore.quux.de> References: <87tyrspfyj.fsf@bowmore.quux.de> Message-ID: <20100403182415.GJ69383@Space.Net> Hi, On Sat, Apr 03, 2010 at 08:07:48PM +0200, Jens Link wrote: > I just wanted to flash a WRT54GL 1.1 with OpenWRT (8.09.2) and configure > IPv6 with it. This doesn't work (insmod ipv6 insmod: unresolved symbol > tcp_destroy_sock This is documented, but the ticket is closed as "works > for me".) This has bitten me as well last week (and annoyed me like hell). I think the problem is that kernels for *some* architectures are compiled correctly, and the broadcom kernels are compiled with "IPv6 = no", which omits proper symbol exporting, so "insmod ipv6" fails. It is broken both for 2.4 and for 2.6 kernels... *sigh* I wanted to open a bug report, but forgot my WRT power supply at the customer site and couldn't yet properly verify it yet :-) (but if you open one, let me know and I'll second...) > So which firmware should I try next? Or should I buy a Cisco for my > parents? ;-) OpenWRT 7.09 does IPv6 (but you need to edit config files by hand, no www gui support yet). There's a 10.0 release candidate, but I have not tested that one yet. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From martin at airwire.ie Sat Apr 3 20:52:23 2010 From: martin at airwire.ie (Martin List-Petersen) Date: Sat, 03 Apr 2010 19:52:23 +0100 Subject: Which firmware for Linksys WRT54GL 1.1 and IPv6 In-Reply-To: <87tyrspfyj.fsf@bowmore.quux.de> References: <87tyrspfyj.fsf@bowmore.quux.de> Message-ID: <4BB78E67.9020301@airwire.ie> Jens Link wrote: > Hi, > > I just wanted to flash a WRT54GL 1.1 with OpenWRT (8.09.2) and configure > IPv6 with it. This doesn't work (insmod ipv6 insmod: unresolved symbol > tcp_destroy_sock This is documented, but the ticket is closed as "works > for me".) > > So which firmware should I try next? Or should I buy a Cisco for my > parents? ;-) Maybe you should opt for a AVM Fritz!Box or a Mikrotik Router before going down the Cisco route. Might be a lot cheaper (both do IPv6) It looks like the module either mismatches your kernel or the kernel wasn't compiled with IPv6 support (neither module, nor compiled in). Kind regards, Martin List-Petersen From lists at quux.de Sun Apr 4 14:02:24 2010 From: lists at quux.de (Jens Link) Date: Sun, 04 Apr 2010 14:02:24 +0200 Subject: Which firmware for Linksys WRT54GL 1.1 and IPv6 In-Reply-To: <20100403182415.GJ69383@Space.Net> (Gert Doering's message of "Sat\, 3 Apr 2010 20\:24\:15 +0200") References: <87tyrspfyj.fsf@bowmore.quux.de> <20100403182415.GJ69383@Space.Net> Message-ID: <87vdc78lyn.fsf@bowmore.quux.de> Gert Doering writes: > OpenWRT 7.09 does IPv6 (but you need to edit config files by hand, no > www gui support yet). Thanks, it's working now with 7.09. x-wrt.org offers a OpenWRT version with GUI (which has no IPv6 support) I'll report a bug againt 8.09.2 later today. cheers, -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From hahn at berkom.de Tue Apr 6 13:37:10 2010 From: hahn at berkom.de (Christian Hahn) Date: Tue, 06 Apr 2010 13:37:10 +0200 Subject: Which firmware for Linksys WRT54GL 1.1 and IPv6 In-Reply-To: <87tyrspfyj.fsf@bowmore.quux.de> References: <87tyrspfyj.fsf@bowmore.quux.de> Message-ID: <4BBB1CE6.4030506@berkom.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > Hi, > > I just wanted to flash a WRT54GL 1.1 with OpenWRT (8.09.2) and configure > IPv6 with it. This doesn't work (insmod ipv6 insmod: unresolved symbol > tcp_destroy_sock This is documented, but the ticket is closed as "works > for me".) > > So which firmware should I try next? Or should I buy a Cisco for my > parents? ;-) I have one running with 8.09, flashed at least half a year ago, and the kernel supports IPv6. If you want OpenWRT 8.* I would suggest to try out a slightly older release than 8.09.2. cheers, Christian > > Jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAku7HOMACgkQ6kMW7HW8621m+QCgyZphwSXyRafm5Nr1yjKE0O3p j3kAoJwUPS3wNqUEJZ8AloWCVCmqcLVv =9vpB -----END PGP SIGNATURE----- From steve at ibctech.ca Sat Apr 10 00:55:08 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 09 Apr 2010 18:55:08 -0400 Subject: Webstats gathering Message-ID: <4BBFB04C.8060809@ibctech.ca> Hi all, I'm looking for a recommendation on software, technique or a combination of both to extract data from a couple of years of web logs. Specifically, a successful combination must be able to do two things: read from a cronolog system, and identify IPv4 and IPv6 traffic separately. Here is how Apache is configured (I apologize for the wrap): ServerAdmin admin at ibctech.ca DocumentRoot /web/blog ServerName www.ipv6canada.com CustomLog "|/usr/local/sbin/cronolog /var/log/www/%Y/%m/%d/ipv6canada.com-access.log" common ErrorLog "|/usr/local/sbin/cronolog /var/log/www/%Y/%m/%d/ipv6canada.com-errors.log" I'm absolutely willing to perform some automated concat operations if necessary, but I'm curious as to whether there is a more elegant way that others are using. No stats have ever been gathered from these logs before. Cheers, Steve From tedm at ipinc.net Sat Apr 10 01:07:33 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 09 Apr 2010 16:07:33 -0700 Subject: Webstats gathering In-Reply-To: <4BBFB04C.8060809@ibctech.ca> References: <4BBFB04C.8060809@ibctech.ca> Message-ID: <4BBFB335.1050100@ipinc.net> Have you already tried the usual candidate: http://awstats.sourceforge.net/ Ted On 4/9/2010 3:55 PM, Steve Bertrand wrote: > Hi all, > > I'm looking for a recommendation on software, technique or a combination > of both to extract data from a couple of years of web logs. > > Specifically, a successful combination must be able to do two things: > read from a cronolog system, and identify IPv4 and IPv6 traffic separately. > > Here is how Apache is configured (I apologize for the wrap): > > > ServerAdmin admin at ibctech.ca > DocumentRoot /web/blog > ServerName www.ipv6canada.com > CustomLog "|/usr/local/sbin/cronolog > /var/log/www/%Y/%m/%d/ipv6canada.com-access.log" common > ErrorLog "|/usr/local/sbin/cronolog > /var/log/www/%Y/%m/%d/ipv6canada.com-errors.log" > > > I'm absolutely willing to perform some automated concat operations if > necessary, but I'm curious as to whether there is a more elegant way > that others are using. > > No stats have ever been gathered from these logs before. > > Cheers, > > Steve From steve at ibctech.ca Sat Apr 10 01:13:59 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 09 Apr 2010 19:13:59 -0400 Subject: Webstats gathering In-Reply-To: <4BBFB335.1050100@ipinc.net> References: <4BBFB04C.8060809@ibctech.ca> <4BBFB335.1050100@ipinc.net> Message-ID: <4BBFB4B7.2010604@ibctech.ca> On 2010.04.09 19:07, Ted Mittelstaedt wrote: > > Have you already tried the usual candidate: > > > http://awstats.sourceforge.net/ Nope, it's been a bit of a while. In the past, I've always used webalizer. It is apparent that I need to brush up on my googliage linguistics... usually I can find anything ;) Thanks Ted, I'll have a look. Steve From steve at ibctech.ca Sat Apr 10 01:35:23 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 09 Apr 2010 19:35:23 -0400 Subject: IPv6 network policies Message-ID: <4BBFB9BB.3070207@ibctech.ca> ...while I'm at it, I might as well ask a couple other questions that I've been contemplating recently. My network is _just_ under the size that two people can manage. We keep extensive documentation on almost absolutely everything (mostly automated). There are a couple of areas that are grey and sketchy though. One of these areas is ACL management. Although I use uRPF for everything, this doesn't fix the areas where ACLs are still needed (and in fact, I have ACLs in place on top of uRPF). An issue that I notice from time-to-time, is that I have an interface that has the appropriate v4 ACLs applied, but the v6 ones have been forgotten. What do other operators do to ensure consistency on ACL application in regards to both protocols? The other 'question' I have is regarding a very sensitive area. I do not want to get into a war about this. I figure that this list is exactly where I should ask. What I'm looking for is from _only_ those that use it, is how you document it, example config snips, if/how you reserve around it and from a topology standpoint how you alloc/assign it. I'm sorry, but I'm talking about /126 or /127 for ptp. I must admit, I am concerned with ping-pong and no real easy way to combat it, so I'd like operational feedback and education from those that use them without any traditional strong opinions from those that oppose it (if possible :) Steve From david.freedman at uk.clara.net Sat Apr 10 01:44:41 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Sat, 10 Apr 2010 00:44:41 +0100 Subject: IPv6 network policies In-Reply-To: <4BBFB9BB.3070207@ibctech.ca> Message-ID: On 10/04/2010 00:35, "Steve Bertrand" wrote: > ...while I'm at it, I might as well ask a couple other questions that > I've been contemplating recently. > > My network is _just_ under the size that two people can manage. We keep > extensive documentation on almost absolutely everything (mostly automated). > > There are a couple of areas that are grey and sketchy though. One of > these areas is ACL management. > > Although I use uRPF for everything, this doesn't fix the areas where > ACLs are still needed (and in fact, I have ACLs in place on top of uRPF). I can't have uRPF6 in many places due to lack of hardware support on my vendor's equipment. This means resorting to ACLs. We have a lot of ACLs :) > > An issue that I notice from time-to-time, is that I have an interface > that has the appropriate v4 ACLs applied, but the v6 ones have been > forgotten. What do other operators do to ensure consistency on ACL > application in regards to both protocols? Well, for us, we re-use the same framework we have in place for auditing compliance of components of existing infrastructure, for us it is just another check (i.e v4 acl present, v6 enabled, v6 acl should be present), whether you have a large multifaceted system for auditing configs, or just a set of simple scripts, the logic tests that can be applied remain the same. > > The other 'question' I have is regarding a very sensitive area. I do not > want to get into a war about this. I figure that this list is exactly > where I should ask. > > What I'm looking for is from _only_ those that use it, is how you > document it, example config snips, if/how you reserve around it and from > a topology standpoint how you alloc/assign it. I'm sorry, but I'm > talking about /126 or /127 for ptp. I must admit, I am concerned with > ping-pong and no real easy way to combat it, so I'd like operational > feedback and education from those that use them without any traditional > strong opinions from those that oppose it (if possible :) We use /126, no strong opinions, just trying to be kinder on cross training the folk who are comfortable with using IPv4 /30s. (we were never a /31 adopter) Dave. > > Steve > ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net From steve at ibctech.ca Sat Apr 10 01:55:20 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 09 Apr 2010 19:55:20 -0400 Subject: IPv6 network policies In-Reply-To: References: Message-ID: <4BBFBE68.2040309@ibctech.ca> On 2010.04.09 19:44, David Freedman wrote: > On 10/04/2010 00:35, "Steve Bertrand" wrote: >> Although I use uRPF for everything, this doesn't fix the areas where >> ACLs are still needed (and in fact, I have ACLs in place on top of uRPF). > > I can't have uRPF6 in many places due to lack of hardware support on my > vendor's equipment. This means resorting to ACLs. We have a lot of ACLs :) Well, given that we're a small shop, just look at it that 'I don't have uRPF6 in many places' and 'I do too' ;) >> An issue that I notice from time-to-time, is that I have an interface >> that has the appropriate v4 ACLs applied, but the v6 ones have been >> forgotten. What do other operators do to ensure consistency on ACL >> application in regards to both protocols? > > Well, for us, we re-use the same framework we have in place for auditing > compliance of components of existing infrastructure, for us it is just > another check (i.e v4 acl present, v6 enabled, v6 acl should be present), > whether you have a large multifaceted system for auditing configs, or just a > set of simple scripts, the logic tests that can be applied remain the same. Might I ask what you use for auditing? Does what you use for auditing work against/with the likes of a RANCID setup as opposed to polling the gear? iow, our auditing is limited to the op ensuring its done, and if not, someone catching in the RANCID change log that it wasn't done. ie. not yet automated. >> The other 'question' I have is regarding a very sensitive area. I do not >> want to get into a war about this. I figure that this list is exactly >> where I should ask. >> >> What I'm looking for is from _only_ those that use it, is how you >> document it, example config snips, if/how you reserve around it and from >> a topology standpoint how you alloc/assign it. I'm sorry, but I'm >> talking about /126 or /127 for ptp. I must admit, I am concerned with >> ping-pong and no real easy way to combat it, so I'd like operational >> feedback and education from those that use them without any traditional >> strong opinions from those that oppose it (if possible :) > > We use /126, no strong opinions, just trying to be kinder on cross training > the folk who are comfortable with using IPv4 /30s. (we were never a /31 > adopter) Ok. That works. I use /30. I'm more considerate to /126 (/30) than I am to the other. I've been using /64 for ptp, but am seriously reconsidering given the inability to combat what I've been lab'ing that could potentially become a nightmare. However, if I do change to this approach, I'm thinking that I'll reserve the encompassing /64, just in case. This is why I was curious about how these /12xs were being assigned. >From one specific block for the entire network, or in the same tradition as /30s are used (ie. steal from a delegation)? Thanks David, Steve From david.freedman at uk.clara.net Sat Apr 10 02:06:54 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Sat, 10 Apr 2010 01:06:54 +0100 Subject: IPv6 network policies In-Reply-To: <4BBFBE68.2040309@ibctech.ca> Message-ID: > > Might I ask what you use for auditing? Does what you use for auditing > work against/with the likes of a RANCID setup as opposed to polling the > gear? iow, our auditing is limited to the op ensuring its done, and if > not, someone catching in the RANCID change log that it wasn't done. ie. > not yet automated. Well, for us it is a simple set of scripts, each of which run periodically on the archived configs (i.e rancid) and produce reports on stuff which would normally cause engineers to raise an eyebrow, mailing them out for review. > Ok. That works. I use /30. I'm more considerate to /126 (/30) than I am > to the other. I see this just like the OSPF(v3) vs IS-IS argument, do what you feel most comfortable with. Our scheme is based on "least confusion principle", i.e /126 for p2p and /64 for anything larger, introducing stuff in the middle adds confusion and tends to either slow people down or induce greater amounts of human error (and yes, human error is always present as we know , despite modern automated provisioning systems!) > > This is why I was curious about how these /12xs were being assigned. > > From one specific block for the entire network, or in the same tradition > as /30s are used (ie. steal from a delegation)? We have a /64 for /126s, we only encourage use of these between routers (router to host we like to make as resilient as possible), we don't reserve anything more for a /126, if we need to expand the subnet then we move to a brand new /64. Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net From steve at ibctech.ca Sat Apr 10 03:26:16 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 09 Apr 2010 21:26:16 -0400 Subject: IPv6 network policies In-Reply-To: References: Message-ID: <4BBFD3B8.6050500@ibctech.ca> On 2010.04.09 20:06, David Freedman wrote: >> Might I ask what you use for auditing? Does what you use for auditing >> work against/with the likes of a RANCID setup as opposed to polling the >> gear? iow, our auditing is limited to the op ensuring its done, and if >> not, someone catching in the RANCID change log that it wasn't done. ie. >> not yet automated. > > Well, for us it is a simple set of scripts, each of which run periodically > on the archived configs (i.e rancid) and produce reports on stuff which > would normally cause engineers to raise an eyebrow, mailing them out for > review. Ok. That is trivial enough. >> This is why I was curious about how these /12xs were being assigned. >> >> From one specific block for the entire network, or in the same tradition >> as /30s are used (ie. steal from a delegation)? > > We have a /64 for /126s, we only encourage use of these between routers > (router to host we like to make as resilient as possible), we don't reserve > anything more for a /126, if we need to expand the subnet then we move to a > brand new /64. I guess this is what I was after. Correct me if I'm wrong, but what I hear you saying is that you have a single /64 reserved for the use of /126s across your entire network. Is that right? Steve From sm at resistor.net Sat Apr 10 06:41:28 2010 From: sm at resistor.net (SM) Date: Fri, 09 Apr 2010 21:41:28 -0700 Subject: Webstats gathering In-Reply-To: <4BBFB04C.8060809@ibctech.ca> References: <4BBFB04C.8060809@ibctech.ca> Message-ID: <6.2.5.6.2.20100409212645.0910d9b0@resistor.net> Hi Steve, At 15:55 09-04-10, Steve Bertrand wrote: >I'm looking for a recommendation on software, technique or a combination >of both to extract data from a couple of years of web logs. > >Specifically, a successful combination must be able to do two things: >read from a cronolog system, and identify IPv4 and IPv6 traffic separately. > >Here is how Apache is configured (I apologize for the wrap): > > It's better not to have a hostname there. If you are using name-based virtual hosts, you could rewrite it as: For the IPv6 case: Set the relevant directives to get a log for IPv4 and one for IPv6 traffic. Regards, -sm From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Apr 10 13:51:00 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 10 Apr 2010 21:21:00 +0930 Subject: IPv6 network policies In-Reply-To: <4BBFB9BB.3070207@ibctech.ca> References: <4BBFB9BB.3070207@ibctech.ca> Message-ID: <20100410212100.69bceb95@opy.nosense.org> On Fri, 09 Apr 2010 19:35:23 -0400 Steve Bertrand wrote: > ...while I'm at it, I might as well ask a couple other questions that > I've been contemplating recently. > > My network is _just_ under the size that two people can manage. We keep > extensive documentation on almost absolutely everything (mostly automated). > > There are a couple of areas that are grey and sketchy though. One of > these areas is ACL management. > > Although I use uRPF for everything, this doesn't fix the areas where > ACLs are still needed (and in fact, I have ACLs in place on top of uRPF). > > An issue that I notice from time-to-time, is that I have an interface > that has the appropriate v4 ACLs applied, but the v6 ones have been > forgotten. What do other operators do to ensure consistency on ACL > application in regards to both protocols? > > The other 'question' I have is regarding a very sensitive area. I do not > want to get into a war about this. I figure that this list is exactly > where I should ask. > > What I'm looking for is from _only_ those that use it, is how you > document it, example config snips, if/how you reserve around it and from > a topology standpoint how you alloc/assign it. I'm sorry, but I'm > talking about /126 or /127 for ptp. That may be a false fear. In the last week I've tried to cause this issue under IOS 12.3.20 (i.e. quite a number of years old) over a serial link, and no matter what I try, I cannot make it happen. I've tried both HDLC and PPP encapsulations, conventional address assignment, as well as using static interface routes for a /64 pointing out the serial interface on both routers at both ends of the link. RFC4443 (ICMPv6) specifies the rule against forwarding packets back onto the point-to-point link it was received on, and it seems IOS has been RFC4443 compliant for a number of years. I haven't tried it on a p2p POS link. I can organise a test one, however with what I've found with a vanilla serial link, I'm wondering if it is worth the time. I don't have Juniper equipment to play with, however they are also now claiming RFC4443 compliance for Junos 10.1. I did find that Linux does suffer from it. What I also discovered was that Linux and IOS aren't implementing complete Neighbor Discovery (i.e. NS/NA) on P2P links, and full ND NS/NA implementations won't suffer from this issue. I've started looking to find in the IPv6 RFCs if not implementing NS/NA on P2P links is allowable. I haven't found so in the Neighbor Discovery RFC and neither so in the IPv6 over PPP RFC. The current IPv6 Node Requirements RFC, which applies to both end-nodes and routers, also says ND NS/NA must be implemented on all links. I'd think the ND RFC would be authorative on this, and it says: point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point to point links, and interfaces can be assigned link-local addresses.) Neighbor Discovery should be implemented as described in this document. So it seems to me that the IPv6 protocol is being blamed for a problem that has been created by not implementing ND completely on P2P to links. If there is no text in RFCs allowing ND NS/NAs to be avoided on P2P links, then I wonder what impact that has on claims of IPv6 compliance that these implementations might be making. > I must admit, I am concerned with > ping-pong and no real easy way to combat it, so I'd like operational > feedback and education from those that use them without any traditional > strong opinions from those that oppose it (if possible :) > Make sure you read RFC3627. While it's title directly refers to /127s, it also covers some of the issues in using prefix lengths other than /64. In particular, the requirement to clear bits 70 and 71 correctly in all prefix lengths longer than /64s seems to be commonly overlooked. It does exist for /64s too, however as people commonly use static assignments starting at the least significant IID bits (i.e. :1, :2 etc.), and aren't likely to or need to create a node address hierarchy, these bits are cleared without active intention. As it's more likely that subnetting bits are going to structured with aggregation boundaries, then there needs to be a conscious effort to ensure they're always cleared. Regards, Mark. From sthaug at nethelp.no Sat Apr 10 16:38:16 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 10 Apr 2010 16:38:16 +0200 (CEST) Subject: IPv6 network policies In-Reply-To: <20100410212100.69bceb95@opy.nosense.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> Message-ID: <20100410.163816.74661976.sthaug@nethelp.no> > > What I'm looking for is from _only_ those that use it, is how you > > document it, example config snips, if/how you reserve around it and from > > a topology standpoint how you alloc/assign it. I'm sorry, but I'm > > talking about /126 or /127 for ptp. > > That may be a false fear. In the last week I've tried to cause this > issue under IOS 12.3.20 (i.e. quite a number of years old) over a > serial link, and no matter what I try, I cannot make it happen. I've > tried both HDLC and PPP encapsulations, conventional address assignment, > as well as using static interface routes for a /64 pointing out the > serial interface on both routers at both ends of the link. RFC4443 > (ICMPv6) specifies the rule against forwarding packets back onto the > point-to-point link it was received on, and it seems IOS has been > RFC4443 compliant for a number of years. > > I haven't tried it on a p2p POS link. I can organise a test one, > however with what I've found with a vanilla serial link, I'm wondering > if it is worth the time. I have a lab setup with an STM-4 link between a Cisco 12404 running IOS XR 3.9.0 and a Juniper M7i running JunOS 9.5R4.3. The loop is very clearly evident here, for anything other than /127 on the link. Can be reproduced at will. > I don't have Juniper equipment to play with, however they are also now > claiming RFC4443 compliance for Junos 10.1. That sounds like a good test for the lab. > What I also discovered was that Linux and IOS aren't implementing > complete Neighbor Discovery (i.e. NS/NA) on P2P links, and full ND > NS/NA implementations won't suffer from this issue. I've started looking > to find in the IPv6 RFCs if not implementing NS/NA on P2P > links is allowable. I haven't found so in the Neighbor Discovery RFC > and neither so in the IPv6 over PPP RFC. The current IPv6 Node > Requirements RFC, which applies to both end-nodes and routers, also > says ND NS/NA must be implemented on all links. As far as I can see on the IOS XR and JunOS boxes I have tried with, ND is *not* performed at all on p2p links. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From otroan at employees.org Sat Apr 10 16:47:16 2010 From: otroan at employees.org (Ole Troan) Date: Sat, 10 Apr 2010 16:47:16 +0200 Subject: IPv6 network policies In-Reply-To: <20100410212100.69bceb95@opy.nosense.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> Message-ID: <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> > So it seems to me that the IPv6 protocol is being blamed for a problem > that has been created by not implementing ND completely on P2P to > links. If there is no text in RFCs allowing ND NS/NAs to be avoided on > P2P links, then I wonder what impact that has on claims of IPv6 > compliance that these implementations might be making. ND has many functions. one of them is address resolution. that's not done on a link without L2 addresses. NUD could be done, but on most router to router links it is unnecessary and not used. is it a requirement to verify reachability before communicating with any node on an IPv6 link? no, and I can find little support for that position in any IPv6 RFC. note, that the ping pong problem isn't an IPv6 problem as such, the same problem exists with IPv4. cheers, Ole From sthaug at nethelp.no Sat Apr 10 17:39:36 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 10 Apr 2010 17:39:36 +0200 (CEST) Subject: IPv6 network policies In-Reply-To: <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> Message-ID: <20100410.173936.41722712.sthaug@nethelp.no> > note, that the ping pong problem isn't an IPv6 problem as such, the same problem exists with IPv4. Absolutely. And for an IPv4 p2p link it seems the most commonly used solution is to use /31 on the link. For IPv6 it seems to me we have two camps with different philosophies: - The ping pong problem *should* be solved in IPv6, and it can be solved if the vendors do . - The ping pong problem doesn't need to be solved in IPv6 since using a /127 works just fine. So let's bless the /127. Given that http://tools.ietf.org/html/draft-ietf-ipngwg-p2p-pingpong-00 is from 2001, and nine years later there are still large/important vendors that have this problem - is it likely that it *will* be solved in the manner suggested by this draft? Steinar Haug, Nethelp consulting, sthaug at nethelp.no From otroan at employees.org Sat Apr 10 18:26:04 2010 From: otroan at employees.org (Ole Troan) Date: Sat, 10 Apr 2010 18:26:04 +0200 Subject: IPv6 network policies In-Reply-To: <20100410.173936.41722712.sthaug@nethelp.no> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100410.173936.41722712.sthaug@nethelp.no> Message-ID: >> note, that the ping pong problem isn't an IPv6 problem as such, the same problem exists with IPv4. > > Absolutely. And for an IPv4 p2p link it seems the most commonly used > solution is to use /31 on the link. > > For IPv6 it seems to me we have two camps with different philosophies: > > - The ping pong problem *should* be solved in IPv6, and it can be solved > if the vendors do . > > - The ping pong problem doesn't need to be solved in IPv6 since using > a /127 works just fine. So let's bless the /127. > > Given that > > http://tools.ietf.org/html/draft-ietf-ipngwg-p2p-pingpong-00 > > is from 2001, and nine years later there are still large/important > vendors that have this problem - is it likely that it *will* be solved > in the manner suggested by this draft? the solution in the draft is incorporated into RFC4443. but yes, I share your sentiment. there seems to be sub-camp suggesting the use of ND "pseudo" address resolution on point to point links too. cheers, Ole From sthaug at nethelp.no Sat Apr 10 20:15:24 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 10 Apr 2010 20:15:24 +0200 (CEST) Subject: IPv6 network policies In-Reply-To: <20100410.163816.74661976.sthaug@nethelp.no> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <20100410.163816.74661976.sthaug@nethelp.no> Message-ID: <20100410.201524.71180317.sthaug@nethelp.no> > I have a lab setup with an STM-4 link between a Cisco 12404 running > IOS XR 3.9.0 and a Juniper M7i running JunOS 9.5R4.3. The loop is very > clearly evident here, for anything other than /127 on the link. Can be > reproduced at will. > > > I don't have Juniper equipment to play with, however they are also now > > claiming RFC4443 compliance for Junos 10.1. > > That sounds like a good test for the lab. The JunOS 10.1 Release Notes lists following under "Outstanding Issues": "If you ping a nonexistent IPv6 address that belongs to the same subnet as an existing point-to-point link, the packet loops between the two point-to-point interfaces until the time-to-live expires. [PR/94954]" And indeed lab verification shows that this problem still exists for JunOS 10.1. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From michael.dillon at bt.com Sat Apr 10 21:31:05 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 10 Apr 2010 20:31:05 +0100 Subject: IPv6 network policies In-Reply-To: <20100410.173936.41722712.sthaug@nethelp.no> Message-ID: <28E139F46D45AF49A31950F88C49745805BCEB61@E03MVZ2-UKDY.domain1.systemhost.net> > For IPv6 it seems to me we have two camps with different philosophies: > > - The ping pong problem *should* be solved in IPv6, and it > can be solved if the vendors do . > > - The ping pong problem doesn't need to be solved in IPv6 > since using a /127 works just fine. So let's bless the /127. What about the pragmatic camp? Reserve a /64 for every PTP link and actually configure a /127 (or /126). This has the advantage of shorter and more memorable prefixes, i.e. 2001:DB8:1:77::/64 would be reserved and 2001:DB8:1:77::/127 would be configured. > Given that > > http://tools.ietf.org/html/draft-ietf-ipngwg-p2p-pingpong-00 > > is from 2001, and nine years later there are still > large/important vendors that have this problem - is it likely > that it *will* be solved in the manner suggested by this draft? It's still early days for IPv6. As more people deploy it and feedback their needs to vendors, more things will get fixed and adjusted. There has been a sad tendency for people to stumble upon a problem with v6 and to use that as an excuse for not deploying, without escalating the stumbling block to where it can be resolved. Now that people are being forced to deploy due to IPv4 runout, they are more likely to get the message to vendors that something needs to be fixed. If and when ping-ponging is fixed, anyone who has reserved a /64 for each PTP connection can switch to configuring the whole /64 if it simplifies Operational Support Systems. Configure it how you want, just don't back yourself into a corner trying to achieve some mythical efficiency that just doesn't exist in IPv6, and is unlikely to cause problems until your great-grandchildren are running the network. --Michael Dillon From sthaug at nethelp.no Sat Apr 10 21:42:26 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 10 Apr 2010 21:42:26 +0200 (CEST) Subject: IPv6 network policies In-Reply-To: <28E139F46D45AF49A31950F88C49745805BCEB61@E03MVZ2-UKDY.domain1.systemhost.net> References: <20100410.173936.41722712.sthaug@nethelp.no> <28E139F46D45AF49A31950F88C49745805BCEB61@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20100410.214226.39243053.sthaug@nethelp.no> > > For IPv6 it seems to me we have two camps with different philosophies: > > > > - The ping pong problem *should* be solved in IPv6, and it > > can be solved if the vendors do . > > > > - The ping pong problem doesn't need to be solved in IPv6 > > since using a /127 works just fine. So let's bless the /127. > > What about the pragmatic camp? Reserve a /64 for every PTP > link and actually configure a /127 (or /126). A /126 has the same ping pong problem as a /64 in my tests. > This has the > advantage of shorter and more memorable prefixes, i.e. > 2001:DB8:1:77::/64 would be reserved and 2001:DB8:1:77::/127 > would be configured. Reserving a /64 for a customer link is fine. I see zero advantages in doing so for backbone router-router links. > If and when ping-ponging is fixed, anyone who has reserved a /64 > for each PTP connection can switch to configuring the whole > /64 if it simplifies Operational Support Systems. *If*. I'm afraid such simplification is not visible from my point of view. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 11 01:12:12 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 11 Apr 2010 08:42:12 +0930 Subject: IPv6 network policies In-Reply-To: References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100410.173936.41722712.sthaug@nethelp.no> Message-ID: <20100411084212.71676b2d@opy.nosense.org> On Sat, 10 Apr 2010 18:26:04 +0200 Ole Troan wrote: > >> note, that the ping pong problem isn't an IPv6 problem as such, the same problem exists with IPv4. > > > > Absolutely. And for an IPv4 p2p link it seems the most commonly used > > solution is to use /31 on the link. > > > > For IPv6 it seems to me we have two camps with different philosophies: > > > > - The ping pong problem *should* be solved in IPv6, and it can be solved > > if the vendors do . > > > > - The ping pong problem doesn't need to be solved in IPv6 since using > > a /127 works just fine. So let's bless the /127. > > > > Given that > > > > http://tools.ietf.org/html/draft-ietf-ipngwg-p2p-pingpong-00 > > > > is from 2001, and nine years later there are still large/important > > vendors that have this problem - is it likely that it *will* be solved > > in the manner suggested by this draft? > > the solution in the draft is incorporated into RFC4443. but yes, I share your sentiment. > > there seems to be sub-camp suggesting the use of ND "pseudo" address resolution on point to point links too. > Doesn't the RFC4861 mandate that i.e. point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast capability and a link-local address. I can't find any text that treats P2P links as a special case and says you don't need to do ND NS/NA. Regards, Mark. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 11 01:38:34 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 11 Apr 2010 09:08:34 +0930 Subject: IPv6 network policies In-Reply-To: <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> Message-ID: <20100411090834.242fb2e1@opy.nosense.org> On Sat, 10 Apr 2010 16:47:16 +0200 Ole Troan wrote: > > So it seems to me that the IPv6 protocol is being blamed for a problem > > that has been created by not implementing ND completely on P2P to > > links. If there is no text in RFCs allowing ND NS/NAs to be avoided on > > P2P links, then I wonder what impact that has on claims of IPv6 > > compliance that these implementations might be making. > > ND has many functions. one of them is address resolution. that's not done on a link without L2 addresses. IPv6 PPP does negotiate 64 bit IIDs, so in effect I think it's going close to creating L2 addresses on P2P links. I think that as those IIDs are not a single bit in size (i.e. "are you going to be 0, because then I'll be 1"), that also supports the idea that P2P links aren't meant to be treated specially by IPv6. > NUD could be done, but on most router to router links it is > unnecessary and not used. > I suppose this comes down to if you don't agree with (or maybe just don't fully understand) the way something works in an RFC, does that mean it's ok for you not to implement it the way the RFC says? For a long time, IPv6 has been designed on the assumption of a single 64 bit IIDs and therefore subnets that have very large amounts of address space. Running ND NS/NA on all link types, as the ND RFCs say should be done, protects against the ping pong problem. It seems to me that in this case people have used existing IPv4 (P2P) methods to guide their IPv6 implementation too much, rather than putting more weight on the IPv6 RFCs. > is it a requirement to verify reachability before communicating with any node on an IPv6 link? no, and I can find little support for that position in any IPv6 RFC. > > note, that the ping pong problem isn't an IPv6 problem as such, the same problem exists with IPv4. > True. However, although IPv4 PPP doesn't protect against it, IPv4 PPP did a lot more neighbor discovery functions i.e. IPCP address negotation. As a lot of that functionality has been generalised to to over the top of ICMPv6, i.e. a significant design change over IPv4, as I said above, IPv4 is probably not a strong model of how IPv6 over P2P links was expected to operate. Regards, Mark. From brian.e.carpenter at gmail.com Sun Apr 11 01:41:49 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 11 Apr 2010 11:41:49 +1200 Subject: IPv6 network policies In-Reply-To: <20100411084212.71676b2d@opy.nosense.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100410.173936.41722712.sthaug@nethelp.no> <20100411084212.71676b2d@opy.nosense.org> Message-ID: <4BC10CBD.8000806@gmail.com> On 2010-04-11 11:12, Mark Smith wrote: ... > Doesn't the RFC4861 mandate that i.e. > > point-to-point - a link that connects exactly two interfaces. A > point-to-point link is assumed to have multicast > capability and a link-local address. > > > I can't find any text that treats P2P links as a special case and says > you don't need to do ND NS/NA. E.g., when using PPP, all IP6CP [RFC5072] does is negotiate an interface identifier for each end. After that you create a link-local address at each end and then treat the Pt2Pt link just like any other link to get a global address. Nothing special. Brian From jimb at jsbc.cc Sun Apr 11 01:46:22 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sat, 10 Apr 2010 16:46:22 -0700 Subject: IPv6 network policies In-Reply-To: <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> Message-ID: <4BC10DCE.5060909@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/10/2010 07:47, Ole Troan wrote: > note, that the ping pong problem isn't an IPv6 problem as such, the same problem exists with IPv4. > > cheers, > Ole > Yes. The ping-pong problem can be easily demonstrated on my 6in4 link. My simple solution is two ACL entries: Router A: ip6tables --append FORWARD --destination 2001:db8:1234:567::1/128 - -out-interface he6 --jump ACCEPT ip6tables --append FORWARD --destination 2001:db8:1234:567::/64 - -out-interface he6 --jump REJECT --reject-with icmp6-adm-prohibited Router B: ip6tables --append FORWARD --destination 2001:db8:1234:567::2/128 - -out-interface he6 --jump ACCEPT ip6tables --append FORWARD --destination 2001:db8:1234:567::/64 - -out-interface he6 --jump REJECT --reject-with icmp6-adm-prohibited If this is done at both ends it eliminates the issue. Most routers can do something similar. Be nice if the router could do it automagically, but this works. :) - -Jim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvBDc4ACgkQ2fXFxl4S7sRpTwCgi6XoMUZHCQKWNfJii1KyXs+k 7WUAn3B3hmXzfam2UnuT+sVFEe0Rc4bJ =3UyU -----END PGP SIGNATURE----- From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 11 02:19:29 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 11 Apr 2010 09:49:29 +0930 Subject: IPv6 network policies In-Reply-To: <20100410.163816.74661976.sthaug@nethelp.no> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <20100410.163816.74661976.sthaug@nethelp.no> Message-ID: <20100411094929.764742a2@opy.nosense.org> Hi Steinar, On Sat, 10 Apr 2010 16:38:16 +0200 (CEST) sthaug at nethelp.no wrote: > > > What I'm looking for is from _only_ those that use it, is how you > > > document it, example config snips, if/how you reserve around it and from > > > a topology standpoint how you alloc/assign it. I'm sorry, but I'm > > > talking about /126 or /127 for ptp. > > > > That may be a false fear. In the last week I've tried to cause this > > issue under IOS 12.3.20 (i.e. quite a number of years old) over a > > serial link, and no matter what I try, I cannot make it happen. I've > > tried both HDLC and PPP encapsulations, conventional address assignment, > > as well as using static interface routes for a /64 pointing out the > > serial interface on both routers at both ends of the link. RFC4443 > > (ICMPv6) specifies the rule against forwarding packets back onto the > > point-to-point link it was received on, and it seems IOS has been > > RFC4443 compliant for a number of years. > > > > I haven't tried it on a p2p POS link. I can organise a test one, > > however with what I've found with a vanilla serial link, I'm wondering > > if it is worth the time. > > I have a lab setup with an STM-4 link between a Cisco 12404 running > IOS XR 3.9.0 and a Juniper M7i running JunOS 9.5R4.3. The loop is very > clearly evident here, for anything other than /127 on the link. Can be > reproduced at will. > So it seems that the difference might be hardware vs software forwarding implementations. > > I don't have Juniper equipment to play with, however they are also now > > claiming RFC4443 compliance for Junos 10.1. > > That sounds like a good test for the lab. > > > What I also discovered was that Linux and IOS aren't implementing > > complete Neighbor Discovery (i.e. NS/NA) on P2P links, and full ND > > NS/NA implementations won't suffer from this issue. I've started looking > > to find in the IPv6 RFCs if not implementing NS/NA on P2P > > links is allowable. I haven't found so in the Neighbor Discovery RFC > > and neither so in the IPv6 over PPP RFC. The current IPv6 Node > > Requirements RFC, which applies to both end-nodes and routers, also > > says ND NS/NA must be implemented on all links. > > As far as I can see on the IOS XR and JunOS boxes I have tried with, > ND is *not* performed at all on p2p links. > I found a couple of other things that I found that might be interesting to verify or test in your lab. Firstly, I did find that the IOS version I tested had DAD enabled by default, and was performing it (i.e. an NS/NA transaction for the new address). The 'show ipv6 interface' output will show what the DAD status is. In the case of PPP encapsulation, this is despite the IPv6 PPP RFC recommending it is switched off, excepting a few cases that my test scenario doesn't satisfy. I'd think if these implementations are interested in optimising away general NS/NA on P2P links, they'd also default DAD to off on them too. Secondly, if you view the subscribed IPv6 multicast groups on the interface, the interface is subscribed to IPv6 solicited node groups for addresses that have been assigned to it. If those same observations carry through to hardware platforms such as the ones you have, that says to me that the interfaces have all the mechanisms required to perform full, general ND, with the only thing missing i.e disabled, is a neighbor cache and ND NS/NAs for addresses that fall within the subnet. IOW, fixing the ping pong issue should be as simple as a fairly straight forward change to the code to stop treating P2P links as a special case. Regards, Mark. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 11 02:39:59 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 11 Apr 2010 10:09:59 +0930 Subject: IPv6 network policies In-Reply-To: <4BC10CBD.8000806@gmail.com> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100410.173936.41722712.sthaug@nethelp.no> <20100411084212.71676b2d@opy.nosense.org> <4BC10CBD.8000806@gmail.com> Message-ID: <20100411100959.0b56ca63@opy.nosense.org> On Sun, 11 Apr 2010 11:41:49 +1200 Brian E Carpenter wrote: > On 2010-04-11 11:12, Mark Smith wrote: > ... > > Doesn't the RFC4861 mandate that i.e. > > > > point-to-point - a link that connects exactly two interfaces. A > > point-to-point link is assumed to have multicast > > capability and a link-local address. > > Actually this is the text I meant to quote: point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point-to-point links, and interfaces can be assigned link-local addresses.) multicast - Neighbor Discovery operates over multicast capable links as described in this document. The preceding ND RFC (RFC2461) was more explicit: point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point to point links, and interfaces can be assigned link-local addresses.) Neighbor Discovery should be implemented as described in this document. multicast - Neighbor Discovery should be implemented as described in this document. > > > > I can't find any text that treats P2P links as a special case and says > > you don't need to do ND NS/NA. > > E.g., when using PPP, all IP6CP [RFC5072] does is negotiate an > interface identifier for each end. After that you create a link-local > address at each end and then treat the Pt2Pt link just like any other > link to get a global address. Nothing special. > > Brian From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 11 03:07:13 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 11 Apr 2010 10:37:13 +0930 Subject: IPv6 network policies In-Reply-To: <20100411090834.242fb2e1@opy.nosense.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100411090834.242fb2e1@opy.nosense.org> Message-ID: <20100411103713.3ce0e5d7@opy.nosense.org> On Sun, 11 Apr 2010 09:08:34 +0930 Mark Smith wrote: > On Sat, 10 Apr 2010 16:47:16 +0200 > Ole Troan wrote: > > > > So it seems to me that the IPv6 protocol is being blamed for a problem > > > that has been created by not implementing ND completely on P2P to > > > links. If there is no text in RFCs allowing ND NS/NAs to be avoided on > > > P2P links, then I wonder what impact that has on claims of IPv6 > > > compliance that these implementations might be making. > > > > ND has many functions. one of them is address resolution. that's not done on a link without L2 addresses. > > IPv6 PPP does negotiate 64 bit IIDs, so in effect I think it's going > close to creating L2 addresses on P2P links. I think that as those IIDs > are not a single bit in size (i.e. "are you going to be 0, because then > I'll be 1"), that also supports the idea that P2P links aren't meant > to be treated specially by IPv6. > > > NUD could be done, but on most router to router links it is > > unnecessary and not used. > > > > I suppose this comes down to if you don't agree with (or maybe just > don't fully understand) the way something works in an RFC, does that > mean it's ok for you not to implement it the way the RFC says? > > For a long time, IPv6 has been designed on the assumption of a > single 64 bit IIDs and therefore subnets that have very large amounts that should have read "single size, 64 bit IIDs" > of address space. Running ND NS/NA on all link types, as the ND RFCs > say should be done, protects against the ping pong problem. > > It seems to me that in this case people have used existing IPv4 > (P2P) methods to guide their IPv6 implementation too much, rather than > putting more weight on the IPv6 RFCs. > > > is it a requirement to verify reachability before communicating with any node on an IPv6 link? no, and I can find little support for that position in any IPv6 RFC. > > > > > note, that the ping pong problem isn't an IPv6 problem as such, the same problem exists with IPv4. > > > > True. However, although IPv4 PPP doesn't protect against it, IPv4 PPP > did a lot more neighbor discovery functions i.e. IPCP address > negotation. As a lot of that functionality has been generalised to to > over the top of ICMPv6, i.e. a significant design change over IPv4, as > I said above, IPv4 is probably not a strong model of how IPv6 over P2P > links was expected to operate. > > Regards, > Mark. From swmike at swm.pp.se Sun Apr 11 03:16:34 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 11 Apr 2010 03:16:34 +0200 (CEST) Subject: IPv6 network policies In-Reply-To: <20100410.173936.41722712.sthaug@nethelp.no> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100410.173936.41722712.sthaug@nethelp.no> Message-ID: On Sat, 10 Apr 2010, sthaug at nethelp.no wrote: >> note, that the ping pong problem isn't an IPv6 problem as such, the same problem exists with IPv4. > > Absolutely. And for an IPv4 p2p link it seems the most commonly used > solution is to use /31 on the link. Errr, a /30 IPv4 configured with "no ip directed-broadcast" (or equivalent) won't forward packets to the first and last address of the /30, so the problem doesn't exist there. -- Mikael Abrahamsson email: swmike at swm.pp.se From sthaug at nethelp.no Sun Apr 11 08:18:58 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 11 Apr 2010 08:18:58 +0200 (CEST) Subject: IPv6 network policies In-Reply-To: References: <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100410.173936.41722712.sthaug@nethelp.no> Message-ID: <20100411.081858.74718912.sthaug@nethelp.no> > > Absolutely. And for an IPv4 p2p link it seems the most commonly used > > solution is to use /31 on the link. > > Errr, a /30 IPv4 configured with "no ip directed-broadcast" (or > equivalent) won't forward packets to the first and last address of the > /30, so the problem doesn't exist there. Agreed. While a /126 on an IPv6 p2p link *does* show the problem in my lab testing. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From otroan at employees.org Sun Apr 11 08:32:08 2010 From: otroan at employees.org (Ole Troan) Date: Sun, 11 Apr 2010 08:32:08 +0200 Subject: IPv6 network policies In-Reply-To: <20100411090834.242fb2e1@opy.nosense.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100411090834.242fb2e1@opy.nosense.org> Message-ID: <2A7E7443-03C0-47CA-982F-6AC228B59A12@employees.org> >> NUD could be done, but on most router to router links it is >> unnecessary and not used. >> > > I suppose this comes down to if you don't agree with (or maybe just > don't fully understand) the way something works in an RFC, does that > mean it's ok for you not to implement it the way the RFC says? good to hear that you are the authority on how RFC4861 should be read (note this may be sarcasm. ;-)). please point us to the sections in RFC4861 which require an implementation to do address resolution on a link without L2 addresses. and if it is not address resolution, which part of ND are you referring to? references to the ipng mail archive would also be appreciated. cheers, Ole From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 11 09:55:21 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 11 Apr 2010 17:25:21 +0930 Subject: IPv6 network policies In-Reply-To: <2A7E7443-03C0-47CA-982F-6AC228B59A12@employees.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100411090834.242fb2e1@opy.nosense.org> <2A7E7443-03C0-47CA-982F-6AC228B59A12@employees.org> Message-ID: <20100411172521.5bd80cf3@opy.nosense.org> On Sun, 11 Apr 2010 08:32:08 +0200 Ole Troan wrote: > >> NUD could be done, but on most router to router links it is > >> unnecessary and not used. > >> > > > > I suppose this comes down to if you don't agree with (or maybe just > > don't fully understand) the way something works in an RFC, does that > > mean it's ok for you not to implement it the way the RFC says? > > good to hear that you are the authority on how RFC4861 should be read (note this may be sarcasm. ;-)). > please point us to the sections in RFC4861 which require an implementation to do address resolution on a link without L2 addresses. and if it is not address resolution, which part of ND are you referring to? > I've quoted the sections of that RFC (and it's ancestor) twice to this thread already that support this view. I've also looked through the ND RFCs for any statements that specifically refer to the operation of ND over P2P links, and what is optional. I can't find any. It's well known that the pong pong problem doesn't exist if ND NS/NAs are used. The IPv6 PPP spec negotiates 64 bit IDs for ends of links. As P2P links only have two attachments, then I think that also supports /64s per PPP link, and therefore ND NS/NA. As the PPP RFC does deal with neighbor discovery issues (i.e. the DAD clauses) I'd expect it'd also specify that ND NS/NAs could be switched off, if that was allowed. It doesn't. The IPv6 Node Requirements RFC doesn't make a special case of P2P links in it's Neighbor Discovery section. The only (Informational) RFC I can find that refers to running IPv6 over SONET (i.e. the case people commonly refer to when pointing out the ping pong problem), RFC3572 - "Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)", does not state that it is acceptable to not perform NS NS/NAs. It does specify the use of EUI-64s instead of MAPOS link layer addresses, which naturally implies /64 assignment. As people commonly run PPP over SONET anyway, whatever the IPv6 PPP RFC says about ND operation is applicable. I'm yet to have anybody provide a reference to text in any RFC that says this "optimisation" is allowed. I made that invitation quite a number of emails ago. If such text exists, I'd like to read it. The invitation to provide it is still open. The sooner I can find out I'm wrong, the sooner I'll be right. But I won't just take people's opinions to change mine, because I've been burnt enough in the past taking peoples' statements at face value. (Here's an example. If you want to create a static sink route on a Cisco router, can you use an Admin Distance of 255?) > references to the ipng mail archive would also be appreciated. > Aren't RFCs supposed to be authoritative? Regards, Mark. From michael.dillon at bt.com Sun Apr 11 09:58:23 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 11 Apr 2010 08:58:23 +0100 Subject: IPv6 network policies In-Reply-To: <20100410.214226.39243053.sthaug@nethelp.no> Message-ID: <28E139F46D45AF49A31950F88C49745805BCEBA3@E03MVZ2-UKDY.domain1.systemhost.net> > Reserving a /64 for a customer link is fine. I see zero > advantages in doing so for backbone router-router links. I see zero advantages in NOT reserving a /64 for every PTP link. And using a simple shortened /127 or /126 from the beginning of the /64, seems to me to be an advantage operationally. > > If and when ping-ponging is fixed, anyone who has reserved > a /64 for > > each PTP connection can switch to configuring the whole > > /64 if it simplifies Operational Support Systems. > > *If*. I'm afraid such simplification is not visible from my > point of view. OSS means software. It is rather less predicatable what kind of software packages you might need to work with in future. Companies get merged, and suddenly you have to shift all of your operational data to another OSS package. If you run into an OSS package that only can accept a /64 prefix for PTP links, you just feed it with your reserved /64 regardless of what you actually have configured. There just is nothing to lose by reserving a /64 for every network, PTP or otherwise. --Michael Dillon From gert at space.net Sun Apr 11 11:15:38 2010 From: gert at space.net (Gert Doering) Date: Sun, 11 Apr 2010 11:15:38 +0200 Subject: IPv6 network policies In-Reply-To: <20100410212100.69bceb95@opy.nosense.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> Message-ID: <20100411091538.GQ69383@Space.Net> Hi, On Sat, Apr 10, 2010 at 09:21:00PM +0930, Mark Smith wrote: > What I also discovered was that Linux and IOS aren't implementing > complete Neighbor Discovery (i.e. NS/NA) on P2P links, I always wondered why anyone would *want* to implement ND on P2P links. After all, you know that there is only two entities on the link, so if the packet isn't for you, it must be for them - and there is no need to construct a l2 address header for POS or PPP links. So all "full ND" gains you is "more overhead" and "larger attack surface on the router". Yes, the corrolary is "packets might loop", but this is what RFC4443 takes into account. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From alex at digriz.org.uk Sun Apr 11 12:33:39 2010 From: alex at digriz.org.uk (Alexander Clouter) Date: Sun, 11 Apr 2010 11:33:39 +0100 Subject: IPv6 network policies References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <4BC10DCE.5060909@jsbc.cc> Message-ID: <35l897-mj3.ln1@chipmunk.wormnet.eu> Jim Burwell wrote: > > Yes. The ping-pong problem can be easily demonstrated on my 6in4 > link. My simple solution is two ACL entries: > > Router A: > ip6tables --append FORWARD --destination 2001:db8:1234:567::1/128 > - -out-interface he6 --jump ACCEPT > ip6tables --append FORWARD --destination 2001:db8:1234:567::/64 > - -out-interface he6 --jump REJECT --reject-with icmp6-adm-prohibited > That's an ugly use of icmp6-adm-prohibited if I might say. A better approach IMO: ---- ip route add unreachable ---- This then only needs to be done at your end, which is the correct thing to do (as you are the one using the default route). Cheers -- Alexander Clouter .sigmonster says: I hope the ``Eurythmics'' practice birth control ... From dkluge at acm.org Sun Apr 11 15:40:17 2010 From: dkluge at acm.org (Daniel G. Kluge) Date: Sun, 11 Apr 2010 15:40:17 +0200 Subject: Which firmware for Linksys WRT54GL 1.1 and IPv6 In-Reply-To: <4BBB1CE6.4030506@berkom.de> References: <87tyrspfyj.fsf@bowmore.quux.de> <4BBB1CE6.4030506@berkom.de> Message-ID: Am 06.04.2010 um 13:37 schrieb Christian Hahn: >> >> I just wanted to flash a WRT54GL 1.1 with OpenWRT (8.09.2) and configure >> IPv6 with it. This doesn't work (insmod ipv6 insmod: unresolved symbol >> tcp_destroy_sock This is documented, but the ticket is closed as "works >> for me".) >> >> So which firmware should I try next? Or should I buy a Cisco for my >> parents? ;-) > I have one running with 8.09, flashed at least half a year ago, and the kernel > supports IPv6. If you want OpenWRT 8.* I would suggest to try out a slightly > older release than 8.09.2. > You just made me look again, I'm running KAMIKAZE (8.09.1, r16278) on my WRT54GL, and it servers as my IPv6 yunnel endpoint. So that binary worked just fine. And here some handy notes I keep for the installation (That was eight months ago, and it has been running since). Necessary packages for IPv6: aiccu radvd kmod-ipv6 kmod-tun ip Optional packages I need/like: minupnpd ip6tables ntpclient tcpdump Cheers, -daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100411/c4745691/attachment.html From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Apr 11 16:25:36 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 11 Apr 2010 23:55:36 +0930 Subject: IPv6 network policies In-Reply-To: <20100411091538.GQ69383@Space.Net> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <20100411091538.GQ69383@Space.Net> Message-ID: <20100411235536.0d92d1f8@opy.nosense.org> Hi Gert, On Sun, 11 Apr 2010 11:15:38 +0200 Gert Doering wrote: > Hi, > > On Sat, Apr 10, 2010 at 09:21:00PM +0930, Mark Smith wrote: > > What I also discovered was that Linux and IOS aren't implementing > > complete Neighbor Discovery (i.e. NS/NA) on P2P links, > > I always wondered why anyone would *want* to implement ND on P2P links. > Because you want the simplicity of /64s everywhere, and it's simpler to try to minimise the differences between link layers - to have IPv6 treat them as alike as possible. Nearly all link layers support multicast, so all IPv6 ND requires is a multicast capability. That's why the ND RFC doesn't make very many link layer specific statements - it doesn't have to. IPv4 was different in this regard - neighbor discovery protocols were an add on, rather than being designed in from the outset. > After all, you know that there is only two entities on the link, so if > the packet isn't for you, it must be for them Whether or not an address is offlink or onlink is a dependent on the prefix length of the subnet assigned to the link, and subnet prefix length is a property of a layer 3 protocol, not a layer 2 one. If the prefix length says there are more than two addresses, and the protocol doesn't make point-to-point links a special case for neighbor discovery, then layer 3/layer 2 address resolution needs to take place. > - and there is no need to > construct a l2 address header for POS or PPP links. So all "full ND" > gains you is "more overhead" and "larger attack surface on the router". > The key thing you're not stating is the assumption that you are allowed to have prefix lengths greater than /64. That hasn't been the case and currently isn't the case with IPv6, according to the RFCs. Obviously people are lobbying for /127s, with one of the justifications being this lack of ND NS/NA implementation on P2P links. IOW, it's the result of an implementation choice, not what the protocol specified. The "more overhead" is two packets, and an occasional NUD query, so I don't think it really justifies this optimisation. If your control plane is that overloaded then you've probably got much bigger problems like BGP dropping sessions etc. I'm presuming the "larger attack surface" you're referring to is the neighbor cache DoS? That's not specific to P2P links, and either also justifies switching off ND NS/NA for LANs, or abandoning /64s for LANs too, or changing ND NS/NA operation so that it isn't vulnerable. I'm in favour of the latter. There have been one or two proposals to address it, and I'm thinking about making one myself. > Yes, the corrolary is "packets might loop", but this is what RFC4443 > takes into account. > People might think I'm being a pedant or too theoretical. I'm not. Here is my problem. When I encounter equipment which isn't operating as I expect e.g. may have a fault, at some point one of troubleshooting steps I follow is "how should it be working", and for that I go to the RFCs. If the behaviour then doesn't match what is in the RFCs, when the implementer has claimed compliance with it, then I'll assume it's a bug in the implementation and lodge a fault for it. So I'm pretty binary about compliance with RFCs - either the implementation complies with them or it doesn't (obviously in accordance with the specified SHOULDs, MUSTs etc.). I need to be able to rely on RFCs accurately stating what the behaviour should be (and they must, they are the protocol specifications after all), so that I can determine where a fault exists and what I then need to do next to resolve it. Regards, Mark. From sthaug at nethelp.no Sun Apr 11 16:31:13 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 11 Apr 2010 16:31:13 +0200 (CEST) Subject: IPv6 network policies In-Reply-To: <20100411235536.0d92d1f8@opy.nosense.org> References: <20100410212100.69bceb95@opy.nosense.org> <20100411091538.GQ69383@Space.Net> <20100411235536.0d92d1f8@opy.nosense.org> Message-ID: <20100411.163113.71114401.sthaug@nethelp.no> > The key thing you're not stating is the assumption that you are allowed > to have prefix lengths greater than /64. That hasn't been the case and > currently isn't the case with IPv6, according to the RFCs. Obviously > people are lobbying for /127s, with one of the justifications being > this lack of ND NS/NA implementation on P2P links. IOW, it's the result > of an implementation choice, not what the protocol specified. I'm tempted to say that people who think prefix lengths greater than /64 should not be allowed, are living in a fantasy world. Longer prefix lengths are *used*. Get over it. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From otroan at employees.org Sun Apr 11 20:15:43 2010 From: otroan at employees.org (Ole Troan) Date: Sun, 11 Apr 2010 20:15:43 +0200 Subject: IPv6 network policies In-Reply-To: <20100411172521.5bd80cf3@opy.nosense.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100411090834.242fb2e1@opy.nosense.org> <2A7E7443-03C0-47CA-982F-6AC228B59A12@employees.org> <20100411172521.5bd80cf3@opy.nosense.org> Message-ID: Mark, >>>> NUD could be done, but on most router to router links it is >>>> unnecessary and not used. >>>> >>> >>> I suppose this comes down to if you don't agree with (or maybe just >>> don't fully understand) the way something works in an RFC, does that >>> mean it's ok for you not to implement it the way the RFC says? >> >> good to hear that you are the authority on how RFC4861 should be read (note this may be sarcasm. ;-)). >> please point us to the sections in RFC4861 which require an implementation to do address resolution on a link without L2 addresses. and if it is not address resolution, which part of ND are you referring to? >> > > I've quoted the sections of that RFC (and it's ancestor) twice to this > thread already that support this view. I've also looked through the ND > RFCs for any statements that specifically refer to the operation of ND > over P2P links, and what is optional. I can't find any. > > It's well known that the pong pong problem doesn't exist if ND > NS/NAs are used. I presume by saying "NS/NA", you mean the address resolution function of ND. see section 7.2: "Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. Address resolution is performed only on addresses that are determined to be on-link and for which the sender does not know the corresponding link-layer address (see Section 5.2). Address resolution is never performed on multicast addresses." in particular see "does not know the corresponding link-layer address". then on section 7.3: "Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes, including host-to-host, host-to-router, and router-to-host communication. Neighbor Unreachability Detection may also be used between routers, but is not required if an equivalent mechanism is available, for example, as part of the routing protocols." it is pretty clear that the current behaviour is expected and fully compliant with the IPv6 RFCs. if you want that behaviour changed, then write an Internet draft. you will have much more luck with that approach than suggesting that implementors of IPv6 stacks don't understand the RFC. the ping-pong problem is already covered in RFC4443. other workarounds available today are the use of /128, link-locals only, /127, /64 with ACLs... the solution you propose, 'pseudo address resolution on link-types without L2 addressing', requires spec changes. cheers, Ole From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 12 00:24:33 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 12 Apr 2010 07:54:33 +0930 Subject: IPv6 network policies In-Reply-To: References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100411090834.242fb2e1@opy.nosense.org> <2A7E7443-03C0-47CA-982F-6AC228B59A12@employees.org> <20100411172521.5bd80cf3@opy.nosense.org> Message-ID: <20100412075433.0a03ea0e@opy.nosense.org> On Sun, 11 Apr 2010 20:15:43 +0200 Ole Troan wrote: > Mark, > > >>>> NUD could be done, but on most router to router links it is > >>>> unnecessary and not used. > >>>> > >>> > >>> I suppose this comes down to if you don't agree with (or maybe just > >>> don't fully understand) the way something works in an RFC, does that > >>> mean it's ok for you not to implement it the way the RFC says? > >> > >> good to hear that you are the authority on how RFC4861 should be read (note this may be sarcasm. ;-)). > >> please point us to the sections in RFC4861 which require an implementation to do address resolution on a link without L2 addresses. and if it is not address resolution, which part of ND are you referring to? > >> > > > > I've quoted the sections of that RFC (and it's ancestor) twice to this > > thread already that support this view. I've also looked through the ND > > RFCs for any statements that specifically refer to the operation of ND > > over P2P links, and what is optional. I can't find any. > > > > It's well known that the pong pong problem doesn't exist if ND > > NS/NAs are used. > > I presume by saying "NS/NA", you mean the address resolution function of ND. > see section 7.2: > > "Address resolution is the process through which a node determines the > link-layer address of a neighbor given only its IP address. Address > resolution is performed only on addresses that are determined to be > on-link and for which the sender does not know the corresponding > link-layer address (see Section 5.2). Address resolution is never > performed on multicast addresses." > > in particular see "does not know the corresponding link-layer address". > I don't agree, because I would consider knowing a link layer address doesn't exist (verified by the absence of a NA in response to an NS) as significantly different from assuming it exists, which is your position. The latter position is what is causing the ping-pong problem. Without ND NS/NA on a P2P link, you're always assuming an address must exist, and as IPv6 ND doesn't special case P2P links, and says to treat them as nothing more than multicast links, then only the IPv6 longest match rule can be used to determine that. A point to point link in IPv6 can only be recognised by a /127 prefix length - anything shorter and you're saying to IPv6 one of two things: (a) all the non-local addresses are assigned to the device at the other end of the link (b) the address exists somewhere within the link, and therefore an ND NS/NA transaction should take place. As /127s aren't and haven't ever been specified in IPv6 Addressing RFCs, then that says to me that ND NS/NAs are expected on all links. But that's my interpretation. I think a lot of the IPv6 RFCs support that model - in the least the current IPv6 Addressing Architecture RFC doesn't support prefix lengths greater than a /64. > then on section 7.3: > > "Neighbor Unreachability Detection is used for all paths between hosts > and neighboring nodes, including host-to-host, host-to-router, and > router-to-host communication. Neighbor Unreachability Detection may > also be used between routers, but is not required if an equivalent > mechanism is available, for example, as part of the routing > protocols." > > it is pretty clear that the current behaviour is expected and fully compliant with the IPv6 RFCs. > I wouldn't qualify a point to point link being a routing protocol. I'd interpret that to mean the neighbor recognition / availability mechanisms in e.g. OSPF. > if you want that behaviour changed, then write an Internet draft. you will have much more luck with that approach than suggesting that implementors of IPv6 stacks don't understand the RFC. > > the ping-pong problem is already covered in RFC4443. other workarounds available today are the use of /128, link-locals only, /127, /64 with ACLs... > Unfortunately none of those are solutions that suit a scenario I'm working on. I can't guarantee the routers support RFC4443 (which includes ADSL CPE), and none of the other options are scalable to 100K+ ADSL PPP/PPPoE subscribers. I'll email to the v6ops mailing list for answers as to what to do, as I can only use RFC compliant solutions because I'm working in a very vendor diverse environment. > the solution you propose, 'pseudo address resolution on link-types without L2 addressing', requires spec changes. > > cheers, > Ole From jimb at jsbc.cc Mon Apr 12 08:48:30 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sun, 11 Apr 2010 23:48:30 -0700 Subject: IPv6 network policies In-Reply-To: <35l897-mj3.ln1@chipmunk.wormnet.eu> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <4BC10DCE.5060909@jsbc.cc> <35l897-mj3.ln1@chipmunk.wormnet.eu> Message-ID: <4BC2C23E.80709@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/11/2010 03:33, Alexander Clouter wrote: > Jim Burwell wrote: >> >> Yes. The ping-pong problem can be easily demonstrated on my 6in4 >> link. My simple solution is two ACL entries: >> >> Router A: ip6tables --append FORWARD --destination >> 2001:db8:1234:567::1/128 - -out-interface he6 --jump ACCEPT >> ip6tables --append FORWARD --destination 2001:db8:1234:567::/64 >> - -out-interface he6 --jump REJECT --reject-with >> icmp6-adm-prohibited >> > That's an ugly use of icmp6-adm-prohibited if I might say. > > A better approach IMO: ---- ip route add unreachable > ---- > > This then only needs to be done at your end, which is the correct > thing to do (as you are the one using the default route). > > Cheers > Yeah this is more of a "working example". Any icmp6 type could be used (addr-unreachable perhaps), or the traffic could simply be dropped silently. Would that route really do what I want it to do? Remember, the ptp link (6in4 tunnel) is a /64. I wish only traffic to the :1 and :2 addresses to flow for that particular /64. Any other traffic to that /64 (such as :3) is dropped or rejected so there is no "ping-pong" situation. Without that ACL the forwarding loop definitely does happen. I actually tested this by doing the unreachable route thing to the entire /64, and it actually had no effect. Pings to both sides of the tunnel worked, traffic still flowed through, and the ping-ping still happened when I did a ping6 of :3 from inside or outside. I believe this is because the interface was still up and running with an address on that /64, even though the connected route vanished from the routing table when I put in the "unreachable". The ACL method definitely does the job and gets rid of the ping-pong by simply dropping traffic to anything but the two valid IPv6s on either end of the tunnel. Sure, it could get "messy" especially on a router with a lot of ptp style connections since you'd need a bunch of ACLs. Actually, in a particular case, a Cisco style "wildcard" instead of prefix length traffic filter would only require two entries to cover an entire chunk of space dedicated to ptp links. Say you allocated a /48 for a raft of /64 ptp link addresses, and designed it so one side would always be :1 and the other side would be :2. You could fashion a wildcard match so that the "accept" part matched the first 48 bits exactly, was wild for the next 16 bits, and matched exactly all but the last two bits (ie: "2001:db8:1234::[12] ::ffff:0:0:0:3" using 1 or 2 depending on which side you were on). The "reject" (or drop) part would be for the whole /48. That'd cover and entire /48 worth of /64 ptp links with two ACL entries. I'm not sure if Cisco (or other vendors for that matter) support wild matching with IPv6 though, like the old IPv4 ACLs. From what I've seen in my playing with IPv6 under IOS so far, the IPv6 traffic filter ACLs only do prefix length based matching (someone correct me if I'm wrong!). It'd be super fast in hardware too, since it's just a bitwise AND of the address in-packet + compare with the ACL address (I'm sure the prefix length methods work the same, generating the AND mask from the addr/length pair). - -Jim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvCwj0ACgkQ2fXFxl4S7sQ6GACcDJ+FjNlYUuf2NFedMW7tOrnw x08AoMktXQwv26KQX9qgYbr141aaaJDA =s5vg -----END PGP SIGNATURE----- From otroan at employees.org Mon Apr 12 09:21:30 2010 From: otroan at employees.org (Ole Troan) Date: Mon, 12 Apr 2010 09:21:30 +0200 Subject: IPv6 network policies In-Reply-To: <20100412075433.0a03ea0e@opy.nosense.org> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <20100411090834.242fb2e1@opy.nosense.org> <2A7E7443-03C0-47CA-982F-6AC228B59A12@employees.org> <20100411172521.5bd80cf3@opy.nosense.org> <20100412075433.0a03ea0e@opy.nosense.org> Message-ID: <73F5E43F-3A0B-43DE-A3C3-F180B3A5A34A@employees.org> Mark, >>> It's well known that the pong pong problem doesn't exist if ND >>> NS/NAs are used. >> >> I presume by saying "NS/NA", you mean the address resolution function of ND. >> see section 7.2: >> >> "Address resolution is the process through which a node determines the >> link-layer address of a neighbor given only its IP address. Address >> resolution is performed only on addresses that are determined to be >> on-link and for which the sender does not know the corresponding >> link-layer address (see Section 5.2). Address resolution is never >> performed on multicast addresses." >> >> in particular see "does not know the corresponding link-layer address". >> > > I don't agree, because I would consider knowing a link layer address > doesn't exist (verified by the absence of a NA in response to an NS) as > significantly different from assuming it exists, which is your > position. The latter position is what is causing the ping-pong problem. where do you get the idea that there are any assumptions made? the link has no link-layer addresses. there is nothing to resolve. you don't need to send an NS to figure that out, it is a property of the link type. I don't think we'll get much further in this discussion, so lets end it here or take it off-list. /ot From nick-lists at netability.ie Mon Apr 12 09:24:37 2010 From: nick-lists at netability.ie (Nick Hilliard) Date: Mon, 12 Apr 2010 08:24:37 +0100 Subject: IPv6 network policies In-Reply-To: <4BC2C23E.80709@jsbc.cc> References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <4BC10DCE.5060909@jsbc.cc> <35l897-mj3.ln1@chipmunk.wormnet.eu> <4BC2C23E.80709@jsbc.cc> Message-ID: <4BC2CAB5.407@netability.ie> On 12/04/2010 07:48, Jim Burwell wrote: > Actually, in a particular case, a Cisco style "wildcard" instead of > prefix length traffic filter would only require two entries to cover > an entire chunk of space dedicated to ptp links. Say you allocated a > /48 for a raft of /64 ptp link addresses, and designed it so one side > would always be :1 and the other side would be :2. You could fashion > a wildcard match so that the "accept" part matched the first 48 bits > exactly, was wild for the next 16 bits, and matched exactly all but > the last two bits (ie: "2001:db8:1234::[12] ::ffff:0:0:0:3" using 1 or > 2 depending on which side you were on). The "reject" (or drop) part > would be for the whole /48. That'd cover and entire /48 worth of /64 > ptp links with two ACL entries. You'd want to make sure that your hardware supported this. ACL TCAM is an expensive resource, and compromises are often made in terms of not fully supporting arbitrary masks on ipv6 acls: > http://www.ciscosystems.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/acl.html#wp1090842 ... or in terms of tcam carveup: > http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swipv6.html#wp1063564 ... or generic limitations: > http://www.cisco-secure.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_52_se/configuration/guide/swv6acl.html#wp4334642 Having said all this, routers which handle sonet or ppp links don't always use tcam either. Nick From mohacsi at niif.hu Mon Apr 12 14:48:18 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 12 Apr 2010 14:48:18 +0200 (CEST) Subject: Which firmware for Linksys WRT54GL 1.1 and IPv6 In-Reply-To: References: <87tyrspfyj.fsf@bowmore.quux.de> <4BBB1CE6.4030506@berkom.de> Message-ID: Be sure, that you use the same version of firmware and packages, otherwise you might expect unresolved symbols.... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Sun, 11 Apr 2010, Daniel G. Kluge wrote: > Am 06.04.2010 um 13:37 schrieb Christian Hahn: > > I just wanted to flash a WRT54GL 1.1 with OpenWRT (8.09.2) and configure > > IPv6 with it. This doesn't work (insmod ipv6 insmod: unresolved symbol > > tcp_destroy_sock This is documented, but the ticket is closed as "works > > for me".) > > > So which firmware should I try next? Or should I buy a Cisco for my > > parents? ;-) > > I have one running with 8.09, flashed at least half a year ago, and the kernel > supports IPv6. If you want OpenWRT 8.* I would suggest to try out a slightly > older release than 8.09.2. > > > You just made me look again, I'm running?KAMIKAZE (8.09.1, r16278) on my WRT54GL, and it servers as my IPv6 yunnel endpoint. > > So that binary worked just fine. And here some handy notes I keep for the installation (That was eight months ago, and it has been > running since). > > Necessary packages for IPv6: > aiccu?radvd?kmod-ipv6?kmod-tun?ip > > Optional packages I need/like: > minupnpd?ip6tables?ntpclient?tcpdump > > Cheers, > -daniel > > > From ryan at u13.net Mon Apr 12 20:15:04 2010 From: ryan at u13.net (Ryan Rawdon) Date: Mon, 12 Apr 2010 14:15:04 -0400 Subject: Youtube-over-IPv6 In-Reply-To: <2e8c64261002040214g368a6b34w5fa2d393644e220a@mail.gmail.com> References: <1264722718.1613.86.camel@hsa.vpn.anti> <2e8c64261001281645t13ab8d69n176131df478cba9@mail.gmail.com> <20100129081135.GJ32226@Space.Net> <4B62B350.4050804@danysek.cz> <20100129101027.GL32226@Space.Net> <1265189005.28198.80.camel@hsa.vpn.anti> <2e8c64261002040214g368a6b34w5fa2d393644e220a@mail.gmail.com> Message-ID: <4BC36328.2070606@u13.net> Erik, others, Are there plans to add AAAA for upload.youtube.com? I noticed that uploads themselves go over v4 and involve this hostname, which is v4-only currently (and upload-related content comes from this hostname over v4)? Ryan Erik Kline wrote: >> I tried firewalling away my IPv4 connectivity and used a non-local, >> dual-stacked, DNS resolver to browse the page and it sort-of works. >> Front page looks kind-of stupid (some elements missing), but it is >> possible to view videos, etc. :) >> > > Any idea which hostnames aren't dualstacked or, more precisely, what is missing? > > >> So you IPv6 ninjas over at Google, what's next? :) >> > > More. :) > > >> Achieving support of single-stack IPv6 users should be the long-term >> goal, I presume. >> Dare you answer at all re: the DNS infrastructure? :) >> > > The existing whitelist program is not a long term solution, as many > have noted. I wouldn't worry too much about it affecting any > potential future DNSSEC support of Google domains. > From ocl at gih.com Tue Apr 13 17:44:34 2010 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Tue, 13 Apr 2010 17:44:34 +0200 Subject: Prefixes, allocation and type of address Message-ID: <4BC49162.8080003@gih.com> Hello, I wonder if there is a way (perhaps are there lists somewhere) to identify specific types of IPv6 addresses like - IPv6 to IPv4 Web proxies - 6-to-4 addresses (are these all prefixed at 2002::/16 ?) - 6-in-4 addresses - 6rd - Teredo addresses (are these all prefixed (|2001:0000::/32 ?|) - addresses from Tunnel Brokers (is there a list of those, or do I need to look at address allocation from the local RIR to each Tunnel Broker service?) etc. I know that some are defined by their prefix, but is there a maintained list that tracks those? (or please be so kind to point me to the different lists) Many thanks, Olivier -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100413/70c87fc0/attachment.html From evyncke at cisco.com Tue Apr 13 17:48:08 2010 From: evyncke at cisco.com (Eric Vyncke) Date: Tue, 13 Apr 2010 17:48:08 +0200 Subject: Prefixes, allocation and type of address In-Reply-To: <4BC49162.8080003@gih.com> Message-ID: You got most of them ;-) ISATAP addresses can also be identified because they have :0:5efe: in their address (of course, there will be false positives) On 13/04/10 17:44, "Olivier MJ Crepin-Leblond" wrote: > Hello, > > I wonder if there is a way (perhaps are there lists somewhere) to identify > specific types of IPv6 addresses like > > - IPv6 to IPv4 Web proxies > - 6-to-4 addresses (are these all prefixed at 2002::/16 ?) > - 6-in-4 addresses > - 6rd > - Teredo addresses (are these all prefixed (2001:0000::/32 ?) > - addresses from Tunnel Brokers (is there a list of those, or do I need to > look at address allocation from the local RIR to each Tunnel Broker service?) > etc. > > I know that some are defined by their prefix, but is there a maintained list > that tracks those? > (or please be so kind to point me to the different lists) > > Many thanks, > > Olivier -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100413/12a8f453/attachment.html From tme at americafree.tv Tue Apr 13 17:54:45 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 13 Apr 2010 11:54:45 -0400 Subject: Prefixes, allocation and type of address In-Reply-To: <4BC49162.8080003@gih.com> References: <4BC49162.8080003@gih.com> Message-ID: <358837AF-1381-4D0D-876D-FEC8328F0E6E@americafree.tv> On Apr 13, 2010, at 11:44 AM, Olivier MJ Crepin-Leblond wrote: > Hello, > > I wonder if there is a way (perhaps are there lists somewhere) to > identify specific types of IPv6 addresses like > These lists of course might be useful. http://www.iana.org/assignments/ipv6-address-space/ http://www.iana.org/assignments/ipv6-unicast-address-assignments/ http://www.iana.org/assignments/ipv6-multicast-addresses/ > - IPv6 to IPv4 Web proxies > - 6-to-4 addresses (are these all prefixed at 2002::/16 ?) > - 6-in-4 addresses > - 6rd > - Teredo addresses (are these all prefixed (2001:0000::/32 ?) > - addresses from Tunnel Brokers (is there a list of those, or do I > need to look at address allocation from the local RIR to each Tunnel > Broker service?) > etc. > > I know that some are defined by their prefix, but is there a > maintained list that tracks those? > (or please be so kind to point me to the different lists) > I wonder if IANA should maintain a fuller IPv6 unicast list. Regards Marshall > Many thanks, > > Olivier > -- > Olivier MJ Cr?pin-Leblond, PhD > http://www.gih.com/ocl.html From jeroen at unfix.org Tue Apr 13 18:40:35 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 13 Apr 2010 18:40:35 +0200 Subject: Prefixes, allocation and type of address In-Reply-To: <4BC49162.8080003@gih.com> References: <4BC49162.8080003@gih.com> Message-ID: <4BC49E83.6080302@unfix.org> On 2010-04-13 17:44, Olivier MJ Crepin-Leblond wrote: > Hello, > > I wonder if there is a way (perhaps are there lists somewhere) to > identify specific types of IPv6 addresses like > > - IPv6 to IPv4 Web proxies Nothing special about the address here. As for the SixXS IPv6gate, it lives on a set of hosts and is distributed thus requests can come from a variety of hosts now. For some time there was a list on Wikipedia which defined them, but some editors didn't want the article about IPv6gate thus that information got removed too, oh well, more freedom for the Chinese then ;) > - 6-to-4 addresses (are these all prefixed at 2002::/16 ?) Yes. > - 6-in-4 addresses Nothing special. > - 6rd Nothing special either, only the ISP can tell. > - Teredo addresses (are these all prefixed (|2001:0000::/32 ?|) Yes. > - addresses from Tunnel Brokers (is there a list of those, or do I need > to look at address allocation from the local RIR to each Tunnel Broker > service?) > etc. For SixXS: http://www.sixxs.net/pops/prefixes/ 57x /40 which is equivalent to a total of 14592 /48's or 1x /35 + 1x /36 + 1x /37 + 1x /40 just a few more /40's to go to get a /34 full ;) Of course, there are new ones once in a while there. There is a handy CSV edition too. > I know that some are defined by their prefix, but is there a maintained > list that tracks those? Not that I know of. Also, it should not matter anyway for general connectivity, IPs are IPs. You might want to know this for research purposes though to see where your clients are coming from of course. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100413/091d63c7/attachment.bin From alex at digriz.org.uk Wed Apr 14 20:44:42 2010 From: alex at digriz.org.uk (Alexander Clouter) Date: Wed, 14 Apr 2010 19:44:42 +0100 Subject: IPv6 network policies References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <4BC10DCE.5060909@jsbc.cc> <35l897-mj3.ln1@chipmunk.wormnet.eu> <4BC2C23E.80709@jsbc.cc> Message-ID: Jim Burwell wrote: > > On 4/11/2010 03:33, Alexander Clouter wrote: >> Jim Burwell wrote: >>> >>> Yes. The ping-pong problem can be easily demonstrated on my 6in4 >>> link. My simple solution is two ACL entries: >>> >>> Router A: ip6tables --append FORWARD --destination >>> 2001:db8:1234:567::1/128 - -out-interface he6 --jump ACCEPT >>> ip6tables --append FORWARD --destination 2001:db8:1234:567::/64 >>> - -out-interface he6 --jump REJECT --reject-with >>> icmp6-adm-prohibited >>> >> That's an ugly use of icmp6-adm-prohibited if I might say. >> >> A better approach IMO: ---- ip route add unreachable >> ---- >> >> This then only needs to be done at your end, which is the correct >> thing to do (as you are the one using the default route). > > Yeah this is more of a "working example". Any icmp6 type could be > used (addr-unreachable perhaps), or the traffic could simply be > dropped silently. > Probably better still (and then applicable for all): ip6tables -A -i he6 -o he6 -j REJECT --reject-with icmp-host-unreachable > Would that route really do what I want it to do? Remember, the ptp > link (6in4 tunnel) is a /64. I wish only traffic to the :1 and :2 > addresses to flow for that particular /64. Any other traffic to that > /64 (such as :3) is dropped or rejected so there is no "ping-pong" > situation. Without that ACL the forwarding loop definitely does happen. > Yeah, my fault, I mis-read your iptables rule and was thinking of the obvious case where loops arise from the use of the 'default' route, rather than in the case of P2P links. I would still personally try to avoid the use of a firewall. A filter is for filtering, not solving routing glitches. :) Try something the following instead and let me know if that helps: ip rule add to 2001:db8:1234:567::/64 iif he6 unreachable Cheers -- Alexander Clouter .sigmonster says: It looks like blind screaming hedonism won out. From alex at digriz.org.uk Wed Apr 14 22:24:42 2010 From: alex at digriz.org.uk (Alexander Clouter) Date: Wed, 14 Apr 2010 21:24:42 +0100 Subject: IPv6 network policies References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <4BC10DCE.5060909@jsbc.cc> <35l897-mj3.ln1@chipmunk.wormnet.eu> <4BC2C23E.80709@jsbc.cc> Message-ID: Alexander Clouter wrote: > > Probably better still (and then applicable for all): > > ip6tables -A -i he6 -o he6 -j REJECT --reject-with icmp-host-unreachable > *ahem* s/-A /-A FORWARD / *ahem* Cheers -- Alexander Clouter .sigmonster says: Computer programmers do it byte by byte. From cfriacas at fccn.pt Thu Apr 15 16:53:06 2010 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 15 Apr 2010 15:53:06 +0100 (WEST) Subject: IPv6 in HEP (High Energy Physics) In-Reply-To: References: <4BBFB9BB.3070207@ibctech.ca> <20100410212100.69bceb95@opy.nosense.org> <25A7B0BC-29C2-4D39-8746-C853B7FFD4CC@employees.org> <4BC10DCE.5060909@jsbc.cc> <35l897-mj3.ln1@chipmunk.wormnet.eu> <4BC2C23E.80709@jsbc.cc> Message-ID: Dear list, (sorry if this topic is not interesting for most of this list members, i know this falls more under promotion than operations...) I was made aware that the usage (or non-usage) of IPv6 by this HEP community is being discussed next week at a conference: http://indico.cern.ch/contributionDisplay.py?sessionId=39&contribId=57&confId=73181 Content: The transition to IPv6 has been just several years away for quite a few years now. Some HEP sites (or the national networks they belong to) have started tests and making plans. This discussion session will allow HEPiX participants to share some of their experiences and plans. We should consider what happens next. Is it time for HEPiX to start an activity in this area, for example? People working for NRENs (or others), who might know people within this community from their country might want to drop them a word or two about this subject... :-) Best Regards, Carlos From steve at cymru.com Thu Apr 15 23:10:59 2010 From: steve at cymru.com (Steve Santorelli) Date: Thu, 15 Apr 2010 14:10:59 -0700 Subject: Major additions to Team Cymru's Bogon Feed - includes IPv6 prefixes Message-ID: <4BC780E3.9080409@cymru.com> Team Cymru is pleased to announce a significant addition to our bogon reference project which might be of interest to this list as it relates to IPv6 matters. The new portions of the project are offered at no cost to the community, and the original bogon lists and feeds are not being changed or canceled, just augmented. The new "fullbogon" feed includes prefixes allocated to RIRs, but not assigned by the RIRs to end-users, ISPs, etc, providing a more complete view of the unassigned space that should not be seen on the Internet. This new service is therefore more granular than the original feed, including a wide variety of non-routable prefixes as well as unassigned prefixes and it also includes IPv6 prefixes. Simply email bogonrs at cymru.com with your ASN, peering IP addresses and whether you use MD5 authentication. See an overview in the 46th episode of Team Cymru's 'The Who and Why Show' at www.youtube.com/teamcymru, as well as a more basic overview in episode 12. For a more detailed explanation, see . Even more so than the original feed, there are significant changes to the list every day and the feed automatically recalculates the prefixes as they are allocated from the regional registries, so make sure you are able to regularly update your lists. Internet security is all about "the other guy." If one sizeable network is insecure, it WILL be used to abuse other networks. We look forward to continuing to help our community to secure the edge. Why is this important? Bogons are defined as Martians (private and reserved addresses defined by RFC 1918 and RFC 5735) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority. A bogon prefix is a route that should never appear in the Internet routing table on a Router. A packet routed over the public Internet (obviously, not including over VPNs or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks and our research has previously shown that, in some cases, up to 60% of DDoS packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.). This new service comprises a larger set which also includes IP space that has been allocated to an RIR, but not by that RIR to an actual ISP or other end-user. While not all DDoS attacks use bogons, every little bit helps. Note additionally that bogon filtering is a component of anti-spoofing filtering, which is also very important. Internet security is all about "the other guy." If one sizeable network is insecure, it WILL be used to abuse other networks. We look forward to continuing to help our community to secure the edge. warm regards, Steve. -- Steve Santorelli,Team Cymru, Inc.|www.team-cymru.org steve at cymru.com|desk:+1-630-230-5434|cell:+1-312-804-7771 Also, please note that there are many way to keep up with what Team Cymru are doing, see the lower part of: http://www.team-cymru.org/About/contact.html plus: * join our announce list via cymru-announce-subscribe at cymru.com * see what we see, www.team-cymru.org/Monitoring/Graphs * probably the best news feed in the world, www.team-cymru.org/News * cool stuff you can use, www.team-cymru.org/Services/ * see our Twitter feed at http://twitter.com/teamcymru From gert at space.net Sun Apr 18 13:52:20 2010 From: gert at space.net (Gert Doering) Date: Sun, 18 Apr 2010 13:52:20 +0200 Subject: Which firmware for Linksys WRT54GL 1.1 and IPv6 In-Reply-To: <87tyrspfyj.fsf@bowmore.quux.de> References: <87tyrspfyj.fsf@bowmore.quux.de> Message-ID: <20100418115220.GA77592@Space.Net> Hi, to followup on this. On Sat, Apr 03, 2010 at 08:07:48PM +0200, Jens Link wrote: > I just wanted to flash a WRT54GL 1.1 with OpenWRT (8.09.2) and configure > IPv6 with it. This doesn't work (insmod ipv6 insmod: unresolved symbol > tcp_destroy_sock This is documented, but the ticket is closed as "works > for me".) I saw the same problem at a training at a customer's site, with customer- installed WRTs (so I don't know exactly which kernel they used). I tried to reproduce this at home today, to be able to open a bug report - and couldn't! Test setup: WRT54GL v1.1, OpenWRT 8.09.02, from here: http://downloads.openwrt.org/kamikaze/8.09.2/brcm-2.4/openwrt-wrt54g-squashfs.bin installed via "tftp push via boot_wait" (standard method). Installed IPv6 module via "opkg install kmod-ipv6" next, and everything behaved as expected... So I can only speculate that *some* kernel+squashfs bundles might have problems - but I'm not going to test all WRT bundles now to see if one of them might fail. "wrt54g" definitely works :-) (For the record, the brcm-2.4/...-wrt54g-...) binary for the newly released 10.03 openwrt also works) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From wouter at widexs.nl Sun Apr 18 15:09:50 2010 From: wouter at widexs.nl (Wouter de Jong) Date: Sun, 18 Apr 2010 15:09:50 +0200 Subject: (L2) Switches with incoming src-address ACL's Message-ID: <00ab01cadef8$6ea911b0$4bfb3510$@nl> Hi, Does anyone know on which (access-) (L2) switches you can actually put an ACL to only allow incoming traffic with a source-address (IPv4 and IPv6) that is assigned to the device behind it ? (port-based would be the only useable option) VMware vSphere vSwitches probably can't do this kind of filtering, anyone who knows if the Cisco Nexus 1000V can do it ? What is this 'feature' usually called like, if it exists at all ? Eg. needed for co-location where servers of different customers are in a shared subnet and renumbering is not an option. Thanks for any clue's. Regards, Wouter From frnkblk at iname.com Sat Apr 24 17:22:05 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Apr 2010 10:22:05 -0500 Subject: Comcast's IPv6 CPE selection Message-ID: This week Comcast came out with some updated information regarding each of the trials it plans to undertake in the coming year (http://www.comcast6.net/). One of the items was a list of three different CPE for Trial #2 (native dual-stack): Apple Airport Extreme NetGear WNR3500 NetGear WNR1000 I know that Apple has a reasonably decent IPv6 implementation, but I wasn't aware that Netgear was doing anything on SOHO routers. When I checked the documentation for both models on Netgear's website there was no mention of IPv6 anywhere. Does anyone have the inside scoop? Frank From tedm at ipinc.net Sat Apr 24 18:27:02 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 24 Apr 2010 09:27:02 -0700 Subject: Comcast's IPv6 CPE selection In-Reply-To: References: Message-ID: <4BD31BD6.7000807@ipinc.net> The WNR1000 and the WNR3500 run GPL Linux, you can download the source from here: http://kb.netgear.com/app/answers/detail/a_id/2649 The WNR3500 can run DD-WRT as a matter of fact. The Linux that is contained in these probably already has the Ipv6 utilities in it, and if you can get to a command prompt you might even be able to activate Ipv6 routing on them. it's just the Netgear webinterface that would need to be changed. Thus Comcast has several options. First they can contract with the DD-WRT folks to produce a DD-WRT version for them that contains IPv6, that would be very quick to do. Secondly they could contract with Netgear to produce a code version that would contain IPv6 for them - but if that happened then Netgear would be required under the GPL terms to distribute that on their own website. Third Comcast could take the existing code and add in the IPv6 support themselves - which espically if they consider their customers "owning" these devices once they get them - would also constitute "redistribution" under the GPL and thus Comcast would be obligated to post their source. I think it highly unlikely that Comcast would pay to rewrite the firmware for the WNR's from scratch, thus avoiding the GPL redistribution requirements. So I'd assume that your going to be dealing with the Linux IPv6 stack. My advice is if you have Comcast and plan on participating in this trial to by all means get the WNR3500. That way if the Comcast or Netgear firmware is crap, you can load DD-WRT on it. Ted On 4/24/2010 8:22 AM, Frank Bulk wrote: > This week Comcast came out with some updated information regarding each of > the trials it plans to undertake in the coming year > (http://www.comcast6.net/). One of the items was a list of three different > CPE for Trial #2 (native dual-stack): > Apple Airport Extreme > NetGear WNR3500 > NetGear WNR1000 > > I know that Apple has a reasonably decent IPv6 implementation, but I wasn't > aware that Netgear was doing anything on SOHO routers. When I checked the > documentation for both models on Netgear's website there was no mention of > IPv6 anywhere. > > Does anyone have the inside scoop? > > Frank > From frnkblk at iname.com Sat Apr 24 18:50:44 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Apr 2010 11:50:44 -0500 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD31BD6.7000807@ipinc.net> References: <4BD31BD6.7000807@ipinc.net> Message-ID: Ted: What you've written seems very plausible. It's my understanding, from following on this listserv and others, that DD-WRT doesn't have IPv6 as part of the base package and that it takes a little bit of work to put on and that not all the kinks are worked out. Hopefully the good folk who work on the DD-WRT stuff can massage IPv6 into the base package and feature set. Frank -----Original Message----- From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of Ted Mittelstaedt Sent: Saturday, April 24, 2010 11:27 AM To: ipv6-ops at lists.cluenet.de Subject: Re: Comcast's IPv6 CPE selection The WNR1000 and the WNR3500 run GPL Linux, you can download the source from here: http://kb.netgear.com/app/answers/detail/a_id/2649 The WNR3500 can run DD-WRT as a matter of fact. The Linux that is contained in these probably already has the Ipv6 utilities in it, and if you can get to a command prompt you might even be able to activate Ipv6 routing on them. it's just the Netgear webinterface that would need to be changed. Thus Comcast has several options. First they can contract with the DD-WRT folks to produce a DD-WRT version for them that contains IPv6, that would be very quick to do. Secondly they could contract with Netgear to produce a code version that would contain IPv6 for them - but if that happened then Netgear would be required under the GPL terms to distribute that on their own website. Third Comcast could take the existing code and add in the IPv6 support themselves - which espically if they consider their customers "owning" these devices once they get them - would also constitute "redistribution" under the GPL and thus Comcast would be obligated to post their source. I think it highly unlikely that Comcast would pay to rewrite the firmware for the WNR's from scratch, thus avoiding the GPL redistribution requirements. So I'd assume that your going to be dealing with the Linux IPv6 stack. My advice is if you have Comcast and plan on participating in this trial to by all means get the WNR3500. That way if the Comcast or Netgear firmware is crap, you can load DD-WRT on it. Ted On 4/24/2010 8:22 AM, Frank Bulk wrote: > This week Comcast came out with some updated information regarding each of > the trials it plans to undertake in the coming year > (http://www.comcast6.net/). One of the items was a list of three different > CPE for Trial #2 (native dual-stack): > Apple Airport Extreme > NetGear WNR3500 > NetGear WNR1000 > > I know that Apple has a reasonably decent IPv6 implementation, but I wasn't > aware that Netgear was doing anything on SOHO routers. When I checked the > documentation for both models on Netgear's website there was no mention of > IPv6 anywhere. > > Does anyone have the inside scoop? > > Frank > From nicholas.hatch at gmail.com Sat Apr 24 20:46:37 2010 From: nicholas.hatch at gmail.com (nick hatch) Date: Sat, 24 Apr 2010 11:46:37 -0700 Subject: Comcast's IPv6 CPE selection In-Reply-To: References: <4BD31BD6.7000807@ipinc.net> Message-ID: On Sat, Apr 24, 2010 at 9:50 AM, Frank Bulk wrote: > > Hopefully the good folk who work on the DD-WRT stuff can massage IPv6 into > the base package and feature set. > > As long as we're wishing for things, I'd love to see IPv6 support in the excellent Tomato firmware [1]. It's simplicity and interface usability is second to none. It's a great "normal person" firmware. DD-WRT is complex enough that IPv6 can be "supported", but not easily usable. When something as user-friendly as Tomato supports IPv6 out of the box with sane defaults, I'll feel more confident about the battle being won. -Nick [1] http://www.polarcloud.com/tomato -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100424/2d47b6d7/attachment.html From dougb at dougbarton.us Sat Apr 24 21:40:34 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 24 Apr 2010 12:40:34 -0700 Subject: Comcast's IPv6 CPE selection In-Reply-To: References: <4BD31BD6.7000807@ipinc.net> Message-ID: <4BD34932.3000107@dougbarton.us> On 04/24/10 09:50, Frank Bulk wrote: > Ted: > > What you've written seems very plausible. > > It's my understanding, from following on this listserv and others, that > DD-WRT doesn't have IPv6 as part of the base package and that it takes a > little bit of work to put on and that not all the kinks are worked out. > Hopefully the good folk who work on the DD-WRT stuff can massage IPv6 into > the base package and feature set. Two problems here, the first is that when you talk about "DD-WRT" you're really talking about many different firmwares, packages, combinations of modules, etc. (For better or worse) there is no One True DD-WRT. The other problem is that what you wrote isn't quite accurate. :) I'm happily using IPv6 on my Linksys 160N: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=66205 As you can see from this chart IPv6 support is included in all but the tiniest versions of DD-WRT: http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions Admittedly it was not as easy to set up as just clicking a few buttons, but now that it's done it "just works." The computers on my home network see the RAs and configure themselves as they should. As far as they are concerned it's native IPv6 just as $DEITY intended. :) hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From frnkblk at iname.com Sun Apr 25 03:50:48 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Apr 2010 20:50:48 -0500 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD34932.3000107@dougbarton.us> References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> Message-ID: And note the "[5]" behind IPv6 feature that says "Apparently, IPv6-related features DO NOT work by default in DD-WRT v24. See IPv6 on v24.", and clicking throught "IPv6 on v24" I see all kinds of "insmod" commands. Seems a little rough around the edges to me. =) Frank -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Saturday, April 24, 2010 2:41 PM To: frnkblk at iname.com Cc: ipv6-ops at lists.cluenet.de Subject: Re: Comcast's IPv6 CPE selection On 04/24/10 09:50, Frank Bulk wrote: > Ted: > > What you've written seems very plausible. > > It's my understanding, from following on this listserv and others, that > DD-WRT doesn't have IPv6 as part of the base package and that it takes a > little bit of work to put on and that not all the kinks are worked out. > Hopefully the good folk who work on the DD-WRT stuff can massage IPv6 into > the base package and feature set. Two problems here, the first is that when you talk about "DD-WRT" you're really talking about many different firmwares, packages, combinations of modules, etc. (For better or worse) there is no One True DD-WRT. The other problem is that what you wrote isn't quite accurate. :) I'm happily using IPv6 on my Linksys 160N: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=66205 As you can see from this chart IPv6 support is included in all but the tiniest versions of DD-WRT: http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions Admittedly it was not as easy to set up as just clicking a few buttons, but now that it's done it "just works." The computers on my home network see the RAs and configure themselves as they should. As far as they are concerned it's native IPv6 just as $DEITY intended. :) hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From frnkblk at iname.com Sun Apr 25 03:51:09 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Apr 2010 20:51:09 -0500 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD34932.3000107@dougbarton.us> References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> Message-ID: And note the "[5]" behind IPv6 feature that says "Apparently, IPv6-related features DO NOT work by default in DD-WRT v24. See IPv6 on v24.", and clicking throught "IPv6 on v24" I see all kinds of "insmod" commands. Seems a little rough around the edges to me. =) Frank -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Saturday, April 24, 2010 2:41 PM To: frnkblk at iname.com Cc: ipv6-ops at lists.cluenet.de Subject: Re: Comcast's IPv6 CPE selection On 04/24/10 09:50, Frank Bulk wrote: > Ted: > > What you've written seems very plausible. > > It's my understanding, from following on this listserv and others, that > DD-WRT doesn't have IPv6 as part of the base package and that it takes a > little bit of work to put on and that not all the kinks are worked out. > Hopefully the good folk who work on the DD-WRT stuff can massage IPv6 into > the base package and feature set. Two problems here, the first is that when you talk about "DD-WRT" you're really talking about many different firmwares, packages, combinations of modules, etc. (For better or worse) there is no One True DD-WRT. The other problem is that what you wrote isn't quite accurate. :) I'm happily using IPv6 on my Linksys 160N: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=66205 As you can see from this chart IPv6 support is included in all but the tiniest versions of DD-WRT: http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions Admittedly it was not as easy to set up as just clicking a few buttons, but now that it's done it "just works." The computers on my home network see the RAs and configure themselves as they should. As far as they are concerned it's native IPv6 just as $DEITY intended. :) hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dougb at dougbarton.us Sun Apr 25 04:10:25 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 24 Apr 2010 19:10:25 -0700 Subject: Comcast's IPv6 CPE selection In-Reply-To: References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> Message-ID: <4BD3A491.9060202@dougbarton.us> On 04/24/10 18:50, Frank Bulk wrote: > And note the "[5]" behind IPv6 feature that says "Apparently, IPv6-related > features DO NOT work by default in DD-WRT v24. See IPv6 on v24.", and > clicking throught "IPv6 on v24" I see all kinds of "insmod" commands. The v24 firmwares are all getting pretty long in the tooth, and v26 is the recommended version on all routers that support it (which is most of the ones that have been manufactured in the last 5 years or so). And if you read the forum post I included the link to you can see that there IS a bit of manual configuration that has to be done, but unlike in the past where you had to create numerous boot scripts, install packages by hand, ssh into the router, etc. etc.[1] modern versions of dd-wrt (except for the very smallest firmwares) already include everything you need, and allow you to configure the two things you need to get IPv6 working (radvd and the startup commands for the tunnel) from the gui. I'm not saying I'd turn my grandfather loose on this, rather that a reasonably capable tech-oriented person could go from stock linksys firmware to having their router as a tunnel endpoint and RA on their local network in a few hours ... maybe a little more if their forum/wiki/google search fu is not up to par. hth, Doug [1] Compare http://www.tunnelbroker.net/forums/index.php?topic=106.0 -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From frnkblk at iname.com Sun Apr 25 04:12:05 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Apr 2010 21:12:05 -0500 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD3A491.9060202@dougbarton.us> References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> <4BD3A491.9060202@dougbarton.us> Message-ID: Ack on that -- hopefully it can be grandparent ready in a few months. Frank -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Saturday, April 24, 2010 9:10 PM To: frnkblk at iname.com Cc: ipv6-ops at lists.cluenet.de Subject: Re: Comcast's IPv6 CPE selection On 04/24/10 18:50, Frank Bulk wrote: > And note the "[5]" behind IPv6 feature that says "Apparently, IPv6-related > features DO NOT work by default in DD-WRT v24. See IPv6 on v24.", and > clicking throught "IPv6 on v24" I see all kinds of "insmod" commands. The v24 firmwares are all getting pretty long in the tooth, and v26 is the recommended version on all routers that support it (which is most of the ones that have been manufactured in the last 5 years or so). And if you read the forum post I included the link to you can see that there IS a bit of manual configuration that has to be done, but unlike in the past where you had to create numerous boot scripts, install packages by hand, ssh into the router, etc. etc.[1] modern versions of dd-wrt (except for the very smallest firmwares) already include everything you need, and allow you to configure the two things you need to get IPv6 working (radvd and the startup commands for the tunnel) from the gui. I'm not saying I'd turn my grandfather loose on this, rather that a reasonably capable tech-oriented person could go from stock linksys firmware to having their router as a tunnel endpoint and RA on their local network in a few hours ... maybe a little more if their forum/wiki/google search fu is not up to par. hth, Doug [1] Compare http://www.tunnelbroker.net/forums/index.php?topic=106.0 -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From tedm at ipinc.net Sun Apr 25 06:23:27 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 24 Apr 2010 21:23:27 -0700 Subject: Comcast's IPv6 CPE selection In-Reply-To: References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> <4BD3A491.9060202@dougbarton.us> Message-ID: <4BD3C3BF.1020707@ipinc.net> I will chime in on this as I've had a lot of experience with this firmware. For starters there is no "v26" there is only V24 and "V24 pre-SP2" First thing to realize with dd-wrt is that the biggest reason (IMHO) that people use it is that it's rock-solid stable compared to the vendor firmware. So new releases take a long time. Since there's many routers out there with crummy firmware there is much clamoring for dd-wrt to be ported to ever new platforms, and a lot of the maintainer's time is spent doing this. The second thing to realize is that VERY FEW consumer-grade routers that support 802.11g came with MORE than 4MB of flash. Originally many DID come with 4MB - but then later they went to 2MB (such as the later Linksys WRT54G units) of flash. The problem here is that the newer DD-WRT firmware using the newer Linux kernel consumes more space. Thus, the DD-WRT developers have spent a huge amount of time figuring out how to delete things from the newer Linux loads to get them to run on the 2MB flash units. (Just about all Belkin units for example use 2MB flash) IPv6 is one of those things. This means essentially that NO Broadcom-based 54G router with 2MB and NO Atheros based 54G router with 4MB flash will run a dd-wrt load that will do IPv6. The current dd-wrt load is a so-called "beta" of v24 (they call it pre-SP2 but the new releases have been called that for almost the last 2 years) it's SVN# 13064, this came out about 4 months ago. The "official" dd-wrt release does NOT contain good IPv6 support. Because of this, a user crushedhat decided about 2 years ago to fork off SVN# 10070 and made a huge boatload of changes to it to support IPv6 properly. This is detailed here: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=196058#196058 crushedhat is NOT one of the dd-wrt developers. He DID post a set of instructions on how he setup the build environment. The rapid intro of draft-N routers into the market has changed dd-wrt development as the developers now appear to mainly be concerned with expanding the footprint of dd-wrt onto more hardware. This is good and bad. The good part is that many of the newer draft-N routers (such as the Linksys 160N) shipped with 4MB of flash or 8MB (Linksys 300N, Netgear WNR3500L, etc.) but it is bad because the developers never really integrated CrushedHat's IPv6 changes and probably won't until V24 SP2 is a reality - and that seems to be in the distant future as they really aren't working on getting SP2 out the door. The reality of IPv6 on dd-wrt is you either run the developer released standard loads (which require 4MB flash minimum) and have a lot of things missing from IPv6 (traceroute6, etc.) but are the current SVN#, or you run the 2-year-old Crushedhat SVN fork which has a complete IPv6 implementation but is not the current SVN, or you use the Crushedhat instructions and setup a development environment and pull down the current SVN source, apply the crushedhat mods, then build that one. The 2 year old crushedhat release is stable and reliable and so a lot of people run it. But it's clear that we are a ways off from "official" support of IPv6 from the dd-wrt developers for 4MB flash units. However, in the long run this may not matter IF the wireless market jumps en-mass onto the 802.11 N standard. That is (IMHO) what the dd-wrt developers are betting on, and it's why they are focusing most of their effort on porting DD-WRT as quickly as possible to the widest number of N routers that are on the market, instead of doing what's needed to get a v24 SP2 release out the door. And all of this also applies only to the command-line interface to dd-wrt. The GUI interface would have to be modified to support all of the IPv6 utilities (like traceroute6) before you could point to DD-WRT and call it "grandparent ready" and that is not easy as it's written in an obfuscated manner (to prevent copying, the GUI is NOT under the GPL like the rest of DD-WRT is) However, this isn't any different than OpenWRT, which while it has a good command-line implementation of IPv6, none of the GUIs that are out there for OpenWRT support it. (although, those ARE easily modified) Ted On 4/24/2010 7:12 PM, Frank Bulk wrote: > Ack on that -- hopefully it can be grandparent ready in a few months. > > Frank > > -----Original Message----- > From: Doug Barton [mailto:dougb at dougbarton.us] > Sent: Saturday, April 24, 2010 9:10 PM > To: frnkblk at iname.com > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: Comcast's IPv6 CPE selection > > On 04/24/10 18:50, Frank Bulk wrote: >> And note the "[5]" behind IPv6 feature that says "Apparently, IPv6-related >> features DO NOT work by default in DD-WRT v24. See IPv6 on v24.", and >> clicking throught "IPv6 on v24" I see all kinds of "insmod" commands. > > The v24 firmwares are all getting pretty long in the tooth, and v26 is > the recommended version on all routers that support it (which is most of > the ones that have been manufactured in the last 5 years or so). > > And if you read the forum post I included the link to you can see that > there IS a bit of manual configuration that has to be done, but unlike > in the past where you had to create numerous boot scripts, install > packages by hand, ssh into the router, etc. etc.[1] modern versions of > dd-wrt (except for the very smallest firmwares) already include > everything you need, and allow you to configure the two things you need > to get IPv6 working (radvd and the startup commands for the tunnel) from > the gui. > > I'm not saying I'd turn my grandfather loose on this, rather that a > reasonably capable tech-oriented person could go from stock linksys > firmware to having their router as a tunnel endpoint and RA on their > local network in a few hours ... maybe a little more if their > forum/wiki/google search fu is not up to par. > > > hth, > > Doug > > [1] Compare http://www.tunnelbroker.net/forums/index.php?topic=106.0 > From dougb at dougbarton.us Sun Apr 25 07:09:23 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 24 Apr 2010 22:09:23 -0700 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD3C3BF.1020707@ipinc.net> References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> <4BD3A491.9060202@dougbarton.us> <4BD3C3BF.1020707@ipinc.net> Message-ID: <4BD3CE83.1060402@dougbarton.us> On 04/24/10 21:23, Ted Mittelstaedt wrote: > I will chime in on this as I've had a lot of experience with > this firmware. For starters there is no "v26" there is only > V24 and "V24 pre-SP2" Sorry, I got my Ks and Vs mixed up. :) (some snipping below) > The current dd-wrt load is a so-called "beta" of v24 (they call it > pre-SP2 but the new releases have been called that for almost the last 2 > years) it's SVN# 13064, this came out about 4 months ago. The > "official" dd-wrt release does NOT contain good IPv6 support. 13064 is prehistoric. I was using 13575 quite successfully for the last couple months (as noted in my forum post). I just upgraded to 14289 today since poking around on the web site to prepare my first post on this thread led to me noticing a more recent stable snapshot. > Because of this, a user crushedhat decided about 2 years ago to fork > off SVN# 10070 and made a huge boatload of changes to it to > support IPv6 properly. This is detailed here: > > http://www.dd-wrt.com/phpBB2/viewtopic.php?p=196058#196058 > > crushedhat is NOT one of the dd-wrt developers. He DID post > a set of instructions on how he setup the build environment. This is all accurate AFAIK, but it's also no longer necessary. While having the tools like ping6 and traceroute6 on the router can be handy, it's not essential. > The reality of IPv6 on dd-wrt is you either run the developer > released standard loads (which require 4MB flash minimum) > and have a lot of things missing from IPv6 (traceroute6, etc.) > but are the current SVN#, or you run the 2-year-old Crushedhat > SVN fork which has a complete IPv6 implementation but is not > the current SVN, or you use the Crushedhat instructions and > setup a development environment and pull down the current > SVN source, apply the crushedhat mods, then build that one. I think I have already demonstrated that there is another alternative. > The 2 year old crushedhat release is stable and reliable and > so a lot of people run it. But it's clear that we are a ways > off from "official" support of IPv6 from the dd-wrt developers > for 4MB flash units. However, in the long run this may not matter > IF the wireless market jumps en-mass onto the 802.11 N standard. > That is (IMHO) what the dd-wrt developers are betting on, and it's > why they are focusing most of their effort on porting DD-WRT as > quickly as possible to the widest number of N routers that are > on the market, instead of doing what's needed to get a v24 SP2 > release out the door. I'm not going to speculate on motives, but I have noticed that there is less emphasis on making a new official release. This does lead to a situation where you have to do a little searching on the forums to find out what is the most recent stable development snapshot, but the two main producers of them are actually pretty good about doing them on a semi-regular basis, and the members of the community who follow the development on a daily basis are pretty good about testing, commenting, etc. So once again, it's not as easy as even I would like it to be, but it's not rocket science either. > And all of this also applies only to the command-line interface > to dd-wrt. The GUI interface would have to be modified to support > all of the IPv6 utilities (like traceroute6) before you could > point to DD-WRT and call it "grandparent ready" and that is not easy > as it's written in an obfuscated manner (to prevent copying, the > GUI is NOT under the GPL like the rest of DD-WRT is) However, this > isn't any different than OpenWRT, which while it has a good > command-line implementation of IPv6, none of the GUIs that > are out there for OpenWRT support it. (although, those ARE > easily modified) Agreed on both points. I used to use openwrt, and it has some things to recommend it. However (AFAICT) the development has stalled, and they are definitely NOT focusing on newer hardware which means my latest CPE has no openwrt version available for it. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 26 08:46:49 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 16:16:49 +0930 Subject: Fw: IPv6 network policies Message-ID: <20100426161649.425a2f44@opy.nosense.org> Well I took this off-list as Ole requested two weeks ago. As I spent at least 45 minutes on it, and haven't got any response, I thought I'd send it through to the list, so that I'll at least get some value from the time I spent on it. Hopefully it is of some use to others. I think it very clearly justifies why P2P links should have NS/NAs performed - to test address assignment and availability. Begin forwarded message: Date: Mon, 12 Apr 2010 21:49:04 +0930 From: Mark Smith To: Ole Troan Subject: Re: IPv6 network policies Hi Ole, On Mon, 12 Apr 2010 09:21:30 +0200 Ole Troan wrote: > Mark, > > >>> It's well known that the pong pong problem doesn't exist if ND > >>> NS/NAs are used. > >> > >> I presume by saying "NS/NA", you mean the address resolution function of ND. > >> see section 7.2: > >> > >> "Address resolution is the process through which a node determines the > >> link-layer address of a neighbor given only its IP address. Address > >> resolution is performed only on addresses that are determined to be > >> on-link and for which the sender does not know the corresponding > >> link-layer address (see Section 5.2). Address resolution is never > >> performed on multicast addresses." > >> > >> in particular see "does not know the corresponding link-layer address". > >> > > > > I don't agree, because I would consider knowing a link layer address > > doesn't exist (verified by the absence of a NA in response to an NS) as > > significantly different from assuming it exists, which is your > > position. The latter position is what is causing the ping-pong problem. > > where do you get the idea that there are any assumptions made? > the link has no link-layer addresses. there is nothing to resolve. you don't need to send an NS to figure that out, it is a property of the link type. > > I don't think we'll get much further in this discussion, so lets end it here or take it off-list. > Ok. For get for the moment that we're talking about P2P links (and specifically IPv6) What is the purpose of the prefix length when assigning a subnet to an interface? As protocols like IPv6, IPv4, IPX and Appletalk don't track individual end-node addresses, unlike CLNS, the prefix length is an indication of the range addresses that _may_ be present on the link. Some of those addresses may be assigned to devices, others may not. And even then, there is no guarantee that the device will be available when you wish to communicate with it. It could be there when the packet leaves the router's interface, yet while the packet is in flight, the device disappears. IOW, you only know if a packet is going to arrive after it has. This is of course why packet networks are called unreliable/best effort. One of the best ways I've heard to describe this idea is that when a protocol doesn't track end-nodes individually, then routing information is really only a 'hint' - because the routing information summarises information, therefore you are only getting an indication of what might be there, not what is there. Because you summarise information, you lose accuracy. Even then, for protocols that do track end nodes it still is a hint, not a status, because of the target failure during flight scenario. (I think I first read of this hint description in - "48-bit Absolute Internet and Ethernet Host Numbers" - http://ethernethistory.typepad.com/papers/HostNumbers.pdf i.e. the paper than explains why MAC addresses are 48 bits, "way to big" for what you'd operationally need, as well as discussing some other general network addressing issues) So when you assign a /64 to a link in IPv6 (or /24 in IPv4, cable number/range in Appletalk etc), you are saying that there might be 2^64 node addresses attached to the link. Or there might not be. You certainly aren't saying they all are, or even if there were 2^64 assigned addresses, you're still not saying that they'll all be available at the same time. Even when you assign a /31 to an IPv4 p2p link, or an IPv6 /127, you're still only providing a hint. You're restricting the range of available addresses on the link to one other, but you aren't saying it has been assigned, or that it is available. A /31 assigned to only one end of an operationally up p2p link between routers is functionally valid, although usually operationally useless. In other words, IPv6 status information on one end of a P2P link implies, but doesn't 100% constantly and accurately state IPv6 status information on the other end of the link. To be trusted, it has to be tested. Neighbor Discovery protocols (i.e. the NS/NA part of IPv6, AARP for Appletalk etc.) perform two functions: (1) verify remote layer 3 address assignment and availability (2) for protocols that need it, provide layer 2 addressing information for the queried layer 3 address Neither is completely necessary in all scenarios. As you've said, (2) isn't necessary on a P2P link that doesn't have layer 2 addresses. (1) isn't completely necessary, unless you want to generate feedback to the packet origin that it has sent a packet towards an unreachable destination. IPv6 does generate those ICMPv6 messages, actually MUST (from RFC4861, page 61) - "If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT solicitations, address resolution has failed. The sender MUST return ICMP destination unreachable indications with code 3 (Address Unreachable) for each packet queued awaiting address resolution." (The state created to be able to send back these ICMPv6 Address Unreachables is the same state that the ND cache DoS is taking advantage of.) So if you need to to have IPv6 universally provide address unreachable feedback messages, you need to have a neighbor discovery protocol probe for addresses that are onlink targets, regardless of the prefix length assigned to the link. That would even be the case if you assigned /128s on each end of the link, and a static route for the opposite /128 on the opposite router - because the router's local /128 static route could be wrong. If you don't perform (1) on a P2P link, because (2) isn't necessary, the local prefix and prefix length information, for any prefix length (/64 through /127), is stating that all addresses within the prefix are assigned and always available. While this is the common situation with a /127s, as you shorten the prefix length, the less and less accurate this statement becomes. A /64 on a P2P link is atrociously inaccurate, unless the hint it provides is tested. The ping-pong problem is a result of IPv6 routers on both ends of P2P link with a /64 prefix are making this presumption of constant address assignment and 100% availability. They aren't testing to see if a neighbor exists before they try to send to it, and they each take turns falling into the same trap. /127s on P2P links mitigate this issue. That's fine for infrastructure links like backbone SONET/SDH links. /127s aren't an option for residential subscriber PPP/PPPoE P2P links, because the only practical way to provide IPv6 services in that environment is to use either SLAAC or Stateful DHCPv6, and they of course mandate /64s. There is going to hundreds of thousands if not millions of those types of links services around the world. Even though you can share a single /64 amongst multiple PPP sessions on a single router (i.e. an NBMA hub-and-spoke structure), as you can on a Cisco, your business customers, who'll probably want static IPv6 addresses on their ends of their PPP session, regardless of the router they attach to, will require static /64s per PPP session. The ping-pong remedy in RFC4443 is a solution, although if you think about it, if address availability checking via Neighbor Discovery was performed in the first place, the packet that is not "ponged back", instead generating the ICMP Address Unreachable, would have never arrived in the first place. (On related side note, RFC4443 should be mandatory in the simple CPE draft. In the last few days, I've seen CPE that suffers from the ping pong problem because it doesn't do Neighbor Discovery NS/NA on it's PPP/PPPoE link, and hasn't implemented RFC4443.) Regards, Mark. From otroan at employees.org Mon Apr 26 08:53:02 2010 From: otroan at employees.org (Ole Troan) Date: Mon, 26 Apr 2010 08:53:02 +0200 Subject: IPv6 network policies In-Reply-To: <20100426161649.425a2f44@opy.nosense.org> References: <20100426161649.425a2f44@opy.nosense.org> Message-ID: <1DC19D95-58D9-4307-8A18-38DDC347759F@employees.org> Mark, > Well I took this off-list as Ole requested two weeks ago. As I spent at > least 45 minutes on it, and haven't got any response, I thought I'd > send it through to the list, so that I'll at least get some value from > the time I spent on it. Hopefully it is of some use to others. I think > it very clearly justifies why P2P links should have NS/NAs performed - > to test address assignment and availability. so you didn't get this reply from April 13? From: Ole Troan Subject: Re: IPv6 network policies Date: April 13, 2010 0:45:29 GMT+02:00 To: Mark Smith Mark, [...] > So when you assign a /64 to a link in IPv6 (or /24 in IPv4, cable > number/range in Appletalk etc), you are saying that there might be > 2^64 node addresses attached to the link. Or there might not be. You > certainly aren't saying they all are, or even if there were 2^64 > assigned addresses, you're still not saying that they'll all be > available at the same time. > > Even when you assign a /31 to an IPv4 p2p link, or an IPv6 /127, you're > still only providing a hint. You're restricting the range of > available addresses on the link to one other, but you aren't saying it > has been assigned, or that it is available. A /31 assigned to only one > end of an operationally up p2p link between routers is functionally > valid, although usually operationally useless. In other words, IPv6 > status information on one end of a P2P link implies, but doesn't 100% > constantly and accurately state IPv6 status information on the other > end of the link. To be trusted, it has to be tested. the prefix-length used says nothing about which other nodes exist on the link or which addresses they may use. the prefix-length or subnet information is only used for onlink determination. so I wouldn't consider the prefix length as a hint of anything. you can obviously guess the other end's address if the prefix length was /127, but that's more of an artifact. > Neighbor Discovery protocols (i.e. the NS/NA part of IPv6, AARP for > Appletalk etc.) perform two functions: > > (1) verify remote layer 3 address assignment and availability yes. probably better with the term "reachability" to cover this. > (2) for protocols that need it, provide layer 2 addressing information > for the queried layer 3 address > > > Neither is completely necessary in all scenarios. As you've said, (2) > isn't necessary on a P2P link that doesn't have layer 2 addresses. > > (1) isn't completely necessary, unless you want to generate feedback to > the packet origin that it has sent a packet towards an unreachable > destination. IPv6 does generate those ICMPv6 messages, actually MUST > (from RFC4861, page 61) - > > "If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT > solicitations, address resolution has failed. The sender MUST return > ICMP destination unreachable indications with code 3 (Address > Unreachable) for each packet queued awaiting address resolution." > > (The state created to be able to send back these ICMPv6 Address > Unreachables is the same state that the ND cache DoS is taking > advantage of.) > > So if you need to to have IPv6 universally provide address > unreachable feedback messages, you need to have a neighbor discovery > protocol probe for addresses that are onlink targets, regardless of the > prefix length assigned to the link. That would even be the case if you > assigned /128s on each end of the link, and a static route for the > opposite /128 on the opposite router - because the router's local /128 > static route could be wrong. in that case they could hardly be considered on-link. > If you don't perform (1) on a P2P link, because (2) isn't > necessary, the local prefix and prefix length information, for any > prefix length (/64 through /127), is stating that all addresses within > the prefix are assigned and always available. While this is the common > situation with a /127s, as you shorten the prefix length, the less and > less accurate this statement becomes. A /64 on a P2P link is > atrociously inaccurate, unless the hint it provides is tested. in my view this is entirely independent of the prefix length. > The ping-pong problem is a result of IPv6 routers on both ends of P2P > link with a /64 prefix are making this presumption of constant address > assignment and 100% availability. They aren't testing to see if a > neighbor exists before they try to send to it, and they each take turns > falling into the same trap. no, they just forward packets following the routing table doing a longest match on the destination. again this is independent of the prefix length used. this does hit an ICMP redirect exception case of course, since the packet will be sent out the same interface as it arrived. which is the solution offered by RFC4443. > /127s on P2P links mitigate this issue. That's fine for infrastructure > links like backbone SONET/SDH links. /127s aren't an option for > residential subscriber PPP/PPPoE P2P links, because the only practical > way to provide IPv6 services in that environment is to use either SLAAC > or Stateful DHCPv6, and they of course mandate /64s. There is going to > hundreds of thousands if not millions of those types of links services > around the world. Even though you can share a single /64 > amongst multiple PPP sessions on a single router (i.e. an NBMA > hub-and-spoke structure), as you can on a Cisco, your business > customers, who'll probably want static IPv6 addresses on their ends of > their PPP session, regardless of the router they attach to, will require > static /64s per PPP session. agree, a /127 is not an acceptable workaround for this case. assuming you knew there was a router on the other end you don't have to use global addresses on the link at all. > The ping-pong remedy in RFC4443 is a solution, although if you > think about it, if address availability checking via Neighbor Discovery > was performed in the first place, the packet that is not "ponged back", > instead generating the ICMP Address Unreachable, would have never > arrived in the first place. that's correct. > (On related side note, RFC4443 should be mandatory in the simple CPE > draft. In the last few days, I've seen CPE that suffers from the ping > pong problem because it doesn't do Neighbor Discovery NS/NA on it's > PPP/PPPoE link, and hasn't implemented RFC4443.) yes, we should probably add that requirement. it has passed WG last call, but let me see if we can get it in. do you have proposed text? as I said on the list, if you want to change the behaviour of IPv6 to always use ND before communicating to on-link nodes on any type of link, then you need to write a draft. plan to? I would not object to such a solution. cheers, Ole From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 26 09:47:43 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 17:17:43 +0930 Subject: IPv6 network policies In-Reply-To: <1DC19D95-58D9-4307-8A18-38DDC347759F@employees.org> References: <20100426161649.425a2f44@opy.nosense.org> <1DC19D95-58D9-4307-8A18-38DDC347759F@employees.org> Message-ID: <20100426171743.2c929993@opy.nosense.org> Hi Ole, On Mon, 26 Apr 2010 08:53:02 +0200 Ole Troan wrote: > Mark, > > > Well I took this off-list as Ole requested two weeks ago. As I spent at > > least 45 minutes on it, and haven't got any response, I thought I'd > > send it through to the list, so that I'll at least get some value from > > the time I spent on it. Hopefully it is of some use to others. I think > > it very clearly justifies why P2P links should have NS/NAs performed - > > to test address assignment and availability. > > > so you didn't get this reply from April 13? > I've just checked my inbox, and it seems that I did. It was unread, so I'm not sure how I missed it - I have 94 unread emails currently, and it seems that threading of replies in my inbox is hiding ones like this. My sincere apologies for missing it. > From: Ole Troan > Subject: Re: IPv6 network policies > Date: April 13, 2010 0:45:29 GMT+02:00 > To: Mark Smith > > Mark, > > [...] > > yes, we should probably add that requirement. it has passed WG last > call, but let me see if we can get it in. do you have proposed text? Is there still an opportunity for this? > > as I said on the list, if you want to change the behaviour of IPv6 to always use ND before communicating to on-link nodes on any type of link, then you need to write a draft. plan to? > I would not object to such a solution. > I'm happy to if it is necessary. My interpretation though, because I can't find any 'special casing' of P2P links in the RFCs, is that that is how things are supposed to be. I presume 6man be the best place to get a determination on that before I spend time developing a draft? Regards, Mark. From otroan at employees.org Mon Apr 26 09:56:29 2010 From: otroan at employees.org (Ole Troan) Date: Mon, 26 Apr 2010 09:56:29 +0200 Subject: IPv6 network policies In-Reply-To: <20100426171743.2c929993@opy.nosense.org> References: <20100426161649.425a2f44@opy.nosense.org> <1DC19D95-58D9-4307-8A18-38DDC347759F@employees.org> <20100426171743.2c929993@opy.nosense.org> Message-ID: <602CC0AD-4C5B-4CA9-B471-0783F83F95BC@employees.org> Mark, [...] >> yes, we should probably add that requirement. it has passed WG last >> call, but let me see if we can get it in. do you have proposed text? > > Is there still an opportunity for this? yes, I believe so. it hasn't gone to the IESG yet. >> as I said on the list, if you want to change the behaviour of IPv6 to always use ND before communicating to on-link nodes on any type of link, then you need to write a draft. plan to? >> I would not object to such a solution. >> > > I'm happy to if it is necessary. My interpretation though, because I > can't find any 'special casing' of P2P links in the RFCs, is that that > is how things are supposed to be. I presume 6man be the best place to > get a determination on that before I spend time developing a draft? yep, I also think 6man is the best place. cheers, Ole From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Apr 26 09:59:14 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 26 Apr 2010 17:29:14 +0930 Subject: IPv6 network policies In-Reply-To: <602CC0AD-4C5B-4CA9-B471-0783F83F95BC@employees.org> References: <20100426161649.425a2f44@opy.nosense.org> <1DC19D95-58D9-4307-8A18-38DDC347759F@employees.org> <20100426171743.2c929993@opy.nosense.org> <602CC0AD-4C5B-4CA9-B471-0783F83F95BC@employees.org> Message-ID: <20100426172914.5e4064d5@opy.nosense.org> Hi Ole, On Mon, 26 Apr 2010 09:56:29 +0200 Ole Troan wrote: > Mark, > > [...] > > >> yes, we should probably add that requirement. it has passed WG last > >> call, but let me see if we can get it in. do you have proposed text? > > > > Is there still an opportunity for this? > > yes, I believe so. it hasn't gone to the IESG yet. > Good, I'll come up with something. > >> as I said on the list, if you want to change the behaviour of IPv6 to always use ND before communicating to on-link nodes on any type of link, then you need to write a draft. plan to? > >> I would not object to such a solution. > >> > > > > I'm happy to if it is necessary. My interpretation though, because I > > can't find any 'special casing' of P2P links in the RFCs, is that that > > is how things are supposed to be. I presume 6man be the best place to > > get a determination on that before I spend time developing a draft? > > yep, I also think 6man is the best place. > Ok, thanks. > cheers, > Ole > Regards, Mark. From d at teklibre.org Mon Apr 26 15:45:31 2010 From: d at teklibre.org (Dave Taht) Date: Mon, 26 Apr 2010 07:45:31 -0600 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD3CE83.1060402@dougbarton.us> References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> <4BD3A491.9060202@dougbarton.us> <4BD3C3BF.1020707@ipinc.net> <4BD3CE83.1060402@dougbarton.us> Message-ID: <4BD598FB.9090006@teklibre.org> On 04/24/2010 11:09 PM, Doug Barton wrote: > And all of this also applies only to the command-line interface >> to dd-wrt. The GUI interface would have to be modified to support >> all of the IPv6 utilities (like traceroute6) before you could >> point to DD-WRT and call it "grandparent ready" and that is not easy >> as it's written in an obfuscated manner (to prevent copying, the >> GUI is NOT under the GPL like the rest of DD-WRT is) However, this >> isn't any different than OpenWRT, which while it has a good >> command-line implementation of IPv6, none of the GUIs that >> are out there for OpenWRT support it. (although, those ARE >> easily modified) >> > Agreed on both points. I used to use openwrt, and it has some things to > recommend it. However (AFAICT) the development has stalled, and they are > definitely NOT focusing on newer hardware which means my latest CPE has > no openwrt version available for it. > I don't quite "get" where you say openwrt has stalled. In recent weeks they rapidly went through several rc candidates and came out with a brand new version, called "backfire", which supports, among many other things, the mac80211 drivers and Linux 2.6.32. The commit logs are quite active for the project. I've been using openwrt as my base for new ipv6 related development for the sheevaplug, nanostation M5, and nanostation 2HP. It's working pretty great. I definately think they gave up trying to carry 2.4.x forward or coping with routers with less than 4MB flash, but for better routers, they seem to be rather closely following the kernel mainline and wireless trees. Lastly, although I don't use it myself, at least one of the guis does support IPv6 to at least some extent. > > hth, > > Doug > > From frnkblk at iname.com Mon Apr 26 16:36:38 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 26 Apr 2010 09:36:38 -0500 Subject: Testing your IPv6 connectivity Message-ID: Jason Fesler of gigo.com has put together a javascript-based IPv6 test that goes through several simple checks of your IPv6 connectivity. http://test-ipv6.com It's basically a public facing version of the kinds of tests Geoff Huston/APNIC, Google, and a few others have been doing to measure IPv6 usage levels. Jason is open to feedback, so if something is not working like you believe it should, or you have suggestions for improvement, please include that in the comment section. More here: http://markmail.org/message/hhw65igc75rhec3n Regards, Frank From dougb at dougbarton.us Mon Apr 26 20:58:38 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 26 Apr 2010 11:58:38 -0700 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD598FB.9090006@teklibre.org> References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> <4BD3A491.9060202@dougbarton.us> <4BD3C3BF.1020707@ipinc.net> <4BD3CE83.1060402@dougbarton.us> <4BD598FB.9090006@teklibre.org> Message-ID: <4BD5E25E.7020600@dougbarton.us> On 04/26/10 06:45, Dave Taht wrote: > On 04/24/2010 11:09 PM, Doug Barton wrote: >> And all of this also applies only to the command-line interface >>> to dd-wrt. The GUI interface would have to be modified to support >>> all of the IPv6 utilities (like traceroute6) before you could >>> point to DD-WRT and call it "grandparent ready" and that is not easy >>> as it's written in an obfuscated manner (to prevent copying, the >>> GUI is NOT under the GPL like the rest of DD-WRT is) However, this >>> isn't any different than OpenWRT, which while it has a good >>> command-line implementation of IPv6, none of the GUIs that >>> are out there for OpenWRT support it. (although, those ARE >>> easily modified) >>> >> Agreed on both points. I used to use openwrt, and it has some things to >> recommend it. However (AFAICT) the development has stalled, and they are >> definitely NOT focusing on newer hardware which means my latest CPE has >> no openwrt version available for it. >> > > I don't quite "get" where you say openwrt has stalled. Sorry, I wasn't clear, I was referring to development for new hardware. I can't run it on my newest AP, so it's not relevant to me. :) Doug From d at teklibre.org Mon Apr 26 21:27:13 2010 From: d at teklibre.org (Dave Taht) Date: Mon, 26 Apr 2010 13:27:13 -0600 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD5E25E.7020600@dougbarton.us> References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> <4BD3A491.9060202@dougbarton.us> <4BD3C3BF.1020707@ipinc.net> <4BD3CE83.1060402@dougbarton.us> <4BD598FB.9090006@teklibre.org> <4BD5E25E.7020600@dougbarton.us> Message-ID: <4BD5E911.3030801@teklibre.org> On 04/26/2010 12:58 PM, Doug Barton wrote: > On 04/26/10 06:45, Dave Taht wrote: > >> On 04/24/2010 11:09 PM, Doug Barton wrote: >> >>> And all of this also applies only to the command-line interface >>> >>>> to dd-wrt. The GUI interface would have to be modified to support >>>> all of the IPv6 utilities (like traceroute6) before you could >>>> point to DD-WRT and call it "grandparent ready" and that is not easy >>>> as it's written in an obfuscated manner (to prevent copying, the >>>> GUI is NOT under the GPL like the rest of DD-WRT is) However, this >>>> isn't any different than OpenWRT, which while it has a good >>>> command-line implementation of IPv6, none of the GUIs that >>>> are out there for OpenWRT support it. (although, those ARE >>>> easily modified) >>>> >>>> >>> Agreed on both points. I used to use openwrt, and it has some things to >>> recommend it. However (AFAICT) the development has stalled, and they are >>> definitely NOT focusing on newer hardware which means my latest CPE has >>> no openwrt version available for it. >>> >>> >> I don't quite "get" where you say openwrt has stalled. >> > Sorry, I wasn't clear, I was referring to development for new hardware. > I can't run it on my newest AP, so it's not relevant to me. :) > > > Doug > The equipment I mentioned is all "new hardware", shipped or developed in the past year. The Guruplugs, in particular, are an excellent candidate for CPE. (They are what I intend to use, anyway - I've been using the open-rt development box with great success) http://www.globalscaletechnologies.com/t-guruplugdetails.aspx From gert at space.net Mon Apr 26 22:50:22 2010 From: gert at space.net (Gert Doering) Date: Mon, 26 Apr 2010 22:50:22 +0200 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD5E911.3030801@teklibre.org> References: <4BD34932.3000107@dougbarton.us> <4BD3A491.9060202@dougbarton.us> <4BD3C3BF.1020707@ipinc.net> <4BD3CE83.1060402@dougbarton.us> <4BD598FB.9090006@teklibre.org> <4BD5E25E.7020600@dougbarton.us> <4BD5E911.3030801@teklibre.org> Message-ID: <20100426205022.GZ67092@Space.Net> Hi, On Mon, Apr 26, 2010 at 01:27:13PM -0600, Dave Taht wrote: > The equipment I mentioned is all "new hardware", shipped or developed in > the past year. > > The Guruplugs, in particular, are an excellent candidate for CPE. (They > are what I intend to use, anyway - I've been using the open-rt > development box with great success) > > http://www.globalscaletechnologies.com/t-guruplugdetails.aspx I find OpenWRT to not overly well suited for the GuruPlug - on a box with that much flash (512Mb), I'd just install off-the-shelf debian/ARM, with man pages, full-featured programs, etc. Which is exactly what I've done on my OpenRD Client (which is based on the the same SoC) :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tedm at ipinc.net Mon Apr 26 23:16:45 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 26 Apr 2010 14:16:45 -0700 Subject: Comcast's IPv6 CPE selection In-Reply-To: <4BD5E911.3030801@teklibre.org> References: <4BD31BD6.7000807@ipinc.net> <4BD34932.3000107@dougbarton.us> <4BD3A491.9060202@dougbarton.us> <4BD3C3BF.1020707@ipinc.net> <4BD3CE83.1060402@dougbarton.us> <4BD598FB.9090006@teklibre.org> <4BD5E25E.7020600@dougbarton.us> <4BD5E911.3030801@teklibre.org> Message-ID: <4BD602BD.1080606@ipinc.net> On 4/26/2010 12:27 PM, Dave Taht wrote: > On 04/26/2010 12:58 PM, Doug Barton wrote: >> On 04/26/10 06:45, Dave Taht wrote: >>> On 04/24/2010 11:09 PM, Doug Barton wrote: >>>> And all of this also applies only to the command-line interface >>>>> to dd-wrt. The GUI interface would have to be modified to support >>>>> all of the IPv6 utilities (like traceroute6) before you could >>>>> point to DD-WRT and call it "grandparent ready" and that is not easy >>>>> as it's written in an obfuscated manner (to prevent copying, the >>>>> GUI is NOT under the GPL like the rest of DD-WRT is) However, this >>>>> isn't any different than OpenWRT, which while it has a good >>>>> command-line implementation of IPv6, none of the GUIs that >>>>> are out there for OpenWRT support it. (although, those ARE >>>>> easily modified) >>>>> >>>> Agreed on both points. I used to use openwrt, and it has some things to >>>> recommend it. However (AFAICT) the development has stalled, and they >>>> are >>>> definitely NOT focusing on newer hardware which means my latest CPE has >>>> no openwrt version available for it. >>>> >>> I don't quite "get" where you say openwrt has stalled. >> Sorry, I wasn't clear, I was referring to development for new hardware. >> I can't run it on my newest AP, so it's not relevant to me. :) >> >> >> Doug > > The equipment I mentioned is all "new hardware", shipped or developed in > the past year. > I think the problem is that the OpenWRT people don't want to use the manufacturer-supplied "binary blob" drivers for the radios, and so in the current OpenWRT they have been dragging their feet on including those. For example with the WRT160N (I think that's the one that Doug has) they dragged and dragged their feet waiting for the open source b43 driver to be released by Broadcom - then at the last minute they must have written Broadcom directly and got permission to redistribute the "binary blob" driver for the Linux 2.6 kernel for the chip in the WRT 160N version 1. (that blob driver is in the Backfire release for the 150N, but you have to really dig to find a last-minute note about this here: http://sites.google.com/site/snipes4202/wrt160n-notes ) In the meanwhile the DD-WRT project seems to have always had the philosophy that if the manufacturer has released a "binary blob" driver for a radio, they would just write them and get permission for redistribution. As a result that has allowed them to not only support the 160N v 1/1.1 but also the 160N v3 - a platform that the OpenWRT people haven't even started building for. I can understand the OpenWRT's team's philosophy as that's straight out of the RMS "never compromise your principles, even if it means the user just isn't going to get software at all for something" handbook, and they must be ardent disciples. The DD-WRT approach is definitely more pragmatic. But the problem is that both OpenWRT and DD-WRT are the fleas on the dog's back and when the dog wants to run the fleas just have to hang on and recognize they aren't going to be able to force the dog to change. Ted From martin at hotze.com Tue Apr 27 15:00:56 2010 From: martin at hotze.com (Martin Hotze) Date: Tue, 27 Apr 2010 15:00:56 +0200 Subject: save the date: nov 8th 2010 - RIPE IPv6 Training Course in Innsbruck Message-ID: <275E689A52D3FD4E922743D02EAEA8FA32975E@server1.hotze.local> Hello, for folks from southern Germany/western Austria, etc: save the date for the RIPE IPv6 Training Course in Innsbruck [1], Tyrol, Austria, on Monday, November 8th 2010. We (hotze.com, AS8596) are hosting the training. ---snip - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html ---snap greetings, martin [1] Google Map: http://shorl.com/stenomukystaso From frnkblk at iname.com Tue Apr 27 19:31:32 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 27 Apr 2010 12:31:32 -0500 Subject: CMTS support of IPv6 Message-ID: Just got off the phone with the pre-sales tech support person for our CMTS vendor, Motorola. He shared that "no one is asking for IPv6", "none of my customers have asked about it", and plans are for full support in 2H 2011. Also shared that we will likely see CPE (by that he means CM and CM gateway) support via firmware upgrades. He says the market and therefore software and hardware development focus has been on bandwidth -- more downstream and upstream channel bonding. There's some IPv6 support in the existing code base, but he wasn't able to describe where it's lacking. I know it's missing some dynamic routing protocol support, but I haven't yet identified any other feature gaps. So anyone who has Motorola CMTS gear, I would encourage them to talk to their sales person and encourage them to make it a greater priority. Frank From paul at paulstewart.org Tue Apr 27 19:41:56 2010 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 27 Apr 2010 13:41:56 -0400 Subject: CMTS support of IPv6 In-Reply-To: References: Message-ID: <03c901cae630$ef4a67d0$cddf3770$@org> Interesting.. thanks for sharing that. Today we run Cisco 7246VXR and there's internal discussions around either adding more of them or moving to Motorola. The question around IPv6 was raised but nobody pursued an answer that I know of. Speaking of, does anyone know if the 7246VXR properly supports IPv6? Best regards, Paul -----Original Message----- From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf Of Frank Bulk - iName.com Sent: April-27-10 1:32 PM To: ipv6-ops at lists.cluenet.de Subject: CMTS support of IPv6 Just got off the phone with the pre-sales tech support person for our CMTS vendor, Motorola. He shared that "no one is asking for IPv6", "none of my customers have asked about it", and plans are for full support in 2H 2011. Also shared that we will likely see CPE (by that he means CM and CM gateway) support via firmware upgrades. He says the market and therefore software and hardware development focus has been on bandwidth -- more downstream and upstream channel bonding. There's some IPv6 support in the existing code base, but he wasn't able to describe where it's lacking. I know it's missing some dynamic routing protocol support, but I haven't yet identified any other feature gaps. So anyone who has Motorola CMTS gear, I would encourage them to talk to their sales person and encourage them to make it a greater priority. Frank From chris at uplogon.com Tue Apr 27 20:44:32 2010 From: chris at uplogon.com (Chris Gotstein) Date: Tue, 27 Apr 2010 13:44:32 -0500 Subject: CMTS support of IPv6 In-Reply-To: <03c901cae630$ef4a67d0$cddf3770$@org> References: <03c901cae630$ef4a67d0$cddf3770$@org> Message-ID: <4BD73090.2030109@uplogon.com> We are running a uBR7246 CMTS and i have it configured with an IPv6 address on the loopback and bundle. Since we are using CNR version 6.x, we cannot push out IPv6 addresses to the end-user at this time. CNR version 7.x is supposed to have full support for IPv6 clients. We are also only running DOCSIS 1.1/2.0 modems which do not support IPv6. So bottom line is that the Cisco CMTS supports IPv6, but the provisioning software (6.x) and the modems (DOCSIS 1.1/2.0) to do not currently support IPv6. ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com On 4/27/2010 12:41 PM, Paul Stewart wrote: > Interesting.. thanks for sharing that. Today we run Cisco 7246VXR and > there's internal discussions around either adding more of them or moving to > Motorola. The question around IPv6 was raised but nobody pursued an answer > that I know of. > > Speaking of, does anyone know if the 7246VXR properly supports IPv6? > > Best regards, > > Paul > > > -----Original Message----- > From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de > [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf Of > Frank Bulk - iName.com > Sent: April-27-10 1:32 PM > To: ipv6-ops at lists.cluenet.de > Subject: CMTS support of IPv6 > > Just got off the phone with the pre-sales tech support person for our CMTS > vendor, Motorola. He shared that "no one is asking for IPv6", "none of my > customers have asked about it", and plans are for full support in 2H 2011. > Also shared that we will likely see CPE (by that he means CM and CM gateway) > support via firmware upgrades. He says the market and therefore software > and hardware development focus has been on bandwidth -- more downstream and > upstream channel bonding. > > There's some IPv6 support in the existing code base, but he wasn't able to > describe where it's lacking. I know it's missing some dynamic routing > protocol support, but I haven't yet identified any other feature gaps. > > So anyone who has Motorola CMTS gear, I would encourage them to talk to > their sales person and encourage them to make it a greater priority. > > Frank > > > From frnkblk at iname.com Tue Apr 27 21:11:25 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 27 Apr 2010 14:11:25 -0500 Subject: CMTS support of IPv6 In-Reply-To: <03c901cae630$ef4a67d0$cddf3770$@org> References: <03c901cae630$ef4a67d0$cddf3770$@org> Message-ID: Based on Comcast's publicized plans (http://www.comcast6.net/), Cisco and Arris are ready. In fact, Comcast can't start one of its IPv6 trials with Moto at this time. Frank -----Original Message----- From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of Paul Stewart Sent: Tuesday, April 27, 2010 12:42 PM To: frnkblk at iname.com; ipv6-ops at lists.cluenet.de Subject: RE: CMTS support of IPv6 Interesting.. thanks for sharing that. Today we run Cisco 7246VXR and there's internal discussions around either adding more of them or moving to Motorola. The question around IPv6 was raised but nobody pursued an answer that I know of. Speaking of, does anyone know if the 7246VXR properly supports IPv6? Best regards, Paul -----Original Message----- From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf Of Frank Bulk - iName.com Sent: April-27-10 1:32 PM To: ipv6-ops at lists.cluenet.de Subject: CMTS support of IPv6 Just got off the phone with the pre-sales tech support person for our CMTS vendor, Motorola. He shared that "no one is asking for IPv6", "none of my customers have asked about it", and plans are for full support in 2H 2011. Also shared that we will likely see CPE (by that he means CM and CM gateway) support via firmware upgrades. He says the market and therefore software and hardware development focus has been on bandwidth -- more downstream and upstream channel bonding. There's some IPv6 support in the existing code base, but he wasn't able to describe where it's lacking. I know it's missing some dynamic routing protocol support, but I haven't yet identified any other feature gaps. So anyone who has Motorola CMTS gear, I would encourage them to talk to their sales person and encourage them to make it a greater priority. Frank From frnkblk at iname.com Tue Apr 27 22:23:33 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 27 Apr 2010 15:23:33 -0500 Subject: CMTS support of IPv6 In-Reply-To: <4BD73090.2030109@uplogon.com> References: <03c901cae630$ef4a67d0$cddf3770$@org> <4BD73090.2030109@uplogon.com> Message-ID: We don't need IPv6 for CM management, just for customer equipment (CPE, not to be confused with what Moto calls CPE which include Surfboard cable modems and gateways). So the lack of IPv6 support for CMs is actually fine with me. Frank -----Original Message----- From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of Chris Gotstein Sent: Tuesday, April 27, 2010 1:45 PM To: ipv6-ops at lists.cluenet.de Subject: Re: CMTS support of IPv6 We are running a uBR7246 CMTS and i have it configured with an IPv6 address on the loopback and bundle. Since we are using CNR version 6.x, we cannot push out IPv6 addresses to the end-user at this time. CNR version 7.x is supposed to have full support for IPv6 clients. We are also only running DOCSIS 1.1/2.0 modems which do not support IPv6. So bottom line is that the Cisco CMTS supports IPv6, but the provisioning software (6.x) and the modems (DOCSIS 1.1/2.0) to do not currently support IPv6. ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com On 4/27/2010 12:41 PM, Paul Stewart wrote: > Interesting.. thanks for sharing that. Today we run Cisco 7246VXR and > there's internal discussions around either adding more of them or moving to > Motorola. The question around IPv6 was raised but nobody pursued an answer > that I know of. > > Speaking of, does anyone know if the 7246VXR properly supports IPv6? > > Best regards, > > Paul > > > -----Original Message----- > From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de > [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf Of > Frank Bulk - iName.com > Sent: April-27-10 1:32 PM > To: ipv6-ops at lists.cluenet.de > Subject: CMTS support of IPv6 > > Just got off the phone with the pre-sales tech support person for our CMTS > vendor, Motorola. He shared that "no one is asking for IPv6", "none of my > customers have asked about it", and plans are for full support in 2H 2011. > Also shared that we will likely see CPE (by that he means CM and CM gateway) > support via firmware upgrades. He says the market and therefore software > and hardware development focus has been on bandwidth -- more downstream and > upstream channel bonding. > > There's some IPv6 support in the existing code base, but he wasn't able to > describe where it's lacking. I know it's missing some dynamic routing > protocol support, but I haven't yet identified any other feature gaps. > > So anyone who has Motorola CMTS gear, I would encourage them to talk to > their sales person and encourage them to make it a greater priority. > > Frank > > > From chris at uplogon.com Tue Apr 27 23:43:58 2010 From: chris at uplogon.com (Chris Gotstein) Date: Tue, 27 Apr 2010 16:43:58 -0500 Subject: CMTS support of IPv6 In-Reply-To: References: <03c901cae630$ef4a67d0$cddf3770$@org> <4BD73090.2030109@uplogon.com> Message-ID: <4BD75A9E.3000901@uplogon.com> I agree. I don't see the need for the CM to support IPv6. I'm more interested in pushing IPv6 to the customers router or PC. But for us this requires an upgrade to our provisioning software, which is cost prohibitive right now. ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com On 4/27/2010 3:23 PM, Frank Bulk - iName.com wrote: > We don't need IPv6 for CM management, just for customer equipment (CPE, not > to be confused with what Moto calls CPE which include Surfboard cable modems > and gateways). So the lack of IPv6 support for CMs is actually fine with > me. > > Frank > > -----Original Message----- > From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de > [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of > Chris Gotstein > Sent: Tuesday, April 27, 2010 1:45 PM > To: ipv6-ops at lists.cluenet.de > Subject: Re: CMTS support of IPv6 > > We are running a uBR7246 CMTS and i have it configured with an IPv6 > address on the loopback and bundle. Since we are using CNR version 6.x, > we cannot push out IPv6 addresses to the end-user at this time. CNR > version 7.x is supposed to have full support for IPv6 clients. We are > also only running DOCSIS 1.1/2.0 modems which do not support IPv6. So > bottom line is that the Cisco CMTS supports IPv6, but the provisioning > software (6.x) and the modems (DOCSIS 1.1/2.0) to do not currently > support IPv6. > > ---- ---- ---- ---- > Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP > http://uplogon.com | +1 906 774 4847 | chris at uplogon.com > > On 4/27/2010 12:41 PM, Paul Stewart wrote: >> Interesting.. thanks for sharing that. Today we run Cisco 7246VXR and >> there's internal discussions around either adding more of them or moving > to >> Motorola. The question around IPv6 was raised but nobody pursued an > answer >> that I know of. >> >> Speaking of, does anyone know if the 7246VXR properly supports IPv6? >> >> Best regards, >> >> Paul >> >> >> -----Original Message----- >> From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de >> [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf > Of >> Frank Bulk - iName.com >> Sent: April-27-10 1:32 PM >> To: ipv6-ops at lists.cluenet.de >> Subject: CMTS support of IPv6 >> >> Just got off the phone with the pre-sales tech support person for our CMTS >> vendor, Motorola. He shared that "no one is asking for IPv6", "none of my >> customers have asked about it", and plans are for full support in 2H 2011. >> Also shared that we will likely see CPE (by that he means CM and CM > gateway) >> support via firmware upgrades. He says the market and therefore software >> and hardware development focus has been on bandwidth -- more downstream > and >> upstream channel bonding. >> >> There's some IPv6 support in the existing code base, but he wasn't able to >> describe where it's lacking. I know it's missing some dynamic routing >> protocol support, but I haven't yet identified any other feature gaps. >> >> So anyone who has Motorola CMTS gear, I would encourage them to talk to >> their sales person and encourage them to make it a greater priority. >> >> Frank >> >> >> > From frnkblk at iname.com Tue Apr 27 23:46:17 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 27 Apr 2010 16:46:17 -0500 Subject: CMTS support of IPv6 In-Reply-To: <4BD75A9E.3000901@uplogon.com> References: <03c901cae630$ef4a67d0$cddf3770$@org> <4BD73090.2030109@uplogon.com> <4BD75A9E.3000901@uplogon.com> Message-ID: How does configuring IPv6 support tie into the provisioning software? Assigning static IPs to CPE? Frank -----Original Message----- From: Chris Gotstein [mailto:chris at uplogon.com] Sent: Tuesday, April 27, 2010 4:44 PM To: frnkblk at iname.com Cc: ipv6-ops at lists.cluenet.de Subject: Re: CMTS support of IPv6 I agree. I don't see the need for the CM to support IPv6. I'm more interested in pushing IPv6 to the customers router or PC. But for us this requires an upgrade to our provisioning software, which is cost prohibitive right now. ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com On 4/27/2010 3:23 PM, Frank Bulk - iName.com wrote: > We don't need IPv6 for CM management, just for customer equipment (CPE, not > to be confused with what Moto calls CPE which include Surfboard cable modems > and gateways). So the lack of IPv6 support for CMs is actually fine with > me. > > Frank > > -----Original Message----- > From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de > [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of > Chris Gotstein > Sent: Tuesday, April 27, 2010 1:45 PM > To: ipv6-ops at lists.cluenet.de > Subject: Re: CMTS support of IPv6 > > We are running a uBR7246 CMTS and i have it configured with an IPv6 > address on the loopback and bundle. Since we are using CNR version 6.x, > we cannot push out IPv6 addresses to the end-user at this time. CNR > version 7.x is supposed to have full support for IPv6 clients. We are > also only running DOCSIS 1.1/2.0 modems which do not support IPv6. So > bottom line is that the Cisco CMTS supports IPv6, but the provisioning > software (6.x) and the modems (DOCSIS 1.1/2.0) to do not currently > support IPv6. > > ---- ---- ---- ---- > Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP > http://uplogon.com | +1 906 774 4847 | chris at uplogon.com > > On 4/27/2010 12:41 PM, Paul Stewart wrote: >> Interesting.. thanks for sharing that. Today we run Cisco 7246VXR and >> there's internal discussions around either adding more of them or moving > to >> Motorola. The question around IPv6 was raised but nobody pursued an > answer >> that I know of. >> >> Speaking of, does anyone know if the 7246VXR properly supports IPv6? >> >> Best regards, >> >> Paul >> >> >> -----Original Message----- >> From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de >> [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf > Of >> Frank Bulk - iName.com >> Sent: April-27-10 1:32 PM >> To: ipv6-ops at lists.cluenet.de >> Subject: CMTS support of IPv6 >> >> Just got off the phone with the pre-sales tech support person for our CMTS >> vendor, Motorola. He shared that "no one is asking for IPv6", "none of my >> customers have asked about it", and plans are for full support in 2H 2011. >> Also shared that we will likely see CPE (by that he means CM and CM > gateway) >> support via firmware upgrades. He says the market and therefore software >> and hardware development focus has been on bandwidth -- more downstream > and >> upstream channel bonding. >> >> There's some IPv6 support in the existing code base, but he wasn't able to >> describe where it's lacking. I know it's missing some dynamic routing >> protocol support, but I haven't yet identified any other feature gaps. >> >> So anyone who has Motorola CMTS gear, I would encourage them to talk to >> their sales person and encourage them to make it a greater priority. >> >> Frank >> >> >> > From phrickman at upcbroadband.com Wed Apr 28 08:50:11 2010 From: phrickman at upcbroadband.com (Rickman, Phil) Date: Wed, 28 Apr 2010 08:50:11 +0200 Subject: CMTS support of IPv6 In-Reply-To: <03c901cae630$ef4a67d0$cddf3770$@org> References: , <03c901cae630$ef4a67d0$cddf3770$@org> Message-ID: UBR 10ks have full support but it is software based forwarding We see a 70-90 increase in processor load with 5-10 meg of transit traffic. The new SCD release is due sometime in the next few weeks for testing. Casa also have IPv6 implementation but their IGPs a scant to say the least and really not a supportable configuration We also have the Motorolas but i have yet to test them but once I do will let you know how they turn out. Phil ________________________________________ From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of Paul Stewart [paul at paulstewart.org] Sent: 27 April 2010 19:41 To: frnkblk at iname.com; ipv6-ops at lists.cluenet.de Subject: RE: CMTS support of IPv6 Interesting.. thanks for sharing that. Today we run Cisco 7246VXR and there's internal discussions around either adding more of them or moving to Motorola. The question around IPv6 was raised but nobody pursued an answer that I know of. Speaking of, does anyone know if the 7246VXR properly supports IPv6? Best regards, Paul -----Original Message----- From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf Of Frank Bulk - iName.com Sent: April-27-10 1:32 PM To: ipv6-ops at lists.cluenet.de Subject: CMTS support of IPv6 Just got off the phone with the pre-sales tech support person for our CMTS vendor, Motorola. He shared that "no one is asking for IPv6", "none of my customers have asked about it", and plans are for full support in 2H 2011. Also shared that we will likely see CPE (by that he means CM and CM gateway) support via firmware upgrades. He says the market and therefore software and hardware development focus has been on bandwidth -- more downstream and upstream channel bonding. There's some IPv6 support in the existing code base, but he wasn't able to describe where it's lacking. I know it's missing some dynamic routing protocol support, but I haven't yet identified any other feature gaps. So anyone who has Motorola CMTS gear, I would encourage them to talk to their sales person and encourage them to make it a greater priority. Frank From tore.anderson at redpill-linpro.com Wed Apr 28 12:55:59 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 28 Apr 2010 12:55:59 +0200 Subject: IPv6 client loss measurements, now on the web Message-ID: <4BD8143F.4090407@redpill-linpro.com> Hi list, I've finally gotten around to creating a web page dedicated to the measurements I've posted about here earlier. You'll find it at . It will be automatically updated every night, and it even has graphs. I think it'll be a much better home for the information than an IPv6 mailing list archive, so this means I won't be posting monthly reports any longer. Feel free to have a look! Any feedback is of course very welcome. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From ford at isoc.org Wed Apr 28 13:13:17 2010 From: ford at isoc.org (Matthew Ford) Date: Wed, 28 Apr 2010 12:13:17 +0100 Subject: IPv6 client loss measurements, now on the web In-Reply-To: <4BD8143F.4090407@redpill-linpro.com> References: <4BD8143F.4090407@redpill-linpro.com> Message-ID: Tore, This really is excellent work, thanks! Of course there's always room for improvement ;) - one thing I'd like to see would be a version of the no-known-brokenness-historic graph *with* timeout, to get a sense of the impact of the state of the IPv6 inter-network on connectivity and latency in the absence of other bigger problems. - Mat On 28 Apr 2010, at 11:55, Tore Anderson wrote: > Hi list, > > I've finally gotten around to creating a web page dedicated to the > measurements I've posted about here earlier. You'll find it at > . It will be automatically updated every night, > and it even has graphs. > > I think it'll be a much better home for the information than an IPv6 > mailing list archive, so this means I won't be posting monthly reports > any longer. > > Feel free to have a look! Any feedback is of course very welcome. > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 From ford at isoc.org Wed Apr 28 13:38:12 2010 From: ford at isoc.org (Matthew Ford) Date: Wed, 28 Apr 2010 12:38:12 +0100 Subject: IPv6 client loss measurements, now on the web In-Reply-To: References: <4BD8143F.4090407@redpill-linpro.com> Message-ID: On 28 Apr 2010, at 12:13, Matthew Ford wrote: > Tore, > > This really is excellent work, thanks! > > Of course there's always room for improvement ;) - one thing I'd like to see would be a version of the no-known-brokenness-historic graph *with* timeout, to get a sense of the impact of the state of the IPv6 inter-network on connectivity and latency in the absence of other bigger problems. > Gah. There's certainly room for improvement in my observational skills. It's not graphed, but the numbers are there. So, client loss of 0.01% with a 10s timeout. Is that acceptable to your customers (both the loss rate and the timeout)? How does this change with, say a 5s or a 1s timeout? - Mat > - Mat > > > > On 28 Apr 2010, at 11:55, Tore Anderson wrote: > >> Hi list, >> >> I've finally gotten around to creating a web page dedicated to the >> measurements I've posted about here earlier. You'll find it at >> . It will be automatically updated every night, >> and it even has graphs. >> >> I think it'll be a much better home for the information than an IPv6 >> mailing list archive, so this means I won't be posting monthly reports >> any longer. >> >> Feel free to have a look! Any feedback is of course very welcome. >> >> Best regards, >> -- >> Tore Anderson >> Redpill Linpro AS - http://www.redpill-linpro.com/ >> Tel: +47 21 54 41 27 > From tore.anderson at redpill-linpro.com Wed Apr 28 14:51:08 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 28 Apr 2010 14:51:08 +0200 Subject: IPv6 client loss measurements, now on the web In-Reply-To: References: <4BD8143F.4090407@redpill-linpro.com> Message-ID: <4BD82F3C.8090703@redpill-linpro.com> * Matthew Ford >> This really is excellent work, thanks! I'm glad you like it! :-) >> Of course there's always room for improvement ;) - one thing I'd >> like to see would be a version of the no-known-brokenness-historic >> graph *with* timeout, to get a sense of the impact of the state of >> the IPv6 inter-network on connectivity and latency in the absence >> of other bigger problems. >> > Gah. There's certainly room for improvement in my observational > skills. It's not graphed, but the numbers are there. Actually, it's graphed too: http://fud.no/ipv6/gnuplot/no-known-brokenness-t10.png http://fud.no/ipv6/gnuplot/no-known-brokenness-t10-historic.png Same goes for the "noosx" and "nobuggyopera" variants. I just took them out of the page since I got feedback that they just made the the page too cluttered with graphs. After all, they're not graphs of real user behaviour, they're just illustrating a ?wishful thinking? scenario, so he thought the no-timeout variant made the point well enough and that the timeout one was therefore redundant. But I'll put them back in as text links instead, hopefully that'll satisfy you both. :-) Better now? > So, client loss of 0.01% with a 10s timeout. Is that acceptable to > your customers (both the loss rate and the timeout)? How does this > change with, say a 5s or a 1s timeout? I think 0.01% would be acceptable, yes. I haven't given up on trying to convince them to go for it at this point either, but it certainly requires some nagging! It would take me quite a few hours to run the parsing scripts again with a modified timeout on all the logs, so I'd rather not start that right now since I'm doing some calculations on the impact of a certain 6to4-filtering end-user network here in Norway at the moment. However Steinar has also been looking into my logs to see how long the delays are, and he found that many are clustered around 75 seconds. That appears to be how long it takes Safari (possibly other Mac OS X-based browsers too?) to recover from a failed initial IPv6 connection attempt. This behaviour has been observed by others, too, see: http://www.potaroo.net/ispcol/2009-01/mtu6.html So 10s should be sufficient to weed out those false positives, at least. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From steve at ipv6canada.com Wed Apr 28 14:59:16 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Wed, 28 Apr 2010 08:59:16 -0400 Subject: IPv6 client loss measurements, now on the web In-Reply-To: <4BD8143F.4090407@redpill-linpro.com> References: <4BD8143F.4090407@redpill-linpro.com> Message-ID: <4BD83124.6090700@ipv6canada.com> On 2010.04.28 06:55, Tore Anderson wrote: > Hi list, > > I've finally gotten around to creating a web page dedicated to the > measurements I've posted about here earlier. You'll find it at > . It will be automatically updated every night, > and it even has graphs. > > I think it'll be a much better home for the information than an IPv6 > mailing list archive, so this means I won't be posting monthly reports > any longer. Tore, This is an absolutely fantastic piece of work! Thanks for putting this up, and cheers to your clients who allowed you to use them as a test bed. Keep up the great work! Steve From tedm at ipinc.net Wed Apr 28 19:23:25 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 28 Apr 2010 10:23:25 -0700 Subject: IPv6 client loss measurements, now on the web In-Reply-To: <4BD8143F.4090407@redpill-linpro.com> References: <4BD8143F.4090407@redpill-linpro.com> Message-ID: <4BD86F0D.6010407@ipinc.net> Tore, There is one thing missing. You mentioned: "...I'd like to thank Opera Software for working with me and fixing the problem in their browser, and Fedora, Canonical, Gentoo, Novell, Mandriva, and Debian for applying my patches to glibc in their respective Linux distributions..." However there is NO mention of Apple - yet you have documented MacOSX with the "...the RFC1918/6to4 preference problem...." I cannot believe that you have IGNORED Apple Computer and NOT made any attempt to contact them about this bug. Any THINKING person who saw this site would instantly assume the same. I can only conclude that you attempted to contact Apple who in their usual "Not Invented Here" assumption that they are God's Gift to Computing, basically told you to go to hell. I would assume anyone reading this page would assume the same - in short, assume the worst. Thus, this site is a HUGE slam against Apple Computer and I'm frankly surprised that legions of Macaphiles haven't burned you at the stake yet. But seriously, I think your really doing a disservice to Mac owners. If you HAVEN'T contacted Apple then say so and I'm sure there's a few Mac owners who have their brand new Macs will take it upon themselves to contact Apple for you. If you HAVE contacted them and they have pooh-poohed this then say so also and once more I'm sure there's going to be some well-connected Mac owners who will bring pressure to bear. Or if you HAVE contacted them and they have said "we are working on a fix" then once more, Mac owners have an interest in knowing. But don't just leave us hanging by saying nothing. Mac owners will want this fixed, just like they would want any bug in MacOS fixed, the sooner the better. For them to get it done means that we need public documentation of Apples responses. Ted On 4/28/2010 3:55 AM, Tore Anderson wrote: > Hi list, > > I've finally gotten around to creating a web page dedicated to the > measurements I've posted about here earlier. You'll find it at > . It will be automatically updated every night, > and it even has graphs. > > I think it'll be a much better home for the information than an IPv6 > mailing list archive, so this means I won't be posting monthly reports > any longer. > > Feel free to have a look! Any feedback is of course very welcome. > > Best regards, From john at sackheads.org Wed Apr 28 19:29:59 2010 From: john at sackheads.org (John Payne) Date: Wed, 28 Apr 2010 13:29:59 -0400 Subject: IPv6 client loss measurements, now on the web In-Reply-To: <4BD86F0D.6010407@ipinc.net> References: <4BD8143F.4090407@redpill-linpro.com> <4BD86F0D.6010407@ipinc.net> Message-ID: On Apr 28, 2010, at 1:23 PM, Ted Mittelstaedt wrote: > > Tore, > > There is one thing missing. You mentioned: > > "...I'd like to thank Opera Software for working with me and fixing the > problem in their browser, and Fedora, Canonical, Gentoo, Novell, > Mandriva, and Debian for applying my patches to glibc in their > respective Linux distributions..." So, just before that... under the Resources section there's a: "a message to Apple regarding the OS X problems" which is a link to Tore's email to the ipv6-dev list at Apple which starts quite a thread there. > I cannot believe that you have IGNORED Apple Computer and NOT made > any attempt to contact them about this bug. Any THINKING person who > saw this site would instantly assume the same. This THINKING person actually read the site (and Tore's other emails where he mentioned this). *shrug* From tedm at ipinc.net Wed Apr 28 20:25:49 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 28 Apr 2010 11:25:49 -0700 Subject: IPv6 client loss measurements, now on the web In-Reply-To: References: <4BD8143F.4090407@redpill-linpro.com> <4BD86F0D.6010407@ipinc.net> Message-ID: <4BD87DAD.2010808@ipinc.net> That link, despite being titled "a message to Apple regarding the OS X problems" is NOT a "a message to Apple regarding the OS X problems" I'll call you attention to the following in this URL: http://www.lists.apple.com/mailman/listinfo "...These lists are NOT a replacement for formal support or bug reporting procedures. They are an informal communications tool, with no guarantee that every posting will be read by someone at Apple..." Here is the link for the actual bug reports: http://developer.apple.com/bugreporter/bugrptform.html Now, as to the thread that's linked: There is NO response from anyone identifying themselves as being from Apple. There's a post from David Sinn saying: "I've submitted a bug, we'll have to wait and see if Apple reacts" dated a month ago. No followup. No bug # or any way to check the status of the bug or if it was even submitted. Nor is it mentioned if it was submitted to the public Darwin project or to Apple proper. Darwin bugs seem to be sent to the Darwin-dev mailing list at the above URL. In an earlier post David says: "...Being in .edu space, we have predominantly public IPv4 addressed hosts..." Thus clearly David is not an Apple employee so this isn't even an "insider" taking care of this quietly, under the table. Ted On 4/28/2010 10:29 AM, John Payne wrote: > > On Apr 28, 2010, at 1:23 PM, Ted Mittelstaedt wrote: > >> >> Tore, >> >> There is one thing missing. You mentioned: >> >> "...I'd like to thank Opera Software for working with me and fixing the >> problem in their browser, and Fedora, Canonical, Gentoo, Novell, >> Mandriva, and Debian for applying my patches to glibc in their >> respective Linux distributions..." > > > So, just before that... under the Resources section there's a: > > "a message to Apple regarding the OS X problems" > > which is a link to Tore's email to the ipv6-dev list at Apple which starts quite a thread there. > >> I cannot believe that you have IGNORED Apple Computer and NOT made >> any attempt to contact them about this bug. Any THINKING person who >> saw this site would instantly assume the same. > > This THINKING person actually read the site (and Tore's other emails where he mentioned this). > > *shrug* > > From tore.anderson at redpill-linpro.com Thu Apr 29 09:13:48 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 29 Apr 2010 09:13:48 +0200 Subject: IPv6 client loss measurements, now on the web In-Reply-To: <4BD86F0D.6010407@ipinc.net> References: <4BD8143F.4090407@redpill-linpro.com> <4BD86F0D.6010407@ipinc.net> Message-ID: <4BD931AC.6060100@redpill-linpro.com> Good morning, Ted, * Ted Mittelstaedt > But seriously, I think your really doing a disservice to Mac owners. I'm sorry you interpreted the page in that way. It was certainly not meant to be. What I want to do is simply to raise awareness of the issues that exist, and hopefully convince those in a position to do something about them to actually do so. Apple is certainly one of those - I believe that a fix provided by them would benefit everyone, their own users most of all. The reason why I haven't thanked Apple in the acknowledgements section is simply because they haven't yet released any fix (or stated an intention to do so). That's also why I thank the individual Linux distributions instead of the GNU libc upstream developers, who declined to fix the issue. > If you HAVEN'T contacted Apple then say so and I'm sure there's a > few Mac owners who have their brand new Macs will take it upon > themselves to contact Apple for you. > > If you HAVE contacted them and they have pooh-poohed this then say > so also and once more I'm sure there's going to be some > well-connected Mac owners who will bring pressure to bear. > > Or if you HAVE contacted them and they have said "we are working on a > fix" then once more, Mac owners have an interest in knowing. > > But don't just leave us hanging by saying nothing. Mac owners will > want this fixed, just like they would want any bug in MacOS fixed, > the sooner the better. For them to get it done means that we need > public documentation of Apples responses. Given that one of my goals is to convince Apple to provide a fix, it would certainly be counter-productive to not actually tell them about the issue in the first place. So rest assured that I have. In addition to the posts to Apple's IPv6 list that are linked to in my page page, I have sent direct e-mails to Stuart Cheshire, Apple's representative on the IAB (at the time), and James Woodyatt, an Apple engineer who's active the on IETF IPv6 lists. I've also posted about the issues to those IETF lists. I have not submitted a bug report. I felt that would be redundant, as one of the first replies to my post to the Apple IPv6 list was from Janos Mohacsi, who stated ?[N]umber of people filled bug report, including me?. The only feedback I've received from Apple is a confirmation that my messages on the subject has been read and discussed by their engineers. This confirmation was sent to me privately, by the way, so I do not feel it would be proper to put it up on the site as ?public documentation?. I did not want to make a big deal about this on the page, as I thought that could easily be mis-interpreted as me ?slamming? Apple on lack of communication - which certainly isn't my intention. I understand that Apple's corporate culture is rather secretive, so [I hope that] the lack of communication does not necessarily mean that a fix is not forthcoming. In any case, I've added the phrase ?I've reported the issue to Apple, and have received confirmation that their engineers are aware of it? to the page now, and have also modified the link text ?a message to Apple? to ?a message to Apple's IPv6 developement list?. I hope those changes takes care of your concerns. Thank you for your feedback! Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From tedm at ipinc.net Thu Apr 29 19:32:52 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 29 Apr 2010 10:32:52 -0700 Subject: IPv6 client loss measurements, now on the web In-Reply-To: <4BD931AC.6060100@redpill-linpro.com> References: <4BD8143F.4090407@redpill-linpro.com> <4BD86F0D.6010407@ipinc.net> <4BD931AC.6060100@redpill-linpro.com> Message-ID: <4BD9C2C4.6060201@ipinc.net> On 4/29/2010 12:13 AM, Tore Anderson wrote: > Good morning, Ted, > > * Ted Mittelstaedt > >> But seriously, I think your really doing a disservice to Mac owners. > > I'm sorry you interpreted the page in that way. It was certainly not > meant to be. What I want to do is simply to raise awareness of the > issues that exist, and hopefully convince those in a position to do > something about them to actually do so. Apple is certainly one of those > - I believe that a fix provided by them would benefit everyone, their > own users most of all. > You have to understand part of my post was very tongue-in-cheek. As you know Apple's marketing department runs all of their marketing as though Apple is God's Gift to Computing and the Macophiles just eat that up, they love it. (ie: Mac vs PC adverts, etc.) Thus it is enormous fun to find a flaw like this, it's like finding and pointing out a paint flaw in a Rolls Royce. Obviously it's a serious issue. But really stupid flaws have got a lot more attention from Apple before and been fixed quite rapidly. This one is among the "for lack of a nail the war was lost" flaws and really should have been taken care of immediately. For goodness sake, as Darwin is built on FreeBSD all they needed to do was go lift the code FreeBSD used to fix this in it's distro and use that!! > The reason why I haven't thanked Apple in the acknowledgements section > is simply because they haven't yet released any fix (or stated an > intention to do so). That's also why I thank the individual Linux > distributions instead of the GNU libc upstream developers, who declined > to fix the issue. > >> If you HAVEN'T contacted Apple then say so and I'm sure there's a >> few Mac owners who have their brand new Macs will take it upon >> themselves to contact Apple for you. >> >> If you HAVE contacted them and they have pooh-poohed this then say >> so also and once more I'm sure there's going to be some >> well-connected Mac owners who will bring pressure to bear. >> >> Or if you HAVE contacted them and they have said "we are working on a >> fix" then once more, Mac owners have an interest in knowing. >> >> But don't just leave us hanging by saying nothing. Mac owners will >> want this fixed, just like they would want any bug in MacOS fixed, >> the sooner the better. For them to get it done means that we need >> public documentation of Apples responses. > > Given that one of my goals is to convince Apple to provide a fix, it > would certainly be counter-productive to not actually tell them about > the issue in the first place. So rest assured that I have. In addition > to the posts to Apple's IPv6 list that are linked to in my page > page, I have sent direct e-mails to Stuart Cheshire, Apple's > representative on the IAB (at the time), and James Woodyatt, an Apple > engineer who's active the on IETF IPv6 lists. I've also posted about > the issues to those IETF lists. > > I have not submitted a bug report. I felt that would be redundant, as > one of the first replies to my post to the Apple IPv6 list was from > Janos Mohacsi, who stated ?[N]umber of people filled bug report, > including me?. > > The only feedback I've received from Apple is a confirmation that my > messages on the subject has been read and discussed by their engineers. > This confirmation was sent to me privately, by the way, so I do not > feel it would be proper to put it up on the site as ?public documentation?. > I'd encourage you that despite your private assurances that there are bug reports on this already that have been looked at, that you go through the motions of submitting the bug through the official link, then post Apple's response to that. Either that, or email Janos and ask what the bug number is and post that number and name on your site. > I did not want to make a big deal about this on the page, as I thought > that could easily be mis-interpreted as me ?slamming? Apple on lack of > communication - which certainly isn't my intention. I understand that > Apple's corporate culture is rather secretive, so [I hope that] the lack > of communication does not necessarily mean that a fix is not forthcoming. > > In any case, I've added the phrase ?I've reported the issue to Apple, > and have received confirmation that their engineers are aware of it? to > the page now, Excellent. This makes all the difference in the world as now that this is on record, interested Mac users can refer to this site when they file their own bug reports to Apple, this prevents Apple from making the excuse that "it's the first time we've heard of this" Even better of course would be a bug assignment number from Apple that could be used as a referral. Ted From steve at ipv6canada.com Fri Apr 30 06:06:40 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Fri, 30 Apr 2010 00:06:40 -0400 Subject: Requesting feedback for a considered DNS test Message-ID: <4BDA5750.4000701@ipv6canada.com> Hi all, My first foray into global testing was great, but I really didn't have the research background behind me to understand the full ramifications of what I was doing. I'd like to try it again, immediately, but this time, instead of an inward-bound test, I'd like to do something that reaches outwards. Even though it has only been a few days, I'm one for learning, so I'm throwing it out into the community again. On my site, I had a q&d 'idea' listed, which I've subsequently re-engineered. The basics are the same, but there is a bit more detail on my initial thinking on implementation. Please let me know what you think. I'm specifically interested to know whether: - it's a waste of time - has already been done - a half wheel, already in progress The brief that I put up for a description does not come close to describing what my complete thinking is, but it is enough for you to tell me whether there is another project that you know about that I could throw my efforts at instead, or continue on... http://ipv6canada.com/?p=110 Cheers, Steve From swmike at swm.pp.se Fri Apr 30 06:34:56 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 30 Apr 2010 06:34:56 +0200 (CEST) Subject: Requesting feedback for a considered DNS test In-Reply-To: <4BDA5750.4000701@ipv6canada.com> References: <4BDA5750.4000701@ipv6canada.com> Message-ID: On Fri, 30 Apr 2010, Steve Bertrand wrote: > - has already been done Some of this has been done, -- Mikael Abrahamsson email: swmike at swm.pp.se From tore.anderson at redpill-linpro.com Fri Apr 30 09:37:27 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 30 Apr 2010 09:37:27 +0200 Subject: IPv6 client loss measurements, now on the web In-Reply-To: <4BD9C2C4.6060201@ipinc.net> References: <4BD8143F.4090407@redpill-linpro.com> <4BD86F0D.6010407@ipinc.net> <4BD931AC.6060100@redpill-linpro.com> <4BD9C2C4.6060201@ipinc.net> Message-ID: <4BDA88B7.6030008@redpill-linpro.com> Hi Ted, * Ted Mittelstaedt > I'd encourage you that despite your private assurances that there are > bug reports on this already that have been looked at, that you go > through the motions of submitting the bug through the official link, > then post Apple's response to that. I have to admit I don't share your belief that this will serve any purpose. Apple has already read my messages and arguments on the issue and why it should be fixed. If they agree with me, I'm sure they're working on the fix as we speak. If they on the other hand don't agree and don't intend to fix it, I doubt that me repeating my arguments through another channel will make them change their minds. Of course, if somebody other than me also reported having these problems, that would be different. Especially if that other person is one of their own customers, holding a valid support contract, I guess. > Either that, or email Janos and ask what the bug number is and post > that number and name on your site. He's already on this list, but I've added him to the Cc field of this message anyway now. Janos: If you'd like me to, I'd be happy to post the ID of the bug you submitted to Apple on the OSX/RFC3484 issue on my web site, if you want to share it with us. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From tore.anderson at redpill-linpro.com Fri Apr 30 09:57:05 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 30 Apr 2010 09:57:05 +0200 Subject: IPv6 client loss measurements, now on the web In-Reply-To: References: <4BD8143F.4090407@redpill-linpro.com> Message-ID: <4BDA8D51.2010007@redpill-linpro.com> * Matthew Ford > So, client loss of 0.01% with a 10s timeout. Is that acceptable to > your customers (both the loss rate and the timeout)? How does this > change with, say a 5s or a 1s timeout? Hi again, see , where I'm comparing the 10s timeout to a 5s and 20s one. There's not much difference between the three, which I take it to mean that the 10s timeout plots likely do what they're intended to well enough, without introducing too much bias. I've also updated the description of the 10s timeout variants on the page. Thanks for your suggestion! Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From steve at ipv6canada.com Fri Apr 30 10:06:35 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Fri, 30 Apr 2010 04:06:35 -0400 Subject: Requesting feedback for a considered DNS test In-Reply-To: References: <4BDA5750.4000701@ipv6canada.com> Message-ID: <4BDA8F8B.7090801@ipv6canada.com> On 2010.04.30 00:34, Mikael Abrahamsson wrote: > On Fri, 30 Apr 2010, Steve Bertrand wrote: > >> - has already been done > > Some of this has been done, Thanks Mikael, iow, I guess what I'm saying, is that I'm now fully prepared and willing to provide every resource that I have to the betterment of v6...particularly by trying to ensure that we are all connected properly. Outreach, promotion, hardware, (minuscule) bandwidth, time, whatever... If I can help, I'm here... Steve From ayourtch at gmail.com Fri Apr 30 12:01:27 2010 From: ayourtch at gmail.com (Andrew Yourtchenko) Date: Fri, 30 Apr 2010 12:01:27 +0200 Subject: Requesting feedback for a considered DNS test In-Reply-To: References: <4BDA5750.4000701@ipv6canada.com> Message-ID: On Fri, Apr 30, 2010 at 6:34 AM, Mikael Abrahamsson wrote: > On Fri, 30 Apr 2010, Steve Bertrand wrote: > >> - has already been done > > Some of this has been done, I've an alpha version of bicycle with slightly differently-shaped wheels here: http://testv6.stdio.be/ the v6-only DNS server test always succeeds so far - because I do not have one readily available yet. It's use is that you include a tag into the webpage, the server takes a few 302 redirects before finally sending the 1x1 transparent gif (if the client makes it this far). The original referer is sha1-hashed and used as a key to record where we "lost" the clients. And afterwards it can draw a nice diagram - per referer. So one can see the results tailored to their specific audience. Any comments are likewise very welcome - I made it specifically so others could test. Not sure if I would have been better off with the