Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!rutgers!ucsd!ucbvax!PATTON.NYSER.NET!fedor
From: fedor@PATTON.NYSER.NET
Newsgroups: comp.sys.proteon
Subject: Re:  p4200 routing
Message-ID: <8812281536.AA05513@patton.nyser.net>
Date: 28 Dec 88 15:36:12 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 84


>Date: Sat, 24 Dec 88 09:40:02 EST
>From: Joe Ragland <jrr@ncnoc.tucc.edu>
>Subject: p4200 routing
>
>Mark:
>
>A local VMS host running CMU-TEK TCP/IP has revealed an interesting routing
>situation with the p4200s.  Turns out that if one says 'telnet 127.0.0.1'
>to the local host loopback address, CMU-TEK forwards the packets to
>suranet-gw.tucc.edu (p4200) which then forwards the packets down the
>default route.  Since Virginia is advertising default, the packets land
>on uvaarpa.virginia.edu and uvaarpa answers the telnet request.
>
>Question:  Should the p4200s be forwarding packets for net 127.0?  It 
>may be that this is one of those situations not explicitly covered in
>IP routing RFCs.  Whether or not this is the case, I think the p4200s
>should discard such packets with an appropriate error message.
>
>--Joe
>>>

	Joe,

	Way back in the beginning of NYSERNet the same situation
	happened, but it wasn't with mail, it was with the
	syslog messages.  Seems as if some ultrix machines were
	sending their syslog messages to localhost (127.0.0.1).
	The ultrix machines didn't have a route to the loopback
	interface (it was config'ed down).  So, the syslog
	messages happened to follow the default path of NYSERNet
	until it got to a machine that had a route to 127.0.0.1.
	Unfortunately, that was my machine! :^)

	Kind of amusing, but a definate pain.

	To answer your question, looking at my copy of RFC 1009:

	in section 2.1:

	(g) [127, <any>]

	    Internal host loopback address.  Should never appear
	    outside host.

	Then, in section 4.4 "Special addresses and Filters":

	"We can distinquish two classes of these special cases.
	 The first (cases (a), (b), (c), (g), (h), and (i) in
	 section 2.1) contains addresses which should never
	 appear in the destination address field of any IP datagram,
	 so a gateway should never be asked to route one of these
	 addresses.  However, in the real world of imperfect
	 implementation and configuration errors, such bad destination
	 addresses do occur.  It is the responsibility of the gateway
	 to avoid propogating such erroneous addresses; this is
	 especially important for gateways included in the global
	 interconnect system.  In particular, a gateway which receives
	 a datagram with one of these forbidden addresses should:

		1. Avoid inserting that address into its routing database
		   and avoid including it in routing updates to any
		   other gateway.

		2. Avoid forwarding a datagram containing that address as
		   a destination.

	To enforce these restrictions, it is suggested that a gateway
	include a configurable filter for datagrams and routing
	updates. ......"

	So, it seems as if the P4200 is compliant with the RFC as it
	has a filter mechanism available.  The question is, should the
	filter for 127.0.0.0 be automatically enabled or should it be
	a manual thing like it is now.

	Maybe a line in the proteon users manual about "recommending
	this filter"  if the gateway is participating in the internet.

	What do you think?

	Mark

	P.S.  If you want to get picky, your CMU-TEK IP is broken.