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@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@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@orange-ftgroup.com; address-policy-wg@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