|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: RFC 1918
Being another fly on the wall who uses RFC 1918 addresses in a corporate networking setting, consider the following: (1) RFC 1918 addresses were never intended for use on the public Internet. (2) People who use RFC 1918 addresses on the public Internet are typically end users who can't spell RFC 1918 much less implement it. (3) Ill-intentioned users will use RFC 1918 addresses in their exploits. (4) RFC 1918 traffic cannot be properly routed once it leaves its originating subnet. (5) Filtering RFC 1918 addresses reflects best practices for managing Internet traffic. Why on earth would anyone object to filtering RFC 1918 traffic? For DSL or other leaf-node users, a list of solutions is easy: fixed IP address, NAT, proxy, etc. The problem is that it's an issue of training, communication, and standards enforcement. ISPs should not be responsible for their downstream's lack of understanding of basic Internet architecture. However, if an ISP wants to keep its customers from endless ignorance and frustration, it would not be a bad idea to offer resources by which users can gain a basic operational understanding that would at least keep them from making simple but costly mistakes. But we can't have it both ways. We can't get educated end users by endlessly telling them RTFM. We can't coerce them to have a clue. But we also can't simply shut them off. In doing so, we invite the backlash of frustration and its companion effects on revenue and reputation. And we can't fix it for them. They have to come to the conclusion that it's appropriate to seek information and act on it. They have to recognize that there are rules of engagement for building IT resources and connecting them to the Internet, and that many of these rules are non-negotiable. The filtering of RFC 1918 addresses is a simple, logical, and effective example. John Fraizer wrote: > > <snip> > The ruleset you use is great for a leaf-node. The problem it can > represent on the borders of a larger network is that a lot of nice script > kiddies like to spoof their source as RFC1918 space and since ICMP is 8 > times out of 10 their payload, using such on the edges exposes the core > (and potentially some poor customer of yours on a DS1, etc) to whatever > level of hate-and-discontent you're capable of accepting on the borders. > > --- > John Fraizer > EnterZone, Inc > </snip> -- -------------------------------------------------------------------------- Stephen Kowalchuk [email protected] Diamonex, Incorporated
|