Re: 6to4v2 (as in ripv2)?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.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
> 

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]