[sig-policy] New version of prop-110: Designate as Anycast to

  • To: <sig-policy at lists dot apnic dot net>
  • Subject: [sig-policy] New version of prop-110: Designate as Anycast to support DNS Infrastructure
  • From: Masato Yamanishi <myamanis at japan-telecom dot com>
  • Date: Thu, 13 Feb 2014 11:08:53 -0800
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • 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>
  • Thread-topic: New version of prop-110: Designate as Anycast to support DNS Infrastructure
  • User-agent: Microsoft-MacOutlook/
    • Dear SIG members

      A new version of the proposal "prop-110: Designate as Anycast 
      to support DNS Infrastructure" has been sent to the Policy SIG for review.

      Information about earlier versions is available from:

      You are encouraged to express your views on the proposal:

      - Do you support or oppose 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?



      prop-110v002: Designate as Anycast to support DNS

      Proposers:       Dean Pemberton, dean at internetnz dot net dot nz
                       Geoff Huston, gih at apnic dot net

      1. Problem statement

         Network 1 ( was allocated to APNIC by the IANA on 19
         January 2010. In line with standard practice APNIC's Resource Quality
         Assurance activities determined that 95% of the address space would
         be suitable for delegation as it was found to be relatively free of
         unwanted traffic [1].

         Testing, conducted by APNIC R&D found that certain blocks within
         Network 1 attract significant amounts of unwanted traffic, primarily
         due to its unauthorised use as private address space [2].

         Analysis revealed that, prior to any delegations being made from the
         block, attracted an average of 140Mbps - 160Mbps of
         unsolicited incoming traffic as a continuous sustained traffic level,
         with peak bursts of over 800Mbps.

         The analysis highlighted individual addresses such as with
         its covering /24 (identified as remain in APNIC
         quarantine and it is believed they will not be suitable for normal
         address distribution.

         The proposal proposes the use of in a context of locally
         scoped infrastructure support for DNS resolvers.

      2. Objective of policy change

         As the addresses attract extremely high levels of unsolicited
         incoming traffic, the block has been withheld from allocation and
         periodically checked to determine if the incoming traffic profile has
         altered. None has been observed to date. After four years, it now
         seems unlikely there will ever be any change in the incoming traffic

         The objective of this proposal is to permit the use as a
         anycast addresses to be used in context of scoped routing to support
         the deployment of DNS resolvers. It is noted that as long as
         providers who use this address use basic route scope limitations, the
         side effect of large volumes of unsolicited incoming traffic would
         be, to some extent mitigated down to manageable levels.

      3. Situation in other regions

         Improper use of this address space is a globally common issue.
         However the block is delegated only APNIC and so therefor, no other
         RIR has equivalent policy to deal with the situation.

      4. Proposed policy solution

         This proposal recommends that the APNIC community agree to assign to the APNIC Secretariat for use in the context of locally
         scoped infrastructure support for DNS resolvers.

         At some future point there is nothing restricting an RFC being
         written to include this prefix into the special-purpose IPv4
         registry.  However, at this time it is considered sufficient for the
         APNIC community to designate this prefix to be managed as a common
         anycast address for locally scoped infrastructure support for DNS

      5. Advantages / Disadvantages


         - It will make use of this otherwise unusable address space.
         - DNS operators will have an easy-to-remember address they can use to
           communicate with their users (e.g. configure "" as your DNS


         - The address attracts a large volume of unsolicited incoming
           traffic, and leakage of an anycast advertisement outside of a
           limited local scope may impact on the integrity of the DNS service
           located at the point associated with the scope leakage. Some
           operators with high capacity infrastructure may see this as a
           negligible issue.

      6. Impact on APNIC

         Although this space will no longer be available for use by a single
         APNIC/NIR account holder, the proposal would result in benefit for
         all APNIC community members, as well as the communities in other


         [1] Resource Quality Good for Most of IPv4 Network "1"

         [2] Traffic in Network