Re: [sig-policy] prop-101 Returned to mailing list and Newversionposted
[Dean]:
"APNIC is now the only RIR remaining with an absolute requirement for
multihoming for portable address assignments."
Do you disagree with all the other RIR implementations of this concept?
[Terence]:
First, the above is not fully accurate, under current APNIC policy,
multihome, IXP and Criticical Infrastures are eligible for portable assignments,
so multihome is not an absolute requirement.
Secondly, each RIR's situation is different, you should also notice that
APNIC 's IPv4 portable assignment policy is also different with other RIRs(before and after final /8),
take ARIN for example, I think the main reason they move to the current
IPv6 portable assignement criterias is to keep it consistent with IPv4 portable
assignment criterias, it's hard to explain to an organization that they are
eligible for IPv4 PI but not IPv6 PI.
But APNIC don't have that situation, APNIC's IPv6 portable assignment criterias
are consistent with IPv4 portable assignment criterias, and I don't see any issues raised
about the IPv4 assignment policy.
[Dean]:
that the operational stability of the region is jeopardised, I will
co-author the proposal with you to overturn this.
[Terence]:
I am afraid that's an one way street.
Regards
Terence
On Mon, Mar 12, 2012 at 8:21 PM, Terence Zhang YH <zhangyinghao at cnnic dot cn> wrote:
> Hi David,
>
> My concerns about prop-101 is not address consumption but route aggregation,
> I am afraid the popular use of portable assignments will make route
> aggregation less possible.
>
> "2000 addresses or 200 /64s" seems to serve the 'conservation' purpose,
> but not the 'aggregation' purpose,
> I think we can explicitly define the situations where renumbering will
> result in a significant impact, which cannot be aviod technically.
>
> Regards
> Terence
>
> ----- Original Message -----
> From: David Woodgate
> To: Terence Zhang YH ; Owen DeLong
> Cc: sig-policy at apnic dot net
> Sent: Friday, March 09, 2012 10:16 AM
> Subject: Re: [sig-policy] prop-101 Returned to mailing list and
> Newversionposted
>
>
> Terence,
>
> May I ask whether you consider that the ARIN criteria adequately meet your
> concerns? For example, if I cut and paste the ARIN criteria (especially the
> "2000 addresses or 200 /64s" criteria), would that be sufficient gain your
> support for the proposal?
>
> Regards, David
>
> At 12:32 PM 9/03/2012, Terence Zhang YH wrote:
>
> What I mean is I support expanding the current portable assignment criterias
> (multihome, IXP, CI),
> but not to replace the current criterias with a 'reasonable justification'.
>
> Regards
> Terence
> ----- Original Message -----
> From: Owen DeLong
> To: Terence Zhang YH
> Cc: Dean Pemberton ; Randy Whitney ; sig-policy at apnic dot net
> Sent: Friday, March 09, 2012 12:24 AM
> Subject: Re: [sig-policy] prop-101 Returned to mailing list and
> Newversionposted
>
> I'm not sure I fully understand your concern here, Terrence. ARIN has been
> issuing portable /48 assignments for a few years now. I think it is a
> reasonable minimum end-user assignment for IPv6. Can you elaborate on what
> you mean by "a few exceptional"?
>
> Owen
>
> On Mar 8, 2012, at 5:26 AM, Terence Zhang YH wrote:
>
>
> I don't object to allow a few exceptional /48 portable assignments,
> and I don't insist on the '2-year-expiration',
> but I suggest either define the 'reasonable justification' criterias
> explicitly & clearly
> or put in some safeguarding limit.
>
> Regards
> Terence
>
> ----- Original Message -----
> From: Dean Pemberton
> To: Randy Whitney
> Cc: sig-policy at apnic dot net
> Sent: Thursday, March 08, 2012 11:14 AM
> Subject: Re: [sig-policy] prop-101 Returned to mailing list and
> Newversionposted
>
> I too support this version of the proposal
>
>
>
> On Thursday, March 8, 2012, Randy Whitney < randy.whitney at verizon dot com>
> wrote:
>> I support this version of the proposal, which removes the controversial
>> 4.E.e Sunset Clause from the text, while leaving the 4.E.d Reporting
>> requirement.
>>
>> Best Regards,
>> Randy.
>>
>> On 3/6/2012 8:20 PM, Masato Yamanishi wrote:
>>> Dear SIG members
>>>
>>> # I'm sending this notification on behalf of Andy Linton, Policy SIG
>>> chair
>>>
>>> Version 3 of prop-101 Removing multihoming requirement for IPv6 portable
>>> assignments, did not reach consensus at the APNIC 33 Policy SIG.
>>> Therefore, this proposal is being returned to the author
>>> and the Policy SIG mailing list for further discussion.
>>>
>>> The author has submitted a revised proposal, prop-101-v004, for further
>>> discussion on the Policy SIG mailing list.
>>>
>>>
>>> Proposal details
>>> ---------------------
>>>
>>> This is 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.
>>>
>>>
>>> Proposal details including the full text of the proposal, history, and
>>> links to mailing list discussions are available at:
>>>
>>> http://www.apnic.net/policy/proposals/prop-101
>>>
>>> Regards
>>>
>>> Andy, Skeeve, and Masato
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> 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 > 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
>>>
>
> --
> Regards,
>
> Dean
>
>
> ________________________________
>
> * 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
>
--
Regards,
Dean