This document describes the RIPE community’s current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region.

Information on the Address Policy WG is available at:
http://www.ripe.net/ripe/groups/wg/ap

Contents

1.0 Introduction    

1.1 Scope    

2.0 IPv4 Address Space    

3.0 Goals of the Internet Registry System    

3.1 Confidentiality     

3.2 Language     

4.0 Registration Requirements    

5.0 Policies and Guidelines for Allocations    

5.1 Allocations made by the RIPE NCC to LIRs    

5.2 Unforeseen circumstances

5.3 Address Recycling

5.4 Sub-allocations    

5.5 Transfers of Allocations     

6.0 Policies and Guidelines for Assignments    

6.1 Assignments to Internet Exchange Points    

6.2 Network Infrastructure and End User Networks    

6.3 Validity of an Assignment

7.0 Types of Address Space    

8.0 LIR Audit    

9.0 Closing an LIR by the RIPE NCC

1.0 Introduction

The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. The distribution of IP space follows the hierarchical scheme described in the document "Internet Registry System".

1.1 Scope

This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC. These policies must be implemented by all RIPE NCC member LIRs.

This document does not describe policies related to AS Numbers, IPv6, Multicast, or private address space. Nor does it describe address distribution policies used by other RIRs. The RIPE community’s policies for ASN assignment and IPv6 are published in the RIPE Document Store at:
http://www.ripe.net/ripe/docs/policy

2.0 IPv4 Address Space

For the purposes of this document, IP addresses are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses:

1. Public IP addresses are distributed to be globally unique according to the goals described in Section 3 of this document. The two types of IPv4 address described in this documents are Provider Aggregatable (PA) and Provider Independent (PI). 
2. Some address ranges are set aside for the operation of private IP networks. Anyone may use these addresses in their private networks without registration or co-ordination. Hosts using these addresses cannot directly be reached from the Internet. Such connectivity is enabled by using the technique known as Network Address Translation (NAT). Private addresses restrict a network so that its hosts only have partial Internet connectivity. Where full Internet connectivity is needed, unique, public addresses should be used.
   
   For a detailed description of “Address Allocation for Private Internets” and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 found at: ftp://ftp.ripe.net/rfc/rfc1918.txt
   
   For information on the “Architectural Implications of NAT”, please refer to RFC 2993, found at: ftp://ftp.ripe.net/rfc/rfc2993.txt
3. Some address ranges are reserved for special use purposes. These are described in RFC 3330 and are beyond the scope of this document. RFC 3330 can be found at: ftp://ftp.ripe.net/rfc/rfc3330.txt

3.0 Goals of the Internet Registry System

Public IPv4 address assignments should be made with the following goals in mind:

1. Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified.
2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.
3. Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.

3.1 Confidentiality

Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality.

3.2 Language

Please note that all communication with the RIPE NCC must be in English.

4.0 Registration Requirements

All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.

Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).

5.0 Policies and Guidelines for Allocations

An allocation is a block of IPv4 addresses from which assignments are taken.    

All LIRs receiving address space from the RIPE NCC must adopt a set of policies that are consistent with the policies formulated by the RIPE community and described in this document.

5.1 Allocations made by the RIPE NCC to LIRs

The RIPE NCC's minimum allocation size is /22.    

Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC"

On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:

1. The size of the allocation made will be exactly one /22.
2. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).   
3. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application.   
4. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.

In case an allocation of a single /22 as per clause 1 can no longer  be made, multiple allocations up to an equivalent of a /22 in address  space will be made to fulfill a request.

5.2 Unforeseen circumstances

A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen.  Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it.

In the event that this /16 remains unused at the time the remaining addresses covered by this policy has been distributed, it returns to the pool to be distributed as per section 5.1, and this section is to  be automatically deleted from the policy document.

5.3 Address Recycling

Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1.

This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.

5.4 Sub-allocations

Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 7.0.

LIRs wishing to convert their allocations to PA status should contact the RIPE NCC by email at lir-help _at_ ripe _dot_ net.

The minimum size of a sub-allocation is /24. This is the smallest prefix length that can be reverse delegated and allows for a reasonable number of small assignments to be made by a downstream network operator.

LIRs may make sub-allocations to multiple downstream network operators.

The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations.

Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address    space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator.

5.5 Transfers of Allocations

Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA. Such address space must not contain any block that is assigned to an End User.

Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation.

Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.

LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.

The RIPE NCC will record the change of allocation after the transfer.

The RIPE NCC will publish a list of all allocations transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.

The list will contain information about approved and non-approved transfers. 

The following information will be published for approved transfers:

• the name of the transferring party,
• the block originally held by the transferring party,
• the name(s) of the receiving party or parties,
• each subdivided prefix (each partial block derived from that original block) transferred,
• the date each prefix was transferred.

Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published

• the number of requested transfers not approved after the RIPE NCC’s evaluation,
• the sum of the number of addresses included in the requested transfers.

Neither the blocks nor the organizations involved will be identified in these statistics.

Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC until the transfer of address space to another LIR is completed or the address space is returned. The LIR must ensure that all policies are applied.

Re-allocated blocks will be signed to establish the current allocation owner.

Re-allocated blocks are no different from the allocations made directly by the RIPE NCC and so they must be used by the receiving LIR according to the policies described in this document.

6.0 Policies and Guidelines for Assignments

6.1. Assignments to Internet Exchange Points

A /16 will be held in reserve for exclusive use by Internet Exchange Points.  On application for IPv4 resources, an Internet Exchange Point  (IXP) will receive one number resource (/24 to /22) according to the following:

• This space will be used to run an Internet Exchange Point peering LAN; other uses are forbidden.     
• Organisations receiving space under this policy must be Internet Exchange Points and must meet the definition as described in  section two of the RIPE document "IPv6 Address Space for Internet Exchange Points".      
• IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment.      
• New Internet Exchange points will be assigned a /24.  Internet exchange points may return this /24 (or existing PI used as an  IXP peering LAN) should they run out of space and receive a larger (/23, or /22 if utilisation requires) assignment.      
• IP space returned by Internet Exchange Points will be added to the reserved pool maintained for Internet Exchange Point use.      
• Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN.

6.2 Network Infrastructure and End User Networks

IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users.

An explanation of how to register objects in the database can be found in the "RIPE Database User Manual: Getting Started" found at: http://www.ripe.net/data-tools/support/documentation/getting-started

6.3 Validity of an Assignment

All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid.

7.0 Types of Address Space

LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered.

Clear contractual arrangements are recommended and are mandatory for PA space. End Users requesting PA space should be given this or a similar warning:

Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses.

LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum object in the RIPE Database. The possible values of this attribute are:

• ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider.     
• ALLOCATED PI: This address space has been allocated to an LIR or RIR and all assignments made from it are portable. Assignments can be kept as long as the criteria for the original assignment are met. Sub-allocations cannot be made from this type of address space.     
• ALLOCATED UNSPECIFIED: This address space has been allocated to an LIR  or RIR. Assignments may be PA or PI. This status is intended to document past allocations where assignments of both types exist. It is avoided for new allocations. Sub-allocations cannot be made from this type of address space.     
• SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider.     
• LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used.  When the addresses are used, a more specific inetnum should be  registered.     
• LIR-PARTITIONED PI: This allows an LIR to document distribution and delegate management of allocated space within their organisation.  Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnum should be registered.     
• EARLY-REGISTRATION: This is used by the RIPE Database administration when transferring pre-RIR registrations from the ARIN Database. The value can be changed by database users (except for ALLOCATED PA). Only  the RIPE Database administrators can create objects with this value.     
• NOT-SET: This indicates that the registration was made before the  "status:" attributes became mandatory for inetnum objects. The object  has not been updated since then. New objects cannot be created with this value. The value can be changed by database users.     
• ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR.
• ASSIGNED PI: This address space has been assigned to an End User and can be kept as long as the criteria for the original assignment are met.     
• ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD  anycast services.

The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status.

Address space without an explicit type in the "status:" attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either "PA" or "PI" as appropriate.

In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses.

The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1.

8.0 LIR Audit

The RIPE community asked the RIPE NCC to audit LIR operations and ensure consistent and fair implementation of the community's policies. Details of this activity are described in the RIPE Document "RIPE NCC Audit Activity" found at: http://www.ripe.net/ripe/docs/audit

9.0 Closing an LIR by the RIPE NCC

The RIPE NCC may close an LIR for any of the following reasons:

• the LIR does not pay money owed to the RIPE NCC     
• the LIR cannot be contacted by the RIPE NCC for a significant period of time     
• the LIR consistently violates the RIPE community's policies    

The RIPE NCC takes on responsibility for address space held by closing LIRs.

This document relates to the policy proposal 2013-03, “No Need – Post-Depletion Reality Adjustment and Cleanup”. If approved, it will modify ripe-582. To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.

We indicate changes to existing text in the document like this:

All other text in the document will not be replaced.

Abstract

This document describes the RIPE community’s current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region.

Information on the Address Policy WG is available at: 

http://www.ripe.net/ripe/groups/wg/ap

1.0 Introduction

The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. The distribution of IP space follows the hierarchical scheme described in the document "Internet Registry System".

1.1 Scope

This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC. These policies must be implemented by all RIPE NCC member LIRs.

This document does not describe policies related to AS Numbers, IPv6, Multicast, or private address space. Nor does it describe address distribution policies used by other RIRs. The RIPE community’s policies for ASN assignment and IPv6 are published in the RIPE Document Store at:
http://www.ripe.net/ripe/docs/policy

2.0 IPv4 Address Space

For the purposes of this document, IP addresses are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses:

2. Some address ranges are set aside for the operation of private IP networks. Anyone may use these addresses in their private networks without registration or co-ordination. Hosts using these addresses cannot directly be reached from the Internet. Such connectivity is enabled by using the technique known as Network Address Translation (NAT). Private addresses restrict a network so that its hosts only have partial Internet connectivity. Where full Internet connectivity is needed, unique, public addresses should be used.

For a detailed description of “Address Allocation for Private Internets” and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 found at: ftp://ftp.ripe.net/rfc/rfc1918.txt

For information on the “Architectural Implications of NAT”, please refer to RFC 2993, found at: ftp://ftp.ripe.net/rfc/rfc2993.txt

2. Some address ranges are reserved for special use purposes. These are described in RFC 3330 and are beyond the scope of this document. RFC 3330 can be found at: ftp://ftp.ripe.net/rfc/rfc3330.txt

3.0 Goals of the Internet Registry System

Public IPv4 address assignments should be made with the following goals in mind:

1. Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified.

2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.

3.1 Confidentiality

Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality.

3.2 Language

Please note that all communication with the RIPE NCC must be in English.

4.0 Registration Requirements

All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.

Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).

6.2 Network Infrastructure and End User Networks

IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users.

An explanation of how to register objects in the database can be found in the “RIPE Database User Manual: Getting Started” found at:

http://www.ripe.net/data-tools/support/documentation/getting-started

This document relates to the policy proposal 2012-02, “Policy for Inter-RIR Transfers of IPv4 Address Space”. If approved, it will modify ripe-582. To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.

We indicate changes to existing text in the document like this:

All other text in the document will not be replaced.

Abstract

This document describes the RIPE community’s current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region.

Information on the Address Policy WG is available at:

http://www.ripe.net/ripe/groups/wg/ap

Contents

1.0 Introduction

1.1 Scope

2.0 IPv4 Address Space

3.0 Goals of the Internet Registry System

3.1 Confidentiality

3.2 Language

4.0 Registration Requirements

5.0 Policies and Guidelines for Allocations

5.1 First Allocation

5.2 Slow-start Mechanism

5.3 Additional Allocations

5.4 Sub-allocations

5.5 Transfers of Allocations

5.6 Use of last /8 PA Allocations

6.0 Policies and Guidelines for Assignments

6.1 Documentation for Assignments

6.2 Network Infrastructure and End User Networks

6.3 Utilisation Rates

6.4 Reservations Not Supported

6.5 Administrative Ease

6.6 Validity of an Assignment

6.7 Efficiency

6.8 Renumbering

6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers

6.10 Provider Independent IPv4 Assignments for Multihoming

7.0 Assignment Window

8.0 PA vs. PI Address Space

9.0 Record Keeping

10.0 LIR Audit

11.0 Closing an LIR by the RIPE NCC

1.0 Introduction

The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. The distribution of IP space follows the hierarchical scheme described in the document "Internet Registry System".

1.1 Scope

This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC. These policies must be implemented by all RIPE NCC member LIRs.

This document does not describe policies related to AS Numbers, IPv6, Multicast, or private address space. Nor does it describe address distribution policies used by other RIRs. The RIPE community’s policies for ASN assignment and IPv6 are published in the RIPE Document Store at:

http://www.ripe.net/ripe/docs/policy

2.0 IPv4 Address Space

For the purposes of this document, IP addresses are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses:

1. Public IP addresses are assigned to be globally unique according to the goals described in Section 3 of this document.
2. Some address ranges are set aside for the operation of private IP networks. Anyone may use these addresses in their private networks without registration or co-ordination. Hosts using these addresses cannot directly be reached from the Internet. Such connectivity is enabled by using the technique known as Network Address Translation (NAT). Private addresses restrict a network so that its hosts only have partial Internet connectivity. Where full Internet connectivity is needed, unique, public addresses should be used.
   For a detailed description of “Address Allocation for Private Internets” and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 found at: ftp://ftp.ripe.net/rfc/rfc1918.txt
   For information on the “Architectural Implications of NAT”, please refer to RFC 2993, found at: ftp://ftp.ripe.net/rfc/rfc2993.txt
3. Some address ranges are reserved for special use purposes. These are described in RFC 3330 and are beyond the scope of this document. RFC 3330 can be found at: ftp://ftp.ripe.net/rfc/rfc3330.txt

3.0 Goals of the Internet Registry System

Public IPv4 address assignments should be made with the following goals in mind:

1. Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified.
2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.
3. Conservation: Public IPv4 address space must be fairly distributed to the End Users operating networks. To maximise the lifetime of the public IPv4 address space, addresses must be distributed according to need, and stockpiling must be prevented.
4. Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.

3.1 Confidentiality

Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality.

3.2 Language

Please note that all communication with the RIPE NCC must be in English.

4.0 Registration Requirements

All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.

Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).

5.0 Policies and Guidelines for Allocations

An allocation is a block of IPv4 addresses from which assignments are taken.

The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of up to 12 months.

All LIRs receiving address space from the RIPE NCC must adopt a set of policies that are consistent with the policies formulated by the RIPE community and described in this document.

5.1 First Allocation

The RIPE NCC’s minimum allocation size is /21.

Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC"

Members can receive an initial IPv4 allocation when they have demonstrated a need for IPv4 address space.

5.2 Slow-start Mechanism

The slow-start mechanism was put into place to ensure a consistent and fair policy for all LIRs with respect to allocations.

Address space is allocated to LIRs at the rate that the addresses are sub-allocated and assigned by the LIRs. An allocation larger than the minimum size can be made if a need is demonstrated. The size of future allocations is based on the usage rate of previous allocation(s). 

