>| Log Message:
>| reject packets with 127/8 on IPv4 src/dst, they must not appear on wire
>| (RFC1122).  torture-tests will be welcomed.
>| XXX do we want to check source routing headers as well?
>I am unclear that this is the correct change. I'm not sure
>how to state this best, because some of it is in the realm of
>"I'm not sure that RFC1122 says that," and some of it is
>"even if RFC1122 says that, I'm not sure we should do it."
>
>The principles of simplicity and understandability say to me
>that we should not provide special treatment for one IP address
>over another, unless there is a compelling reason.

	I understand your concern.  maybe my commit message was poorly written.
	RFC1122 specifies sender rules only here.  it does not explicitly talk
	about receiver rules.

>It seems to me that there should be a counter for assocaited with rejecting
>these packets, if they are going to have a special case block of code
>(as they do in your patch). If you don't think so, I'd like to see the
>argument against.

	this is reasonable, will do.

>I feel like we're treating 127/8 specially for a reason that is not
>particularly good, though. It's not as if there is an important
>security issue here -- applications should not have been depending on
>127.0.0.1 as being a local IP address, and I am unclear on how this
>patch makes that sort of thing more secure, since we can still receive
>packets that are sourced from an IP address associated with any of our
>interface that are not 127.0.0.1. So I do not see how we get a
>security benefit.

	(for this part, I prefer it to stay in developers mailing list)

	basically, the patch was to protect against to-be-published advisory.
	did you see the draft for the advisory?  the advisory was about
	circumventing access control by taking advantage of weak host model
	(BSD falls into this category).

itojun