Re: Automatic tunnels

[itojun@iijlab.net]

>I guess we agree that the main priority for ISP ought to be, "provide
>native IPv6 services". The question then is what should an ISP do when
>it wishes to provide IPv6 but is not quite ready. I would expect the ISP
>design team to tell us more about the constraints and the
>practicalities, but there are clearly three possibilities: do nothing,
>provide support for automatic tunneling, or provide configured tunnels.
>The support for automatic tunneling is simple: just provide a
>6to4-to-native service and advertise a route to 192.88.99.1; to avoid
>abuse, make sure that 192.88.99.1 is only reachable by subscribers of
>this ISP. The support for configured tunnels is somewhat more complex:
>if the ISP really want to provide additional benefits compare to
>automatic tunnels, it needs to do some form of customer management to
>ensure that customers get stable prefixes, that they use the tunnel end
>point closest to home, etc. Frankly, I don't know whether the additional
>complexity is worth the cost.

	for native-to-6to4, there's no way to protect from abuse (since
	2002::/16 has to be advertised, more-specific route is not permitted).
	how do you address the problem? (pekka's draft outlines the problem
	very well)

	seriously, with ISP hat on, we have been talking about putting 6to4
	relay router in our backbone, but we end up rejecting it due to the
	possibility of abuse, and the impact of abuse (and the lack of human
	resource to monitor/track down the source of abuse).  i'm very
	pessimistic about 6to4 relay router deployment.

itojun