> 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/