[sig-policy] Global IPv6 PI policy proposal

  • To: "global-v6 at lists dot apnic dot net" <global-v6 at lists dot apnic dot net>
  • Subject: [sig-policy] Global IPv6 PI policy proposal
  • From: JORDI PALET MARTINEZ <jordi.palet at consulintel dot es>
  • Date: Fri, 14 Apr 2006 17:01:03 +0200
  • Cc:
  • List-archive: <http://www.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • Reply-to: jordi.palet@consulintel.es
  • Thread-index: AcZf1D+EfeKCs8vHEdqXyQANky3PwA==
  • Thread-topic: Global IPv6 PI policy proposal
  • User-agent: Microsoft-Entourage/
    • 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 dot 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.
      8. Policy term:
            a. temporary, permanent, or renewable.
      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
      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
      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:
      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.