Re: [sig-policy] prop-101-v001: Removing multihoming requirement for IPv
Hash: SHA1
Hi all,
I think this proposal is timely and support it.
thanks
-gaurab
On 1/31/12 8:37 PM, Andy Linton wrote:
> Dear SIG members
>
> The proposal "prop-101-v001: Removing multihoming requirement for
> IPv6 portable assignments" has been sent to the Policy SIG for
> review.
>
> It will be presented at the Policy SIG at APNIC 33 in New Delhi,
> India, Thursday, 1 March 2012.
>
> The comment period on the mailing list is an important part of the
> policy development process. We encourage you to express your views
> on the proposal.
>
> Does this proposal solve a problem you are experiencing? David
> Woodgate is looking for a co-author to present this proposal to the
> APNIIC 33 Policy SIG as he is unable to attend. If you are
> interested please contact him directly.
>
> Information about this and other policy proposals is available
> from:
>
> http://www.apnic.net/policy/proposals
>
> Andy, Skeeve, Masato
>
>
>
> ------------------------------------------------------------------------
>
> prop-101-v001: Removing multihoming requirement for IPv6 portable
> assignments
>
> ------------------------------------------------------------------------
>
>
>
> Author: David Woodgate <dwoodgate5 at gmail dot com>
>
>
> 1. Introduction ----------------
>
> This a proposal to change the "IPv6 address allocation and
> assignment policy" to allow portable (that is, provider independent
> or PI) assignments of IPv6 address blocks to be made by APNIC to
> any organization with due justification and payment of standard
> fees, removing the current requirement that the requestor is or
> plans to be multihomed.
>
>
> 2. Summary of the current problem
> ----------------------------------
>
> Current APNIC policy only permits portable assignments of IPv6
> addresses to be made to an organization "if it is currently
> multihomed or plans to be multihomed within three months." [1] This
> requirement may unnecessarily complicate the implementation of IPv6
> in some networks that are large or complex and use static
> assignment of addresses. It is therefore proposed to remove this
> requirement.
>
> IPv6 models tend to assume widespread assignment of registered
> IPv6 addresses to equipment throughout a network; so if provider
> assigned IPv6 addresses have been used in an organization's
> network, then any change of ISP would require a renumbering of the
> entire network. Such renumbering may be feasible if the network is
> small or dynamically assigned (for example, through use of
> prefix-delegation), but renumbering a large, statically-assigned
> network would be a significant operational challenge, and may not
> be practically possible.
>
> Although it is likely that many large networks would be
> multihomed, there will be technical or commercial reasons why some
> will not be; currently those networks cannot obtain portable IPv6
> assignments from APNIC, and would need to use assignments from
> their ISPs, and accept the associated difficulties of future
> renumbering if they do so. This consideration and complexity could
> significantly delay IPv6 use by the affected organisations, which
> is not desirable.
>
> There is a risk that removing the multihoming requirement could
> cause a significant increase in demand for portable assignments,
> which in turn could cause the Internet routing tables to grow
> beyond manageable levels. It is not feasible to quickly generate
> any realistic model of likely demand increase which would arise
> from the proposed policy change, but it is argued that any such
> increase would only be of a scale to produce a manageable impact on
> global routing, for reasons including:
>
> - Organizations would only be likely to seek portable addressing
> if they believed it were essential for their operations, as
> provider assigned IPv6 addressing would be likely to be offered
> automatically and at no additional cost with their Internet
> services from their ISP;
>
> - APNIC membership fees would be expected to naturally discourage
> unnecessary requests, as these would be a far greater cost than
> that for provider assigned addressing;
>
> - Many or most organizations that require portable addressing will
> be multihomed, so the demand increase caused by removing the
> multihomed requirement should be small;
>
> - Only a limited set of an ISP's products is likely to allow
> customers to use portable assignments if they are singly-homed.
>
>
> 3. Situation in other RIRs ---------------------------
>
> APNIC is now the only RIR remaining with an absolute requirement
> for multihoming for portable address assignments.
>
> AfriNIC: The "Policy for IPv6 ProviderIndependent (PI) Assignment
> for End-Sites" [2] does not mention any requirement for
> multihoming;
>
> ARIN: Section 6.5.8 of the "ARIN Number Resource Policy Manual" [3]
> only identifies multihoming as one of several alternative criteria
> for direct IPv6 assignment to end-user organizations;
>
> LACNIC: There is no mention of multihoming anywhere in the IPv6
> section (Section 4) of the current LACNIC Policy Manual (v1.8 -
> 07/12/2011) [4].
>
> RIPE: The latest version (RIPE-545 [5]) published in January 2012
> of the "IPv6 Address Allocation and Assignment Policy" does not
> mention multihoming, removing the requirement that existed in
> previous versions of the document.
>
>
> 4. Details -----------
>
> It is proposed that section 5.9.1 of APNIC's "IPv6 address
> allocation and assignment policy" (apnic-089-v010) is rewritten to
> remove the absolute multihoming requirement for portable
> assignments, and to incorporate the following conditions:
>
>
> A. Portable IPv6 assignments are to be made only to organizations
> that have either joined APNIC as members or have signed the
> non-member agreement, under the standard terms & conditions and
> paying the standard fees applicable for their respective category.
>
> B. An organization will be eligible for a portable assignment if
> they have previously justified an IPv4 portable assignment from
> APNIC.
>
> C. A request for an IPv6 portable assignment will need to be
> accompanied by a reasonable technical justification indicating why
> IPv6 addresses from an ISP or other LIR are unsuitable.
>
> D. The minimum IPv6 portable assignment to any organization is to
> be an address block of /48. A portable assignment of a block
> larger than a /48 can be made if it can be demonstrated that more
> than 32,768 /64 subnets (or equivalent) are required within its
> network or if numbering is required for 2 or more of the
> organization's sites operating distinct and unconnected networks.
>
> E. In order to minimise routing table impacts:
>
> (a) Only one IPv6 address block is to be given to an organization
> upon an initial request for a portable assignment; subnets of this
> block may be assigned by the organization to its different sites if
> needed;
>
> (b) It is recommended that the APNIC Secretariat applies sparse
> allocation methodologies so that any subsequent requests from an
> organization for additional portable addressing would be
> accommodated where possible through a change of prefix mask of a
> previous assignment (for example, 2001:db8:1000::/48 ->
> 2001:db8:1000::/44), rather than through allocation of a new
> prefix. An additional prefix should only be allocated where it is
> not possible to simply change the prefix mask.
>
> (c) Any subsequent request for an additional portable assignment to
> an organization must be accompanied by information demonstrating:
>
> (i) Why an additional portable assignment is required, and why an
> assignment from from an ISP or other LIR cannot be used for this
> purpose instead;
>
> (ii) That the use of previous portable IPv6 allocations generated
> the minimum possible number of global routing announcements and the
> maximum aggregation of that block;
>
> (iii) How the additional assignment would be managed to minimise
> the growth of the global IPv6 routing table.
>
> F. An organization must only use portable assignments made under
> this policy to address its own networks. An organization must not
> use portable assignments to address the networks or sites of other
> organizations.
>
>
> 5. Pros/Cons -------------
>
> Advantages:
>
> - This proposal would provide access to portable IPv6 addresses
> for all organizations with valid needs, removing a potential
> impediment to industry standard IPv6 addressing for large
> singly-homed networks
>
> - This change would align APNIC with the policies of all other RIRs
> on portable assignments
>
> Disadvantages:
>
> - There would be a risk of an unmanageably large increase in
> global IPv6 routing table size and APNIC workload if there were to
> be a substantial and widespread increase in demand for portable
> assignments arising from the removal of the multihoming
> requirement
>
> - But demand is expected to be limited by the requirements
> specified in section 4 for justifications and APNIC standard fees,
> as well as other industry factors such as the capability of
> Internet services to support portable addressing.
>
>
> 6. Effect on APNIC -------------------
>
> The impact of this proposal on the APNIC Secretariat would depend
> on the increase of demand for portable assignments. Even if demand
> is eventually large, it is unlikely that there will be an
> significant change in hostmaster workloads for a long time because
> of the slow rate of take up of IPv6, and so there should be
> sufficient time to identify and take steps to modify policies and
> processes if necessary to manage the increase.
>
>
> 7. Effect on NIRs ------------------
>
> This proposal specifically applies to portable assignments made by
> APNIC. It would be the choice of each NIR as to whether they would
> adopt a similar policy.
>
>
> 8. References: ---------------
>
> [1] Section 5.9.1, IPv6 address allocation and assignment policy,
> http://www.apnic.net/policy/ipv6-address-policy#5.9
>
> [2] http://www.afrinic.net/docs/policies/AFPUB-2007-v6-001.htm
>
> [3] https://www.arin.net/policy/nrpm.html#six58
>
> [4] http://www.lacnic.net/en/politicas/manual5.html
>
> [5] http://www.ripe.net/ripe/docs/ripe-545
>
>
>
>
>
>
> * sig-policy: APNIC SIG on resource management policy
> * _______________________________________________ sig-policy
> mailing list sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
- --
http://www.gaurab.org.np/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9IdiYACgkQSo7fU26F3X0LFACfbgDw65P5QgqSC22QsaRkWLkT
7UgAnRwlrEpA9Y7VFzxvqa9F9+XoMT8N
=RGwn
-----END PGP SIGNATURE-----