Question about what other service/network providers are doing in relation to allocation of addresses for websites.
With IPv6 starting to trickle its way in, what is considered the industry best practise now for IP(v6) addresses bonded to websites. In the past the standard practise was to have a single IPv4 address shared between multiple sites using a name based virtual host directive in Apache/IIS, unless of course the site was SSL in which case it normally needed a IP of its own (unless you had a client who was happy to only support SSL on IE7+ browsers with SNI).
Does the best practise switch to now using one IPv6 per site, or still the same one IPv6 for multi-sites?
Given web browser issues with javascript and DNS changes (see DNS
pinning) I'm not sure why you wouldn't want to pick a configuration
strategy where the IP could follow the site name from server to
server.
I'm not in the multi-site web server business any more. The stuff I
build these days needs a load balancer. If I was I suspect I'd start
at routing a /64 to each web server. Then I'd take a long hard look at
whether it was a better plan to put all the multiply-addressed servers
on a single /64 and let neighbor discovery find the right one for each
site, or to implement /64''s per server and put /128 overrides in the
adjacent router for sites that move from the original server (because
the customer upgraded of course).
Then I'd consider whether to route a /112 to each server instead of a
/64 and assign a single /64 for the set of web servers. I don't know
of any specific problem with routing 2^64 addresses to a single host
but I also can't imagine hosting more than 65,000 sites on a single
server.
So, not a BCP but perhaps some food for thought when choosing your approach.
Does the best practise switch to now using one IPv6 per site, or still
the same one IPv6 for multi-sites?
As I've been migrating my sites to IPv6, each site gets its own IP.
Works great. I did find that I needed to improve my tools so I could
track the individual IP addresses and assign the appropriate DNS names
to them, as I took several dozen (it's a small machine) sites and put
them on IPv6.
Other than not wanting to go to the effort to change all the config
files, it's hard to think of a reason to share IPv6 addresses for
anything. Virtual hosts were specifically invented to conserve IPv4
addresses; they don't provide any added function.
R's,
John
PS: Well, there is my spider trap at http://web.sp.am which would be
hard to do without using a shared IP. But that's perverse.
Demon's homepages service was based on IPv4 virtual hosting and had IIRC a
/16 and two /18s allocated to it. It was a single web server with a few
reverse proxies that took most of the load and that also had all the IP
addresses. The Irix version used a cunning firewall configuration to
accept connections to all the addresses without stupid numbers of virtual
interfaces; the BSD version used a kernel hack. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/12071
On the web server we stuffed the IP address into the filesystem path name
to find the document root. (Or used various evil hacks to map the IP
address to a canonical virtual server host name before stuffing the latter
in the path.)
Certainly it would be nice to have IPv6 address per vhost. In many
cases, this will be practical.
It also sometimes will NOT be practical.
Imagine that I am one of the rather clueless hosting companies who are
handing out /64 networks to any customer who asks for one, and using
NDP to find the machine using each address in the /64. Churn problems
aside, if you have any customer doing particularly dense virtual
hosting, say a few thousand IPv6 addresses on his one or more
machines, then he will use up the whole NDP table for just himself.
You probably won't want to be a customer on the same layer-3 device as
that guy. Now that there might be dozens of VMs per physical server
and maybe 40 physical servers per each top-of-rack device, you can
quickly exhaust all of your NDP entries even with normal, legitimate
uses like www virtual hosting.
Now imagine the hosting company has decided the "stacking" trend is a
good idea, and stacked up a row of 10 EX4200s so they can all share
the same configuration, uplinks, etc. They also share the same NDP
table, so it will be quite easy to run out of NDP (there is only room
for a few thousand entries) not just on one top-of-rack switch, but on
the whole row.
Further, imagine you decided to use a 6500 for a room full of
customers, or even your whole datacenter, which will often work just
fine for IPv4. Suddenly it won't for IPv6, because each customer may
want to make hundreds of NDP entries for his various virtual-hosts.
Just one busy customer with a lot of virtual hosting will run out a
resource shared by every other customer.
So yes, having an IPv6 address per each www virtual-host is certainly
a nice idea. If you have to use NDP to get your addresses to your web
server, though, it might not be practical. It certainly will be
foolish in a "dedicated server" type of environment where you are
renting individual machines or VMs and not owning your own layer-3
box.
That's not the best way to stand up /64s for vhosts.
If you're smart, the customer gets a /64 for machine addresses (put
your interfaces in this /64) and each machine gets a /64 for vHosts
(put your vhost addresses on the loopback interface of the applicable
machine). Then, you route the /64 to the machine address for the
applicable machine and the vhosts never hit your neighbor table.
[snip] Deleted a whole bunch of additional reasons you really want
to do things the way I suggest above [/snip]