BCP38 adoption "incentives"?

Tue Sep 27 12:31:24 UTC 2016

Does anyone know if any upstream and tiered internet providers include 
in their connection contracts a mandatory requirement that all 
directly-connected routers be in compliance with BCP38?

Does anyone know if large ISPs like Comcast, Charter, or AT&T have put 
in place internal policies requiring 
retail/business-customer-aggregating routers to be in compliance with BCP38?

Does any ISP, providing business Internet connectivity along with a 
block of IP addresses, include language in their contracts that any 
directly connected router must be in compliance with BCP38?

I've seen a lot of moaning and groaning about how BCP38 is pretty much 
being ignored.  Education is one way to help, but that doesn't hit 
anyone in the wallet.  You have to motivate people to go out of their 
way to *learn* about BCP38; most business people are too busy with 
things that make them money to be concerned with "Internet esoterica" 
that doesn't add to the bottom line.  You have to make their ignorance 
SUBTRACT from the bottom line.

Contracts, properly enforced, can make a huge dent in the problem of 
BCP38 adoption.  At a number of levels.

Equipment manufacturers not usually involved in this sort of thing (home 
and SOHO market) would then have market incentive to provide equipment 
at the low end that would provide BCP38 support.  Especially equipment 
manufacturers that incorporate embedded Linux in their products.  They 
can be creative in how they implement their product; let creativity blossom.

I know, I know, BCP38 was originally directed at Internet Service 
Providers at their edge to upstreams.  I'm thinking that BCP38 needs to 
be in place at any point -- every point? -- where you have a 
significant-sized collection of systems/devices aggregated to single 
upstream connections.  Particular systems/devices where any source 
address can be generated and propagated -- including compromised desktop 
computers, compromised light bulbs, compromised wireless routers, 
compromised you-name-it.

(That is one nice thing about NAT -- the bad guys can't build spoofed 
packets.  They *can* build, um, "other" packets...which is a different 
subject entirely.)

(N.B.:  Now you know why I'm trying to get the simplest possible 
definition of BCP38 into words.  The RFCs don't contain "executive 
summaries".)