Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

[Brian E Carpenter <[e-mail]>]

Oops... silly mistake below:

On 2011-04-22 13:23, Brian E Carpenter wrote:
> On 2011-04-20 21:36, Nick Hilliard wrote:
> ...
> 
>>>> I suggest that if Ole feels that a formal end-date for removal of
>>>> 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we
>>>> create a very small new ID which explicitly states a date on which IANA
>>>> formally deregisters both prefixes and requests that operators filter
>>>> them from the DFZ.  It's not a biggie, but if it's what's needed to get
>>>> vendors to ditch support, then let's just be pragmatic and do it.
> 
>>> It would be a biggie and I would oppose it very strongly. This would
>>> break deployed systems and we should never, ever do that.
> 
> 
>> Alas, despite notable voices of opposition, I suspect that consensus can
>> be formed in IETF around the swift and merciless breaking of all the
>> deployed and otherwise working 6to4 systems in exchange for facilitating
>> the rollout of more commercially viable IPv6 services.
> 
> I think you will be surprised. However, I realised that we are arguing
> about very little. From the very beginning of 6to4, it has been stated
> that great care is needed in scoping announcements of 2002::/16 (i.e. the
> route to a return relay). In fact, this in effect an anycast prefix.
> I quote from RFC 3056:
> 
>    It is a matter of routing policy how
>    far this routing advertisement of 2002::/16 is propagated in the
>    native IPv6 routing system.  Since there will in general be multiple
>    relay routers advertising it, network operators will require to
>    filter it in a managed way.  Incorrect policy in this area will lead
>    to potential unreachability or to perverse traffic patterns.
> 
> In other words, it has always been the case that 2002::/16 should not
> be propagated blindly across the DFZ and should be filtered accordingly.
> Nothing new here.
> 
> As far as a route to 192.88.99.1 goes, the same applies - as for
> any anycast address, it should not be propagated blindly outside the
> scope of its intended users. Anyone injecting it into the DFZ is
> asking for trouble.
> 
> I hope that the guidance in -historic already makes this clear.

s/-historic/-advisory/

> 
>      Brian
> 
> 
> 
> 
>> I plan to submit a draft soon that specifies a formal phaseout plan for
>> 6to4, and we shall see how much opposition is really out there.  If
>> consensus can emerge in IETF around a formal phaseout plan, then we will
>> all save a lot of time and energy that we would otherwise spend
>> maintaining and improving support for 6to4 in forthcoming host and
>> router equipment regardless of whether I-D.ietf-v6ops-6to4-to-historic
>> is published in the RFC series or not.
>