- address-policy-wg - mailman.ripe.net

Last call to participate: 2010 Global IPv6 Deployment Monitoring Survey
by Paul Rendek 29 Jun '10

29 Jun '10

[Apologies for duplicates] Dear Colleagues, This is a last-call reminder to participate in the 2010 Global IPv6 Deployment Monitoring Survey, conducted by GNKS Consult and TNO in collaboration with the RIPE NCC. The survey is available at: http://www.surveymonkey.com/s/IPv6deploymentmonitoring2010 The deadline to complete the survey is this Thursday, 1 July 2010. All five Regional Internet Registries have committed to soliciting participation in this survey in order to compile the most complete global IPv6 deployment data possible. The goal of the survey is to gain a better understanding of where the community is moving, and what can be done to ensure the Internet community is ready for the widespread adoption of IPv6. We encourage all organisations in the RIPE NCC service region to participate in this survey, which we hope will establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. The survey is composed of 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 61, which will be held 15-19 November in Rome, Italy. Results will also be published on IPv6 Act Now: http://ipv6actnow.org Please provide your name and contact information on the survey form if you wish to receive the draft survey analysis when available. Please also indicate whether you are willing to share additional data with the TNO and GNKS Consult IPv6 Deployment Monitoring team. Any questions concerning the survey itself should be addressed to <info(a)gnksconsult.com>. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0

AW: [address-policy-wg] 2010-02 New Policy Proposal (Allocations from the last /8)
by Marcus.Gerdon 18 Jun '10

18 Jun '10

Nick, although assignments might be out of scope here, but Max isn't strolling that far taking his thought logically. Is there a limitation on the size of a PI assignment in place at some time in any one of the lately changed policies? Without digging for any actual numbers out of daily business I'd say there's quite a number of assignments exceeding initial alloctions - and easily exceeding the proposed limit of /22 per LIR. Let me walk a bit further along Max' comment. As soon as I got that last /22 allocation which policy keeps me from requesting a /19 PI for our own use? As far as I remember (at least in v4-world) LIRs aren't excluded from PI policies. Correct me if I'm wrong, but according current practice moving all our dynamic DSL-pools into PI space would be quite valid as each customer only get's a single address with the sole purpose being the connection to our network (mirroring hosting/housing to circuit business). In addition as a LIR I might come to think of issues with equality in business when running into problems after having used up that last /22 and noticing that ISP running their business on PI space are able to further request addtional IP space. 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(a)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(a)ripe.net > [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von Nick Hilliard > Gesendet: Mittwoch, 16. Juni 2010 22:00 > An: address-policy-wg(a)ripe.net > Betreff: Re: [address-policy-wg] 2010-02 New Policy Proposal > (Allocations from the last /8) > > On 16/06/2010 19:37, Max Tulyev wrote: > > I think, the policy is fair. > > > > But you completely forget the Provider Independent > assignments there! So > > I vote for changing "LIRs" to "Companies" there. > > This policy is about allocations (i.e. to LIRs), not assignments (i.e. > directly to end users). I don't think anyone forgot > assignments - they're > just outside the scope of the policy. > > Nick > >

2 1

2010-04 New Policy Proposal (80% Rule Ambiguity Cleanup)
by Emilio Madaio 18 Jun '10

18 Jun '10

PDP Number: 2010-04 80% Rule Ambiguity Cleanup Dear Colleagues A new RIPE 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/2010-04.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 15 July 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC

7 6

Re: [address-policy-wg] 2010-04 New Policy Proposal (80% Rule Ambiguity Cleanup)
by Remco van Mook 18 Jun '10

18 Jun '10

+1 Remco ----- Original Message ----- From: address-policy-wg-admin(a)ripe.net <address-policy-wg-admin(a)ripe.net> To: address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net> Sent: Thu Jun 17 18:26:49 2010 Subject: Re: [address-policy-wg] 2010-04 New Policy Proposal (80% Rule Ambiguity Cleanup) On 17/06/2010 15:50, Emilio Madaio wrote: > http://www.ripe.net/ripe/policies/proposals/2010-04.html agree. please implement. Nick This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.

9 8

Reminder: Global IPv6 Deployment Monitoring Survey
by Paul Rendek 17 Jun '10

17 Jun '10

