BLACKHOLE community RFC7999

[Stuart Henderson]

On 2016/10/20 10:51, Job Snijders wrote:
> On Thu, Oct 20, 2016 at 05:35:43PM +0200, Clemens Schrimpe wrote:
> > >> Just FYI: https://www.rfc-editor.org/rfc/rfc7999.txt
> > >> I guess this feature deserves to be implemented.
> > > 
> > > Oh, sure. We plan to implement it.
> > 
> > It would be nice if export filters for the Kernel protocol could set a
> > route type, as in iproute(8):
> > 
> > TYPE := [ unicast | local | broadcast | multicast | throw |
> >           unreachable | prohibit | blackhole | nat ]
> > 
> > That would probably make more versatile than a static RFC7999 hack,
> > while allowing to easily implement RFC7999 and others.
> 
> Be careful not to overshoot:
> 
> RFC 7999 says:
> 
> 4.  Vendor Implementation Recommendations
> 
>    Without an explicit configuration directive set by the operator,
>    network elements SHOULD NOT discard traffic destined towards IP
>    prefixes that are tagged with the BLACKHOLE community.  The operator
>    is expected to explicitly configure the network element to honor the
>    BLACKHOLE community in a way that is compliant with the operator's
>    routing policy.
> 
>    Vendors MAY provide a shorthand keyword in their configuration
>    language to reference the well-known BLACKHOLE community attribute
>    value.  The suggested string to be used is "blackhole".
> 

Exactly - it can't be a static config as requirements will differ between
networks. But being able to set the type on routes exported to the kernel
is definitely needed in order to implement many common policies.