current 6to4 state

[Brian E Carpenter]

On 12/11/2012 08:21, Eric Vyncke (evyncke) wrote:
> Indeed, running a BitTorrent client exhibits a lot of Teredo and 6to4 peers BECAUSE on BitTorrent the peer is identified by its IPv* address and not by a DNS, so, for each peer there is only one address and source address selection is not used (there is no choice but using this IPv* address); hence, Teredo and 6to4 can be used and are used indeed.
> 
> Web servers are accessed by FQDN and in the case of A and AAAA records, source address selection is used and will NEVER (IMHO) use 6to4 or Teredo, hence, content owner (such as Steinar's employer) do not see 6to4 anymore which is a Good Thing of course

That will depend on the age of the stack and whether the user has been
messing with netsh interface ipv6 6to4 or equivalent.

   Brian

> -éric
> 
>> -----Original Message-----
>> From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de [mailto:ipv6-ops-
>> bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf Of Ivan Shmakov
>> Sent: lundi 12 novembre 2012 06:49
>> To: ipv6-ops at lists.cluenet.de
>> Subject: current 6to4 state
>>
>>>>>>> Steinar H Gunderson <sesse at google.com> writes:
>>>>>>> 2012/11/10 Ivan Shmakov <oneingray at gmail.com>:
>>  >> Which makes me wonder on what are the costs of operating one's own  >>
>> “IPv6-to-6to4” relay?  As it seems, the “no valid route to  >> 192.88.99.1”
>> case is much easier to troubleshoot that the converse  >> “no valid route to
>> 2002::/16” one, so the latter may indeed deserve  >> some extra care.
>>
>>  > It's simple; if you wish, you can add a 6to4 decapsulation on every  >
>> server if you wish.
>>
>> 	Well, my question was about 6to4 /encapsulation/, actually.
>>
>> 	AIUI, there's likely to be just a single 6to4 relay
>> 	decapsulating the packets sent from 6to4 hosts to the IPv6 nodes
>> 	proper.  However, there'll be a lot of such relays on the
>> 	reverse direction, and thus it's the broken /encapsulating/
>> 	relay case that'd likely be much harder to troubleshoot.
>>
>>  > I've done it a few times, with a marked increase in reliability to  >
>> 6to4-using hosts.  (Nowadays it's quite irrelevant, though, since  > 6to4 is
>> all but extinct.)
>>
>> 	My numbers are hardly representative (and are rather a
>> 	back-of-the-envelope calculation), but while operating a
>> 	BitTorrent DHT6 node for a short time, I've observed that 6to4
>> 	constitutes over 90% of all /48 prefixes seen, being responsive
>> 	for 36% of all messages seen by the node.  The latter number, if
>> 	any, should be more representative of the present 6to4
>> 	deployment, due to the possibility of 6to4 nodes using a dynamic
>> 	IPv4 address, and thus more than one IPv6 /48 prefix, and also
>> 	because /48 may prove itself a bit coarse for the native IPv6
>> 	case.
>>
>> --
>> FSF associate member #7257
>