• Date Prev
• Date Next
• Thread Prev
• Thread Next
• Date Index
• Thread Index

Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default

• To: Andy Linton <asjl at lpnz dot org>
• Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size
• From: Owen DeLong <owen at delong dot com>
• Date: Sat, 25 Jan 2014 20:39:08 -0800
• Cc: SIG policy <sig-policy at apnic dot net>
• Delivered-to: sig-policy at mailman dot apnic dot net
• Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:x-dkim:dkim-signature:content-type:mime-version:subject: from:in-reply-to:date:cc:message-id:references:to:x-mailer:x-greylist; bh=OcJRaOknCCmS5wSI8HV27Im7uImKjkwjkxATYTYlsBE=; b=zagyrdJ5w6f4E/zLu0lo4nKXlO6abIq4WnR7rjt2XPtqSyxT4+uqSYvR7FtI7uejJRGeXvT1SXhX5 +T0T9PiVlDyRcAoj0gyVlRRh6xj7J6YuH+7ArAr5JEluhwN6jBxKKn1fHvCcHp+owftHD6hUNXfsY4 BhWMzw+SMVQQYfxk=
• Dkim-signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1390711361; bh=flKx3yjG/QYIUn/d8jIgY+FvKXY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=c0wBPm2vmzfvHk8dtHrff2SYFzEKVxf38LSBcAVVSbxauRxIVexiYHpkIT2FEKYGe P/y0j3LwQ1t4l0kXp1kM0SfpMzkQxnEmo8XisiNKZGF3o/tapllhfIxOIwcBNYhEC9 r8hSLBtJgHd0Fv/6xFnPCkUkskSd0cDQbfSQ+kh4=
• In-reply-to: <CALS-_OpoaFyk-77ReARzYkyn_yVSe7Xc1Ktd6nML59+0AZE3wg at mail dot gmail dot com>
• List-archive: <http://mailman.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/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
• References: <CALS-_OpoaFyk-77ReARzYkyn_yVSe7Xc1Ktd6nML59+0AZE3wg@mail.gmail.com>

If you're going to do this, I would rather see providers given the option of choosing a size ranging from /28 to /32 with encouragement towards either end (/28 or /32). This has several advantages: 1. It reduces bitmath requirements. 2. It simplifies DNS delegation for ip6.arpa zones 3. It allows providers that simply don't need a larger allocation to choose the size that best meets their needs. 4. It simplifies APNIC's resource management process. 5. It simplifies the request process and qualification requirements. Owen On Jan 25, 2014, at 17:22 , Andy Linton <asjl at lpnz dot org> wrote: Dear SIG members The proposal "prop-111-v001: Request-based expansion of IPv6 default allocation size" has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 37 in Petaling Jaya, Malaysia, on Thursday, 27 February 2014. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal:      - Do you support or oppose this proposal?      - Does this proposal solve a problem you are experiencing? If so,        tell the community about your situation.      - Do you see any disadvantages in this proposal?      - Is there anything in the proposal that is not clear?      - What changes could be made to this proposal to make it more        effective? Information about this policy proposals is available from:     http://www.apnic.net/policy/proposals/111 Andy, Masato ---------------------------------------------------------------------- prop-111-v001: Request-based expansion of IPv6 default allocation size ---------------------------------------------------------------------- Author:       Tomohiro Fujisaki               fujisaki at syce dot net 1. Problem statement --------------------    Currently, IPv6 minimum allocation size to LIRs is defined as /32 in    the "IPv6 address allocation and assignment policy", while APNIC    currently reserves up to /29 for each /32 allocation. It's better to    expand this minimum allocation size up to /29 since:    - For traffic control purpose, some LIRs announce address blocks      longer than /32 (e.g. /35). However, some ISPs set filters to block      address size longer than /32. If LIRs have multiple /32, they can      announce these blocks and its reachability will be better than      longer prefix.    - If an LIR needs address blocks larger than /32, LIRs may tend to      announce as a single prefix if a /29 is allocated initially at      once. i.e., total number of announced prefixes in case 1 may be      smaller than in case 2.      case 1:      The LIR obtains /29 at the beginning of IPv6 network construction.      case 2:      The LIR obtains /32, and /31, /30 additionally with the subsequent      allocation mechanism.    - Before sparse allocation mechanism implemented in late 2008, /29      was reserved for all /32 holders by sequence allocation mechanism      in the early years. It is possible to use these reserved      blocks efficiently with this modification. 2. Objective of policy change -----------------------------    This proposal modifies the eligibility for an organization to receive    an initial IPv6 allocation up to a /29 by request basis. 3. Situation in other regions -----------------------------    RIPE-NCC:    The policy "Extension of IPv6 /32 to /29 on a per-allocation vs    per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get    up to /29 by default. 4. Proposed policy solution ----------------------------    - Change the text to "5.2.2 Minimum initial allocation size" of      current policy document as below:      Organizations that meet the initial allocation criteria are      eligible to receive an initial allocation of /32. For allocations      up to /29 no additional documentation is necessary.    - Add following text in the policy document:      for Existing IPv6 address space holders      LIRs that hold one or more IPv6 allocations are able to request      extension of each of these allocations up to a /29 without meeting      the utilization rate for subsequent allocation and providing      further documentation. 5. Explain the advantages of the proposal -----------------------------------------    - It will be possible for LIRs to control traffic easier.    - It is possible to use current reserved blocks efficiently. 6. Explain the disadvantages of the proposal --------------------------------------------    Some people may argue this will lead to inefficient utilization of    IPv6 space. However, the space up to /29 is reserved by APNIC    secretariat for each /32 allocation. 7. Impact on resource holders -----------------------------    NIRs must implement this policy if it is implemented by APNIC. Date Prev Date Next Thread Prev Thread Next Date Index Thread Index Prev by Date: Re: [sig-policy] prop-109v001: Allocate 1.0.0.0/24 and 1.1.1.0/24 to APNIC Labs as Research Prefixes Next by Date: Re: [sig-policy] prop-110v001: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure Previous by thread: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size Next by thread: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size Index(es): Date Thread