5.3 Additional Allocations

An LIR may receive an additional allocation when about eighty percent (80%) of all the address space currently allocated to it is used in valid assignments or sub-allocations. A new allocation can be made if a single assignment or sub-allocation requires a larger set of addresses than can be satisfied with the address space currently held by the LIR.

Reservations are not considered valid assignments or sub-allocations. It may be useful for internal aggregation to keep some address space free for future growth in addition to the actual assignment. However, the LIR must be aware that these internal reservations are not counted as valid usage. The space must be sub-allocated or assigned before the LIR can request another allocation.

To obtain a new allocation, an LIR should submit a request to the RIPE NCC using the "IPv4 Additional Allocation Request Form" available from the RIPE Document Store at:

http://www.ripe.net/ripe/docs/add-allocation

Additional address space will only be allocated after the information supplied with the request has been verified and a new allocation deemed necessary.

The RIPE NCC will do its best to allocate contiguous address space in order to support aggregation. This cannot be guaranteed as it depends on factors outside the RIPE NCC's influence (e.g. the number of new LIRs and the time needed to utilise the allocation).

5.4 Sub-allocations

Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of “ALLOCATED PA”. LIRs holding “ALLOCATED PI” or “ALLOCATED UNSPECIFIED” allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various “status:” attribute values are described in Section 9.0.

LIRs wishing to convert their allocations to PA status should contact the RIPE NCC by email at lir-help _at_ ripe _dot_ net.

The minimum size of a sub-allocation is /24. This is the smallest prefix length that can be reverse delegated and allows for a reasonable number of small assignments to be made by a downstream network operator.

An LIR may sub-allocate up to an IPv4 /20 (4096 addresses) to a downstream network operator every twelve months.

LIRs may make sub-allocations to multiple downstream network operators.

However, downstream network operators may receive sub-allocations totalling more than a /20 from more than one LIR.

The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community’s policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community’s policies when those operators have sub-allocations.

The RIPE NCC considers sub-allocated space as “used” when evaluating requests from the LIR for an additional IPv4 allocation. Where an LIR has made many sub-allocations with little assigned within them, the RIPE NCC will ask the LIR to justify the reasons for the sub-allocations.

LIRs should note that evaluating a request for an allocation is different from evaluating a request for an assignment. With assignments, the evaluator can see the network plans for a single organisation. With allocations, the evaluator is often presented with sales and marketing plans. The addressing requirements of individual organisations cannot be examined.

It is recommended that LIRs make use of a slow-start mechanism when making a sub-allocation for a downstream network operator. There are two main advantages to this: the LIR can ensure that the address space it sub-allocates is used efficiently; also the LIR can determine the ability of the downstream organisation to operate within the policies set by the RIPE community.

Sub-allocations form part of an LIR’s aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR’s network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator.

5.5 Transfers of Allocations

Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA. Such address space must not contain any block that is assigned to an End User.

Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.

LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.

The RIPE NCC will record the change of allocation after the transfer.

The RIPE NCC will publish a list of all allocations transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.

The list will contain information about approved and non-approved transfers. 

The following information will be published for approved transfers:

• the name of the transferring party,
• the block originally held by the transferring party,
• the name(s) of the receiving party or parties,
• each subdivided prefix (each partial block derived from that original block) transferred,
• the date each prefix was transferred.

Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published

• the number of requested transfers not approved after the RIPE NCC’s evaluation,
• the sum of the number of addresses included in the requested transfers.

Neither the blocks nor the organizations involved will be identified in these statistics.

Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC until the transfer of address space to another LIR is completed or the address space is returned. The LIR must ensure that all policies are applied.

Re-allocated blocks will be signed to establish the current allocation owner.

Re-allocated blocks are no different from the allocations made directly by the RIPE NCC and so they must be used by the receiving LIR according to the policies described in this document.

5.6 Use of last /8 for PA Allocations

The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:

1. Allocations for LIRs from the last /8

   On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:

   1. LIRs may only receive one allocation from this /8.  The size of the allocation made under this policy will be exactly one /22.
   2. LIRs receive only one /22, even if their needs justify a larger allocation.
   3. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application.
   4. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.
2. Assignments to Internet Exchange Points

   A /16 from the final /8 will be held in reserve for exclusive use by Internet Exchange Points.  On application for IPv4 resources, an Internet Exchange Point (IXP) will receive one number resource (/24 to /22) according to the following:

   • This space will be used to run an Internet Exchange Point peering LAN; other uses are forbidden.
   • Organisations receiving space under this policy must be Internet Exchange Points and must meet the definition as described in section two of the RIPE document “IPv6 Address Space for Internet Exchange Points”.
   • IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment.
   • New Internet Exchange points will be assigned a /24. Internet exchange points may return this /24 (or existing PI used as an IXP peering LAN) should they run out of space and receive a larger (/23, or /22 if utilisation requires) assignment.
   • IP space returned by Internet Exchange Points will be added to the reserved pool maintained for Internet Exchange Point use.
   • Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN
3. Unforeseen circumstances

   A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen.  Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. In the event that this /16 remains unused at the time the remaining /8 covered by this policy has been distributed, it returns to the pool to be distributed as per clause 1.

4. Post-depletion Address Recycling

   This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.

   1. Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in clause 1.
   2. Minimum allocation sizes for the relevant /8 blocks will be updated if necessary
5. Insufficient address space

   In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.

6.0 Policies and Guidelines for Assignments

Conservation and aggregation are often conflicting goals. When the Internet Registry System goals are in conflict with the interests of individual End Users or service providers, careful analysis and judgement is necessary to find an appropriate compromise. The rules and guidelines in this document are intended to help LIRs and End Users in their search for equitable compromises.

Please note that LIRs must request approval from the RIPE NCC for assignments that are larger than the LIR's AW (Section 7.0). LIRs are always welcome to approach the RIPE NCC for a second opinion on requests even if they fall within the LIR's AW.

6.1 Documentation for Assignments

In order to determine the address space requirements for a network, relevant information must be gathered. The details needed for justification of each End User organisation’s assignments include the addressing requirements, network infrastructure and future plans. The current address space usage of the organisation should also be determined to ensure that an existing assignment is not duplicated.

This information is essential in making the appropriate assignment decisions. Balancing the overall goals of the Internet Registry System (Section 3.0) with the requirements of the network in question is needed for every network. The level of detail is dependent on the complexity of the network. The LIR must ensure that the necessary information is complete before making an assignment.

The RIPE NCC provides forms for gathering the required information. The information requested in the forms must be collected by the LIR. LIRs may use these forms for their customers' requests or develop their own forms. Local forms can be used if they record all the required data. This is very important when an LIR makes assignments using its AW.

If a request needs to be approved by the RIPE NCC or if information is required in the event of an audit, the information must be submitted on the version of the request form in place at the time of the assignment. The current versions of all request forms can be found at:

http://www.ripe.net/ripe/docs/request-forms-supporting-notes

6.2 Network Infrastructure and End User Networks

IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users.

An explanation of how to register objects in the database can be found in the “RIPE Database User Manual: Getting Started” found at:

http://www.ripe.net/data-tools/support/documentation/getting-started

6.3 Utilisation Rates

Assignments’ immediate utilisation should be at least 25% of the assigned space. After one year, this should be at least 50% of the space unless special circumstances are defined.

Assignments may only be based on realistic expectations recorded in the documentation.

6.4 Reservations Not Supported

End Users are not permitted to reserve address space based on long-term plans. This violates the goal of conservation and fragments the address space when initial forecasts are not met. Evaluation of IP address space requests must be based on a demonstrated need. Unused, or inefficiently used address space assigned in the past should be used to meet the current request, or returned. Once an organisation has used its assigned address space, it can request additional address space based on an updated estimate of growth in its network.

6.5 Administrative Ease

The current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. Examples of this include, but are not limited to, ease of billing administration and network management.

6.6 Validity of an Assignment

All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid.

For these reasons it is important that LIRs make sure that assignments approved by the RIPE NCC are properly registered in the database. The inetnum object or objects for approved assignments must use the netname(s) approved by the RIPE NCC and not be larger than the approved size. Additionally, the date in the first “changed:” attribute must not be earlier than the date of the approval message from the RIPE NCC.

The RIPE NCC reviews assignments made by LIRs when evaluating requests for additional allocations (see 5.3). It also runs consistency checks as part of the auditing activity requested by the community as described in the RIPE Document “RIPE NCC Audit Activity” found at:

http://www.ripe.net/ripe/docs/audit

6.7 Efficiency

Where large amounts of address space are assigned for a purpose that is often satisfied with smaller amounts (e.g. transient connections or virtual server hosting), the RIPE NCC may verify the existing usage before approving additional assignments.

6.8 Renumbering

In general, addresses can be replaced on a one-to-one basis. Valid assignments can be replaced with the same number of addresses if the original assignment criteria are still met. The addresses to be replaced must still be in use. End Users are required to submit a new request if more than half the original assignment is not in use. When the renumbering request exceeds the new LIR’s AW (see Section 7.0) the request needs to be sent to the RIPE NCC for approval.

The RIPE community generally accepts that a period of three months is enough time to migrate a network to new address space. Where the End User wants to keep both assignments for more than three months, an agreement should be obtained from the RIPE NCC for the proposed time frame.

Once a network has been renumbered, the old assignment must be removed from the RIPE Database.

6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers

