Re: RFC 1918

["Scott McGrath" <s_mcgrath () bexair com>]

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/