Change in ICMP Mobility Type

Folks,

At the request of Gab Montenegro, we are currently discussing on
[email protected] exactly how to get a common experimental mobility ICMP type
code for both Seamoby and FMIP. The current proposal is described in the
attachment below. At the moment, it is not certain whether the ICMP subtype
format proposed below will be for all experimental protocols or just for the
experimental mobility protocols. And, the discussion is currently only going
on for IPv6, presumably IPv4 would follow that format. This discussion means
that, unfortunately, the Seamoby document approval process will be postponed
until the issue is resolved.

If you have any comments, please post them to the IPv6 list.

            jak

------------------------------------------------------

Common ICMP Type Assignment for Experimental Protocols

1. Background

Several experimental protocols will soon be requesting ICMP Type
assignments from IANA:


- CARD and CTP from the SEAMOBY WG, and
- FMIPv6 from the MIPSHOP WG.

Because of (1) the limited number of ICMP Types, and (2) the
unpredictability of experimental protocols' advancement as
proposed standards, the AD's have asked us to limit our
requests for permanent ICMP Types.

We have complied by modifying FMIPv6 to
use one ICMP Type instead of the previous four and by SEAMOBY's
requesting one shared Type for both CARD and CTP.
Nevertheless, the way things were going, we were about to
request two separate ICMP Types (one for the SEAMOBY protocols,
and another one for FMIPv6).

We are now ironing out the details for a common format.
We also wish to specify the format such that this single Type
could also be used for other experimental protocols (i.e.,
an "Experimental Protocol" Type not just an "Experimental
Mobility" Type).

Because of the potentially wider applicability, we are seeking your input.


2. Format of the Experimental Protocol Type

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.

   Reserved  MUST be set to zero by the sender and ignored by
            the receiver, unless defined otherwise by Sub-Types.


This new Type/Sub-Type format would be specified in the next revision of
draft-ietf-seamoby-iana-01.txt.

As an example usage, FMIPv6 would put the flags after the
Sub-Type (octet 5) and leave octets 6 and 7 for the identifier.

3. Rationale for the Proposed Format

The above format is proposed as a *general* experimental facility
not necessarily limited to mobility related protocols. If such
a generalization is not deemed worth the effort or too premature,
we are also considering the possibility of going forward with a format
for limited use of experimental mobility protocols only.

Your feedback will help us understand if we wish to pursue a
general or a limited proposal.

An alternative format is to insert the "sub-type" information
in the Code field.

Instead, the above format leaves the Code field unchanged. This has an
advantage if and when an experimental protocol is ready to move out
from under the "experimental ICMP Type" into its own Type. In such
a case the handling of both the Type and Sub-Type fields must be
modified, but at least the Code field is left untouched.

Filtering applications are another consideration. The format above keeps
both
the Type and Sub-Type information within the fixed ICMP header, so it is not
expected to pose difficulties from this point of view.

4. Initial Assignments

 Protocol/Message  Sub-Type              Reference
----------------------------------------------------------------------
  CARD                0       draft-ietf-seamoby-card-protocol
  CTP                 1       draft-ietf-seamoby-ctp
  FMIPv6/HI           2       draft-ietf-mipshop-fast-mipv6
  FMIPv6/HACK         3       draft-ietf-mipshop-fast-mipv6
  FMIPv6/RtSolPr      4       draft-ietf-mipshop-fast-mipv6
  FMIPv6/PrRtAdv      5       draft-ietf-mipshop-fast-mipv6

5. IANA Implications

IANA would be requested to set up a registry with the above initial values
for Sub-Types.


New Sub-Type values would be assigned via  "specification required",
"Standards Action" or "IESG Approval" as defined in RFC 2434.