On Wed, May 10, 2006 at 07:29:30AM +0200, Julien BLACHE wrote: > Francesco Paolo Lovergine <[EMAIL PROTECTED]> wrote: > > Hi, > > >> Huh? It's a IPv6 address, followed by a slash, followed by the number > >> of significant bits in decimal. Just like IPv4. > > > > Sorry, that's not what I meant. > > > > ::ffff:192.168.0.0/124 is correct, ::ffff:192.168.0.0/24 not. > > because the second address is a mixed ipv4-in-ipv6 spec, but must > > specify the whole 128 bit range, not the ipv4 form. > > Ah, ok, now it makes sense to reject that, indeed. As long as regular > IPv4 CIDR is supported :) >
The true problem is admin inconsistency ;) Unfortunately ::ffff:10.0.0.0/24 is a perfectly valid CIDR notation, but IS NOT what a naive user would expect, because IPV6 CIDR are on a 128bit range. So using that notation indeed open the daemon to all ipv4 addresses, as noted. Being defensive on that regards could help. My own opinion is that using a 32 bit CIDR value with a ipv4-into-ipv6 address should be at least warned or refused (as in the patch) because it's probably an admin error. Upstream patches refuses CIDR notation in IPv6 context at all which is sub-optimali, indeed. ::1/124 would be refused as well, for instance. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
