Correction, 3ffe:80a::/64 was the old PAIX Palo Alto exchange address. BTW, Jeroen does have a valid beef, ipv6@he.net used to not be handled by our normal engineering staff. It was somebody's part time side project. This has changed with the migration of our IPv6 network into our core. Since IPv6 is available via all core routers for customers on the same links as their IPv4 connection, all Hurricane network engineers are now required to be able take care of issues with it. On Wed, 30 May 2007, Mike Leber wrote:
On Wed, 30 May 2007, Jeroen Massar wrote:
[let me whine again about this one more time... *sigh*] [guilty parties in cc + public ml's so that every body sees again that this is being sent to you so that you can't deny it... *sigh again*]
Actually appreciated, as the only sessions with 3ffe link addresses (less than you can count on one hand) are with networks that haven't responded to previous emails from us to renumber, and hopefully now something will be done. It will all get sorted out anyway as we've recently completed a network wide core router upgrade and moved IPv6 into our core, and IPv6 BGP sessions over tunnels are deprecated and being replaced with native sessions. (BTW for observers, he isn't talking about 3ffe prefix announcements, he is talking about a left over 3ffe::/127 address used on a link.)
BTW, here is our IPv6 peering information for anybody with a IPv6 BGP tunnel with us, we would be happy to migrate you to native sessions (send email to peering@he.net to get sessions setup):
NAP Status Speed IPv4 IPv6 --------------- ------- ------- -------------- ------------------------ EQUINIX-ASH UP 10GigE 206.223.115.37 2001:504:0:2::6939:1 EQUINIX-CHI UP GigE 206.223.119.37 2001:504:0:4::6939:1 EQUINIX-DAL UP GigE 206.223.118.37 2001:504:0:5::6939:1 EQUINIX-LAX UP GigE 206.223.123.37 2001:504:0:3::6939:1 EQUINIX-SJC UP 10GigE 206.223.116.37 2001:504:0:1::6939:1 LINX UP 10GigE 195.66.224.21 2001:7f8:4:0::1b1b:1 LINX UP GigE 195.66.226.21 2001:7f8:4:1::1b1b:2 LoNAP UP GigE 193.203.5.128 2001:7f8:17::1b1b:1 AMS-IX UP 10GigE 195.69.145.150 2001:7f8:1::a500:6939:1 NL-IX UP GigE 194.153.154.14 2001:7f8:13::a500:6939:1 PAIX Palo Alto UP 10GigE 198.32.176.20 2001:504:d::10 NYIIX UP 10GigE 198.32.160.61 2001:504:1::a500:6939:1 LAIIX UP GigE 198.32.146.50 2001:504:a::a500:6939:1 PAIX New York PENDING DE-CIX PENDING NOTA PENDING SIX PENDING
Iljitsch van Beijnum wrote:
On 30-mei-2007, at 13:23, Nathan Ward wrote:
I can't seem to reach www.ietf.org over IPv6 these days and I have to wait 10 seconds before I fall back to IPv4.
[..]
I think what's going on is that packets from www.ietf.org don't make it back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and TCP sessions don't connect so it's not a PMTUD problem. So it's an actual timeout.
I also just started noticing this, that is, that it does not work. And there is a very simple explanation for this: 6bone space.
As a lot of people might recall, the 6bone was shutdown on 6/6/6. Still there are folks who are definitely not running anything operational or who care at all about the state of their network, if they did they would not be using it now would they?
As this is what I found on the way from $US -> $IE
7 2001:470:0:1f::2 112.131 ms 108.949 ms 108.316 ms 8 2001:470:0:9::2 109.864 ms 112.767 ms 111.586 ms 9 3ffe:80a::c 111.118 ms 86.010 ms 86.648 ms 10 2001:450:2001:1000:0:670:1708:1225 193.914 ms 194.640 ms 194.976 ms
And what do we see: 6bone space and still in use.
As a lot of places correctly filter it out, the PMTU's get dropped, as they are supposed to be dropped.
Just the same as you would expect to see if somebody was using 10.0.0.0/8 address space for a link. Similarly discouraged, though done on occasion.
The whois.6bone.net registry is fun of course:
inet6num: 3FFE:800::/24 netname: ISI-LAP descr: Harry Try IPv6 country: CA
Fortunately it still also has:
ipv6-site: ISI-LAP origin: AS4554 descr: LAP-EXCHANGE Los Angeles country: US
Which matches what GRH has on list for it: Bill.
Now I have a very very very simple question:
Can you folks finally, a year after the 6bone was supposed to be completely gone, renumber from out that 6bone address space that you are not supposed to use anymore?
That most likely will resolve the issues that a lot of people are seeing. Or should there be another 6/6/7 date which states that de-peering networks which are still announcing/forwarding 6bone space should become into effect?
Would you similarly disconnect a nonresponsive customer because they used a /30 from RFC1918 space on a point to point link with you?
BTW, I do agree that the links involved should be renumbered immediately.
Considering we are in the business of providing connectivity, the thought of tearing down the session as opposed to gracefully getting rid of them didn't cross our mind.
Of course, Neustar, who are hosting www.ietf.org, might also want to look for a couple of extra transit providers who can provide them with real connectivity to the rest of the world.
That won't renumber Bill Manning's links if that is the problem you are trying to fix.
If somebody helps Bill with his IPv6 config, please remove the 3ffe prefix announcement as it is still there, we just happen to be filtering it.
Mike.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
+----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+