[Apologies for duplicates] Dear Colleagues, This is a reminder to participate in the 2010 Global IPv6 Deployment Monitoring Survey being conducted by GNKS Consult and TNO, in collaboration with the RIPE NCC. The survey is now available at: http://www.surveymonkey.com/s/IPv6deploymentmonitoring2010 The survey will close on 1 July 2010. All five Regional Internet Registries have committed to soliciting participation in this survey in order to compile the most complete global IPv6 deployment data possible. The goal of the survey is to gain a better understanding of where the community is moving, and what can be done to ensure the Internet community is ready for the widespread adoption of IPv6. We encourage all organisations in the RIPE NCC service region to participate in this survey, which we hope will establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. The survey is composed of 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 61, which will be held 15-19 November in Rome, Italy. Results will also be published on IPv6 Act Now: http://ipv6actnow.org Please provide your name and contact information on the survey form if you wish to receive the draft survey analysis when available. Please also indicate whether you are willing to share additional data with the TNO and GNKS Consult IPv6 Deployment Monitoring team. Any questions concerning the survey itself should be addressed to <info(a)gnksconsult.com >. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0

2010-02 New Policy Proposal (Allocations from the last /8)
by Ingrid Wijte 16 Jun '10

16 Jun '10

PDP Number: 2010-02 Allocations from the last /8 Dear Colleagues A new RIPE 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/2010-02.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 11 May 2010. Regards Ingrid Wijte Policy Development Officer RIPE NCC

6 6

2009-01 Last Call for Comments (Global Policy for the Allocation of IPv4 blocks to Regional Internet Registries)
by Emilio Madaio 16 Jun '10

16 Jun '10

PDP Number: 2009-01 Global Policy for the Allocation of IPv4 blocks to Regional Internet Registries Dear Colleagues, The proposal described in 2009-01 is now at its Concluding Phase. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2009-01.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 14 July 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Getting LIR
by danica hal 14 Jun '10

14 Jun '10

Hello, sorry for the inconvenience if this is the wrong place for this kind of question. In this case please be so kind and point me to the right place. We are thinking about getting a LIR and I need some informations about the requirements we need to fulfil. I know documents about requirements of getting PI and ASN but for getting LIR and tho PA i feel a bit clumsy.. :-) Thank you! best wishes, Danica

2 1

Global Policy for IPv4 Allocations by the IANA Post Exhaustion
by Chris Grundemann 04 Jun '10

04 Jun '10

