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
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf