Subject: RAW sockets and protocols

From: "Lori Napoli" <[email-masked]>
Date: Mon, 17 Sep 2001 10:11:11 -0400

For RAW sockets, an application can use any procotol for IPv4.  In IPv6, I
imagine there are problems if a RAW application opens a socket and uses a
known IPv6 extension header number as the protocol since now the IP layer
will expect that next header field to be an extension header.  Therefore,
is it a restriction now that an IPv6 RAW application cannot use an known
IPv6 extension header as the protocol on the socket call?

Thanks
Lori

z/OS Communications Server Development - TCP/IP Stack

919-254-6146   T/L 8-444-6146
E-mail: [email-masked]

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Sep 2001 21:06:23 +0200 (CEST)

> IPv6 extension header as the protocol on the socket call?

Good question.

I suspect this is implementation dependent since the Advanced API is
silent on the issue.

What do different implementations do?

My guess (from the structure of the code - I haven't run a test) is that
Solaris will not return an error to the socket call, but that the
socket will not receive any packets since the extension header processing
in IP will take precendence.

   Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 18 Sep 2001 12:07:53 +0900

>>>>> On Mon, 17 Sep 2001 21:06:23 +0200 (CEST), 
>>>>> Erik Nordmark <[email-masked]> said:

> I suspect this is implementation dependent since the Advanced API is

I think so, too.

> What do different implementations do?

KAME (perhaps unintentionally) does not allow applications to specify
a next header ID for an extension header as a socket protocol.  The
implementation has protocol switch structures for the extension header
types with specifying NULL as the corresponding user request
functions.  As a result, the kernel routing for the socket(2) call
fails, with the EPROTONOSUPPORT error, when the protocol value is one
of the extension header types.

I've checked this behavior with a tiny test program.  If you're
interested, you may be able to do the same test for your own
implementation by:
- grab the latest version at
  http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/advapitest/
- compile the "accept" command in the test kit.
- execute "accept -P ipv6-opts" etc.
(I don't know if the test kit is portable enough, though.)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Sep 2001 10:47:55 +0200 (CEST)

> (I don't know if the test kit is portable enough, though.)

Not very portable. 
Once I wacked away the syntax problems (assuming sin6_len plus a 
bunch of stuff due to Solaris not having all of rfc2292bis)
I realized that accept.c assumes that for SOCK_RAW ai_protocol is passed
through from hints to the getaddrinfo result.
The Solaris getaddrinfo doesn't do this. I don't know if this is a Solaris
problem since I haven't check what the standards text for getaddrinfo()
says about SOCK_RAW.

In any case I verified that the socket call doesn't fail on Solaris for 
(PF_INET6, SOCK_RAW, exthdr number).

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 18 Sep 2001 20:11:37 +0900

>>>>> On Tue, 18 Sep 2001 10:47:55 +0200 (CEST), 

> The Solaris getaddrinfo doesn't do this.

Okay, although I'm not sure if you still have an interest on the test
kit, I modified the code as portable as possible according to your
comments.  Also, since at least two people tried to use the kit (the
other one said so in a private message), I made a tar+gz ball of the
kit at
ftp://ftp.kame.net/pub/misc/advapitest.tgz
for convenience.

> I don't know if this is a Solaris

I've checked rfc2553bis-03.  The spec seems ambiguous on this point...

> (PF_INET6, SOCK_RAW, exthdr number).

Hmm, so we have at least two different implementations.

					JINMEI, Tatuya