Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Le 2014-01-22 11:54, Francis Dupont a écrit : On 20/01/2014 17:12, Simon Perreault wrote: IIRC, recent versions of Bind open a socket per address on IPv4 = not it is not by choice, just: - DNS requires to answer from the address the request was received - there is no standard/portable way to do this without the one socket per address in IPv4 (if you need an argument, just ask what this discussion is about :-) Exactly what I had guessed. Thanks for confirming. = BIND polls from time to time interfaces to bind() to new addresses (again, there is no standard/portable way to be notified. BTW we (ISC) know this is a point which can be improved so if you know a generic simple solution...) Listening on a routing socket doesn't qualify as generic nor simple, does it? ;) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
In your previous mail you wrote: On 20/01/2014 17:12, Simon Perreault wrote: IIRC, recent versions of Bind open a socket per address on IPv4 = not it is not by choice, just: - DNS requires to answer from the address the request was received - there is no standard/portable way to do this without the one socket per address in IPv4 (if you need an argument, just ask what this discussion is about :-) this feature was one of the main reasons I stopped using BIND. It has the side effect that you cannot necessarily set it up on a system which shares IP addresses using e.g. VRRP, because you cannot be guaranteed that the system will have the virtual IP address configured at the time that BIND starts. Frustrating. = BIND polls from time to time interfaces to bind() to new addresses (again, there is no standard/portable way to be notified. BTW we (ISC) know this is a point which can be improved so if you know a generic simple solution...) Regards francis.dup...@fdupont.fr (also fdup...@isc.org)
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
On 22/01/2014 16:54, Francis Dupont wrote: - there is no standard/portable way to do this without the one socket per address in IPv4 (if you need an argument, just ask what this discussion is about :-) i thought recvfrom() fixed this issue? Forgive me if I'm wrong here - it's been far too long since I've done any socket related stuff. = BIND polls from time to time interfaces to bind() to new addresses (again, there is no standard/portable way to be notified. BTW we (ISC) know this is a point which can be improved so if you know a generic simple solution...) server.c:load_configuration() has: interface_interval = cfg_obj_asuint32(obj) * 60; which means that the granularity for interface rescanning is per-minute. I'm not suggesting that per-second rescan would be a good idea, but per-minute is too long for workable failover with vrrp. Nick
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
On 22/01/2014 17:15, Mateusz Błaszczyk wrote: put a load-balancer in front of it. I would do this in an instant if I had an option to do it. vrrp is for network failover. it's for ip address failover. Nick
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
On 22 Jan 2014, at 17:10, Nick Hilliard wrote: server.c:load_configuration() has: interface_interval = cfg_obj_asuint32(obj) * 60; which means that the granularity for interface rescanning is per-minute. I'm not suggesting that per-second rescan would be a good idea, but per-minute is too long for workable failover with vrrp. put a load-balancer in front of it. vrrp is for network failover. -mateusz signature.asc Description: Message signed with OpenPGP using GPGMail
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, On Wed, Jan 22, 2014 at 12:00:05PM -0500, Simon Perreault wrote: Le 2014-01-22 11:54, Francis Dupont a écrit : On 20/01/2014 17:12, Simon Perreault wrote: IIRC, recent versions of Bind open a socket per address on IPv4 = not it is not by choice, just: - DNS requires to answer from the address the request was received - there is no standard/portable way to do this without the one socket per address in IPv4 (if you need an argument, just ask what this discussion is about :-) Exactly what I had guessed. Thanks for confirming. I was about to write it's not that hard, you have IP_PKTINFO on Linux and IP_RECVDSTADDR on *BSD - but then I remembered that bind runs on a *lot* more platforms than that, and I'm not sure if I want to know about the gory details on AIX, HP-UX, SCO, ... regarding this :-) OpenVPN is much more lucky here: it needs a tun/tap driver, so all the (nowadays) oddball platforms can not be supported anyway, which makes my life much easier (in a way). = BIND polls from time to time interfaces to bind() to new addresses (again, there is no standard/portable way to be notified. BTW we (ISC) know this is a point which can be improved so if you know a generic simple solution...) Listening on a routing socket doesn't qualify as generic nor simple, does it? ;) I'm fairly sure half of the platforms BIND runs on do not have routing sockets... so that part of the code is likely to be full of interesting bits and pieces as well. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, On Wed, Jan 22, 2014 at 05:10:17PM +, Nick Hilliard wrote: On 22/01/2014 16:54, Francis Dupont wrote: - there is no standard/portable way to do this without the one socket per address in IPv4 (if you need an argument, just ask what this discussion is about :-) i thought recvfrom() fixed this issue? Forgive me if I'm wrong here - it's been far too long since I've done any socket related stuff. recvfrom() will give you the source address of the packet, but not the destination address (*your* address where you received the packet on). recvmsg() will give that to you, but the interface for IPv4 is system dependent, and I'm fairly sure, not present everywhere bind runs. RFC 2292 / 3542 talk about the socket API extentions to get IPv6 destination addresses (IPV6_RECVPKTINFO), so with that and a bit of source code reading, you can figure out how it works for IPv4 (I haven't found actual docs for that yet). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
In your previous mail you wrote: On 22/01/2014 16:54, Francis Dupont wrote: - there is no standard/portable way to do this without the one socket per address in IPv4 (if you need an argument, just ask what this discussion is about :-) i thought recvfrom() fixed this issue? Forgive me if I'm wrong here - it's been far too long since I've done any socket related stuff. = recvfrom() returns the peer address, i.e., the source address of the request, when you need the local address, i.e., the destination address. = BIND polls from time to time interfaces to bind() to new addresses (again, there is no standard/portable way to be notified. BTW we (ISC) know this is a point which can be improved so if you know a generic simple solution...) server.c:load_configuration() has: interface_interval = cfg_obj_asuint32(obj) * 60; which means that the granularity for interface rescanning is per-minute. I'm not suggesting that per-second rescan would be a good idea, but per-minute is too long for workable failover with vrrp. = I'd like to say VRRP needs to be fixed but here the reasonable solution is to be notified... Regards francis.dup...@fdupont.fr
