> In practise this seems to suggest that the sending node must always be > sure beforehand which extension headers the recipient supports (think e.g. > some MIPv6 feature or new ISPEC feature or whatever). > > In practise this seems to mean either: > 1) never define new extension headers (except in _very_ controlled > scenarios, like new payload protocols) > 2) implement some form of 'extension header capability discovery'.
My personal opinions - and see philosophical question at end. In some cases new extensions headers can be viewed the same way as new transport protocols - how does an application know whether the peer implements SCTP or whether it must fall back to TCP? In some cases this is handed by out of band communication. In other cases the desire might be to use extension headers might be more like destination options. The suggestion in mobile-ip is to carry optional information as an extension header since IPsec selectors can operate on the next header but isn't as specified capable of looking at individual options. There is a mechanism which *can* be used to determine if the peer is supporting a new extension header. If it isn't supported is ICMP parameter problem with code = unrecognized Next Header type encountered will be returned. The philosophical question is whether ICMP parameter problem is intended for this purpose, or whether it is a debugging tool i.e. protocols shouldn't respond to this ICMP error by altering their behavior. Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
