I support this proposal.
...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd [email protected] ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering On Sun, Jan 26, 2014 at 12:21 PM, Andy Linton <[email protected]> wrote: > Dear SIG members > > The proposal "prop-110v001: Designate 1.2.3.0/24 as Anycast to support > DNS Infrastructure" 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. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in 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? > > > Information about this policy proposals is available from: > > http://www.apnic.net/policy/proposals/110 > > Andy, Masato > > ------------------------------------------------------------------------ > prop-110v001: 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, to be managed as a common > anycast address to support DNS infrastructure deployment > > Any party who applies to APNIC to use this address block on a > non-exclusive basis to number their DNS resolver will receive a > Signed Letter of Authority to permit their Autonomous System to > originate a route for 1.2.3.0/24, and APNIC will also publish a RPKI > ROA designating the AS as being permitted to originate a route. This > ROA shall be valid until APNIC is advised otherwise by the AS holder. > > 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. > > There is the need to set up an administrative process in the > reception of applications to use the address block, and in the > maintenance of a set of ROAs associated with these applications > > > 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 > [email protected] > http://mailman.apnic.net/mailman/listinfo/sig-policy > >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
