Hi,
Francis Dupont wrote:
> 2. only loosen the restriction about destination options headers;
> (e.g.) add another ancillary data type/socket option to specify the
> relationship between a destination options header and a fragment
> header.
>
> => I believe the issue has to be solved, a quick & dirty hack shan't be
> enough next time.
>From the MIP's point of view, I think this approach will solve the
exthdr order problem related to MIP. Although, with respect to MIP, I
guess the advapi is not important part for implementers because MIP is
highly related to IPv6 stack, many MIP implemnters will make it in the
kernel (and I am one of them). So few of them consider using advapi to
realize MIP stack.
Beside MIP, to make the insertion logic of destopt exthdrs more
flexible sounds good for me. Destopt is a generic exthdr than other
exthdrs, the flexibility will solve some future exthdr problems.
I think most of us are thinking that the 1st approach that jinmei
proposed is the ideal way. But we are worry about we must consume a
lot of time to achive the real goal, a very flexible advapi, while we
don't have much time...
---
Keiichi SHIMA <[EMAIL PROTECTED]>
Internet Initiative Japan Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
