>Brian <[EMAIL PROTECTED]> wrote,
>On Mon, 26 Feb 2001, Bradley J. Wilson wrote:
>
>> ElephantChild wrote:
>>
>> RFC 1918, section 3:
>>
>> "[...]Because private addresses have no global meaning, routing
>> information
>> about private networks shall not be propagated on inter-enterprise
>> links, *and packets with private source or destination addresses
>> should not be forwarded across such links.*"
>>
>> ...But that's not what's happening in the case of the traceroute which
>> started this discussion. The only reason we're seeing those private
>> addresses is because we're basically snooping around in someone else's
>> network. RFC 1918 is still being upheld - privately-addressed traffic is
>> not being forwarded over inter-enterprise links.
>
>and the packets being sourced or destined are not being done from rfc1918
>space, just passing thru it.
While what you say is true about the "forward path," onto which I
send normal traffic or the UDP probes of traceroute, the ICMP
TTL-exceeded responses that define the traceroute responses have the
source address of the router interfaces that generated them. If
these interfaces are RFC1918 numbered, and the address originating
the traceroute is in registered space, there become only two
alternatives:
1. Packets with RFC1918 source addresses have to enter registered space
2. There will be no response to the traceroute.
>
>>
>> The difference is this: "information about private networks shall not be
>> *propogated*"...meaning my routers must not actively advertise my private
>> networks to external ASes. Well, okay - the ISP isn't doing that. But when
>> we trace through a network using private addresses, we will see them - we're
>> snooping around, but the routers aren't actively propogating those private
> > numbers.
As best as I can see, you would want a "hole" put through the RFC
2827 ingress filtering filters (or equivalents with reverse path
verification), which state that Best Current Practice is to block any
packet sourced from an address to which you have no active route.
To open an exception for ICMP, without maintaining state that you
have issued a traceroute, is an open invitation for denial of service
attack. To keep state that you have issued a traceroute, you impose
a significant performance hit on the routers involve.
Even if I could implement all these special cases, the reality
remains that more than one provider in the path could use the same
RFC1918 address, and I now have accurate traceroute results that are
utterly confusing and indistinguishable from traceroutes of looping
paths.
> >
>> I'm excited about IPv6...but if we can make v4 last a little while longer,
>> hey, let's do it. ;-)
>>
> > BJ
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
