[address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space

> -----Original Message-----
> From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-
> admin at ripe.net] On Behalf Of Marcus.Gerdon
> Sent: Thursday, May 06, 2010 8:43 AM
> To: address-policy-wg at ripe.net
> Subject: AW: [address-policy-wg] Discrepancy Between RIPE Policies on
> IPv4 and IPv6 Provider Independent (PI) Address Space
> 
> In the scenario described here I'd tend to think the colocation/housing
> provider imho is going for ISP bussiness.
> 
> Handing out chunks of address space to customers, which are supposedly
> going to be single-homed, documenting them etc. sounds like LIR
> business. Multi-homing these chunks independent of wether they are PI
> or PA gets to the 'sub-allocation' topic - which isn't supposed to be
> done using parts of a PI space *assigned* to another party. Who's going
> to handle abuse and what ever else might come from the address usage?
> 
> My opinion I'm led to by this scenario is that there's someone who
> wants to circumvent the administrative tasks and save a few $$$ by
> doing ISP/LIR bussiness within PI space.
> 
> Accordingly I think the policy should be kept at (noted at a quick)
> 
> - single address for connecting a customers server
> 	=> PI
> - prefix routed onto customers server
> 	=> *no* PI - go for LIR
> - prefix/range further distributed by customer himself
> 	=> *no* PI - go for LIR
> - contained /64 (!) segment (i.e. dedicated vlan for a customers rack)
> 	=> I think somewhat of a border case, but tend to *no* PI
> 
> Surely everyone wanting to can become a LIR, and everyone wanting to
> hand out chunks of address space to other parties is able to request an
> allocation, or did I miss something?
> 
> @Mark:
> >>PA IPv6 address space is currently not available for us
> Why's that? Sorry for asking a possibly obvisous question, but going
> over the PA policies now I'm simply to lazy. :)
Becoming a LIR is from a business economics view not good for us and the
network we use doesn't offer IPv6 PA, so the only option left without moving
to another network is to use IPv6 PI. But if we are required to be a LIR we
will also require more IPv4 IP space so we have enough for the future. Is it
a target by preventing us to use IPv6 PI to use the last IPv4 IPs as fast as
possible? We currently not even use a /22 IPv4 space, but when we need to
become a LIR we will look for ways to get more IPv4 space.

Regards, Mark
> 
> I can remember that there's been a discussion quite some time ago where
> someone stated he's not able/allowed the LIR contracts with RIPE due to
> regulatory/legal issue or something like that. In case something like
> this is the underlying reason why PI is used for ISP/LIR bussiness then
> imho RIPE/NCC should look into solving this 'organizational' problem
> directly instead of bending policies around making PI into PA lite.
> 
> Just my 2c.
> 
> regards,
> 
> Marcus
> 
> -----------------------------------------------------------------------
> ------------------
> Engineering IP Services
> 
> Versatel West GmbH
> Unterste-Wilms-Strasse 29
> D-44143 Dortmund
> 
> Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491
> marcus.gerdon at versatel.de | www.versatel.de
> 
> Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738
> Geschäftsführer: Dr. Hai Cheng, Joachim Bellinghoven
> -----------------------------------------------------------------------
> ------------------
>  AS8881 / AS8638 / AS13270 / AS29610 | MG3031-RIPE
> -----------------------------------------------------------------------
> ------------------
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: address-policy-wg-admin at ripe.net
> > [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von
> > michael.dillon at bt.com
> > Gesendet: Mittwoch, 5. Mai 2010 14:47
> > An: address-policy-wg at ripe.net
> > Betreff: RE: [address-policy-wg] Discrepancy Between RIPE
> > Policies on IPv4 and IPv6 Provider Independent (PI) Address Space
> >
> >
> > > - With IPv6 we would like to offer a client (collocation) at
> > > least a /112 (with PI this isn't allowed if I'm correctly informed)
> >
> > This points out a material difference between IPv6 and IPv4.
> >
> > IPv6 is classful. Normally, ISPs get a /32 class allocation and
> > give their customers /48 class assignments. Currently the PI policy
> > comes from wanting to allow organizations to get a /48 class
> > assignment from RIPE directly. But if the organization is involved
> > in the hosting business, it is conceivable that customers will
> > expect to receive a /48 class block from the data centre operator.
> >
> > Forget whether this is allowed or not because that is irrelevant.
> > The point is that in the IPv6 world there is the expectation that
> > no network will ever get less than a /64. In a data centre
> environment
> > one would expect that people renting a server or even a rack, would
> > be satisfied with a /64. But people renting a room, or a row of
> racks,
> > might justifiably demand a /48 for their own internal subnetting and
> > routing, even if much of it happens on virtual routers and switches.
> > With the increasing number of cores per chip, even an organization
> > renting a full rack might need more than a /64 because they need
> > to have a network hierarchy within their rack.
> >
> > The problem is that /48 class blocks can't be stretched. In IPv4,
> > there are no classes and everyone allocates according to strict needs
> > now and in the very near future. But IPv6 has classes and allocates
> > so that 99% of allocations can be permanent and never have to be
> > expanded.
> >
> > We would not want organizations asking for a /40 PI allocation this
> > year, then returning next year for another /40, and the year
> > after that.
> >
> > The only way out that I can see is to treat a data centre like an ISP
> > and offer organizations one /32 for each data centre that
> > they operate.
> > This would not apply to WAN operators since they can ask RIPE
> > for a /30
> > or a /28 to cover all of their WAN and all data centres, then
> allocate
> > internally at whatever bit boundary is appropriate.
> >
> > One thing that RIPE should never accept is any plan that assigns less
> > than
> > /64 to a network. If such a plan is submitted, it should be
> > returned and
> > the applicant should be requested to expand any longer prefixes to a
> > full
> > /64, then resubmit. In other words, if you ask for too few addresses,
> > RIPE
> > should deny the request, because it is not in line with IPv6
> > architecture.
> >
> >
> > --Michael Dillon
> >
> >