Geoff and Dean, As next step, can you share your thought as the authors whether continue the discussion or withdraw this proposal?
Rgs, Masato 2014-03-03 5:27 GMT-08:00 Masato Yamanishi <[email protected]>: > 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, [email protected] > Geoff Huston, [email protected] > > > 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 > > -- Masato Yamanishi SVP, Network Engineering Japan Telecom America Tel: +1-213-623-0797 ext.106
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
