Hi Mildis,

>> And regarding "2001:db8::1234", you can't forbit it simply because you
>> don't know if 1234 is a port or not in this context, as you have
>> reported.
>
> Sure. In this very specific case 1234 can’t be a port as 2001:db8:: is
> then a subnet.

For the record: you can't know that, unless you know the subnetmask.

I can assign 2001:db8::/128 to a loopback and bind a service to it,
I can bind 2001:db8::/127 to one box and connect it to a box with
2001:db8::1/127 on the other side.

I can also configure 2001:db8::/16 on box on my private network,
where 2001:: is the subnet IP, not 2001:db8::.

A lot of valid configurations out there, you can't assume that all
configurations are simple and straightforward unicast LAN networks.

It is then the kernels job to reject binds to adresses it considers
invalid (for example due to subnetting), but the application does not
(and imho *must not*) be subnet aware.



Regarding the patch: I think this is very useful and I like the square
brackets very much. I'm always scratching my head when I see a ipv6 bind
configuration in haproxy and the square brackets fix this interpretation
problem once and for all (for users that want to use them, others just
keep using current notation).


Thanks for this!



Regards,

Lukas

                                          

Reply via email to