[6bone] proposal for transfer of 6bone address management responsibilities to RIRs

[Bill Manning]

% > 	What does a faulty BGP implementation have to do with 
% > 	a prefix?
% 
% As you perfectly know, 6bone is more than address allocation. It also
% describes the network of 6bone sites connected by tunnels, with the
% general philosophy of generously allowing tunnels between any two
% 6bone sites, and exchanging full routing tables. It's symptomatic that
% the 6bone whois does not even have a syntax to describe native
% connections.

	Whois is never authoritative.  Remove 3ffe:: and we still 
	have a "network of (ipv6) sites connected by tunnels".
	your assertion of the "general philsophy" does not seem to 
	hold.   

% You could argue that this could also happen without 6bone, i.e. with
% sites having RIR allocations. However, we don't see this today, and
% it's unlikely that those operators will show the same attitude.

	Hogwash.  Route Churn is a serious problem in the v4 world
	and is/will be in the v6 world, regardless of prefix.

% The only way I see to permanently solve these problems is to have a
% core of responsible and responsive operators with sensible network
% interconnections, and apply route filters to other parties connecting
% to this core.

	That will only "work" if you reduce the network to 
	a single operator with zero interconnections and then
	you only eliminate the BGP problems. IGPs have their
	own issues w/ convergence.  Your "solution" is a red herring.

% > 	Please back your assertions.
% 
% Please ask for specific connectivity requirement that you think cannot
% be provided without 6bone in its current form.

	I would like to get native IPv6 service from 30% of the
	existing ISPs that have Los Angeles in their coverage
	footprint. Thats been a standing offer for two years.
	Have had two takers, one backhauling from Japan.
	Not what most would call production quality transit
	service. :)

	W/O 6bone (tunnels) there would be no viable v6 service
	in my region.  (this has been true since we started working
	w/ IPv6, with the 5f:: prefix, predating 6bone (3ffe::), since
	IPv6 capability was possible. 

% What is your proposal how we can move to a stable network without the
% above mentioned problems?

	Fundamentally its a social/cash issue. Persuading ISPs
	that v6 is required and backing those assertions with
	cash will allow ISPs to presure vendors to integrate
	v6 into mainstream support.  Now, with many ISPs "supporting"
	v6 on independent hardware which increases their OPEX, most can
	do this with "spare" hardware but are unable/unwilling to
	pay for the cost of independent v6 native circuits.  So
	we end up with distinct v4 and v6 hardware and the v6 is
	tunneled through the v4 circuits to other v6 endpoints.
	And with the v6 stuff on non-production hardware, it gets
	much less visability than the v4 stuff, on which their 
	cash flow depends.

	That said, perhaps the best way forward is to revise
	RFC 2770 (or what ever Robs document is) to describe
	what the existing community thinks is currently the
	set of practices which promotes stable routing in the
	v6 world, regardless of prefix.
	
	
% 
% Robert
% 


-- 
--bill