I've been seeing a growing amount of traffic of various sorts from various public internet sites that has a source address in an RFC 1918 private net. In some cases because I have servers running multi-homed on administrative LANs which use these private networks, and because I've installed filters to ensure traffic isn't coming from the wrong nets on the wrong interfaces, this is even causing some services and requests to fail. (Eg. source quenches coming from private nets where even if the filters didn't exist the desired effect is not achieved.) I'm also seeing a growing number of requests on a couple of my transparent web cache machines that seem to be directed at hosts in RFC 1918 private networks -- i.e. it would appear as though the URLs refer either directly to private networks, or perhaps some domain names used in publicly accessible URLs resolve to point at private nets. I'm almost tempted to try and implement a DNS proxy that'll refuse to allow any responses from foreign nameservers to contain RFC 1918 addresses (and of course ensure that my internal DNS is authoritative for all the necessary in-addr.arpa zones). I suspect what's happening is that people are putting load-balanced servers behind service re-directors and are running these servers on RFC 1918 private networks in hopes that the re-director will do the appropriate NAT. Unfortunately most of these re-directors are not yet sophisticated enough to work as full proxies, and they often fail to properly translate associated packets, such as related ICMP traffic. (As has been amply evidenced by the extremely common failure of Path-MTU discovery from several such load-balancing devices.) In cases where I can identify the owners of the errant servers from my filter logs and/or from simple tcpdump traces I do attempt to contact them. However I'd rather try a more preventative approach, perhaps by making this issue more widely known, and perhaps by educating vendors and implementors of devices that might be causing these problems of what mistakes they might be making. I'm interested in exchanging information about these issues with other operators and in trying to track down and identify devices that might be letting some such private traffic slip through, and of course in helping to find and implement fixes to these problems. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>