Hello APWG, I and a group of others have been working on a global policy proposal regarding returning and re-allocating IPv4 addresses to and from the IANA post IPv4 exhaustion. As this is a global proposal, we have decided that the best approach is to float the current draft publicly in all five regions and solicit feedback, before submitting it as an official policy proposal. We hope that this will let us identify and address any problems or gaps ahead of time and thus ease the process. Barring any major issues being raised, we hope to submit the proposal next week so I would love to get your feedback incorporated by Tuesday (8 June) if at all possible. Please feel free to provide comments on or off list. Thanks in advance - have a wonderful weekend! # Global Policy for IPv4 Allocations by the IANA Post Exhaustion # Rationale: This policy defines the process for the allocation of IPv4 addresses post "Exhaustion Phase"[1]. In order to fulfill the requirements of this policy, the IANA must set up a reclamation pool to hold addresses in and distribute from in compliance with this policy. This policy establishes the process by which IPv4 addresses can be returned to and re-issued from the IANA post Exhaustion Phase. The intent of this policy is as follows: * Includes all post Exhaustion Phase address space returned to the IANA. * Allows allocations by the IANA from the Reclamation Pool once the Exhaustion Phase has been completed. * Defines "need" as the basis for further IPv4 allocations by the IANA. * Does not differentiate any class of IPv4 address space unless defined by RFC 1918. * Encourages the return of IPv4 address space by making this re-allocation process available. * Disallows transfers of addresses sourced from the Reclamation Pool in the absence of an IPV4 Global Transfer Policy to neutralize transfer process inequities across RIR regions. * Applies to legacy IPv4 Address Space initially allocated by the IANA to users including the allocations to RIRs. * Includes any length of fragments currently held by the IANA now or in the future. 1. Reclamation Pool Upon adoption of this IPv4 address policy by the ICANN Board of Directors, the IANA shall establish a Reclamation Pool to be utilized post RIR IPv4 exhaustion as defined in Section 5. As soon as the first RIR exhausts its inventory of IP address space, this Reclamation Pool will be declared active. 2. Returning Address Space to the IANA The IANA will accept into the Reclamation Pool all eligible IPv4 address space that is offerred for return. Eligible address space includes any addresses not previously designated for special use by an IETF published RFC explicitly offerred for return to the IANA by: a) The RIR to which the space is assigned b) The registrant of record where no RIR holds authority 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Aggregates in the Reclamation Pool may be divided on a CIDR boundary to the longest minimum allocation or assignment of any of the RIRs in order to complete these allocations. Addresses that are left over will be held in the Reclamation Pool until additional IP addresses are returned, or a minimum allocation unit is achieved that allows continued allocations from the pool. 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool, an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of the RIR's policy defined minimum allocation unit. Any RIR that is formed after this policy has been adopted by the ICANN Board of Directors is not eligible to utilize this policy to obtain IPv4 address space from the IANA. 5. Reporting Requirements The IANA shall publish on at least a weekly basis a report that is publicly available which at a minimum details all address space that has been received and that has been allocated. The IANA shall publish a Returned Address Space Report which indicates what resources were returned, by whom and when. The IANA shall publish an Allocations Report on at least a weekly basis which at a minimum indicates what IPv4 address space has been allocated, which RIR received the allocation and when. The IANA shall publish a public report confirming RIR eligibility subsequent to Section 4. 6. No Transfer Rights Address space assigned from the Reclamation Pool is not subject to transfer outside of an ICANN Board adopted globally adopted transfer policy. The definition of Global Transfer Policy for the purpose of this policy is a global policy that has been processed and adopted by ICANN in compliance with the MoU [2] and attachments as agreed to in October 2004 between ICANN and the RIRs. 7. Definitions IANA - Internet Assigned Numbers Authority or it's successor ICANN - Internet Corporation for Assigned Names and Numbers or it's successor RIR - Regional Internet Registry as recognized by ICANN MOU - Memorandum of Understanding between ICANN and the RIR's IPV4 - Internet Protocol Version Four, the target protocol of this Global Policy 8. References 1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm Global Policy for the Allocation of the Remaining IPv4 Address Space, IANA, Retrieved 27 April 2010 2. http://www.nro.net/documents/aso-mou.html ICANN Address Supporting Organization (ASO) MoU , Retrieved 27 May 2010. ## Thanks again for your time and attention! ~Chris -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org

1 0

Registry - not a policy proposal
by Rob Blokzijl 03 Jun '10

03 Jun '10

[apologies for duplicate mails] Dear RIPE, soon there will be no more IPv4. However, we still have a registry of these addresses. Daniel Karrenberg and myself have produced a document (attached to this mail) which describes what we think the role of this registry should be after the runout of the unallocated IPv4 address space. We will present this document in the Address Policy WG, and would like to invite you to let us know your thoughts. The place for further discussion will be <address-policy-wg(a)ripe.net>. Thank you for your attention, Rob Blokzijl

10 10

2010 IPv6 Deployment Monitoring Survey Now Underway
by Paul Rendek 02 Jun '10

02 Jun '10

[Apologies for duplicates] Dear Colleagues, As announced at RIPE 60 in Prague, GNKS Consult and TNO are working with the RIPE NCC to repeat the 2009 survey on the current and future use of IPv6 throughout the RIPE NCC service region. The IPv6 Deployment Monitoring Survey is now online, and we encourage all members of the RIPE community to participate: http://www.surveymonkey.com/s/IPv6deploymentmonitoring2010 The purpose of the survey is to better understand where the community is moving, and what can be done to ensure the Internet community is ready for the widespread adoption of IPv6. As it is mostly the same as the survey carried out in 2009, comparison of progress will be possible. In addition, RIPE community participation will contribute to a better understanding of the global situation, as APNIC, AfriNIC and LACNIC will also send out the request to participate to their communities. We encourage all organisations in the RIPE NCC service region to participate in this survey, which we hope will establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. The survey is composed of 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. The survey will close on 1 July 2010. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 61, which will be held 15-19 November in Rome, Italy. Results will also be published on IPv6 Act Now: http://ipv6actnow.org Please provide your name and contact information on the survey form if you wish to receive the draft survey analysis when available. Please also indicate whether you are willing to share additional data with the TNO and GNKS Consult IPv6 Deployment Monitoring team. We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to <info(a)gnksconsult.com >. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0

