Re: 6to4v2 (as in ripv2)? (was: draft-ietf-v6ops-6to4-to-historic (yet again))

[Alexandru Petrescu <alexandru.petrescu@xxxxxxxxx>]

I jump in the midle of discussion and lazy to dissect emails:

Is there a replacement for historic 6to4?  What should I now install in 
the lab, without interaction to some admin or web page of some core server?

Thanks,

Alex


Le 26/07/2011 15:47, Ronald Bonica a écrit :
> Brian,
>
> Does the following text work for you?
>
>                           Ron
>
>
> N. Meaning of HISTORIC
>
> For the purposes of this document, the term HISTORIC means:
>
> - 6-to-4 should not be configured by default on any implementation (host, cpe router, other)
>
> - Vendors will decide which future versions of their products will support 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) they are no longer economically incented to do so and b) they are economically incented to remove unused features from their products.
>
> - Operators will decide when to decommission 6-to-4 relays, if ever. It is assumed that operators will continue to operate 6-to-4 relays as long as they are economically incented to do so. When 6-to-4 traffic levels reach zero, operators will probably begin to consider decommissioning.
>
> The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time.
>
>
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:brian.e.carpenter@xxxxxxxxx]
> > Sent: Monday, July 25, 2011 11:09 PM
> > To: Ronald Bonica
> > Cc: ietf@xxxxxxxx
> > Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
> >
> > To be clear, I'd like to see exact proposed text before expressing
> > support for the proposal. The trick is to get 6to4 disabled by default
> > at the user end, without disabling it for users who are getting good
> > service from it.
> >
> > Regards
> >     Brian
> >
> > On 2011-07-26 09:49, Brian E Carpenter wrote:
> > > >   Likewise, operators will decide whether/when 6-to-4 relays will be
> > removed from their networks.
> > > This is, of course, an undeniable statement of fact (as it is for any
> > other feature
> > > of the Internet). However, it needs to be made clear that doing so
> > *prematurely*
> > > would penalise existing successful users of those relays, and
> > therefore it should
> > > only be done when there is no successful traffic through them. Which
> > is when any
> > > operator would remove them anyway.
> > >
> > > Therefore, I don't see much value in this statement, and possible
> > harm to users.
> > > The ways to avoid such harm as far as possible are already in the RFC
> > Editor
> > > queue.
> > >
> > > Regards
> > >     Brian Carpenter
> > >
> > > On 2011-07-26 02:30, Ronald Bonica wrote:
> > > > Folks,
> > > >
> > > > After some discussion, the IESG is attempting to determine whether
> > there is IETF consensus to do the following:
> > > > - add a new section to draft-ietf-v6ops-6to4-to-historic
> > > > - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> > > >
> > > > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
> > and convert their status to HISTORIC. It will also contain a new
> > section describing what it means for RFCs 3056 and 3068 to be
> > classified as HISTORIC. The new section will say that:
> > > > - 6-to-4 should not be configured by default on any implementation
> > (hosts, cpe routers, other)
> > > > - vendors will decide whether/when 6-to-4 will be removed from
> > implementations. Likewise, operators will decide whether/when 6-to-4
> > relays will be removed from their networks. The status of RFCs 3056 and
> > 3068 should not be interpreted as a recommendation to remove 6-to-4 at
> > any particular time.
> > > > draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
> > clarifies the meaning of "HISTORIC" in this particular case, it does
> > not set a precedent for any future case.
> > > > Please post your views on this course of action by August 8, 2011.
> > Ron Bonica
> > > >
> > <speaking as OPS Area AD>
> > > > _______________________________________________
> > > > Ietf mailing list
> > > > Ietf@xxxxxxxx
> > > > https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf