Alex, Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it?
If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? Of course, if implementors choose to drop the code you might not be able to upgrade software versions - but hopefully by that time you will have native IPv6 service anyway. Regards Brian Carpenter On 2011-07-27 03:37, Alexandru Petrescu wrote: > 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.carpen...@gmail.com] >>> Sent: Monday, July 25, 2011 11:09 PM >>> To: Ronald Bonica >>> Cc: ietf@ietf.org >>> 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@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf >>>>> >>>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
