[30834] in North American Network Operators' Group
RE: ARIN Policy on IP-based Web Hosting
daemon@ATHENA.MIT.EDU (Karyn Ulriksen)
Thu Aug 31 16:21:38 2000
Message-ID: <0127E258EE29D3118A0F00609765B44847CB8D@dhcp-gateway.sitestream.net>
From: Karyn Ulriksen <kulriksen@publichost.com>
To: 'Deepak Jain' <deepak@ai.net>,
"Alec H. Peterson" <ahp@hilander.com>
Cc: nanog@merit.edu
Date: Thu, 31 Aug 2000 13:14:17 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1252"
Errors-To: owner-nanog-outgoing@merit.edu
I second that. I believe that some are already doing it, but maybe more
could... probably easier than some of the IP based virtual services could be
modified.
Karyn
> -----Original Message-----
> From: Deepak Jain [mailto:deepak@ai.net]
> Sent: Thursday, August 31, 2000 12:59 PM
> To: Alec H. Peterson
> Cc: John A. Tamplin; nanog@merit.edu
> Subject: Re: ARIN Policy on IP-based Web Hosting
>
>
>
>
> This is not meant at anyone personally, its just something I noticed.
>
> When we are deciding that IP savings, etc are worth it, why
> not make all
> Cable/DSL/Dialup providers use NAT to map access logins to a
> small pool of
> IPs too? The software to do that transparently is already
> available for a
> very high percentage of applications. Heck, even upstreams
> could then NAT
> their downstreams' pools of IPs. We could run the whole internet off a
> single class C again.
>
> This would of course be an inconvenience to some networks
> that use a lot
> of applications that haven't been updated, but we're sure the
> savings are
> worth the pain too.
>
> ---
>
> I guess the point/concern I have is that the largest providers can now
> pick up /13s because they use that many IPs in 3 months, but if you
> subtract out the number of truly unique IPs even the largest
> network would
> absolutely need, applying all available technology, the
> number might be as
> low as a few hundred unique IPs.
>
> Deepak Jain
> AiNET
>
>
> On Thu, 31 Aug 2000, Alec H. Peterson wrote:
>
> >
> > "John A. Tamplin" wrote:
> > >
> > > Well, if the policy is that you have to use name-based
> hosting everywhere
> > > feasible and do something different for those customers that need
> > > something different, that can be quite a hardship on
> existing setups.
> > > For example, re-engineering all the tools to create and
> maintain vdom
> > > services, changing existing customer setups, etc. It is
> certainly easier
> > > to treat all hosting customers alike, rather than have completely
> > > separate setups and then have to change a customer from
> one to the other
> > > when they add or delete services (including downtime).
> >
> > That was also brought up at the meeting, however it was
> generally agreed
> > that the address savings were worth the work.
> >
> > >
> > > Another issue nobody has mentioned is security between
> virtual servers.
> > > Under name-based hosting, they all run as the same
> user-id and thus to get
> > > the same security you have with separate IP-based servers
> you have to put
> > > all the access conrol checks in all the tools that can be
> used. This can be
> > > hard if not impossible to do when you allow full shell
> access to the files
> > > used by the server.
> >
> > Not if you chroot() the user into their file space. That
> may not be ideal,
> > but there are ways to deal with it.
> >
> > Alec
> >
> > --
> > Alec H. Peterson - ahp@hilander.com
> > Staff Scientist
> > CenterGate Research Group - http://www.centergate.com
> > "Technology so advanced, even _we_ don't understand it!"
> >
> >
>
>
