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

2008-05 Proposal Accepted (Anycasting Assignments for TLDs and Tier 0/1 ENUM)
by Ingrid Wijte 23 Jun '09

23 Jun '09

PDP Number: 2008-05 Anycasting Assignments for TLDs and Tier 0/1 ENUM Dear Colleagues Consensus has been reached, and the proposal described in 2008-05 has been accepted by the RIPE community. The related RIPE policy documents have now been updated, published and can be found at: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region: http://www.ripe.net/ripe/docs/ripe-471.html and IPv6 Address Allocation and Assignment Policy: http://www.ripe.net/ripe/docs/ripe-472.html The proposal is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2008-05.html The RIPE NCC will implement this new policy within one month. Thank you for your input. Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0

2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM)
by Filiz Yilmaz 22 Jun '09

22 Jun '09

PDP Number: 2008-05 Anycasting Assignments for TLDs and Tier 0/1 ENUM Dear Colleagues The text of the policy proposal 2008-05, "Anycasting Assignments for TLDs and Tier 0/1 ENUM" has been revised. We have published the new version (version 3.0) today. The draft documents for the proposal have also been published, as well as the impact analysis that was conducted for this proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-05.html and the draft documents at: http://www.ripe.net/ripe/draft-documents/ripe-449-draft2008-05.html http://www.ripe.net/ripe/draft-documents/ripe-450-draft2008-05.html We encourage you to read the draft documents and send any comments to address-policy-wg(a)ripe.net before 23 April 2009. Regards Filiz Yilmaz Policy Development Officer RIPE NCC

14 34

IPv6 Deployment Monitoring Survey Now Underway!
by Paul Rendek 18 Jun '09

18 Jun '09

[Apologies for duplicates] Dear Colleagues, As announced at RIPE 58, TNO and GNKS Consult are working with the RIPE NCC to conduct a survey, sponsored by the European Commission, 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://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg 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. The survey was developed in consultation with members of the RIPE community, and is inspired by the 2008 survey conducted by ARIN and CAIDA in North America. It is sponsored by the European Commission, which has actively supported the adoption of IPv6, in the interests of innovation and the continuing competitiveness of European industry. 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. By making the survey design similar to the ARIN/CAIDA survey, we hope that the results will contribute to a better global picture of current and future IPv6 deployment. The survey is composed of 16 questions and can be completed in 10-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 3 July 2009. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 59, which will be held 5-9 October in Lisbon, Portugal. 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

3 2

2009-08 New Policy Proposal (IPv6 Provider Independent (PI) Assignments for LIRs)
by Ingrid Wijte 16 Jun '09

16 Jun '09

PDP Number: 2009-08 IPv6 Provider Independent (PI) Assignments for LIRs 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/2009-08.html We encourage you to review this proposal and send your comments to address-policy-wg(a)ripe.net before 1 July 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC

4 3

2009-02 Last Call for Comments (Allocating/Assigning Resources to the RIPE NCC)
by Ingrid Wijte 16 Jun '09

16 Jun '09

PDP Number: 2009-02 Allocating/Assigning Resources to the RIPE NCC Dear Colleagues, The proposal described in 2009-02 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-02.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 14 July 2009. Regards Ingrid Wijte Policy Development Officer RIPE NCC

1 0

AW: [address-policy-wg] 2009-08
by Marcus.Gerdon 09 Jun '09

09 Jun '09

I support this proposal as is. Where's the reason for treating LIR's different than end users in regards to 'validity of the assignment' and return of a resource? If routing reasons are the main criteria for assignment existing policies already define the return of the resource as soon as the reasons become invalid. Or did I miss something? kind 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: Marc Lützenkirchen, Dr. Hai Cheng, Dr. Max Padberg, Peter Schindler ---------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 | MG3031-RIPE ---------------------------------------------------------------------------------------- ________________________________ Von: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von Stream Service Gesendet: Dienstag, 9. Juni 2009 02:45 An: address-policy-wg(a)ripe.net Betreff: RE: [address-policy-wg] 2009-08 Because of point 2 I don't support this proposal, if/when this point is removed I support this proposal. Some people don't want that RIPE is saying anything about routing policy, so it should also not look for this for returning IPv6/IPv4 IP assignments if you ask me. From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of David Freedman Sent: maandag 8 juni 2009 22:05 To: address-policy-wg(a)ripe.net Subject: RE: [address-policy-wg] 2009-08 Can I just ask for clarification of the following: "the LIR must demonstrate the unique routing requirements for the PI assignment." and "The LIR must return the IPv6 PI assignment within a period of six months should the unique routing requirements for the PI assignment no longer be met." 1. does this mean that the following question from RIPE-468 is no longer valid for routing? "% Is the End User requesting extra address space for routing and/or % administrative reasons? (Yes/No)" 2. Will this include the space not being routed at all? or does this require that the space be routed? Regards, Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: address-policy-wg-admin(a)ripe.net on behalf of Frederic Sent: Mon 6/8/2009 20:07 To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] 2009-08 hi, we support this proposal. http://www.ripe.net/ripe/policies/proposals/2009-08.html bst regards. Frederic

1 0

2009-08
by Frederic 09 Jun '09

09 Jun '09

hi, we support this proposal. http://www.ripe.net/ripe/policies/proposals/2009-08.html bst regards. Frederic

4 3

RE: [policy-announce] 2009-06 New Policy Proposal (Removing Routing Requirements from the IPv6 Address Allocation Policy)
by Marcus.Gerdon 08 Jun '09

08 Jun '09

Dear colleagues, I can't give support to this proposal as it is. Some of you have already argumented against the resulting de-aggregation and therefore polution of the (IPv6) routing table to be expected. The mindful use of 'Operators Choice' you can all see when browsing the IPv4 table. There *will* be operators de-aggregating an allocation just because they need one - i.e. - /40 to be traversing a defined link. Allowing allocations to be routed at operators liking (which is meant by 'Operators Choice' of course) without violating any policy will supposedly never again be confined once it has been started. Before starting to fire back arguments like 'filtering bcp is at minimum allocation size', 'RIPE doesn't guarantee routing/reachability' etc. think about how to get out of this later on. An example: tell a customer, possibly one of the larger ones you have, that the homemade isp at the other end of the world is polluting the global routing tables and therefore won't receive the customers emails as you are filtering *valid* advertisements (which would be the result after the policy change) based on a recommendation. This doesn't work out. Sooner or later anybody will somehow be forced to accept any de-aggregated trash. IPv6 had been designed for hierarchical addressing. I understand there is need for de-aggregation to support traffic engineering, load-sharing, localized routing or alike. I remember (darkly, so pls don't take me by word) a discussion along the IPv6 PI years (?) regarding geological allocation of address space. So why do we now want to go into the opposite direction? I'm not quite happy having IPv4 and IPv6 being compared in regards to policies and assignment of topics onto wg's. IPv6 has an inherent combination of address assignment/allocation and routing. Doing one without the other in mind will result in IPv4 world again. That said, I come to the part of 'as it is' I stated to the beginning. I suggest to modify the routing requirements to support some level of de-aggregation instead of removing them completely. Why not change b) advertise the allocation that they will receive as a single prefix if the prefix is to be used on the Internet; into something like (roughly worded for short) b) advertise the allocation in whole, and if needed additional overlapping more-specifics up to an 8th the allocations size at most I think this might help in limiting the number of de-aggregated routes within the tables while allowing for a still more stringent filtering based on the 'minimum allocation size'/8. In cases where regional routing or load-sharing across multiple links to the same peer is required special arrangements can always be made I think (using no-export or alike). At least the requirement of advertising the aggregated allocation would maintain reachability across min-alloc-size filters and allow for serious arguments - aka finger-pointing - in regards to customer discussions when traffic isn't able to traverse the aggregate route. 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: Marc Lützenkirchen, Dr. Hai Cheng, Dr. Max Padberg, Peter Schindler ---------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 | MG3031-RIPE ---------------------------------------------------------------------------------------- > -----Ursprüngliche Nachricht----- > Von: address-policy-wg-admin(a)ripe.net > [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von Jeroen Massar > Gesendet: Mittwoch, 27. Mai 2009 18:37 > An: Frederic > Cc: alain.bidron(a)orange-ftgroup.com; address-policy-wg(a)ripe.net > Betreff: Re: [address-policy-wg] RE: [policy-announce] > 2009-06 New Policy Proposal (Removing Routing Requirements > from the IPv6 Address Allocation Policy) > > Frederic wrote: > > we do not support this proposal and we would garant routing for min > > ipv6-PI block assignement. > > RIPE NCC cannot guarantee anything regarding routing. You need to > communicate with the rest of the parties where you want your prefix to > go if they want to accept it or not. > > Please see: > http://www.ripe.net/ripe/docs/ipv6-policies.html#routability > (see section 4.2. Routability Not Guaranteed in RIPE-466) > As mentioned in the text of the proposal. > > > Clearly there is a lot of confusion about this, thus, as I > mentioned in > my other mail, the text can be amended by removing those > statements, but > then there should definitely be a clear link to the above document. > > Greets, > Jeroen > >

1 0

please remove ripe-staff@telecomitalia.it from the whois records
by Jérôme Bouat 08 Jun '09

08 Jun '09

Hello, I'm trying to find the right contact for network issues. Querying the RIPE whois database with the below command: --- whois -h whois.ripe.net 87.14.213.17 --- provides the below result: --- (...) e-mail: ripe-staff(a)telecomitalia.it (...) --- However it appears that the "ripe-staff" mail account is undefined on the "telecomitalia.it" mail server. This means that my Spam complaints never reach the network admin team. Could you please update the whois database (RIPE) by removing the invalid "ripe-staff(a)telecomitalia.it" email address and also provide a replacement ? Thanks for your help. Regards.

3 3

please remove invalid abuse contacts
by Jérôme Bouat 04 Jun '09

04 Jun '09

Hello, Your Whois database is providing "jhli_jl(a)mail.jl.cn" abuse contact email for IP 222.160.20.110. However, the mailbox is full (see attached error message). Please ensure each abuse complaint is processed by each network admin or remove useless contacts. Sometimes the user account or the domain name is invalid in the provided email. Thanks for you help. Regards.

6 10