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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf