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 PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, June 02, 2004 12:59 AM Subject: RE: Common ICMP Type Assignment for Experimental Protocols 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 PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext gabriel montenegro Sent: Tuesday, June 01, 2004 2:26 AM To: [EMAIL PROTECTED] 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 PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------