ICMP informational messages can be easily handled by adding type and code selectors and defining the 16-bit "port" field in the IKE Identity payload to be used as a "type" and "code" field. The selector addition is something that can be done by any implementation without any changes to bits on the wire -- a future revision of the base spec [RFC2401] could make this either optional or manditory.
What is required is a way to negotiate the availability of this selector, so it does require an extension to IKE, and this must be documented and standardized. As it would be inside of a proposal payload, an implementation that did not recognize the type/code decoding would simply not accept that proposal.
A problem that arrises is that one would have to establish an SA for each type/code that one wished to permit to be transmitted. Many administrators would be happy to simply permit some subset of ICMP messages through as a group.
A much desired extension to IKE would permit multiple selectors to be used when establishing an SA. An alternate, but complementary method would permit the selectors for an SA to be changed -- i.e. to permit new flows into an existing SA without rekeying it.
The design and deployment of selector groups for IKE may take an extended period of time. A vendor who wished to permit information ICMP messages into a given SA might be better to define a new identity payload which was defined to be very much like the existing identity payload, but implicitely included ICMP messages in the SA. Again, this would be seen to be an unknown proposal to an incompatible responder, and that proposal would not be selected.