Subject: [MOBILE-IP] Mobile IP dinner

From: Carl Williams <[email-masked]>
Date: Sun, 5 Mar 2000 13:04:57 -0800

Will happen after the Roundtable. Still some room.
We have about 50 signed up.

Again, send email to [email-masked] for RSVP to
do the Mobile iP dinner.  *NO* need to RSVP for
attending roundtable - it is open to anyone and
no registration required.

Also Reminder:  Conny Larson will be talking at 3:00pm
at the Crowne Plaza Ballroom on the Ericsson Mobile IPv6
research implementation on Monday (3/6).

Mobile IP Dinner
================

Some members of the panel will be joining Connectathon
participants for dinner after the event at a local San Jose
restaurant.  If you are interested in attending the dinner
you *must* RSVP John Hird at [email-masked].  You will be
responsible for the cost of your dinner.  More information
about where the dinner will be provided at the roundtable
event.  There will be limited room so the RSVP will be on
a first come basis.

---

From: Gopal Dommety <[email-masked]>
Date: Sun, 5 Mar 2000 23:42:39 -0800

Hello:

        In the format of the Vendor Specific Extensions, we are making the following change:

Previously Vendor-Type and opaque data were defined. It was  recommended that the opaque date be encoded as length and value pair.

Now Vendor-Type, Vendor-Lenght, and Vendor-Value are defined.

Please let me know if any of you have any objections. I am appending the draft.

Thanks
Gopal

Mobile IP Working Group                                    Gopal Dommety
INTERNET DRAFT                                             Kent Leung
February 2000                                              cisco Systems

Expires August 2000

           Mobile IP Vendor/Organization-Specific Extensions
                draft-ietf-mobileip-vendor-ext-10.txt

Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document defines two new extensions to Mobile
   IP [1]. These extensions will facilitate equipment vendors and
   organizations to make specific use of these extensions as they see
   fit for research or deployment purposes.

Dommety, Leung                                                  [Page 1]

Internet Draft    Mobile IP Vendor-Specific Extensions       February 2000

1. Introduction

   Current specification of Mobile IP [1] does not allow for
   organizations and vendors to include organization/vendor-specific
   information in the Mobile IP messages. With the imminent wide scale
   deployment of Mobile IP it is useful to have vendor or
   organization-Specific Extensions to support this capability. This
   draft defines two extensions that can be used for making
   organization specific extensions by vendors/organizations for
   their own specific purposes.

1.1. Specification Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [3].

   In addition, the following words are used to signify the requirements
   of the specification.

   silently discard
              The implementation discards the datagram without
              further processing, and without indicating an error
              to the sender.  The implementation SHOULD provide the
              capability of logging the error, including the contents
              of the discarded datagram, and SHOULD record the event
              in a statistics counter.

2. Vendor/Organization Specific Extensions

   Two Vendor/Organization Specific Extensions are described, Critical
   (CVSE) and Normal (NVSE) Vendor/Organization Specific Extensions.
   The basic differences  between the Critical and Normal Extensions
   are that when the Critical extension is encountered but not recognized,
   the message containing the extension MUST be silently discarded, whereas
   when a Normal Vendor/Organization Specific Extension is encountered
   but not recognized, the extension SHOULD be ignored, but the rest of the
   Extensions and message data MUST still be processed. Another
   difference between the two is that Critical Vendor/Organization
   Extension has a length field of two octets and the NVSE has a
   length field of only one octet.

2.1. Critical Vendor/Organization Specific Extension (CVSE)

   The format of this extension is as shown below.

    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      |   Reserved    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Vendor/Org-ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Vendor-CVSE-Type     |         Vendor-Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Vendor-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 1: Critical Vendor/Organization Specific Extension

   Type       38 (To be assigned by IANA)

   Reserved   Reserved for future use. MUST be set to 0 on sending,
              MUST be ignored on reception.

   Length     Length in bytes of this extension, not including the
              Type and Length bytes.

   Vendor/Org-ID
              The high-order octet is 0 and the low-order 3 octets

Dommety, Leung                                                  [Page 2]

Internet Draft    Mobile IP Vendor-Specific Extensions       February 2000

              are the SMI Network Management Private Enterprise Code
              of the Vendor in network byte order, as defined in the
              Assigned Numbers RFC [2].

   Vendor-CVSE-Type
              Indicates the particular type of Vendor-Sub-Extension.  The
              administration of the Vendor-CVSE-Types is done by the
              Vendor.
   Vendor-Length
              Length in bytes of this Vendor-Sub-Extension, not including the
              Vendor-CVSE-Type and Vendor-Length bytes.

   Vendor-Data

              Vendor/organization specific data of this Vendor-Sub-Extension.
              These data fields may be published in future RFCs.  The
              Vendor-Data is zero or more octets.

   Multiple Vendor-Sub-Extensions specified by Vendor-CVSE-Type, Vendor-Length,
   and Vendor-Data can be included in a CVSE.

   The length field of this extension is chosen to be two bytes long
   to allow for more than 248 bytes of Opaque Data.  If an
   implementation does not recognize the CVSE, according to RFC [1]
   the entire packet is to be silently dropped. But if an agent
   recognizes the CVSE, then it is aware of how to deal with the
   length size.

