Subject: 2292bis comment

From: [email-masked]
Date: Fri, 19 Nov 1999 16:53:28 +0900

I have a comment about 2292bis-01, chapter 3.2 (ICMPv6 filter).
	What is the semantics of raw socket with ICMPv6 filter?
	I can imagine several interpretations:
	a. it will throw any ICMPv6 packet to the userland, regardless of
	   ICMPv6 checksum nor any validation failure.
	b. it will throw ICMPv6 packet to the userland, only if it
	   passes ICMPv6 checksum check.  the kernel does not do further
	   validations.
	c. it will throw ICMPv6 packet to the userland, only if it looks
	   completely okay to the kernel (checksum is okay and all validations
	   are passed).

	Since:
	- it is raw socket, and
	- we have IPV6_CHECKSUM automatically turned on
	I think it would be (b) or (c), not (a).  what is the position of the
	authors?  I would like to see clarification to help userland
	programmers.

itojun
--------------------------------------------------------------------
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: Fri, 19 Nov 1999 13:31:08 -0800 (PST)

> 	   completely okay to the kernel (checksum is okay and all validations

b) makes the most sense to me.
"All validations" can not be true in general since it requires the
kernel to know about all future ICMP based protocols, which is impossible.
You could say e.g. "all validations for icmp types ..."
but that would be different for different implementations.

Thus from the perspective of the application it can not assume that the
protocol stack knows about a particular ICMP type thus it must do the
validation checks in the application.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 23 Nov 1999 17:29:21 +0100

> 	   completely okay to the kernel (checksum is okay and all validations
   
=> I have implemented c) because I give the packet to the raw input
routine only when the kernel has finished to deal with it.

=> it is possible to be not so hard in validation checks, for instance
I discard unknown types only when they are not information types.

=> there are some common rules but I agree they should be written down
(not only in the source code).

=> in any case it is better to do validation checks twice than none,
then application MUST do them!

[email-masked]

PS: the final text should be open, ie. kernel can do some further
(then checksum) validations.
PPS: the real problem is to know if the kernel should deal with ICMP
interesting packets before or after give them to the application.
(note that before/after semantic is not clear on a multi-processor)
I believe no assumption is the best answer.
--------------------------------------------------------------------
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: [email-masked]
Date: Wed, 24 Nov 1999 10:30:43 +0900

>(not only in the source code).

	If we put validation in the kernel before throwing packets to the
	userland, we will not be able to implement certain class of userland
	applications.
	example: a userland application that monitors and prints invalid
	ICMPv6 packets (maybe academic example...).

	We may be able to extend 2292 if there are high demand on it:
	putting "kernel's thoughts on validity of the packet" into ancillary
	data? (too much?)

	I would like to see some consensus here, and some explicit words
	in 2292bis.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Wed, 24 Nov 1999 09:22:39 +0100

=> for this kind of applications I believe something like BPF is better,
it can give invalid IPv6 packets too (for instance with an anycast source
address) and it can send them...

Regards

[email-masked]

PS: I am still in favor of c) with a MAY for validations.