The organisations applicable under this policy are TLD managers, as recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /24 prefixes per TLD and four /24 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC 4786 (http://www.ietf.org/rfc/rfc4786.txt).

Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".

Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for authoritative TLD or ENUM Tier 0/1 DNS lookup services via anycast any longer.

6.10 Provider Independent IPv4 Assignments for Multihoming

The RIPE NCC will assign additional IPv4 addresses to an End User in order to make the assignment size a multiple of a /24 if an End User demonstrates: 

• the need for Provider Independent (PI) IPv4 address space; and
• the intent to announce this address space for the purpose of multihoming to two or more Autonomous Systems which the End User does not own or control

Cumulatively, no more than 255 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined above.

7.0 Assignment Window

An AW refers to the maximum number of addresses that can be assigned by the LIR without prior approval from the RIPE NCC, either to their own network or to an End User's network. The size of the AW is expressed in CIDR notation.

The AW policy was developed to achieve various levels of support based on the level of experience of the LIR. The RIPE NCC may review assignments made with the LIR's AW to ensure that the LIR is assigning address space according to the RIPE community’s policies. This is important to assure the fair distribution of address space and to meet the goals of aggregation, conservation and registration. Documentation for assignments made with an AW need to contain the same information as in a completed request form found at:

http://www.ripe.net/ripe/docs/request-forms-supporting-notes

All new LIRs start with an AW of zero (0). Their AW will automatically be set to a /21 (2048 addresses) six months after receiving their first allocation. This means that all new LIRs need to request approval before making each assignment until their AW has been raised.

The AW is applied differently depending on whether the assignment is for an End User or for the LIR's infrastructure.

There is no constraint on how often the LIR uses its AW for its own infrastructure. These assignments may not exceed the LIR's AW. This means that an LIR with a /25 AW can make numerous individual /25 assignments to its own network infrastructure without having to send each request to the RIPE NCC. However, where a single assignment would exceed a /25 the LIR would need to request approval for that assignment from the RIPE NCC.

LIRs must specify which assignments to their own infrastructure have used the AW. Such assignments must have a "remarks:" attribute with the value <INFRA-AW> in the inetnum object registered in the RIPE Database. It is important that a separate "remarks:" attribute is used solely for this purpose.

An AW can be applied to an End User network once per 12-month period. This means an LIR or a downstream network operator as the user of a sub-allocation can make more than one assignment to an End User in any 12-month period but the total amount of address space cannot be larger than the LIR's AW. An LIR’s AW is refreshed on the anniversary of an assignment. When an LIR has made several assignments to an organisation over the period of a year their AW for that organisation will be fully restored on the anniversary of the last assignment.

The LIR may only assign additional addresses to the same End User after approval from the RIPE NCC.

AWs are regularly reviewed by RIPE NCC staff. LIRs may approach the RIPE NCC for an evaluation of their AW six months after receiving their first allocation and at any time after that. Please note that LIRs are always welcome to approach the RIPE NCC for a second opinion on requests even if they fall within the LIR's AW.

As the proficiency of the LIR contacts increases, the size of their AW may be raised. This is determined based on:

• correctly completed documentation presented to the RIPE NCC
• good judgment shown in the evaluation of address space requests
• past assignments have been properly registered

An established LIR is responsible for training its new LIR contacts to handle address space assignments according to the policies described in this document and their procedures. Less experienced LIR contacts may make errors both in judgment and procedure. If errors happen repeatedly, the AW of the LIR may be decreased to prevent the LIR from making invalid assignments. The AW may again be increased based on the criteria stated above.

The AW may also be lowered after or during an audit if invalid assignments are noted.

8.0 PA vs. PI Address Space

LIRs are allocated PA address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered.

In contrast, Provider Independent (PI) address space is assigned to End Users directly from the address pools managed directly by the RIPE NCC. PI space cannot be re-assigned or further assigned to other parties. PI address space can only remain assigned to a network as long as the criteria for the original assignment are maintained.  Additionally, all new PI address space assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

As PI addresses are not assigned from LIR-allocated PA address blocks, they cannot be aggregated on the public Internet. Consequently, they are expensive to route, and therefore may not be globally routable. The use of PA address space should always be recommended.

LIRs must make it clear to End Users which type of address space is assigned. Clear contractual arrangements are recommended and are mandatory for PA space.

In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses.

End Users requesting PA space should be given this or a similar warning:

Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses.

End Users requesting PI space should be given this or a similar warning:

Assignment of this IP space is valid as long as the criteria for the original assignment are still met and is also subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

Assignment of address space does NOT imply that this address space will be ROUTABLE ON ANY PART OF THE INTERNET. It is expected that users will have to pay a premium for actual routing of PI addresses as opposed to PA addresses. It may eventually become impossible to get relatively small amounts of PI space routed on most of the Internet. We strongly suggest you contact any prospective service provider for information about issues related to service when using PI addresses.

LIRs will register the type of any assigned address space using the “status:” attribute of the inetnum object in the RIPE Database. The possible values of this attribute are:

• ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider.
• ALLOCATED PI: This address space has been allocated to an LIR or RIR and all assignments made from it are portable. Assignments can be kept as long as the criteria for the original assignment are met. Sub-allocations cannot be made from this type of address space.
• ALLOCATED UNSPECIFIED: This address space has been allocated to an LIR or RIR. Assignments may be PA or PI. This status is intended to document past allocations where assignments of both types exist. It is avoided for new allocations. Sub-allocations cannot be made from this type of address space.
• SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider.
• LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnum should be registered.
• LIR-PARTITIONED PI: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnum should be registered.
• EARLY-REGISTRATION: This is used by the RIPE Database administration when transferring pre-RIR registrations from the ARIN Database. The value can be changed by database users (except for ALLOCATED PA). Only the RIPE Database administrators can create objects with this value.
• NOT-SET: This indicates that the registration was made before the “status:” attributes became mandatory for inetnum objects. The object has not been updated since then. New objects cannot be created with this value. The value can be changed by database users.
• ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR.
• ASSIGNED PI: This address space has been assigned to an End User and can be kept as long as the criteria for the original assignment are met.
• ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD anycast services.

The creation of an inetnum object with a status of “ASSIGNED PA” or “ASSIGNED PI” is only possible if there is no less specific or more specific inetnum object with an “ASSIGNED” status.

Address space without an explicit type in the “status:” attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either “PA” or “PI” as appropriate.

The RIPE NCC no longer allocates PI address space. Consequently, many LIRs do not have PI allocations from which to make PI assignments. If an LIR has an End User that requires PI address space they are able to support them by sending these requests to the RIPE NCC on behalf of the End User. This support includes helping End Users prepare a properly documented request. The RIPE NCC will make PI assignments when justified.

9.0 Record Keeping

All documentation related to an IP address request and sub-allocation or assignment must be maintained by the LIR for future reference. This data is needed for the evaluation of subsequent requests for the same organisation, for audits by the RIR, and for the resolution of any questions that may arise regarding assignments. The records must include:

• The original request
• All supporting documentation
• All related correspondence between the LIR and the End User
• The assignment decision, including the reasons behind any unusual decision
• The details of the person responsible for making the decision

The history of events and the people responsible should be clearly recorded. In order to help the exchange of information, it is strongly recommended that documents are kept electronically and are readily accessible. If requested, any of this information should be made available to the RIPE NCC in English.

10.0 LIR Audit

The RIPE community asked the RIPE NCC to audit LIR operations and ensure consistent and fair implementation of the community’s policies. Details of this activity are described in the RIPE Document "RIPE NCC Audit Activity" found at:

http://www.ripe.net/ripe/docs/audit

11.0 Closing an LIR by the RIPE NCC

The RIPE NCC may close an LIR for any of the following reasons:

• the LIR does not pay money owed to the RIPE NCC
• the LIR cannot be contacted by the RIPE NCC for a significant period of time
• the LIR consistently violates the RIPE community’s policies

The RIPE NCC takes on responsibility for address space held by closing LIRs.

Information on training courses and training material can be found at: http://www.ripe.net/lir-services/training

This policy describes the transfers of IPv4 address space between LIRs of different Regional Internet Registries.

Content

• 1.0 Introduction
• 1.1 Scope
• 1.2 Definitions
• 1.2.1 Originating LIR
• 1.2.2 Originating RIR
• 1.2.3 Originating Policy
• 1.2.4 Destination LIR
• 1.2.5 Destination RIR
• 1.2.6 Destination Policy
• 2.0 Transferring IPv4 address space to the RIPE NCC service region
• 3.0 Transferring IPv4 address space from the RIPE NCC service region
• 4.0 Attribution

1.0 Introduction

Apart from transfers of address space within the service region of the RIPE NCC, this policy defines the framework that outlines what specific rules apply to IPv4 address space transfers in between the different RIR regions. Because of its multi-regional nature and the geographical scope of RIPE policy, this policy also refers to policies for transfer of IPv4 address space as defined by other regions.

1.1 Scope

This document describes the policy for transferring IPv4 address space to or from the RIPE NCC service region. This policy applies only to IPv4 address space and not to any other number resources. This document does not describe any rules about transfers of IPv4 address space within the RIPE NCC service region; instead it refers to those rules to maintain a single set of rules for all IPv4 address space transfers as much as possible.

1.2 Definitions

1.2.1 Originating LIR

The LIR that the IPv4 address space is transferring away from.

1.2.2 Originating RIR

The RIR responsible for the service region in which the Originating LIR is present.

1.2.3 Originating Policy

The current and relevant address policies within the Originating RIR service region at the time of the transfer.

1.2.4 Destination LIR

The LIR that is receiving the transferred IPv4 address space.

1.2.5 Destination RIR

The RIR responsible for the service region in which the Destination LIR is present.

1.2.6 Destination Policy

The current and relevant address policies within the Destination RIR service region at the time of the transfer.

2.0 Transferring IPv4 address space to the RIPE NCC service region

RIPE NCC shall accept any IPv4 address space transferred to the RIPE NCC service region, provided:

1. The Originating LIR and the IPv4 address space transferred are in compliance with the Originating Policy;
2. The Destination LIR and the IPv4 address space transferred are in compliance with the Destination Policy;
3. The Destination LIR is qualified to receive the transferred IPv4 address space as outlined in the policy for transfers within the RIPE NCC service region, as defined in Chapter 5.5 “Transfers of Allocations” of “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”;
4. There must be an inter-RIR IPv4 transfer policy in effect in the Originating RIR service region at the time of transfer.

3.0 Transferring IPv4 address space from the RIPE NCC service region

RIPE NCC shall accept any IPv4 address space transferred from the RIPE NCC service region, provided:

1. The Originating LIR and the IPv4 address space transferred are in compliance with the Originating Policy;
2. The Destination LIR and the IPv4 address space transferred are in compliance with the Destination Policy;
3. Originating LIR and the IPv4 address space transferred are in compliance with the policy for transfers within the RIPE NCC service region, as defined in Chapter 5.5 “Transfers of Allocations” of “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”;
4. There must be an inter-RIR IPv4 transfer policy in effect in the Destination RIR service region at the time of transfer.

4.0 Attribution

This document is developed by the RIPE Community.

The following people actively contributed by making proposal through the RIPE NCC Policy Development Process:

Sandra Brown

Table of contents

Requirements For IPv6 in ICT Equipment

Introduction

To ensure the smooth and cost-efficient uptake of IPv6 across their networks, it is important that governments and large enterprises specify requirements for IPv6 compatibility when seeking tenders for Information and Communication Technology (ICT) equipment and support. This document is intended to provide a Best Current Practice (BCP) and does not specify any standards or policy itself.

It can serve as a template to be used by governments, large enterprises and other organisations when seeking IPv6 support in their tenders or equipment requirements, and can offer guidance on what specifications to ask for. It can also serve as an aid to those people or organisations interested in tendering for government or enterprise contracts.

Be aware that the standards listed here have their origin in various bodies, which operate independently, and that any of these standards might be changed or become replaced with a newer version. You may also need to adjust the recommendations to your specific local needs.

Some parts of this section are loosely based on the NIST/USGv6 profile developed by the US government:

http://www.antd.nist.gov/usgv6/

General Information on How to Use his Document

In this document we suggest two strategies for ensuring IPv6 readiness in tendered equipment and services. These two strategies should not be seen as exclusive, but rather complimentary. The first strategy is based on the IPv6 Ready Logo program, the second on a tailored set of requirements based on your specific situation and needs, and referencing specific IETF documents (Request For Comments or RFCs) or 3GPP standards.

The IPv6 Ready Logo Program

An IPv6 Ready Logo certificate can be obtained for any device that meets the relevant requirements. This is the easiest way for vendors to prove that their equipment fulfills basic IPv6 requirements.

About the IPv6 Ready Logo program:

http://www.ipv6ready.org/

Specific Requirements

Even if you rely on the IPv6 Ready Logo Program, however, a tender initiator should also provide a specific list of requirements, both mandatory and optional. This will mean that you do not exclude vendors that have not certified their equipment under the IPv6 Ready Logo Program, and avoid preferential treatment of specific equipment types or vendors in public tenders.

Requirements specified in this document are defined as either 'Mandatory' or 'Optional'. Some requirements are designated 'Mandatory' if a specific functionality is required. The tender initiator should decide what functionality is required, not the equipment vendor.

Depending on the specific needs of your organisation, you may wish to change requirements designated 'Optional' in this document to 'Mandatory' in your tender request.

How to Specify Requirements

As stated above, the IPv6 Ready Logo Program does not cover all equipment that correctly supports IPv6. This document recommends that the tender initiator specify that eligible equipment be either certified under the IPv6 Ready Program, or be compliant with the appropriate standards listed in the sections below.

The work of projects such as BOUNDv6 can also be an important resource. The goal of BOUNDv6 is to create a permanent multi-vendor network environment connecting approved laboratories for the purpose of testing IPv6-enabled applications and devices in meaningful test scenarios. Tender initiators may find the results useful in preparing their tender request documents.

About BOUNDv6:

http://www.boundv6.org/

Important note for tender initiator:

IPv6 Ready Logo certification covers basic IPv6 requirements and some advanced features, but not all of them. If you require an advanced feature not covered by IPv6 Ready Logo certification, you should specify a list of requirements to cover those specific needs in addition to IPv6 Logo certification.

In the sections below, standards already required under the IPv6 Ready Logo program are marked with an asterisk (*).

Proposed generic text for the tender initiator:

All ICT hardware as subject of this tender must support both the IPv4 and IPv6 protocols. Similar performance must be provided for both protocols in input, output and/or throughput data-flow performance, transmission and processing of packets.

IPv6 support can be verified and certified by the IPv6 Ready Logo certificate.

Any software that communicates via the IP protocol must support both protocol versions (IPv4 and IPv6). The difference must not be noticeable to users.

Equipment that has not been put through the IPv6 Ready testing procedures must comply with the requirements listed below:

[Select an appropriate list of selected mandatory and optional RFCs from the lists below]

Lists of Mandatory and Optional RFC /3GPP Standards Support for Various Hardware and Software

Requirements are divided between hardware equipment and integrator support.

It should be assumed that all IPv4 traffic will eventually migrate to IPv6. All requirements placed on IPv4 traffic capabilities, such as latency, bandwidth and throughput, should also be required for IPv6 traffic.

Definitions and Descriptions of Different Type of Devices

The following definitions will be used for classifying hardware equipment. While some hardware may have overlapping functionality (for instance, a layer-2 switch can act as a layer-3 router or a router may have some firewall capabilities), it is expected that in cases of overlapping functionality, the requirements for each specific device be combined.

Host: A host is a network participant that sends and receives packets but does not forward them on behalf of others.

Layer-2 switch: A layer-2 switch is a device that is primarily used for forwarding packets based on layer-2 attributes. Exchanging layer-2 information with other layer-2 switches is usually part of its function.

Router or layer-3 switch: A router or layer-3 switch is a device that is primarily used for forwarding packets based on layer-3 attributes. Exchanging routing information with other routers or layer-3 switches is usually part of its function.

Network security equipment: Network security equipment refers to devices whose primary function is to permit, deny and/or monitor traffic between interfaces in order to detect or prevent potential malicious activity. These interfaces can also include VPNs (SSL or IPsec). Network security equipment is often also a layer-2 switch or a router/layer-3 switch.

Customer Premises Equipment (CPE): A CPE device is a small office or residential router that is used to connect home users and/or small offices in various configurations. Although a CPE is usually a router, the requirements are different from an enterprise/ISP router/layer-3 switch.

Mobile node: In the context of this document a mobile node is a device that connects via some 3GPP specification (such as 3G, GPRS/UMTS or LTE). In situations where the network logic is being provided solely by a dedicated device (A) connected to another device (B), the specification refers to device A and not to device B. If the protocol logic is distributed (for example, a computer with an external Ethernet interface that performs TCP checksum offloading), the aggregate system is being referred to.

Load balancer: A networking device that distributes workload across multiple computers, servers or other resources, to achieve optimal resource utilisation, maximize throughput, minimize response time and avoid overload.

At the time of publication, all standards and documents listed below are valid; however, all references are subject to revision. Users of this document are therefore encouraged to investigate the possibility of applying the most recent edition of the references listed below.

Lists of Required RFC /3GPP Standards for Different Type of Hardware

ICT hardware equipment are divided into six groups:

• Host: client or server

• Layer-2 switch

• Router or layer-3 switch

• Network security equipment (firewalls, IDS, IPS, etc.)

• CPE

• Mobile node

• Load balancers

We have divided the following requirements into two categories, 'Mandatory' and 'Optional'. Equipment must meet the mandatory standards requirements list. Support for the optional requirements may earn the tender applicant additional points, if so specified by the tender initiator.

Any hardware that does not comply with all of the mandatory standards should be marked as inappropriate by the tender evaluator.

The standards that are part of the IPv6 Ready Logo test procedures, typically performed by accredited labs, are marked with an asterisk *.

Requirements for Host Equipment

Mandatory support:

• IPv6 basic specification [RFC 2460] *

• IPv6 Addressing Architecture basic [RFC 4291] *

• Default Address Selection [RFC 3484(bis)]

• Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]

• ICMPv6 [RFC 4443] *

• DHCPv6 client [RFC 3315] *

• SLAAC [RFC 4862] *

• Path MTU Discovery [RFC 1981] *

• Neighbor Discovery [RFC 4861] *

• Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213]

• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *

• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *

• ISAKMP [RFC 2407, RFC 2408, RFC 2409] *

• If support for mobile IPv6 is required, the device must support “MIPv6” [RFC 3775, RFC 5555] and “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC 4877]

• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]

• DNS message extension mechanism [RFC 2671]

• DNS message size requirements [RFC 3226]

Optional support:

• Revised ICMPv6 [RFC 5095] *

• IPv6 Router Advertisement Options for DNS Configuration [RFC 6106]

• Extended ICMP for multi-part messages [RFC 4884]

• SEND [RFC 3971]

• SLAAC Privacy Extensions [RFC 4941]

• Stateless DHCPv6 [RFC 3736] *

• DS (Traffic class) [RFC 2474, RFC 3140]

• Cryptographically Generated Addresses [RFC 3972]

• IPsec-v3 [RFC 4301, RFC 4303, RFC 4302] *

• SNMP protocol [RFC 3411]

• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]

• Multicast Listener Discovery version 2 [RFC 3810] *

• Packetization Layer Path MTU Discovery [RFC 4821]

Requirements for Consumer-grade Layer 2 Switch Equipment

Mandatory support:

• MLDv2 snooping [RFC 4541]

Optional support (management):

• IPv6 basic specification [RFC 2460] *

• IPv6 Addressing Architecture basic [RFC 4291] *

• Default Address Selection [RFC 3484(revise)]

• ICMPv6 [RFC 4443] *

• SLAAC [RFC 4862] *

• SNMP protocol [RFC 3411]

• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]

Requirements for Enterprise/ISP-grade Layer-2 Switch Equipment

Mandatory support:

• MLDv2 snooping [RFC 4541]

• DHCPv6 filtering [RFC 3315]

• Router Advertisement (RA) filtering [RFC 4862]

• Dynamic "IPv6 Neighbor solicitation/advertisement" inspection [RFC 4861]

• Neighbor Unreachability Detection [NUD, RFC 4861] filtering

• Duplicate Address Detection [DAD, RFC 4429] snooping and filtering

Note that the IETF Source Address Validation Improvements (SAVI) working group is currently working on RFCs that specify a framework for source address validation. Once these RFCs are published, the NUD and DAD filtering references can be changed accordingly.

