Re: [sig-policy] prop-101 Returned to mailing list and Newversion posted
I support your proposal as is. I concur with Randy that narrowing it down doesn't make it any better, and instead 'would eliminate other unforeseen "reasonable technical
justification[s]" in the future'.
Yi Chu
Sprint
-----Original Message-----
From: sig-policy-bounces at lists dot apnic dot net [mailto:sig-policy-bounces at lists dot apnic dot net] On Behalf Of Randy Whitney
Sent: Wednesday, August 08, 2012 12:46 PM
To: David Woodgate
Cc: sig-policy at lists dot apnic dot net
Subject: Re: [sig-policy] prop-101 Returned to mailing list and Newversion posted
Hi David,
I support your proposal. I have some minor concerns that can hopefully
be settled in time for the meeting in three weeks, but if not, sobeit.
Like Terence, I had a similar concern about the vagueness of "a
reasonable technical justification". However, I do not wish to strike
the text out completely and replace it with extremely narrow and strict
criteria that would eliminate other unforeseen "reasonable technicial
justification[s]" in the future.
When it comes to our region's need to push rapid IPv6 adoption, IMO it
is better to be more open, at least initially, to allow for much more
rapid adoption, so I would still support your proposal even with the
unaltered text.
Best Regards,
Randy.
On 8/8/2012 10:54 AM, David Woodgate wrote:
> Terence,
>
> Thank you for stating your concerns so clearly. Would your concerns be
> addressed if the term "a reasonable technical justification" were simply
> deleted, and the two criteria currently identified as examples were to
> become the only specific options permitted? That is, changing the
> wording to:
>
> C. Requests by organizations that have not previously received an
> IPv4 portable assignment will need to be accompanied by:
>
> (a) EITHER:
>
> (i) Demonstration that the relevant network is statically
> addressed and of a size or complexity that would make IPv6
> renumbering operationally impractical within an acceptable
> business period, together with evidence that dynamic or
> multiple addressing options are either not available from
> the relevant ISP or are unsuitable for use by the
> organization;
>
> OR:
>
> (ii) Demonstration that any future renumbering of the relevant
> network could potentially interfere with services of a
> critical medical or civic nature;
>
> AND
>
> (b) A detailed plan of intended usage of the proposed address block
> over at least the 12 months following allocation.
>
> I'm always concerned about *not* allowing the Secretariat scope for
> interpretation of the policies, because I doubt I'd be able to think of
> all of the scenarios that they would encounter. However, I *think* the
> criteria (a)(i) & (ii) above would cover all the situations I'm trying
> to address (but I would welcome any suggestions from the list about any
> realistic situations which might not be suitably covered).
>
> Would you consider that this change (if incorporated into a new draft of
> the proposal) would address your concerns?
>
> And to those on the list that have previously expressed support, would
> you continue to support the proposal if such a change were to be made?
>
> [BTW, it may be noted that under these two criteria that multihoming
> would *not* by itself be sufficient justification for portable
> assignment. My argument supporting this is that, given potential options
> with IPv6 for dynamic and multiple addressing, multihoming shouldn't
> necessarily mean that portable addressing will always be required or
> warranted, unless the situations described by criteria (a)(i) & (ii)
> applies anyway. I would be happy to discuss this further with anyone on
> this list if desired.]
>
> With best regards,
>
> David
>
>
> On 8/08/2012 1:21 PM, Terence Zhang YH wrote:
>> Hi, David & All,
>>
>> Thanks for the update of prop-101, I also don't think multihoming is nessessary for
>> IPv6 portable assignments, there for I support the intend of this proposal, and I
>> support revising the IPv6 portable assignment criterias.
>>
>> How ever, my concern to prop-101 is, technically, by 'a reasonable technical justification'
>> criteria, all other portable assignment requirements become vain.
>> Currently APNIC policy allow IPv6 portable assignments in 3 situation (criterias):
>> multihoming, IXP and Critical Infrastructure.
>>
>> Prop-101 propose rewriting the 'multihoming' criteria to 'a reasonable technical justification',
>> but by doing that, 'a reasonable technical justification' will actually supersede
>> all other portable assignment criterias, since those criterias are 'OR' conditions.
>> If those criterias were 'And' conditions and we remove the 'multihoming' condition,
>> I think it's reasonable.
>>
>> I am not sure if every one is aware that prop-101 is more than the proposal title suggests,
>> ('Removing multihoming requirement for IPv6 portable assignments' )
>> I think a more acurate description would be
>> 'Removing current IPv6 portable assignments criterias with a reasonable technical justification'
>>
>> So the proposal title stresses on 'removing mutihoming requirement', and the proposal text
>> fully explains why 'mutihoming requirement' is unnecessary and even harmful,
>> I agree on most of those explanation and support 'multihoming is unnecessary'.
>>
>> But the actual effect of the proposal is removing all other criterias as well,
>> so I can not support the proposal as it's currently written,
>>
>> I would suggest replacing 'reasonable technical justification' with well defined criterias.
>>
>> Thanks & Regards
>> Terence
>>
>> ----- Original Message -----
>> From: "David Woodgate" <dwoodgate5 at gmail dot com>
>> To: <sig-policy at lists dot apnic dot net>
>> Sent: Tuesday, August 07, 2012 3:07 PM
>> Subject: Re: [sig-policy] prop-101 Returned to mailing list and Newversion posted
>>
>>
>>> I would still like to encourage adoption of this proposal, and I thank
>>> the many people who have expressed their support for it so far.
>>>
>>> To summarise once again:
>>>
>>> - APNIC policy still formally requires demonstration of multihoming in
>>> order to be allocated a portable or provider independent IPv6 allocation;
>>>
>>> - This means that currently a company with a singly-homed and
>>> statically-configured configured network would need to number their
>>> network from their ISP's allocation, and changing ISP would require
>>> renumbering the entire network. This could deter them from implementing
>>> IPv6 in their enterprise. Removing APNIC's multihoming requirement would
>>> remove this deterrent by allowing them access to portable address
>>> allocations.
>>>
>>> - APNIC is the only RIR remaining that requires demonstration of
>>> multihoming in order to allocate portable IPv6 addresses.
>>>
>>> - It is therefore proposed that multihoming be removed as a requirement
>>> for portable IPv6 allocations, and be replaced instead with requirements
>>> aimed to limit allocations to organisations truly requiring portable
>>> addressing for reasons of difficulty of renumbering or criticality of
>>> network services.
>>>
>>> The only particular concern that has been raised about this draft, and I
>>> believe only explicitly by one member of this list, is that the removal
>>> of the multihoming requirement could lead to a potential explosion of
>>> the IPv6 global routing table because of a large number of requests for
>>> portable address allocations, especially as the the draft only requires
>>> "reasonable technical justifications" rather than mandatory and
>>> explicitly detailed criteria (although two examples of "reasonable
>>> justifications" are included, based on complexity of renumbering or
>>> importance of civic services).
>>>
>>> The draft itself does provide some reasons suggesting why the number of
>>> additional allocations arising should only have a relatively small or
>>> manageable impact on the global routing table, and some provisions are
>>> proposed in the draft for progressive reporting of the number of
>>> portable allocations to provide timely warning to the community should
>>> the resulting number of allocations prove more significant than expected.
>>>
>>> I would welcome any further comment on this draft before the Phnom Penh
>>> meeting in a few weeks, especially if there are any remaining concerns
>>> about the draft, as well as any additional indications of support or
>>> opposition.
>>>
>>> With many thanks,
>>>
>>> David Woodgate
>>>
>>>
>>>
>>> On 11/07/2012 1:46 PM, Andy Linton wrote:
>>>> Can we remind you all that a revised version of this proposal,
>>>> available at http://www.apnic.net/policy/proposals/prop-101, is up for
>>>> consideration at our next meeting. Of course, you should consider the
>>>> whole proposal before deciding to support or oppose this proposal.
>>>>
>>>> The change from the previous version is the *removal* of the following clause:
>>>>
>>>> (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?"
>>>>
>>>> --
>>>>
>>>> This clause was a major point of debate in the debate at the last
>>>> policy SIG meeting and while some people now are happy to support the
>>>> proposal there has been no other discussion. We encourage you express
>>>> your views on the list so that those who won't be able to attend the
>>>> meeting in person have a chance to take part in the discussions.
>>>>
>>>>
>>>> Andy, Masato, Skeeve
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> prop-101-v004: 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.
>>>>
>>>>
>>>> 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 automatically eligible for a minimum IPv6
>>>> portable assignment if they have previously justified an IPv4
>>>> portable assignment from APNIC.
>>>>
>>>> C. Requests by organizations that have not previously received an
>>>> IPv4 portable assignment will need to be accompanied by:
>>>>
>>>> (a) a reasonable technical justification indicating why IPv6
>>>> addresses from an ISP or other LIR are unsuitable - examples of
>>>> suitable technical justifications may include (but are not
>>>> limited to):
>>>>
>>>> (i) Demonstration that the relevant network is statically
>>>> addressed and of a size or complexity that would make IPv6
>>>> renumbering operationally impractical within an acceptable
>>>> business period, together with evidence that dynamic or
>>>> multiple addressing options are either not available from
>>>> the relevant ISP or are unsuitable for use by the
>>>> organization;
>>>>
>>>> (ii) Demonstration that any future renumbering of the relevant
>>>> network could potentially interfere with services of a
>>>> critical medical or civic nature;
>>>>
>>>> (b) A detailed plan of intended usage of the proposed address block
>>>> over at least the 12 months following allocation.
>>>>
>>>> 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:
>>>>
>>>> (a) 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;
>>>>
>>>> (b) If addressing is required for 2 or more of the organization's
>>>> sites operating distinct and unconnected networks.
>>>>
>>>> Any requests for address blocks larger than the minimum size will
>>>> need to be accompanied by a detailed plan of the intended usage of
>>>> the proposed assignment over at least the following 12 months.
>>>>
>>>> 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.
>>>>
>>>>
>>>> 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 at lists dot apnic dot net
>>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>> * 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
>
> * 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
>
* 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
________________________________
This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.