Hi Owen, Normally I'd agree with you, with the view that "who would want to use this particular "highly tainted" prefix?", but life is full of surprises and this policy proposal is a response to representations made to me in the past along the lines of "can we use this prefix on a non-exclusive basis for local DNS services?" So my motivation for co-authoring this proposal was that I'm of the view that the best answer to such requests is to pass this back to the regional policy sig and see if there is some support for a positive answer to such representations. Obviously we all are aware that the broader the scope of the advertisement of this prefix the larger the dross the advertiser will attract, so I'm not sure that protecting folk from themselves is really a conclusive issue here. The folk who wanted to use this prefix could've used any address from their own local pool, and probably will do so for the command and control ports of the service. I understand that the attraction of 1.2 .3.0/24 was to advise the intended clients of their local DNS resolver to configure with DNS resolution system with 1.2.3.4 as a recursive resolver.
regards, Geoff On 27 Jan 2014, at 7:15 pm, Owen DeLong <[email protected]> wrote: > Thinking about this a little more, it seems to me that there's no really good > argument for doing this. > > The stated problem (DNS Anycast Servers) can easily be solved using either an > IPv6 subnet anycast address, an IPv6 anycast address, or an IPv6 multicast > address. > > The unstated problem (figuring out something useful to do with this noisy > dreggs of the bottom of the IPv4 barrel prefix) really doesn't need to be > solved. It's not like this is the only unusable /24 in the IPv4 space. > > Owen > > On Jan 26, 2014, at 22:59 , Aftab Siddiqui <[email protected]> wrote: > >> Hi Geoff, >> >> If you are referring to a visible routing advertisement for 1.2.3.0/24 in >> the global BGP routing tables, then nothing has been seen of this prefix. >> >> Well, actually this is good, I wrongly assumed otherwise. >> >> If you are referring to the use of individual addresses drawn from this >> prefix in local contexts, then the profile of unsolicited traffic that is >> directed to this address points to an inference of a considerable level of >> local use of this prefix, which of course if unauthorised local use given >> that this prefix has not been allocated or assigned for end use. >> >> If you are referring to further studies of the "dark traffic" in 1.2.3.0/24 >> as a followup to the original work in 2010, then we have not performed any >> followup analysis of this prefix since then, but as the incoming traffic was >> so large at the time, and the studies on 1.0.0.0/24 and 1.1.1.0/24 point to >> increasing traffic since then, there is no reason to believe that the fate >> of 1.2.3.0/24 is any different >> >> Just checked 2 days of flows and surprisingly (naive) enough even our >> network is adding around 1M of such traffic towards 1.2.3.0/24. >> >> Is this prefix useable in local contexts? Its a balance between this >> unauthorised use and the associated traffic profile associated with this >> address, and the desire of some operators to use "memorable" IP addresses >> for DNS services. Some folk may find this attractive, despite the downside >> of associated noise, while others will continue to use "quieter" IP >> addresses for such a service. >> >> Speaking about "memorable", I quick whois suggest that 103.0.0.0/24 is also >> available. Not as memorable as 1.2.3.0/24 but I guess less prone to unwanted >> incoming traffic. I'm definitely in favour of having a prefix for anycast >> but 1.2.3.0/24 is not going to help in anyways. But you are the stats guru >> you can suggest better. >> >> Regards, >> >> Aftab A. Siddiqui >> * 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
