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: zio_done panic on unadulterated FreeBSD Release 9.1
On Wed, Jan 09, 2013 at 08:03:38PM +, Po-Li Soong wrote: Hi, My name is Po-Li Soong. I ran into a crash not long after installing the 9.1 release on my home machine. I was performing a test run of file transfer with samba server running on the FreeBSD installation. The transfer rate was about 70-80 MB/sec. The core.txt is attached. If there are other crash dumps needed, please let me know. I first discussed this panic with Justin Gibbs, a coworker of mine at Spectra Logic. He referred me to this email address, suggesting that the information should be relevant to you. Thanks for the help. Regards, Po-Li Soong maestoso dumped core - see /var/crash/vmcore.0 Sat Jan 5 19:53:24 MST 2013 FreeBSD maestoso 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xfffb812815d8 fault code= supervisor read data, page not present instruction pointer = 0x20:0x80b50597 stack pointer = 0x28:0xff80fa3bc8d0 frame pointer = 0x28:0xff80fa3bc900 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (zio_write_intr_5) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: #0 0x809208a6 at kdb_backtrace+0x66 #1 0x808ea8be at panic+0x1ce #2 0x80bd8240 at trap_fatal+0x290 #3 0x80bd857d at trap_pfault+0x1ed #4 0x80bd8b9e at trap+0x3ce #5 0x80bc315f at calltrap+0x8 #6 0x80b506f5 at vm_page_free_toq+0x45 #7 0x80b4f276 at vm_object_page_remove+0x196 #8 0x80b46b06 at vm_map_delete+0x316 #9 0x80b46c11 at vm_map_remove+0x51 #10 0x80b3a70a at uma_large_free+0x3a #11 0x808d589a at free+0x5a #12 0x8169b4ce at zio_done+0x2ee #13 0x81699063 at zio_execute+0xc3 #14 0x8092cf55 at taskqueue_run_locked+0x85 #15 0x8092ded6 at taskqueue_thread_loop+0x46 #16 0x808bb9ef at fork_exit+0x11f #17 0x80bc368e at fork_trampoline+0xe Uptime: 3h19m34s Dumping 571 out of 3561 MB:..3%..12%..23%..31%..42%..51%..62%..73%..82%..93% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko #0 doadump (textdump=Variable textdump is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=Variable textdump is not available. ) at pcpu.h:224 #1 0x808ea3a1 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0x808ea897 in panic (fmt=0x1 Address 0x1 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0x80bd8240 in trap_fatal (frame=0xc, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #4 0x80bd857d in trap_pfault (frame=0xff80fa3bc820, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:773 #5 0x80bd8b9e in trap (frame=0xff80fa3bc820) at /usr/src/sys/amd64/amd64/trap.c:456 P #6 0x80bc315f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0x80b50597 in vm_page_remove (m=0xfe00cd733ab0) at /usr/src/sys/vm/vm_page.c:975 #8 0x80b506f5 in vm_page_free_toq (m=0xfe00cd733ab0) at /usr/src/sys/vm/vm_page.c:1872 #9 0x80b4f276 in vm_object_page_remove (object=0x81281580, start=477512, end=477539, options=Variable options is not available. ) at /usr/src/sys/vm/vm_object.c:1899 #10 0x80b46b06 in vm_map_delete (map=0xfe0002e8, start=Variable start is not available. ) at /usr/src/sys/vm/vm_map.c:2739 #11 0x80b46c11 in vm_map_remove (map=0xfe0002e8, start=18446743525909626880, end=18446743525909737472) at /usr/src/sys/vm/vm_map.c:2871 #12 0x80b3a70a in uma_large_free (slab=0xfe00aceff8e0) at /usr/src/sys/vm/uma_core.c:3085 #13 0x808d589a in free
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
