Nick Hilliard wrote :
Personally - and I say this as an IXP operator who has had yet another
week-end ruined due to prolonged DDoS problems on an IXP
fabric - I don't think this is an appropriate document for standards track,
or even for publication as an RFC. The reason for this
is that section 3.4 creates the expectation that IXPs could or should be
involved in facilitating blackholing of IP addresses.
I'm with you here. I have never been an IXP operator myself, but I think it's a
bad idea that IXPs themselves get involved in the blackholing business. I habe
been very specific in the CBBC FAQ (1) that it was not something I thought IXPs
should use.
It's not just DDoS that will be targeted here.
Correct. Although some blackholing by _participants_ in an IXP could be useful,
for the layer 9 issues you mentioned earlier it makes total sense that the IXP
itself would not be involved. Maybe a route-server operated by a completely
independent third party.
Job Snijders wrote :
This is a stifling argument. A blackhole mechanism is already today
standardized as RFC 5635. This draft merely exists to standardize a codepoint.
I have to disagree. This drafts does more than to standardize a codepoint, it
creates a community with global significance. If the draft was about
standardizing the :666 part of it, I could support it (with the removal of 3.4).
As of RFC5635, I thought it was a step in the right direction. A draft that
reserves 1 digit in the community for BCP38 control (including a "don't care"
option) and some other of the remaining digits in the community for some other
knobs regarding the reason for blackholing would be the way to go, IMHA.
Michel.
(1) http://arneill-py.sacramento.ca.us/cbbc/