Re: Another look at 6to4 (and other IPv6 transition issues)

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

 



On Jul 16, 2011, at 4:03 PM, Ronald Bonica wrote:

> Hi John,
> 
> I think that most of the rancor around RFCs 3056 and 3068 is due to RFC 2026's very terse definition of HISTORIC. According to RFC 2026, "A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level." That's the entire definition. Anything more is read into it.
> 
> Granted, the phrase "for any other reason considered to be obsolete" is pretty subjective. In this thread, I have seen people interpret that phrase as follows:
> 
> "the IETF thinks that there are no longer any valid use cases for this technology"
> "the IETF recommends that you remove this technology from your network"
> "the IETF believes that nobody is using this technology"
> 
> I doubt if any of these interpretations are valid, because the IETF is not in a good position to evaluate what is in use or tell an operator how to run a network.  A more likely interpretation is as follows:

> "the IETF is not likely to invest effort in the technology in the future"

Such a determination seems premature.  There are some ideas floating around for protocol fixes to deal with some of the operational problems associated with 6to4.  It's too early to know whether there are significant flaws with them or whether they can get traction.  Admittedly, v4 address space exhaustion along with the introduction of LSN means that 6to4 has diminishing applicability.  But for those nets and hosts that still have access to the public IPv4 internet, it's conceivable that the reliability of 6to4 can be considerably improved.  (Though of course it will never be as good as be as a well-run native v6 service.)   At some point, some evaluation of cost vs. benefit needs to be made; and the "cost" of not fixing 6to4 needs to consider the consequences of using other tunneled transition mechanisms besides 6to4.   

Put another way:  Given that there are admittedly several operational issues associated with 6to4, there are at least four strategies that might be employed:

1. Encourage changes to the operational practices that are causing problems that are associated with 6to4.
2. Discourage all use of 6to4 in the strongest possible terms.
3. Discourage use of 6to4 except in the cases where it is believed it can work well.
4. Improve the 6to4 protocol to address some of the issues.

IMO, -advisory tries to do #1;  -historic tries to do #2; -experimental tries to do #3.  #4 is something I hope can be discussed, informally, in Quebec.  We should have a better idea after the meeting how workable this is.

Keith

_______________________________________________
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]