2.2. Normal Vendor/Organization Specific Extension (NVSE)

   The format of this extension is as shown below.

    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      |    Length     |               Reserved        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vendor/Org-ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Vendor-NVSE-Type           | Vendor-Length | Vendor-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: Normal Vendor/Organization Specific Extension

   Type       134 (To be assigned by IANA)

   Length     Length in bytes of this extension, not including the
              Type and Length bytes.

   Reserved   Reserved for future use. To be set to 0.

   Vendor/Org-ID
              The high-order octet is 0 and the low-order 3
              octets are the SMI Network Management Private
              Enterprise Code of the Vendor in network byte order,
              as defined in the Assigned Numbers RFC [2].

    Vendor-NVSE-Type
              Indicates the particular type of Vendor-Sub-Extension.
              The administration of the Vendor-NVSE-Types is done by the
              Vendor.

   Vendor-Length
              Length in bytes of this Vendor-Sub-Extension, not including the
              Vendor-NVSE-Type and Vendor-Length bytes.

   Vendor-Data

              Vendor/organization specific data of this Vendor-Sub-Extension.
              These data fields may be published in future RFCs.  The
              Vendor-Data is zero or more octets.

   Multiple Vendor-Sub-Extensions specified by Vendor-NVSE-Type,
   Vendor-Length, and Vendor-Data can be included in a NVSE.

2.3 Vendor/Organization Specific Extensions Processing Considerations

   When a Mobile IP entity receives a registration request message (or
   any other request/update message) with an extension of type 38
   (CVSE) and recognizes it, but the extension contains an
   unknown/unsupported vendor ID or does not know how to interpret the
   opaque data or a part of opaque data, a registration reject (or the
   appropriate deny message) MUST be sent with the error code to
   indicate that the registration was rejected due to the presence of
   an unknown CVSE.

   When a Mobile IP entity receives a registration reply (or any other
   mobile IP reply/acknowledgement message) with an extension of type 38
   (CVSE) and recognizes it, but the extensions contains an
   unknown/unsupported vendor ID or does not know how to interpret the
   opaque data or a part of opaque data, the processing is performed as
   described below.

   1. If the Mobile IP entity is a transit node for the reply (i.e, this
   entity  processes and sends the registration reply to another entity)
   a registration reject (or the appropriate deny message) MUST be sent
   with the error code to indicate that the registration was rejected due
   to the presence of an unknown CVSE. For example, FA when it receives an
   un understood CVSE in a registration reply from the HA, should send a
   registration reject to the MN.

   2. If the Mobile IP entity is not a transit node for the reply, the
   reply is treated as a reject (or the appropriate deny message) due to
   the presence of an unknown CVSE.

   While designing enhancements wherein a CVSE is included in a reply
   message, it should noted that the reply message could be discarded
   by the mobile IP entity processing this message.  Enhancements that
   include  a CVSE should take this into consideration during design.

   When a Mobile IP entity receives a mobile IP related message
   (registration request/reply, advertisement/solicitation, etc) with
   an extension of type 134 (NVSE) and recognizes it, but the extension
   contains an unknown/unsupported vendor ID or does not know how to
   interpret the opaque data, the entire extension is skipped. If it does
   not know how to interpret only a part of the opaque data that part of
   the extension is skipped.

   NOTE that according to RFC 2002 [1], when an extension numbered within
   the range 0 through 127 is encountered in a registration message but
   not recognized, the message containing that extension MUST be
   silently discarded.  This draft is compliant with the above
   specification and specifies the action if the extension of type 38
   is encountered and recognized, but does not support the vendor ID or
   the vendor type extension within.

2.4 Error Codes

   The following error codes are defined.

   Registration denied by the Foreign agent:

        107: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Mobile Node to the
        Foreign Agent.

        108: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Home Agent to the
        Foreign Agent.

   Registration denied by the Home agent:

        141: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Mobile Node to the Home Agent.

        142: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Foreign Agent to the Home Agent.

Dommety, Leung                                                  [Page 3]

Internet Draft    Mobile IP Vendor-Specific Extensions       February 2000

