<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><title>Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why?</title><style></style></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1>Hi Jan, <o:p></o:p><o:p> </o:p>If you are providing SSL hosting on your shared, dedicated of VPS webservers, you are allowed to use PI space, as long as you don’t provide blocks to a specific customers to use. That is considered assigning, so if you use a first come, first served assignment strategy on PI IP’s, that is acceptable for PI is my experience with the IPRA’s. <o:p></o:p><o:p> </o:p>If your customer is hosting SSL sites on their equipment (read: you are providing collocation), you would need to sign up as a LIR for now, as your customer isn’t multi-homed (I assume) and that is (still) another requirement for IPv6 PI. <o:p></o:p><o:p> </o:p>I have a policy change requested through the formal channels to remove the multi-homing requirement for PI IPv6, so expect some more discussion on PI IPv6 on the list soon. <o:p></o:p><o:p> </o:p>Regards,<o:p></o:p>Erik Bais <o:p></o:p><o:p> </o:p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jan Tuomi Sent: Wednesday, March 30, 2011 11:55 AM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 PI request is turned down for my multihomed hosting facility - Why?<o:p></o:p></div></div><o:p> </o:p>On 30 mar 2011, at 11.08, Adrian Czapek wrote: > W dniu 2011-03-30 10:58, Tero Toikkanen pisze: >> Hi, >> >> As far as I’m concerned, there seems to be a strange discrepancy between >> IPv4 PI and IPv6 PI. Apparently Janne has already successfully obtained >> IPv4 PI and has now requested IPv6 PI, declaring the same intended use. >> Could someone please point out where in the policy documents it says one >> can use IPv4 PI for hosting, but not IPv6 PI? I’m having a hard time >> finding such terms. >> > <a href="http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider">http://www.ripe.net/ripe/docs/ripe-512#_8._IPv6_Provider</a> > > Most important is the last sentence: > The PI assignment cannot be further assigned to other organisations. > > And according to IPRA, if you provide hosting services on your own infratructure to other companies, you are sub-allocating part of your PI address space to them, so you cannot use PI address space for that purpose. > > Regards > -- > Adrian > So what this means is that if a customer puts their server in my facility I am sub-allocating? To sub-allocate I have to be an LIR and request an own PA-space? For each customer I have to assign their own /64 and register it in the ripe-database? Setting up an SSL-webhost is also sub-allocating? so to set up an ssl-host I have to again allocate an own /64 for the host, register it in the database, set up VLANS and routing on the webserver and network equipment since its a different IP-network? this will cause a lot of problem with stateful inspection in the firewall because i need to use multiple default gateways on the same server. So in the end I have to set up a whole new webbserver for each customer who needs SSL to get things running smoothly? hmm.. seems that I have to forget about IPv6 and continue running IPv4 only.... // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi@ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05 <o:p></o:p><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div>No virus found in this message. Checked by AVG - <a href="http://www.avg.com">www.avg.com</a> Version: 10.0.1204 / Virus Database: 1498/3537 - Release Date: 03/29/11<o:p></o:p></div></div></body></html>