March 2011 - address-policy-wg

2006-05 New Draft Document Published (PI Assignment Size)
by Emilio Madaio 26 Apr '11

26 Apr '11

Dear Colleagues, Following the feedback received at RIPE 60, the proposal 2006-05 was taken over by a new proposer and a new version was produced. The draft document for the new version of the proposal has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 18 November 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC

10 16

IPv6 PI request is turned down for my multihomed hosting facility - Why?
by Jan Tuomi 01 Apr '11

01 Apr '11

Hi, A have made a request for a IPv6 PI / 48 allocation for my hosting facility. I am mostly hosting shared services, but I also have a lot of Co-located services for my customers. I am already multihomed to have redundancy from two ISPs for IPv4 and I am going to setup the IPv6 Network the same way. My ASN is 196704, and I am multihoming trough IP-Only (AS12552) and Telenor (AS8434). My sponsoring LIR says that I can get an assignment from their PA-space right away, BUT then I would not be multi-homed, so that is NOT an option. The answer I get from you (RIPE) is: You mentioned that several of the subnets will be used to provide services to your customers (LEON Hosting, Co-location/Dedicated servers). Unfortunately current IPv6 address assignment and allocation policy does not permit the use of IPv6 PI address space for these services. At this time IPv6 PI address space cannot be used for any service where a customer would receive a subnet of IP space (including a single IP). Therefore it cannot be used for colocation services, dedicated servers, SSL certificates etc. There is currently a discussion on exactly this subject within the RIPE community. Ventiro AB are welcome to sign up for the mailing list and join the discussion. You can find the mailing list here: http://www.ripe.net/ripe/mail/ripe-lists/address-policy-wg I need to be multihomed because i feel its safer to have redandancy from separate upstreams with separate infrastructure than buying the redundancy from one provider. My business is to keep servers running in my hosting facility, part of them owned by me, part of them owned by the customers. Some servers are shared among several customers, some are dedicated to one customer only. With todays technology as far as I know I must have separate IPs for SSL-enabled services. Is it RIPEs hidden agenda to put small hosting facilitys out of business with IPv6 and force all customers to use the bigger ISPs? When I requested my IPv4 PI allocation, I was already planning to also run with IPv6 to be prepared for the future and somehow try to help with the transition to IPv6, so people dont have the arguments that we dont use IPv6 because there is no services, its now so much services from a global point of view, but it wouldnt be IPv4 only.... So what should I do? What are my options? // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi(a)ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05

14 31

2011-01 New Policy Proposal (Global Policy for post exhaustion IPv4 mechanisms by the IANA)
by Emilio Madaio 22 Mar '11

22 Mar '11

Dear Colleagues, A new Global Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-01/ We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 18 April 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

6 7

RE: [address-policy-wg] IPv6 allocations for 6RD
by Kurt Smolderen 21 Mar '11

21 Mar '11

I strongly support the idea of assigning a smaller prefix to ISPs which are in a state of deploying IPv6 but need to use transitional mechanism for (some of) their customers. Mark has described one of the problems very clear in his email: if an ISP has only a /32 prefix and needs to use all 32 IPv4 bits in the 6rd configuration, only a /64 can be delivered to the home instead of the desired /56 or /48. Needing all 32 bits is for instance the case when an ISP offers internet connectivity to some of its customers via a partnership with another ISP. However, I want to point to an additional problem which appears when an ISP wants to deploy native IPv6 but needs to roll out 6rd (or any other transitional technique) as well. For native IPv6, the ISP will create an IPv6 addressing plan. This will normally include separate prefixes for the ISP's own servers, the ISP's backbone, the ISP's customers etc. For the 6rd domain, the full /32 range is however needed. So at this stage, the ISP has two options: 1) Implement 6rd only 2) Implement native IPv6 only and exclude some customers from being able to use IPv6 (those which would normally be connected through 6rd) I strongly believe we all agree 6rd is only a temporary solution. So I can't imagine we would prefer skipping native IPv6 deployments in favor of IPv6 transitional mechanisms. I also believe we all agree we should enable IPv6 for as much customers as we can, which makes me conclude the second 'option' is not really an option at all... My primary concern is that any ISP - regardless of how small or big it is - can independently of other organizations/ ISPs move forward with IPv6 deployment. RIPE can support this by adapting a policy which - albeit for a limited time span - allows the assignment of a contiguous IPv6 prefix which size does not only depend on the amount of customers the ISP has, but also incorporates the needed technologies to 'IPv6-enable' as much customers as possible. Regards, -Kurt

7 17

2010-05 Policy Proposal Withdrawn (Global Policy for IPv4 Allocation by the IANA post exhaustion)
by Emilio Madaio 18 Mar '11

18 Mar '11

