Correct, The assumption is that NAT was in use here. After a quick phone conversation with Jared. We concluded that at least in the specific case I was speaking about, I was correct in that nothing was "Spoofed". However, Explained further in detail about what he sees from other IP's on that list. And it clicked when he pointed out how many times 8.8.8.8 and 4.2.2.1..etc. pop up as the src of the reply. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Mark Andrews" <marka@isc.org> Sent: Tuesday, January 28, 2014 4:40 PM To: "Jared Mauch" <jared@puck.nether.net> Cc: nick@flhsi.com, "NANOG" <nanog@nanog.org> Subject: Re: BCP38.info Jarad is correct. There is lack of BCP38 filtering in the CPE ASN. Either the packet has gone "probe" -> CPE ->(*) recursive server -> "probe" or "probe" -> CPE -> recursive server -> CPE ->(*) "probe" (*) indicates the packet that should have been blocked depending apon how the NAT worked. In either case the CPE ASN had failed to check the source address of a packet. In the first case the source address of the query to the recursive server. In the second case the source address of the reply back to the probe after it had been through the NAT process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org