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 <ekr@xxxxxxxx> 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 [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
