Hi Leo, I support this document and think it's important and very well written. I do have some overall comments and a couple of editorial suggestions:
At a high level, the document is arguing that with no more IANA unallocated /8s, then existing corresponding filters should be removed, and then lists special purpose prefixes that should not be router in the Internet. I think that the document could benefit from making a stricter classification of "bogons" from the Intro onwards, into "unallocated" and "martian"; then, "martian filters" do not change, but "unallocated" do (as continuously do, but now there is a notable milestone). These unallocated prefix filers now need to be larger than /8, but there is still value in filtering RIRs unallocated. So there is a choice of whether no longer filter based on address allocation status at all, or do it with finer granularity, with pros and cons. I think that the document should contain the final state (martians only) but list pros and cons of the transition (filter or not RIR unallocated prefixes). I do not want to suggest overcomplicating the document, as its simplicity is a plus, though. On the more editorial side, I think that perhaps slightly more emphasis on the fact that this is filtering on the "source" (even on the title) can prevent potential confusions. Similarly, a note of caution as to the application of filters (as some of the blocks can "appear", but not be Internet-routed. My 2ยข. Thanks ! -- Carlos. On 2/3/2011 9:40 AM, Leo Vegoda wrote: > Hi, > > I have just uploaded draft-vegoda-no-more-unallocated-slash8s-00 to the I-D > repository and have been advised to mention it on OPSEC and GROW, so that it > can be well reviewed. > > This document advises network operators to remove filters for any unicast /8s > they previously filtered on the basis of being unallocated. The IANA IPv4 > Address Space Registry is now fully allocated and so the practice of > filtering IPv4 address space based on its registration status is no longer > advisable. > > Your thoughts and comments are welcome. > > Kind regards, > > Leo Vegoda > _______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
