[address-policy-wg] Global IPv6 PI policy proposal

Please, use global-v6 at lists.apnic.net for inputs to this draft policy
proposal, in order to avoid threads being split across multiple mail
exploders in different regions.


1.  Number: (The RIPE NCC will assign this)
 
2. Policy Proposal Name:
 
Provider-Independent (PI) IPv6 Assignments for End-User-Organizations
 
Note: We can use ³Portable IPv6 Assignments for End-User-Organizations² if
that helps some folks to buy-in the proposal.
 
3. Author:
      a. name:                        Jordi Palet Martinez
      b. e-mail:                        jordi.palet at consulintel.es
      c. organisation:            Consulintel
 
4. Proposal Version:            1.1
 
5. Submission Date:            17/4/2006
 
6. Suggested RIPE Working Group for discussion and publication:
 
Address Policy
 
7. Proposal type:
      a. new, modify, or delete.
 
            NEW
 
8. Policy term:
      a. temporary, permanent, or renewable.
 
            TEMPORARY
 
9. Summary of proposal:
 
This policy is intended to provide a solution for organizations that have a
need for provider independent assignments in IPv6.
 
Typically those organizations will require the provider independent
assignment in order to be able to become multihomed in a similar fashion as
today is done for IPv4, but other reasons are also foreseen. For example
some organizations aren¹t multihomed, but still require being globally
routable with stable addressing (avoiding renumbering if they change the
upstream provider) and in those cases (reasons behind may be administrative,
policy, security, etc.) it seems that no other solution than provider
independence is feasible, at least by now.
 
Considering the foreseen consequences in the medium/long-term of this policy
in the routing tables, this policy proposes an expiry date of 3 years once a
technically correct alternative valid and deployable solution becomes
accepted by the community.  After that sunset period, the assignments done
for multihoming purposes should be reclaimed and this policy should be
modified to still allow assignments that could be required for purposes
different than multhoming.
 
At the sunset, the organizations that want to avoid renumbering and qualify
to become an LIR, will be able to opt for that solution and they will get
allocated the same prefix.
 
10. Policy text:
      a. Current (if modify):
      b. New:
 
Provider-Independent IPv6 assignment to End-User-Organizations
Qualification for an IPv6 Provider-Independent assignment: To qualify for a
direct assignment, the organization must not be an IPv6 LIR and must qualify
for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4
policy. This is valid regardless of actually having being assigned or
allocated such an IPv4 block.
 
Provider-Independent IPv6 assignment size to End-User-Organizations: The
minimum size of the assignment is /32. However a larger assignment can be
provided if duly documented and justified.
 
Subsequent assignment size to End-User-Organizations: Whenever possible,
further assignments will be made from adjacent address blocks, but only if
duly documented and justified.
 
Assignment super-block: Those assignments shall be allocated from a separate
super-block to allow for LIRs to filter them if required.
 
Expiry for those assignments: In the case of assignments done under this
proposal in order to address the multihoming issue, they will need to return
the block in a maximum period of 3 years after a technically correct
alternative valid and deployable solution becomes accepted by the community.
Alternatively, to avoid renumbering, some of the organizations affected by
this, could become an LIR, if they qualify for it.
 
11. Rationale:
      a. Arguments supporting the proposal
 
In IPv4 there are organizations that qualify for an allocation for being PI,
or could opt to be an LIR, either because they need to be multihomed or have
other administrative or technical reasons to require a portable addressing
block.
 
This is not the case today for IPv6 and it is perceived as a clear barrier
for deployment of IPv6 in some organizations, and is being addressed by this
proposal by means of providing a direct assignment from RIPE NCC.
 
These organizations are not allowed to make further assignments to other
external organizations, but instead only to assign subnets internally within
their own facilities.
 
Assigning /32 will make those blocks to behave as other regular
LIR-allocated ones and follow the generally accepted routing filtering
practices, but at the same time being identifiable belonging to a special
super-block. Also, it allows becoming an LIR, if that¹s the case, without
requiring a renumbering.
 
By setting up this policy, we avoid creating an unfairness situation among
different regions and allow any organization that requires PI to access to
it. All the organizations that opt for this PI, will be in the same fair
situation once the technical solution is agreed and will have to either move
to the new solution or become an LIR if they qualify. Newcomers will be in
the same situation. Organizations that don¹t opt to PI with this policy is
because they don¹t need it, so they aren¹t put in an unfair situation.
 
Those that don¹t believe in possible alternative solutions and agree in
going for a permanent PI policy instead, don¹t have valid reasons to oppose
to this proposal, as the sunset will only enter into effect once that
solution is agreed, so this proposal is not against their view.
 
Some organizations my qualify to become an LIR now and avoid using this
temporary assignment, but if their only reason to become an LIR is to get
the PI block, then it seems better, looking in the long-term routing table
size conservation, to go for this choice, which is more fair for the overall
community.
 
The ³temporarily² of this assignment must be understood as a long-term one,
as we may expect those alternative solutions to be available possible in 3-4
years, which means that with the ³transition² period of 3 years, asking for
a change in 6-7 years must not be considered as a pain.
 
      b. Arguments opposing the proposal
 
The possible effect of this proposal is the grow of the routing tables to
figures which, together with the existing (and forecasted) IPv4 routing
entries, could create an important trouble to operators before vendors
provide products with implement technical solutions, or even if those
technical solutions exists, have an important impact in the cost or/and
depreciation period for the infrastructure investments.
 
This is the reason why the proposal provides already a fix sunset, but
relative to the date where an alternative and technically correct solution
is available and accepted as deployable by the community.
 
Regarding the size of the assignment (/32), being a temporal one, should not
be considered as a space waste, and instead be seen as an advantage in the
sense of not requiring new special filters.
 
 
 
Acknowledgments: I will like to acknowledge the inputs received for the
first version of this proposal from Marcelo Bagnulo and Lea Roberts.
 




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.