Optional support (management):

• IPv6 basic specification [RFC 2460] *

• IPv6 Addressing Architecture basic [RFC 4291] *

• Default Address Selection [RFC 3484(bis)]

• ICMPv6 [RFC 4443] *

• SLAAC [RFC 4862] *

• SNMP protocol [RFC 3411]

• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]

• IPv6 Routing Header [RFC 2460, Next Header value 43] filtering *

• Deprecation of Type 0 Routing Headers in IPv6 [RFC 5095]

• UPnP filtering

Requirements for Router or Layer-3 Switch Equipment

Mandatory support:

• IPv6 basic specification [RFC 2460] *

• IPv6 Addressing Architecture basic [RFC 4291] *

• Default Address Selection [RFC 3484(bis)]

• Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]

• ICMPv6 [RFC 4443] *

• SLAAC [RFC 4862] *

• MLDv2 snooping [RFC 4541]

• Router-Alert option [RFC 2711]

• Path MTU Discovery [RFC 1981] *

• Neighbor Discovery [RFC 4861] *

• Classless Inter-domain Routing [RFC 4632]

• If a dynamic interior gateway protocol (IGP) is requested, then RIPng [RFC 2080], OSPF-v3 [RFC 5340] or IS-IS [RFC 5308] must be supported. The contracting authority shall specify the required protocol.

• If OSPF-v3 is requested, the equipment must comply with "Authentication/Confidentiality for OSPF-v3" [RFC 4552]

• If BGP4 protocol is requested, the equipment must comply with RFC 4271, RFC 1772, RFC 4760, RFC 1997, RFC 3392 and RFC 2545

• Support for QoS [RFC 2474, RFC 3140]

• Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213]

• Using IPsec to Secure IPv6-in-IPv4 tunnels [RFC 4891]

• Generic Packet Tunneling and IPv6 [RFC 2473]

• If 6PE is requested, the equipment must support "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)” [RFC 4798]

• Multicast Listener Discovery version 2 [RFC 3810] *

• If mobile IPv6 is requested, the equipment must support MIPv6 [RFC 3775, RFC 5555] and "Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC 4877]

• If the IS-IS routing protocol is requested the equipment must support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120]

• If MPLS functionality (for example, BGP-free core, MPLS TE, MPLS FRR) is requested, the PE-routers and route reflectors must support "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" [RFC 4798]

• If layer-3 VPN functionality is requested, the PE-routers and route reflectors must support "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN" [RFC 4659]

• If MPLS Traffic Engineering is used in combination with IS-IS routing protocol, the equipment must support "M-ISIS: Multi-Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120]

Optional support:

• Revised ICMPv6 [RFC 5095] *

• IPv6 Router Advertisement Options for DNS Configuration [RFC 6106]

• DHCPv6 client / server [RFC 3315] *

• Extended ICMP for multi-part messages [RFC 4884]

• SEND [RFC 3971]

• SLAAC Privacy Extensions [RFC 4941]

• Stateless DHCPv6 [RFC 3736] *

• DHCPv6 PD [RFC 3633] *

• Route Refresh for BGP Capabilities-4 [RFC 2918]

• BGP Extended Communities Attribute [RFC 4360]

• (QOS), Assured Forwarding [RFC 2597]

• (QOS) Expedited Forwarding [RFC 3246]

• Generic Routing Encapsulation [RFC 2784]

• Cryptographically Generated Addresses [RFC 3972]

• ProSafe-v3 (IPSec-v3) [RFC 4301, RFC 4303, RFC 4302] *

• IPSec-v2 [RFC 2401, RFC 2406, RFC 2402] *

• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *

• ISAKMP [RFC 2407, RFC 2408, RFC 2409]

• SNMP protocol [RFC 3411]

• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]

• Mibsam SNMP for IP [RFC 4293] Forwarding [RFC 4292], IPsec [RFC 4807] and DiffServ [RFC 3289]

• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]

• DNS message extension mechanism [RFC 2671]

• DNS message size Requirements [RFC 3226]

• 127-bit IPv6 Prefixes on Inter-Router Links [RFC 6164]

• Packetization Layer Path MTU Discovery [RFC 4821]

Requirements for Network Security Equipment

Equipment in this section is divided into three subgroups:

• Firewall (FW)

• Intrusion prevention device (IPS)

• Application firewall (APFW)

For each mandatory standard the applicable subgroups are specified in parentheses at the end of the line.

Mandatory support:

• IPv6 basic specification [RFC 2460] (FW, IPS, APFW) *

• IPv6 Addressing Architecture basic [RFC 4291] (FW, IPS, APFW)

• Default Address Selection [RFC 3484(bis)] (FW, IPS, APFW)

• ICMPv6 [RFC 4443] (FW, IPS, APFW) *

• SLAAC [RFC 4862] (FW, IPS) *

• Inspecting IPv6-in-IPv4 protocol-41 traffic, Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213] (FW, IPS)

• Router-Alert option [RFC 2711] (FW, IPS)

• Path MTU Discovery [RFC 1981] (FW, IPS, APFW) *

• Neighbor Discovery [RFC 4861] (FW, IPS, APFW) *

• Even if highly discouraged, if the request is for the BGP4 protocol, the equipment must comply with RFC 4271, RFC 1772, RFC 4760 and RFC 2545 (FW, IPS, APFW)

• If the request is for a dynamic internal gateway protocol (IGP), then the required RIPng [RFC 2080], OSPF-v3 [RFC 5340] or IS-IS [RFC 5308] must be supported. The contracting authority shall specify the required protocol. (FW, IPS, APFW)

• If the requested OSPF-v3, the device must support "Authentication/Confidentiality for OSPFv3" [RFC 4552] (FW, IPS, APFW)

• Support for QoS [RFC 2474, RFC 3140] (FW, APFW)

• Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC 4213] (FW)

• Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC 4891] (FW)

A network security device is often placed where a layer-2 switch or a router/layer-3 switch would otherwise be placed. Depending on this placement those requirements should be included.

Functionality and features that are supported over IPv4 should be comparable with the functionalities supported over IPv6. For example, if an intrusion prevention system is capable of operating over IPv4 in layer-2 and layer-3 mode, then it should also offer this functionality over IPv6. Or if a firewall is running in a cluster capable of synchronizing IPv4 sessions between all members of a cluster, then this must also be possible with IPv6 sessions.

Optional support

• Revised ICMPv6 [RFC 5095] *

• IPv6 Router Advertisement Options for DNS Configuration [RFC 6106]

• DHCPv6 client / server [RFC 3315] *

• Extended ICMP for Multipart Messages [RFC 4884]

• SEND [RFC 3971]

• SLAAC Privacy Extensions [RFC 4941]

• Stateless DHCPv6 [RFC 3736] *

• DHCPv6 PD [RFC 3633] *

• BGP Communities Attribute [RFC 1997]

• BGP Capabilities Advertisement WITH-4 [RFC 3392]

• (QOS), Assured Forwarding [RFC 2597]

• (QOS) Expedited Forwarding [RFC 3246]

• Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]

• Cryptographically Generated Addresses [RFC 3972]

• IPsec-v3 [RFC 4301, RFC 4303, RFC 4302] *

• OSPF-v3 [RFC 5340]

• Authentication / Confidentiality for OSPF-v3 [RFC 4552]

• Generic Packet Tunneling and IPv6 [RFC 2473]

• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *

• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *

• ISAKMP [RFC 2407, RFC 2408, RFC 2409]

• SNMP protocol [RFC 3411]

• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]

• DNS protocol extensions for incorporating IPv6 DNS resource records INTO [RFC 3596]

• DNS message extension mechanism [RFC 2671]

• DNS message size requirements [RFC 3226]

• Using IPSec to Secure IPv6-in-IPv4 Tunnels [RFC 4891]

• Multicast Listener Discovery version 2 [RFC 3810] *

• MLDv2 snooping [RFC 4541] (when in L2 or passthrough mode) *

• Packetization Layer Path MTU Discovery [RFC 4821]

Requirements for CPE Equipment

Mandatory support:

• RFC 6204 (Basic Requirements for IPv6 Customer Edge Routers) *

• If this specification is used for business class CPE, then IPsec-v2 [RFC 2401, RFC 2406, RFC 2402], IKE version 2 (IKEv2) [RFC 4306, RFC 4718] and ISAKMP [RFC 2407, RFC 2408, RFC 2409] must be supported in addition to RFC 6204 requirements

Optional support:

• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *

• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *

• ISAKMP [RFC 2407, RFC 2408, RFC 2409]

• If support for mobile IPv6 is required, the device needs to comply to “MIPv6” [RFC 3775, RFC 5555] and “Mobile IPv6 Operation With IKEv2 and the Revised IPsec Architecture” [RFC 4877]

• Revised ICMPv6 [RFC 5095] *

• Extended ICMP for multi-part messages [RFC 4884]

• SEND [RFC 3971]

• SLAAC Privacy Extensions [RFC 4941]

• DS (Traffic class) [RFC 2474, RFC 3140]

• Cryptographically Generated Addresses [RFC 3972]

• IPsec-v3 [RFC 4301, RFC 4303, RFC 4302] *

• SNMP protocol [RFC 3411]

• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]

• Multicast Listener Discovery version 2 [RFC 3810] *

• Packetization Layer Path MTU Discovery [RFC 4821]

• IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC 5969]

• Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [RFC 6333] If support this then also must support Dynamic Host Configuration protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite [RFC 6334]

• The A+P Approach to the IPv4 Address Shortage [I-D.ymbk-aplusp]

Requirements for Mobile Nodes

Mandatory support:

• IPv6 basic specification [RFC 2460] *

• IPv6 Node Requirements [RFC 4294] (errata for RFC 2460)

• Neighbor Discovery for IPv6 [RFC 4861] (obsoletes RFC 2461) *

• IPv6 Stateless Address Autoconfiguration [RFC 4862] (obsoletes RFC 2462) *

• IPv6 Addressing Architecture basic [RFC 4291] *

• ICMPv6 [RFC 4443] *

• IPv6 over PPP [RFC 2472]

• Multicast Listener Discovery [RFC 2710]

• IPv6 Router Alert Option [RFC 2711]

• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]

• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *

• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *

• ISAKMP [RFC 2407, RFC 2408, RFC 2409] *

Optional support:

• Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC 4941]

• Privacy Extensions for Address Configuration in IPv6 [RFC 3041]

• Path MTU Discovery for IPv6 [RFC 1981] *

• Generic Packet Tunneling for IPv6 [RFC 2473]

• DHCPv6 [RFC 3315] *

• DHCPv6 option for SIP servers [RFC 3319]

• Default Address Selection [RFC 3484(bis)]

References:

3GPP

• Internetworking Between Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) [3GPP TS 29.061]

• GPRS Service Description [3GPP TS 23.060]

• Signalling flows for IP multimedia Call control based on SIP and SDP [3GPP TS 24.228]

• IP multimedia call control protocol based on SIP and SDP [3GPP TS 24.229]

• IP Based Multimedia Framework [3GPP TS 22.941]

• Architectural Requirements [3GPP TS 23.221]

• Packet domain; Mobile Stations (MS) Supporting Packet Switching Service [3GPP TS 27.060]

• IPv6 migration guidelines [3GPP TR 23.975]

3GPP2

• IP Network Architecture Model for cdma2000 Spread Spectrum Systems [3GPP2 S.R0037-0]

• Wireless IP Network Standard [3GPP2 P.S0001-B]

IETF

• IPv6 for Some Second and Third Generation Cellular Hosts [RFC 3316]

• Recommendations for IPv6 in 3GPP Standards [RFC 3314]

Requirements for Load Balancers

A load balancer distributes incoming requests and/or connections from clients to multiple servers. Load balancers will have to support several combinations of IPv4 and IPv6 connections:

• Load balancing IPv6 clients to IPv6 servers (6-to-6) must be supported

• Load balancing IPv6 clients to IPv4 servers (6-to-4) must be supported

• Load balancing IPv4 clients to IPv4 servers (4-to-4) should be supported

• Load balancing IPv4 clients to IPv6 servers (4-to-6) should be supported

• Load balancing a single external/virtual IPv4 address to a mixed set of IPv4 and IPv6 servers should be supported

• Load balancing a single external/virtual IPv6 address to a mixed set of IPv4 and IPv6 servers should be supported

If a load balancer provides layer-7 (application level / reverse proxy, defined as ‘surrogate’ in section 2.2 of RFC 3040) load balancing then support for the X-forwarded-for (or equivalent) header in HTTP must be provided in order to make the source IP address of the client visible to the servers.

Mandatory support:

• IPv6 basic specification [RFC 2460] *

• IPv6 Addressing Architecture basic [RFC 4291] *

• Default Address Selection [RFC 3484(bis)]

• Unique Local IPv6 Unicast Addresses (ULA) [RFC 4193]

• ICMPv6 [RFC 4443] *

• Path MTU Discovery [RFC 1981] *

• Neighbor Discovery [RFC 4861] *

• ISAKMP [RFC 2407, RFC 2408, RFC 2409] *

• DNS protocol extensions for incorporating IPv6 DNS resource records [RFC 3596]

• DNS message extension mechanism [RFC 2671]

• DNS message size requirements [RFC 3226]

Optional support:

• Revised ICMPv6 [RFC 5095] *

• IPv6 Router Advertisement Options for DNS Configuration [RFC 6106]

• Extended ICMP for multi-part messages [RFC 4884]

• SEND [RFC 3971]

• DS (Traffic class) [RFC 2474, RFC 3140]

• Cryptographically Generated Addresses [RFC 3972]

• IPsec-v2 [RFC 2401, RFC 2406, RFC 2402] *

• IKE version 2 (IKEv2) [RFC 4306, RFC 4718] *

• IPsec-v3 [RFC 4301, RFC 4303, RFC 4302] *

• SNMP protocol [RFC 3411]

• SNMP capabilities [RFC 3412, RFC 3413, RFC 3414]

• Multicast Listener Discovery version 2 [RFC 3810] *

• Packetization Layer Path MTU Discovery [RFC 4821]

• NAT64/DNS64 [RFC 6146, RFC 6147]

Requirements for IPv6 Support in Software

All software must support IPv4 and IPv6 and be able to communicate over IPv4-only, IPv6-only and dual-stack networks. If software includes network parameters in its local or remote server settings, it should also support configuration of IPv6 parameters.

All features that are offered over IPv4 must also be available over IPv6. The user should not experience any noticeable difference when software is communicating over IPv4 or IPv6, unless this is providing explicit benefit to the user.

It is not recommended that any address literals be used in software code, as described in “Default Address Selection for Internet Protocol version 6” [RFC 3484].

Skill Requirements of the Systems Integrator

Vendors and resellers that offer system integration services must have at least three employees who have valid certificates of competency from the equipment manufacturers for the equipment that is sold as part of the tender. Additionally, these employees should have general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security, as indicated by certification from independent education providers (not simply the equipment manufacturers). Such knowledge may be awarded extra points in the tender process.

