Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
1 Mar
2012
10:22 a.m.
Aftab, Dean, AJ,
Thank you for your feedback. It is clear to me both from the observations about precedence in the meeting and from your comments since that point (e) should be removed.
I will post an accordingly updated version soon.
Regards, David
At 08:27 PM 1/03/2012, Aftab Siddiqui wrote:
I'm in support of ver2 adding point (d) but I seriously don't see any reason to have point (e).
Regards,
Aftab A. Siddiqui
On Thu, Mar 1, 2012 at 2:07 PM, Dean Pemberton <dean@deanpemberton.com > wrote:
- I strongly supported version 002 of this proposal.
- I agree with point (d) and I would support with a proposal which contained it.
- I disagree with point (e) as it stands and I would not support with
- any policy which contained a similar clause.
- I believe that placing a sunset clause on this policy sets a bad
- precedent. As mentioned by the APNIC secretariat, there has been no
- example of this being done on any previous proposal.
- As mentioned by David during the meeting, there is nothing to stop any
- other proposal being raised which would repeal prop-101 if a situation
- arose.
- As such I do not support version 003 of prop-101.
- Regards,
- Dean
- On Thu, Mar 1, 2012 at 9:54 PM, Andy Linton <asjl@lpnz.org> wrote:
- > Dear SIG members
- >
- > Version 003 of the proposal "prop-101: Sparse allocation guidelines for
- > IPv6 resource allocations" has been sent to the Policy SIG for review.
- >
- > This new version of the proposal reflects feedback from the community
- > received on the Policy SIG mailing list:
- >
- > - Section 4 now includes two additional clauses at (d) and (e)
- >
- > The proposal text is available below or at the following URL:
- >
- >
- > Information about this and other policy proposals is available from:
- >
- > http://www.apnic.net/policy/proposals
- >
- >
- > Regards,
- >
- > Andy, Skeeve, and Masato
- >
- >
- >
- > -----------------------------------------------------------------------------
- >
- > prop-101-v003: Removing multihoming requirement for IPv6 portable
- > assignments
- >
- > -----------------------------------------------------------------------------
- >
- >
- >
- > 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.
- >
- >
- > 4Details
- > ---------------
- >
- > 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 larger block (that
- > is, a block with a prefix mask less than /48) may be made:
- >
- > (i) If it is needed to ensure that the HD-ratio for the planned
- > network assignments from the block remains below the applied HD-ratio
- > threshold specified in Section 5.3.1 of the APNIC IPv6 policy [6], or;
- >
- > (ii) If addressing 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.
- >
- >
- > (d) The APNIC Secretariat will produce reports of the number of
- > portable IPv6 assignments requested, preferably as an
- > automatically-generated daily graph of the number of cumulative IPv6
- > portable assignments published publically on the APNIC website, or else
- > as regular (at a minimum, quarterly) reports sent to the sig-policy
- > mailing list detailing the incremental assignments of new IPv6 portable
- > assignments made since the last report, plus the cumulative total of
- > IPv6 portable assignments.
- >
- >
- > (e) The first Policy SIG meeting of 2014 (expected to be APNIC
- > Meeting 35) will as an agenda item consider the observed rate of IPv6
- > portable assignments and potential 10-year forecasts of growth of
- > portable assignments prepared by the APNIC Secretariat extrapolated on
- > the observed data, and by consensus consider the question "Should the
- > IPv6 portable assignment criteria revert to requiring multihoming?"
- >
- >
- >
- > 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.
- >
- >
- > 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 [6] Section 5.3.1, IPv6
- > address allocation and assignment policy,
- > http://www.apnic.net/policy/ipv6-address-policy#5.3
- > * sig-policy: APNIC SIG on resource management policy *
- > _______________________________________________
- > sig-policy mailing list
- > sig-policy@lists.apnic.net
- > http://mailman.apnic.net/mailman/listinfo/sig-policy
- --
- Regards,
- Dean
- * sig-policy: APNIC SIG on resource management policy *
- _______________________________________________
- sig-policy mailing list
- sig-policy@lists.apnic.net
- http://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
1
0
Activity Summary
- 4294 days inactive
- 4294 days old
- sig-policy@lists.apnic.net
- 1 participants
- 0 comments