>I was thinking about private vs. public inet address space the other day, and
it occurred to
>me that with all the changing of authority with domain registrars and ip
authorities, that some things
>are bound to get fuddled in the near future. For instance, right now it is the
responsibility of the nic
>and a couple other core entities to delegate to the rest of the root-servers
crowd not to route the
>10.X's, 192.168.X's etc...,
NICs have nothing to do with routing. The closest thing to the scenario you're
talking about
is reverse name lookups. I don't expect any difficulty there. ISPs are
responsible for not leaking
RFC1918 addresses into the Internet, and would be even if DNS didn't exist.
>and if that responsibility expands past these few entities (especially seeing
as
>how aquisitions are occurring right and left), there is obvious room for
mistakes or confusion. We've all
>seen what happens when upstream ISPs fudge the routing tables, but I wonder
what the impact
>would be if one of the newcomers decided to route 10.0.1.X at the same time
another one did.
If ISPs screw up and start sending RFC1918 addresses into the Internet (which
happens often
enough), it shouldn't really matter. If more than one does it, too bad for them,
since they're not
supposed to be there in the first place.
>I believe
>it's possible that packets could end up on someone else's private net given the
appropriate fudging
>scenario. So what I'm wondering is ... among the firewall list folks, has
anyone seen any anomalies
>of this nature, and if so, what are the responses that stateful inspection vs.
packet filtering give on
>unexpected WAN behavior?
As a matter of course, firewall admins should implement anti-spoofing rules that
block (source)
addresses for their inside nets, any RFC1918 addresses, and anything above
223.255.255.255
(minus anything they wish to explicitly allow for MBONE, routing protocols,
etc..)
Ryan
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
