Masato,

Can it be explained how this occurred.  Did something change between the two?

I thought it was practice that the AMM essentially confirmed the proceedings on the Policy SIG - to avoid these kinds of events, especially at APRICOT meetings where support/non-support may not be able to make both events.

I find it extraordinarily a waste of time if all the effort of the Policy SIG is undone on an individual policy basis.  The AMM should be confirming the whole Policy SIG event, not individual policies..   or you might as well not call for consensus during Policy SIG and just save time and do it once at the AMM, or the other way around.

I've seen this happen a number of times at combined Apricot events with a lot of other parties present.  One might say that it would be wiser to propose policies only at the mid-year events.






...Skeeve

Skeeve Stevens - eintellego Networks Pty Ltd
The Experts Who The Experts Call
Juniper - Cisco - Cloud - Consulting - IPv4 Brokering


On Tue, Mar 4, 2014 at 12:27 AM, Masato Yamanishi <myamanis@japan-telecom.com> wrote:
Dear colleagues

Version 2 of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS
Infrastructure, reached consensus at the APNIC 37 Policy SIG, but did
not reach consensus at the APNIC 37 Member Meeting.

Therefore, this proposal is being returned to the authors and the Policy
SIG mailing list for further consideration.


Proposal details
----------------

The objective of this proposal is to permit the use 1.2.3.0/24 as
anycast addresses to be used in context of scoped routing to support the
deployment of DNS resolvers.

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-110

Regards

Masato



------------------------------------------------------------------------
prop-110v002: Designate 1.2.3.0/24 as Anycast to support DNS
              Infrastructure
------------------------------------------------------------------------


Proposers:       Dean Pemberton, dean@internetnz.net.nz
                 Geoff Huston, gih@apnic.net


1. Problem statement
--------------------

   Network 1 (1.0.0.0/8) 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, 1.0.0.0/8 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 1.2.3.4 with
   its covering /24 (identified as 1.2.3.0/24) remain in APNIC
   quarantine and it is believed they will not be suitable for normal
   address distribution.

   The proposal proposes the use of 1.2.3.0/24 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
   profile.

   The objective of this proposal is to permit the use 1.2.3.0/24 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
   1.2.3.0/24 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
   resolvers.


5. Advantages / Disadvantages
-----------------------------

Advantages

   - 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 "1.2.3.4" as your DNS
     resolver")


Disadvantages

   - 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
   regions.



References
----------

   [1] Resource Quality Good for Most of IPv4 Network "1"
   http://www.apnic.net/publications/press/releases/2010/network-1.pdf

   [2] Traffic in Network 1.0.0.0/8
   http://www.potaroo.net/ispcol/2010-03/net1.html


*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy