Hi Willy,
My bad : in the doc, I didn’t get the « add a colon without a port to
end an address » trick.
That’s why I was lost at first.
The doc obviously says ‘<address>[:[port]]’ making the port optional and
an ending colon valid but it looks like a typo to me as ending an IPv6
address with a colon is not one of my habit.
The provided patch sent initially should handle square brackets but
still makes the colon mandatory even with no port.
I’ll rework it so it accepts :
- 2001:db8::1234: as IPv6 no port (for backward compatibility)
- [2001:db8::1234] as IPv6 no port
- [2001:db8::1234]:80 as IPv6 with port
but forbid ‘[2001:db8::1234]:’ and ‘2001:db8::1234’
Would it makes sense to you ?
mildis
Le 2015-10-06 11:11, Willy Tarreau a écrit :
On Mon, Oct 05, 2015 at 06:42:52PM +0200, Mildis wrote:
Le 2015-10-05 18:07, David du Colombier a écrit :
>>It looks like IPv6 parsing may lead to errors.
>>The logic cannot distinguish from ???2001:db8::1234:80??? as :
>>- a plain IPv6 address 2001:db8::1234:80
>>- IPv6 2001:db8::1234 on port 80
>
>As far I remember, to prevent this confusion, we made the final
>colon mandatory on IPv6 addresses. This way, anything before
>the final colon is the address.
>
>If you don't want to specify the port explicitly, the address
>ends with a colon.
Technically, it???s seem OK.
But it should be less haproxy-centric to stick to an RFC.
We support all the formats mandated by RFCs 1884, 2373, 3513,
and 4291. The address format doesn't mandate the use of a port
which is a transport-layer issue. Many (most) products have
historically supported <address>:<port> to group layer 3 and
layer 4 information in a same word. And haproxy is no exception
and has supported this for 15 years in all places where an
address was expected since the port was almost always there.
Thus when introducing IPv6, it was natural that only the address
part had to be distinguished between IPv4 and IPv6. At some point
we added the ability to support port-less addresses at certain
places (eg: server addresses). In order to leverage the ambiguity
it could raise, these ones had the trailing colon mandatory.
We could also decide to add support for brackets in the address
parser so that it's possible to write [address]:port like in URLs,
I'm fine with this, though I'm not the one who will spend time on
this right now.
And by the way I think that the format is perfectly clear in the
documentation.
Regards,
Willy