BCP38.info

[nick at flhsi.com (Nick Olsen)]

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 at isc.org>
Sent: Tuesday, January 28, 2014 4:40 PM
To: "Jared Mauch" <jared at puck.nether.net>
Cc: nick at flhsi.com, "NANOG" <nanog at 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 at isc.org