Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi,
On Thu, 10 Jan 2013 00:23:01 +
Ben Morrow b...@morrow.me.uk said:
ben ip6addrctl does more than just order v4 vs v6: it also sorts the v6
ben addresses, in a way which can be quite important. IMHO both the v6
ben addresses returned from getipnodebyname and the addresses returned from
ben gethostbyname2(AF_INET6) ought to be sorted according to ip6addrctl,
ben even if getipnodebyname special-cases the v4-mapped addresses to appear
ben last.
Okay, it seems reasonable. I've just committed to obey ip6addrctl
only for IPv6 address:
http://svnweb.freebsd.org/changeset/base/245256
As for gethostbyname2, it doesn't obey ip6addrctl in the first place,
and it is hard to obey ip6addrctl. So, I leave it as is.
ben Well, if important applications like Sendmail are still using it it's
ben probably important it works consistently with the rest of the system's
ben IPv6 support. I'd rather see it removed, or reimplemented as a wrapper
ben around getaddrinfo, than left in a broken state.
I don't think our getipnodebyname is broken. We tried to implement
getipnodebyname with getaddrinfo backend without success in years
past. As the result, implementation of getipnodebyname has become
like now.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi,
On Wed, 9 Jan 2013 20:28:28 +0100
Ulrich Sp$(D+S(Brlein u...@freebsd.org said:
uqs The source address problem I'm now talking about is happening on my
uqs router at home, which has a Sixxs tunnel and needs to use AICCU of all
uqs things to talk to the outside world, sixxs-aiccu will create the tun(4)
uqs interface and set it up like this:
uqs tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280
uqs options=8LINKSTATE
uqs inet6 fe80::230:5ff:fe77:e7a0%tun0 prefixlen 64 scopeid 0xd
uqs inet6 fe80::2428:ff00:1b:2%tun0 prefixlen 64 scopeid 0xd
uqs inet6 2a02:2528:ff00:1b::2 -- 2a02:2528:ff00:1b::1 prefixlen 128
uqs nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
uqs Opened by PID 82756
uqs and I'd like to have ipv6 connection originating from this host use
uqs 2a02:2528:ff0d::1%em0 instead of 2a02:2528:ff00:1b::2%tun0 as the
uqs outgoing address. That tun0 interface can come and go, btw, which
uqs complicates things. Is this possible? Or should I just switch to the one
uqs local DSL provide I have here that actually offers native IPv6 for home
uqs DSL users?
It is impossible with RFC 6724 / 3484 as hrs@ said. So, I made
modification.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
On 01/08/2013 23:33, Hiroki Sato wrote:
Ulrich Spörlein u...@freebsd.org wrote
in 20130108184051.gi35...@acme.spoerlein.net:
uq After setting this, it now looks like this:
uq root@acme: ~# ip6addrctl
uq Prefix Prec Label Use
uq ::1/128 50 00
uq ::/0 40 10
uq 2002::/16 30 20
uq ::/96 20 30
uq :::0.0.0.0/96 10 40
uq
uq And even sendmail is happily finding the sockets to bind to. Thanks for the
hint!
I think this just hides the problem. If gshapiro@'s explanation is
correct, no :::0.0.0.0/96 address should be returned if the name
resolution works fine...
-- Hiroki
getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:-
If a host has both IPv6 and IPv4 addresses, both are returned.
The IPv4 address is presented as a mapped address.
The order in which the addresses are returns depends on the
address selection policy (_hpreorder in lib/libc/net/name6.c)
#include netinet/in.h
#include netdb.h
#include resolv.h
#include stdio.h
static void resolve(const char *);
int main(int argc, char *argv[])
{
int i;
for (i = 1; i argc; i++) {
resolve(argv[i]);
}
return 0;
}
static void resolve(const char *hostname)
{
struct hostent *h;
char **a;
int i;
int e = 0;
h = getipnodebyname(hostname, AF_INET6, AI_DEFAULT|AI_ALL, e);
if (!h) {
return;
}
printf(h_name: %s\n, h-h_name);
for (a = h-h_aliases; *a; a++) {
printf( alias: %s\n, *a);
}
printf(h_addrtype: %d\n, h-h_addrtype);
printf(h_length: %d\n, h-h_length);
for (a = h-h_addr_list; *a; a++) {
printf(h_length: %d\n, h-h_length);
printf( address: 0x);
for (i = 0; i h-h_length; i++) {
printf(%02x, (unsigned char)(*a)[i]);
}
printf(\n);
}
}
prefer_ipv4:
$ ./a.out youtube.com
h_name: youtube.com
h_addrtype: 28
h_length: 16
h_length: 16
address: 0xadc241be
h_length: 16
address: 0xadc2415b
h_length: 16
address: 0xadc2415d
h_length: 16
address: 0xadc24188
h_length: 16
address: 0x2a00145040130c5b
prefer_ipv6:
$ ./a.out youtube.com
h_name: youtube.com
h_addrtype: 28
h_length: 16
h_length: 16
address: 0x2a00145040130c5b
h_length: 16
address: 0xadc2415b
h_length: 16
address: 0xadc2415d
h_length: 16
address: 0xadc24188
h_length: 16
address: 0xadc241be
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi,
On Wed, 09 Jan 2013 07:33:54 +0900 (JST)
Hiroki Sato h...@freebsd.org said:
hrs I think this just hides the problem. If gshapiro@'s explanation is
hrs correct, no :::0.0.0.0/96 address should be returned if the name
hrs resolution works fine...
I changed getipnodebyname to obey ip6addrctl in years past. I read
RFC 2553 again, and realize that it mentions IPv6 addresses are
returned 1st. So, my past change might be bad thing. X-(
However, I'm still curious about use of AI_ALL in sendmail. As far as
I read the source of sendmail briefly, it seems the usage doesn't
depend on AI_ALL.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
On Wed, 2013-01-09 at 14:14:18 +0100, Michiel Boland wrote: On 01/08/2013 23:33, Hiroki Sato wrote: Ulrich Spörlein u...@freebsd.org wrote in 20130108184051.gi35...@acme.spoerlein.net: uq After setting this, it now looks like this: uq root@acme: ~# ip6addrctl uq Prefix Prec Label Use uq ::1/128 50 00 uq ::/0 40 10 uq 2002::/16 30 20 uq ::/96 20 30 uq :::0.0.0.0/96 10 40 uq uq And even sendmail is happily finding the sockets to bind to. Thanks for the hint! I think this just hides the problem. If gshapiro@'s explanation is correct, no :::0.0.0.0/96 address should be returned if the name resolution works fine... -- Hiroki getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:- If a host has both IPv6 and IPv4 addresses, both are returned. The IPv4 address is presented as a mapped address. The order in which the addresses are returns depends on the address selection policy (_hpreorder in lib/libc/net/name6.c) Is this also supposed to work for selecting the source IP address for outgoing packets/sockets? And should it work for ping6? Using a tunnel for IPv6, I have this transfer net configured on my router, but for ACL purposes I would like to have all connections come from my real prefix, not the transfer net. So I wrote my own policy, yet ping6 seems to ignore it. The tunnel: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280 options=8LINKSTATE inet6 fe80::230:5ff:fe77:e7a0%tun0 prefixlen 64 scopeid 0xd inet6 fe80::2428:ff00:1b:2%tun0 prefixlen 64 scopeid 0xd inet6 2a02:2528:ff00:1b::2 -- 2a02:2528:ff00:1b::1 prefixlen 128 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL The policy: root@coyote:~# ip6addrctl Prefix Prec Label Use ::1/128 50 00 ::/0 40 1 107 2002::/16 30 20 ::/96 20 30 :::0.0.0.0/96 10 40 2a02:2528:ff0d::/64 60 5 85 The ping: root@coyote:~# ping6 acme PING6(56=40+8+8 bytes) 2a02:2528:ff00:1b::2 -- 2a01:4f8:131:23c2::1 16 bytes from 2a01:4f8:131:23c2::1, icmp_seq=0 hlim=54 time=43.606 ms 16 bytes from 2a01:4f8:131:23c2::1, icmp_seq=1 hlim=54 time=42.871 ms As you can see, source prefix stays 2a02:2528:ff00, though I'd like it to be 2a02:2528:ff0d. Cheers, Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
Ulrich Spörlein u...@freebsd.org wrote in 20130109142111.gl35...@acme.spoerlein.net: uq On Wed, 2013-01-09 at 14:14:18 +0100, Michiel Boland wrote: uq On 01/08/2013 23:33, Hiroki Sato wrote: uq Ulrich Spörlein u...@freebsd.org wrote uq in 20130108184051.gi35...@acme.spoerlein.net: uq uq uq After setting this, it now looks like this: uq uq root@acme: ~# ip6addrctl uq uq Prefix Prec Label Use uq uq ::1/128 50 00 uq uq ::/0 40 10 uq uq 2002::/16 30 20 uq uq ::/96 20 30 uq uq :::0.0.0.0/96 10 40 uq uq uq uq And even sendmail is happily finding the sockets to bind to. Thanks for the hint! uq uq I think this just hides the problem. If gshapiro@'s explanation is uq correct, no :::0.0.0.0/96 address should be returned if the name uq resolution works fine... uq uq -- Hiroki uq uq uq getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:- uq uq If a host has both IPv6 and IPv4 addresses, both are returned. uq The IPv4 address is presented as a mapped address. uq The order in which the addresses are returns depends on the uq address selection policy (_hpreorder in lib/libc/net/name6.c) uq uq Is this also supposed to work for selecting the source IP address for uq outgoing packets/sockets? And should it work for ping6? Yes. uq Using a tunnel for IPv6, I have this transfer net configured on my uq router, but for ACL purposes I would like to have all connections come uq from my real prefix, not the transfer net. So I wrote my own policy, yet uq ping6 seems to ignore it. uq As you can see, source prefix stays 2a02:2528:ff00, though I'd like it uq to be 2a02:2528:ff0d. This is because the prefix on the interface has the first priority. Why don't you use an fe80::/10 address to route packets to the other endpoint of tun0? -- Hiroki pgpFTwL8cirug.pgp Description: PGP signature
Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi,
On Wed, 09 Jan 2013 23:42:10 +0900 (JST)
Hiroki Sato h...@freebsd.org said:
hrs This is because the prefix on the interface has the first priority.
hrs Why don't you use an fe80::/10 address to route packets to the other
hrs endpoint of tun0?
I don't like this policy. I think it reduce the availability of the
policy table. So, I'm disabling it locally by applying the attached
patch.
Sincerely,
Index: sys/netinet6/in6_src.c
diff -u -p sys/netinet6/in6_src.c.orig sys/netinet6/in6_src.c
--- sys/netinet6/in6_src.c.orig 2011-09-23 09:51:37.0 +0900
+++ sys/netinet6/in6_src.c 2011-10-08 20:44:31.583463740 +0900
@@ -369,10 +369,12 @@ in6_selectsrc(struct sockaddr_in6 *dstso
*/
/* Rule 5: Prefer outgoing interface */
- if (ia_best-ia_ifp == ifp ia-ia_ifp != ifp)
- NEXT(5);
- if (ia_best-ia_ifp != ifp ia-ia_ifp == ifp)
- REPLACE(5);
+ if (!(ND_IFINFO(ifp)-flags ND6_IFF_NO_PREFER_IFACE)) {
+ if (ia_best-ia_ifp == ifp ia-ia_ifp != ifp)
+NEXT(5);
+ if (ia_best-ia_ifp != ifp ia-ia_ifp == ifp)
+REPLACE(5);
+ }
/*
* Rule 6: Prefer matching label
Index: sys/netinet6/nd6.h
diff -u sys/netinet6/nd6.h.orig sys/netinet6/nd6.h
--- sys/netinet6/nd6.h.orig 2011-09-23 09:51:37.0 +0900
+++ sys/netinet6/nd6.h 2011-10-08 20:46:47.972777802 +0900
@@ -86,6 +86,7 @@
#define ND6_IFF_DONT_SET_IFROUTE 0x10
#define ND6_IFF_AUTO_LINKLOCAL 0x20
#define ND6_IFF_NO_RADR 0x40
+#define ND6_IFF_NO_PREFER_IFACE 0x80 /* XXX: not related to ND. */
#define ND6_CREATE LLE_CREATE
#define ND6_EXCLUSIVE LLE_EXCLUSIVE
Index: usr.sbin/ndp/ndp.8
diff -u usr.sbin/ndp/ndp.8.orig usr.sbin/ndp/ndp.8
--- usr.sbin/ndp/ndp.8.orig 2011-09-23 09:51:37.0 +0900
+++ usr.sbin/ndp/ndp.8 2011-10-08 20:44:31.586462415 +0900
@@ -201,6 +201,15 @@
selection, see the
.Pa IMPLEMENTATION
file supplied with the KAME kit.
+.It Ic no_prefer_iface
+The address on the outgoing interface is preferred by source addess
+selection rule.
+If this flag is set, stop treating the address on the
+.Ar interface
+as special even when the
+.Ar interface
+is outgoing interface.
+The default value of this flag is off.
.It Ic disabled
Disable IPv6 operation on the interface.
When disabled, the interface discards any IPv6 packets
Index: usr.sbin/ndp/ndp.c
diff -u -p usr.sbin/ndp/ndp.c.orig usr.sbin/ndp/ndp.c
--- usr.sbin/ndp/ndp.c.orig 2011-09-23 09:51:37.0 +0900
+++ usr.sbin/ndp/ndp.c 2011-10-08 20:44:31.588462742 +0900
@@ -1011,6 +1011,9 @@ ifinfo(ifname, argc, argv)
#ifdef ND6_IFF_PREFER_SOURCE
SETFLAG(prefer_source, ND6_IFF_PREFER_SOURCE);
#endif
+#ifdef ND6_IFF_NO_PREFER_IFACE
+ SETFLAG(no_prefer_iface, ND6_IFF_NO_PREFER_IFACE);
+#endif
SETVALUE(basereachable, ND.basereachable);
SETVALUE(retrans, ND.retrans);
SETVALUE(curhlim, ND.chlim);
@@ -1088,6 +1091,10 @@ ifinfo(ifname, argc, argv)
if ((ND.flags ND6_IFF_PREFER_SOURCE))
printf(prefer_source );
#endif
+#ifdef ND6_IFF_NO_PREFER_IFACE
+ if ((ND.flags ND6_IFF_NO_PREFER_IFACE))
+ printf(no_prefer_iface );
+#endif
}
putc('\n', stdout);
#undef ND
Index: sbin/ifconfig/af_inet6.c
diff -u -p sbin/ifconfig/af_inet6.c.orig sbin/ifconfig/af_inet6.c
--- sbin/ifconfig/af_inet6.c.orig 2011-09-23 09:51:37.0 +0900
+++ sbin/ifconfig/af_inet6.c 2011-10-08 20:55:17.871353069 +0900
@@ -511,6 +511,8 @@ static struct cmd inet6_cmds[] = {
DEF_CMD(-prefer_source,-ND6_IFF_PREFER_SOURCE,setnd6flags),
DEF_CMD(auto_linklocal,ND6_IFF_AUTO_LINKLOCAL,setnd6flags),
DEF_CMD(-auto_linklocal,-ND6_IFF_AUTO_LINKLOCAL,setnd6flags),
+ DEF_CMD(no_prefer_iface,ND6_IFF_NO_PREFER_IFACE,setnd6flags),
+ DEF_CMD(-no_prefer_iface,-ND6_IFF_NO_PREFER_IFACE,setnd6flags),
DEF_CMD_ARG(pltime, setip6pltime),
DEF_CMD_ARG(vltime, setip6vltime),
DEF_CMD(eui64, 0, setip6eui64),
Index: sbin/ifconfig/af_nd6.c
diff -u -p sbin/ifconfig/af_nd6.c.orig sbin/ifconfig/af_nd6.c
--- sbin/ifconfig/af_nd6.c.orig 2011-09-23 09:51:37.0 +0900
+++ sbin/ifconfig/af_nd6.c 2011-10-08 20:57:46.484522687 +0900
@@ -58,7 +58,7 @@ static const char rcsid[] =
#define MAX_SYSCTL_TRY 5
#define ND6BITS \020\001PERFORMNUD\002ACCEPT_RTADV\003PREFER_SOURCE \
\004IFDISABLED\005DONT_SET_IFROUTE\006AUTO_LINKLOCAL \
- \007NO_RADR\020DEFAULTIF
+ \007NO_RADR\010NO_PREFER_IFACE\020DEFAULTIF
static int isnd6defif(int);
void setnd6flags(const char *, int, int, const struct afswtch *);
Index: sbin/ifconfig/ifconfig.8
diff -u sbin/ifconfig/ifconfig.8.orig sbin/ifconfig/ifconfig.8
--- sbin/ifconfig/ifconfig.8.orig 2011-09-23 09:51:37.0 +0900
+++ sbin/ifconfig/ifconfig.8 2011-10-08 20:53:47.050796897 +0900
@@ -690,6 +690,13 @@
.It Cm -prefer_source
Clear a flag
.Cm prefer_source .
+.It Cm no_prefer_iface
+Set a flag to not prefer address on the interface as candidates of the
+source address for outgoing packets, even when the interface is
+outgoing interface.
+.It Cm -no_prefer_iface
+Clear a flag
+.Cm no_prefer_iface .
.El
.Pp
The
Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi,
On Wed, 09 Jan 2013 23:01:52 +0900
Hajimu UMEMOTO u...@freebsd.org said:
ume I changed getipnodebyname to obey ip6addrctl in years past. I read
ume RFC 2553 again, and realize that it mentions IPv6 addresses are
ume returned 1st. So, my past change might be bad thing. X-(
I've just committed to disable it:
http://svnweb.freebsd.org/base?view=revisionrevision=245225
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
Quoth Hiroki Sato h...@freebsd.org: Gregory Shapiro gshap...@freebsd.org wrote in 20130108180920.gj36...@rugsucker.smi.sendmail.com: gs How can I unstupid sendmail here? gs gs I don't think sendmail is being stupid here as it is doing what it has gs been doing under 8.x and 9.1 (the code is the same). I think gs something changed with the upgrade to 9.1. As far as tracking it gs down, the sendmail code does: gs gs getipnodebyname(acme.spoerlein.net, AF_INET6, AI_DEFAULT|AI_ALL, gs err); gs gs This will only return an IPv4 mapped address if: gs gs 1. There are no IPv6 addresses configured on the interfaces. snip gs gs 2. The query for an record for acme.spoerlein.net failed. gs snip This is not quite right. AI_DEFAULT is AI_V4MAPPED | AI_ADDRCONFIG. AI_V4MAPPED says 'if there are no records, query for A records and return them as v4-mapped addresses'. AI_ALL is only valid with AI_V4MAPPED, and says 'always query for A records and return v4-mapped addresses'. AI_ADDRCONFIG says 'only query for records if there is at least one interface with an IPv6 address; only query for A records if there is at least one interface with an IPv4 address'. (Loopback explicitly doesn't count for this purpose.) The resulting list of addresses is sorted according to ip6addrctl. So getipnodebyname is behaving correctly here: the host has both IPv4 and IPv6 addresses, and Sendmail is requesting both native and v4-mapped addresses be returned in all cases. The v4-mapped addresses are then sorted to the top of the list. On FreeBSD, where net.inet6.ip6.v6only is on by default, I believe this is incorrect, and Sendmail should be passing 0 for the flags argument, unless it's going to check or clear the IPV6_V6ONLY socket option. There is no point binding a socket to a v4-mapped address if the kernel isn't going to deliver IPv4 connections to it. Sendmail should also be binding to all the addresses returned, if it isn't already, rather than just the first: this would make the problem go away, since both v4-mapped and native IPv6 sockets would be bound, and the v4-mapped ones would simply never get any connections. Fixing this by setting ipv6_prefer is not necessarily a good idea; this will cause IPv6 addresses to be preferred across the whole system, and unless your IPv6 connectivity is at least as good as your IPv4, that probably isn't what you want. Just curious, but is there any specific reason not to return an error when Family=inet6 and no RR? In this case, Sendmail explicitly requested that v4-mapped addresses be returned in all cases... Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
Quoth Hajimu UMEMOTO u...@freebsd.org: On Wed, 09 Jan 2013 23:01:52 +0900 Hajimu UMEMOTO u...@freebsd.org said: ume I changed getipnodebyname to obey ip6addrctl in years past. I read ume RFC 2553 again, and realize that it mentions IPv6 addresses are ume returned 1st. So, my past change might be bad thing. X-( Where does it say that? All I can find (but I might be being stupid) is the bit in the description of AI_ALL where it says 'A query is first made for records and if successful, the IPv6 addresses are returned. Another query is then made for A records and any found are returned as IPv4-mapped IPv6 addresses.'. I don't believe that is meant to indicate the results are returned first in the list, just that both sets of results are included. Also, RFC 6724 (which is more recent), says 'we intend that implementations of APIs such as getaddrinfo() will use the destination address selection algorithm specified here to sort the list of IPv6 and IPv4 addresses that they return.'. AFAICS 'APIs such as getaddrinfo()' is supposed to include getipnodebyname and gethostbyname2, and the whole list of v4 and v6 addresses is supposed to be sorted by those rules. However, given that FreeBSD disables the use of v4-mapped addresses on AF_INET6 sockets by default, it might be sensible to change the rules a little. An application making an AF_INET6 query is probably going to use the result with an AF_INET6 socket, so a v4-mapped address is going to be mostly useless. I've just committed to disable it: http://svnweb.freebsd.org/base?view=revisionrevision=245225 I don't think that's the right answer. Even if the code should be changed to always return addresses from A records last, the IPv6 addresses from records should still be sorted according to ip6addrctl. Otherwise sites with multiple prefixes (say, a ULA prefix and a global prefix) won't be able to control their use properly. Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
Ben Morrow b...@morrow.me.uk wrote in 20130109154435.ga81...@anubis.morrow.me.uk: be So getipnodebyname is behaving correctly here: the host has both IPv4 be and IPv6 addresses, and Sendmail is requesting both native and v4-mapped be addresses be returned in all cases. The v4-mapped addresses are then be sorted to the top of the list. be be On FreeBSD, where net.inet6.ip6.v6only is on by default, I believe this be is incorrect, and Sendmail should be passing 0 for the flags argument, be unless it's going to check or clear the IPV6_V6ONLY socket option. There be is no point binding a socket to a v4-mapped address if the kernel isn't be going to deliver IPv4 connections to it. Sendmail should also be binding be to all the addresses returned, if it isn't already, rather than just the be first: this would make the problem go away, since both v4-mapped and be native IPv6 sockets would be bound, and the v4-mapped ones would simply be never get any connections. I reread the RFC 2553 and realize your explanation is correct. gshapiro's explanation was a behavior in the case of (AF_INET6, AI_DEFAULT), not (AF_INET6, AI_DEFAULT|AI_ALL). I think sendmail should work regardless of net.inet6.ip6.v6only. Is just dropping AI_ALL enough for that? When RR is found, no v4-mapped address will return in that case. Is this correct? be Fixing this by setting ipv6_prefer is not necessarily a good idea; this be will cause IPv6 addresses to be preferred across the whole system, and be unless your IPv6 connectivity is at least as good as your IPv4, that be probably isn't what you want. Yes, I agree that ipv6_prefer is not a correct way to solve this specific issue. be Just curious, but is there any specific reason not to return an error be when Family=inet6 and no RR? be be In this case, Sendmail explicitly requested that v4-mapped addresses be be returned in all cases... -- Hiroki pgp8oZFQaQ0r1.pgp Description: PGP signature
Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi,
On Wed, 9 Jan 2013 16:29:00 +
Ben Morrow b...@morrow.me.uk said:
ben Where does it say that? All I can find (but I might be being stupid) is
ben the bit in the description of AI_ALL where it says 'A query is first
ben made for records and if successful, the IPv6 addresses are
ben returned. Another query is then made for A records and any found are
ben returned as IPv4-mapped IPv6 addresses.'. I don't believe that is meant
ben to indicate the results are returned first in the list, just that
ben both sets of results are included.
It is the sentence you mentioned. It was not thought those days that
a query order and an order of the value to return were another. So, I
think that it implies the order of the value to return.
ben Also, RFC 6724 (which is more recent), says 'we intend that
ben implementations of APIs such as getaddrinfo() will use the destination
ben address selection algorithm specified here to sort the list of IPv6 and
ben IPv4 addresses that they return.'. AFAICS 'APIs such as getaddrinfo()'
ben is supposed to include getipnodebyname and gethostbyname2, and the whole
ben list of v4 and v6 addresses is supposed to be sorted by those rules.
I thought so at the time when I implemented it. However,
getipnodebyname has IPv4-mapped addresses issue as compared with
getaddrinfo.
Since gethostbyname2 doesn't treat multiple families at once, it is
out of scope, IMHO. gethostbyname2 in FreeBSD doesn't obey
ip6addrctl.
ben However, given that FreeBSD disables the use of v4-mapped addresses on
ben AF_INET6 sockets by default, it might be sensible to change the rules a
ben little. An application making an AF_INET6 query is probably going to use
ben the result with an AF_INET6 socket, so a v4-mapped address is going to
ben be mostly useless.
There is IPV6_V6ONLY socket option. Still, an application has two
choices:
- convert IPv4-mapped address to IPv4 address, or
- issue IPV6_V6ONLY socket option.
In anyway, I think it is important that an application conscious of
using the IPv4-mapped address.
I've just committed to disable it:
http://svnweb.freebsd.org/base?view=revisionrevision=245225
ben I don't think that's the right answer. Even if the code should be
ben changed to always return addresses from A records last, the IPv6
ben addresses from records should still be sorted according to
ben ip6addrctl. Otherwise sites with multiple prefixes (say, a ULA prefix
ben and a global prefix) won't be able to control their use properly.
getipnodebyname was deprecated by RFC 3493 and appropriate time has
passed since then. So, it is low-priority, IMHO.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
On Wed, 2013-01-09 at 23:42:10 +0900, Hiroki Sato wrote: Ulrich Spörlein u...@freebsd.org wrote in 20130109142111.gl35...@acme.spoerlein.net: On Wed, 2013-01-09 at 14:14:18 +0100, Michiel Boland wrote: On 01/08/2013 23:33, Hiroki Sato wrote: Ulrich Spörlein u...@freebsd.org wrote in 20130108184051.gi35...@acme.spoerlein.net: uq After setting this, it now looks like this: uq root@acme: ~# ip6addrctl uq Prefix Prec Label Use uq ::1/128 50 00 uq ::/0 40 10 uq 2002::/16 30 20 uq ::/96 20 30 uq :::0.0.0.0/96 10 40 uq uq And even sendmail is happily finding the sockets to bind to. Thanks for the hint! I think this just hides the problem. If gshapiro@'s explanation is correct, no :::0.0.0.0/96 address should be returned if the name resolution works fine... -- Hiroki getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:- If a host has both IPv6 and IPv4 addresses, both are returned. The IPv4 address is presented as a mapped address. The order in which the addresses are returns depends on the address selection policy (_hpreorder in lib/libc/net/name6.c) Is this also supposed to work for selecting the source IP address for outgoing packets/sockets? And should it work for ping6? Yes. Using a tunnel for IPv6, I have this transfer net configured on my router, but for ACL purposes I would like to have all connections come from my real prefix, not the transfer net. So I wrote my own policy, yet ping6 seems to ignore it. As you can see, source prefix stays 2a02:2528:ff00, though I'd like it to be 2a02:2528:ff0d. This is because the prefix on the interface has the first priority. Why don't you use an fe80::/10 address to route packets to the other endpoint of tun0? I don't think I have a choice here. To clarify: the sendmail problem is on a server that has native IPv6 connectivity, here I setup my actual prefix as the first address, the address I need to talk to the router is configured as an alias. This works fine. The source address problem I'm now talking about is happening on my router at home, which has a Sixxs tunnel and needs to use AICCU of all things to talk to the outside world, sixxs-aiccu will create the tun(4) interface and set it up like this: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280 options=8LINKSTATE inet6 fe80::230:5ff:fe77:e7a0%tun0 prefixlen 64 scopeid 0xd inet6 fe80::2428:ff00:1b:2%tun0 prefixlen 64 scopeid 0xd inet6 2a02:2528:ff00:1b::2 -- 2a02:2528:ff00:1b::1 prefixlen 128 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL Opened by PID 82756 and I'd like to have ipv6 connection originating from this host use 2a02:2528:ff0d::1%em0 instead of 2a02:2528:ff00:1b::2%tun0 as the outgoing address. That tun0 interface can come and go, btw, which complicates things. Is this possible? Or should I just switch to the one local DSL provide I have here that actually offers native IPv6 for home DSL users? Cheers, Uli pgp1mnFAoe1vP.pgp Description: PGP signature
Re: sendmail vs ipv6 broken after upgrade to 9.1
Quoth Hajimu UMEMOTO u...@freebsd.org: Hi, On Wed, 9 Jan 2013 16:29:00 + Ben Morrow b...@morrow.me.uk said: ben Where does it say that? All I can find (but I might be being stupid) is ben the bit in the description of AI_ALL where it says 'A query is first ben made for records and if successful, the IPv6 addresses are ben returned. Another query is then made for A records and any found are ben returned as IPv4-mapped IPv6 addresses.'. I don't believe that is meant ben to indicate the results are returned first in the list, just that ben both sets of results are included. It is the sentence you mentioned. It was not thought those days that a query order and an order of the value to return were another. So, I think that it implies the order of the value to return. OK. Since this is a legacy API, the real question is 'what do existing applications calling it expect?'. You may be right that they will expect to see IPv6 addresses first if there are any. ben Also, RFC 6724 (which is more recent), says 'we intend that ben implementations of APIs such as getaddrinfo() will use the destination ben address selection algorithm specified here to sort the list of IPv6 and ben IPv4 addresses that they return.'. AFAICS 'APIs such as getaddrinfo()' ben is supposed to include getipnodebyname and gethostbyname2, and the whole ben list of v4 and v6 addresses is supposed to be sorted by those rules. I thought so at the time when I implemented it. However, getipnodebyname has IPv4-mapped addresses issue as compared with getaddrinfo. Since gethostbyname2 doesn't treat multiple families at once, it is out of scope, IMHO. gethostbyname2 in FreeBSD doesn't obey ip6addrctl. ip6addrctl does more than just order v4 vs v6: it also sorts the v6 addresses, in a way which can be quite important. IMHO both the v6 addresses returned from getipnodebyname and the addresses returned from gethostbyname2(AF_INET6) ought to be sorted according to ip6addrctl, even if getipnodebyname special-cases the v4-mapped addresses to appear last. ben However, given that FreeBSD disables the use of v4-mapped addresses on ben AF_INET6 sockets by default, it might be sensible to change the rules a ben little. An application making an AF_INET6 query is probably going to use ben the result with an AF_INET6 socket, so a v4-mapped address is going to ben be mostly useless. There is IPV6_V6ONLY socket option. Still, an application has two choices: - convert IPv4-mapped address to IPv4 address, or - issue IPV6_V6ONLY socket option. In anyway, I think it is important that an application conscious of using the IPv4-mapped address. Yeah; I agree that the v4-mapped option is pretty useless (even when using a stack which supports it). I suspect the IETF people were trying too hard to account for the case of a v6-only stack talking to the v4 Internet, when AFAIK there aren't any v6-only stacks yet, nor are there likely to be for the forseeable future. That's why I think Sendmail ought to be changed to pass 0 flags, so it doesn't see v4-mapped addresses at all: after all, there's little point binding separate v4 and v6 sockets if the v6 socket is just going to end up bound to a v4-mapped address. I've just committed to disable it: http://svnweb.freebsd.org/base?view=revisionrevision=245225 ben I don't think that's the right answer. Even if the code should be ben changed to always return addresses from A records last, the IPv6 ben addresses from records should still be sorted according to ben ip6addrctl. Otherwise sites with multiple prefixes (say, a ULA prefix ben and a global prefix) won't be able to control their use properly. getipnodebyname was deprecated by RFC 3493 and appropriate time has passed since then. So, it is low-priority, IMHO. Well, if important applications like Sendmail are still using it it's probably important it works consistently with the rest of the system's IPv6 support. I'd rather see it removed, or reimplemented as a wrapper around getaddrinfo, than left in a broken state. Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
In message 20130110002257.ga84...@anubis.morrow.me.uk, Ben Morrow writes: Yeah; I agree that the v4-mapped option is pretty useless (even when using a stack which supports it). I suspect the IETF people were trying too hard to account for the case of a v6-only stack talking to the v4 Internet, when AFAIK there aren't any v6-only stacks yet, nor are there likely to be for the forseeable future. That's why I think Sendmail ought to be changed to pass 0 flags, so it doesn't see v4-mapped addresses at all: after all, there's little point binding separate v4 and v6 sockets if the v6 socket is just going to end up bound to a v4-mapped address. Mapped addresses are for dual stack hosts and sockets with IPV6_ONLY turned off. They work much better when the IPv4 side of the stack has been upgraded to support all of the new features of IPv6 socket api like packet info so that the application doesn't need to remember if it is talking to a IPv4 or IPv6 destination. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
How can I unstupid sendmail here? I don't think sendmail is being stupid here as it is doing what it has been doing under 8.x and 9.1 (the code is the same). I think something changed with the upgrade to 9.1. As far as tracking it down, the sendmail code does: getipnodebyname(acme.spoerlein.net, AF_INET6, AI_DEFAULT|AI_ALL, err); This will only return an IPv4 mapped address if: 1. There are no IPv6 addresses configured on the interfaces. How are your IPv6 addresses assigned? If auto-configured (DHCPv6, RTADV), is it possible sendmail is being started before autoconfiguration has completed? Restarting the MTA after boot and seeing if it still gets the mapped address will say whether or not this is the cause. 2. The query for an record for acme.spoerlein.net failed. This doesn't appear to be the case for dns based on your dig output (assuming you ran that dig command on the same machine that is exhibiting the problem). However, your nsswitch.conf lists hosts before dns and there have been broken name resolution implementations that, with 'hosts' listed first in nsswitch.conf have given back bad info if the first hostname match didn't have the IPv6 address. You could try switching the order in /etc/hosts to see if this helps. (Note, the broken implementation was not FreeBSD.) You can also test theory #2 by writing a small C program to do the getipnodebyname() call shown above and see what you get. If it gives the same bad address, then you need to look outside of sendmail. In the mean time, although not optimal, you can work around the issue by using the IPv6 address instead of the hostname in the Addr= equate. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
On 01/08/2013 16:18, Ulrich Spörlein wrote:
[...]
98054 sendmail CALL bind(0x7,0x708dbc,0x1c)
98054 sendmail STRU struct sockaddr { AF_INET6, [:::88.198.49.12]:587 }
98054 sendmail RET bind -1 errno 49 Can't assign requested address
Yeah right ... I don't want an IPv6-mapped-IPv4 address, I want it to bind to
the real thing.
Sendmail uses the first address returned by gethostbyname, rather than scan for
a 'real' ipv6 address instead of a mapped ipv4 address.
My guess is that things will improve once you do '/etc/rc.d/ip6addrctl
prefer_ipv6'. This will cause gethostbyname to return the real ipv6 address first.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
On Tue, 2013-01-08 at 18:36:34 +0100, Michiel Boland wrote: On 01/08/2013 16:18, Ulrich Spörlein wrote: Hey, I upgraded a server running 8.x to 9.1 over the weekend and sendmail no longer wants to bind the AF_INET6 sockets. So while this still works: DAEMON_OPTIONS(`Port=smtp, Addr=127.0.0.1, Name=MSA, M=Eu, InputMailFilters=dkim') DAEMON_OPTIONS(`Port=smtp, Addr=::1, Name=MSA, Family=inet6, M=Eu, InputMailFilters=dkim') this is broken: DAEMON_OPTIONS(`Port=submission, Addr=acme.spoerlein.net, Name=MSA, M=E, InputMailFilters=dkim') DAEMON_OPTIONS(`Port=submission, Addr=acme.spoerlein.net, Name=MSA, Family=inet6, M=E, InputMailFilters=dkim') which makes me believe this has to do with name resolution... The actual reported errors are: Jan 8 16:05:03 acme sm-msp-queue[98057]: starting daemon (8.14.6): queueing@00:30:00 Jan 8 16:05:03 acme sm-mta[98054]: NOQUEUE: SYSERR(root): opendaemonsocket: daemon MSA: cannot bind: Can't assign requested address What's the output of the 'ip6addrctl' command on your machine? Cheers Michiel root@acme: ~# ip6addrctl Prefix Prec Label Use :::0.0.0.0/96 50 00 ::1/128 40 10 ::/0 30 272866 2002::/16 20 34 ::/96 10 40 Gah! I remember having to set ip6addrctl_policy=ipv6_prefer on another system that I upgraded to 9.x a long time ago. After setting this, it now looks like this: root@acme: ~# ip6addrctl Prefix Prec Label Use ::1/128 50 00 ::/0 40 10 2002::/16 30 20 ::/96 20 30 :::0.0.0.0/96 10 40 And even sendmail is happily finding the sockets to bind to. Thanks for the hint! The bigger question now is, why don't we want to have a working IPv6 out of the box? Regards, Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
On Tue, 2013-01-08 at 10:09:20 -0800, Gregory Shapiro wrote: How can I unstupid sendmail here? I don't think sendmail is being stupid here as it is doing what it has been doing under 8.x and 9.1 (the code is the same). I think something changed with the upgrade to 9.1. As far as tracking it down, the sendmail code does: getipnodebyname(acme.spoerlein.net, AF_INET6, AI_DEFAULT|AI_ALL, err); This will only return an IPv4 mapped address if: 1. There are no IPv6 addresses configured on the interfaces. How are your IPv6 addresses assigned? If auto-configured (DHCPv6, RTADV), is it possible sendmail is being started before autoconfiguration has completed? Restarting the MTA after boot and seeing if it still gets the mapped address will say whether or not this is the cause. 2. The query for an record for acme.spoerlein.net failed. This doesn't appear to be the case for dns based on your dig output (assuming you ran that dig command on the same machine that is exhibiting the problem). However, your nsswitch.conf lists hosts before dns and there have been broken name resolution implementations that, with 'hosts' listed first in nsswitch.conf have given back bad info if the first hostname match didn't have the IPv6 address. You could try switching the order in /etc/hosts to see if this helps. (Note, the broken implementation was not FreeBSD.) You can also test theory #2 by writing a small C program to do the getipnodebyname() call shown above and see what you get. If it gives the same bad address, then you need to look outside of sendmail. In the mean time, although not optimal, you can work around the issue by using the IPv6 address instead of the hostname in the Addr= equate. Turns out it was the missing setting of ip6addrctl_policy=ipv6_prefer in rc.conf that also bit me in strange and mysterious ways on another machine where I did the upgrade. It's very unfortunate that this will runtime-break sendmail and I honestly don't know why we make ipv4 the default in this day and age. Can some IPv6 guru chime in here? This is all thoroughly confusing. Thanks! Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sendmail vs ipv6 broken after upgrade to 9.1
Gregory Shapiro gshap...@freebsd.org wrote in 20130108180920.gj36...@rugsucker.smi.sendmail.com: gs How can I unstupid sendmail here? gs gs I don't think sendmail is being stupid here as it is doing what it has gs been doing under 8.x and 9.1 (the code is the same). I think gs something changed with the upgrade to 9.1. As far as tracking it gs down, the sendmail code does: gs gs getipnodebyname(acme.spoerlein.net, AF_INET6, AI_DEFAULT|AI_ALL, gs err); gs gs This will only return an IPv4 mapped address if: gs gs 1. There are no IPv6 addresses configured on the interfaces. How are gs your IPv6 addresses assigned? If auto-configured (DHCPv6, RTADV), is gs it possible sendmail is being started before autoconfiguration has gs completed? Restarting the MTA after boot and seeing if it still gets gs the mapped address will say whether or not this is the cause. gs gs 2. The query for an record for acme.spoerlein.net failed. This gs doesn't appear to be the case for dns based on your dig output gs (assuming you ran that dig command on the same machine that is gs exhibiting the problem). However, your nsswitch.conf lists hosts gs before dns and there have been broken name resolution implementations gs that, with 'hosts' listed first in nsswitch.conf have given back bad gs info if the first hostname match didn't have the IPv6 address. You gs could try switching the order in /etc/hosts to see if this helps. gs (Note, the broken implementation was not FreeBSD.) Just curious, but is there any specific reason not to return an error when Family=inet6 and no RR? -- Hiroki pgpKBFOU0X1Fy.pgp Description: PGP signature
Re: sendmail vs ipv6 broken after upgrade to 9.1
Ulrich Spörlein u...@freebsd.org wrote in 20130108184051.gi35...@acme.spoerlein.net: uq After setting this, it now looks like this: uq root@acme: ~# ip6addrctl uq Prefix Prec Label Use uq ::1/128 50 00 uq ::/0 40 10 uq 2002::/16 30 20 uq ::/96 20 30 uq :::0.0.0.0/96 10 40 uq uq And even sendmail is happily finding the sockets to bind to. Thanks for the hint! I think this just hides the problem. If gshapiro@'s explanation is correct, no :::0.0.0.0/96 address should be returned if the name resolution works fine... -- Hiroki pgpTBxYwcfkgN.pgp Description: PGP signature
