Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings

[JORDI PALET MARTINEZ <[e-mail]>]

+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 <[e-mail]> en nombre de Richard Barnes <[e-mail]>
Responder a: <[e-mail]>
Fecha: sábado, 29 de julio de 2017, 18:31
Para: Stephen Farrell <[e-mail]>
CC: "[e-mail]" <[e-mail]>, Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>
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 <[e-mail]> 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.