Skip to content

Instantly share code, notes, and snippets.

@n-st
Last active March 4, 2017 18:19
Show Gist options
  • Save n-st/e53867574cbd9431fbb8cd27bce4f8e3 to your computer and use it in GitHub Desktop.
Save n-st/e53867574cbd9431fbb8cd27bce4f8e3 to your computer and use it in GitHub Desktop.
IPv6. You're doing it wrong.

IPv6. You're doing it wrong.

If you're reading this, you've probably been called out on assigning unreasonably small IPv6 subnets or even individual IPv6 addresses to your customers.
Here's why you should reconsider and assign a separate /64 subnet to each customer:

  • RFC 6177: IPv6 Address Assignment to End Sites:

    The recommendation in RFC 3177 to assign /48s as a default is not a requirement of the IPv6 architecture; anything of length /64 or shorter works from a standards perspective.

  • Why Allocating a /64 is Necessary:

    • Simplicity
    • Route Summarisation
    • (Not) Breaking IPv6
  • IPv6 Email is a little different: One customer, one /64:

    A large hosting company did that recently, assigning each of their customers a small range of IPv6 addresses out of a single /64 – and they discovered why it’s a terrible idea. They had no more than the usual level of email delivery problems on IPv4, but all of their IPv6 mail was blocked at a lot of destinations. Because a /64 is the smallest recommended range to assign to a user it’s also the smallest quantum that reputation services and blacklists will block by. Bad behaviour by one of their customers got the /64 that customer was sending from blocked – along with all the other customers sending from other parts of that /64.

    So don’t do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment