On killing IPv6 transition mechanisms

[Ivan Shmakov]

>>>>> Alex Broque <broquea at he.net> writes:
>>>>> Ivan Shmakov wrote:

[...]

 >> I know the difference.  The problem is that HE.net offers just a few
 >> /64, and I need somewhat larger address space.  And they don't seem
 >> to offer reverse DNS, which is available for 6to4.

 > Just want to clarify some points. We've offered reverse DNS
 > delegation for the /64 statically routed subnet since at least 2003,
 > although it was a lot more manual configuration on our side back
 > then. Then the /48 subnets since early 2008, which ushered in a more
 > automated process for delegation for both /64 and /48 subnets. And
 > yes, those are the only subnets that the user gets delegation control
 > over.

	So, I've set up an rDNS zone for my home /64 network.  (Still
	have to submit the KSK to https://dlv.isc.org/.)

 >> Well, it seems that HE.net operates a 6to4 relay that's open for
 >> those subscribed to their 6in4 service.

 > These are actually publicly available relays, and not limited to our
 > tunnelbroker.net users. Those users obviously would be using static
 > tunnels from that service, not tunnels based on the 6to4 well known
 > anycasted ranges.

	BTW, I've checked it and it indeed works for those IPv4
	addresses that weren't configured as tunnel endpoints on
	tunnelbroker.net.  Most probably I was bitten by some other
	issue while trying to configure it earlier.  (Perhaps it has
	something to do with the fact that while I'm sending packets to
	a unicast IPv4, I still get replies from an anycast address.)

	For now, I have set up ::/0 routes over both 6to4 and 6in4
	tunnels, so that a few hosts that were previosly unavailable
	(like packages.debian.org and tools.ietf.org) now work.

-- 
FSF associate member #7257
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100321/0b23d322/attachment.sig>