Hi Tore, > Over the years operational experience has revealed that the 6to4 > protocol suffers from so severe operational problems that it simply > cannot be fixed. Therefore, the IETF recently decided to deprecate 6to4: > > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic > > The document is approved for publication by the IESG and is just > awaiting the finishing editorial touches by the RFC Editor. > > The important stuff is in section 5: > > It is NOT RECOMMENDED to include the anycast 6to4 transition > mechanism in new implementations. If included in any > implementations, the anycast 6to4 mechanism MUST be disabled by > default. > > In host implementations, unicast 6to4 MUST also be disabled by > default. All hosts using 6to4 MUST support the IPv6 address > selection policy described in [RFC6724]. > > In router implementations, 6to4 MUST be disabled by default. In > particular, enabling IPv6 forwarding on a device MUST NOT > automatically enable 6to4. > > ConnMan does currently automatically enable 6to4, so will violate this > new requirement. I'm thinking that the easiest way to deal with that is > to simply rip out the 6to4 code completely, since the operational > problems with 6to4 (see RFC 6343) makes it such that the end users are > far better off by staying IPv4-only than "dual-stacked" with 6to4. But I > thought I'd ask before sending such a patch. The alternative would be > to keep the code, but disable it by default. Any thoughts?
I would initially hide it behind a main.conf option, but have it defaulting to disable to comply with this updated RFC once it has been accepted. However with 6to4, I actually do not know how many users are actually depending on our support of 6to4. Others that have used this feature, might want to comment here. Regards Marcel _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
