Subject: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)

From: Jeroen Massar <[email-masked]>
Date: Wed, 30 May 2007 16:03:00 +0100

[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*]

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.

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?

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.

Thank you, I sincerely hope that this matter will finally be resolved.

Greets,
 Jeroen

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 30 May 2007 18:41:50 +0100

Steve Powell wrote:
> Greetings.

Thanks for the quick response. That is always appreciated.
Some networks don't even take that decency to respond, and for the
record, those are the ones that the previous mail is targeted at, in
the hope that they at least maybe acknowledge that there is a problem
instead of letting everything go into /dev/null. Acknowledging a
problem is a first step, fixing it is of course the next and better one.

> I do not believe 6bone space has anything to do with it.

As I wrote in my message, it definitely has. 6bone space is correctly
dropped by various AS's and routers, as it is not supposed to be used
for almost a *YEAR*. As the ICMP "Packet Too Big" packets from routers
who change MTU also get dropped by that when the router is sending
this message from 6bone space, this definitely has effect.

Solution: Do not use 6bone space as you are supposed to.

> 3ffe:80a::/64 is still being used by  PAIX in Palo Alto.

It's an IX, that is L2, who cares what L3 IP's are used over it?
I would depeer those folks, as clearly they don't care about the state
of the network anyway. If they do care they will fix it up really soon
after you did that.

In a week (6/6/7) it was a year ago that you where supposed to stop
using it. If in that time you really could not arrange for a
renumbering of a transit session I seriously wonder what is wrong in
that scenario.

> In general, I had no problems reaching www.ietf.org from
> pretty much anywhere in our network. 

This is because you most likely have a lot of paths which are nicely
MTU 1500 all the way, or have something setting it to eg 1280 quite
quickly on both sides of the path.

> However, I have seen stranger stuff with IPv6.  If you could
> send me a traceroute and show me where its dieing, I can
> do some more poking around.

As traceroute uses relatively small ICMPv6 or UDP packets these come
through perfectly fine. The problem occur when you want to access as
website, eg http://www.ietf.org and the packets are larger than
actually fit through the link, thus causing pMTU discovery etc.
Even the TCP session setup works fine, but nothing else.

When traceroute fails it is 'easy' to pinpoint the problem when you
can traceroute from both sides of the pond.

If you want traceroutes from an array of networks, please see
http://www.sixxs.net/tools/traceroute/ which provides that
functionality from several ASNs.

As an additional side note, you could of course always offer the IETF
(nee Neustar) a transit service, even if it is only for your own
customers. This way you avoid the dependency on 2 other networks, the
one you connect with and use as a transit for your own network, is
notoriously known to not fix problems or even reply. But of course
their routing is "immeasurably superior"*. Note the point that you
can't measure it :)

Greets,
 Jeroen

* = http://www.he.net/colo_ipv6.html

---

From: Steve Powell <[email-masked]>
Date: Wed, 30 May 2007 17:10:48 +0000

Greetings.  I do not believe 6bone space has anything
to do with it.  3ffe:80a::/64 is still being used by 
PAIX in Palo Alto.  However, we should be filtering
6bone space.  So were only using it until all peers are
moved off of 6bone space.  Unfortunately, moving those
peers and getting rid of our remaining overlay routers
is about has hard to do as dislodging an Alabama tick.

In general, I had no problems reaching www.ietf.org from
pretty much anywhere in our network.  The one exception
was a single overlay router located at AMS-IX IPV6.  I
have a number of usual suspect bugs that I checked out, but
I could still not reach www.ietf.org.  I changed routing
policy to learn 2610:A0::/32 from AS3257, which is directly
connected to us on AMS-IX.  I still could not ping it.
However, I could ping www.ietf.org from all other locations
despite the fact the path had to go through the same router.
The scope of my policy change was global.  So the entire network
prefered that path through the Amsterdam router.  

However, I have seen stranger stuff with IPv6.  If you could
send me a traceroute and show me where its dieing, I can
do some more poking around.  If your going through that particular
overlay router, I'll just reboot tonight.  The traceroute I
see in the forwarded message appears to be going to HEAnet,
www.ietf.org.  So I would like to see what a traceroute looks
like.

[email-masked]> traceroute 2610:A0:C779:B::D1AD:35B4
traceroute6 to 2610:A0:C779:B::D1AD:35B4 (2610:a0:c779:b::d1ad:35b4) from 2001:450:2001:1000:0:670:1708:219, 30 hops max, 12 byte packets
 1  2001:450:1:2000::c (2001:450:1:2000::c)  50.432 ms  60.226 ms  50.749 ms
 2  2001:450:1:2000::c (2001:450:1:2000::c)  50.581 ms  50.368 ms  50.771 ms
 3  2001:450:1:1::29 (2001:450:1:1::29)  50.355 ms  50.593 ms  50.444 ms
 4  GBLX-v6-CHI1.cr1.ord1.us.occaid.net (2001:4830:ff:1010::3549)  64.120 ms  55.993 ms  54.963 ms
 5  ge-0-1-0.cr1.iad1.us.occaid.net (2001:4830:ff:f151::2)  111.167 ms  81.835 ms  80.415 ms
 6  unassigned.in6.twdx.net (2001:4830:e6:d::2)  84.715 ms  88.792 ms  91.223 ms
 7  stsc350a-eth3c0.va.neustar.com (2610:a0:c779::fe)  88.154 ms  85.269 ms  84.699 ms
 8  www.ietf.ORG (2610:a0:c779:b::d1ad:35b4)  97.191 ms  86.825 ms  86.173 ms

---

From: "James Jun" <[email-masked]>
Date: Wed, 30 May 2007 15:55:13 -0400

> there is a very simple explanation for this: 6bone space.

We (OCCAID) had recently turned up peering with a few networks (including HE
and others) and as a result our outbound path to HEAnet and other networks
had changed.

Some of the abrupt route changes are being corrected today evening and
hopefully should resolve pMTU problems in reaching www.ietf.org.  If you
continue to experience trouble in reaching thru OCCAID via IPv6, please
don't hesitate to drop me a line in private.

Regards,
James

---

From: [email-masked]
Date: Thu, 31 May 2007 01:20:26 +0000

> The whois.6bone.net registry is fun of course:

	one very good reason to not trust whois databases.

> Which matches what GRH has on list for it: Bill.

	Hi.

> are not supposed to use anymore?

	Sure...  there are only a few left.  Got rid of two a couple
	weeks back.  That said....

	I will announce the prefix as long as people are using it.
	(whine away)

> Thank you, I sincerely hope that this matter will finally be resolved.

	It will, but not on your arbitrary timetable.