Re: [sig-policy] prop-110v001: Designate 1.2.3.0/24 as Anycast to suppor
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 <gih at apnic dot net> 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 <owen at delong dot com> 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 <aftab.siddiqui at gmail dot com> 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
>>> sig-policy at lists dot apnic dot net
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>