James Carlson wrote:
> John Leser writes:
>> In the course of creating test cases for Clearview's ipnet observability
>> feature, I've come across some cases where traffic can pass between zones
>> that I did not expect. This occurs when you bind a local address 127.0.0.1,
>> then connect or send to the IP address of another shared-stack zone (or the
>> global zone) on the system.
>>
>> This "succeeds" in both TCP and UDP cases. In the TCP case, traffic can
>> flow both ways, but in the UDP case, from what I can tell, if the receiver
>> attempts to reply to the message source, it will communicate with the
>> loopback (127.0.0.1) interface local to that zone. So in effect, the
>> listener is fooled into thinking the packet originated from inside the zone
>> where the listener is running.
>>
>> I'm interested in any opinions as to whether this is valid or desirable
>> behavior. Incidentally, IPv6 traffic from ::1 cannot cross zone boundaries
>> this way.
>
> When receiving packets set to a "real" (non-loopback) IP address, we
> should discard those packets with a bogus source -- including loopback
> and multicast. It's one of the implications of RFC 1122 section
> 3.2.1.3(g).
3.1.2.3(g) talks only about "outside a host", so I don't see how it
constrains our behavior here.
> When sending packets on socket bound to the loopback address, I think
> we should refuse (ENETUNREACH) to send to any non-loopback
> destination.
>
> That sounds like a pair of bugs to me.
Are we sure those are bugs? I think BSD allows such behavior. And I have
no idea whether applications may or may not depend on it.
We clearly shouldn't allow 127.0.0.1 be used as a source address when
sending packets out on the wire, but there isn't any harm in letting
them be delivered locally is there?
(Sure, shared-IP zones makes life more complex. I suggest we rip that
out and just use exclusive-IP zones ;-)
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
