I'm Policy WG Chair of JP Open Policy Forum, Toshio Tachibana. We had an opinion collection meeting with our community in Japan, and would like to share our input.
There is comment from prop-110-v001 based discussion because meeting hold before v002 proposed. --------------------------------------------------------------------------- [prop-110] Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure How this proposal may help: - It would be good to have any space based on functions Effectiveness of the proposal: - There should be multiple candidates for DNS resolvers, therefore multiple prefixes should be reserved instead of a single prefix. Read: http://www.apnic.net/policy/proposals/prop-110 Concern about its effect: - There was a software which was designed to send all bug reports to this address. Expanding the use of this space: - Please clarify who will use this space for what purpose. (if the use will not be limited to anycast DNS) - This proposal should be withdrawn if this is not for anycast, as it will be a substantial change. Where to discuss this proposal: - Since this will be expanding private address space, the decision should not be made only in the APNIC region, and return the space to the IANA. - On the other hand, it is an allocated space to APNIC, which may not quite fit in to handle it in the IANA. - It affects vendors in its specifications, please bring it to the IETF. --------------------------------------------------------------------------- Best regards, Toshio Tachibana On Fri, Feb 14, 2014 at 4:08 AM, Masato Yamanishi <myama...@japan-telecom.com> wrote: > Dear SIG members > > A new version of the proposal "prop-110: Designate 1.2.3.0/24 as Anycast > to support DNS Infrastructure" has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > http://www.apnic.net/policy/proposals/prop-110 > > 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? > > Regards, > > Masato > > > > > ------------------------------------------------------------------------ > prop-110v002: Designate 1.2.3.0/24 as Anycast to support DNS > Infrastructure > ------------------------------------------------------------------------ > > > Proposers: Dean Pemberton, d...@internetnz.net.nz > Geoff Huston, g...@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 > * 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
