I don't necessarily oppose folks using the prefix that way, but I'm also not convinced that there is actually a benefit to doing so.
So I guess I'm neutral on the proposal, but I encourage my competitors to do this in their networks. Owen On Jan 27, 2014, at 13:04 , Geoff Huston <[email protected]> wrote: > 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
