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

(Draft) minutes from APWG Meeting at RIPE 62
by Gert Doering 28 Sep '11

28 Sep '11

Hello Working Group, the draft minutes from the APWG sessions at the last RIPE meeting have now been published: http://www.ripe.net/ripe/groups/wg/ap/minutes/minutes-from-ripe-62 please let us know if there is anything that needs to be corrected or amended. Thanks to the RIPE NCC for their work on this, and apologies to the WG for the delay in publishing - that was all my doing, dragging my feet with the initial review. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? 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 0

Re: [address-policy-wg] 2011-01 Last Call for Comments (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA)
by S Moonesamy 27 Sep '11

27 Sep '11

At 02:16 06-09-2011, Emilio Madaio wrote: >The proposal described in 2011-01, "Global Policy for post exhaustion >IPv4 allocation mechanisms by the IANA", is now at its Concluding >Phase. FYI, the ARIN CEO posted a message ( http://lists.arin.net/pipermail/arin-ppml/2011-September/023220.html ) about the IANA review. Regards, S. Moonesamy

1 0

2011-02 Last Call for Comments (Removal of multihomed requirement for IPv6 PI)
by Emilio Madaio 26 Sep '11

26 Sep '11

Dear Colleagues, The proposal described in 2011-02, "Removal of multihomed requirement for IPv6 PI", is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-02 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 24 October 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Updated RIPE document ripe-527, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
by Emilio Madaio 20 Sep '11

20 Sep '11

Dear colleagues, Please note that ripe-524 has been updated to ripe-527. This is due to the addition of a sentence to the policy text. The sentence was accidentally removed from the policy text during the update that followed approval of policy proposal 2010-01. It has been reinstated in this version. This sentence is from the end of Section 11.0: "Information on training courses and training material can be found at: http://www.ripe.net/lir-services/training" The updated RIPE document is available at: https://www.ripe.net/ripe/docs/ripe-527 We apologise for this administrative oversight and any inconvenience caused. Kind regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0

IANA implementation analysis of proposal 2011-01, "Global Policy Proposal for Post Exhaustion IPv4 Allocation Mechanisms by IANA"
by Emilio Madaio 19 Sep '11

19 Sep '11

Dear Colleagues, In order to provide a more comprehensive overview of the expected implementation aspects of proposal 2011-01, the RIPE NCC sought input from IANA staff. Below is the analysis produced by Leo Vegoda. We hope that this input will be useful to RIPE community discussion of this proposal. We also note that the current Review Phase for the proposal will end on 25 August 2011. Best Regards Emilio Madaio Policy Development Officer RIPE NCC --------oooooooooo-------------- IANA staff impact analysis of RIPE policy proposal 2011-01 This analysis considers the impact of ratification of RIPE policy proposal 2011-01 (as a part of GPP-IPv4-2011) by the ICANN Board of Directors. 1. The policy would require ICANN, as the IANA function operator, to establish a Recovered IPv4 Pool. The pool would have to include “any fragments that may be left over in the IANA”. In order to do this, ICANN staff would have to work closely with the five RIRs’ staffs to make sure the initial pool included all fragments assigned to IANA. It is not clear whether this policy proposal is intended to supersede the IETF’s right to make IPv4 assignments for “specialised address blocks (such as multicast or anycast blocks)” as documented in section 4.3 of RFC 2860. This should be clarified but that can probably be done by way of assertions from the NRO rather than a revision to the policy text. In the event that the policy is intended to supersede RFC 2860 there is a potential issue with the internal reservation of small blocks address blocks that have been informally reserved for IETF standards track work currently in progress. 2. It would replace the current procedure for Updating legacy Class A IPv4 allocations, which was agreed with the NRO in February 2007. This is because the text includes a statement that “The Recovered IPv4 Pool will initially contain any fragments that may be left over in the IANA. It will also hold any space returned to the IANA by any other means” and this presumably include address space returned directly by registrants. 3. Once it was activated by an RIR declaring that it has less than a /9 in its inventory, IANA would have to make the first allocation. IANA would then have to make additional allocations on 1 March and 1 September each year, if there is enough address space left in the pool. The minimum allocation size would be a /24 and the “allocation unit” used in each allocation would be determined by dividing the total pool by five and rounding down to the nearest CIDR boundary. As an example, if the pool contained 27 /24s, each RIR would be allocated a /22 (or the equivalent made from multiple /24 prefixes) because 5.4 /24s is not on a CIDR boundary. There is no text stating that the “allocation units” must be a single prefix and so it seems reasonable to make them up from a bundle of prefixes when necessary. 4. All address space added to the Recovered IPv4 Pool would be registered as such in the IANA IPv4 Address Space Registry. Similarly, allocations from the pool would also be registered. This would require the granularity of registration to move from /8 boundaries as is currently the case and as such could inflate the size of the registry from 256 lines to several thousand. --------oooooooooo--------------

2 1

2011-01 Last Call for Comments (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA)
by Emilio Madaio 06 Sep '11

06 Sep '11

Dear Colleagues, The proposal described in 2011-01, "Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA", is now at its Concluding Phase. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2011-01/ Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 4 October 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-01 Review Period extended until 25 August 2011 (Global Policy for post exhaustion IPv4 mechanisms by the IANA)
by Emilio Madaio 31 Aug '11

31 Aug '11

Dear Colleagues, The Review Period for the proposal 2011-01 has been extended until 25 August 2011. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-01 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Emilio Madaio Policy Development Officer RIPE NCC

13 14

2010-01 Proposal Accepted (Temporary Internet Number Assignment Policies)
by Emilio Madaio 12 Aug '11

12 Aug '11

Dear Colleagues, Consensus has been reached, and the proposal described in 2010-01 has been accepted by the RIPE community. The new policy "Temporary Internet Number Assignment Policies" is available at: https://www.ripe.net/ripe/docs/ripe-526 The updated policies "IPv6 Address Allocation and Assignment Policy", "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" and "Autonomous System (AS) Number Assignment Policies" are available respectively at: https://www.ripe.net/ripe/docs/ripe-523 https://www.ripe.net/ripe/docs/ripe-524 https://www.ripe.net/ripe/docs/ripe-525 You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-01 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-03 Last Call for Comments (Post-depletion IPv4 address recycling)
by Emilio Madaio 11 Aug '11

11 Aug '11

Dear Colleagues, The proposal described in 2011-03 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-03 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 8 September 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-03 New Draft Document Published (Post-depletion IPv4 address recycling)
by Emilio Madaio 11 Aug '11

11 Aug '11

Dear Colleagues, The draft document for the proposal described in 2011-03 has been published. The Impact Analysis that was conducted for this proposal has also been published. You can find the full proposal and Impact Analysis at: http://www.ripe.net/ripe/policies/proposals/2011-03 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2011-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 10 August 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

6 5

2011-02 Review Period extended until 23 August 2011 (Removal of multihomed requirement for IPv6 PI)
by Emilio Madaio 09 Aug '11

09 Aug '11

Dear Colleagues, The Review Period for the proposed change to RIPE Document has been extended until 23 August 2011. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2011-02 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0

Discussion standards
by Sander Steffann 08 Aug '11

08 Aug '11

Hello working group, Declaration of hats: speaking on behalf of the chairs of this working group: Gert Döring and myself. We have noticed that in the last months a lot of messages about policy proposals contain assumptions, feelings and expectations. While these can be very important in a discussion it is very hard to discuss such statements. Too much of this and it can make policy development nearly impossible. If we want to make good decisions and work towards consensus we need to raise our standards a bit. I want to ask everybody here to add supporting facts, numbers, statistics or other data wherever possible. That doesn't mean that nobody should express their doubts or opinions! All input is still welcome. But please be aware that when trying to judge if consensus has been reached we might give less weight to input that has no data backing it. Thank you, Sander Steffann APWG Co-chair

1 0

2006-05 Last Call for Comments (PI Assignment Size)
by Emilio Madaio 08 Aug '11

08 Aug '11

Dear Colleagues, The proposal described in 2006-05 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-05 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 5 September 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] the post-mortem on 2008-08
by Milton L Mueller 28 Jul '11

