• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None

      AS A user with only IPv6 connectivity
      I WANT to be able to use MusicBrainz just as well as a user who only has IPv4 connectivity


      Worth having a think about what would be needed to make this happen.

      DNS

      • Do our DNS zones support AAAA records?
      • Are our NS's reachable by IPv6?
        • everydns isn't
        • ns1.digitalwest.net isn't
        • ns2.digitalwest.net is
      • Are all the other dependent DNS servers reachable by IPv6?
      • Also check CNAMEs pointing to external domains: their NSs, their dependent NSs, the name itself, ...

      Hosting

      • DW servers (or at least, user endpoints) need IPv6 addresses
        • todo
      • Non-DW user endpoints (OSL@OSU, hefty, ...?) need IPv6 addresses
        • ftp.musicbrainz.org => musicbrainz.osuosl.org => ftp.osuosl.org => no AAAA
        • rsync.musicbrainz.org => rsync.osuosl.org => no AAAA

      Infrastructure

      • carl/lenny nginx. Does it "just work"?
      • carl/lenny incoming connections SMTP (etc)
      • Does webalizer support IPv6?

      Software

      • Is mb_server limited to IPv4 only?
      • How would mb_server per-IP rate limiting work?
      • Client apps (Picard etc), as long as they use IPv4/6-agnostic code, it should hopefully "just work".

          [MBH-77] IPv6 Support

          Zas added a comment -

          No progress, but i'll start on this soon, at least for underlying infrastructure.

           

          We can start to:

          • add IPv6 AAAA to DNS (almost none set)
          • ensure IP stacks on nodes are set for IPv6
          • ensure firewalls are properly set for IPv6

          But many MeB apps aren't IPv6 ready yet, a full audit is needed.

          Zas added a comment - No progress, but i'll start on this soon, at least for underlying infrastructure.   We can start to: add IPv6 AAAA to DNS (almost none set) ensure IP stacks on nodes are set for IPv6 ensure firewalls are properly set for IPv6 But many MeB apps aren't IPv6 ready yet, a full audit is needed.

          This ticket is very old.... but still MB is not available for IPv6. It is now fully on Hetzner's infrastructure, which is 100% IPv6 ready. Any progress?

          Michel Vorenhout added a comment - This ticket is very old.... but still MB is not available for IPv6. It is now fully on Hetzner's infrastructure, which is 100% IPv6 ready. Any progress?

          Dave Evans added a comment -

          Will Orton @ DW writes:
          "

          So here's DWNI's status:
          Our backbone is dual-stack with native v6 on 3 of our 4 paid transit upstreams and many peers (I refuse to do any tunnels for v6 in our backbone)

          Our DNS servers ns1/2/3.digitalwest.net are completely v6-enabled (AAAA glue in GTLDs and able to answer queries and make queries over v6). We use 4 physical servers spread over 3 locations. (note you're only using ns1/2 right now, let us know if you want to add ns3 for more redundancy).

          We can support serving AAAA and v6 PTR records (meaning our internal NOC tool for managing DNS supports those record types)

          We have ipv6 enabled resolvers for colo clients to use (2001:48c0:0:1::1 and ::2)

          We have started doing native/dual-stack v6 on Ethernet handoffs in colo. Generally we assign a colo handoff a /64, then if you want more we'll allocate you a a /48 and route it over the /64 to a specific host or router. So far what we do is have our router do RA's on the colo handoff while also having a static v6 for the gateway (usually the /64's subnet ::1). Then you can use static or automatic addressing for your hosts and choose between setting a static default route towards us or use the RAs to automatically set a default route via the link-local address. We've had good success with both linux and windows server customers so far.

          Let me know if you'd like a /64 turned on for your handoff!

          "

          Dave Evans added a comment - Will Orton @ DW writes: " So here's DWNI's status: Our backbone is dual-stack with native v6 on 3 of our 4 paid transit upstreams and many peers (I refuse to do any tunnels for v6 in our backbone) Our DNS servers ns1/2/3.digitalwest.net are completely v6-enabled (AAAA glue in GTLDs and able to answer queries and make queries over v6). We use 4 physical servers spread over 3 locations. (note you're only using ns1/2 right now, let us know if you want to add ns3 for more redundancy). We can support serving AAAA and v6 PTR records (meaning our internal NOC tool for managing DNS supports those record types) We have ipv6 enabled resolvers for colo clients to use (2001:48c0:0:1::1 and ::2) We have started doing native/dual-stack v6 on Ethernet handoffs in colo. Generally we assign a colo handoff a /64, then if you want more we'll allocate you a a /48 and route it over the /64 to a specific host or router. So far what we do is have our router do RA's on the colo handoff while also having a static v6 for the gateway (usually the /64's subnet ::1). Then you can use static or automatic addressing for your hosts and choose between setting a static default route towards us or use the RAs to automatically set a default route via the link-local address. We've had good success with both linux and windows server customers so far. Let me know if you'd like a /64 turned on for your handoff! "

            Unassigned Unassigned
            djce Dave Evans
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:

                Version Package