IPv6 Address allocation best practises for sites.
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? - Mitch
On Mon, Sep 24, 2012 at 6:52 PM, John Mitchell <mitch@illuminati.org> wrote:
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?
Hi John, 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. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
William Herrin <bill@herrin.us> wrote:
but I also can't imagine hosting more than 65,000 sites on a single server.
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.) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
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.
On Mon, Sep 24, 2012 at 6:52 PM, John Mitchell <mitch@illuminati.org> wrote:
Does the best practise switch to now using one IPv6 per site, or still the same one IPv6 for multi-sites?
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. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Sep 24, 2012, at 21:08 , Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Mon, Sep 24, 2012 at 6:52 PM, John Mitchell <mitch@illuminati.org> wrote:
Does the best practise switch to now using one IPv6 per site, or still the same one IPv6 for multi-sites?
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.
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] Owen
participants (6)
-
Jeff Wheeler -
John Levine -
John Mitchell -
Owen DeLong -
Tony Finch -
William Herrin