Daniel Senie wrote:
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.
The conflict potential is real, but it is also discussed with customers. We'll deal with those conflicts. It's not an Internet issue, but rather, and issue between a provider and customer. If a customer asks for a non-RFC1918 link, we'll give them one. I'd like to see someone do something about the problems that happen, or happen to a greater extent, when /30 links are allocated out of routable space. Large ISPs have enough address space to dedicate a whole netblock to their links in one place. Small ISPs won't have that much. Yet with turnover, fragmentation still happens, and ARIN doesn't take SWIPs for /30. Thus we end up with holes that look like they are big enough to assign and use, but they aren't. Then we have to renumber to aggregate the holes. Since they are links, that means coordinating with customers to renumber their routers. Then there's the use of RFC1918 for DNS. It's entirely optional for our customers, as they can use the real address instead. We do this just to minimize the number of changes needed when we do need to renumber (which will happen again soon, and probably again in 2000 or 2001 as we grow). You have a bigger network w/o these problems, right? -- Phil Howard KA9WGN phil@intur.net phil@ipal.net