1 / 14

Zenon Mousmoulas Greek Research and Technology Network IPv6 Technologies & Advanced Services

Supporting HTTP over IPv6 for production/legacy web servers. Zenon Mousmoulas Greek Research and Technology Network IPv6 Technologies & Advanced Services Athens, 19 October 2004. Introduction. HTTP is a relatively easy protocol for IPv6 migration, does not pose any protocol specific burdens

truda
Download Presentation

Zenon Mousmoulas Greek Research and Technology Network IPv6 Technologies & Advanced Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Supporting HTTP over IPv6 for production/legacy web servers Zenon Mousmoulas Greek Research and Technology Network IPv6 Technologies & Advanced Services Athens, 19 October 2004

  2. Introduction • HTTP is a relatively easy protocol for IPv6 migration, does not pose any protocol specific burdens • The WWW is still an indisputable key service: • HTTP provides infrastructure and foundation layer for current and future applications (e.g. XML web services) • A web site is a significant factor for attracting even non technical users to IPv6 • Provides transparent to the user access to infinite amounts of readily available content • Wide availability of applications for HTTP over IPv6 (browsers, servers etc.)

  3. The problem • Millions of web sites and web servers out there already running on legacy platforms • Not easy to update a web server on a production system and not always feasible: • On UNIX/Linux systems you could just recompile • For other platforms it means upgrading to a new version (e.g. IIS 6.0): additional costs • Not a trivial process: no real incentive for the web sites to offer IPv6 connectivity while there is still no heavy demand

  4. Paths for upgrading to an IPv6 aware Apache server • IPv6 support in Apache available natively in version 2.0 • For 1.3 branch support available through KAME patches (only up to 1.3.19 though) • Maintainability issues: • Manually tracking patches and managing building process • No pre-built packages widely available • Maintain security on your own: patch, recompile and reinstall to address new security issues exposed

  5. Upgrading to Apache 2.0 • Wide range of functionality commonly linked into Apache in modern installations: authentication modules, application handlers, cryptography providers (OpenSSL) etc. • Building Apache and preserving such functionality means satisfying dependencies with a large number of software: • For building Apache itself: perl, OpenSSL etc. • For building Apache modules: PHP, MySQL, Postgresql, OpenLDAP etc. • Upgrading Apache on a legacy system requires upgrading a vast amount of the system’s software • Building and maintaining (security updates) such an installation is not trivial or easily manageable • Perhaps easier to upgrade the system altogether

  6. Alternative implementation approach: Reverse Proxying • In cases where upgrading a system is not feasible, a need for an alternative implementation method arises • Reverse HTTP proxying is the answer • Allows for a gradual upgrade path for systems while providing IPv6 accessible web sites to end users today

  7. Reverse HTTP Proxying • Mechanism similar to normal (forward) caching proxies but transparent to end user (not required to use a proxy server) • Popular technique widely deployed for giving access to isolated web servers, filtering content etc. • Implementation possible using: • Apache 2.0 and mod_proxy • SQUID

  8. Apache 2.0 & mod_proxy • Module available for Apache 1.3 but supports only HTTP 1.0 • Minimal Apache installation required: # ./configure --prefix=/usr/local/apache2rp --enable-so --disable-v4-mapped --enable-mods-shared="proxy proxy_http proxy_ftp proxy_connect headers" --with-mpm=prefork # make # make install • Modules: • proxy_connect: handle the CONNECT method for SSL tunnelling • headers: rewrite HTTP request/response headers • Also consider mod_proxy_html: rewrite absolute URLs in web content escaping the proxy address space

  9. Configuring the reverse proxy Minimal configuration: • Listening on all interfaces may not work: use specific addresses instead of generic if running on the same system • Load modules • Reverse proxying directives: # turn off proxyrequests to stop forward proxying ProxyRequests Off # proxy clients from everywhere, since this is a reverse proxy <Proxy *> Order deny,allow Allow from all </Proxy> # translate local requests to the ipv4 backend # the directive matches everything, since we have no local content ProxyPass / http://123.123.123.123/ # translate http responses generated by the ipv4 httpd # translate URLs in http redirection headers (automatically generated by the IPv4 httpd) back into the IPv6 proxy’s address space ProxyPassReverse http://123.123.123.123/ /

  10. Deployment considerations • Same system: bind on IPv6 sockets only, keep running legacy httpd • Run a proxy for multiple separate sites: centralized reverse proxy service • For every Virtual Host repeat the configuration: • IP Address based: use IP addresses for proxy directives • Name based: must use domain names in directives • Treat HTTP over SSL as another Virtual Host: must also include mod_ssl directives and provide certificates

  11. Reverse proxying using Squid? • HTTP accelerator (reverse proxy) mode ideal for mass deployment of this mechanism • Dynamically map requests to appropriate back-end servers using a split DNS scheme: zero configuration, add DNS records to start proxying • However IPv6 support in Squid not mature yet: • IPv6 branch stale: has not followed development in 2.5 and 3.0 • Some crippled Debian binary packages available

  12. Pros & cons Pros: • Fast implementation, instantly provide web service over IPv6 • Zero modifications required in a production web server environment • Allow for timely upgrading of systems • Scalable mechanism: a central proxy can support many web sites Cons: • Significant administrative overhead for very large scale deployment • May break advanced authentication and access control schemes • Breaks statistics: all IPv6 requests seem to be coming from the same address (may be fixed with filtering and concatenation of logs) • Not a long term solution overall, native IPv6 support is readily available in related applications and should be preferred whenever possible

  13. Existing deployments • December 2003: mechanism first implemented for GRNET supported Greek open-source community portal www.ellak.gr (first web site in Greece accessible over native IPv6) • February 2004: Panayiotis Christias deployed a central reverse proxy service for a large number of web sites: • www.grnet.gr (now natively supporting IPv6) • www.seeren.org • www.hellasgrid.gr • www.go-online.gr • www.ebusinessforum.gr • Other known deployments: • ipv6gate.sixxs.net provides a similar automated service using DNS

  14. Does all this seem trivial to you? It really is, yet some times simple things can make a difference if they can lead to a breakthrough: wide scale, easy to deploy use of IPv6 on the WWW. Reverse proxying has been popular for some time now, but was not used for this purpose. In September 2004 Jeff Garzik described a mostly identical mechanism (with the addition of caching) and got slashdotted:http://linux.yyz.us/ipv6/proxy.htmlhttp://apache.slashdot.org/apache/04/09/21/237204.shtml

More Related