<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="DE-CH" link="blue" vlink="purple"> <div class="WordSection1"> Hi to all<o:p></o:p> <o:p> </o:p> +1<o:p></o:p> I fully support this proposal. I believe it is an important step to allow for useful deployment of IPv6 taking advantage of the advanced and extended IPv6 address architecture.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Responding to the request for feedback on the "RIPE understanding" section here are some thoughts and comments:<o:p></o:p> <o:p> </o:p> <![if !supportLists]>- <![endif]>The overall tone of the "understanding" section still sounds more like "our main goal is to preserve addresses" instead of "let's make generous use oft he extended address architecture and available space" to me. It is not easy to step out of IPv4 thinking. While we all know in our minds that we need to do this, implementing it is much more difficult. (I am for instance referring to this sentence, which appears more than once: " The RIPE NCC will ask for additional documentation to justify why a less address consuming hierarchy or topology can not be implemented."). There is a widely adopted rule that all address conservation mechanisms should be removed from IPv6 address plans.<o:p></o:p> <o:p> </o:p> <![if !supportLists]>- <![endif]>There is one point where I have a problem to understand, maybe I am misinterpreting the statement. It says " The RIPE NCC will consider longevity reasonable for a similar timeframe for which past growth was documented." - So my question is: how does this accomodate startups? We are moving into the age of the Internet of Things. We expect new technologies and services to spring up, not foreseeable. This includes new business models and opportunities for new companies that have no history. <o:p></o:p> <o:p> </o:p> <![if !supportLists]>- <![endif]>The policy for subsequent allocations will have to be updated accordingly if this policy is accepted.<o:p></o:p> <o:p> </o:p> <![if !supportLists]>- <![endif]>Quote: "If this network topology is justified, the RIPE NCC will consider up to one extra bit per hierarchical level or geographical segment as reasonable, on top of the documented need for that part of the network." Comment: how about "generally up to one bit" - leave room for exceptions.<o:p></o:p> <o:p> </o:p> <![if !supportLists]>- <![endif]>The rules seem quite complicated and a bit hard to really understand and correctly apply to me. I wonder how easy it will be to assess requests based on this. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> As mentioned already, I believe this proposal is a good step. When it comes to how to apply it, I feel there is a lot of "strictness" in the wording. It is always nice to have clear and strict rules, everyone can easily apply them. But reality is different. There is no good rule without exceptions and I hope that this policy will be applied with common sense and adjusted to reality. <o:p></o:p> <o:p> </o:p> And my personal viewpoint is, that we should not restrict IPv6 address plans from the beginning. Our main target should be to finally DEPLOY it as broadly as possible and have ease of operation as a main goal. That is what the address architecture provides.<o:p></o:p> <o:p> </o:p> By today we have given out the equivalent of 171'000 /32 of the currently defined global unicast space (2000::/3) (according to <a href="http://www.bgpexpert.com/addrspace-ipv6.php">Bgpexpert</a>) and this equals 0.032%. Hey that is 171'000 times more than the whole current Internet and we are at 0.032%! I think we should apply a generous allocation model that makes it easy to deploy, operate, secure…..<o:p></o:p> <o:p> </o:p> …and if we get to the point where we feel we have been too generous, we can still adjust policies and become more careful. Once we have used 2000::/3 we still have 7 more chances to do better. We could even define a re-assessment once we are 30% or 50% into the 2000::/3. <o:p></o:p> <o:p> </o:p> My two cents, greetings from the summer heat<o:p></o:p> Silvia Hagen<o:p></o:p> Chair Swiss IPv6 Council<o:p></o:p> <o:p> </o:p> <o:p> </o:p> -----Urspr�ngliche Nachricht----- Von: address-policy-wg [<a href="mailto:address-policy-wg-bounces@ripe.net">mailto:address-policy-wg-bounces@ripe.net</a>] Im Auftrag von Marco Schmidt Gesendet: Donnerstag, 9. Juli 2015 14:20 An: <a href="mailto:policy-announce@ripe.net">policy-announce@ripe.net</a> Cc: <a href="mailto:address-policy-wg@ripe.net">address-policy-wg@ripe.net</a> Betreff: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Dear colleagues,<o:p></o:p> <o:p> </o:p> The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC.<o:p></o:p> <o:p> </o:p> The proposal aims to expand the criteria for evaluating initial<o:p></o:p> IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure.<o:p></o:p> <o:p> </o:p> Some of the differences from version 1.0 include: <o:p></o:p> <o:p> </o:p> - Introduction of new assessment criteria used to evaluate IPv6 allocations larger than a /29<o:p></o:p> - Related wording adjustments in the summary and rationale of the proposal<o:p></o:p> <o:p> </o:p> <o:p> </o:p> You can find the full proposal and the impact analysis at:<o:p></o:p> <o:p> </o:p> <a href="https://www.ripe.net/participate/policies/proposals/2015-03"> https://www.ripe.net/participate/policies/proposals/2015-03</a><o:p></o:p> <o:p></o:p> and the draft document at:<o:p></o:p> <o:p> </o:p> <a href="https://www.ripe.net/participate/policies/proposals/2015-03/draft"> https://www.ripe.net/participate/policies/proposals/2015-03/draft</a><o:p></o:p> <o:p> </o:p> <o:p> </o:p> We encourage you to read the draft document text and send any comments to <a href="mailto:address-policy-wg@ripe.net">address-policy-wg@ripe.net</a> before 7 August 2015.<o:p></o:p> <o:p> </o:p> Regards<o:p></o:p> <o:p> </o:p> Marco Schmidt<o:p></o:p> Policy Development Officer<o:p></o:p> RIPE NCC<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Sunny Connection AG<o:p></o:p> CH-8124 Maur<o:p></o:p> +41 (0)44 887 62 10<o:p></o:p> <a href="http://www.sunny.ch/">www.sunny.ch</a><o:p></o:p> <a href="http://twitter.com/sunny_shagen">http://twitter.com/sunny_shagen</a><o:p></o:p> ******************************************<o:p></o:p> <a href="http://www.ipv6conference.ch/">IPv6 Business Conference, June 18, 2015, Zurich</a><o:p></o:p> International Top Speakers, Unique Program<o:p></o:p> Great Networking - watch out for the 2016 Conference<o:p></o:p> ******************************************<o:p></o:p> Switzerland is in the Top 5 in IPv6 User Adoption<o:p></o:p> We reached 21% in June 2015!<o:p></o:p> ***********************************<o:p></o:p> Our website is dual-stack – how about yours?<o:p></o:p> ***********************************<o:p></o:p> <o:p> </o:p> </div> </body> </html>