Subject: RE: Common ICMP Type Assignment for Experimental Protocols

From: [email-masked]
Date: Wed, 2 Jun 2004 02:59:00 -0500

Gabriel,

I have submitted the updated version of the ICMPv6 draft 
(draft-ietf-ipngwg-icmp-v3-04.txt) today.  The draft is available at
http://sonic.net/~mukesh77/draft-ietf-ipngwg-icmp-v3-04.txt till it 
appears on the IETF website.

Please look at section 2.1 (Message General Format).  The section
adds type 100, 101, 200 and 201 for private experimentation.  Also
section 6 (IANA consideration) describes a policy on allocating 
reclaimable ICMP type and code values.

Is this going to help your work ??

Please review the relevent sections of the draft and let me know if
making any changes to the draft will solve your purpose.

Regards
Mukesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
ext gabriel montenegro
Sent: Tuesday, June 01, 2004 2:26 AM
To: [email-masked]
Cc: Thomas Narten; James Kempf; Rajeev Koodli
Subject: Common ICMP Type Assignment for Experimental Protocols

Folks,

James Kempf, Rajeev Koodli and I have been discussing with Thomas Narten
about an ICMP Type for experimental protocols. Since Thomas suggested we query
the IPv6 WG for feedback on this, I'm sending the description of what we're
thinking about.

Does this seem useful? Does the format make sense? Any other potential uses
of such a facility if it were adopted?

Thanks for any comments,

-gabriel
--------------------------------------------------------
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.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
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 11:32:22 +0200

> reclaimable ICMP type and code values.

Hi,

Not sure we can use 100,101,200 or 201. From the draft:

    It is
    expected that multiple concurrent experiments will be done with the
    same type values.

Beyond very limited usage within a lab or a specific site, I don't
believe these can be used safely. For example, I hear rumors about
impending FMIPv6 deployments, in which case these codes would not
really work.

So we're left with:

    Any wide scale and/or uncontrolled usage should
    obtain real allocations as defined in section 6.

We're certainly in this category. But you also define
Type 255 for future assignment in case of shortage. What
we're proposing is a way of doing such extended typing.

> Is this going to help your work ??

Well, it supports our work, because we can obtain a new assignment.
Nothing to add to your draft.

I think the question is more the other way around:

	Given that we're adopting our format for our own
	protocols, would this be useful for others as well?

I don't believe the ICMPv6 draft needs to be modified in this
respect, though. We're just suggesting a new assignment and
how to handle it (as allowed by your draft). So we currently fall within
item #2 of your IANA considerations section (assignments with the
reclaimable tag), and moving soon to item #1 (permanent
assignment), because CARD/CTP and FMIPv6 will be going soon to experimental
RFC's.

> making any changes to the draft will solve your purpose.

I did notice the absence of RFC2434 language in your draft, and
I'd suggest using it for clarity and consistency with other IANA
sections or documents (e.g., rfc2780).

For example, in your IANA section,
item 3 seems to map to "specification required" or "IESG approval".
I'm not as clear with respect to item 1. At first sight,
it would seem to map to "standards action", but actually it
differs as you specifically include non-standards track documents
(e.g., experimental). It is because of your support for experimental
RFC's that our seamoby/FMIPv6 assignment is supported.

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jun 2004 09:34:50 -0700

Mukesh,

I briefly looked through your draft and I agree with Gab's assessment. The
types outlined there for "private experimental" use are not appropriate for
the Seamoby and FMIP protocols because we don't expect there to be multiple,
concurrent usage of these types. We expect there to be co-ordinated
prototype deployments for purposes of testing interoperability and assessing
various characteristics of the protocols in realistic deployment situations.

Using 255 is a possibility, but this would require agreeing now on a
generalized extension mechanism. I believe there are a few reasons why
that's not advisable. One is that its not yet necessary, so it seems
premature. Another is that, as Seamoby chair, I'd like to get the WG wrapped
up as quickly as possible, and therefore not spend a lot of time discussing
exactly what is the right mechanism for genralized ICMP extension,
especially since, from an IPv6 standpoint, it isn't yet necessary. Rather,
I'd like to see the mechanism Gab proposed as an experiment, just for
experimental mobility protocols, which might later be an appropriate general
mechanim for extension. Also, it is possible that somewhere down the line
the experimental mobility protocols might become PSs. I think it would be
far easier for the transition to PS if we could keep the subtype structure
for the experimental mobility protocols rather than having to reallocate
ICMP type codes. Finally, from a Seamoby standpoint, the Seamoby protocols
are designed for IPv4 too, and I'd like to have the same subtype codes. It
probably won't be possible to have the same ICMP type code, of course.

