On Thu, 21 Oct 2010 06:38:33 +0200 Graham Beneke <graham@apolix.co.za> wrote:
On 21/10/2010 03:49, Matthew Kaufman wrote:
On 10/20/2010 5:51 PM, Owen DeLong wrote:
Part 2 will be when the first provider accepts a large sum of money to route it within their public network between multiple sites owned by the same customer.
Is this happening now with RFC 1918 addresses and IPv4?
I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN.
Part 3 will be when that same provider (or some other provider in the same boat) takes the next step and starts trading routes of ULA space with other provider(s).
Is this happening now with RFC 1918 addresses and IPv4?
I've seen this too. Once again small providers who pretty quickly get caught out by collisions.
The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess.
I don't think there is a difference. The very small providers are the ones who make the stupid mistakes, it's the larger ones that do the right thing because it is in their operational interests. Operational competence, and the resulting increased reliability, is one of the attributes customers of ISPs value highly. If any of the Tier-1s don't route ULA address space, then it is useless compared to global addresses that *are* routed by *all* the Tier-1s. As the Tier-1s also hire competent networking people, they'll also understand the scaling issues of the ULA address space, and why it shouldn't be globally routed. Competent networking people also exist at the lower tiers as well. If operators just blindly accept and implement what sales people tell them to, then those operators aren't operators. They're mindless drones - and the rest of the people operating the Internet will protect the Internet from them. Darwin eventually gets rid of those operators and the ISP that employ them. Since ULAs could be used as DoS attack sources, they'll also likely be filtered out by most people as per BCP38. Regards, Mark.