RE: ingress filtering

[Eric Germann <ekgermann () cctec com>]

At 08:57 AM 5/29/98 -0400, jeyers () ialn com wrote:
> -----Original Message-----
> From: Eric Germann [mailto:ekgermann () cctec com]
> Sent: Friday, May 29, 1998 8:09 AM
> To: John Fraizer
> Cc: Mr. Dana Hudes; nanog () merit edu
> Subject: Re: ingress filtering
>
> At 02:32 PM 5/28/98 -0400, John Fraizer wrote:
>
> > Actually it has nothing to do with WINS.  If all the ISP's would
> implement
>
> Bzzt.  Thank you for playing, though.  If it were not for WinS, there
> wouldn't
> be a second packet being sent, no matter what junk is the payload.

Buzz, again.  Try reading about WINS.  It is a manifestation of a NetBIOS
name server as defined in RFC 1001/1002.  If it were using WINS for this,
it would NOT hit the target machine, but the WINS server.  Also, if DNS can
resolve the in-addr.arpa mapping, the second packet is never sent.  Ergo,
it has nothing to do with WINS.


> > solid in-addr.arpa reverse mappings, this would go away.  Microsoft's
> DNS
> > resolver has been extended, when DNS lookups fail, to do a reverse
> NETBIOS
> > query against the target machine so it can use its name when displaying
> > stuff via NBTSTAT, etc.  It was designed this way, before the Internet
> > became popular.
>
> Excuse me?  I was using the Internet way before Microshaft was a dream
> in Bill's
> head.  The RFC's you quote were rammed into existance by DARPA to
> provide early
> ecanpsulation techniques so that companies like MS could say they were
> IP/Internet
> compatible, (instead of using a real protocol) and get away from Novel
> slamming
> them for non-routable protocol support only.  All they did was to take
> the same 
> non-routable junk and throw it inside an ip packet and call it
> "internet" 
> compatible.  The RFC's quoted provide a way to make that encapsulation
> work, they
> do not recommend conversion to that as a standard.  To encourage that
> kind of
> conversion would be a major leap backwards.  (Wow! let's all abandon our
> routeable
> protocols and use a non-routed local segment only, encapsulated
> protocol.  Yippee!)
>
> Now I agree ISP's should do better DNS resolution, but every MS box
> plugged into
> the net sending a second packet adds up to a lot of junk packets eating
> up 
> expensive bandwidth.  MS catches the blunt of the critisizm because they
> are the
> only ones to have adopted such a lame networking scheme, and then forced
> it
> down others quotes.

Again, do solid reverse DNS and the problem goes away.  It only does it iff
reverse DNS fails. Period.  As for timing, MS didn't give a shit about IP
at the time they were written.  MS wasn't even directly in the business at
the time.   Repeat after me, NetBIOS is a programming interface, not a
protocol.  Write it 100 times and them come back and play the game.

NetBIOS is neither inherently routable or nonroutable.  It depends on the
underlying transport protocol, be it XNS, IPX, IP, OSI or proprietary
NetBEUI.  

As for forcing it down others "quotes", the industry picked it.  MS
networking will run quite happily over any of the above mentioned transport
protocols.  Your customers selected it.  Do your reverse DNS right, and you
won't have the problem.


=============================================================================
Eric Germann                         Computer and Communications Technologies
ekgermann () cctec com                                        Van Wert, OH 45891
                                                          Phone: 419 968 2640

http://www.cctec.com                                        Fax: 419 968 2641
Network Design, Connectivity & System Integration Services 
A Microsoft Solution Provider