-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, May 29, 2017 at 4:45 PM, Peter Todd <p...@petertodd.org> wrote: > On Sun, May 28, 2017 at 05:46:22AM -0700, pixel fairy wrote: >> > Are you suggesting that VM's no longer have internal ipv4 addresses? You >> > mean >> > via the ipv4-in-ipv6 address range or something else? >> >> i was thinking dual stack and nat for both 4 and 6. my first thought was >> using the v6 addresses to internally address the vms, but that seems to be >> mostly done through vchan. proxy, firewall, and network vms, would need to >> support both anyway. >> >> the only other way ive tried was nat64, and i remember hitting a problem >> with tls verification, but my setup could have been wrong. tried googling >> for "nat64 ssl" and "nat64 tls" and cant find anything on it. > > Right, with nat64 you're requiring the VM's and the software in them to use > IPv6 addresses, which get translated to IPv4. That's inevitably going to have > compatibility issues, as nat64 just isn't very common, and there's plenty of > software around that can only talk IPv4. I think a dual-stack arrangement is > much preferable to this, even if both IPv4 and IPv6 end up having to use NAT. > > It's notable how the relative rarity of IPv6 NAT may be a problem - the IPv6 > infrastructure wasn't designed with clients running multiple VM's at a time in > mind.
I'd like to mention the relative complexity of the IPv6 specification (and by extension, its implementations) as a reason against this proposed change. For example, take a look at this list of CVEs related to IPv6 [0]. Please also note that writing firewall rules for IPv6 can be quite challenging at times. Second, IPv6 was, in fact, designed with clients running multiple VMs at a time in mind -- you're just supposed to delegate v6 addresses from a /64 (or bigger) IPv6 prefix and not use a NAT mechanism. While I do accept the fact that IPv6 support is neccessary, I don't think the existing v6 network stack implementations are quite as mature as the v4 ones (which have undergone extensive testing "in production" over the last few decades) -- especially not mature enough for use in a security-oriented OS. Should you find yourself in an environment with only v6 connectivity, having IPv6 stack available **only** in the untrusted net VM will definitely come in handy, but IMO all the VMs downstream should be using v4 (either via 4in6 [1] or similar transition mechanism). Cheers, Patrik [0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ipv6 [1] https://en.wikipedia.org/wiki/4in6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZLFKpAAoJEFwecd8DH5rl+QYP/3s9SmOPrKlPcO8FKFIIAWfW +RMB4PRvj1uT2sfsuMHVJhLu0RWS0ZHo1Y2yatad10fC/r9hqq7j1WbHz6+9keMJ 9vdLV1jTbuGLaEqgDNM0DPapXNau1SA4qLbEs7EgkZKv0prBLysTLXUOMwEE9zzi T7V23fQx/un4+qiH7qmuPBgoGspyJwo7Vb0bXmrFGPNYS4Y7+YCWay4t+gI77Bcq Ynv0OkPLpf1CWO8MnYg0S4YRikxbRJr5Sk6UeJeB2RAW0fEGtirXLJ/Kc953Je+h lHBiRGGW1nOrcw8PR4ZLe8h7nhGtcCJK5PkktLO/SZPrrCXEYRvb9e4FFX/FG4iQ yILLE00LPwKGX4x2wr4G53JY6cGg9cUVX960CZzZaFp2Q5sTZiFT9BVT/jBMCCXV TCPp9O/wRyIUtJufmSWPp0UjQvUefNR2FLNg4/gH357pyqOIu0+cP3EwYL77nyIJ hbrEo9Vv5qL3NhE9oytgBJGf75OK87KGhvqgh4maUfZFOqyC+U5mTrnc7pcwapF0 1v5XZvX35uuHEj+AR+MSOrJmu1IVG3LexHbwmxGEqAQGYVav+oCZQwMb/JjuWZwC zwiCZhpsbcoQ0fF6nJAT5skNShQDPVtGytKe4R3x39VSg3ngbNQe2CWhKnlpx6W8 T7jTwz0TSEdmo0I5fqoS =WsSS -----END PGP SIGNATURE----- On Mon, May 29, 2017 at 4:45 PM, Peter Todd <p...@petertodd.org> wrote: > On Sun, May 28, 2017 at 05:46:22AM -0700, pixel fairy wrote: >> >> >> > >> > Are you suggesting that VM's no longer have internal ipv4 addresses? You >> > mean >> > via the ipv4-in-ipv6 address range or something else? >> > >> >> i was thinking dual stack and nat for both 4 and 6. my first thought was >> using the v6 addresses to internally address the vms, but that seems to be >> mostly done through vchan. proxy, firewall, and network vms, would need to >> support both anyway. >> >> the only other way ive tried was nat64, and i remember hitting a problem >> with tls verification, but my setup could have been wrong. tried googling >> for "nat64 ssl" and "nat64 tls" and cant find anything on it. > > Right, with nat64 you're requiring the VM's and the software in them to use > IPv6 addresses, which get translated to IPv4. That's inevitably going to have > compatibility issues, as nat64 just isn't very common, and there's plenty of > software around that can only talk IPv4. I think a dual-stack arrangement is > much preferable to this, even if both IPv4 and IPv6 end up having to use NAT. > > It's notable how the relative rarity of IPv6 NAT may be a problem - the IPv6 > infrastructure wasn't designed with clients running multiple VM's at a time in > mind. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > > -- > You received this message because you are subscribed to the Google Groups > "qubes-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-devel+unsubscr...@googlegroups.com. > To post to this group, send email to qubes-devel@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-devel/20170529144548.GA7082%40fedora-23-dvm. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CAFfni-GNxRRMKckOv8o2tg2%2B%2BNANY%2BV2r07bvy13fH4au_d%3DLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
