ietf
[Top] [All Lists]

Re: 6to4v2 (as in ripv2)?

2011-07-26 17:50:21
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(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com]
Sent: Monday, July 25, 2011 11:09 PM
To: Ronald Bonica
Cc: ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf