The policy proposals on this page have been archived. You can see at
a glance if they were accepted and adopted by the RIPE community or withdrawn
at any stage.
Name
 |
Status |
Proposal
Number |
Working Group |
Date Archived |
IPv6 Provider Independent (PI) Assignments for LIRs |
ACCEPTED |
|
|
September 2009 |
| Summary: This proposal is to allow LIRs to receive IPv6 PI assignments in addition to an IPv6 allocation. |
Removing Routing Requirements from the IPv6 Address Allocation Policy |
ACCEPTED |
|
|
September 2009 |
| Summary: The IPv6 address allocation policy currently contains mandates about how an allocated address range should be announced into the routing table. Following discussion at RIPE 58, it is proposed that this is removed from the address policy as it does not relate to address allocation. |
Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries |
ACCEPTED |
|
|
September 2009 |
| Summary: According to the current global policy (ripe-416), IANA will cease to make any distinction between 16 bit and 32-bit only ASN blocks by 31 December 2009, when making allocations to RIRs. This proposal is to extend this date by one year, to 31 December 2010. |
Allocating/Assigning Resources to the RIPE NCC |
ACCEPTED |
|
|
July 2009 |
| Summary: This proposal sets out how the RIPE NCC can allocate/assign resources to itself. |
Anycasting Assignments for TLDs and Tier 0/1 ENUM |
ACCEPTED |
|
|
June 2009 |
| Summary:The proposal is to allow Tier 0/1 ENUM operators to receive IPv4 and IPv6 anycasting assignments and extend the number of anycasting prefixes that can be assigned to an operator from one to up to four assignments. |
Multiple IPv6 /32 Allocations for LIRs |
WITHDRAWN |
|
|
May 2009 |
Summary: This was a proposal to allow an LIR operating separate networks in unconnected geographical areas to receive multiple /32 IPv6 allocations.
Reason for Withdrawal: The proposer, together with the Working Group Chairs, decided to withdraw this proposal due to insufficient support for it as it is written. |
Provider Independent (PI) IPv6 Assignments for End User Organisations |
ACCEPTED |
|
|
April 2009 |
| Summary: This proposal introduced a solution for organisations that needed IPv6 Provider Independent (PI) address space. |
| ASPLAIN Format for the Registration of 4-byte ASNs |
WITHDRAWN |
|
|
February 2009 |
Summary:This proposal seeks to modify the current policy document 'Autonomous System (AS) Number Assignment Policies and Procedures' to adopt the use of ASPLAIN for recording and representation of 4-byte AS Numbers.
Reason for Withdrawal: The proposer decided to withdraw this proposal upon publication of RFC 5396. |
Enabling Methods for Reallocation of IPv4 Resources |
ACCEPTED |
|
|
December 2008 |
| Summary: This proposal outlines a framework to migrate previously allocated IPv4 resources from one Local Internet Registry (LIR) to another LIR within
the RIPE NCC Service Region. |
| IPv6 ULA-Central |
WITHDRAWN |
|
|
November 2008 |
Summary:
This policy is intended to allow the assignment of IPv6 blocks within the so-called 'Centrally Assigned Unique Local IPv6 Unicast Addresses' to organisations or individuals requiring it. These addresses are globally unique and intended for local communications, usually within a site or set of them and are not expected to be routable on the global Internet. Prefix FC00::/7 is already reserved by IANA for ULA (bit 8 determines if locally or centrally assigned, so ULA or ULA-Central).
Reason for Withdrawal:
The proposer decided to withdraw this proposal and wait for the IETF process on the subject to conclude. |
| Direct Internet Resource Assignments to End Users from the RIPE NCC |
ACCEPTED |
|
|
October 2008 |
| Summary: This proposal states that a contractual relationship between an End User and a sponsoring LIR or the RIPE NCC must be established before the End User receives Internet number resources (Autonomous System (AS) Number, Provider Independent (PI) IPv4 and IPv6, Internet Exchange Point (IXP) and anycasting assignments) directly from the RIPE NCC. The proposal also reaffirms and clarifies the existing RIPE policy that IPv4 provider independent address assignments of any type cannot be sub-assigned. |
| Global Policy for the Allocation of the Remaining IPv4 Address Space |
ACCEPTED |
|
|
September 2008 |
| Summary: This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, one /8 will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. |
| Cooperative Distribution of the End of the IPv4 Free Pool |
WITHDRAWN |
|
|
September 2008 |
Summary:
This
policy will establish a process for RIR-to-RIR redistribution
of the tail-end of the IPv4 pool, taking effect after the IANA
Reserve is exhausted. Each redistribution Allocation will be
triggered by the recipient RIR depleting its reserve to a 30
day supply, and will result in up to a 3 month supply being
transferred from the RIR with the longest remaining time before
it exhausts its own pool.
Reason for Withdrawal:
The proposer decided to withdraw this proposal due to
insufficient support for it. |
| Assigning IPv6 PA to Every LIR |
WITHDRAWN |
|
|
May 2008 |
Summary:
With the acceptance of this policy RIPE NCC will run a one-time
operation to allocate an IPv6 block to every LIR that does not have any
existing IPv6 holdings.
Reason for Withdrawal:
The proposer decided to withdraw this proposal due to
insufficient support for it. |
| Assigning IPv6 PI to Every INETNUM Holder |
WITHDRAWN |
|
|
May 2008 |
Summary:
With the acceptance of this policy, the RIPE NCC will conduct a one-time
operation to assign a /56 IPv6 PI prefix to all End Users with an IPv4
assignment registered in the RIPE Database.
Reason for Withdrawal:
The proposer decided to withdraw this proposal due to
insufficient support for it. |
| End Policy for IANA IPv4 Allocations to RIRs |
WITHDRAWN |
|
|
March 2008 |
Summary:
This proposal seeks to provide the solutions to the problems in terms of address management which may arise if no measures are taken for IPv4 address exhaustion.
Reason for Withdrawal:
Authors decided that they want to make a new proposal (see 2008-03). |
| Global Policy for the Allocation of the Remaining IPv4 Address Space |
WITHDRAWN |
|
|
March 2008 |
Summary:
This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy.
Reason for Withdrawal:
Authors decided that they want to make a new proposal (see 2008-03). |
| Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy |
ACCEPTED |
2005-08 |
|
November 2007 |
| Summary: To amend the RIPE IPv6 address allocation policies regarding the definition of the default size of End Site allocations, the threshold value for End Site allocation efficiency, and the method of calculation of the End Site allocation efficiency metric. |
| IPv4 Countdown Policy |
WITHDRAWN |
|
|
October 2007 |
Summary:
This policy proposal proposes four general principles, which will be needed to accomplish the smooth termination of IPv4 address allocation.
Reason for Withdrawal:
Authors decided that they want to make a new proposal (see 2007-07). |
| IANA
Policy for Allocation of ASN Blocks to RIRs |
ACCEPTED |
2007-04 |
|
September 2007 |
|
Summary: This
This proposal is to have a global policy for the Regional Internet
Registries (RIRs) to receive blocks of Autonomous System Numbers
(ASNs) from the Internet Assigned Numbers Authority (IANA). |
| Change in IP Assignments for Anycasting DNS Policy |
WITHDRAWN |
|
|
August 2007 |
Summary: This proposal suggested that there should no longer be a requirement to be a ccTLD or a gTLD to receive IPv4 and IPv6 assignments for anycasting DNS.
Reason for Withdrawal: The proposer decided to withdraw this proposal due to insufficient support for it. |
| IPv6
Address Allocation and Assignment Policy |
ACCEPTED |
|
|
July 2007 |
| Summary: This proposal is to change the IPv6 Initial Allocation criteria and the End Site definition in the "IPv6 Address Allocation and Assignment Policy". |
| First Raise in IPv4 Assignment Window Size |
ACCEPTED |
2006-07 |
|
April 2007 |
| Summary: This proposal suggests the Assignment Window (AW) available to new LIRs should automatically be raised from zero (0) to /21 (2,048 IPv4 addresses) six months after they receive their first allocation. Because the sub-allocation policy references the AW policy, the sub-allocation policy also needs to be updated. This proposal suggests that the maximum sub-allocation should be kept at /20 (4,096 IPv4 addresses). |
| IPv4 Maximum Allocation Period |
ACCEPTED |
|
|
March 2007 |
| Summary: This proposal is to have the RIPE NCC allocate address space
to Local Internet Registries (LIRs) based on their one-year needs.
In other words, it suggests setting a maximum allocation period
of 12 months. |
| Contact E-Mail Address Requirements |
WITHDRAWN |
|
|
February 2007 |
Summary: This proposal suggested that working and up-to-date contact e-mail
addresses should be maintained at all times for address space
that is registered in the RIPE Database.
Reason for Withdrawal: Withdrawn by the proposer and the Address Policy Working Group chair as not enough consensus was reached. |
| 4-Byte AS Number Policy |
ACCEPTED |
|
|
September 2006 |
| Summary: This policy proposal details a set of actions and associated dates for RIR AS Number allocation policies to assist in an orderly transition to use of the 4-byte AS Number space. |
| IP Assignments for Anycasting DNS |
ACCEPTED |
2005-02 |
|
September 2006 |
| Summary: To enable country code Top Level Domain (ccTLD) and global Top Level Domain (gTLD) name server operators to provide their DNS service using shared unicast technology, RIPE NCC may assign one IPv4 and/or one IPv6 prefix to each TLD operator. |
| LIR-PARTITIONED
Status for IPv6 |
WITHDRAWN |
|
|
July 2006 |
Summary: This proposal is to have a new status for IPv6 address space as
"LIR-PARTITIONED".
Reason for Withdrawal: The
proposer decided that the proposal was no longer necessary. |
| IPv6
Initial Allocation |
WITHDRAWN |
2005-03 |
|
June 2006 |
Summary: The proposal is to change the IPv6 Initial Allocation criteria outlined
in the "IPv6
Address Allocation and Assignment Policy". The proposed
change is to remove "have a plan for making at least 200 /48
assignments to other organisations within two years" and to
remove the reference to "/48s" as the assignment size.
Reason for Withdrawal: Withdrawn
by proposer who thought this proposal is superceded by 2006-02,
IPv6 Address Allocation and Assignment Policy. |
| Multicast
Monitoring on RIPE NCC Test Traffic Boxes |
WITHDRAWN
|
2005-11 |
|
May 2006 |
Summary: A proposal to add testing of multicast connectivity between the
RIPE NCC Test Traffic boxes that are connected to multicast-capable
networks.
Reason for Withdrawal: During
the discussion phase, the working group decided that the RIPE NCC
should do the work and that there was no need to complete the full
PDP cycle for this proposal. |
| Consumer
Broadband Monitoring Feasibility |
WITHDRAWN
|
2005-10 |
|
May 2006 |
Summary: This is a proposal to have the RIPE NCC, as a neutral body, develop
a way of measuring performance for consumer broadband networks.
The proposal requests funding for a limited deployment prototype
with the purpose of assessing industry and consumer acceptance,
functional requirements and technical issues.
Reason for Withdrawal: During
the discussion phase, the working group decided that the RIPE NCC
should do the work and that there was no need to complete the full
PDP cycle for this proposal. |
| HD-ratio
Proposal |
WITHDRAWN |
2005-01 |
|
May 2006 |
Summary:
The proposal is to change the further allocation criteria for IPv4
as described in ripe-324: "IPv4
Address Allocation and Assignment Policies for the RIPE NCC Service
Region".
Reason for Withdrawal: Withdrawn
by proposer who felt that as there had been a number of objections,
consensus had not been reached. |
| Internet
Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks
to Regional Internet Registries |
ACCEPTED |
2005-09 |
|
April 2006 |
| Summary: The proposal was to have a policy governing the allocation of IPv6
address space from the IANA to the Regional Internet Registries (RIRs). |
| IPv6
Address Allocation and Assignment Policy - definition for "End-Site" |
WITHDRAWN |
2005-04 |
|
January 2006 |
Summary: There are various terms for "end-site" in the IPv6 allocation
and assignment policy (ripe-267) and the RFC3177. We need to have
a final definition for "End-Site" to establish clear internal
assignment policies.
Reason for Withdrawal: During
discussions the proposer decided that the proposal was no longer
necessary. |
| Introducing
DNSSEC Service to Reverse DNS Trees |
ACCEPTED
|
2005-07 |
|
October 2005 |
| Summary: To implement DNSSEC, we propose extending the policy for Reverse Address
Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service
Region. |
| Proposal
to Add Regional Boundaries to Policy Documents |
WITHDRAWN |
2005-06 |
|
July 2005 |
Summary: Our AS assignment policy has the following statement in it - "The
RIPE NCC assigns AS Numbers for Autonomous Systems located in the
RIPE NCC service region". Neither the IPv4 nor the IPv6 policy
documents have such a clear statement in them. It might be a good
idea to add a similar statement to those documents when they are
updated.
Reason for Withdrawal: The
proposer decided to withdraw this proposal. |
| Proposal
to Remove Special African Policies From RIPE Policy Documents |
ACCEPTED |
2005-05 |
|
July 2005 |
| Summary: To modify the policy document text to reflect full recognition of
AfriNIC as a functioning RIR. |
| |
| |
| |
| |
| |
