> > E) There isn't any perceived new revenue to the network > generated from > > turning on sources address policing. > > > > "E" is the #1 reason I've run into with SPs for not > deploying source > > address policing. > > > Agreed. In fact, if there was some way to make the > application of source address policing in some way a /sine > qua non/ for any ISP with end customer connections, then I > think we would be most, if not all of the way there. Indeed > one of the goals of SAVA would be to significantly increase > the incentive to apply source address filtering.
The SPs who do this do have it as part of their default config for new customers. But that would not get it turned on the interface by default. How do you know POS 0/0 is a customer interface? You don't. Even if you could solve that, SPs who dive into BCP38 often have to get their AUPs changed with their customer contracts. BCP 38 techniques for IPv4 translate to IPv6. ACLs, uRPF Strict Mode, DHCP Lease Query, and IP Source Verify all work with IPv6 addressing (it is just a matter of coding priority). Hence, you will not get any faster deployment of BCP38 than you have today. Now Prec/DSCP recoloring - that is a different issue. As soon as a miscreant figures out how to extort an SP's IPTV service cause a BOTNET is configured to blow the pay per view away during the superbowl, then you will get an incentive to do BCP38++ (source IP, MAC, and Prec/DSCP recoloring). _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
