http://www.amis.net/ vs. 6to4

[Jeroen Massar]

On 2012-01-01 19:34 , Ivan Shmakov wrote:
>>>>>> Brian E Carpenter <brian.e.carpenter at gmail.com> writes:
>>>>>> On 2011-12-31 16:47, Ivan Shmakov wrote:
> 
> […]
> 
>  >> As the traceroutes above start to differ at the link between
>  >> 2001:15c0:ffff:d::d and 2001:15c0:ffff:7::2, I'd assume that one of
>  >> these is in charge.
> 
>  > Ivan, Read http://tools.ietf.org/html/rfc6343
> 
>  > There are many possible explanations for Anycast 6to4 failures.  Some
>  > of them are unfixable.
> 
> 	In this case, I'm quite sure that the problem is that either of
> 	the two aforementioned routers have their 2002:/16 routes set to
> 	/dev/null or the like.  Which makes me wonder if anyone there at
> 	AMiS is reading this list and is willing to help?

I've forwarded the message to folks at AMIS who are in control of the
IPv6 network.

> 	JFTR: their HTTP server at www.amis.net (2001:15c0:ffff:f::18)
> 	is also unreachable via 6to4 (from three distinct IPv4
> 	networks), but is perfectly reachable via both HE.net's 6in4
> 	tunnels, and via native IPv6 (from a single network in my reach
> 	which has one.)

A traceroute (see http://www.sixxs.net/tools/traceroute/) toward
2002:c058:6301:: aka the 6to4 anycast address indicate that there is a
local node doing 6to4.

One of the many failure modes in 6to4 is that the 6to4 host does not
accept packets from the anycast address, or has state tracking enabled
which causes the firewall to drop proto-41 from 'unknown' hosts etc.

Without access or any details at all of what the remote host is (and you
mentioned that you didn't have root or access to it before) it will be
very though to fix this issue.

Your best step though is to convince the 6to4 host to get proper
connectivity. 6to4 is great for testing but when it breaks it breaks in
way too many mysterious ways.

Greets,
 Jeroen