On Tue, Nov 14, 2006 at 11:31:57AM +0100, Joerg Sonnenberger wrote: > On Tue, Nov 14, 2006 at 10:00:54AM +0100, Simon 'corecode' Schubert wrote: > > Joerg Sonnenberger wrote: > > >At least the IPv6 case is incomplete as it doesn't deal with mapped ipv4 > > >addresses. I also don't think the behaviour for INADDR_ANY is correct. > > > > Could you elaborate on that? How should mapped ipv4 addresses be handled? > > I guess there would need to be a check for already used ipv4 addresses, and > > vice versa. > > If mapped IPv4 addresses are allowed, they should get exactly the same > handling as normal IPv4 addresses. Esp. mapped 127.0.0.1 needs to be > handled accordingly.
The mapped ipv4 addresses needs further investigation, i'll check it ASAP. > > > What behaviour for INADDR_ANY would be correct? (If you can use this term) > > When a socket is allowed to bind to INADDR_ANY two things have to be > guarantied: > (a) Connections to it are effectively only allowed, when one of the jail > IPs can be used. E.g. if the jail is bound to 192.168.1.1 and 10.1.1.1, > but the machine has also 176.1.1.1 as IP, a connection to that must not > go to the jail. This is already guaranteed. > (b) Connections *from* the jail must use one of the jail addresses as > source. E.g. when the jail is bound to 192.168.1.1 as before, a > connection to 10.1.1.2 must not use 10.1.1.1 as soure address. > > This gets further complicated by the question whether or not binding to > broadcast and/or multicast addresses should be enabled by default. Multicast is not supported in jails. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros.