Subject: extension headers

From: Mauro Tortonesi <[email-masked]>
Date: Fri, 18 Aug 2000 14:31:43 +0200

i am writing an ipv6 enabled version of ping, and i want to dump informations 
collected from ipv6 packets returned by icmpv6 error messages.
the matter is: before i can collect informations from the tcp or udp header
i have to skip the ipv6 extension headers.

i have found some code which does exactly this in the linux kernel, with a 
different purpose. here is a note from alexei kuznetsov (linux kernel 
developer):

/*
 * Skip any extension headers. This is used by the ICMP module.
 *
 * Note that strictly speaking this conflicts with RFC1883 4.0:
 * ...The contents and semantics of each extension header determine whether 
 * or not to proceed to the next header.  Therefore, extension headers must
 * be processed strictly in the order they appear in the packet; a
 * receiver must not, for example, scan through a packet looking for a
 * particular kind of extension header and process that header prior to
 * processing all preceding ones.
 * 
 * We do exactly this. This is a protocol bug. We can't decide after a
 * seeing an unknown discard-with-error flavour TLV option if it's a 
 * ICMP error message or not (errors should never be send in reply to
 * ICMP error messages).
 * 
 * But I see no other way to do this. This might need to be reexamined
 * when Linux implements ESP (and maybe AUTH) headers.
 * --AK
 */

and this is what rfc2460 (section 4.0) says:

   ... to proceed to the next header.  Therefore, extension headers must
   be processed strictly in the order they appear in the packet; a
   receiver must not, for example, scan through a packet looking for a
   particular kind of extension header and process that header prior to
   processing all preceding ones.

it seems to me that there is at least one situation in which ipv6 
extension headers should be skipped - before a packet is sent back
within an icpmv6 error message, the kernel must be sure that it is not
an icmp error message.

i think there are many other situations in which low-level network programs 
need to access payload data without processing extension headers. the 
problems are two: 

	1) ipv6 standards do not seem to permit this	
	2) there is not a standard way to skip ext. headers

imho this wg should consider the following solutions:

	1) permit to programs the skip of the ext. headers IF AND ONLY IF
	they are only interested in collecting data for error reporting 
	purposes.
	2) provide a standard macro that returns protocol id of the upper 
	layer protocol and the offset of the payload from the beginning of 
	the packet, to be included in the next version of 
	draft-ietf-ipngwg-rfc2292bis.

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			[email-masked]
Ferrara Linux User Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it
--------------------------------------------------------------------
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: Sat, 19 Aug 2000 09:46:21 +0900

>different purpose. here is a note from alexei kuznetsov (linux kernel 

	please take a look at RFC2292.  IPv6 raw socket will not send you
	the IPv6 header nor extension header, it only sends up the real
	payload.  you will be able to grab information about IPv6 header and 
	extension header, via ancillary data stream.

	so, userland appliation (like your ping6) do not need to worry about
	extension header, normally.  if you would like to take a look at,
	you can always look at it via ancillary data stream.

	I believe there are IPv6-ready Linux ping6 packages, you may want to
	take a look at those.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 19 Aug 2000 11:21:14 +0900

>>>>> On Sat, 19 Aug 2000 09:46:21 +0900, 
>>>>> [email-masked] said:

> 	you can always look at it via ancillary data stream.

I guess the intention of the original message is parsing the inner
IPv6 packet (including extension headers) within an ICMPv6 error
message. The advanced API does not strip such extension headers, so
application programs have to parse and strip the headers by
themselves.

Actually, we have code for this purpose in KAME's ping6 command (see
the pr_retip() function in ping6.c).

BTW: as for the specification, I agree with Tim; it is already clear
enough and we don't have to revise it.

					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: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
Date: Sat, 19 Aug 2000 13:00:55 +0900

> the pr_retip() function in ping6.c).

FYI: I've brought it into Linux iputils ping6.
<http://apps.v6.linux.or.jp/usagi/apps/iputils/iputils-ss991024-usagi-20000819.patch.gz>

-- 
Hideaki YOSHIFUJI @ USAGI Project  <[email-masked]>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
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: Mauro Tortonesi <[email-masked]>
Date: Sat, 19 Aug 2000 13:54:30 +0200 (CEST)

> application programs have to parse and strip the headers by

you have perfectly understood.

> the pr_retip() function in ping6.c).

i'll take a look at it. BTW can you explain to me why two different
programs? i think i have successfully integrated icmpv6 support into
netkit-base ping (you can get the patch on my site:
http://project6.ferrara.linux.it)

> enough and we don't have to revise it.

this is probably the best choice. however what do you think about the
other proposal (the standard macro to skip ext. headers)?

---

From: Francis Dupont <[email-masked]>
Date: Sat, 19 Aug 2000 14:29:15 +0200

In your previous mail you wrote:

=> this was already discussed. The general idea was/is it doesn't matter
because it is expensive and in some cases impossible to verify the
offending packet is an icmp error message then if the trivial check
for an ICMP error fails then you may return an ICMPv6 error.
Just don't forget to apply the ICMPv6 rate limit on it...

   i think there are many other situations in which low-level network programs 
   need to access payload data without processing extension headers.

=> I don't understand how you may both access payload data and
no process extension headers because it is the processing of extension
headers which gives the position (and the kind) of payload data.
 Would you like to parse incomming packets twice, the first time in order
to find extension headers, the second time in order to process them?
An implementation may do this but this is not required... and this
couldn't work easily with ESP header.

=> I disagree. What you want seems to be a wildcard raw socket and
this is not a standard feature for many good reasons. If you need
to look at inside incoming packets before their processing then
something like BPF is a better solution.

Regards

[email-masked]

---

From: Mauro Tortonesi <[email-masked]>
Date: Sat, 19 Aug 2000 15:31:13 +0200 (CEST)

> Just don't forget to apply the ICMPv6 rate limit on it...

right. 
 
> to find extension headers, the second time in order to process them?

of course not. but think of ipv6 packets returned from an icmpv6 error
that don't have an esp. a direct access to the payload could fasten the
process of dumping the upper level protocol header.

> couldn't work easily with ESP header.

in fact esp would be a serious problem. i had missed this point.

> something like BPF is a better solution.

i don't want that. but think of ipv6 packets retured from icpmv6 error.
shouldn't be nice if dumping of the upper level protocol informations
could be done like this:

void dump_tcp(struct tcphdr *);

void dump(struct ip6_hdr *hdr)
{
	int offset, upper_level_protocol;
	uint8_t *payload;

	MY_FUNC(hdr, &offset, &upper_level_protocol);
	payload = ((uint8_t *)hdr) + offset;

	switch(upper_level_protocol) {
	case IPPROTO_TCP: dump_tcp((struct tcphdr*)payload);
			  break;
	case IPPROTO_UDP: ... etc,etc ...
	}
}

however, as you state, MY_FUNC would have great problems handling esp, and
that makes MY_FUNC nearly useless.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 21 Aug 2000 16:20:05 +0900

>>>>> On Sat, 19 Aug 2000 13:54:30 +0200 (CEST), 
>>>>> Mauro Tortonesi <[email-masked]> said:

> http://project6.ferrara.linux.it)

I'm not sure what you meant by "two different programs", but if it was
the reason why we separated ping6 from the IPv4 version of ping,
please see the following URL:

http://www.freebsd.org/cgi/query-pr.cgi?pr=20527

> other proposal (the standard macro to skip ext. headers)?

Hmm...it MAY be useful in some cases, but I'm personally not in favor
of the idea, because we'd rarely need such a function in applications
(remember that normal extension headers are grabbed as ancillary data
via the advanced API).

					JINMEI, Tatuya