Phil Howard wrote:
Greg A. Woods wrote:
So are you making a case to allow RFC1918 source addresses out into the network?
Huh? No, I thought I was saying very much the opposite! I don't want my upstream provider to use RFC1918 on inter-router links, but they do anyway. I'd like them to filter those addresses too, but they won't.
I do agree they should be filtered out.
At what point should we draw the line and say who can, and who cannot, use RFC1918 addresses on links? My first thought would be any link over which traffic from more than one AS transits, or between AS's, should always be fully routable. Any better ideas?
My take on this is the line is at the edge of a single, end customer. In other words, a company which buys IP service from an ISP may use RFC 1918 addresses internally. An ISP should NOT use private address space in their own network for any equipment, with the exception of their administrative or management functions, provided those functions are restricted in scope to their own use. There should be no gear in the path from an end customer to peering points which use private address space. The reason I arrive at this conclusion is for the sake of the end user. The purpose, in my opinion, of the private address space described in RFC 1918 is to allow users to build large networks without consuming public address space. The goal was to provide someplace for private networks to go that'd be unique to themselves, provided they didn't talk to another private end user. Now what happens when a company has already used 10.x.x.x and built a large network, and uses NAT or proxies at their border, but their upstream ISP decides to also use 10.x.x.x for everything? There is real potential for conflict. What I find most annoying about my upstream using private address space for their own use is it takes away my ability to use that address space as an end customer, and could have required me to renumber to ensure there were no conflicts. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com