28 Jul '11

Jim: > -----Original Message----- > We're in a paradox where the > community has killed a policy on address certification while > simultaneously authorising the NCC to develop such a system. [snip] > There now needs to be a vote by the NCC membership to > take a decision which will normalise that situation. And unlike RIPE's > PDP, the AGM shouldn't take 3 years to decide. If the NCC membership votes to continue developing the system, how exactly does the situation get "normalized?" A vote to continue development of a system that has been rejected in the policy process continues the paradox, does it not? Only a negative vote would normalize. And I don't get the impression that you would vote no, or urge others to vote no. Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org

2 1

Re: 2006-05 New Draft Document Published (PI Assignment Size)
by Josh Nertrino 24 Jul '11

24 Jul '11

I fully support this proposal. Finally some movement..... (this draft was submitted back in 2006!) Ps. ARIN already has this for years !!!

1 0

RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
by Ivan Pepelnjak 22 Jul '11

22 Jul '11

Let me try to understand: (A) We don't disagree that he might actually deserve more than /32 (B) According to my understanding of previous discussions I had on this topic, RIPE might actually have already reserved extra space for his future needs (C) According to the current rules he can't get another /32 for a total of /31 without using most of the current /32 (and hoping his next /32 will be adjacent) (D) Someone is seriously suggesting he returns the current /32 and asks for a brand new /31 which he will likely get. Was someone reading too much Kafka or The Good Soldier Švejk lately? Ivan > -----Original Message----- > From: Jan Zorz @ Go6.si [mailto:jan@go6.si] > Sent: Monday, July 18, 2011 5:13 PM > To: Ivan Pepelnjak; 'Sander Steffann'; 'Yannis Nikolopoulos' > Subject: RE: [ipv6-wg] additional IPv6 allocation (ripe-512 issues) > > Going to production it was said :) > > I did a long discussion with Alex Le Heux (RIPE IPRA) about the same > issue, his advice was that. > > Jan > > Ivan Pepelnjak <ipepelnjak(a)gmail.com> wrote: > > >Extremely helpful advice from the ops perspective. > > > >> Trade in your /32 and get something bigger under initial alloc > >> conditions... :) > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity.