3. Restrictions

   Multiple TLV's with the types 38 and 134 can be included in a
   message.  TLVs with types 38 and 134 can be placed anywhere after
   the fixed portion of the Mobile IP message.  These TLVs
   are expected to be protected by the corresponding authenticator as
   necessary.  Ordering of these TLV's should not be modified by
   intermediate nodes.

4. IANA Considerations

   The  Critical Vendor/Organization Specific Extension (CVSE) as
   defined in Section 2.1  and Normal  Vendor/Organization  Specific
   Extension (NVSE) as defined in section 2.2 are proposed new
   extensions to the Mobile IP protocol, defined in RFC 2002 [1] and
   extended in RFC 2356 [5].

   The Authors request IANA to assign the Type value of 38 for the
   Critical Vendor/Organization Specific Extension (CVSE), and a Type
   value of 134 for the Normal Vendor/Organization Specific Extension
   (NVSE) from the. The numbers 38 and 134 for the CVSE and the NVSE
   are taken from the numbering space defined for Mobile IP
   registration extensions [1].

   The new code values specified for errors 107, 108, 141, and
   142 as listed in section 2.4, MUST NOT conflict with any other
   code values listed in RFC 2002, RFC 2344 [9], or RFC 2356 [10]. The
   Authors request IANA to record these values.

   The Type  and code numbers requested have  been identified  as not
   conflicting with any numbers defined in RFC 2002 [1] and extended in
   RFC 2344 [4] and RFC 2356 [5] and documented at
   http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers.

5. Security Considerations

   This document assumes that the Mobile IP messages are authenticated
   using a method defined by the Mobile IP protocol.  This document does
   not impose any additional requirements on Mobile IP messages from a
   security point of view. So this is not expected to be a security
   issue.

6. Acknowledgments

   The authors would like to thank TR45.4 WG, TR45.6 WG, Basavaraj
   Patil, Phil Roberts, Jouni Malinen, and Patrice Calhoun for
   their useful discussions.

7. References

   [1] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
       1996.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       USC/Information Sciences Institute, October 1994.

   [3] Bradner S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, March 1997.

   [4] G. Montenegro.  Reverse Tunneling for Mobile IP.  RFC 2344, May
       1998.

   [5] G. Montenegro and V. Gupta.  Sun's SKIP Firewall Traversal for
       Mobile IP.  RFC 2356, June 1998.

Author Information

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: [email-masked]

   Kent Leung
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: [email-masked]

Dommety, Leung

Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
[email-masked]
Cisco Systems, San Jose, CA, 95051

---

From: Jouni Malinen <[email-masked]>
Date: Mon, 6 Mar 2000 11:17:00 +0200

On Sun, Mar 05, 2000 at 11:42:39PM -0800, Gopal Dommety wrote:

> Previously Vendor-Type and opaque data were defined. It was
> recommended that the opaque date be encoded as length and value
> pair.
>

Is there a good reason for requiring the vendor extensions to have two
length fields even if they have only one sub-extension? The draft
allows one to use multiple vendor extensions in one message and
multiple sub-extensions within each vendor extension. I think that the
internal structure of the vendor extension is up to the vendor
designing it and I thus liked the possibility to use opaque data
without the requirement for strict formating.

>    The format of this extension is as shown below.

Have you some plans for the reserved space in the header? I have been
using multiple NVSEs in a registration message, but these extensions
have only one "sub-extension" and no need for the extra length
field. I would thus like to be able to use something like the
following structure in the extensions (saving three octets):

    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      |    Length     |          Vendor-Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Vendor/Org-ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Opaque Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This way I could use sub-extensions, if I wanted, but at least so far
I haven't come up with a reason to add the concept of
sub-extensions. They would, at least, make the parsing of messages a
bit more complicated and I don't see any extra possibilities compared
to multiple vendor extensions. If I need to add a non-vendor-extension
between two sub-extensions, I would anyway have to separate them in
two vendor extensions. Do you have some examples, in which the
sub-extensions would be more convenient?

--
Jouni Malinen

---

From: Gopal Dommety <[email-masked]>
Date: Mon, 6 Mar 2000 02:13:56 -0800

Jouni:

I too prefer the opaque data type.  There was a comment from IESG to look into
strict typing. Since there was strict typing, I saw no reason not to have multiple sub-extension.
 I did send them a reply stating my preference for leaving it opaque. They came back with the
same suggestion.

>Have you some plans for the reserved space in the header? I have been

Nothing that I can think of. We left it to align. If we do not have multiple sub-extensions
in a extensions, we have the format as you suggested (only for logical seperation we might
prefer to leave it alone). But I agree about the usage of two extra bytes.

Thank You.
Regards,
Gopal

Gopal Dommety
408 525 1404
[email-masked]