Subject: Re: kern/9387: Forwarding loop on down interfaces
To: None <itojun@iijlab.net>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-net
Date: 02/15/2000 10:59:42
On Tue, 15 Feb 2000 21:51:04 +0900 
 itojun@iijlab.net wrote:

 > 	The logic on the PR (which is already committed) does not work
 > 	properly when:
 > 	- same IPv4 address (X) is assigned to two or more interfaces
 > 	- one of them is !IFF_UP
 > 	In this case, packet with ip_dst = X can be mistakingly dropped.
 > 
 > 	I really need clarification on what IFF_UP means, and the right
 > 	behavior.  In the following, suppose we've got a packet with
 > 	ip_dst = X.
 > 
 > 	Traditional 4.4BSD (and open/freebsd):
 > 		accept packets regardless form IFF_UP flag.
 > 		I believe this is because of the following thinking:
 > 		- IFF_UP means "layer-2 is down", not others
 > 		- IPv4 address lookup in "goto ours" logic should not consult
 > 		  layer-2 thing.  also, IPv4 address lookup is based on weak
 > 		  model (we accept the packet, even if the incoming interface
 > 		  != interface which has X)

I'm not entirely sure that this was the thinking when the original 4.4
code was written :-)  I'm thinking that the reason the check for IFF_UP
wasn't explicit before is because you don't expect to receive packets
on a down interface.

I.e. I almost think it was an oversight, more than anything.

 > 	NetBSD 1.4.1:
 > 		accept packets, only when interface which has X is IFF_UP.
 > 		non-accepted packet can be forwarded till TTL goes to 0
 > 		in the kernel (which is not pleasant)

Right, this is bad.

 > 	NetBSD-current (with nrt's patch):
 > 		accept packets, only when interface which has X is IFF_UP.
 > 		non-accepted packet result in icmp unreach.
 > 		(there's some mistake in icmp unreach decision)
 > 
 > 	We can fix it in multiple ways.  Which behavior is 'the right one'?

I think we want different behavior based on the value of ip_forwarding:

	if (ip_forwarding)
		send ICMP unreach
	else
		1.4.1 behavior (which results in the packet being dropped)

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>