If it becomes obvious during the equipment installation and integration that the integrator’s knowledge, competence and experience is not sufficient to successfully install and configure the equipment to establish normal IPv4 and IPv6 communication with the network, the agreement shall be canceled and become null and void. The definition of proper integration, timing and degree of disruption of the network during the assembly should be a matter of agreement between the client and systems integrator.

Declaration of IPv6 Competence

Tender initiators should require a declaration of technical IPv6 competence from the equipment supplier or integrator. IPv6 knowledge and experience is required to assure proper installation and integration of IPv6 in the ICT environment.

This declaration should state:

• That the equipment supplier or system integrator have a sufficient number of people employed to perform the offered services;

• That those employees are professionally trained for their work (including design, construction and integration of ICT equipment in both IPv4 and IPv6 networks and environments);

• That the quality of offered services meets the requirements laid out in the tender documents, in relation to both IPv4 and IPv6.

The ability to legally enforce such declarations will vary depending on local legislation. Therefore translators and tender initiators should get legal advise on the exact wording for these requirements.

Additional Information: Working With Your ISP

This document specifies how to request IPv6 functionality and compliance when buying ICT equipment, but equipment itself, even if installed and implemented correctly, is not enough. You still need to communicate with the Internet, which usually means connecting to one or multiple Internet Service Providers (ISPs).

To ensure that your ISP(s) offers you the appropriate level of IPv6 service, we suggest asking them the following questions, compiled specifically for enterprise and very large customers:
http://go6.si/service-provider-ipv6/

Acknowledgments

The initial version of this document was prepared by the Go6 Expert Council and the Slovenian IPv6 Working Group.

The authors would like to thank all involved in creation and modification of previous versions of this document. First of all we would like to thank Janez Sterle, Urban Kunc, Matjaz Straus, Simeon Lisec, Davor Sostaric and Matjaz Lenassi from the Go6 Expert Council for their enthusiastic governance of this document. We recognise the work done in the Slovenian IPv6 Working Group for their review and useful input; special recognition goes to Ivan Pepelnjak, Andrej Kobal and Ragnar Us for their efforts and work done on the document. Thanks also to the Co-chairs of RIPE IPv6 Working Group, David Kessens, Shane Kerr and Marco Hogewoning, for their support and encouragement. We would also like to thank Patrik Fältström, Torbjörn Eklöv, Randy Bush, Matsuzaki Yoshinobu, Ides Vanneuville, Olaf Maennel, Ole Trøan, Teemu Savolainen and participants in the RIPE IPv6 Working Group (Joao Damas, S.P.Zeidler, Gert Döring and others) for their input, comments and review of the document. Last, but not least we would like to thank Chris Buckridge from RIPE NCC for correcting our grammar and wording in this document. And everybody else that contributed to this work.

The authors of this current document would like to thank RIPE IPv6 WG and its Co-chairs for all support end encouragement in developing a collow-up version of the document. Special thanks goes to Ole Trøan, editor of RFC 6204 for his help in the CPE section and also suggesting other changes across the document. Thanks to Marco Hogewoning, Ivan Pepelnjak and S.P. Zeidler for great input in ideas how to improve the document's structure and content, Timothy Winters and Erica Johnson (both IPv6 Ready Logo committee, UNH) for help with marking the RFCs on which they base their tests and constructive suggestions. Thanks also to Yannis Nikolopoulos and Frits Nolet.

Document ID: ripe-TBA
Date: TBA

This document relates to RIPE policy proposal 2010-01 - Temporary Internet Number Assignment Policies.

Abstract

This document outlines policies for temporary direct assignments of IPv4/IPv6 address space and Autonomous System (AS) Numbers in the RIPE NCC service region.

Contents

1.0 Introduction
2.0 Internet Registry Number Resource Pool Reservation
2.1 RIPE NCC Assignment Procedures
3.0 End User Term and Limitations
3.1 Assignment Time Limits
3.2 Realistic Expectations
3.3 IPv4 Address Utilisation Rate
3.4 Compliance with Other RIPE NCC Assignment Policies

1.0 Introduction

This policy allows the RIPE NCC to assign number resources for temporary direct assignment purposes and, for this purpose, to reserve pools of IPv4/IPv6 addresses, AS Numbers and any other numbers for which it acts as Regional Internet Registry (RIR).

2.0 Internet Registry Number Resource Pool Reservation

The RIPE NCC is authorised to reserve pools of IPv4 addresses, IPv6 addresses, 16-bit AS Numbers and 32-bit AS Numbers for the purpose of direct assignment under this policy.

2.1 RIPE NCC Assignment Procedures

The RIPE NCC may assign number resources to End Users on a temporary deployment basis for a specific time-limited purpose. Examples of specific purposes include, but are not limited to, academic research and experimental purposes, conferences and other types of events which require network connectivity for short periods of time, and other strictly time-limited projects such as deployment tests for new Internet services and technologies.

Resources issued for temporary assignments must not be used for purposes other than those specified in the application, and they may be returned to the RIPE NCC at any time during the approved assignment period. The number resources will be automatically de-registered and returned to the appropriate reservation pool at the end of the approved assignment period.

The RIPE NCC will register the issued number resources in the RIPE Database for the duration of the assignment and will note the start and end dates of the assignment period for each database object.

3.0 End User Terms and Limitations

3.1 Assignment Time Limits

Depending on the specified purpose of the assignment request, different upper time limits may apply. For conferences and other events of short, fixed duration, the maximum assignment time period will be seven calendar days more than the scheduled length of the conference/event but no longer than one month in any case.

For longer term projects and research purposes, the number resources may be issued on a temporary basis for a period of up to six calendar months, or two calendar weeks longer than the expected life of the project/research/experiment, whichever is shorter.

In the case where an End User requires number resources for research purposes, and where the research project details are made public upon registration of the number resources by the RIPE NCC, and where the End User commits to making public the results of their research project free of charge and free from disclosure constraints, then the requested number resources may be issued for a period of up to one calendar year.

At the RIPE NCC’s discretion renewal of the registration of the resources may be possible in exceptional circumstances on receipt of a new request that details continuation of the End User's requirements during the extended period. Should this request be denied by the RIPE NCC, an appeal may be made using the RIPE NCC Conflict Arbitration Procedure.

3.2 Realistic Expectations

Assignments may only be based on realistic expectations recorded on the request form. The RIPE NCC may require the End User to provide documentation or other evidence supporting the End User's assignment request.

3.3 IPv4 Address Utilisation Rates

For short-lived assignments of less than one month, the immediate IPv4 address utilisation rate should be no less than 50% of the total temporary assignment. For all other temporary assignments, immediate IPv4 address utilisation should be no less than 25%, and utilisation after one month should be no less than 50%.

3.4 Compliance with Other RIPE NCC Assignment Policies

In all respects not covered by this document, temporary assignment policies are subject to all other RIPE NCC policies regarding standard direct assignment of number resources.

How to read this draft document:

This document relates to Version 2.0 of RIPE policy proposal 2010-01 Temporary Internet Number Assignment Policies. If approved, it will modify ripe-496. To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.

We indicate additions to the document like this:

We indicate changes to existing text in the document like this:

All other text in the document will not be replaced.

Abstract

This document describes the policies for the assignment of globally unique Autonomous System (AS) Numbers within the RIPE NCC service region. These policies are developed by the RIPE community following the RIPE Policy Development Process.

Contents

1.0 Definition
2.0 Assignment Criteria

1.0 Definition

An Autonomous System (AS) is a group of IP networks run by one or more network operators with a single clearly defined routing policy. When exchanging exterior routing information, each AS is identified by a unique number. Exterior routing protocols such as BGP, described in RFC1771, "A Border Gateway Protocol 4 (BGP-4)", are used to exchange routing information between Autonomous Systems. An AS will normally use some interior gateway protocol to exchange routing information on its internal networks.

2.0 Assignment Criteria

In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930.

A network must be multihomed in order to qualify for an AS Number.
When requesting an AS Number the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database.

The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”.

How to read this draft document:

This document relates to RIPE policy proposal 2010-01 - Temporary Internet Number Assignment Policies. If approved, it will replace ripe-481. To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.

We indicate additions to the document like this:

We indicate changes to existing text in the document like this:

All other text in the document will not be replaced.

Abstract

This document defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. It was developed through joint discussions among the APNIC, ARIN and RIPE communities.

Contents

1. Introduction
1.1. Overview
2. Definitions
2.1. Internet Registry (IR)
2.2. Regional Internet Registry (RIR)
2.3. National Internet Registry (NIR)
2.4. Local Internet Registry (LIR)
2.5. Allocate
2.6. Assign
2.7. Utilisation
2.8. HD-Ratio
2.9. End Site
3. Goals of IPv6 address space management
3.1. Goals
3.2. Uniqueness
3.3. Registration
3.4. Aggregation
3.5. Conservation
3.6. Fairness
3.7. Minimised Overhead
3.8. Conflict of Goals
4. IPv6 Policy Principles
4.1. Address space not to be considered property
4.2. Routability not guaranteed
4.3. Minimum Allocation
4.4. Consideration of IPv4 Infrastructure
5. Policies for allocations and assignments
5.1. Initial allocation
5.1.1. Initial allocation criteria
5.1.2. Initial allocation size
5.2. Subsequent allocation
5.2.1. Subsequent allocation criteria
5.2.2. Applied HD-Ratio
5.2.3. Subsequent Allocation Size
5.3. LIR-to-ISP allocation
5.4. Assignment
5.4.1. Assignment address space size
5.4.2. Assignments shorter than a /48 to a single End Site
5.4.3. Assignment to operator's infrastructure
5.5. Registration
5.6. Reverse lookup
5.7. Existing IPv6 address space holders

1. Introduction

1.1. Overview

This document describes policies for the allocation and assignment of globally unique Internet Protocol version 6 (IPv6) address space.

[RFC 4291] designates 2000::/3 to be global unicast address space that the Internet Assigned Numbers Authority (IANA) may allocate to the RIRs. In accordance with [RFC 4291], IANA allocated initial ranges of global unicast IPv6 address space from the 2000::/3 address block to the RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies. All bits to the left of /64 are in scope.

This policy is subject to future review and potential revision, subject to continuing experience in the administration of IPv6.

2. Definitions

[Note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.]

The following terms and their definitions are of particular importance to the understanding of the goals, environment and policies described in this document.

Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below.

2.1. Internet Registry (IR)

An Internet Registry is an organisation that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above.

2.2. Regional Internet Registry (RIR)

Regional Internet Registries are established and authorised by respective regional communities and recognised by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions.

2.3. National Internet Registry (NIR)

A National Internet Registry primarily allocates address space to its members or constituents, which are generally LIRs organised at a national level. NIRs exist mostly in the Asia Pacific region.

2.4. Local Internet Registry (LIR)

A Local Internet Registry is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs.

2.5. Allocate

To “allocate” means to distribute address space to IRs for the purpose of subsequent distribution by them.

2.6. Assign

To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.

2.7. Utilisation

The actual usage of addresses within each assignment may be low when compared to IPv4 assignments. In IPv6, "utilisation" is only measured in terms of the bits to the left of the efficiency measurement unit (/56). In other words, "utilisation" effectively refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual End Site assignments.

Throughout this document, the term "utilisation" refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual subnets within those End Sites.

2.8. HD-Ratio

The HD-Ratio is a way of measuring the efficiency of address assignment [RFC 3194 ]. It is an adaptation of the H-Ratio originally defined in [RFC1715 ] and is expressed as follows:

   
       Log (number of allocated objects) 
HD = ---------------------------------------------- 
       Log (maximum number of allocatable objects) 
        

where (in the case of this document) the objects are IPv6 site addresses assigned from an IPv6 prefix of a given size.

2.9. End Site

An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:

• that service provider assigning address space to the End User

• that service provider providing transit service for the End User to other sites

• that service provider carrying the End User's traffic

• that service provider advertising an aggregate prefix route that contains the End User's assignment

3. Goals of IPv6 address space management

3.1. Goals

IPv6 address space is a public resource that must be managed in a prudent manner with regards to the long-term interests of the Internet. Responsible address space management involves balancing a set of sometimes competing goals. The following are the goals relevant to IPv6 address policy.

3.2. Uniqueness

Every assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.

3.3. Registration

Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users.

The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws.

3.4. Aggregation

Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs and to limit the expansion of Internet routing tables.

This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.

IPv6 address policies should seek to avoid fragmentation of address ranges.

Further, RIRs should apply practices that maximise the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation.

3.5. Conservation

Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.

3.6. Fairness

All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size, or any other factor.

3.7. Minimised overhead

It is desirable to minimise the overhead associated with obtaining address space. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions.

3.8. Conflict of goals

The goals described above will often conflict with each other, or with the needs of individual IRs or End Users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole.

In IPv6 address policy, the goal of aggregation is considered to be the most important.

4. IPv6 Policy Principles

To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below.

4.1. Address space not to be considered property

It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.

The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license.

RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment.

4.2. Routability not guaranteed

There is no guarantee that any address allocation or assignment will be globally routable.

However, RIRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability.

4.3. Minimum allocation

The minimum allocation size for IPv6 address space is /32.

4.4. Consideration of IPv4 infrastructure

Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure.

5. Policies for Allocations and Assignments

5.1. Initial allocation

5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an organisation must:

a) be an LIR;
b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.

5.1.2. Initial allocation size

Organisations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32.

Organisations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure.

5.2. Subsequent allocation

Organisations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.

5.2.1. Subsequent allocation criteria

Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below.

5.2.2. Applied HD-Ratio

The HD-Ratio value of 0.94 is adopted as indicating an acceptable address utilisation for justifying the allocation of additional address space. Appendix A provides a table showing the number of assignments that are necessary to achieve an acceptable utilisation value for a given address block size.

5.2.3. Subsequent allocation size

When an organisation has achieved an acceptable utilisation for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.

If an organisation needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement.

5.3. LIR-to-ISP allocation

There is no specific policy for an organisation (LIR) to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation of the total address block allocated to the LIR. However, all /48 assignments to End Sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.

5.4. Assignment

LIRs must make IPv6 assignments in accordance with the following provisions.

5.4.1. Assignment address space size

End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).

5.4.2. Assignment of multiple /48s to a single End Site

When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level.

Note: There is no experience at the present time with the assignment of multiple network prefixes to the same End Site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.

5.4.3. Assignment to operator's infrastructure

An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.

5.5. Registration

When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate. (Information registered by an RIR/NIR may be replaced by a distributed database for registering address management information in future). Information is registered at the granularity of End Site assignments. When more than a /48 is assigned to an organisation, the assigning organisation is responsible for ensuring that the address space is registered in an RIR/NIR database.

RIR/NIRs will use registered data to calculate the HD-Ratio at the time of application for subsequent allocation and to check for changes in assignments over time.

IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration.

5.6. Reverse lookup

