On 22 Apr 99, at 16:44, Bret wrote:
> ---Reply to mail from David Gillett about read-rfc1918-for-details.iana.net
>
> > On 22 Apr 99, at 11:08, Bret wrote:
> >
> >> RFC1918 Addresses are not routable back to the small business, so
> >
> > So packets with these as originating IPs have no business being passed on
> > across the Internet. Especially when these anonymous goodies could be
> > carrying nasty payloads.
> >
>
> Technically yes, however in theory that doesnt work right.. People config
> routers with the primary interface being a RFC1918 addr.. If I do a
> traceroute to see if something is broke, then I may find that it goes to
> provider A and then hits a RFC1918 addr, then breaks.. Well that lets me
> know that it at least got to that router and gives me a little more info
> to try to get a problem resolved (quicker)..
Sorry, you've lost me.
If you do a tracert against an RFC1918 address, the first thing that's going
to happen is a reverse DNS lookup -- which, as I understand it, is part of
what has prompted this change. I know that we have DNS set up locally *for
the RFC1918 addresses that we use locally*, so my reasonable(?) expectation
is that reverse lookups hitting the root servers are against RFC1918 ranges
*not in use at the querying sites*. [Of course, my idea of "reasonable" may
not apply elsewhere.]
Having done a reverse-DNS lookup, tracert is then going to try to send to
the RFC1918 address. This, of course, will die at the first router it hits;
AFAIK, this is regardless of whether that router happens to use an RFC addr
on its primary interface. I suppose it's possible that it will show slightly
different results if the greakage that leaked the packet is actually *on* the
router nearest to me, but what are the odds of that?
> Net admins/firewall admins should filter all outbound traffic that isnt
> from one of their assigned network numbers.. This makes it harder for
> people to accidentally or intentionally spew out garbage (but wont prevent
> a dns lookup on a RFC1918 addr) that shouldnt go outside.. But experience
> shows that this isnt gonna happen globally any time soon :)
I agree -- they (we!) should do it, and, by and large, can't or won't.
BUT ... I assume that hosts don't just sit there all day doing reverse
lookups against random RFC1918 addresses. They do lookups (quite possibly
automatically...) against specific addresses to try and see where traffic
from unrecognized hosts is coming from. The volume of traffic to root
servers that prompted this change isn't IMHO "the problem", it's a *symptom*,
and I don't see that the answer "somebody has misconfigured something
somewhere" fixes anything. Putting recognition of RFC1918 addresses into the
world's resolver libraries (like that would ever happen!) would at least cut
down on the root server traffic, but still doesn't help locate address leaks
or sources of spoofed traffic.
David G
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
