Hi,
I've ran into an issue which i'm not sure that is known. I'm able to
provide a patch if people feel this is something that should be fixed.
Anyway, the source address of packets is not taken into account when
matching for xfrm policies when socket(AF_INET6, SOCK_RAW,
IPPROTO_RAW) sockets are used. This doesn't allow for (S,G) policies
to be deployed for IPv6 for local output packets as is required for
some multicast communications (read: SSM).
The behavior is the same as in UDP, but ipv6_pinfo->saddr is not
usually set for these kind of sockets. I would say that if fl6_src is
any, it should be copied from the ipv6 header.
Another question is why does raw.c require a msg_name? If
inet->hdrincl was set, it could use the ipv6 header destination
address in the absense of msg_name.
Any comments? :-)
Thanks,
Hugo
Hello.
In article [off-list ref] (at Tue, 4 Dec 2007 16:27:50 +0100), "Hugo Santos" [off-list ref] says:
The behavior is the same as in UDP, but ipv6_pinfo->saddr is not
usually set for these kind of sockets. I would say that if fl6_src is
any, it should be copied from the ipv6 header.
What do you mean by "ipv6 header"?
Another question is why does raw.c require a msg_name? If
inet->hdrincl was set, it could use the ipv6 header destination
address in the absense of msg_name.
I think hdrincl is broken (and even, say, deprecated) on IPv6.
If we do really support it, if hdcincl is set, XFRM and other
all extension header processes should be skipped, but they are
not very clear at all so far.
--yoshfuji
Hi,
On Dec 4, 2007 4:52 PM, YOSHIFUJI Hideaki / 吉藤英明
[off-list ref] wrote:
What do you mean by "ipv6 header"?
If IPPROTO_RAW is set, we supply the ipv6 header, extensions and payload.
I think hdrincl is broken (and even, say, deprecated) on IPv6.
By IPv6 you mean the protocol, or Linux's implementation of it?
Although there are APIs that allow applications to build and supply
the extension headers to the network stack, i think the ability to
provide the full ipv6 packet is also useful for some use cases.
If we do really support it, if hdcincl is set, XFRM and other
all extension header processes should be skipped, but they are
not very clear at all so far.
I understand how some users of IPPROTO_RAW would want xfrm to be
skipped, but on the other hand i also see the interoperation between
the two as useful, to for instance allowing a ESP tunnel to be used by
such packets.
Hugo
Hello.
In article [off-list ref] (at Tue, 4 Dec 2007 17:01:43 +0100), "Hugo Santos" [off-list ref] says:
quoted
If we do really support it, if hdcincl is set, XFRM and other
all extension header processes should be skipped, but they are
not very clear at all so far.
I understand how some users of IPPROTO_RAW would want xfrm to be
skipped, but on the other hand i also see the interoperation between
the two as useful, to for instance allowing a ESP tunnel to be used by
such packets.
I do think all extension header, including fragment and/or XFRM, process
should be skipped if hdrincl is set.
--yoshfuji