In your previous mail you wrote:
> Alternatively, we could specify that any mutable options that appear
> after the AH header are treated as if they were immutable, i.e.,
> included in the authentication computation. Such options,
> though mutable,
> would not undergo mutation, so could safely be treated as
> immutable by AH.
At least I definitely prefer this approach (this is the way I have it
implemented).
=> I have done the same thing then I should agree but:
AH (nor any other extension header) should not care what follows after it,
it's just payload at that stage.
=> this cannot deal with the case where there are more than one AH header
(I've seen some mails about this issue but I don't remember whether this
issue was solved and (more important) how). Of course the problem is
detected when the internal AH is processed...
Thanks
[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]
--------------------------------------------------------------------