20 44

Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)
by Sander Steffann 18 Jul '11

18 Jul '11

Hello Yannis, > Lately we've been trying to lay out a future-proof IPv6 addressing plan (actually, to revise our initial IPv6 plan from a few years back) and we came to the conclusion that if we were to plan ahead for a few years, we would need an extra IPv6 allocation from RIPE, one more /32 (we already have one). Well, according to ripe-512 we're not eligible for a subsequent allocation yet, since we haven't met the subsequent allocation criteria (HD ratio). > > We'll be offering our commercial dual stack services (broadband, leased-lines VPNs) next year. This means that we'll have 1,2M potential subscribers (/56) just for the retail service. And then there's all the /48s for the VPNs and bigger customers. I'm not saying that all of our customers will migrate to IPv6 at once but we have to plan, don't we? And then there's the growth factor to be considered also... > > For us, this extra /32 will make the difference between an efficient and future-proof addressing plan that will last for many years and one that will have to be revised after 2-3 years (with all the readdressing etc). I thought that one of the key advantages with IPv6 was the fact that we would get rid of readdressing. What I'm trying to say is that ripe-512 is not flexible enough. In the end, should we planning ahead for many years (as per RFC6177) or not? I am adding the address policy working group. Any changes to address policy / ripe-512 should (also) be discussed there. Thank you, Sander Steffann APWG co-chair

2 1

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

15 Jul '11

Dear Colleagues, Following the feedback received, a new version of the proposal described in 2006-05 is now published. The draft policy document for the proposal has been published. The Impact Analysis that was conducted for this proposal has also been published. You can find the full proposal and Impact Analysis at: http://www.ripe.net/ripe/policies/proposals/2006-05 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2006-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 29 July 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

11 10

2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI)
by Emilio Madaio 12 Jul '11

12 Jul '11

Dear Colleagues, The draft document for the proposal described in 2011-02 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 at: http://www.ripe.net/ripe/policies/proposals/2011-02 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2011-02/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 26 July. Regards Emilio Madaio Policy Development Officer RIPE NCC

28 72

RE: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI)
by poty＠iiat.ru 12 Jul '11

12 Jul '11

> What we do need to make up our collective minds is: > > - do we want to see IPv6 deployed? > (some of the comments can be read as "let's not deploy IPv6, because > the IPv4 routing table is already too large!" - and I'm not > convinced > that this line of reasoning is conclusive) My answer - yes. > - do we think that the group of networks that would get IPv6 PI under > the changed policy, but can't get IPv6 PI now is... > > a) large enough that it makes a difference regarding IPv6 > deployment? No. > b) small enough to avoid exploding the routing table? No. > > As for "b)", the numbers given by Alex Le Heux set a certain upper > boundary > for the number of IPv6 PI prefixes to expect - if every user of an IPv4 > PI > routing table slot today (in the RIPE region) will get an IPv6 PI > block, > we're "in the 10.000s" of routes, but not "in the millions". So we > have > some numbers. There is rather uneasy answers to this as soon as times changes. As soon as IPv6 PI would be easy to get and easy to hold - there will be a "market" for it. It would be presented as a gift, got for prestige, "future", "presence in the Internet", "cool practice" and so on. So you cannot rely on digits for rather tough IPv4 PI policy. Such "blocks" will be nothing (in terms of traffic and usefulness of the deployment), but will clog the routing table a lot, inspiring ISPs to constantly change the equipments and delaying full deployment of full-working IPv6. As soon as the first answers (a) is "No" in my opinion, it is preferable for me to postpone the easing of the requirement until IPv6 starts. Regards, Vladislav Potapov

