RE: [Mip6] Experimental and Vendor specific messages

"Vijay Devarapalli" <Vijay.Devarapalli@AzaireNet.com> Mon, 19 June 2006 23:28 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTA4-0007MJ-Bb; Mon, 19 Jun 2006 19:28:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTA3-0007MA-LA for mip6@ietf.org; Mon, 19 Jun 2006 19:28:03 -0400
Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsT9z-0000aJ-9U for mip6@ietf.org; Mon, 19 Jun 2006 19:28:03 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mip6] Experimental and Vendor specific messages
Date: Mon, 19 Jun 2006 16:27:57 -0700
Message-ID: <C8E1D942CB394746BE5CFEB7D97610E701AE7EE9@bart.corp.azairenet.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mip6] Experimental and Vendor specific messages
Thread-Index: AcaT949s0n+cHTE6SzSusTMmy0W0dAAAETAg
From: Vijay Devarapalli <Vijay.Devarapalli@AzaireNet.com>
To: Samita Chakrabarti <samitac2@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Mobile IPv6 Mailing List <mip6@ietf.org>
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Errors-To: mip6-bounces@ietf.org

> I think the experimental and vendor specific message/options would be
> useful. The drafts talk about node behavior when the node 
> does not understand
> these messages. How about some texts about node behavior when these
> option types are unrecognized ? I assume they will be skipped.

there is some text on this.

   Home agent or
   correspondent node implementations that do not recognize the mobility
   message type, discard the message and send Binding Error message as
   described in [2], with the Status field set to 2 (unrecognized MH
   Type value).  Mobile nodes that do not recognize the mobility message
   type should discard the message and send an ICMP Parameter problem
   with code 0.

   Mobility options, by definition, can be skipped if an implementation
   does not recognize the mobility option type [2].

Vijay

> 
> -Samita
> 
> On 6/15/06, Vijay Devarapalli <vijay.devarapalli@azairenet.com> wrote:
> > hello,
> >
> > the following two drafts specify experimental and vendor
> > specific mobility header messages and options.
> >
> > 
> http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-exp
erimental-messages-00.txt
> > 
> http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-vsm-00.txt
> >
> > the motivation behind these drafts is that they would
> > encourage experiments and protocol extensions to Mobile
> > IPv6. comments would be much appreciated.
> >
> > Vijay
> >
> > _______________________________________________
> > Mip6 mailing list
> > Mip6@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> 

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6