I also have a basic question on the partitioning of the ICMP code space into
error and informational messages, as described in Section 2.1 of your draft.
While this partioning is valid for the types you describe in the draft, I
think it misses the additional function of ICMP in IPv6 involving signaling
on the local link that may cause state changes in the node. "Error" and
"informational" to me don't imply any state change in the node. Such state
change is caused  by, for example, RS with a Link Address option (router's
Neighbor Cache is updated), ND for DAD (could cause tentative IP address to
become confirmed or not), and, in the current case, Seamoby CTP (initiate
transfer of feature context between routers) and FMIP (initiate local
routing change and update router Neighbor Cache with mobile node's IP
address).

            jak

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, June 02, 2004 12:59 AM
Subject: RE: Common ICMP Type Assignment for Experimental Protocols

Gabriel,

Regards
Mukesh

-----Original Message-----

Folks,

James Kempf, Rajeev Koodli and I have been discussing with Thomas Narten
about an ICMP Type for experimental protocols. Since Thomas suggested we
query
the IPv6 WG for feedback on this, I'm sending the description of what we're
thinking about.

Thanks for any comments,

-gabriel

1. Background

    0                   1                   2                   3

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

5. IANA Implications

---

From: Bob Hinden <[email-masked]>
Date: Thu, 03 Jun 2004 16:04:16 -0700

Gabriel,

>impending FMIPv6 deployments, in which case these codes would not

Yes, I agree in this case it would be better to get individual assignments.

>we're proposing is a way of doing such extended typing.

The thinking behind the assignment strategy in the IANA considerations 
section of the draft is that the there isn't that many current assignments 
and if we should get to the point of running out of assignments, it would 
be easy to extend the space by using the type=255 value.

I am not sure it is necessary to deal with an extension mechanisms at this 
point in time.  As you pointed out there are only 23 current assignments.

>assignment), because CARD/CTP and FMIPv6 will be going soon to experimental

Agreed.

>sections or documents (e.g., rfc2780).

It was my understanding that one could use the RFC2434 language, or if one 
wanted to do something more specific then it wasn't required.  I could be 
wrong about this.

>RFC's that our seamoby/FMIPv6 assignment is supported.

Right, we are proposing an approach that was somewhat different from the 
RFC2434 language in that the main requirement for an assignment was a 
published specification, not the documents standardization status.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 03 Jun 2004 16:24:29 -0700

James,

>error and informational messages, as described in Section 2.1 of your draft.

The partitioning of the ICMP type values has been around in all of the 
ICMPv6 RFCs.  This draft is updating RFC2463 currently at Draft Standard.

>routing change and update router Neighbor Cache with mobile node's IP

I tend to agree that many of the assignments in the "informational" part of 
ICMPv6 type values are doing more than providing information.  I think the 
"informational" term at best only apples to the functions in the ICMP 
specification and not the other protocols using the type assignments.  It 
might have been clearer if we used a different word than "informational", 
but I personally don't see very much value changing it at this point in time.

Bob

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 04 Jun 2004 09:04:05 +0200

Bob,

Bob Hinden wrote:
...
> I am not sure it is necessary to deal with an extension mechanisms at 
> this point in time. ...

Ok, I believe this pretty much sums it up. My reading of the feedback is that
(1) it probably does not make much sense to pursue a general extension
mechanism at this time, and (2) there is nothing much wrong with the format
we are considering.

I believe then the best course of action is to pursue that format for our
use within Seamoby and MIPSHOP, and we can expect to get one ICMP Type
assignment for that.

...

> It was my understanding that one could use the RFC2434 language, or if 
> one wanted to do something more specific then it wasn't required.  I 
> could be wrong about this.

I'm quite sure that's the case, I hope I wasn't implying otherwise.
I was just suggesting that when the desired policy actually matches
one of the well-known clauses or phrases in 2434, it might be
a good idea to just use that language. Just for consistency of
terminology, that's all.

thanks,

-gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 04 Jun 2004 09:07:52 +0200

Bob,

> ICMPv6 RFCs.  This draft is updating RFC2463 currently at Draft Standard.

Right, that's legacy, and even though on hindsight it does not seem
to have been a good idea, I agree that it's not worth changing now.

-gabriel