1 0

RE: [address-policy-wg] 2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI)
by poty＠iiat.ru 12 Jul '11

12 Jul '11

Hello, > > 1. As far as I can see there are no fiscal issues here apart from the > usual issue of more PI's meaning more NCC work meaning more staff > (potentially) and hence more costs. > > > > The potential cost of applying more staff at the RIRs like RIPE NCC > is just one issue. The more important issue is that all the line cards > of the core routers should be replaced if we can not limit the grows of > the forwarding tables (FIB)s. AND IPv4 address space trading allready > might create problems concerning the grows. > > > > A total upgrade beed a couple of billon dollars. Unfortunately even > if this many could be spent, the slow down provoked by the bigger table > size could not be avoided. > > > > Therefore if we want to avoid total collaps or total up-grade and > slow down in the very near future then all the FIBs grows should be > minimised. > > > > Any proposal that might provoke a sudden grows of the FIBs should be > postponed until the technology would evolve enough and allow to handle > fast enough tha definitely larger FIBs. > > > > you still haven't provided any reasons why there should be a sudden > spike and evidence suggesting that there will be. Why? You know - Nigel is a real representative of ISP who knows the things. He said - it'll harm his company's business if the requirement would be removed. And still you do not count it as an argument? > - It's highly unlikely that there will be more IPv6 PI Prefixes than > IPv4 PI Prefixes any time soon in ANY way, that's BY DESIGN of IPv6 > ("one prefix per entity" - usually). If your routers cannot handle > that, you're doing something seriously wrong, or you have a wrong idea > about the whole concept Why someone should ask you about how to do their business? As far as I know - the Internet is on and going without the proposal and not the least role in that duty is due to the people like Nigel. You are asking for not necessary privileges for very small end-user companies and do not hear the "business-oriented" Internet companies. > > - It's highly likely that the IPv4 table WILL grow faster if PI-shops > aren't able to use IPv6 without multihoming because they > will literally buy smaller and smaller IPv4 prefixes and announce > them to stay in business when they grow, so instead of one IPv6 PI > Prefix you will > provoke 10 IPv4 PI Prefixes in some cases - because THERE ALREADY IS > NO MULTIHOMING REQUIREMENT for IPv4 PI No, you haven't done your homework again. There are many restrictions about the length of the IPv4 prefixes. And this is the long time the restrictions will ease. So... > All this proposal does is ease up IPv6 deployment for some entities who > - for whatever stupid reason - rely on PI addresses without being > multi-homed themselves. > And THAT is what the majority should want, more IPv6, soon. IMHO you counterargument yourself here. On one hand you've said that there will be a small number of PI, on another - it will speed up IPv6 deployment. IPv6 will grow without the PI-holders definitely. And this proposal doesn't have ANY relation with that. Regards, Vladislav Potapov

1 0

2011-01 New Draft Document Published (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA)
by Emilio Madaio 08 Jul '11

08 Jul '11

Dear Colleagues The draft document for the proposal described in 2011-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 at: http://www.ripe.net/ripe/policies/proposals/2011-01 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2011-01/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 22 July 2011. Regards Emilio Madaio Policy Development Officer

2 1

Information Regarding AS paths
by Ronak Banka 05 Jul '11

05 Jul '11

Dear Members, I am working on a project and I am stuck at a point where I am in need of AS paths, Is there any way to get AS path for all the AS numbers registered under RIPE RIR ?? -- Ronak Banka Internship student

2 1

2011-02 Removal of multihomed requirement for IPv6 PI
by Dan Luedtke 02 Jul '11

02 Jul '11

Dear Community, I can't wait for this change to happen. As I discussed at IPv6 Kongress in Frankfurt, Germany, there are more than a handful of people wanting that change. For example, I have an IPv4 PI network and adopted early to IPv6 using an IPv6 PA network. Never did, nor will I ever understand why multihoming is required for an IPv6 PI network but not for an IPv4 PI network. I support this draft and like to thank everyone who made it happen. This is an important step awaited by me and many others, even if the community decides not to do it. best regards, Dan Luedtke

2 1

IETF working group on renumbering in IPv6
by Shane Kerr 24 Jun '11

24 Jun '11

All, There is some idea to work on the renumbering problem in IPv6. This is certainly of interest to IPv6 folks, but I am including the address policy folks as this may ultimately have impact there. Cheers, -- Shane

2 1