>>>>> On Wed, 19 Dec 2001 14:54:41 +0200,
>>>>> Markku Savela <[EMAIL PROTECTED]> said:
> Ok, I posted sloppily, as defined it's not as bad as I thought, the
> destopt before/after routing option has been removed. Good.
>> in "4.Access to IPv6 and Extension Headers" there is
>> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR,
>> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS,
>> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS,
> ..and I pasted other than just extension header options. However, I
> still question, whether the filter way of specifying them would be
> a more robust solution.
In terms of the notion of generalization, it might be better to use a
same type of array as icmp6 filter. However, I don't see much benefit
of it from a practical point of view. In fact, it is harder to
introduce a new extension headers than to introduce a new ICMPv6 type
(there was actually a discussion on this topic in this list, in a
different context). Additionally, I'm not really sure if an
application wants to receive such new extension headers for a
practical purpose, while new types of ICMPv6 messages will tend to be
handled in the application layer. For minor usage, we've already had
perfectly generic mechanisms such as BPF and DLPI.
So..., sorry, but I won't change the current spec unless we have a
concrete and practical example of such new extension header types and
applications that want to receive the headers.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
