From debbieh at arin.net Wed Jun 21 16:57:16 2000 From: debbieh at arin.net (Debbie Herrmann) Date: Wed, 21 Jun 2000 16:57:16 -0400 Subject: FW: HTTP 1.1 Message-ID: I don't want to take on any additional tasks right now but I should understand what this is all about? We can talk later. It's quitin time! Have a nice evening Debbie Herrmann Engineering Manager American Registry for Internet Numbers 4506 Daly Drive, Suite 200 Chantilly, VA 20151 703-227-9858 debbieh at arin.net -----Original Message----- From: Barry Skeenes [mailto:bskeenes at arin.net] Sent: Wednesday, June 21, 2000 4:37 PM To: Debbie Herrmann Subject: HTTP 1.1 Debbie, Here's the information I came up with re HTTP 1.1. It needs a review from someone who knows how to implement it. ISPs will need instructions on how to provide it to their downstream customers. Let's chat! Barry ARIN GUIDELINES FOR IMPLEMENTATION OF HTTP 1.1 INTRODUCTION ARIN subscription holders that provide virtual webhosting services, and organizations that request address space from ARIN are required to use HTTP 1.1. Many organizations have been utilizing a unique IP address for each domain they host. Since most ISPs provide webhosting service, this uses address space inefficiently and unnecessarily. Mandatory use of HTTP 1.1 will significantly reduce the number of addresses needed for webhosting and help to conserve address space. In utilizing HTTP 1.1, we move from an IP-based system of webhosting, to a name-based system of hosting. HTTP 1.1 enables multiple domains to be hosted by a single IP address. With IP-based virtual hosting, many hostnames can be hosted on the same server, but one IP address must be used for each hostname. In name-based virtual hosting, many hostnames hosted on the same server resolve to one IP address. ISPs are also responsible for coordinating its use with their downstream customers. In order to save an extensive renumbering exercise, organizations that hold IP space received before July 1, 2000, will not be required to convert that space to HTTP 1.1. There are also a few exceptions to its mandatory use, which are described herein. SSL, and its successor TLS, are used to provide channel-oriented security when HTTP is used for transmitting sensitive materials. HTTP can be used over TLS just as HTTP is used over TCP. HTTP 1.1 is layered over SSL (now succeeded by TLS), which distinguishes secure from insecure traffic by the use of a different server port. According to RFC2068, HTTP 1.0 does not effectively address hierarchical proxies, caching, the need for persistent connections, and virtual hosts. HTTP 1.1 allows for multiple web sites to be supported from a single IP address. This helps to simplify large operational web servers where allocation of many IP addresses to a single host has proven to be problematic. HTTP 1.1 was designed to support previous HTTP versions, including 0.9, 1.0, and 1.1. TECHNICAL CONSIDERATIONS Some versions of SSL servers can support name-based virtual hosting while others cannot. In the event that your SSL server cannot support name-based virtual hosting,.... Some SSL connections require a separate IP per website. Currently, there is no software package to do a !reliable! accounting on a name-based basis. Organizations may need to set up a server as a sniffer and make changes to their network layout. Bandwidth monitoring on name-based hosting is not supported by HTTP 1.1. DNS is not fast enough for moving virtual hosts. One possible solution of redirecting to a new www2-host does not work in all cases. Organizations should replace IP-based software with name-based hosting software for their downstream customers. REFERENCES http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-https-03.txt, HTTP Over TLS http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-http-upgrade-05.txt, Upgrading to TLS Within HTTP/1.1 http://info.internet.isi.edu/in-notes/rfc/files/rfc2246.txt, The TLS Protocol Version 1.0 http://www.ics.uci.edu/pub/ietf/http/rfc2616.txt, Hypertext Transfer Protocol -- HTTP/1.1 http://www.ics.uci.edu/pub/ietf/http/rfc2617.txt, HTTP Authentication: Basic and Digest Access Authentication From kerr at arin.net Wed Jun 21 18:02:49 2000 From: kerr at arin.net (Shane Kerr) Date: Wed, 21 Jun 2000 18:02:49 -0400 (EDT) Subject: FW: HTTP 1.1 In-Reply-To: Message-ID: Here's the issue: When somebody wants their web page hosted, they really care about people being able to get to it by name. The usual stuff, http://www.arin.net or whatever. As we know from days of DNS training, what actually happens is that it gets converted to an address, http://10.5.3.53 or something like that. The problem is that this means that each web site would require its own IP address. Given that there are lots and lots (millions) of web sites, this would waste a significant amount of valuable IPv4 space. The answer is to put multiple hosts on a single machine, using a single IP address. The problem is that if both www.arin.net and www.ripe.net use a single IP address, clients will hit the same port (80) on the same machine, and the server needs a way to know which URL the client really meant to retrieve. Enter HTTP 1.1, in which clients tell the server which URL in particular they are looking for. So when my browser goes to 10.5.3.53, it tells the server that I'm actually looking for www.ripe.net, rather than, say, www.arin.net or some other site hosted on the same box. Then the server can return the appropriate page and everything is groovy, IP space saved, and the (virtual) world a better place for our kids. The problem with *that* is that it requires that browsers be polite and use the HTTP 1.1 protocol. AFAIK, all browsers in the last couple of years or so support HTTP 1.1 - we can check our own extensive server logs to get some idea of what percentage of browsers are complaint. An additional problem is that (as noted in the document) many secure servers (using SSL to provide HTTPS service) do not properly support using names to return the appropriate pages. *shrug* Is it wrong to love this stuff? I'm a little surprised at this document, because at our last member meeting our members EXPLICITLY said they don't want HTTP 1.1 support to be mandatory! I haven't read the heavily edited minutes to see what they say, however. :( Anyway, we (meaning "you all", since I'm leaving) can go the Apache and iPlanet and whatever sites and give configuration information to our members for web servers to turn on virtual hosting (we've actually done this for Apache on zinc), but it will require someone tasked with making sure it stays up to date and answering any e-mails on the topic. Maybe we want to set up a mailing list for this too (or just direct people to the mailing lists that surely already exist for their web server software). -- Shane Kerr Senior Software Engineer American Registry for Internet Numbers (ARIN) +1 703-227-9877 On Wed, 21 Jun 2000, Debbie Herrmann wrote: > I don't want to take on any additional tasks right now but I should > understand what this is all about? > > We can talk later. It's quitin time! Have a nice evening > > Debbie Herrmann > Engineering Manager > American Registry for Internet Numbers > 4506 Daly Drive, Suite 200 > Chantilly, VA 20151 > 703-227-9858 > debbieh at arin.net > > > -----Original Message----- > From: Barry Skeenes [mailto:bskeenes at arin.net] > Sent: Wednesday, June 21, 2000 4:37 PM > To: Debbie Herrmann > Subject: HTTP 1.1 > > > Debbie, > Here's the information I came up with re HTTP 1.1. It needs a review from > someone who knows how to implement it. ISPs will need instructions on how to > provide it to their downstream customers. Let's chat! > Barry > > ARIN GUIDELINES FOR IMPLEMENTATION OF HTTP 1.1 > > INTRODUCTION > > ARIN subscription holders that provide virtual webhosting services, and > organizations that request address space from ARIN are required to use HTTP > 1.1. Many organizations have been utilizing a unique IP address for each > domain they host. Since most ISPs provide webhosting service, this uses > address space inefficiently and unnecessarily. Mandatory use of HTTP 1.1 > will significantly reduce the number of addresses needed for webhosting and > help to conserve address space. > > In utilizing HTTP 1.1, we move from an IP-based system of webhosting, to a > name-based system of hosting. HTTP 1.1 enables multiple domains to be hosted > by a single IP address. With IP-based virtual hosting, many hostnames can be > hosted on the same server, but one IP address must be used for each > hostname. In name-based virtual hosting, many hostnames hosted on the same > server resolve to one IP address. > > ISPs are also responsible for coordinating its use with their downstream > customers. In order to save an extensive renumbering exercise, organizations > that hold IP space received before July 1, 2000, will not be required to > convert that space to HTTP 1.1. There are also a few exceptions to its > mandatory use, which are described herein. > > SSL, and its successor TLS, are used to provide channel-oriented security > when HTTP is used for transmitting sensitive materials. HTTP can be used > over TLS just as HTTP is used over TCP. > HTTP 1.1 is layered over SSL (now succeeded by TLS), which distinguishes > secure from insecure traffic by the use of a different server port. > > According to RFC2068, HTTP 1.0 does not effectively address hierarchical > proxies, caching, the need for persistent connections, and virtual hosts. > HTTP 1.1 allows for multiple web sites to be supported from a single IP > address. This helps to simplify large operational web servers where > allocation of many IP addresses to a single host has proven to be > problematic. HTTP 1.1 was designed to support previous HTTP versions, > including 0.9, 1.0, and 1.1. > > TECHNICAL CONSIDERATIONS > > Some versions of SSL servers can support name-based virtual hosting while > others cannot. In the event that your SSL server cannot support name-based > virtual hosting,.... > Some SSL connections require a separate IP per website. > > Currently, there is no software package to do a !reliable! accounting on a > name-based > basis. Organizations may need to set up a server as a sniffer and make > changes to their network layout. > > Bandwidth monitoring on name-based hosting is not supported by HTTP 1.1. > > DNS is not fast enough for moving virtual hosts. One possible solution of > redirecting to a new www2-host does not work in all cases. > > Organizations should replace IP-based software with name-based hosting > software for their downstream customers. > > REFERENCES > > http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-https-03.txt, HTTP Over > TLS > http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-http-upgrade-05.txt, > Upgrading to TLS Within HTTP/1.1 > http://info.internet.isi.edu/in-notes/rfc/files/rfc2246.txt, The TLS > Protocol Version 1.0 > http://www.ics.uci.edu/pub/ietf/http/rfc2616.txt, Hypertext Transfer > Protocol -- HTTP/1.1 > http://www.ics.uci.edu/pub/ietf/http/rfc2617.txt, HTTP Authentication: Basic > and Digest Access Authentication >