2009-01 New Draft Document and Impact Analysis Published (Global Policy for the Allocation of IPv4 blocks to Regional Internet Registries)
by Filiz Yilmaz 02 Jun '10

02 Jun '10

PDP Number: 2009-01 Global Policy for the Allocation of IPv4 blocks to Regional Internet Registries Dear Colleagues, The draft document for the proposal described in 2009-01 has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal and the impact analysis for it at: http://www.ripe.net/ripe/policies/proposals/2009-01.html and the draft document at: http://www.ripe.net/ripe/draft-documents/2009-01-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 9 June 2010. Regards Filiz Yilmaz Policy Development Manager RIPE NCC

1 0

Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space
by Sander Steffann 11 May '10

11 May '10

Hello working group, A document was distributed today at the RIPE 60 meeting in Prague. The document highlights the differences between IPv4 PI and IPv6 PI and the trends that have been observed. The document provides food for thought, and there will be a discussion in the second slot (11:00 - 12:30) of the Address Policy Working Group session tomorrow. Facilities for remote participation are available at http://www.ripe.net/ripe/meetings/ripe-60/index.php?home=remote. This discussion will of course be followed up on this mailing list. Sander Steffann APWG co-chair

11 29

New IPv4 blocks allocated to RIPE NCC
by Andrea Cima 11 May '10

11 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 31/8 and 176/8 from the IANA in May 2010. We will begin allocating from these ranges in the near future. The minimum allocation size for these two /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html> Additionally, please note that three "pilot" prefixes will be announced from each /8. The prefixes are: 31.0.0.0/16 31.1.0.0/21 31.1.24.0/24 176.0.0.0/16 176.1.0.0/21 176.1.24.0/24 They all originate in AS12654. More information on this "pilot" activity is available in the draft 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 iEYEARECAAYFAkvpJ1QACgkQXOgsmPkFrjMChQCgxw7pxH6OgI0nQuwdhdOIWRp7 ig4An0QaM80yGTPN603EvW7dXkrUNQ/g =4M3X -----END PGP SIGNATURE-----

1 0

AW: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space
by Marcus.Gerdon 06 May '10

06 May '10

Richard, > A /64 in IPv6 is what a single address is for IPv4. I don't agree on this when talking about connecting servers. Place a server in a segment and assign it's interface an IPv4 address 192.168.0.1/24 and an IPv6 address FC00::1/64. Will you (be able to) address another server in the same segment using addresses within those prefixes? Can you get that server connected in IPv4 deploying 192.168.0.0/32 onto its interface? The relevant part here what I meant by 'single address' is the number of addresses configured onto those customers server. Indepent of doing v4 oder v6 you'll configured 'a single address' at the server to get it connected. I agree with you when talking i.e. about DSL lines. Instead of the typical /32 assigned for IPv4 you'll put a /64 on the line. But that's another topic talking about lines instead of servers. As said this were quickly noted items that came to my mind. For the last case of a /64 segment dedicated to one customer I'm not sure but might agree with you that as this would be the equivalent to the DSL line's example. As long as you don't route another /64 (or whatever size) onto customer equipment addressed in this segment. But it's definitely hard to tell where to draw the line. 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(a)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: Richard Hartmann [mailto:richih.mailinglist@gmail.com] > Gesendet: Donnerstag, 6. Mai 2010 10:50 > An: Marcus.Gerdon > Cc: address-policy-wg(a)ripe.net > Betreff: Re: [address-policy-wg] Discrepancy Between RIPE > Policies on IPv4 and IPv6 Provider Independent (PI) Address Space > > On Thu, May 6, 2010 at 08:42, Marcus.Gerdon > <Marcus.Gerdon(a)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 >

4 3

RE: 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies)
by Jamie Stallwood 06 May '10

06 May '10

