From: Dave Johnson <hidden> Date: 2007-07-26 00:19:17
ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast
Addresses' (RFC4193) and returns IPV6_ADDR_RESERVED for that range.
SCTP uses this function and will fail bind() and connect() calls that
use RFC4193 addresses, SCTP will also ignore inbound connections from
RFC4193 addresses if listening on IPV6_ADDR_ANY.
There may be other users of ipv6_addr_type() that could also have
problems.
Signed-off-by: Dave Johnson <redacted>
Cc: Srinivas Akkipeddi <redacted>
===== net/ipv6/addrconf_core.c 1.2 vs edited =====
From: David Miller <davem@davemloft.net> Date: 2007-07-26 00:12:19
From: Dave Johnson <redacted>
Date: Wed, 25 Jul 2007 19:49:09 -0400
ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast
Addresses' (RFC4193) and returns IPV6_ADDR_RESERVED for that range.
SCTP uses this function and will fail bind() and connect() calls that
use RFC4193 addresses, SCTP will also ignore inbound connections from
RFC4193 addresses if listening on IPV6_ADDR_ANY.
There may be other users of ipv6_addr_type() that could also have
problems.
Contrarily, there may be ipv6_addr_type() call sites that really
do want to reject rfc4193 addresses.
From: Dave Johnson <hidden> Date: 2007-07-26 01:12:01
David Miller writes:
Contrarily, there may be ipv6_addr_type() call sites that really
do want to reject rfc4193 addresses.
A quick look through the callers and only these functions should be
effected, they check either RESERVED or UNICAST from ipv6_addr_type():
net/ipv6/addrconf.c: ipv6_dev_get_saddr()
net/ipv6/exthdrs.c: ipv6_dest_hao()
net/ipv6/ip6_tunnel.c: ip6_tnl_set_cap()
net/ipv6/netfilter/ip6t_REJECT.c: send_reset()
net/ipv6/route.c: ip6_route_add()
net/ipv6/route.c: ip6_pkt_drop()
net/sctp/ipv6.c: sctp_v6_available()
net/sctp/ipv6.c: sctp_v6_addr_valid()
--
Dave Johnson
Starent Networks
Contrarily, there may be ipv6_addr_type() call sites that really
do want to reject rfc4193 addresses.
A quick look through the callers and only these functions should be
effected, they check either RESERVED or UNICAST from ipv6_addr_type():
net/ipv6/addrconf.c: ipv6_dev_get_saddr()
net/ipv6/exthdrs.c: ipv6_dest_hao()
net/ipv6/ip6_tunnel.c: ip6_tnl_set_cap()
net/ipv6/netfilter/ip6t_REJECT.c: send_reset()
net/ipv6/route.c: ip6_route_add()
net/ipv6/route.c: ip6_pkt_drop()
net/sctp/ipv6.c: sctp_v6_available()
net/sctp/ipv6.c: sctp_v6_addr_valid()
From: Dave Johnson <hidden> Date: 2007-07-26 18:01:27
Simon Arlott writes:
But ULA's scope isn't global, shouldn't it be IPV6_ADDR_SCOPE_ORGLOCAL ?
Isn't ORGLOCAL defined for multicast only?
rfc4193 section 3.3 says:
3.3. Scope Definition
By default, the scope of these addresses is global. That is, they
are not limited by ambiguity like the site-local addresses defined in
[ADDARCH].
But ULA's scope isn't global, shouldn't it be IPV6_ADDR_SCOPE_ORGLOCAL ?
Isn't ORGLOCAL defined for multicast only?
Yes, it's only for multicast. Unicast addresses only have
2 scopes any more: Global and Link-Local.
-vlad
rfc4193 section 3.3 says:
quoted
3.3. Scope Definition
By default, the scope of these addresses is global. That is, they
are not limited by ambiguity like the site-local addresses defined in
[ADDARCH].
Hello.
In article [off-list ref] (at Wed, 25 Jul 2007 19:49:09 -0400), Dave Johnson [off-list ref] says:
ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast
Addresses' (RFC4193) and returns IPV6_ADDR_RESERVED for that range.
Acked-by: YOSHIFUJI Hideaki <redacted>
I would say, it would be better to add IPV6_ADDR_UNICAST as well
for "reserved" addresses unless we have good reason not to do it,
anyway.
--
YOSHIFUJI Hideaki @ USAGI Project [off-list ref]
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
In article [off-list ref] (at Wed, 25 Jul 2007 19:49:09 -0400), Dave Johnson [off-list ref] says:
quoted
ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast
Addresses' (RFC4193) and returns IPV6_ADDR_RESERVED for that range.
Acked-by: YOSHIFUJI Hideaki <redacted>
Ok, I've applied Dave's patch.
Dave, although it's customary and fine to use "+foo-list" email
addresses for mailing list subscriptions and discussions, I
ask that you don't add that cookie to your signoff lines in
patch submissions and I've removed it from your's in this patch.
Thanks a lot.