<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly  complicated when requesting PI space)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Agree, i've always treated such requests from PI Applicants as valid "infrastructure" purpose,<BR>
NCC have always agreed, surely this is a non-issue?<BR>
<BR>
<BR>
------------------------------------------------<BR>
David Freedman<BR>
Group Network Engineering<BR>
Claranet Limited<BR>
<A HREF="http://www.clara.net">http://www.clara.net</A><BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: address-policy-wg-admin@ripe.net on behalf of Gert Doering<BR>
Sent: Wed 7/22/2009 10:07<BR>
To: Dmitry Kiselev<BR>
Cc: Gert Doering; Remco van Mook; Address Policy Working Group<BR>
Subject: Re: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly  complicated when requesting PI space)<BR>
<BR>
Hi,<BR>
<BR>
On Wed, Jul 22, 2009 at 11:48:56AM +0300, Dmitry Kiselev wrote:<BR>
> > The network that started this topic ("we have 10 locations that need a<BR>
> > /24 each") is not your typical *LIR* in the first place, and might really<BR>
> > be better suited with PI /24s - as that's what they are doing: connecting<BR>
> > "independent locations" to the Internet.  They are not doing LIR business.<BR>
> ><BR>
> > A *LIR* needs a reasonable amount of address space, so I really fail to<BR>
> > see why someone would want a /24 PA instead of a /24 PI... (which costs<BR>
> > less, and has the same impact on the routing table).<BR>
><BR>
> PI does not allow end user assignments in it. In my opinion it is<BR>
> good reason for allow /24 allocations.<BR>
<BR>
Well.  I can't really see a scenario where I would assign addresses to<BR>
end users and would be happy with a /24 allocation - our end users get<BR>
assignments up to a /23 from us...<BR>
<BR>
I think one of the focal points here is the question on whether 'giving<BR>
a hosted web server an IP address' is 'assigning address space to end<BR>
users'. <BR>
<BR>
The boundary cases ("the customer has a virtual web presence and not<BR>
even a dedicated IP address" and "the customer is running their own web<BR>
farm and the ISP routes a /24 towards their firewall") are pretty clear<BR>
- but there is lots of space for different way to do web server hosting<BR>
in between (managed servers, rented servers, real servers, vmware<BR>
entities, vserver/jailed virtual servers, ...)<BR>
<BR>
<BR>
The IPv4 PI policy currently defines the transfer networks between an ISP<BR>
network and an access customer as "part of the ISP infrastructure" - so<BR>
if you give /32s to DSL end customers, you could run your whole ISP on<BR>
a PI block (but you can't give one of these customers a /30 to use behind<BR>
their router).  Which is a bit funny indeed.<BR>
<BR>
<BR>
People have argued to remove the PA/PI distinction.  I don't think that<BR>
this is the right way (due to the fact that PA allocations necessarily need<BR>
to be more liberal than PI assignments), but maybe we need to loosen up<BR>
PI rules a bit, as in:<BR>
<BR>
 "Using addresses from a PI block to number other parties' devices is<BR>
  permitted as long as these devices are connected to the same network,<BR>
  documentation about the usage can be presented to the RIPE NCC, and<BR>
  full responsibility for the addresses (abuse handling etc) is done by<BR>
  the PI holder".<BR>
<BR>
<BR>
(After all, one of the reasons why we document end user assignments in a<BR>
public database is to be able to contact a person feeling responsible for<BR>
troubleshooting and abuse handling)<BR>
<BR>
"same network" is important to make it crystal clear that "get a chunk<BR>
of PI and sell off smaller bits to 3rd parties connecting at random to<BR>
other ISPs" is not the desired intention.<BR>
<BR>
<BR>
Now come and flame me :-)<BR>
<BR>
Gert Doering<BR>
        -- APWG chair<BR>
--<BR>
Total number of prefixes smaller than registry allocations:  128645<BR>
<BR>
SpaceNet AG                        Vorstand: Sebastian v. Bomhard<BR>
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann<BR>
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)<BR>
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>