On Sat, 19 Aug 2000, Francis Dupont wrote:
> In your previous mail you wrote:
>
> 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.
>
> => 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...
right.
> 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?
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.
> An implementation may do this but this is not required... and this
> couldn't work easily with ESP header.
in fact esp would be a serious problem. i had missed this point.
> 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.
>
> => 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.
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.
--
Aequam memento rebus in arduis servare mentem...
Mauro Tortonesi [EMAIL PROTECTED]
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 PROTECTED]
--------------------------------------------------------------------
