In your previous mail you wrote: Why do you belive the IPV6_RTHDRDSTOPTS is unnecessary? Is it because of the lack of options that would go into this header?
=> this is the main reason. In fact the only destination option in the draft (or in a RFC), the tunnel encapsulation limit, needs to be in a place not in the recommended ordering. Or is it because of the restrictive ordering (i.e 2460 recomended ordering)? => we know this ordering is bad so there is no reason to insist to enforce it. IPV6_DSTOPTS is enough. P.S. From what I remember of the discussion about header ordering constraints was to stabilize this API and then figure something out that would not be restrictive. => we can't do all what we want so the minimum API is the best. One day we'll try to fix this with a more powerful API but KISS + clever kernel is the best for today. Regards [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] --------------------------------------------------------------------
