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 [EMAIL PROTECTED] 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 GigE206.223.119.37 2001:504:0:4::6939:1
EQUINIX-DAL UP GigE206.223.118.37 2001:504:0:5::6939:1
EQUINIX-LAX UP GigE206.223.123.37 2001:504:0:3::6939:1
EQUINIX-SJC UP 10GigE 206.223.116.37 2001:504:0:1::6939:1
LINXUP 10GigE 195.66.224.21 2001:7f8:4:0::1b1b:1
LINXUP GigE195.66.226.21 2001:7f8:4:1::1b1b:2
LoNAP UP GigE193.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 GigE194.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 GigE198.32.146.50 2001:504:a::a500:6939:1
PAIX New York PENDING
DE-CIX PENDING
NOTAPENDING
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
