> Does this seem useful? Does the format make sense? Any other potential > uses of such a facility if it were adopted?
It makes sense, but there is one pitfall. More and more, firewalls come with restrictive rules about what ICMP packets will be allowed. These rules typically operate on ICMP type and ICMP code. Having a single type-code combination for all experimental packets will force an all or nothing decision in firewalls, allow all experiments or deny them all. This may be OK if experiments are limited in time and in scope, but it may become a liability if experiments linger on -- and we can use Mobile-IPv6 as an example of an experiment that can linger on for a very long time. > Given a single ICMP Type, one must distinguish amongst > the different messages by a "sub-type" somewhere in the header. > This is the format we are considering: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sub-Type | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > > Type To be assigned by IANA (one common Type number for > "Experimental Protocols") > > Code Used for additional granularity on a per-Sub-Type basis > (i.e., similar to normal per-Type usage). > > Checksum The ICMPv6 checksum. > > Sub-Type Experimental Protocol Sub-Types. > This format basically adds 1 bit to the type field. I wonder whether that is enough. Why limit the subtype to 8 bits? Why not use 32 bits, and some decentralized allocation scheme? -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