Dear Colleagues, The global policy proposal 2010-05, "Global Policy for IPv4 Allocation by the IANA post exhaustion", has been withdrawn. It is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2010-05 The reason for withdrawal is: it was agreed with the proposer that the lack of community feedback and the impossibility of the proposal becoming globally accepted due to recent developments in the global PDP at the time were sufficient reasons to have it withdrawn. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Updated RIPE NCC Procedural Document Available
by Arne Kiessling 15 Mar '11

15 Mar '11

Dear Colleagues, The RIPE NCC has published an updated procedural document, ripe-518, "Implementation of RIPE Policy 'Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". This document replaces ripe-511, which was published recently. The updated document is available at: http://www.ripe.net/ripe/docs/ripe-518 -- Kind Regards Arne Kiessling IP Resource Analyst RIPE Network Coordination Centre

2 2

New RIPE NCC Procedural Document Available
by Arne Kiessling 10 Mar '11

10 Mar '11

Dear Colleagues, The RIPE NCC has published the new procedural document ripe-511, "Implementation of RIPE Policy 'Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". This document describes the RIPE NCC procedure when contacting End Users of independent Internet number resources who have not yet entered into a contractual relationship with sponsoring Local Internet Registry (LIR) or the RIPE NCC. It also describes the possible consequences if End Users of independent Internet number resources fail to respond when approached by the RIPE NCC or are not compliant with the policies of the RIPE community. The new document is available at: http://www.ripe.net/ripe/docs/ripe-511 -- Kind Regards Arne Kiessling IP Resource Analyst RIPE Network Coordination Centre

2 1

Re: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting
by Adrian Czapek 07 Mar '11

07 Mar '11

My similar request was rejected for the same reasons. Although I did not get a proposal to sub-allocate PA address space from my allocation and deaggreage it over BGP, as Mathieu got, but let's assume that I would get such proposal if I asked for it. What puzzles me, what is the meaning of that action? Let's check the options: 1. They become LIR, they got their allocation - result: +1 prefix i global routing table. 2. They gets PA suballocation from other LIR and deaggreate it - result +1 prefix in global routing table. 3. They gets PI address space - +1 prefix in global routing table. As can be clearly seen above, global routing table growth is not an issue here, since IPRA suggests to deaggregate PA sub-allocations. So, what is an issue here, beacuse I have a strange feeling that only issue are $$ lost by certain RIR due to certain companies refusing to become LIR?! Regards -- Adrian

2 2

Re: [address-policy-wg] IPv6 PI resource question!
by Igor Ybema 03 Mar '11

03 Mar '11

Hi, I'm new to the list but would like to comment on this subject. I'm also trying to receive IPv6 PI for a webhosting customer of us which seems to be a big problem. I do not understand why everyone claims that 'the routing table growth' is the reason not to allow too much IPv6 PI. Those currently having IPv4 PI would of course require IPv6 PI because they still want to be indepentent. If they need to be a LIR to get IPv6 PA the problem is not solved for the routing-table issue. A prefix is still entered into the same global routing-table. I would suggest changing the IPv6 PI policy to make it more clear for hosting/isp company's to get IPv6 PI by enforcing that the equipment on which the IPv6 addresses are installed in rooms accessible by that company. Multi-homing is a good reason also. I'm not sure if we should delete that reason. This makes the company more aware that they are really independend. This suggestion solves two things: - large broadband ISP's with CPE in office-building, homes etc do not fit into this policy. The equipment is behind other company's doors. This enforces these company's to assign block to their customers from PA space as it was meant to be. - small ISP's/hosting company's with a few racks installed at one ore more DC's (which we talk about in this postings) do fit into this policy and will be independend to their internet suppliers. Of course, they should request another PI (or get assigned-PA from a LIR) for their customers which buy dedicated racks from them and receiving their own key to the lock. This is exactly what we would like to see it. What do other people on the list think about this? regards, Igor Ybema

8 11

New IPv4 block allocated to RIPE NCC
by Andrea Cima 01 Mar '11

01 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC has received the IPv4 address range 185/8 from the IANA. This is the final allocation of IPv4 address space that the RIPE NCC will receive from the IANA as stated in ripe-436, "Global Policy for the Allocation of the Remaining IPv4 Address Space". The minimum allocation size for this /8 has been set at /22. You may wish to adjust any filters you have in place accordingly. More information on the IP address space administered by the RIPE NCC can be found on our website at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Additionally, please note that three "pilot" prefixes will be announced from this /8. The prefixes are: 185.0.0.0/16 185.1.0.0/21 185.1.24.0/24 They all originate in AS12654. The pingable addresses will be: 185.0.0.1 185.1.0.1 185.1.24.1 More information on this activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Kind regards, Andrea Cima Registration Services Manager RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk1Pu9kACgkQXOgsmPkFrjM9FgCgsaT8cFxK0YKTFUFzj41L0PQT N1AAoIgmL1zUY8JjkCSa05xt0t8oppgP =woX5 -----END PGP SIGNATURE-----

2 8