Hosting provider allocation advice

michael.dillon at bt.com michael.dillon at bt.com
Thu Oct 15 16:11:53 CEST 2009


Rather than add IPv6 to existing services or convert each existing
service to an IPv6 version, I would rethink it from the ground up.

To start with, it seems that a shared service would be good enough for
most people since very few are pumping enough traffic to require a
dedicated server or dedicated VLAN. That could be done on one /64. You
would never need any more addresses for this no matter how large your
data center grows. Of course, you might want to offer different classes
of shared service with separate /64s, i.e. one in which porn hosting is
acceptable and one in which it is not. Also a class of shared hosting
that allows email servers to use port 25. That way there will be less
issues with shared fate from others using the same /64.

When you get to the point where people want to do multiple website
hosting on a single dedicated server, then perhaps a /64 per server
would be right since it means that they do not share fate with the same
subnet prefix as the spammer next door. This also fits the model of
renting a dedicated server to someone who then runs VM software and
builds an entire network of virtual machines on their server.

For people who have multiple physical servers, again one /64 per
customer VLAN.

Please avoid ever using a prefix longer than /64 because a) you don't
need to, b) nobody will ever thank you for saving a few addresses, c) it
will cost you more in complexity, and d) any customers on such long
prefixes will share fate with everyone else in the /64. The outside
world will always assume that multiple addresses from the same /64 are
the responsibility of one customer.

For your own internal use (monitoring systems etc.) use a ULA block.

And don't be afraid to allocate more /64s than you had planned, if it
makes your life easier in some way. If you approach IPv6 as a new and
separate service/network from the existing stuff, perhaps you can
simplify things by wasting/spending some of those lovely addresses that
you have received.

--Michael Dillon


More information about the ipv6-ops mailing list