XFRM and IPv6 raw sockets and multicast
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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XFRM and IPv6 raw sockets and multicast
Hi, On Dec 4, 2007 4:52 PM, YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XFRM and IPv6 raw sockets and multicast
Hello. In article [EMAIL PROTECTED] (at Tue, 4 Dec 2007 16:27:50 +0100), Hugo Santos [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XFRM and IPv6 raw sockets and multicast
Hello. In article [EMAIL PROTECTED] (at Tue, 4 Dec 2007 17:01:43 +0100), Hugo Santos [EMAIL PROTECTED] says: 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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