When an RIR/NIR delegates IPv6 address space to an organisation, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organisation should properly manage its reverse lookup zone. When making an address assignment, the organisation must delegate to an assignee organisation, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.

5.7. Existing IPv6 address space holders

Organisations that received /35 IPv6 allocations under the previous IPv6 address policy are immediately entitled to have their allocation expanded to a /32 address block without providing justification so long as they satisfy the criteria in Section 5.1.1.

The /32 address block will contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the organisation. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document.

How to read this draft document:

This document relates to Version 2.0 of RIPE policy proposal 2010-01 Temporary Internet Number Assignment Policies. If approved, it will modify ripe-492. To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.

We indicate additions to the document like this:

We indicate changes to existing text in the document like this:

All other text in the document will not be replaced.

Abstract

This document describes the RIPE community's current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region.

Information on the Address Policy WG is available at:
http://www.ripe.net/ripe/groups/wg/ap

Contents

1.0 Introduction
1.1 Scope
2.0 IPv4 Address Space
3.0 Goals of the Internet Registry System
3.1 Confidentiality
3.2 Language
4.0 Registration Requirements
5.0 Policies and Guidelines for Allocations
5.1 First Allocation
5.2 Slow-start Mechanism
5.3 Additional Allocations
5.4 Sub-allocations
5.5 Transfers of Allocations
6.0 Policies and Guidelines for Assignments
6.1 Documentation for Assignments
6.2 Network Infrastructure and End User Networks
6.3 Utilisation Rates
6.4 Reservations Not Supported
6.5 Administrative Ease
6.6 Validity of an Assignment
6.7 Efficiency
6.8 Renumbering
6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers
7.0 Assignment Window

1.0 Introduction

The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. The distribution of IP space follows the hierarchical scheme described in the document "Internet Registry System".

1.1 Scope

This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC. These policies must be implemented by all RIPE NCC member LIRs.

This document does not describe policies related to AS Numbers, IPv6, Multicast, or private address space. Nor does it describe address distribution policies used by other RIRs. The RIPE community's policies for ASN assignment and IPv6 are published in the RIPE Document Store at:
http://www.ripe.net/ripe/docs/policy

2.0 IPv4 Address Space

For the purposes of this document, IP addresses are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses:

1. Public IP addresses are assigned to be globally unique according to the goals described in Section 3 of this document.

2. Some address ranges are set aside for the operation of private IP networks. Anyone may use these addresses in their private networks without registration or co-ordination. Hosts using these addresses cannot directly be reached from the Internet. Such connectivity is enabled by using the technique known as Network Address Translation (NAT). Private addresses restrict a network so that its hosts only have partial Internet connectivity. Where full Internet connectivity is needed, unique, public addresses should be used.
   
   For a detailed description of "Address Allocation for Private Internets" and the actual ranges of addresses set aside for that purpose, please refer to RFC1918 found at: ftp://ftp.ripe.net/rfc/rfc1918.txt
   
   For information on the "Architectural Implications of NAT", please refer to RFC2993, found at: ftp://ftp.ripe.net/rfc/rfc2993.txt

3. Some address ranges are reserved for special use purposes. These are described in RFC3330 and are beyond the scope of this document. RFC3330 can be found at: ftp://ftp.ripe.net/rfc/rfc3330.txt

3.0 Goals of the Internet Registry System

Public IPv4 address assignments should be made with the following goals in mind:

1. Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified.

2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.

3. Conservation: Public IPv4 address space must be fairly distributed to the End Users operating networks. To maximise the lifetime of the public IPv4 address space, addresses must be distributed according to need, and stockpiling must be prevented.

4. Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.

3.1 Confidentiality

Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality.

3.2 Language

Please note that all communication with the RIPE NCC must be in English.

4.0 Registration Requirements

All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.

Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).

5.0 Policies and Guidelines for Allocations

An allocation is a block of IPv4 addresses from which assignments are taken.

The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of up to 12 months.

Starting on 1 July 2010, a gradual reduction in the allocation period will be applied as follows:

As of 1 July 2010, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to nine months.

As of 1 January 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to six months.

As of 1 July 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to three months.

All LIRs receiving address space from the RIPE NCC must adopt a set of policies that are consistent with the policies formulated by the RIPE community and described in this document.

5.1 First Allocation

The RIPE NCC's minimum allocation size is /21.

Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC"

Members can receive an initial IPv4 allocation when they have demonstrated a need for IPv4 address space.

5.2 Slow-start Mechanism

The slow-start mechanism was put into place to ensure a consistent and fair policy for all LIRs with respect to allocations.

Address space is allocated to LIRs at the rate that the addresses are sub-allocated and assigned by the LIRs. An allocation larger than the minimum size can be made if a need is demonstrated. The size of future allocations is based on the usage rate of previous allocation(s).

5.3 Additional Allocations

An LIR may receive an additional allocation when about eighty percent (80%) of all the address space currently allocated to it is used in valid assignments or sub-allocations. A new allocation can be made if a single assignment or sub-allocation requires a larger set of addresses than can be satisfied with the address space currently held by the LIR.

Reservations are not considered valid assignments or sub-allocations. It may be useful for internal aggregation to keep some address space free for future growth in addition to the actual assignment. However, the LIR must be aware that these internal reservations are not counted as valid usage. The space must be sub-allocated or assigned before the LIR can request another allocation.

To obtain a new allocation, an LIR should submit a request to the RIPE NCC using the "IPv4 Additional Allocation Request Form" available from the RIPE Document Store at:
http://www.ripe.net/ripe/docs/add-allocation.html

Additional address space will only be allocated after the information supplied with the request has been verified and a new allocation deemed necessary.

The RIPE NCC will do its best to allocate contiguous address space in order to support aggregation. This cannot be guaranteed as it depends on factors outside the RIPE NCC's influence (e.g. the number of new LIRs and the time needed to utilise the allocation).

5.4 Sub-allocations

Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 9.0.

LIRs wishing to convert their allocations to PA status should contact the RIPE NCC by email at lir-help _at_ ripe _dot_ net.

The minimum size of a sub-allocation is /24. This is the smallest prefix length that can be reverse delegated and allows for a reasonable number of small assignments to be made by a downstream network operator.

An LIR may sub-allocate up to an IPv4 /20 (4096 addresses) to a downstream network operator every twelve months.

LIRs may make sub-allocations to multiple downstream network operators.

However, downstream network operators may receive sub-allocations totalling more than a /20 from more than one LIR.

The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations.

The RIPE NCC considers sub-allocated space as "used" when evaluating requests from the LIR for an additional IPv4 allocation. LIRs are still required to demonstrate about 80% usage for all their allocations. Where an LIR has made many sub-allocations with little assigned within them, the RIPE NCC will ask the LIR to justify the reasons for the sub-allocations.

LIRs should note that evaluating a request for an allocation is different from evaluating a request for an assignment. With assignments, the evaluator can see the network plans for a single organisation. With allocations, the evaluator is often presented with sales and marketing plans. The addressing requirements of individual organisations cannot be examined.

It is recommended that LIRs make use of a slow-start mechanism when making a sub-allocation for a downstream network operator. There are two main advantages to this: the LIR can ensure that the address space it sub-allocates is used efficiently; also the LIR can determine the ability of the downstream organisation to operate within the policies set by the RIPE community.

Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator.

5.5 Transfers of Allocations

Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA. Such address space must not contain any block that is assigned to an End User.

Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. An LIR may only receive a transferred allocation after their need is evaluated and approved by the RIPE NCC, following the policies set for receiving further allocations within RIPE region (see the Section 5.3 Additional Allocations of this document).

Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.

LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.

The RIPE NCC will record the change of allocation after the transfer. Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC until the transfer of address space to another LIR is completed or the address space is returned. The LIR must ensure that all policies are applied.

Re-allocated blocks will be signed to establish the current allocation owner.

Re-allocated blocks are no different from the allocations made directly by the RIPE NCC and so they must be used by the receiving LIR according to the policies described in this document.

6.0 Policies and Guidelines for Assignments

Conservation and aggregation are often conflicting goals. When the Internet Registry System goals are in conflict with the interests of individual End Users or service providers, careful analysis and judgement is necessary to find an appropriate compromise. The rules and guidelines in this document are intended to help LIRs and End Users in their search for equitable compromises.

The End Users must be assigned with enough address space to meet their needs for a period of up to 12 months.

Starting on 1 July 2010, a gradual reduction in the assignment period will be applied as follows:

As of 1 July 2010, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to nine months.

As of 1 January 2011, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to six months.

As of 1 July 2011, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to three months.

Please note that LIRs must request approval from the RIPE NCC for assignments that are larger than the LIR's AW (Section 7.0). LIRs are always welcome to approach the RIPE NCC for a second opinion on requests even if they fall within the LIR's AW.

6.1 Documentation for Assignments

In order to determine the address space requirements for a network, relevant information must be gathered. The details needed for justification of each End User organisation's assignments include the addressing requirements, network infrastructure and future plans. The current address space usage of the organisation should also be determined to ensure that an existing assignment is not duplicated.

This information is essential in making the appropriate assignment decisions. Balancing the overall goals of the Internet Registry System (Section 3.0) with the requirements of the network in question is needed for every network. The level of detail is dependent on the complexity of the network. The LIR must ensure that the necessary information is complete before making an assignment.

The RIPE NCC provides forms for gathering the required information. The information requested in the forms must be collected by the LIR. LIRs may use these forms for their customers' requests or develop their own forms. Local forms can be used if they record all the required data. This is very important when an LIR makes assignments using its AW.

If a request needs to be approved by the RIPE NCC or if information is required in the event of an audit, the information must be submitted on the version of the request form in place at the time of the assignment. The current versions of all request forms can be found at:
http://www.ripe.net/ripe/docs/request-forms-supporting-notes

6.2 Network Infrastructure and End User Networks

IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users.

An explanation of how to register objects in the database can be found in the "RIPE Database User Manual: Getting Started" found at:
http://www.ripe.net/ripe/docs/db-start.html

6.3 Utilisation Rates

The utilisation rate of an assignment must be such that at least 50% of the total space shall have been utilised halfway through the assignment period applied at the time of the assignment.

Assignments may only be based on realistic expectations recorded in the documentation.

6.4 Reservations Not Supported

End Users are not permitted to reserve address space based on long-term plans. This violates the goal of conservation and fragments the address space when initial forecasts are not met. Evaluation of IP address space requests must be based on a demonstrated need. Unused, or inefficiently used address space assigned in the past should be used to meet the current request, or returned. Once an organisation has used its assigned address space, it can request additional address space based on an updated estimate of growth in its network.

6.5 Administrative Ease

The current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. Examples of this include, but are not limited to, ease of billing administration and network management.

6.6 Validity of an Assignment

All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid.

For these reasons it is important that LIRs make sure that assignments approved by the RIPE NCC are properly registered in the database. The inetnum object or objects for approved assignments must use the netname(s) approved by the RIPE NCC and not be larger than the approved size. Additionally, the date in the first "changed:" attribute must not be earlier than the date of the approval message from the RIPE NCC.

The RIPE NCC reviews assignments made by LIRs when evaluating requests for additional allocations (see 5.3). It also runs consistency checks as part of the auditing activity requested by the community as described in the RIPE document "RIPE NCC Audit Activity" found at:
http://www.ripe.net/ripe/docs/audit.html

6.7 Efficiency

Where large amounts of address space are assigned for a purpose that is often satisfied with smaller amounts (e.g. transient connections or virtual server hosting), the RIPE NCC may verify the existing usage before approving additional assignments.

6.8 Renumbering

In general, addresses can be replaced on a one-to-one basis. Valid assignments can be replaced with the same number of addresses if the original assignment criteria are still met. The addresses to be replaced must still be in use. End Users are required to submit a new request if more than half the original assignment is not in use. When the renumbering request exceeds the new LIR's AW (see Section 7.0) the request needs to be sent to the RIPE NCC for approval.

The RIPE community generally accepts that a period of three months is enough time to migrate a network to new address space. Where the End User wants to keep both assignments for more than three months, an agreement should be obtained from the RIPE NCC for the proposed time frame.

Once a network has been renumbered, the old assignment must be removed from the RIPE Database.

6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers

