APNIC IPv6 transit exchange

[Bernhard Schmidt]

Terry Manderson wrote:

> The reason that I ask for as many offers of transit for this service is 
> to pinpoint ISPs who are indeed capable of being a true IPv6 transit 
> operator. It will always be far better for them to do it than an RIR. 
> That is plainly accepted. Problem is, and I've eluded to this previously 
> - the state of transit affairs in the region, for the entire region (not 
> just our advanced friends in Japan etc) is pretty dismal given the v4 
> exhaustion predictions.

To be honest, I would just laugh at everyone who would try to evaluate 
my ability to provide decent transit service by doing measurements 
through a free two-tunnel setup with a foreign decapsulate/encapsulate 
service in the middle that might as well be on another subcontinent.

> Clearly (and some astute emails have already identified this) the v6TE 
> is a bootstrap mechanism for in-region v6. For those organisations and 
> networks who can't easily secure a relationship with an ISP for v6. Any 
> engineer worth their salt can enumerate the issues with tunnel and 
> overlay networks. Surely people can understand the life-cycle being 
> promoted here? 1) Naive network wants v6, joins v6TE. 2) network 
> engineers get experience with it, realise tunnels and non-native trunks 
> are horrible. 3) network engineers find a better transit arrangement and 
> institutionalise v6. 4) network leaves the APNIC v6TE as it provides no 
> benefit.

The (unfortunately way to often seen) alternative is 2) network 
engineers try to get their services IPv6-ready, 3) network engineers (or 
their bosses) don't get native transit because it might be 10% more 
expensive than the current lowest offer on the market, 4) users from 
well-connected ISPs complain about bad service due to IPv6 being enabled 
on their connection.

"Hey, I've never heard of IPv6, but since you have enabled it 
www.something.net doesn't work anymore!". Seen for www.ietf.org for example.

And, of course, due to the fullswap nature of v6TE I'm very much afraid 
of something like

2001:208::/32	286 1273 6830 6830 6830 6830 6939 6939 6939 6939 2516 7660 
22388 11537 7610 i
2001:410::/32	286 1273 6830 6830 6830 6830 6939 6939 6939 6939 2516 7660 
22388 11537 6509 {271,2884,7860,8111,15296,26677} i
		8767 3549 6175 17715 6435 278 18592 27750 6509 
{271,2884,7860,8111,15296,26677} i

(please have a look at the locations of the ASNs in the path to grasp 
the full problem).

This is _bound_ to happen if you continue with your original plans. And 
I guess the majority in this channel would agree that in such cases a 
fast and clean "No route to destination" would be better.

So, with the risk of repeating myself, in my opinion the only viable 
option is

a) v6TE gets _decent_ commercial-grade transit (for example from one or 
more of the players Alexander mentioned)
b) v6TE only accepts predefined prefixes from their downstreams 
(autogenerated from a routing database or by hand, I don't care, there 
should not be networks with dozens of daily changing prefixes behind 
such a service anyway). Fulltables are only accepted from upstreams.
c) Members can choose between only getting announced to other v6TE 
members (IX mode) or to the commercial transit from a) as well, for 
example with communities. I would even prefer if the default was IX-only 
and they had to enable their prefixes to get announced upstream by 
adding a specific community.

Everything else is bound to create a mess in the long term.

Regards,
Bernhard