+1 Exactly: despite how much I’m pro-IPv6 and not suspicious of being against it, and I agree we should try our own dogfood, I fully agree we MUST not force all the IETF participants to try it, as we aren’t the Debugging Task Force, unless we change our principles and clearly state that the IETF network must be considered experimental and in equal conditions for ANYONE willing to experiment on it, despite breaking anything for the rest. Furthermore: 1) Even if we discover 100 of apps that get broken because the “IPv6-only” network, are we the Internet police or do we have a way to tell those apps developers to do it right? 2) If that’s the case, WHO is going to take the work for notifying the vendors/developers of those apps and making sure that they actually solve the problems? 3) We have a major problem here. We don’t have a real definition of what it means IPv6-only. If we believe that the world will run IPv6-only in the near 3-5 years, we are probably wrong, because we don’t have the power to make it happen. I agree we are turning into an IPv6-only access networks world, but we will keep LANs with dual-stack (with private IPv4 addresses and some transition mechanism in the access router) until 80% of the app developers are done and we can then start considering getting rid-off IPv4 at 100%. If anyone is interesting in contributing to clarifying the concept of IPv6-only, please, comment in v6ops (pvt is ok too) about: https://datatracker.ietf.org/doc/draft-palet-ietf-v6ops-ipv6-only/ Regards, Jordi -----Mensaje original----- De: ietf <ietf-bounces@xxxxxxxx> en nombre de Richard Barnes <rlb@xxxxxx> Responder a: <rlb@xxxxxx> Fecha: sábado, 29 de julio de 2017, 18:31 Para: Stephen Farrell <stephen.farrell@xxxxxxxxx> CC: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@xxxxxxxx" <draft-jjmb-v6ops-ietf-ipv6-only-incremental@xxxxxxxx>, Paul Hoffman <paul.hoffman@xxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx> Asunto: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings This is not the Internet Debugging Task Force. People come to IETF meetings to get work done, not to debug operational issues. Of course people should be doing research on operational impacts of the protocols being developed, bringing the results of that research to the relevant WGs, and adapting protocols to deal with them. The TLS 1.3 work has gone through this cycle several times. However, just like the TLS 1.3 experimentation was not done on production servers that were meant for doing actual work, neither is the IETF network the right place to be discovering protocol issues. If people want to opt in, fine, but let's not make it the default. On Sat, Jul 29, 2017 at 11:51 AM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: On 29/07/17 16:19, Ted Lemon wrote: > The IETF is in the business of designing new networking protocols. If we > are so allergic to dogfood that we can't even tolerate it for a week at a > time three times a year, when there is an easy way to opt out, I think we > ought to just stop spending millions of tons of carbon every year flying to > these stupid meetings and go grow turnips or something. - I quite like the occasional turnip, but hate the idea of having to grow the feckers:-) - I'm also fine with dogfood, e.g the DPRIVE test last time worked just fine for me - even though I had to switch DNS stuff about when switching from ietf-hotel to gsm, I was ok with that as it was an opt-in and I'd opted-in. - I don't like the sound of the query logging in section 3.1 of the draft, but am confident that the NOC folks wouldn't do something bad there. It'd still be good to see that properly described before any switch over, esp if as a default, as I guess the draft is really aimed at a bigger audience who may not be as clueful about privacy as our NOC team. - I have no clue if Ubuntu supports this now - section 4.2 of the draft doesn't fill me with confidence, and I'm puzzled as to how the draft figures ssh will continue to work "without incident" given known_hosts has v4 addresses. And opting-in here will change the state of known_hosts I guess in a way that might in principle lead to attacks (that said I've not checked what ssh clients know about dns64/nat64). The above "corner cases", (not that I agree they are:-), the DNSSEC stuff already mentioned together and Randy's figures imply to me that this isn't yet ready to be a default, and ought remain an opt-in. I might try it out next time though. One other note: if there were a perceived benefit for the folks opting-in that'd help your cause I think. "You can help us all make this better" is not a sufficiently direct benefit to attract that many dogfood eaters IMO. Cheers, S. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.