been there done that ;~} While I was at Networkers one of the sessions I attended briefly touched upon Cisco's new hack for dealing with this it was a combination of MPLS and NAT applied at the border router(s) to solve the overlap problem. I have been looking for more information because I do have some overlap problems "Eric A. Hall" wrote:
Imagine that you inherit a network where RFC1918 addresses are used on most or all backbone links.
Imagine you inherit two of them, and they're both using 10.1.x.x. That's the kind of trouble that end-users have as well. When their networks are running 10.1.1.x and they get ICMP messages from remote networks with that address, all kinds of problems can occur.
I noticed over the weekend I got a couple of ICMP Redirect messages from 1918 space. Lovely. Somebody doesn't understand how Redirect works, which is typical of the crap that comes in from 1918 space.
Filtering 1918 isn't just good practice for most of the leaves, it's mandatory in a lot of cases. No traffic should ever appear on the WAN link using that address (that would violate the spec, right?) so anything that does is bad traffic by definition. Filtered. Easy.
When ISPs choose to mark their packets with Internet-illegal addresses, they are contributing to these problems. Sorry, but you're not supposed to be using these addresses anyway.
Because it's reasonably difficult to get real addresses from ARIN
ARIN is absolutely the root cause of the 1918 problem. They're the principle driver behind the NAT market by extension as well. If it weren't for their qualification rules, the Internet would work a helluva lot better.
Imagine that. Management decides to limit address consumption, so the rats start duplicating addresses, building protocol gateways and crufting other hacks to get around the restriction. Who'd have thunk such a thing would happen.
-- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/