I suggest you ...

Give users IPv6 /64 blocks when you roll out IPv6

As you guys are testing IPv6 in the Singapore region, I highly recommend you give users a /64 each when IPv6 rolls out. This is proper practice, and gives users more flexibility in terms of address selection.

302 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    D. StroutD. Strout shared this idea  ·   ·  Admin →
    Christian KratzerChristian Kratzer shared a merged idea: Add at least optional routed IPv6 /64 per Droplet  ·   · 

    29 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Christian KratzerChristian Kratzer commented  · 

        Yes please implement at least a routed per Droplet /64 network.

        The current setup is useless for me.

        I do not want to run anything in a shared /64 network. Google is already blocking connects from the respective networks and you are blocking mail related ports....

      • Christian KratzerChristian Kratzer commented  · 

        The current ipv6 networking setup with a /124 network per droplet is rather crippled and forces lots of customers into a shared /64.

        Please implement at least an optional /64 IPv6 per droplet.

        Having per customer ipv6 addresse space for free use between Droplets would be even greater but dedicated /64 per Droplets would help a lot.

        This would also permit you to lift your mail related port blocks for the dedicated /64.

        The current shared /64 with /124 setup and the associted filters are a show stopper for my current project of moving my company's mail infrastructure from dedicated KVM hosts on our own hardware to DO.

      • Zachary DuBoisZachary DuBois commented  · 

        It seems like it would be fairly easy for DO to implement this. All it would take is a migration for users with the current setup and then a simple script to update the network interfaces (just like the one they did for old droplets with no floating IPs).

      • HLFHHLFH commented  · 

        We need a IPv6/48 block. Happily if I find better. I'll switch...

      • Zachary DuBoisZachary DuBois commented  · 

        I mean, I was sent here when I was asking why SMTP ports a filtered. Initially, a /64 should be given out because it is true most blacklists block /64's. I am out of votes but I would throw as many as I could here because these are the reasons IPv6 is having such a slow adoption. You have to pay attention to what every one is doing so you can implement it in a non-restriction way.

      • Anonymous commented  · 

        Hello,

        I suggest one /64 per droplet aggregated to one /56 per account and DC.

        Best regards,
        Frank

      • Anonymous commented  · 

        The rollout of IPv6 seems to show a rather high level of technical misunderstanding and possibly incompetence at many levels of DO's engineering team. Thinking you clearly know better than the IETF and authors of IPv6 specs is kind of hilarious.

      • Martin KomonMartin Komon commented  · 

        Upvoting this suggestion. A /64 per droplet is absolute minimum, a /56 to /48 per customer per DC is a reasonable option allowing enough space and flexibility.

      • Melissa PilgrimMelissa Pilgrim commented  · 

        That needs to be a /64 per droplet. You can allocate a /56 or larger per customer per DC if you like, so customers with more than one droplet at a given location will get adjacent /64's. Keep in mind that ARIN, RIPE, and APNIC all expect you to allocate a /56 or larger per customer, and your upstream allocations were based on that. You paid for the allocation, we cover those fees with our droplets, so you are effectively not giving us something for which we're paying.

        Moisey, to address your concern, yes, those of us who harken back to the bad old days of pre-NAT IPv4 and classful routing remember the wasted addresses. But IPv6 was specifically made so large waste is completely a non-issue. The address space is so large we get statements like "can address half the atoms in the planet". Follow RFC, hand out a /64 per droplet, allocate a /56 per DC per customer. You will not make even the slightest dent in the available address space: as wasteful as that seems, you will still need 16.7 MILLION DC-customer tuples to exhaust a single /32.

      • Justin CormackJustin Cormack commented  · 

        The current setup is basically unusable, so I have stopped using DO until you give out a /64 per host.

        A /48 per account would be nice, that is what my home ISP does.

      • Phillip SmithPhillip Smith commented  · 

        Assuming each DC has a /32 assigned to it, that's 4,294,967,296 /64 subnets. More than enough, and I'm sure they could get extra assignments even if it's not.

        I don't think assigning a /64 per account would be very smart.

      • BenBen commented  · 

        Perhaps the best option would be to give the *user account* a /64 per Data Center used by the account, rather than a /64 per droplet. This avoids the problem with smaller-than-/64 networks, without the large usage of /64s for users who have lots of droplets.

      • MickeyMickey commented  · 

        I've been using a ipv6 tunnel service through he.net They offer /48's and /64's with your own dns, its highly flexable, I don't encounter any issues - tunnel servers are a few miliseconds away from DO datacenters, My ipv6 ping over home tunnel is lower even with the extra hops. Moving servers? just point the endpoint to the new ipv4 and there no issue!

      • Anders BerghAnders Bergh commented  · 

        16 addresses is by far too few addresses... IPv6 allocations are not counted in addresses but subnets. And the smallest IPv6 subnet is a /64. Thinking in terms of number of addresses with IPv6 is wrong.

      • Mike GabrielMike Gabriel commented  · 

        Having the OPenVPN server-ip <ip>/112 issue, as well.

        Real /64 bit networks is a must IMHO.

      • Kristian HermansenKristian Hermansen commented  · 

        Google is also blocking DigitalOcean customers because we are not assigned a proper /64 range of host bits. This means if a neighbor on the DO network is running a bot, your IPv6 is being flagged as well. As such, users are impacted right now and unable to rely on IPv6 services. DigitalOcean is effectively violating the RFC.

      • BenBen commented  · 

        The big problem with the current practice of giving each droplet a /124 is that it has resulted in DO filtering email ports over Ipv6, on the theory that since email DNSBL blocking is normally done on a /64 basis, if a droplet does something over IPv6 email that draws a block, the block will end up blocking many other droplets. Note that this means that an IPv6-only dropet *cannot do email at all*. This alone, to me, argues for giving each droplet a /64.

      • EdEd commented  · 

        Note that OpenVPN doesn't support server-ipv6 with anything smaller than a /112.

      • Justin CoffmanJustin Coffman commented  · 

        There is a lot of misconception here as far as allocated subnet sizes. It is against the IPv6 standard to allocate anything smaller than a /64 per subnet. Doing so breaks a lot of the fundamental assumptions that IPv6 relies on to operate properly. That said, there's no reason that a /64 block can't be allocated rather than just a single address.

      • MattMatt commented  · 

        The subnet size should be configurable. Most servers only need 1 address, but 256 addresses would be useful for SSL without SNI (server name indication). Also, multiple subnets should be allowed. You should be able to move those subnets to different hosts within a data center.

        With another VPS company, I setup OpenVPN to tunnel only IPv6 traffic through a IPv4 only ISP to that virtual server. OpenVPN requires two subnets, and they were able to route a second subnet of my requested size (/64) to the existing eth0.

      ← Previous 1

      Feedback and Knowledge Base