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

  • To: SIG policy <sig-policy at apnic dot net>
  • Subject: Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size
  • From: Mike Jager <mike at mikej dot net dot nz>
  • Date: Sat, 1 Feb 2014 00:26:50 +1300
  • 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:content-type:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=5mb81PRXE4u1Y1w5HM9LRI9bWHyK3SKNiYPEBiUeVlo=; b=Ez1/fkZDLfkoJrHm2UUmypv0dL2N1Z2TqsweQS87dh37vOtqV/3upM/oCh34kLgOkuYtA5xtA3GZE QNLu9FgBcuiroV/im4eMA7d6AMl4mLRrJOOMQTxzx2KEJz1avwipT2QX0camTJaI2XlixFBvkbjPvA ZauS2+hiatI7eHJY=
  • 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>
    • 
      > 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.
      
      This policy reminds me of prop-090/098 and prop-099, all of which were previously abandoned.
      
      >    - 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.
      
      Has there been research to support the view that prefixes longer than /32 are widely filtered? It would appear that there are a significant number of /48s announced today - http://bgp.potaroo.net/v6/as2.0/index.html. A handful of networks filtering ge /33 does not meaningfully limit the use of more specific announcements as a TE tool.
      
      >    - 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.
      
      It would be disappointing if networks that received a subsequent allocation contiguous with their existing allocation(s) announced this as a a separate prefix rather than aggregating it.
      
      In the days of v4, APNIC would reserve the address space next to an allocation for a member to receive within a certain time period if justified. I would expect that whatever behaviour members displayed in aggregation/non-aggregation of these v4 prefixes would be repeated when receiving contiguous v6 allocations. Perhaps the v4 behaviour could be investigated to determine the likelihood of aggregation of multiple v6 allocations.
      
      > 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.
      
      The problem statement says that the minimum allocation should be increased to a /29. Are you proposing that the minimum size is increased, or that a /29 can be obtained with no further justification compared to a /32?
      
      > 5. Explain the advantages of the proposal
      > -----------------------------------------
      > 
      >    - It will be possible for LIRs to control traffic easier.
      
      I think I need to see some evidence that ge /33 is filtered on a large scale before I can support this policy on this basis.
      
      >    - It is possible to use current reserved blocks efficiently.
      
      It seems that the intention of the policy is that the remainder of the initial /29 reservations is “used at all”, rather than any specific “efficiency” gain is obtained. If a member has a /32 allocation out of a /29 reservation, but has no need for address space beyond a /32, how is it more efficient to automatically allocate this space?
      
      If this is to proceed, I agree with Owen that /28 makes more sense than /29. However, I’m not sure that this needs to happen at all.
      
      There still seems to be a belief that it is “hard” to receive an allocation larger than a /32, and that this places limitations on members’ addressing plans, particularly when performing sparse allocation within a member’s network. This is absolutely not the case. I have personally justified a /28 using a method very similar to Owen’s preferred addressing plan. It was far from difficult.
      
      Perhaps what is needed is not a policy change, but some education around the fact that a /32 is the *minimum* allocation (much like a /22 was the *minimum* IPv4 allocation), and that with some reasonable justification, a larger allocation is definitely obtainable.