policy change: static verification methods
Tue Feb 23 20:54:41 CET 1999
Hi, > At 16:44 +0100 23/02/99, Paula Caslav wrote: > >Hello all, > > > >A few weeks ago I send the following proposal to the lir-wg mailing > >list for comments. Since no comments were received, we are assuming > >that nobody has objections to change the policy. We have therefore > >decided to implement it starting immediately. > > > >Kind regards, > > > >Paula Caslav > >RIPE NCC > > > > I agree mostly on the proposal. But please bear in mind that in most > european places, local connection are not free. So another use of > static IP is the setup of MX records on dialup connection that are > down most of the time. this is true. We use static ip's for commercial dialup customers who use privat ip internally with a nat capable router and run perhaps their own mailsevers. They often also want to be able to telnet,ssh back into their networks through port forwarding on the nat router. It would be a waste to start making entries in the ripe database for these single ip's. Any non router dialup users or client only users (small network with nat capable router without any mailservers) will do just fine with a dynamic ip address. The difference here lies in client only setups and setups with local mail etc... servers. > I understand also your concern to push http 1.1, but you _can't_ sell > the virtual web hosting without a fixed IP. The percentage of non > http 1.1 compliant browser is just too high for a business customer > to accept that is vanity name will not be seen by those. this is a hot one and I have the need to share some thoughts on this: The large bulk of the web sites we and propably anybody hosts are of the "homepage" kind of variety of which there are loads on one server. Managing ip address allocation for these kind of low end web servers is a major pita. Which alone is reason engough that we are successively converting all these kinds of servers to name based virtual hosting. The point is not having a http1.1 compliant browser. The point is that the browser sends the http "Host:" header which the absolute majority of browsers already do. This has nothing to do with http1.1 Larger sites running on dedicated servers will always get their separate ip's and might even have a /29 bound to the loopback interface for additional sub websites. But this is totally different from what wee see in the typical virtual web hosting market where we are seeing ip's burned by the truckload. It is especially sad the the majority mass web hosters seem to have loads of /24's with thousands of ip's full of "homepages". They get their address space from upstreams with large aw's who don't ask many questions but prefer to please the customers. They also seldomly reuse those adresses as they seem to concentrate on price dumping and thus don't have the manpower or any intention to cleanup. These are the same kind of people that register truckloads of domains and always create new ripe handles for the contacts. We have even seen one major web hoster and ripe lir enter single ip inetnum objects for each and every web hosting customer. This sort of defeats the whole purpose of assignment windows. Neat trick: become a registry, get yourself a /28 or /27 aw. Then bind a /22 to the loopback of some linux box. All you need to do is add an inetnum object each time you setup a new webserver. All of the above is why I am very happy ripe is now also giving the larger registries a bit of attention. We should all get an even chance in this game of being an ISP/IPP/Iwhatever It is our impression that because of such practices the smaller registriers often have to subnet their networks perhaps a bit too tightly with not too much spare when on the other hand others burn ip's by the truckload..... ---- ok timeout..... thats enough thoughts for the first round. I will now step back and wait to be flamed ..... ;) Greetings Christian Kratzer Toplink -- TopLink Internet Services GmbH ck at 171.2.195.in-addr.arpa Christian Kratzer http://www.toplink.net/ Phone: +49 7032 2701-0 Fax: +49 7032 2701-19 FreeBSD spoken here!
[ lir-wg Archive ]