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

[Ivan Shmakov]

>>>>> Jeroen Massar <jeroen at unfix.org> writes:
>>>>> 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:

[…]

 >>> 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.

	ACK, thanks.

 >> 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/)

	JFTR: its “image verification” wasn't working a couple of days
	ago or so.

 > toward 2002:c058:6301:: aka the 6to4 anycast address indicate that
 > there is a local node doing 6to4.

	… From the AMiS node?  I've tried some of the 6to4 addresses
	which are known to work (as per http://lg.he.net/), but none is
	reachable from there.  Which seems to suggest that their 6to4
	router is misconfigured.

 > 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.

	It's the other way around, actually.  There're a few hosts,
	scattered geographically somewhat, with one of them having
	native IPv6 connectivity, some having only 6to4 (provided by
	entities other than their respective ISP's) configured at this
	moment, and one which has both ISP-provided 6to4 and a distant
	(HE.net's) 6in4 tunnel.

	The host I intend to connect, however, is on one of the SixXS
	(AMiS) networks, and was perfectly reachable from one of my
	hosts (via 6to4) at least as of 2011-11-13.

	There, setting up a HE.net 6in4 tunnel for each of the 6to4-only
	hosts is hardly an option (as I'm going to run out of tunnels.)
	and using 6in4 (100 ms) instead of the ISP's-provided 6to4
	router (< 60 ms) doesn't seem like an improvement.

	The problem is further complicated by that the host having both
	6to4 and 6in4 connectivity selects the 6to4 source IP address
	for communication by default when sending data to the SixXS host
	in question.  Surely, I may configure almost every application
	to use an 6in4 address explicitly, but it's somewhat a
	cumbersome solution.

-- 
FSF associate member #7257