September 2011 - address-policy-wg

Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)?
by DI. Thomas Schallar 09 Nov '11

09 Nov '11

Hello! What ist the current status on the multihomed v6 PI topic? regards, Thomas

32 70

Proposal 2011-02 moving to Last Call
by Sander Steffann 27 Oct '11

27 Oct '11

Hello working group, After a extensive analysis of the discussions on the mailing list about proposal 2011-02 we have come to the conclusion that we have rough consensus on this policy proposal, and we have decided to move this policy proposal to Last Call. We have seen much support for this proposal on the mailing list. On the other hand we have seen concern about accelerated growth of the routing table caused by implementing this policy. Data from other RIRs that have a more liberal IPv6 PI policy have not shown evidence for excessive growth in IPv6 PI assignments. As of today, Sep 23, there are 2420 /48 routes in the global BGP table, compared to 3600 /32 routes and ~1100 routes of other prefix lengths. Based on this data we consider the arguments agains this proposal based on possible routing table growth as addressed. We will ask the RIPE NCC to ask for extensive documentation in the IPv6 PI request form about why IPv6 PI space is requested instead of PA space. The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space. If this policy proposal has consensus at the end of Last Call we will also ask the RIPE NCC to monitor and regularly report on IPv6 PI assignment statistics so we can see if the number of PI requests runs out of bounds. On behalf of the Address Policy WG chairs, Sander Steffann

7 10

2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region)
by Emilio Madaio 03 Oct '11

03 Oct '11

Dear Colleagues, The proposal 2008-08, "Initial Certification Policy in the RIPE NCC Service Region", has been withdrawn. It is now archived and can be found at: http://www.ripe.net/ripe/policies/archived-policy-proposals Reason for withdrawal: after carefully following the discussion in the Concluding Phase of the Policy Development Process, the proposer is of the opinion that consensus on this proposal is not possible within the RIPE community. As a consequence, the proposer has decided to withdraw the proposal. Regards Emilio Madaio Policy Development Officer RIPE NCC

14 27

(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