Hi RIPE, Today's discussion was interesting and concern was raised about commercials being able to get all or most of the address space set aside in the proposal, and about unfair commercial advantage. My thoughts as a paragraph, which I know is rushed and woolly and only intended as a discussion point: 3.5 Use by Commercial Organizations Temporary address space will not be assigned by the RIPE NCC to any commercial organization where such an allocation: * Is not shown to be for a research, development or testing project relevant to an operational business of that organization * Does not seek to provide a "benefit", e.g. through published work in academic or industrial journals, or * Is unable to demonstrate a fair inclusion policy for other commercial organizations to contribute to, or benefit from, the project. [Address allocation is at the RIPE NCCs discretion, but subject to the RIPE NCC Conflict Arbitration Procedure.] Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood(a)imerja.com -- Imerja Limited Tel: 0870 8611488 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Paragon House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO Registered Firm No. GB2001527 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated.

3 4

FW: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space
by Stream Service 06 May '10

06 May '10

-----Original Message----- From: Mark Scholten [mailto:mark@streamservice.nl] Sent: Thursday, May 06, 2010 11:21 AM To: 'Marcus.Gerdon'; 'address-policy-wg(a)ripe.net' Subject: RE: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space > -----Original Message----- > From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg- > admin(a)ripe.net] On Behalf Of Marcus.Gerdon > Sent: Thursday, May 06, 2010 8:43 AM > To: address-policy-wg(a)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(a)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(a)ripe.net > > [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von > > michael.dillon(a)bt.com > > Gesendet: Mittwoch, 5. Mai 2010 14:47 > > An: address-policy-wg(a)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 > > > >

1 0

AW: [address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space
by Marcus.Gerdon 06 May '10

06 May '10

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(a)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(a)ripe.net > [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von > michael.dillon(a)bt.com > Gesendet: Mittwoch, 5. Mai 2010 14:47 > An: address-policy-wg(a)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 > >

3 2

Re: [address-policy-wg] Registry - not a policy proposal
by Toni Stoev 05 May '10

05 May '10

On Wednesday 05 May 2010 at 11:15:36 Rob Blokzijl sent: > > [apologies for duplicate mails] > > Dear RIPE, > > soon there will be no more IPv4. However, we still have a registry > of these addresses. Perhaps you mean "no more unallocated IPv4 addresses". > > Daniel Karrenberg and myself have produced a document (attached to > this mail) which describes what we think the role of this registry > should be after the runout of the unallocated IPv4 address space. > > We will present this document in the Address Policy WG, and would > like to invite you to let us know your thoughts. The place for > further discussion will be <address-policy-wg(a)ripe.net>. > > Thank you for your attention, > > Rob Blokzijl

1 0

Final Agenda for upcoming APWG meeting at RIPE 60
by Sander Steffann 04 May '10

04 May '10

Hi APWG folks, Hi RIPE meeting folks, below you can find the final RIPE address policy WG meeting's agenda, which will take place in Prague in the following three time slots: Wednesday, May 5, 09:00 - 10:30 Wednesday, May 5, 11:00 - 12:30 Thursday, May 6, 14:00 - 15:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". regards, Sander Steffann, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Filiz Yilmaz - overview over concluded proposals 2009-03 [run out fairly] - accepted 2008-06 Use of final /8 - withdrawn 2009-04 IPv4 Allocation and Assignments to Facilitate - withdrawn IPv6 Deployment - common policy topics in all regions (end of IPv4, transfers, ...) C. New Proposals since RIPE 59 -> Discussion of open policy proposals, Part 1 (new proposals) 2010-01 Temporary Internet Number Assignment Policy (Nick Hilliard) 2010-02 Allocations from the last /8 (new combined proposal from Philip Smith and Alain Bidron) This proposal replaces 2008-06 (Philip Smith) and 2009-04 (Alain Bidron). Warning: The previous version of the agenda mentioned that this will be discussed on Thursday. The discussion has been moved back here. 2010-03 Global Policy State in RIPE PDP (Dave Wilson) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- K. Document Cosmetic Surgeries Project - Filiz Yilmaz - feedback received on the first set of changes - how to go forward? L. "Authorship of RIPE Policy Documents" - Filiz Yilmaz This presentation seeks to reach community agreement on how to document and acknowledge the role of people that propose changes to RIPE Internet Resource Allocation and Assignment policies. M. "Update what's happening with ITU and the RIRs" - Axel Pawlik This presentation has been moved to the Cooperation Working Group. N. Differences between IPv4 PI and IPv6 PI (open discussion, based on Alex Le Heux' report at RIPE59) - try to come up with consensus on what we think "IPv6 PI" should be used for, and should not be used for, and then start a PDP proposal to adjust the policy according to it (if needed) - data-center operators and their customers - the "IPv4 loophole" -> customer access links considered infra (and thus, single-address customers with NAT can be numbered from IPv4 PI, but not from IPv6 PI) O. The need for a Registration Policy - Rob Blokzijl ---------------------------------------------------------------------- Thursday, 12:30-14:00 ---------------------------------------------------------------------- T. Discussion of open policy proposals (old proposals) ---- old policy proposals ---- 2006-05 PI Assignment Size (dead, up for grabs) 2008-07 Ensuring Efficient Use of Historical IPv4 Resources (Philip Smith) 2008-08 Initial Certification Policy for PA Space Holders (Nigel Titley, CA TF - update what happened since RIPE 59) 2009-01 Global Policy for the allocation of IPv4 blocks to RIRs (5 RIR design team, represented by Axel Pawlik (?)) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) The following subjects have already been raised: - Wording Cleanup regarding 80% rule for PA allocations - Gert Doering - Impact of the 80% rule - Remco van Mook Z. AOB

1 0

RE: [ipv6-wg] "IPv6 Ripeness" measurements on RIPE Labs
by Tony Hain 03 May '10

03 May '10

How about getting RIPE-NCC to read it.... ;) The remote feed page for the RIPE60 plenary has an embedded IPv4 address rather than the fqdn. // netConnectionUrl defines where the streams are found netConnectionUrl: 'rtmp://193.0.0.162/live' Putting the IPv6 literal into VLC shows that the streamer is not even listening on the IPv6 address of that machine because it just fails the connect, where VLC crashes when trying to take the stream from the IPv4 literal. > -----Original Message----- > From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf > Of Mirjam Kuehne > Sent: Wednesday, April 28, 2010 8:30 AM > To: ipv6-wg(a)ripe.net > Subject: [ipv6-wg] "IPv6 Ripeness" measurements on RIPE Labs > > Dear colleagues, > > We looked at the "IPv6 ripeness" of all LIRs in the RIPE NCC service > region. This was initially created to adjust our IPv6 training course > depending on the country we are in. However, we felt this might also be > valuable in a bigger context. > > Please find the results and methodology on RIPE Labs: > > http://labs.ripe.net/content/ipv6-ripeness > > We would be interested to hear what you think about this idea in > general > and if you have any suggestions on how to modify or improve this. > > Kind Regards, > Mirjam Kühne > RIPE NCC

1 0

Policy proposal 2009-01
by Nigel Titley 29 Apr '10

29 Apr '10

Folks, As one of the authors of this proposal I'd like to get some sort of consensus together in the RIPE region so that we can move forward. All other regions have reached consensus and we are the last to do so. All other regions with the exception of Arin have adopted the policy in it's original form. Arin has modified the policy to remove the mandatory return of recovered address space to IANA, which effectively makes it a different policy. 2009-01 is a global policy which means that the same policy has to be agreed in all regions, so to all practical purposes it is doomed already. However, we still need to decide what to do with it in the RIPE region. To my mind there are four possibilities: 1. We adopt it in its original form thus demonstrating solidarity with the other regions, apart from Arin. 2. We adopt the Arin form of the proposal, thus demonstrating solidarity with Arin, but with no one else 3. We reject the proposal outright, thus demonstrating that we can't make up our minds or that we think it will never work, or something... 4. We ask the regional authors (in this case myself and Axel) to withdraw the proposal in this region. Some background may be helpful here. No one seriously expected that any address space would actually be returned as a result of this policy. It was intended as a statement that should IPv4 address space become available then it would be used for the greater good of all the registries rather than those who had already had the majority of the space already. I realise that this was a rather pious hope, but we felt that it was worth making a statement about. The Arin region's position has made it impossible to make this statement globally, but we still have the opportunity to make it here. I would like to solicit the opinions of this working group in order to try and put the matter to bed once and for all. I realise I'm making rather contentious statements here, but I'm hoping to provoke a bit of discussion. Please can the working group indicate how they would like to move this forward. All the best Nigel

23 39

AW: address-policy-wg digest, Vol 1 #1137 - 1 msg
by Bubeck Eberhard 22 Apr '10

22 Apr '10

Pop ----- Originalnachricht ----- Von: address-policy-wg-admin(a)ripe.net <address-policy-wg-admin(a)ripe.net> An: address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net> Gesendet: Tue Apr 20 12:00:03 2010 Betreff: address-policy-wg digest, Vol 1 #1137 - 1 msg Send address-policy-wg mailing list submissions to address-policy-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request(a)ripe.net You can reach the person managing the list at address-policy-wg-admin(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) (Filiz Yilmaz) --__--__-- Message: 1 From: "Filiz Yilmaz" <filiz(a)ripe.net> To: policy-announce(a)ripe.net Cc: address-policy-wg(a)ripe.net Reply-To: address-policy-wg(a)ripe.net Date: Tue, 20 Apr 2010 11:14:43 +0200 Subject: [address-policy-wg] 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) PDP Number: 2010-03 Global Policy State in RIPE PDP Dear Colleagues A new RIPE 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/2010-03.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 18 May 2010. Regards Filiz Yilmaz Policy Development Manager RIPE NCC End of address-policy-wg Digest

1 0

[Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01
by bmanning＠vacation.karoshi.com 22 Apr '10

22 Apr '10

On Apr 20, 2010, at 9:34 PM, bmanning(a)vacation.karoshi.com wrote: > > and a very pleasant evening. > > a few questions. > > IPv6 on your radar? > Looking at options for addressing your future v6 needs? > > Have you looked at the IETF/ID in the subject line? > > if you think something like this is a good idea, worth > persuing, I'd like to hear from you. > and as Friend Bush reminds, if you think this idea is lunacy - I'd like to hear that as well. --bill

1 0

Draft Agenda for upcoming APWG meeting at RIPE 60
by Gert Doering 20 Apr '10

20 Apr '10

Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Prague in the following three time slots: Wednesday, May 5, 09:00 - 10:30 Wednesday, May 5, 11:00 - 12:30 Thursday, May 6, 14:00 - 15:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Filiz Yilmaz - overview over concluded proposals 2009-03 [run out fairly] - accepted [withdrawn proposals, if any] - common policy topics in all regions (end of IPv4, transfers, ...) C. New Proposals since RIPE 59 -> Discussion of open policy proposals, Part 1 (new proposals) 2010-01 Temporary Internet Number Assignment Policy (Nick Hilliard) ????-?? Global Policy State in RIPE PDP (Dave Wilson) [work in progress, no formal number assigned yet] ????-?? Wording Cleanup regarding 80% rule for PA allocations (Gert Doering) [to be submitted in the next days] ????-?? Allocations from the last /8 (new combined proposal from Philip Smith and Alain Bidron, just presented here, to be discussed on Thursday) [work in progress, formal number to be assigned next week] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- K. Document Cosmetic Surgeries Project - Filiz Yilmaz - feedback received on the first set of changes - how to go forward? L. "Authorship of RIPE Policy Documents" - Filiz Yilmaz This presentation seeks to reach community agreement on how to document and acknowledge the role of people that propose changes to RIPE Internet Resource Allocation and Assignment policies. M. Ideas how to tackle any problems that have been experienced by the NCC Registration Services Department. (open discussion, based on the report and comments on Wednesday) - try to come up with consensus on what we think "IPv6 PI" should be used for, and should not be used for, and then start a PDP proposal to adjust the policy according to it (if needed) - data-center operators and their customers - the "IPv4 loophole" -> customer access links considered infra (and thus, single-address customers with NAT can be numbered from IPv4 PI, but not from IPv6 PI) ---------------------------------------------------------------------- Thursday, 12:30-14:00 ---------------------------------------------------------------------- T. Discussion of open policy proposals (old proposals) ---- old policy proposals ---- 2006-05 PI Assignment Size 2008-07 Ensuring Efficient Use of Historical IPv4 Resources (Philip Smith) 2008-08 Initial Certification Policy for PA Space Holders (Nigel Titley, CA TF - update what happened since RIPE 59) 2009-01 Global Policy for the allocation of IPv4 blocks to RIRs (5 RIR design team) ---- directly related to IPv4 run-out --- 2008-06 Use of Final /8 (Philip Smith) 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment (Alain Bidron) these two proposals will be dropped, and replaced by a new combined proposal: ????-?? Last /8 (new combined proposal from Philip Smith and Alain Bidron) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) Z. AOB -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

1 1