Subject: Re: [MOBILE-IP] Draft for Vendor/Organization Specific Extensions

From: Patrice Calhoun <[email-masked]>
Date: Fri, 24 Sep 1999 11:41:44 -0700

Gopal and Kent,

In my haste to get other work done, I missed the fact that your proposal included
two separate extensions, one in the sub-127 space and on in the 127-255 space. This
was good.

However, do we need a new error code to reply back that a vendor specific code was
unrecognized?

PatC
>>
>> Gopal,
>>
>> I think that this is a fine idea, however I have an issue with it. Since there
>is no way
>> to know a priori which vendor's box you will be talking to, what is the
>expected action
>> if one receives either an unsupported vendor extension, or an unknown
>extension from a
>> known vendor? Remember that in the RADIUS world, it has become almost a custom
>to start
>
>Unsupported   vendor extension, or an  unknown  extension from a known
>vendor  for  a  CVSE (Critical)   will  result in  discarding  of  the
>message. For NVSE the extension will be ignored. Is  this what you are
>referring to?
>
>
>Thanks Pat.
>
>-Gopal
>
>
>
>
>
>> supporting all of the various documented, and undocumented, vendor specific
>attributes and
>> the same may apply here.
>>
>> PatC
>>
>> >Hello:
>> >
>> >Attached (and also sent in the previous mail) is a preliminary draft:
>> >
>> >Vendor/Organization-Specific Extensions for Mobile IP
>> >                  <draft-dommety-mobileip-vendor-ext-00.txt>
>> >
>> >
>> >Would really appreciate your comments.
>> >
>> >Thanks.
>> >-Gopal
>> >
>> >
>> >>
>> >> Mobile IP Working Group                                    Gopal Dommety
>> >> INTERNET DRAFT                                             Kent Leung
>> >> August 1999                                                Cisco Systems
>> >>
>> >>
>> >>             Vendor/Organization-Specific Extensions for Mobile IP
>> >>                   <draft-dommety-mobileip-vendor-ext-00.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 draft proposes an extensions that can be used as a vendor
>> >>    or organization-Specific Extensions.  These extensions will facilitate
>> >>    organizations to make specific extensions as they see fit for research
>> >>    or deployment purposes.
>> >>
>> >> 1.0   Introduction
>> >>
>> >>    Current specification of Mobile IP [1] does not allow for
>> >>    organizations and vendor to include organization/vendor-specific
>> >>    extensions in the Mobile IP messages. With the wide scale deployment
>> >>    of Mobile IP it is useful to have a vendor or organization-Specific
>> >>    Extension.  This draft proposes  extensions that can be used for
>> >>    making organization specific extensions.
>> >>
>> >>
>> >> 2.0 Vendor/Organization Specific Extensions
>> >>
>> >> Two  Vendor/Organization Specific Extensions  are described,  Critical
>> >> and Normal    Vendor/Organization  Specific Extensions.     The  basic
>> >> differeces are between the Critical and  the Normal Extensions is that
>> >> whan 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 and not recognized, the extension is 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 lenght feild of two bytes.
>> >>
>> >>
>> >> 2.1 Critical Vendor/Organization Specific Extension
>> >>
>> >>    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             |   Vendor-ID
>> >>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>                      Vendor-ID (cont)                 | Opaque Data...
>> >>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>
>> >>
>> >>                 Figure 1: Vendor/Organization Specific Extension
>> >>
>> >>
>> >>       Type       TBD-1 (value should be in the range of 0-127)
>> >>
>> >>       Length     Length in bytes of this extension, not including the Type
>> >>                  and Length bytes.
>> >>
>> >>       Vendor-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].
>> >>
>> >>       Opaque Data
>> >>                  Vendor/organization specific data.  These data fields
>> >>                  may be publicized in future RFCs.
>> >>
>> >> 2.2 Normal Vendor/Organization Specific Extension
>> >>
>> >>    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     |   Vendor-ID
>> >>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>                  Vendor-ID (cont)     | Opaque Data...                |
>> >>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>
>> >>
>> >>                 Figure 1: Vendor/Organization Specific Extension
>> >>
>> >>
>> >>       Type       TBD-2 (value should be in the range of 128-255)
>> >>
>> >>       Length     Length in bytes of this extension, not including the Type
>> >>                  and Length bytes.
>> >>
>> >>       Vendor-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].
>> >>
>> >>       Opaque Data
>> >>                  Vendor/organization specific data.  These data fields
>> >>                  may be publicized in future RFCs.
>> >>
>> >>
>> >> 3.0 Restrictions
>> >>
>> >>    Multiple TLV's with the TBD-1 and TBD-2 types can  be included in a
>> >> message. TLVs with TBD-1 and TBD-2 types can  be placed anywhere after
>> >> the fixed  portion of the Mobile IP  meggase.  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.0 Security Considerations
>> >>
>> >>    This document assumes that the Mobile IP messages are authenticated
>> >> using a method defined by the Mobile IP protocol.  This proposal 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.
>> >>
>> >>
>> >> 5.0 IPv6 considerations
>> >>
>> >>       This extension can be used in IPv4 and IPv6 alike.
>> >>
>> >> 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.
>> >>
>> >> Authors' Addresses
>> >>
>> >>    Questions about this memo can be directed to:
>> >>
>> >>       Gopal Dommety                   Kent Leung
>> >>       Cisco Systems                     Cisco Systems
>> >>       170 West Tasman Drive             170 West Tasman Drive
>> >>       San Jose, CA 95134                San Jose, CA 95134
>> >>       USA                               USA
>> >>
>> >>       Phone:  +1-408-525-1404           Phone:  +1-408-526-5030
>> >>       EMail:  [email-masked]        EMail:  [email-masked]
>> >>
>> >>
>> >>
>>
>>
>>

---

From: Gopal Dommety <[email-masked]>
Date: Fri, 24 Sep 1999 12:05:09 -0700

> However, do we need a new error code to reply back that a vendor specific code was

Was   thinking about  this. This  will   definelty help. But exisiting
implementations  will not send  the error codes.  Will add error codes
atleast the new implementations will hopefull send them.

Any reasons why an error code was not used for the used for the
cirtical codes (0-127) in RFC2002?

Thanks
Gopal

---

From: "Kent K. Leung" <[email-masked]>
Date: Fri, 24 Sep 1999 12:19:02 -0700

> atleast the new implementations will hopefull send them.

Existing implementations will send 'reason unspecified', which
is OK.

> cirtical codes (0-127) in RFC2002?

Error codes 64 - 127 are for Foreign Agent, 128 - 255 for HA.

-- Kent --

--
     |          |                         Kent Leung
    :|:        :|:                        Software Engineer
   :|||:      :|||:                       IOS Development
.:|||||||:..:|||||||:.                    408.526.5030
c i s c o S y s t e m s                   [email-masked]

---

From: Gopal Dommety <[email-masked]>
Date: Fri, 24 Sep 1999 13:07:46 -0700

> > cirtical codes (0-127) in RFC2002?

Sorry, looks like I messed up again :). I wanted to  know why an error
code was not sent when an existng implementation did not understand an
extension type (0-127) and it drops the message.

Specifically I was referring to the following text of the RFC2002:

 When an Extension numbered in either of these sets within the range 0
   through 127 is encountered but not recognized, the message containing
   that Extension MUST be silently discarded.  When an Extension
   numbered in the range 128 through 255 is encountered which is not
   recognized, that particular Extension is ignored, but the rest of the
   Extensions and message data MUST still be processed.  The Length
   field of the Extension is used to skip the Data field in searching
   for the next Extension.

Thanks
Gopal