On Tue, 18 Sep 2007, YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[(B wrote:I missed the beginning of the discussion, so apologies if I'm way off base. it sounds like the question is, when a packet hits the box that causes a icmp_reply (or other packet) to be generated, which IP address should be used as the source 1. the destination address of the packet that generated the message or. 2. the IP address that the machine would use by default if the machine were to generate a new connection to the destination. I understand that in many cases the historical approach has been #2, but as more machines get multiple IP addresses on each interface, I believe that it's less of a surprise to other systems if the default is #1. most of the time the other systems don't care (and useusally don't want to know) if the service they are contacting is on a dedicated machine or is just one IP among many sharing a box. it gets especially bad when you have load balancing going on and the results could come from multiple boxes. yes, sysadmins deal with this today, but it's a pain to do so and is a continuing dribble of suprises when things don't quite work the way you expect them to as you consoldate things onto more powerful systems (or distribute them among multiple systems). if the packet got to the machine and the machine is accepting it, replying back from the destination IP of that packet should be legitimate (it's what you would do if there was a full connection after all) and greatly reduces the cases where things change. David Lang -
| Davide Libenzi | Re: [patch 7/8] fdmap v2 - implement sys_socket2 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Mariusz Kozlowski | [KJ PATCHES] mostly kmalloc + memset conversion to k[cz]alloc |
git: | |
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| Stefan Richter | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
