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. :)
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@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@ripe.net [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von michael.dillon@bt.com Gesendet: Mittwoch, 5. Mai 2010 14:47 An: address-policy-wg@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
On Thu, May 6, 2010 at 08:42, Marcus.Gerdon <Marcus.Gerdon@versatel.de> wrote:
- single address for connecting a customers server => PI - contained /64 (!) segment (i.e. dedicated vlan for a customers rack) => I think somewhat of a border case, but tend to *no* PI
A /64 in IPv6 is what a single address is for IPv4. This is obviously a _very_ reduced view for the sake of my argument, but I think doing this is valid, in this case. Richard
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg- admin@ripe.net] On Behalf Of Marcus.Gerdon Sent: Thursday, May 06, 2010 8:43 AM To: address-policy-wg@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@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@ripe.net [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von michael.dillon@bt.com Gesendet: Mittwoch, 5. Mai 2010 14:47 An: address-policy-wg@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
participants (3)
-
Marcus.Gerdon -
Mark Scholten -
Richard Hartmann