IPv6 Sub-assignment Clarification

Summary of Proposal

Luckily more and more people are (thinking about) deploying IPv6 in their networks. Some of these networks may already have IPv4 PI assignments and are already being multi-homed and/or independent from one entity providing upstream services – and wish to continue a multi-homed setup for IPv6. Some may want to rethink old habits of IPv4 networking and start fresh, independent and multi-homed for IPv6. The community should encourage and support people who are doing so.

Today, organisation networks usually include some kind of guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to customers’ sites, or anything similar where devices of non-members of the organisation would get assigned an IP out of the organisation’s prefix. Strictly following the current RIPE policy regarding eligibility for IPv6 PI space, organisations aren't allowed to be provided with PI space when this is the case.

As a consequence, people may opt to postpone an IPv6 migration, be unspecific or less honest when answering the RIPE NCC’s questions, or to become an LIR or ask an existing LIR for less flexible PA space and possibly encounter problems with multi-homing. None of these options are ideal.

As an example, some Freifunk Communities in Germany have been had their PI request declined because some 1-digit-number of subnets would have been used as IPv6 prefixes on public WIFIs. This usage of the IP space in the End User’s infrastructure has been interpreted as a sub-assignment of a /128 prefix. This would have been "assigned" to a user device of the public WIFI network as the device would get an IP address via SLAAC (or any other means for that matter).

This interpretation seems rather extreme and history shows that it's not even shared by every member of the RIPE NCC. As discussed at the Address Policy WG during RIPE 72, there have been some other Freifunk communities as well as others getting allocations for the same usage patters. Even the IPv6 prefixes used on the WIFI at RIPE 72 were ASSIGNED-PI. So currently there's an unequal treatment of people being honest and specific in what they want to do and those giving only high-level, incomplete, or even wrong answers to the RIPE NCC when requesting IPv6 PI.

Being more specific in the policy about what a sub-assignment is and setting it to a “/64 or shorter” solves this problem in a simple way and will help a number of (not only non-profit) organisations to smoothly design and set up independent and multi-homed IPv6 networks. Disallowing sub-assignments for “/64 or shorter” will still prevent ISPs from using “cheap” PI space for their subscribers.

Policy Text

a. Current policy text

IPv6 Address Allocation and Assignment Policy

7. IPv6 Provider Independent (PI) Assignments

To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

The RIPE NCC will assign the prefix directly to the End User organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR.

[...]

Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region

2.0 Contractual Responsibilities of End Users and LIRs

[...]

The details of any such contracts are outside the scope of this document.

However, at the minimum, all contracts must include:

[...]

* Notice that none of the provider independent resources may be sub-assigned to a third party

[...]

b. New policy text

IPv6 Address Allocation and Assignment Policy

7. IPv6 Provider Independent (PI) Assignments

To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”.

Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter.

The RIPE NCC will assign the prefix directly to the End User organisation upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR.

[...]

Rationale

a. Arguments supporting the proposal

With this clarification in place, there will be no more room for interpretation regarding whether using PI space in (public) WIFIs or installations is in conflict with the policy. As a /64 is the smallest meaningful prefix length to use in non-PTP links, there should be no worries of people misusing PI space for sub-assigned customer prefixes.

This will even resolve some current policy violations – depending on the interpretation of the current policy – and avoid further ones regarding this point. This may even help to further IPv6 deployment, as there seem to be some people and organisations who would like to use IPv6 PI space but have been denied.

Although the IPv6 address space is huge, it's still finite. Users only needing a /48 (or less) for their organisations would also block a full /29 prefix when forced to become LIRs. This seems unproportional.

b. Arguments opposing the proposal

The boundary of "/64 or shorter" has been chosen as this is the smallest meaningful prefix for IPv6. In theory, this policy change allows people to hand out /80 or smaller prefixes to their users/customers, but the risk of IPv6 PI misuse seems to be rather low here. Prefixes longer than a /64 are of no big use in reality and nobody in their right mind would use such a prefix for their paying users.