The organisations applicable under this policy are TLD managers, as recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /24 prefixes per TLD and four /24 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/RFC4786 (http://www.ietf.org/rfc/rfc4786.txt).

Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".

Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for authoritative TLD or ENUM Tier 0/1 DNS lookup services via anycast any longer.

Overview

There is a need for secure communication between the RIPE NCC and its members. This document presents an overview of the current communication system, and a new approach based on X.509 PKI (Public Key Infrastructure) technology and standards that will make interaction with the services provided by the RIPE NCC to its members more convenient and secure. Finally, the phases necessary to implement the system are described.

Table of Contents

Introduction

1.0 Current Communication System
1.1 Main Components of the Communication System
1.2 Drawbacks of the Current Setup
2.0 Goals of the Project
3.0 Improved System
3.1 Main Features
3.2 PKI Model for the New System
3.3 Integration with the RIPE NCC Services
3.3.1 LIR Portal
3.3.2 RIPE Database
3.3.3 Secure Communication with RS
3.3.4 Reverse Delegation
3.3.5 Billing
3.3.6 DNSSec
3.3.7 Integration Among Services
3.3.7.1 Database Integration
3.3.7.2 Reverse Delegation and Database Integration
4. Project Phases
4.1 LIR Portal
4.2 Database X.509 Support
4.3 Database / LIR Portal Interaction
4.4 Hostmaster Robot(s)
4.5 Reverse Delegation Robot
4.6 Future Services (Billing, DNSSec)

Introduction

Many services that the RIPE NCC provides for its members have requirements of authentication, non-repudiation, data integrity, data confidentiality, and access control. Over time these security requirements become increasingly important. As stated in the RIPE NCC Activity Plan for 2003 "particular attention will be dedicated to the security aspects of such interactions [with the RIPE NCC's systems] to ensure privacy and authentication wherever needed".

This document describes an approach based on X.509 PKI technology and standards to make interaction with the services provided by the RIPE NCC to its members more convenient and secure.

While improving the security of the communication system it is also important to make interaction with RIPE NCC services or systems more flexible and convenient for users.

To achieve these goals the communication system should be based on stable and well deployed industry standards and best practices.

It is important to note here that X.509 PKI is used as technology to facilitate the interaction of RIPE NCC members with the services provided by the RIPE NCC. It is outside the scope of this project to setup a fully functional third-party Certification Authority (CA) and provide X.509 PKI services that are not necessary to the specific goals of this project.

1.0 Current Communication System

1.1 Main Components of the Communication System

There are several subsystems in the RIPE NCC service portfolio provided for members that require authentication, non-repudiation, and data confidentiality.

Registration Services (Hostmaster)

Most of the interactions between a contact member of a Local Internet Registry (LIR) and a RIPE NCC Hostmaster take place via e-mail. Requests are authenticated based on the e-mail address of the originator, which is a very weak form of authentication. Non-repudiation and data integrity requirements are only supported from the RIPE NCC: all e-mails sent to a member are signed with the RIPE NCC PGP key. At the moment it is not possible to authenticate a member using a digital signature, or to send information back to a member in encrypted form.

RIPE Database

Historically the RIPE Database has supported multiple methods of authentication, starting with the weakest (such as NONE) and moving up to the strongest, the PGP signature. Over the last year, one of the weakest forms of authentication - MAIL-FROM - was phased out leaving NONE, CRYPT-PW, MD5-PW and PGPKEY as supported authentication methods. Unfortunately PGPKEY cannot be used with webupdates, a graphical user update interface that makes interactions with the RIPE Database more user friendly.

LIR Portal

This service provides users with increased and simplified access to RIPE NCC services and LIR data via a customised web interface. Authentication and access control for the LIR Portal are password based. Data is exchanged via a secure channel using SSL technology (server-side certificate).

Reverse delegation Robot

Authorisation of reverse delegation requests is based on the LIR designation specified in the e-mail.

1.2 Drawbacks of the Current Setup

As can be see from the overview in section 1.1, there are different security levels for accessing different components. This means that a user has to maintain different types of authentication tokens and sometimes must downgrade to a weaker one for simplicity. There is no possibility at the moment to provide a single sign-on mechanism to access the RIPE NCC service portfolio.

Due to the diversity of the types of credentials used, it is very difficult to provide support for credentials management. This may mean that members cannot control access to RIPE NCC services at their end.

Another serious drawback is that some of the access methods are not strong enough from a security point of view. In some cases, moving to a more secure access method would only be possible with a redesign of the system.

2.0 Goals of the Project

The goal of the project is to make improvements to the current communication system focusing on the following areas:

Access to the services and data

The goal in this area is to make communication faster and easier by introducing stronger and more uniform security mechanisms. This will make it easier for the user to maintain and use their security tokens and will allow the seamless use of some of the advanced interfaces (such as web-based interfaces) with strong security support.

Privilege management

The system will provide unified privilege management support for the users. X.509 PKI certificates used in the system as security tokens have intrinsic revocation and expiry mechanisms that, together with support for their maintenance, make the system less vulnerable.

Minimal deployment and maintenance efforts for the users

Based on an industry standard and being well deployed in commercial and open source software, the communication system will require no additional client-side software.

It is also important to note that transition to the new system will be implemented gradually and backwards compatibility will be preserved. Users will be able to use their current setup to access services they have at the moment.

3.0 Improved System

Technologically the improved system is based on a X.509 Public Key Infrastructure.

3.1 Main Features

The highlights of the new system are:

1. It will be possible to communicate with the RIPE NCC in a highly integrated and coherent manner using only one secure communication technology.
2. A permission management system will be integrated allowing an LIR to administer, in an easy and integrated way, the permissions of all their users that communicate with the RIPE NCC.
3. When deployed, the system will not be compulsory for LIRs. LIRs will be able to continue using the old communication mechanisms. They can partially or completely upgrade, choosing the level of security most appropriate to them.
4. The system will be based on standard and industrial strength technologies. Support for X.509 PKI based secure communication is widely available for critical components of the IT infrastructure. The most widely used mail clients and browsers support X.509 PKI, and a wide set of programming tools is available, both commercially and as open source. Procedures and protocols to manage secure communication are widely available and are very mature.
5. Traditional security dimensions were considered. When the system is fully deployed, it will be possible to interact with the RIPE NCC with a high level of confidentiality, integrity, non-repudiation, and authentication.

3.2 PKI Model for the New System

The new system will be based on an X.509 Public Key Infrastructure.

For each LIR a certificate with administrative powers will be issued. With that certificate an LIR can issue certificates to its own users with varying permissions per user.

One of the most fundamental problems with X.509 PKI is trusting that a third party requesting to be certified as a LIR is what they claim to be. To solve this problem a Registration Authority (RA) has to be put in place.

Another problem is the actual issuing of a certificate. This issuing must be done in a secure and reliable way by a Certification Authority.

The administrative user of the LIR will be able to grant and revoke privileges to the LIR's certified users. This information will be generally available to the various subsystems, as such a component that will make permission information available to the whole IT infrastructure of the RIPE NCC. This component, a Privilege Management System (PMS), is not a standard of typical PKIs.

It will be possible for LIRs to specify the level of security that they desire in their communications with the RIPE NCC. As an example, an LIR might want to use signed and encrypted mail when communicating with the Billing Department but might consider it sufficient to use plain text (unsecured) mail when communicating with Registration Services. A final component, the Communication Preference Management System (CPMS), will make available (internally to the RIPE NCC) the LIRs' preferences in regards to the level of security desired.

As such the following new components will be part of the secure communication system infrastructure:

• Registration Authority (RA)
• Certificate Server (CS)
• Certificate Repository (CR)
• Privilege Management System (PMS)
• Communication Preference Management System (CPMS)

The CS, CPMS, PMS and CR are components where the fundamental issues are technical, whereas the RA has policy points.

When a party contacts the RIPE NCC requiring a certificate with administrative purposes for an LIR, a procedure has to be followed to ensure that that person has the right to hold an administrative certificate for the LIR. The secure communication system will use the procedure in place for the LIR Portal, as a user that is verified as an LIR Portal administrator can request a certificate after authenticating (using username and password) on the LIR Portal (see https://lirportal.ripe.net/lirportal/activation/activation_request.html).

For certificates to be used by users, the RA is the administrative user for the LIR (which holds a certificate that has administrative permissions on the PMS). The LIR administrative user will be responsible for authorising the issuing and revocating certificates to users. The certificate users will have to be LIR Portal users.

3.3 Integration with the RIPE NCC Services

This secure communication system will have an impact on many existing RIPE NCC services, and that impact is assessed here. In each case, the specific proposals will be presented to the community for discussion.

3.3.1 LIR Portal

The integration of the LIR Portal with the secure communication system will have two dimensions:

1. As with all other services, it will be upgraded with a new communication mechanism as discussed in this document.
2. It will serve as an "Administration Console" for the new communication infrastructure. This means all administration procedures will be done via the LIR Portal.

Regarding the first point, it will be possible to login to the LIR Portal using client-side certificates and not only by using a LIR/username identifier and password. In this case users with a client-side certificate installed on their browser will not have to supply any credentials manually as the login procedure will be automated.

Some of the functions available:

1. Install a new certificate in the user's browser
2. Request a new certificate (revocating the current one)
3. Inform users that their certificate will expire or be revoked and offer to generate a new one

3.3.2 RIPE Database

The RIPE Database will have a new authentication mechanism available that will be based on a X.509 PKI.

In the first phase only certificates issued by the LIR Portal will be accepted by the RIPE Database. This means that non-LIR users will not be able to use this new authentication mechanism.

The support of this new authentication method can be done by adding a new option to the "auth:" attribute pointing to an X.509 PKI Distinguished Name.

There will be no need for a new type of key-cert object, as a copy of the issued certificates will not be needed (checking the embedded signature of a presented certificate is enough).

LIR users will be able to use this new type of authentication both with mail and webupdates. This means that a mechanism for updating the RIPE Database, more secure than using passwords, will be available via the web. The PGP mechanism currently available cannot be easily used on the web as it is not supported by standard web technologies.

3.3.3 Secure Communication with RS

It will be possible to communicate securely with Registration Services. The level of security can be chosen by the LIR. The following dimensions can be chosen:

1. Signed mail from the LIR is required
2. Encrypted mail from the LIR is required
3. Registration Services must always X.509 PKI sign their outgoing communications(*)
4. Registration Services must always encrypt their outgoing communications with the LIR public key

   (*) If this option is not chosen, the communication will be PGP signed.

The LIR can choose from a variety of configurations: from the current no authentication, no confidentiality scheme to a two-way authenticated, signed and encrypted communication.

For each specific communication the LIR user can upgrade the security level if necessary: for example, an LIR that requires only X.509 PKI authentication can require confidentiality in a communication that involves the transfer of sensitive data.

3.3.4 Reverse Delegation

An LIR will be able to declare that any changes to its reverse delegation information will have to be authenticated via X.509 PKI. This will mean that all requests from that LIR will have to be signed to be accepted.

Further, reverse delegation information modifications will be supported through the LIR Portal. The same authentication and encryption that applies to the LIR Portal will apply to reverse delegation.

3.3.5 Billing

Billing invoices could be sent, at the LIR’s request, signed and/or encrypted. All communication could proceed as in the Registration Services example given above in 3.3.3.

3.3.6 DNSSec

DNSSec will use PKI as its authentication mechanism. The user will be authenticated and if the user belongs to the LIR to which the IP space of the request is allocated, the user will be authorised to make changes.

3.3.7 Integration Among Services

The deployment of a X.509 PKI infrastructure will allow not only the usage of a single authentication mechanism between LIRs and all RIPE NCC’s services but also a better integration between those services, with single-sign on and authentication passing mechanisms. This integration will be done mostly via the LIR portal. A few examples of integration among services are:

3.3.7.1 Database Integration

An LIR Portal user whose certificate is also an authentication mechanism for one (or more) maintainer objects will be able to transparently use webupdates without proving any other authentication token. This is an example of a single sign-on integration.

3.3.7.2 Reverse Delegation and Database Integration

Using the LIR Portal it will be possible to change reverse delegations that are related to the LIR. This will be possible if the authentication is the same for both the LIR Portal and the objects maintained in the RIPE Database. The process will be transparent to the user and will be made possible by using authentication passing between systems that now have an integrated authentication mechanism.

4. Project Phases

Rough outlines for the various phases of implementing the Improved Secure Communication System (X.509 PKI) for RIPE NCC are given below. The exact delivery and scope may change based on member feedback.

4.1 LIR Portal

The LIR Portal integration must be implemented first. This is necessary since the LIR Portal is where certificates are issued. This will be completed before RIPE 45.

4.2 Database X.509 Support

This is where the RIPE Database is modified to allow the use of X.509 PKI certificates. The exact mechanism will be designed in conjunction with feedback from the RIPE Database Working Group. It is expected that implementing this will take only a few weeks, and should occur shortly after RIPE 45.

4.3 Database / LIR Portal Interaction

Users should be able to update the database through the LIR Portal. This means the database will have to be modified to allow "proxy authentication". Users who have authenticated themselves to the LIR Portal, should not have to re-authenticate themselves when they change database objects. The database will need a mechanism to ensure the portal has authenticated properly. This will be done as part of the ongoing LIR Portal development, expected during the second quarter of 2003.

4.4 Hostmaster Robot(s)

Automatic mail processing must be able to determine whether a certificate for an e-mail is a valid identifier for the given LIR, and handle encrypted e-mail. It is expected that these changes will be made in the third quarter of 2003.

4.5 Reverse Delegation Robot

The robot needs to be able to determine whether a certificate for an e-mail is a valid identifier for the given LIR. These changes are expected to be made in the third quarter of 2003.

4.6 Future Services (Billing, DNSSec)

These changes can be expected to occur in the fourth quarter of 2003, and will be shaped by the feedback received from LIRs, as well as the state of DNSSec.

Table of Contents

• 1.0 Introduction
• 2.0 Defining the Experiment
• 3.0 Publication
• 4.0 Non-commercial Basis
• 5.0 Period of the Temporary Resource Registration
• 6.0 Registration
• 7.0 Making the Request
• 8.0 Nota Bene

1.0 Introduction

Organisations often require deployment tests for new Internet services and technologies. These require numbering resources for the duration of the test.

The policy goal of resource conservation is of reduced importance when resources are issued on a temporary basis.

This document formalises the policy whereby the RIPE NCC registers numbering resources issued on a temporary basis for Internet experiments.

2.0 Defining the Experiment

An organisation receiving numbering resources must document the experiment. This may be in the form of a current IETF Experimental RFC (http://www.ietf.org/rfc/rfc2026.txt see Sec. 4.2.1) or an “experiment proposal” detailing the resources required and the activities to be carried out.

For experiments requiring IP address space the assignment size will be equal to the existing minimum allocation size on the date the request is received. For Autonomous System Number (ASN) requests a single ASN will be assigned. Where the experiment requires a variation to this rule it should be noted in the resource request.

3.0 Publication

The experiment proposal must be made public (e.g. published on web site), upon registration of the resources by the RIPE NCC. Following the conclusion of the experiment the results must be published free of charge and free from disclosure constraints.

4.0 Non-commercial Basis

Resources issued for an experiment must not be used for commercial purposes.

5.0 Period of the Temporary Resource Registration

The resources will be issued on a temporary basis for a period of one year. Renewal of the resources registration is possible on receipt of a new request that details any continuation of the experiment during the extended period.

The resources issued cannot be used for a commercial service following the conclusion of the experiment.

6.0 Registration

The RIPE NCC will register the resources issued in the RIPE Whois Database.

7.0 Making the Request

The request must be made by a Local Internet Registry (LIR) using the appropriate request form for the resource found at:

http://www.ripe.net/ripe/docs/internet-registries.html#request

8.0 Nota Bene

Upon acceptance of this draft document by the RIPE community, the text will be incorporated into the IPv4, IPv6 and ASN policy documents available from the RIPE Document Store at:

http://www.ripe.net/ripe/docs/internet-registries.html#policy

Table of Contents

1. Introduction
2. EU Data Protection Principles
3. What is Whois?
4. What is registered?
5. Why is it there?
6. How is it used?
7. Why do people register their networks?
8. Who uses data from the Whois database?
9. Who really needs access to Whois?
10. Country attribute

1. Introduction

This document discusses the use of the RIPE Whois database. It looks at what information is recorded in the database and why. Further, it asks whether it is appropriate to continue to use the RIPE Whois database today in the same way as it was used in the second half of the 1990s.

Eva Ericsson Rabete asked these questions at the Address Policy WG session at RIPE 49 in Manchester. It was agreed that the issues should be raised on the Address Policy Working Group mailing list for further discussion.

2. EU Data Protection Principles

When assignments are made to private individuals, data protection law restricts what information can legally be published in a public database. EU Data Protection law sets down three requirements for processing personal data:

• The personal data must be collected and processed for specific and explicitly defined purposes.
• The purposes have to be legitimate.
• The processing has to be carried out in a careful manner and must be necessary for, and proportionate to, the legitimate purpose for which the processing is done.

The RIPE NCC is based in the Netherlands and must comply with Dutch Data Protection law, which is based on European Union (EU) Directive 95/46/EC. The EU consists of 25 countries, all of which must implement the EU directive in local law. A list of EU member countries is available from:
http://europa.eu.int/abc/governments/index_en.htm#members

The community needs to decide whether the legitimate purposes can be met with something more restrictive than the current Whois database, in order to meet the requirement for the data processing to be proportionate. In most cases, the person whose data is stored and published in the Whois database needs to give their unambiguous consent.

3. What is Whois?

The Whois protocol was originally defined in RFC 812 and RFC 954. These RFCs defined policy for what information should be reported as well as the technical specification for the protocol. The current specification for the Whois protocol is RFC 3912. The major change since RFC 954 is that it removes all text not relevant to the on-the-wire protocol. The RIPE NCC has published IP address registration data in a Whois database since it began registering Internet number resources in the early 1990s.

4. What is registered?

IPv4, IPv6 and AS Number registrations are recorded in the RIPE Whois database. Anyone can query the database using the Whois protocol.

The main aim of registering Internet Number Resources in the public Whois database is to ensure uniqueness. Registration in the Whois database helps ensure that two different, but interconnected networks, do not accidentally use the same set of Internet Number Resources on their networks.

The public nature of the database and its information makes it clear who is using the resource. Network operators can use this information when configuring their networks to ensure that they do not advertise or route IP address space inappropriately.

5. Why is it there?

Contact information for the users of IPv4 networks ^{[ 2 ]} has traditionally been registered in the Whois database. Originally, this was to enable network operators to contact each other and troubleshoot connectivity problems. More recently, registration has become useful in the administration of the address space as a finite resource.

It is possible to query the RIPE Whois database for a range of different information. The most important database searches are for e-mail addresses, people’s names, IP addresses and the various alphanumeric IDs (nic-hdls) given to people, companies and maintainers (change control protection mechanisms) in the database.

[ 2 ] Network prefixes shorter than /30

6. How is it used?

Routing Registry information is the information associated with the network routing policies of the Internet’s various Autonomous Systems (ASs). This is published using aut-num, route and other database objects. Routing registry information is used by network operators to communicate with each other. It is not used by – and does not relate to – End Users.

IPv4 and IPv6 networks are registered in the Whois database as inetnum and inet6num objects. The data registered is used for a number of purposes, but there are no clear guidelines giving explicit guidance on the content or purpose of the registration and the permitted use of the data. The data registered includes details of the range in use, the user of the address space and contact information for the network operator. In some cases, this might be generic ‘role’ information; in others it could be the names, telephone numbers and e-mail addresses of the ISP’s staff or customers.

7. Why do people register their networks?

Operators whose networks provide services or transit to third parties will often want those third parties to be able contact them. In cases where there is not a direct, contractual relationship it is useful to be able to access appropriate contact information. This is a key reason for the existence of the RIPE Whois database.

Stub sites whose networks do not provide services or transit to third parties, for instance enterprise and home networks, are less likely to want to be contacted by previously unknown third parties. In most cases, these network operators are unlikely to be able to diagnose or resolve the causes of network or other problems with their site. For this reason, there is little benefit in including these network operators’ contact information in a Whois database.

8. Who uses data from the Whois database?

Operators often need to debug connectivity and reachability problems that cross intermediate networks. Being able to contact third party operators to report a problem can be useful.

End Users need to be able to report connectivity and other problems to third party network operators. It is likely that in many situations End Users will need a different set of contacts from those used by network operators.

RIRs currently use records in the Whois database to determine two things: how much of an LIR’s existing address space has been sub-allocated or assigned and whether those sub-allocations or assignments are valid. The case is different for IPv4 and IPv6.

Even a very large IPv4 allocation is unlikely to generate a large number of individual assignment records. This is because ISPs can make large assignments holding the IP space for all their single-IP address customers. It is only networks larger than a /30 that need to be registered in the RIPE Whois Database.

Current policy requires Local Internet Registries (LIRs) to register all /48 IPv6 assignments in a database accessible to their Regional Internet Registry (RIR). Doing so allows the RIR to determine whether the LIR has made a sufficient number of /48 assignments to qualify for an additional IPv6 allocation. These database registrations might either be in the Whois database or an internal private database with limited access for the RIPE NCC. However, in most cases, End Users’ residential connections will receive networks of the same size as large commercial enterprise sites, so neither company nor individual subscribers would be listed in a public Whois database. We should consider the fact that:

• stub sites are unlikely to be helpful when contacted by third parties.
• large ISPs might well make more than one million /48 assignments (a significantly larger number of assignments than would be made for IPv4 connections).

9. Who really needs access to Whois?

Law enforcement agencies, intellectual property owners and other organisations occasionally want to know who was using a particular IP address or network. In some cases they can get this information from Whois databases. In other cases they need to question the organisation running the access network for more specific information regarding the use of the addresses in which they are interested.

10. Country attribute

Both inetnum and inet6num database objects require publication of country information. More than one country can be specified for a single network.

It is not clear whether the country information is meant to be the country or countries where the IP space is in use, where the network connection is based or where the LIR is headquartered. The documentation for the objects is not much help. It just states, “Identifies the country”. This is presumably because it was not clear to the RIPE NCC staff who produced the documentation, or anyone else, what the ‘country:’ attribute is meant to signify. It is worth noting that because the purpose of the information is not well defined, it is not possible to rely on its accuracy. IP addresses do not have any national characteristics, so it is difficult to attempt to tie them to one or more countries with any meaning or relevance.

Document ID: TBD
Date: September 2005

Abstract

This document describes RIPE NCC policy for serving secured DNS data and key exchange. It does not cover deployment of DNSSEC by Local Internet Registries (LIRs) or others in its service region. It should be read alongside ripe-302 - "Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region."

Contents

1.0 Introduction
2.0 Obtaining Secure Delegations from the RIPE NCC
3.0 Procedures
4.0 References

1.0 Introduction

The RIPE NCC is committed to supporting the deployment of DNS Security Extensions (DNSSEC)[1,2,3]. DNSSEC extends the DNS and allows validating DNS resolvers to establish 'chains of trust' from known public keys to the data being validated. A full explanation of DNSSEC is out of the scope of this document. If you want this sort of information, please see [1,2,3,4 and 5].

During the resolution process, DNSSEC aware nameservers will provide secure delegations. These consist of a regular delegation (the NS record) to the nameservers that are authoritative for the child zone, as well as a signed pointer (the DS record) to a key that is authorised to sign the child zone. When the child and parent zone have exchanged keys, the RIPE NCC can provide a secure delegation.

This document describes RIPE NCC policy for serving secured DNS data and key exchange. It does not cover deployment of DNSSEC by Local Internet Registries (LIRs) or others in its service region.

2.0 Obtaining Secure Delegations from the RIPE NCC

It is possible to secure delegations from the RIPE NCC under the "Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region."

RIPE NCC operational staff will deploy DNSSEC zone by zone. They will only exchange keys when parent domains are being signed. This will keep information current.

Key exchange between parent and child is based on the same authorisation and authentication mechanisms as the exchange of nameserver delegation information.

The RIPE NCC will sign any announcements about secured DNS, such as changes in procedures, with its PGP key. It will publish procedures and announcements on a secure website:

https://www.ripe.net/reverse/dnssec/

and also post these to an announcement mailing list (ripe-list _at_ ripe _dot_ net).

3.0 Procedures

The Draft Public Key Procedure explains the procedure that the RIPE NCC will follow with its keys. You will need this document if you plan to configure the RIPE NCC as a 'trust anchor' or if you receive a secure delegation from there.

The Draft Registry Procedure explains how you can get a secure delegation.

4.0 References

[1] DNS Security Introduction and Requirements, Arends et al, RFC4033:
http://www.ietf.org/rfc/rfc4033.txt

[2] Resource Records for the DNS Security Extensions, Arends et al, RFC4034:
http://www.ietf.org/rfc/rfc4034.txt

[3] Protocol Modifications for the DNS Security Extensions, Arends et al, RFC4035:
http://www.ietf.org/rfc/rfc4035.txt

[4] DNSSEC HOWTO, O.M. Kolkman, RIPE NCC:
http://www.ripe.net/projects/disi/dnssec_howto/

[5] DNSSEC information portal:
http://www.dnssec.net

Document ID: TBD
Date: September 2005

Abstract

This document describes how to request DNSSEC Delegations. It is in addition to the existing procedure for requesting reverse delegations..

Contents

1.0 The DOMAIN Object
2.0 The "ds-rdata:" Attribute
3.0 Delegation Checks
4.0 Web Interface Restrictions
5.0 References

1.0 The DOMAIN Object

You can request reverse delegation by submitting domain objects. DNSSEC will not mean any change the existing authorisation mechanisms. The delegation checker will only carry out DNSSEC specific tests if DNSSEC related information is being exchanged.

To allow for the exchange of DNSSEC related information, the domain object now includes a "ds-rdata:" attribute.

domain:        [mandatory]  [single]     [primary/look-up key]      
descr:         [mandatory]  [multiple]   [ ]
admin-c:       [mandatory]  [multiple]   [inverse key]
tech-c:        [mandatory]  [multiple]   [inverse key]
zone-c:        [mandatory]  [multiple]   [inverse key]
nserver:       [optional]   [multiple]   [inverse key]
ds-rdata:      [optional]   [multiple]   [inverse key]
sub-dom:       [optional]   [multiple]   [inverse key]
dom-net:       [optional]   [multiple]   [ ]
remarks:       [optional]   [multiple]   [ ]
notify:        [optional]   [multiple]   [inverse key]         
mnt-by:        [optional]   [multiple]   [inverse key]
mnt-lower:     [optional]   [multiple]   [inverse key]
refer:         [optional]   [single]     [ ]
changed:       [mandatory]  [multiple]   [ ]
source:        [mandatory]  [single]     [ ]

2.0 The "ds-rdata:" Attribute

In DNSSEC the Delegation Signer (DS) Resource Record is created from a DNSKEY Resource Record by comparing it with the public key. The parent publishes the DS Resource Record (see [2]).

The "ds-rdata:" attribute contains the RDATA of the DS Resource Records related to the domain (as shown in the "domain:" attribute).

ds-rdata: 64431 5 1 278BF194C29A812B33935BB2517E17D1486210FA 

The tools provided with BIND (version 9.3.0 and later) will generate a "ds set" during signing. Before an update, you can copy the DS Rdata into the attributes.

The RIPE NCC will also provide a web interface to help with creation of domain objects.

3.0 Delegation Checks

When it receives an update, the update engine will perform a number of checks. These are the most important:

• Is there a matching DNSKEY available in the DNS for each "ds-rdata:" attribute that is submitted in the domain object?

• Is there a valid RRSIG made with the DNSKEY matching the "ds-rdata:"? - The resolution protocol [3] needs this, without it the update will fail.

• Does the DNSKEY has its "SEP" flag set? Setting the SEP flag is not mandatory. If it is not set, a warning will be produced, however the "ds-rdata:" content will still be copied to the zone.

• Is the signature validity period close to expiring and are the Times To Live (TTLs) a reasonable fraction of the signature validity period? We suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period. If the TTL would be of similar order as the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section 7.1 of [2] suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL". As a result query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches. To avoid query load peaks we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period. We currently test on the TTL being at least 2 times smaller than the signature validity period. See [6].

These tests will only be done for "ds-rdata:" attributes using supported digest types [1 section 5.1.3]. Currently we support digest type 1(SHA1).

If the "ds-rdata:" attribute uses an unsupported digest type, you will see a warning message, however the "ds-rdata:" content will still be copied into the parent zone.

4.0 Web Interface Restrictions

The RIPE NCC e will develop a web interface to make it easy to create domain objects with the appropriate "ds-rdata:" attributes. It will have some operational restrictions

• It will use the SEP flag to select the keys for which DSRRs are needed.

• It will use the "ds-rdata:" attribute of the domain object currently available in the RIPE Whois Database to select the appropriate default DNSKEY RR. It will then select a new "ds-rdata:" attribute.

If you find these conditions too restrictive, you can construct domain objects manually.

4.0 References

[1] DNS Security Introduction and Requirements, Arends et al, RFC4033"
http://www.ietf.org/rfc/rfc4033.txt

[2] Resource Records for the DNS Security Extensions, Arends et al, RFC4034:
http://www.ietf.org/rfc/rfc4034.txt

[3] Protocol Modifications for the DNS Security Extensions, Arends et al, RFC4035:
http://www.ietf.org/rfc/rfc4035.txt

[4] DNSSEC HOWTO, O.M. Kolkman, RIPE NCC:
http://www.amsterdamned.org/projects/disi/dnssec_howto/

[5] A DNSSEC information portal:
http://www.dnssec.net/

[6] draft-ietf-dnsop-dnssec-operational-practices-04.txt (work in progress).

Document ID: TBD
Date: September 2005

Abstract

This draft document describes RIPE NCC policy key distribution and maintenance during the deployment of DNSSEC in its service region.

Contents

1.0 Introduction
2.0 Proposed DNSSEC Key Procedure
3.0 References

1.0 Introduction

One of the main issues for early deployment of DNSSEC is key distribution and maintenance. For each zone that is signed, a key pair is created. The private part of that key pair is used to sign the zone, while the public key needs to be distributed to the DNS client. This means validating recursive nameservers to validate the data. DNSSEC allows public key distribution through the DNS, but this will only work if it is possible to build a chain of authority from a 'trust-anchor' through delegation from parents to child in each zone.

This 'trust-anchor' should ideally be the root. If there is no signed root, then all DNS clients that want to verify zone data will have to manually configure the zone keys. Maintenance of these keys is a process that does not scale well. We are working to come up with a solution to this issue.

The lack of key maintenance protocols is no reason to delay deployment of signed zones. Operators that configure 'trust-anchors' into their validating DNS clients will need to carefully maintain them. The 'trust-anchor' and the key signing key used to sign the zone remain must stay synchronised. If operators do not update their keys, then their zones might become invisible to DNS clients performing DNSSEC validation.

To avoid possible possible failures, the RIPE NCC will sign its zones using the policy proposed below.

2.0 Proposed DNSSEC Key Procedure

This procedure applies to each zone that the RIPE NCC will sign.

• RIPE NCC will sign all data in the zone with at least one Zone Signing Key (ZSK). A ZSK is zone specific.

• The ZSK will be published in the DNSKEY Resource Record (RR) set and signed with a Key Signing Key (KSK).

• The KSKs will have a SEP flag set so that they can be distinguished from the ZSKs in the DNSKEY RR set.

• The ZSK may be rolled without making any announcement. We will follow the 'pre-publish rollover scheme' as published in [1]. This will avoid breaks in the chain of trust.

• During the first two years of deployment, the KSK of each signed zone will be rolled twice each year. The rollover scheme that we will follow is the 'double signature scheme' published in [1]. There will be an overlap of three months to allow zone administrators to configure their new key.
  o At t=0 KSK1 signs the keyset. At t=3months KSK1 and KSK2 sign the keyset. DNS clients are expected to configure KSK2 during the three months that follow. At t=6months only KSK2 signs the keyset until (at t=9 months) KSK3 is introduced and a new rollover starts.
  o All zones at the RIPE NCC will roll their KSK simultaneously.

• The RIPE NCC will start generating signatures that are valid for one month. However, after announcing the change, it might decrease the signing validity period to the shortest operationally possible period. Also see [1] section 4.4.4.

The ZSK will be an RSA/SHA1 key of 1200 bits ([