This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] Have we failed as IPv6 Working Group?
- Previous message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
- Next message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Philip Homburg
pch-ripeml at u-1.phicoh.com
Tue Oct 8 20:47:37 CEST 2019
>On the other hand, switching the "default" meeting SSID to IPv6-only/NAT64 >while still providing the dual stack network as a fallback, preferably >combined with a helpdesk staffed by volunteers ready to analyze any >problems that attendees might have, strikes me as a pretty good opportunity >to raise awareness and to find problems where further work is needed. >From a host perspective, NAT64 directly on wifi is not attractive: it will require an address translation component in every host to deal with legacy applications that handle IPv4 literals. NAT64 is also not attractive from a backward compatibility point of view: IPv4-only devices and hosts that are dual stack but lack the 464XLAT component will fail. Considering those issues, why does it make sense to subject attendees of a RIPE meeting to such a network? Anybody who wants to test can do that in the current setup. Why trick other people into connecting to a network that they are unlikely to encounter anywhere else?
- Previous message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
- Next message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]