Increasing the number of PI assignments probably will increase the number of entries in the global v6 routing table. Some people might worry about an increase in the table size in the foreseeable future. Not going forward with this policy change will likely result in people getting /48 to /40 sub-assignments from an LIR or maybe becoming LIRs themselves, resulting in at least the same number of routes, maybe even more (aggregate routes for the PA space + sub-assignments).

Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.

A. RIPE NCC's Understanding of the Proposed Policy

If this proposal is accepted, it is the RIPE NCC’s understanding that for IPv6 PI assignment requests, subnets in the addressing plan smaller than a /64 will be exempt from being considered sub-assignments.

The RIPE NCC has been receiving an increasing amount of IPv6 PI requests where an organisation plans to use IPv6 PI to provide connectivity or other services to End Users with a /128 or other small prefix for each customer. If this policy change is accepted, the RIPE NCC will provide IPv6 PI assignments to these requesters, provided no subnets of a /64 or larger will be provided to entities outside of the requesting organisation.

While this policy change will likely help with the deployment of IPv6 for organisations that provide services to customers, some side effects should be noted:

• Several RFCs refer to a /64 as the minimum size per End Site (RFC6177) or as necessary for interface identifiers used with the Global Unicast Address range (RFC4291). While the examples described in this proposal seem to be within these RFCs, the RIPE NCC would also need to accept requests that are in conflict with RFCs as long as the subnets to customers are not /64 or bigger. There is no requirement that RFCs match RIPE policies, however the RIPE community has traditionally aimed to keep these aligned and often uses RFCs for guidance. This policy change has the potential to increase the number of IPv6 deployments conflicting with RFCs. Assignments that are not in accordance with normative references, such as Standards Track RFCs, might be more difficult to implement technically by the End User.
• Section 5.4.1 of the RIPE IPv6 policy mandates a /64 as the minimum assignment size per End Site within IPv6 allocations, while this policy change will make subnets smaller than a /64 per customer possible within IPv6 PI assignments. This difference might confuse organisations that start with IPv6 PI and later go on to become LIRs and receive IPv6 allocations.
• In order to qualify for IPv6 PI assignments, organisations might assign subnet sizes per customer that later turn out to be too small for optimal use of the various IPv6 features. Alternatively, organisations might provide incorrect information about the subnet size they actually plan to provide.
• The current RIPE Database business rules prevent the creation of more specific objects under an object with the status “ASSIGNED PI”, therefore these small subnets used by customers of the requesting organisation cannot be documented in the RIPE Database.

B. Impact of Policy on Registry and Addressing System

If this proposal is accepted, organisations with services that include the provision of small amounts of IPv6 per customer can request IPv6 PI, resulting in an expected increase of IPv6 PI assignments. Currently the RIPE NCC assigns around 250 IPv6 PI assignments per year, the vast majority of which are a /48. Some organisations that would become LIRs and request an IPv6 allocation (minimum size /32) under the current policy, might instead choose for an IPv6 PI assignment instead (minimum size /48). This would have a slowing effect on the overall IPv6 consumption rate.

Overall, the RIPE NCC estimates that neither of these effects will have a significant impact on the RIPE NCC IPv6 pool.

C. Impact of Policy on RIPE NCC Operations/Services 

A faster processing of IPv6 PI requests is expected by Registration Services, as evaluation will focus on the requester’s documentation and that no sub-assignments of /64 or bigger will be provided to other organisations.

The RIPE NCC might need to spend more effort during request evaluations, training and other outreach activities to explain the importance of sufficient subnet sizes for customers and the relevance of RFC recommendations for the deployment of IPv6.

Implementation 

With the information currently available, it is expected that implementation of the proposal would have a low impact in terms of the software development needed to facilitate the policy changes in internal RIPE NCC systems. Internal and external processes and documentation would also need to be updated.