Subject: RE: Common ICMP Type Assignment for Experimental Protocols

From: "Christian Huitema" <[email-masked]>
Date: Tue, 1 Jun 2004 09:57:11 -0700

> 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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 02 Jun 2004 10:38:27 +0200

> nothing decision in firewalls, allow all experiments or deny them all.

The Code is defined on a per-Type basis, and in our proposed format,
on a per Sub-Type basis, so, of course, we are not
proposing (see my previous msg) a single Type-Code combination.

As for grouping *all* experimental protocols together, well, yes,
that's the goal in order to save on ICMP Types. But the info to
distinguish amongst them is in the fixed part of the header
(the Sub-Type field) so any decent firewall can differentiate.

> Mobile-IPv6 as an example of an experiment that can linger on for a very

Not sure what MIPv6 has to do with this. MIPv6 is not an experimental
protocol, right? It's proposed standard. Perhaps you meant 'experimental'
in the sense of not highly deployed, etc. But that would apply to a host
of other IETF protocols as well.

Or, perhaps you're referring to the fact that MIPv6 assigned 4 new ICMP Types?
If so, yes, it's this kind of consideration that I believe leads the AD's
to want to be more conservative in the future.

...
> and some decentralized allocation scheme?

Our goal has not been to change ICMP Type field semantics, so perhaps
we have not even added the 1 bit you mention (from 7 to 8 bits for
informational messages). So the idea is not to grow the ICMP Type
space to a whopping large number. We hear it is best to be conservative
in doling them out, but I don't believe the problem is serious
enough to warrant growing the Type space significantly.

Data point: from a previous thread, the IPv6 chairs noted that
the total number of assignments was:

ICMPv4: 27
ICMPv6: 23

So the situation is not desperate.

-gabriel