Re: LLC Board Meeting Details - 14 May 2020

[Michael Richardson <[e-mail]>]

    fhfrediani> Perhaps one of the reasons they are not being sufficiently adopted
    fhfrediani> because of the lack examples of people and organizations using them
    fhfrediani> and the main propose is that as much as possible organizations start
    fhfrediani> to do that in the many ways possible, and IETF is an natural
    fhfrediani> one. Really do you see such an inconvenience on that ?

Eric Rescorla <[e-mail]> wrote:
    > Well, the other example besides videoconferencing that usually comes up
    > here is Github, and yes, it would be quite a large inconvenience not to
    > be able to use Github.

I'd like to moderate the discussion/decision slightly.

1) I would like to see native use of IPv6 for a service to be considered among
   the top-5 criteria for selecting one service over another.

2) The time I would make IPv4-only connectivity for a service to be a problem
   is if fails to work for an IPv6-only desktop/etc. system via NAT64.
   (use of XLAT464 not acceptable).
   I believe that is essentially identical to the criteria that Apple applies
   to their AppStore.

I use github.com from IPv6-only systems regularly via NAT64.
It works great, except for certain docker configurations, which are a problem
with Docker.  I haven't tried ietf.webex.com yet.
(I will note that webex audio appears to have stopped working this week from
the public IPv4 that my desktop has)

There are a number of places that are running publically accessible NAT64s.
I'm skeptical that these will survive as they are identical to open proxies
from a nuissance point of view.

{I would otherwise suggest that any IPv4-only service that we IETF decides we
*need* have a DC:SIIT proxy in front of it, operated by us.  But, it won't
work unless we put our AAAA into their DNS, otherwise TLS issues.}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [