From mip6-bounces@ietf.org Wed May 02 12:30:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjHik-0005Wg-8L; Wed, 02 May 2007 12:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjHij-0005Wb-AG for mip6@ietf.org; Wed, 02 May 2007 12:30:25 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjHih-0002h9-Lc for mip6@ietf.org; Wed, 02 May 2007 12:30:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id B5C3490075 for ; Wed, 2 May 2007 12:30:19 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20971-12 for ; Wed, 2 May 2007 12:30:15 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 2 May 2007 12:30:15 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 12:30:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] GRE key Date: Wed, 2 May 2007 12:30:15 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9F5F@exchtewks2.starentnetworks.com> In-Reply-To: <462E3398.7000100@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] GRE key Thread-Index: AceGj7rFzMg4FLNYTRueqQySPl/6sQGRdtug From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" , "Mohamed Khalil" X-OriginalArrivalTime: 02 May 2007 16:30:15.0488 (UTC) FILETIME=[2A0FBC00:01C78CD7] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > I think all other forms of IPv6-in-IPv4 (and in UDPv4) are capable to > deal with the problem of overlapping private IPv4 addressing you cite in > the draft. Don't you think so? Alex, If the LMA (or the HA) has overlapping IPv4 address pools, how does it distinguish the incoming (tunneled) packets? Note that the LMA/HA needs to make this distinction for making next hop decision. For private IPv4 addresses, that means identifying the VLAN tag or tunnel id or the network interface on the egress side of the LMA/HA. AFAIK, GRE keys are used for this purpose. -Kuntal > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, April 24, 2007 11:43 AM > To: Mohamed Khalil > Cc: mip6@ietf.org > Subject: Re: [Mip6] GRE key >=20 > Mohamed Khalil wrote: > > Hi Alexandru, > > > > -----Original Message----- From: Alexandru Petrescu > > [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April 24, 2007 > > 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: mip6@ietf.org Subject: > > Re: [Mip6] GRE key > > > > > > Mohamed Khalil wrote: > >> Hi All, > >> > >> The following draft has been posted on netlmm, your comments and > >> feedback is much appreciated. > >> > >> The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] > >> allows > > > >> the mobile node's IPv4 and IPv6 traffic between the local mobility > >> anchor and the mobile access gateway to be tunneled using IPv6, > >> IPv4 or IPv4-UDP encapsulation headers. These encapsulation modes > >> do not offer semantics for the tunnel end-points to expose a > >> service identifier that can be used to identify traffic for a > >> certain classification, such as for supporting mobile nodes that > >> are using overlapping private IPv4 addressing. The extensions > >> defined in this document allow the mobile access gateway and the > >> local mobility anchor > > > >> to negotiate GRE encapsulation mode and along with the GRE > >> symmetric key or asymmetric keys for marking the flows, so that > >> differential processing can be applied by the tunnel peers over > >> those flows. > > > > Several reasons I believe GRE is not necessary for PMIPv6. > > > > Does GRE work transporting IPv6? I thought it only transports IPv4. > > PMIPv6 assumes IPv6 applications first, in my understanding. > > > > Mohamed>> should be use to transport IP6 too. >=20 > It's true that the RFC I'm referring to is relatively old, is there an > update on the GRE implementation as to show it can transport IPv6? > rfc2784 says: > > o IPv6 as Delivery and/or Payload Protocol > > > > This specification describes the intersection of GRE currently > > deployed by multiple vendors. IPv6 as delivery and/or payload > > protocol is not included in the currently deployed versions of GRE. >=20 > Is there an update to this RFC or to this statement in this RFC? Thanks. >=20 > >> PMIPv6 inherits from MIPv6 tunnelling, which is IPv6-in-IPv6 which > >> is Generic Packet Tunnelling rfc2473 (not GRE); and it maybe > >> inherits from DS-MIPv6 whose method of transporting IPv6 over IPv4 > >> is not yet clarified, but was discussed until now to be IPv6 in > >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol number 41 > >> rfc2893 (yet again not GRE). > >> > >> I think it is also obvious that PMIPv6 done in netlmm WG should > >> encapsulate only once at max, not twice nor more. Ie a packet from > >> LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or > >> maybe IPv6 in IPv6, but not in a double encapsulation like > >> IPv6-in-IPv4-in-GRE). > > > > Mohamed>> I don't see the issue of double encapsulation, IP4-UDP-IP6 > > is double encapsulation (DS-MIP6). IPv4 header (src=3DV4ADDR, > > dst=3DHA_V4ADDR) UDP header IPv6 header (src=3DV4CoA, dst=3DHAADDR) DST-OPT > > HAO (IPv6 home address) Mobility header BU [IPv4 HAO] >=20 > That's simple encapsulation I believe, it's IPv6 packets in UDPv4 > packets. One may interpret that as double encapsulation. >=20 > What I mean is that if the PMIP approach relies on some deployed code > that doesn't assume GRE then where would GRE necessity come from? Could > you answer this? >=20 > >> So in this context, can I ask why GRE? It's not used by MIPv6, was > >> never suggested by DS-MIPv6, can't transport IPv6 and has several > >> implemented alternatives. Why GRE? > > > > mohamed>> GRE is used in this draft to mark/identify traffic for a > > certain classification, such as for supporting mobile nodes that are > > using overlapping private IPv4 addressing. >=20 > Yes, I read that in the abstract. But I don't see any NAT throughout > the document. >=20 > I think all other forms of IPv6-in-IPv4 (and in UDPv4) are capable to > deal with the problem of overlapping private IPv4 addressing you cite in > the draft. Don't you think so? >=20 > Please don't get me wrong. I think many forms of tunnelling are > possible and that some decisions have already been made, and that GRE > tunnelling is straight competitor to the ones I've listed. A dynamic > method to choose between the available methods is probably useful. But > I don't see why pushing solely GRE; again, where is GRE coming from into > the PMIP picture? >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ >=20 > _______________________________________________ > 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 From mip6-bounces@ietf.org Wed May 02 18:08:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjN01-0006Hx-Ro; Wed, 02 May 2007 18:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjN01-0006Hs-4i for mip6@ietf.org; Wed, 02 May 2007 18:08:37 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjMzz-0005jk-Oe for mip6@ietf.org; Wed, 02 May 2007 18:08:37 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1178143714!8401637!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28061 invoked from network); 2 May 2007 22:08:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-128.messagelabs.com with SMTP; 2 May 2007 22:08:34 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l42M8Uar020302; Wed, 2 May 2007 15:08:30 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l42M8T0c016500; Wed, 2 May 2007 17:08:29 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.151]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l42M8Rws016494; Wed, 2 May 2007 17:08:28 -0500 (CDT) Message-ID: <46390BDB.7020200@gmail.com> Date: Thu, 03 May 2007 00:08:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip6] GRE key References: <7CCD07160348804497EF29E9EA5560D7024D9F5F@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9F5F@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000737-2, 30/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip6@ietf.org, Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Chowdhury, Kuntal wrote: >> I think all other forms of IPv6-in-IPv4 (and in UDPv4) are capable >> to deal with the problem of overlapping private IPv4 addressing >> you cite > in >> the draft. Don't you think so? > > Alex, > > If the LMA (or the HA) has overlapping IPv4 address pools, how does > it distinguish the incoming (tunneled) packets? By means of mappings between addresses in the outer and inner headers. In no case by means of a new identifier (key) used as an address. > Note that the LMA/HA needs to make this distinction for making next > hop decision. For private IPv4 addresses, that means identifying the > VLAN tag or tunnel id or the network interface on the egress side of > the LMA/HA. Look, we don't even have a clear idea where _one_ NAT is placed in this PMIPv6/v4 picture (the draft doesn't place _any_ NAT) and we speculate about two overlapping private spaces. Where are the two NATs placed? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 03 05:28:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjXcC-00052l-7W; Thu, 03 May 2007 05:28:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjXcA-0004zv-Jm for mip6@ietf.org; Thu, 03 May 2007 05:28:42 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjXc7-0005sW-1q for mip6@ietf.org; Thu, 03 May 2007 05:28:42 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1178184517!11598016!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 29037 invoked from network); 3 May 2007 09:28:37 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-9.tower-128.messagelabs.com with SMTP; 3 May 2007 09:28:37 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l439STh1016688; Thu, 3 May 2007 02:28:29 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l439SSoF003701; Thu, 3 May 2007 04:28:28 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l439SPUE003635; Thu, 3 May 2007 04:28:26 -0500 (CDT) Message-ID: <4639AB33.6070703@gmail.com> Date: Thu, 03 May 2007 11:28:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Casati, Alessio \(Alessio\)" Subject: Re: [Mip6] GRE key References: <462E3398.7000100@gmail.com> <7CCD07160348804497EF29E9EA5560D7024D9F5F@exchtewks2.starentnetworks.com> <02C627D961164445AFBC01BBDD0EC3244DDFD9@DEEXC1U01.de.lucent.com> In-Reply-To: <02C627D961164445AFBC01BBDD0EC3244DDFD9@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000737-2, 30/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: mip6@ietf.org, Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Casati, Alessio (Alessio) wrote: > Kuntal's view is correct from here too. Where are the NATs? I don't see them. Alex > > Alessio > > *-----Original Message----- > *From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > *Sent: 02 May 2007 17:30 > *To: Alexandru Petrescu; Mohamed Khalil > *Cc: mip6@ietf.org > *Subject: RE: [Mip6] GRE key > * > *> I think all other forms of IPv6-in-IPv4 (and in UDPv4) are > *capable to > *> deal with the problem of overlapping private IPv4 addressing you cite > *in > *> the draft. Don't you think so? > * > *Alex, > * > *If the LMA (or the HA) has overlapping IPv4 address pools, how > *does it distinguish the incoming (tunneled) packets? Note that > *the LMA/HA needs to make this distinction for making next hop > *decision. For private IPv4 addresses, that means identifying > *the VLAN tag or tunnel id or the network interface on the > *egress side of the LMA/HA. > * > *AFAIK, GRE keys are used for this purpose. > * > *-Kuntal > * > * > * > *> -----Original Message----- > *> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > *> Sent: Tuesday, April 24, 2007 11:43 AM > *> To: Mohamed Khalil > *> Cc: mip6@ietf.org > *> Subject: Re: [Mip6] GRE key > *> > *> Mohamed Khalil wrote: > *> > Hi Alexandru, > *> > > *> > -----Original Message----- From: Alexandru Petrescu > *> > [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April 24, 2007 > *> > 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: > *mip6@ietf.org Subject: > *> > Re: [Mip6] GRE key > *> > > *> > > *> > Mohamed Khalil wrote: > *> >> Hi All, > *> >> > *> >> The following draft has been posted on netlmm, your comments and > *> >> feedback is much appreciated. > *> >> > *> >> The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] > *> >> allows > *> > > *> >> the mobile node's IPv4 and IPv6 traffic between the local > *mobility > *> >> anchor and the mobile access gateway to be tunneled using IPv6, > *> >> IPv4 or IPv4-UDP encapsulation headers. These > *encapsulation modes > *> >> do not offer semantics for the tunnel end-points to expose a > *> >> service identifier that can be used to identify traffic for a > *> >> certain classification, such as for supporting mobile nodes that > *> >> are using overlapping private IPv4 addressing. The extensions > *> >> defined in this document allow the mobile access gateway and the > *> >> local mobility anchor > *> > > *> >> to negotiate GRE encapsulation mode and along with the GRE > *> >> symmetric key or asymmetric keys for marking the flows, so that > *> >> differential processing can be applied by the tunnel peers over > *> >> those flows. > *> > > *> > Several reasons I believe GRE is not necessary for PMIPv6. > *> > > *> > Does GRE work transporting IPv6? I thought it only > *transports IPv4. > *> > PMIPv6 assumes IPv6 applications first, in my understanding. > *> > > *> > Mohamed>> should be use to transport IP6 too. > *> > *> It's true that the RFC I'm referring to is relatively old, > *is there an > *> update on the GRE implementation as to show it can transport IPv6? > *> rfc2784 says: > *> > o IPv6 as Delivery and/or Payload Protocol > *> > > *> > This specification describes the intersection of GRE currently > *> > deployed by multiple vendors. IPv6 as delivery and/or payload > *> > protocol is not included in the currently deployed versions of GRE. > *> > *> Is there an update to this RFC or to this statement in this RFC? > *Thanks. > *> > *> >> PMIPv6 inherits from MIPv6 tunnelling, which is > *IPv6-in-IPv6 which > *> >> is Generic Packet Tunnelling rfc2473 (not GRE); and it maybe > *> >> inherits from DS-MIPv6 whose method of transporting IPv6 > *over IPv4 > *> >> is not yet clarified, but was discussed until now to be IPv6 in > *> >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol > *number 41 > *> >> rfc2893 (yet again not GRE). > *> >> > *> >> I think it is also obvious that PMIPv6 done in netlmm WG should > *> >> encapsulate only once at max, not twice nor more. Ie a > *packet from > *> >> LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or > *> >> maybe IPv6 in IPv6, but not in a double encapsulation like > *> >> IPv6-in-IPv4-in-GRE). > *> > > *> > Mohamed>> I don't see the issue of double encapsulation, > *IP4-UDP-IP6 > *> > is double encapsulation (DS-MIP6). IPv4 header (src=V4ADDR, > *> > dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, dst=HAADDR) > *DST-OPT > *> > HAO (IPv6 home address) Mobility header BU [IPv4 HAO] > *> > *> That's simple encapsulation I believe, it's IPv6 packets in UDPv4 > *> packets. One may interpret that as double encapsulation. > *> > *> What I mean is that if the PMIP approach relies on some > *deployed code > *> that doesn't assume GRE then where would GRE necessity come from? > *Could > *> you answer this? > *> > *> >> So in this context, can I ask why GRE? It's not used by > *MIPv6, was > *> >> never suggested by DS-MIPv6, can't transport IPv6 and has several > *> >> implemented alternatives. Why GRE? > *> > > *> > mohamed>> GRE is used in this draft to mark/identify traffic for a > *> > certain classification, such as for supporting mobile > *nodes that are > *> > using overlapping private IPv4 addressing. > *> > *> Yes, I read that in the abstract. But I don't see any NAT > *throughout > *> the document. > *> > *> I think all other forms of IPv6-in-IPv4 (and in UDPv4) are > *capable to > *> deal with the problem of overlapping private IPv4 addressing you cite > *in > *> the draft. Don't you think so? > *> > *> Please don't get me wrong. I think many forms of tunnelling are > *> possible and that some decisions have already been made, and > *that GRE > *> tunnelling is straight competitor to the ones I've listed. > *A dynamic > *> method to choose between the available methods is probably useful. > *But > *> I don't see why pushing solely GRE; again, where is GRE coming from > *into > *> the PMIP picture? > *> > *> Alex > *> > *> > *> > *______________________________________________________________________ > *> This email has been scanned by the MessageLabs Email Security System. > *> For more information please visit http://www.messagelabs.com/email > *> > *______________________________________________________________________ > *> > *> _______________________________________________ > *> 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 > * > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 03 09:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjbEj-0001QC-5p; Thu, 03 May 2007 09:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjbEh-0001Q7-Oz for mip6@ietf.org; Thu, 03 May 2007 09:20:43 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjbEe-0008Qu-BR for mip6@ietf.org; Thu, 03 May 2007 09:20:43 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l43DKbS18603; Thu, 3 May 2007 13:20:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] GRE key Date: Thu, 3 May 2007 08:19:53 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437113FBA32E@zrc2hxm2.corp.nortel.com> In-Reply-To: <4639AB33.6070703@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] GRE key Thread-Index: AceNZXupB47vQvHoSMe2TkeEOXsGFAAH9SwA References: <462E3398.7000100@gmail.com> <7CCD07160348804497EF29E9EA5560D7024D9F5F@exchtewks2.starentnetworks.com> <02C627D961164445AFBC01BBDD0EC3244DDFD9@DEEXC1U01.de.lucent.com> <4639AB33.6070703@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" , "Casati, Alessio \(Alessio\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, Please see comment inline. >=20 > Casati, Alessio (Alessio) wrote: > > Kuntal's view is correct from here too. >=20 > Where are the NATs? I don't see them. That is the key Alex, there is no NAT in the PMIP domain for this case. I believe the figure in the draft is quite straight forward. If you need further discussion on this we can do it offline, if you prefer. >=20 > Alex >=20 > >=20 > > Alessio > >=20 > > *-----Original Message----- > > *From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > *Sent: 02 May 2007 17:30 > > *To: Alexandru Petrescu; Mohamed Khalil > > *Cc: mip6@ietf.org > > *Subject: RE: [Mip6] GRE key > > * > > *> I think all other forms of IPv6-in-IPv4 (and in UDPv4)=20 > are *capable=20 > > to *> deal with the problem of overlapping private IPv4=20 > addressing you=20 > > cite *in *> the draft. Don't you think so? > > * > > *Alex, > > * > > *If the LMA (or the HA) has overlapping IPv4 address pools,=20 > how *does=20 > > it distinguish the incoming (tunneled) packets? Note that=20 > *the LMA/HA=20 > > needs to make this distinction for making next hop *decision. For=20 > > private IPv4 addresses, that means identifying *the VLAN=20 > tag or tunnel=20 > > id or the network interface on the *egress side of the LMA/HA. > > * > > *AFAIK, GRE keys are used for this purpose. > > * > > *-Kuntal > > * > > * > > * > > *> -----Original Message----- > > *> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > *> Sent: Tuesday, April 24, 2007 11:43 AM *> To: Mohamed=20 > Khalil *> Cc:=20 > > mip6@ietf.org *> Subject: Re: [Mip6] GRE key *> *> Mohamed Khalil=20 > > wrote: > > *> > Hi Alexandru, > > *> > > > *> > -----Original Message----- From: Alexandru Petrescu *> >=20 > > [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April=20 > 24, 2007 *>=20 > > > 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: > > *mip6@ietf.org Subject: > > *> > Re: [Mip6] GRE key > > *> > > > *> > > > *> > Mohamed Khalil wrote: > > *> >> Hi All, > > *> >> > > *> >> The following draft has been posted on netlmm, your=20 > comments and=20 > > *> >> feedback is much appreciated. > > *> >> > > *> >> The Proxy Mobile IPv6 base specification defined in=20 > [PMIP6-ID]=20 > > *> >> allows *> > *> >> the mobile node's IPv4 and IPv6 traffic=20 > > between the local *mobility *> >> anchor and the mobile=20 > access gateway=20 > > to be tunneled using IPv6, *> >> IPv4 or IPv4-UDP encapsulation=20 > > headers. These *encapsulation modes *> >> do not offer=20 > semantics for=20 > > the tunnel end-points to expose a *> >> service identifier=20 > that can be=20 > > used to identify traffic for a *> >> certain=20 > classification, such as=20 > > for supporting mobile nodes that *> >> are using=20 > overlapping private=20 > > IPv4 addressing. The extensions *> >> defined in this=20 > document allow=20 > > the mobile access gateway and the *> >> local mobility=20 > anchor *> > *>=20 > > >> to negotiate GRE encapsulation mode and along with the GRE *> >>=20 > > symmetric key or asymmetric keys for marking the flows, so=20 > that *> >>=20 > > differential processing can be applied by the tunnel peers=20 > over *> >>=20 > > those flows. > > *> > > > *> > Several reasons I believe GRE is not necessary for PMIPv6. > > *> > > > *> > Does GRE work transporting IPv6? I thought it only=20 > *transports=20 > > IPv4. > > *> > PMIPv6 assumes IPv6 applications first, in my understanding. > > *> > > > *> > Mohamed>> should be use to transport IP6 too. > > *> > > *> It's true that the RFC I'm referring to is relatively old, *is=20 > > there an *> update on the GRE implementation as to show it can=20 > > transport IPv6? > > *> rfc2784 says: > > *> > o IPv6 as Delivery and/or Payload Protocol *> > *> > This=20 > > specification describes the intersection of GRE currently *> >=20 > > deployed by multiple vendors. IPv6 as delivery and/or payload *> >=20 > > protocol is not included in the currently deployed versions of GRE. > > *> > > *> Is there an update to this RFC or to this statement in this RFC? > > *Thanks. > > *> > > *> >> PMIPv6 inherits from MIPv6 tunnelling, which is > > *IPv6-in-IPv6 which > > *> >> is Generic Packet Tunnelling rfc2473 (not GRE); and=20 > it maybe *>=20 > > >> inherits from DS-MIPv6 whose method of transporting IPv6=20 > *over IPv4=20 > > *> >> is not yet clarified, but was discussed until now to=20 > be IPv6 in=20 > > *> >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol=20 > > *number 41 *> >> rfc2893 (yet again not GRE). > > *> >> > > *> >> I think it is also obvious that PMIPv6 done in netlmm=20 > WG should=20 > > *> >> encapsulate only once at max, not twice nor more. Ie=20 > a *packet=20 > > from *> >> LMA to MAG should only be encapsulated once (IPv6 in=20 > > UDP/IPv4 or *> >> maybe IPv6 in IPv6, but not in a double=20 > > encapsulation like *> >> IPv6-in-IPv4-in-GRE). > > *> > > > *> > Mohamed>> I don't see the issue of double encapsulation, > > *IP4-UDP-IP6 > > *> > is double encapsulation (DS-MIP6). IPv4 header=20 > (src=3DV4ADDR, *> >=20 > > dst=3DHA_V4ADDR) UDP header IPv6 header (src=3DV4CoA,=20 > dst=3DHAADDR) *DST-OPT=20 > > *> > HAO (IPv6 home address) Mobility header BU [IPv4 HAO] *> *>=20 > > That's simple encapsulation I believe, it's IPv6 packets in=20 > UDPv4 *>=20 > > packets. One may interpret that as double encapsulation. > > *> > > *> What I mean is that if the PMIP approach relies on some=20 > *deployed=20 > > code *> that doesn't assume GRE then where would GRE necessity come=20 > > from? > > *Could > > *> you answer this? > > *> > > *> >> So in this context, can I ask why GRE? It's not used=20 > by *MIPv6,=20 > > was *> >> never suggested by DS-MIPv6, can't transport IPv6 and has=20 > > several *> >> implemented alternatives. Why GRE? > > *> > > > *> > mohamed>> GRE is used in this draft to mark/identify=20 > traffic for=20 > > a *> > certain classification, such as for supporting mobile *nodes=20 > > that are *> > using overlapping private IPv4 addressing. > > *> > > *> Yes, I read that in the abstract. But I don't see any NAT=20 > > *throughout *> the document. > > *> > > *> I think all other forms of IPv6-in-IPv4 (and in UDPv4)=20 > are *capable=20 > > to *> deal with the problem of overlapping private IPv4=20 > addressing you=20 > > cite *in *> the draft. Don't you think so? > > *> > > *> Please don't get me wrong. I think many forms of=20 > tunnelling are *>=20 > > possible and that some decisions have already been made,=20 > and *that GRE=20 > > *> tunnelling is straight competitor to the ones I've listed. > > *A dynamic > > *> method to choose between the available methods is=20 > probably useful. > > *But > > *> I don't see why pushing solely GRE; again, where is GRE=20 > coming from=20 > > *into *> the PMIP picture? > > *> > > *> Alex > > *> > > *> > > *> > >=20 > *_____________________________________________________________________ > > _ *> This email has been scanned by the MessageLabs Email Security=20 > > System. > > *> For more information please visit=20 > http://www.messagelabs.com/email=20 > > *>=20 > >=20 > *_____________________________________________________________________ > > _ > > *> > > *> _______________________________________________ > > *> 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 > > * > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 03 10:08:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjbz3-0000A0-Gz; Thu, 03 May 2007 10:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjbz1-00009q-Si for mip6@ietf.org; Thu, 03 May 2007 10:08:35 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hjbz1-0001HV-B3 for mip6@ietf.org; Thu, 03 May 2007 10:08:35 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1178201314!19102143!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 10932 invoked from network); 3 May 2007 14:08:34 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-6.tower-128.messagelabs.com with SMTP; 3 May 2007 14:08:34 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l43E8YK0018835; Thu, 3 May 2007 07:08:34 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l43E8WBd027107; Thu, 3 May 2007 09:08:32 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l43E8TiE027029; Thu, 3 May 2007 09:08:30 -0500 (CDT) Message-ID: <4639ECD8.6040904@gmail.com> Date: Thu, 03 May 2007 16:08:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [Mip6] GRE key References: <462E3398.7000100@gmail.com> <7CCD07160348804497EF29E9EA5560D7024D9F5F@exchtewks2.starentnetworks.com> <02C627D961164445AFBC01BBDD0EC3244DDFD9@DEEXC1U01.de.lucent.com> <4639AB33.6070703@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA32E@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437113FBA32E@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000737-2, 30/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: mip6@ietf.org, Alexandru Petrescu , "Casati, Alessio \(Alessio\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ahmad Muhanna wrote: > Hi Alex, Please see comment inline. > >> Casati, Alessio (Alessio) wrote: >>> Kuntal's view is correct from here too. >> Where are the NATs? I don't see them. > > That is the key Alex, there is no NAT in the PMIP domain for this > case. I believe the figure in the draft is quite straight forward. If there's no NAT then how did people end up designing their address architecture so badly that address spaces overlap? Alex > If you need further discussion on this we can do it offline, if you > prefer. > >> Alex >> >>> Alessio >>> >>> *-----Original Message----- *From: Chowdhury, Kuntal >>> [mailto:kchowdhury@starentnetworks.com] *Sent: 02 May 2007 17:30 >>> *To: Alexandru Petrescu; Mohamed Khalil *Cc: mip6@ietf.org >>> *Subject: RE: [Mip6] GRE key * *> I think all other forms of >>> IPv6-in-IPv4 (and in UDPv4) >> are *capable >>> to *> deal with the problem of overlapping private IPv4 >> addressing you >>> cite *in *> the draft. Don't you think so? * *Alex, * *If the >>> LMA (or the HA) has overlapping IPv4 address pools, >> how *does >>> it distinguish the incoming (tunneled) packets? Note that >> *the LMA/HA >>> needs to make this distinction for making next hop *decision. For >>> private IPv4 addresses, that means identifying *the VLAN >> tag or tunnel >>> id or the network interface on the *egress side of the LMA/HA. * >>> *AFAIK, GRE keys are used for this purpose. * *-Kuntal * * * *> >>> -----Original Message----- *> From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] *> Sent: Tuesday, April 24, >>> 2007 11:43 AM *> To: Mohamed >> Khalil *> Cc: >>> mip6@ietf.org *> Subject: Re: [Mip6] GRE key *> *> Mohamed Khalil >>> wrote: *> > Hi Alexandru, *> > *> > -----Original Message----- >>> From: Alexandru Petrescu *> > >>> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April >> 24, 2007 *> >>>> 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: >>> *mip6@ietf.org Subject: *> > Re: [Mip6] GRE key *> > *> > *> > >>> Mohamed Khalil wrote: *> >> Hi All, *> >> *> >> The following >>> draft has been posted on netlmm, your >> comments and >>> *> >> feedback is much appreciated. *> >> *> >> The Proxy Mobile >>> IPv6 base specification defined in >> [PMIP6-ID] >>> *> >> allows *> > *> >> the mobile node's IPv4 and IPv6 traffic >>> between the local *mobility *> >> anchor and the mobile >> access gateway >>> to be tunneled using IPv6, *> >> IPv4 or IPv4-UDP encapsulation >>> headers. These *encapsulation modes *> >> do not offer >> semantics for >>> the tunnel end-points to expose a *> >> service identifier >> that can be >>> used to identify traffic for a *> >> certain >> classification, such as >>> for supporting mobile nodes that *> >> are using >> overlapping private >>> IPv4 addressing. The extensions *> >> defined in this >> document allow >>> the mobile access gateway and the *> >> local mobility >> anchor *> > *> >>>>> to negotiate GRE encapsulation mode and along with the GRE *> >>>>> >> >>> symmetric key or asymmetric keys for marking the flows, so >> that *> >> >>> differential processing can be applied by the tunnel peers >> over *> >> >>> those flows. *> > *> > Several reasons I believe GRE is not >>> necessary for PMIPv6. *> > *> > Does GRE work transporting IPv6? >>> I thought it only >> *transports >>> IPv4. *> > PMIPv6 assumes IPv6 applications first, in my >>> understanding. *> > *> > Mohamed>> should be use to transport IP6 >>> too. *> *> It's true that the RFC I'm referring to is relatively >>> old, *is there an *> update on the GRE implementation as to show >>> it can transport IPv6? *> rfc2784 says: *> > o IPv6 as Delivery >>> and/or Payload Protocol *> > *> > This specification describes >>> the intersection of GRE currently *> > deployed by multiple >>> vendors. IPv6 as delivery and/or payload *> > protocol is not >>> included in the currently deployed versions of GRE. *> *> Is >>> there an update to this RFC or to this statement in this RFC? >>> *Thanks. *> *> >> PMIPv6 inherits from MIPv6 tunnelling, which is >>> *IPv6-in-IPv6 which *> >> is Generic Packet Tunnelling rfc2473 >>> (not GRE); and >> it maybe *> >>>>> inherits from DS-MIPv6 whose method of transporting IPv6 >> *over IPv4 >>> *> >> is not yet clarified, but was discussed until now to >> be IPv6 in >>> *> >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol >>> *number 41 *> >> rfc2893 (yet again not GRE). *> >> *> >> I think >>> it is also obvious that PMIPv6 done in netlmm >> WG should >>> *> >> encapsulate only once at max, not twice nor more. Ie >> a *packet >>> from *> >> LMA to MAG should only be encapsulated once (IPv6 in >>> UDP/IPv4 or *> >> maybe IPv6 in IPv6, but not in a double >>> encapsulation like *> >> IPv6-in-IPv4-in-GRE). *> > *> > >>> Mohamed>> I don't see the issue of double encapsulation, >>> *IP4-UDP-IP6 *> > is double encapsulation (DS-MIP6). IPv4 header >>> >> (src=V4ADDR, *> > >>> dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, >> dst=HAADDR) *DST-OPT >>> *> > HAO (IPv6 home address) Mobility header BU [IPv4 HAO] *> *> >>> That's simple encapsulation I believe, it's IPv6 packets in >> UDPv4 *> >>> packets. One may interpret that as double encapsulation. *> *> >>> What I mean is that if the PMIP approach relies on some >> *deployed >>> code *> that doesn't assume GRE then where would GRE necessity >>> come from? *Could *> you answer this? *> *> >> So in this >>> context, can I ask why GRE? It's not used >> by *MIPv6, >>> was *> >> never suggested by DS-MIPv6, can't transport IPv6 and >>> has several *> >> implemented alternatives. Why GRE? *> > *> > >>> mohamed>> GRE is used in this draft to mark/identify >> traffic for >>> a *> > certain classification, such as for supporting mobile >>> *nodes that are *> > using overlapping private IPv4 addressing. >>> *> *> Yes, I read that in the abstract. But I don't see any NAT >>> *throughout *> the document. *> *> I think all other forms of >>> IPv6-in-IPv4 (and in UDPv4) >> are *capable >>> to *> deal with the problem of overlapping private IPv4 >> addressing you >>> cite *in *> the draft. Don't you think so? *> *> Please don't >>> get me wrong. I think many forms of >> tunnelling are *> >>> possible and that some decisions have already been made, >> and *that GRE >>> *> tunnelling is straight competitor to the ones I've listed. *A >>> dynamic *> method to choose between the available methods is >> probably useful. >>> *But *> I don't see why pushing solely GRE; again, where is GRE >> coming from >>> *into *> the PMIP picture? *> *> Alex *> *> *> >>> >> *_____________________________________________________________________ >> >>> _ *> This email has been scanned by the MessageLabs Email >>> Security System. *> For more information please visit >> http://www.messagelabs.com/email >>> *> >>> >> *_____________________________________________________________________ >> >>> _ *> *> _______________________________________________ *> 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 >>> * >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> _______________________________________________ Mip6 mailing list >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 03 10:14:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjc50-0003le-Kz; Thu, 03 May 2007 10:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjc4z-0003lW-VN for mip6@ietf.org; Thu, 03 May 2007 10:14:45 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjc4y-0002c1-GO for mip6@ietf.org; Thu, 03 May 2007 10:14:45 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l43EEfG01382; Thu, 3 May 2007 14:14:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] GRE key Date: Thu, 3 May 2007 09:14:36 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437113FBA432@zrc2hxm2.corp.nortel.com> In-Reply-To: <4639ECD8.6040904@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] GRE key Thread-Index: AceNjI62QwQc1kI+RbuyDAxw1Stl+AAAFSSw References: <462E3398.7000100@gmail.com> <7CCD07160348804497EF29E9EA5560D7024D9F5F@exchtewks2.starentnetworks.com> <02C627D961164445AFBC01BBDD0EC3244DDFD9@DEEXC1U01.de.lucent.com> <4639AB33.6070703@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA32E@zrc2hxm2.corp.nortel.com> <4639ECD8.6040904@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: mip6@ietf.org, "Casati, Alessio \(Alessio\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, We are talking about the home address here for different VPNs, for example, that the HA supports and it is possible for two MNs from two different VPNs roam at the same time in the area of a single MAG with the same home private IP address. I hope this would help. Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Thursday, May 03, 2007 9:08 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Alexandru Petrescu; Casati, Alessio (Alessio);=20 > mip6@ietf.org; Khalil, Mohamed (RICH2:2S20) > Subject: Re: [Mip6] GRE key >=20 > Ahmad Muhanna wrote: > > Hi Alex, Please see comment inline. > >=20 > >> Casati, Alessio (Alessio) wrote: > >>> Kuntal's view is correct from here too. > >> Where are the NATs? I don't see them. > >=20 > > That is the key Alex, there is no NAT in the PMIP domain for this=20 > > case. I believe the figure in the draft is quite straight forward. >=20 > If there's no NAT then how did people end up designing their=20 > address architecture so badly that address spaces overlap? >=20 > Alex >=20 > > If you need further discussion on this we can do it offline, if you=20 > > prefer. > >=20 > >> Alex > >>=20 > >>> Alessio > >>>=20 > >>> *-----Original Message----- *From: Chowdhury, Kuntal=20 > >>> [mailto:kchowdhury@starentnetworks.com] *Sent: 02 May 2007 17:30 > >>> *To: Alexandru Petrescu; Mohamed Khalil *Cc: mip6@ietf.org > >>> *Subject: RE: [Mip6] GRE key * *> I think all other forms of > >>> IPv6-in-IPv4 (and in UDPv4) > >> are *capable > >>> to *> deal with the problem of overlapping private IPv4 > >> addressing you > >>> cite *in *> the draft. Don't you think so? * *Alex, *=20 > *If the LMA=20 > >>> (or the HA) has overlapping IPv4 address pools, > >> how *does > >>> it distinguish the incoming (tunneled) packets? Note that > >> *the LMA/HA > >>> needs to make this distinction for making next hop=20 > *decision. For =20 > >>> private IPv4 addresses, that means identifying *the VLAN > >> tag or tunnel > >>> id or the network interface on the *egress side of the LMA/HA. *=20 > >>> *AFAIK, GRE keys are used for this purpose. * *-Kuntal * * * *>=20 > >>> -----Original Message----- *> From: Alexandru Petrescu=20 > >>> [mailto:alexandru.petrescu@gmail.com] *> Sent: Tuesday, April 24, > >>> 2007 11:43 AM *> To: Mohamed > >> Khalil *> Cc: > >>> mip6@ietf.org *> Subject: Re: [Mip6] GRE key *> *> Mohamed Khalil > >>> wrote: *> > Hi Alexandru, *> > *> > -----Original Message----- > >>> From: Alexandru Petrescu *> > > >>> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April > >> 24, 2007 *> > >>>> 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: > >>> *mip6@ietf.org Subject: *> > Re: [Mip6] GRE key *> > *> > *> >=20 > >>> Mohamed Khalil wrote: *> >> Hi All, *> >> *> >> The=20 > following draft=20 > >>> has been posted on netlmm, your > >> comments and > >>> *> >> feedback is much appreciated. *> >> *> >> The Proxy Mobile > >>> IPv6 base specification defined in > >> [PMIP6-ID] > >>> *> >> allows *> > *> >> the mobile node's IPv4 and IPv6 traffic=20 > >>> between the local *mobility *> >> anchor and the mobile > >> access gateway > >>> to be tunneled using IPv6, *> >> IPv4 or IPv4-UDP encapsulation=20 > >>> headers. These *encapsulation modes *> >> do not offer > >> semantics for > >>> the tunnel end-points to expose a *> >> service identifier > >> that can be > >>> used to identify traffic for a *> >> certain > >> classification, such as > >>> for supporting mobile nodes that *> >> are using > >> overlapping private > >>> IPv4 addressing. The extensions *> >> defined in this > >> document allow > >>> the mobile access gateway and the *> >> local mobility > >> anchor *> > *> > >>>>> to negotiate GRE encapsulation mode and along with the GRE *> > >>>>> >> > >>> symmetric key or asymmetric keys for marking the flows, so > >> that *> >> > >>> differential processing can be applied by the tunnel peers > >> over *> >> > >>> those flows. *> > *> > Several reasons I believe GRE is not=20 > >>> necessary for PMIPv6. *> > *> > Does GRE work transporting IPv6? > >>> I thought it only > >> *transports > >>> IPv4. *> > PMIPv6 assumes IPv6 applications first, in my=20 > >>> understanding. *> > *> > Mohamed>> should be use to transport IP6=20 > >>> too. *> *> It's true that the RFC I'm referring to is relatively=20 > >>> old, *is there an *> update on the GRE implementation as=20 > to show it=20 > >>> can transport IPv6? *> rfc2784 says: *> > o IPv6 as=20 > Delivery and/or=20 > >>> Payload Protocol *> > *> > This specification describes the=20 > >>> intersection of GRE currently *> > deployed by multiple vendors.=20 > >>> IPv6 as delivery and/or payload *> > protocol is not=20 > included in the=20 > >>> currently deployed versions of GRE. *> *> Is there an=20 > update to this=20 > >>> RFC or to this statement in this RFC? > >>> *Thanks. *> *> >> PMIPv6 inherits from MIPv6 tunnelling, which is > >>> *IPv6-in-IPv6 which *> >> is Generic Packet Tunnelling=20 > rfc2473 (not=20 > >>> GRE); and > >> it maybe *> > >>>>> inherits from DS-MIPv6 whose method of transporting IPv6 > >> *over IPv4 > >>> *> >> is not yet clarified, but was discussed until now to > >> be IPv6 in > >>> *> >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol=20 > >>> *number 41 *> >> rfc2893 (yet again not GRE). *> >> *> >>=20 > I think it=20 > >>> is also obvious that PMIPv6 done in netlmm > >> WG should > >>> *> >> encapsulate only once at max, not twice nor more. Ie > >> a *packet > >>> from *> >> LMA to MAG should only be encapsulated once (IPv6 in > >>> UDP/IPv4 or *> >> maybe IPv6 in IPv6, but not in a double=20 > >>> encapsulation like *> >> IPv6-in-IPv4-in-GRE). *> > *> > > >>> Mohamed>> I don't see the issue of double encapsulation, > >>> *IP4-UDP-IP6 *> > is double encapsulation (DS-MIP6). IPv4 header > >>>=20 > >> (src=3DV4ADDR, *> > > >>> dst=3DHA_V4ADDR) UDP header IPv6 header (src=3DV4CoA, > >> dst=3DHAADDR) *DST-OPT > >>> *> > HAO (IPv6 home address) Mobility header BU [IPv4=20 > HAO] *> *> =20 > >>> That's simple encapsulation I believe, it's IPv6 packets in > >> UDPv4 *> > >>> packets. One may interpret that as double encapsulation.=20 > *> *> What=20 > >>> I mean is that if the PMIP approach relies on some > >> *deployed > >>> code *> that doesn't assume GRE then where would GRE=20 > necessity come=20 > >>> from? *Could *> you answer this? *> *> >> So in this=20 > context, can I=20 > >>> ask why GRE? It's not used > >> by *MIPv6, > >>> was *> >> never suggested by DS-MIPv6, can't transport=20 > IPv6 and has=20 > >>> several *> >> implemented alternatives. Why GRE? *> > *> > > >>> mohamed>> GRE is used in this draft to mark/identify > >> traffic for > >>> a *> > certain classification, such as for supporting=20 > mobile *nodes=20 > >>> that are *> > using overlapping private IPv4 addressing. > >>> *> *> Yes, I read that in the abstract. But I don't see any NAT =20 > >>> *throughout *> the document. *> *> I think all other forms of > >>> IPv6-in-IPv4 (and in UDPv4) > >> are *capable > >>> to *> deal with the problem of overlapping private IPv4 > >> addressing you > >>> cite *in *> the draft. Don't you think so? *> *> Please=20 > don't get=20 > >>> me wrong. I think many forms of > >> tunnelling are *> > >>> possible and that some decisions have already been made, > >> and *that GRE > >>> *> tunnelling is straight competitor to the ones I've listed. *A=20 > >>> dynamic *> method to choose between the available methods is > >> probably useful. > >>> *But *> I don't see why pushing solely GRE; again, where is GRE > >> coming from > >>> *into *> the PMIP picture? *> *> Alex *> *> *> > >>>=20 > >>=20 > *____________________________________________________________________ > >> _ > >>=20 > >>> _ *> This email has been scanned by the MessageLabs Email=20 > Security=20 > >>> System. *> For more information please visit > >> http://www.messagelabs.com/email > >>> *> > >>>=20 > >>=20 > *____________________________________________________________________ > >> _ > >>=20 > >>> _ *> *> _______________________________________________ *> Mip6=20 > >>> mailing list *> Mip6@ietf.org *> > >>> https://www1.ietf.org/mailman/listinfo/mip6 *=20 > >>> *_______________________________________________ *Mip6=20 > mailing list=20 > >>> *Mip6@ietf.org *https://www1.ietf.org/mailman/listinfo/mip6 > >>> * > >>>=20 > >>=20 > >>=20 > _____________________________________________________________________ > >> _ This email has been scanned by the MessageLabs Email Security=20 > >> System. For more information please visit=20 > >> http://www.messagelabs.com/email=20 > >>=20 > _____________________________________________________________________ > >> _ > >>=20 > >>=20 > >> _______________________________________________ Mip6 mailing list=20 > >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 03 10:37:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjcQy-0001sU-Bs; Thu, 03 May 2007 10:37:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjcQx-0001qQ-0x for mip6@ietf.org; Thu, 03 May 2007 10:37:27 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjcQw-0000Bs-C3 for mip6@ietf.org; Thu, 03 May 2007 10:37:27 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1178203045!10984774!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 23384 invoked from network); 3 May 2007 14:37:25 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-10.tower-128.messagelabs.com with SMTP; 3 May 2007 14:37:25 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l43EbPXf001601; Thu, 3 May 2007 07:37:25 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l43EbOe9020184; Thu, 3 May 2007 09:37:24 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l43EbL5h020118; Thu, 3 May 2007 09:37:22 -0500 (CDT) Message-ID: <4639F3A1.1030005@gmail.com> Date: Thu, 03 May 2007 16:37:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [Mip6] GRE key References: <462E3398.7000100@gmail.com> <7CCD07160348804497EF29E9EA5560D7024D9F5F@exchtewks2.starentnetworks.com> <02C627D961164445AFBC01BBDD0EC3244DDFD9@DEEXC1U01.de.lucent.com> <4639AB33.6070703@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA32E@zrc2hxm2.corp.nortel.com> <4639ECD8.6040904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA432@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437113FBA432@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000737-2, 30/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: mip6@ietf.org, Alexandru Petrescu , "Casati, Alessio \(Alessio\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ahmad Muhanna wrote: > Hi Alex, > > We are talking about the home address here for different VPNs, for > example, that the HA supports and it is possible for two MNs from two > different VPNs roam at the same time in the area of a single MAG with > the same home private IP address. > > I hope this would help. It helps clarifying some parts, in that it may so happen that two MNs have the same private IPv4 Home Address. I will not go as far as saying that I find this problem little worth exploring. [HEre's why: Private IPv4 Home Addresses aren't reachable from the Internet, hence no need to give them continuous access with Mobile IP. MIPv6 doesn't deal with IPv4 Home Addresses. DS-MIPv6 doesn't deal with HA behind NAT, hence doesn't deal with private IPv4 Home Addresses.] Maybe, in this order: -it is thought that GRE is needed for some SDO. Then it should be stated first and foremost. -it is thought that GRE has something to do with PMIPv6 (not with MIPv6). Then the use of GRE tunnel instead of IPv6-in-IPv6 tunnel should be proposed to PMIPv6. -it is thought that private IPv4 Addresses have something to do with DS-MIPv6. Then the use of one IPv4 private home address should be suggested to DS-MIPv6. -it is thought that overlapping IPv4 Home Addresses are a problem with mobility. Then it should be proposed _after_ the above two steps were solved. Thanks, Alex > > Regards, > Ahmad > > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Thursday, May 03, 2007 9:08 AM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: Alexandru Petrescu; Casati, Alessio (Alessio); >> mip6@ietf.org; Khalil, Mohamed (RICH2:2S20) >> Subject: Re: [Mip6] GRE key >> >> Ahmad Muhanna wrote: >>> Hi Alex, Please see comment inline. >>> >>>> Casati, Alessio (Alessio) wrote: >>>>> Kuntal's view is correct from here too. >>>> Where are the NATs? I don't see them. >>> That is the key Alex, there is no NAT in the PMIP domain for this >>> case. I believe the figure in the draft is quite straight forward. >> If there's no NAT then how did people end up designing their >> address architecture so badly that address spaces overlap? >> >> Alex >> >>> If you need further discussion on this we can do it offline, if you >>> prefer. >>> >>>> Alex >>>> >>>>> Alessio >>>>> >>>>> *-----Original Message----- *From: Chowdhury, Kuntal >>>>> [mailto:kchowdhury@starentnetworks.com] *Sent: 02 May 2007 17:30 >>>>> *To: Alexandru Petrescu; Mohamed Khalil *Cc: mip6@ietf.org >>>>> *Subject: RE: [Mip6] GRE key * *> I think all other forms of >>>>> IPv6-in-IPv4 (and in UDPv4) >>>> are *capable >>>>> to *> deal with the problem of overlapping private IPv4 >>>> addressing you >>>>> cite *in *> the draft. Don't you think so? * *Alex, * >> *If the LMA >>>>> (or the HA) has overlapping IPv4 address pools, >>>> how *does >>>>> it distinguish the incoming (tunneled) packets? Note that >>>> *the LMA/HA >>>>> needs to make this distinction for making next hop >> *decision. For >>>>> private IPv4 addresses, that means identifying *the VLAN >>>> tag or tunnel >>>>> id or the network interface on the *egress side of the LMA/HA. * >>>>> *AFAIK, GRE keys are used for this purpose. * *-Kuntal * * * *> >>>>> -----Original Message----- *> From: Alexandru Petrescu >>>>> [mailto:alexandru.petrescu@gmail.com] *> Sent: Tuesday, April 24, >>>>> 2007 11:43 AM *> To: Mohamed >>>> Khalil *> Cc: >>>>> mip6@ietf.org *> Subject: Re: [Mip6] GRE key *> *> Mohamed Khalil >>>>> wrote: *> > Hi Alexandru, *> > *> > -----Original Message----- >>>>> From: Alexandru Petrescu *> > >>>>> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April >>>> 24, 2007 *> >>>>>> 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: >>>>> *mip6@ietf.org Subject: *> > Re: [Mip6] GRE key *> > *> > *> > >>>>> Mohamed Khalil wrote: *> >> Hi All, *> >> *> >> The >> following draft >>>>> has been posted on netlmm, your >>>> comments and >>>>> *> >> feedback is much appreciated. *> >> *> >> The Proxy Mobile >>>>> IPv6 base specification defined in >>>> [PMIP6-ID] >>>>> *> >> allows *> > *> >> the mobile node's IPv4 and IPv6 traffic >>>>> between the local *mobility *> >> anchor and the mobile >>>> access gateway >>>>> to be tunneled using IPv6, *> >> IPv4 or IPv4-UDP encapsulation >>>>> headers. These *encapsulation modes *> >> do not offer >>>> semantics for >>>>> the tunnel end-points to expose a *> >> service identifier >>>> that can be >>>>> used to identify traffic for a *> >> certain >>>> classification, such as >>>>> for supporting mobile nodes that *> >> are using >>>> overlapping private >>>>> IPv4 addressing. The extensions *> >> defined in this >>>> document allow >>>>> the mobile access gateway and the *> >> local mobility >>>> anchor *> > *> >>>>>>> to negotiate GRE encapsulation mode and along with the GRE *> >>>>> symmetric key or asymmetric keys for marking the flows, so >>>> that *> >> >>>>> differential processing can be applied by the tunnel peers >>>> over *> >> >>>>> those flows. *> > *> > Several reasons I believe GRE is not >>>>> necessary for PMIPv6. *> > *> > Does GRE work transporting IPv6? >>>>> I thought it only >>>> *transports >>>>> IPv4. *> > PMIPv6 assumes IPv6 applications first, in my >>>>> understanding. *> > *> > Mohamed>> should be use to transport IP6 >>>>> too. *> *> It's true that the RFC I'm referring to is relatively >>>>> old, *is there an *> update on the GRE implementation as >> to show it >>>>> can transport IPv6? *> rfc2784 says: *> > o IPv6 as >> Delivery and/or >>>>> Payload Protocol *> > *> > This specification describes the >>>>> intersection of GRE currently *> > deployed by multiple vendors. >>>>> IPv6 as delivery and/or payload *> > protocol is not >> included in the >>>>> currently deployed versions of GRE. *> *> Is there an >> update to this >>>>> RFC or to this statement in this RFC? >>>>> *Thanks. *> *> >> PMIPv6 inherits from MIPv6 tunnelling, which is >>>>> *IPv6-in-IPv6 which *> >> is Generic Packet Tunnelling >> rfc2473 (not >>>>> GRE); and >>>> it maybe *> >>>>>>> inherits from DS-MIPv6 whose method of transporting IPv6 >>>> *over IPv4 >>>>> *> >> is not yet clarified, but was discussed until now to >>>> be IPv6 in >>>>> *> >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol >>>>> *number 41 *> >> rfc2893 (yet again not GRE). *> >> *> >> >> I think it >>>>> is also obvious that PMIPv6 done in netlmm >>>> WG should >>>>> *> >> encapsulate only once at max, not twice nor more. Ie >>>> a *packet >>>>> from *> >> LMA to MAG should only be encapsulated once (IPv6 in >>>>> UDP/IPv4 or *> >> maybe IPv6 in IPv6, but not in a double >>>>> encapsulation like *> >> IPv6-in-IPv4-in-GRE). *> > *> > >>>>> Mohamed>> I don't see the issue of double encapsulation, >>>>> *IP4-UDP-IP6 *> > is double encapsulation (DS-MIP6). IPv4 header >>>>> >>>> (src=V4ADDR, *> > >>>>> dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, >>>> dst=HAADDR) *DST-OPT >>>>> *> > HAO (IPv6 home address) Mobility header BU [IPv4 >> HAO] *> *> >>>>> That's simple encapsulation I believe, it's IPv6 packets in >>>> UDPv4 *> >>>>> packets. One may interpret that as double encapsulation. >> *> *> What >>>>> I mean is that if the PMIP approach relies on some >>>> *deployed >>>>> code *> that doesn't assume GRE then where would GRE >> necessity come >>>>> from? *Could *> you answer this? *> *> >> So in this >> context, can I >>>>> ask why GRE? It's not used >>>> by *MIPv6, >>>>> was *> >> never suggested by DS-MIPv6, can't transport >> IPv6 and has >>>>> several *> >> implemented alternatives. Why GRE? *> > *> > >>>>> mohamed>> GRE is used in this draft to mark/identify >>>> traffic for >>>>> a *> > certain classification, such as for supporting >> mobile *nodes >>>>> that are *> > using overlapping private IPv4 addressing. >>>>> *> *> Yes, I read that in the abstract. But I don't see any NAT >>>>> *throughout *> the document. *> *> I think all other forms of >>>>> IPv6-in-IPv4 (and in UDPv4) >>>> are *capable >>>>> to *> deal with the problem of overlapping private IPv4 >>>> addressing you >>>>> cite *in *> the draft. Don't you think so? *> *> Please >> don't get >>>>> me wrong. I think many forms of >>>> tunnelling are *> >>>>> possible and that some decisions have already been made, >>>> and *that GRE >>>>> *> tunnelling is straight competitor to the ones I've listed. *A >>>>> dynamic *> method to choose between the available methods is >>>> probably useful. >>>>> *But *> I don't see why pushing solely GRE; again, where is GRE >>>> coming from >>>>> *into *> the PMIP picture? *> *> Alex *> *> *> >>>>> >> *____________________________________________________________________ >>>> _ >>>> >>>>> _ *> This email has been scanned by the MessageLabs Email >> Security >>>>> System. *> For more information please visit >>>> http://www.messagelabs.com/email >>>>> *> >>>>> >> *____________________________________________________________________ >>>> _ >>>> >>>>> _ *> *> _______________________________________________ *> 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 >>>>> * >>>>> >>>> >> _____________________________________________________________________ >>>> _ This email has been scanned by the MessageLabs Email Security >>>> System. For more information please visit >>>> http://www.messagelabs.com/email >>>> >> _____________________________________________________________________ >>>> _ >>>> >>>> >>>> _______________________________________________ Mip6 mailing list >>>> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >>>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 03 11:10:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjcxD-00076u-Qc; Thu, 03 May 2007 11:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjcxC-00076p-IA for mip6@ietf.org; Thu, 03 May 2007 11:10:46 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjcx9-0000hC-68 for mip6@ietf.org; Thu, 03 May 2007 11:10:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 79BAB90017 for ; Thu, 3 May 2007 11:10:39 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12942-19 for ; Thu, 3 May 2007 11:10:35 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 3 May 2007 11:10:35 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 11:10:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] GRE key Date: Thu, 3 May 2007 11:10:35 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9F68@exchtewks2.starentnetworks.com> In-Reply-To: <46390BDB.7020200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] GRE key Thread-Index: AceNBnOtmNZ/hc8hSriwf/pbPAzH7wAjZtBg From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" X-OriginalArrivalTime: 03 May 2007 15:10:35.0649 (UTC) FILETIME=[3377EF10:01C78D95] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Wednesday, May 02, 2007 5:08 PM > To: Chowdhury, Kuntal > Cc: Alexandru Petrescu; Mohamed Khalil; mip6@ietf.org > Subject: Re: [Mip6] GRE key >=20 > Chowdhury, Kuntal wrote: > >> I think all other forms of IPv6-in-IPv4 (and in UDPv4) are capable > >> to deal with the problem of overlapping private IPv4 addressing > >> you cite > > in > >> the draft. Don't you think so? > > > > Alex, > > > > If the LMA (or the HA) has overlapping IPv4 address pools, how does > > it distinguish the incoming (tunneled) packets? >=20 > By means of mappings between addresses in the outer and inner headers. > In no case by means of a new identifier (key) used as an address. >=20 [KC>] That is the problem. In case of overlapping IP4 HoA pools, two users on the same MAG may get same IPv4 HoA, the inner and outer headers will have identical information for two separate users. > > Note that the LMA/HA needs to make this distinction for making next > > hop decision. For private IPv4 addresses, that means identifying the > > VLAN tag or tunnel id or the network interface on the egress side of > > the LMA/HA. >=20 > Look, we don't even have a clear idea where _one_ NAT is placed in this > PMIPv6/v4 picture (the draft doesn't place _any_ NAT) and we speculate > about two overlapping private spaces. >=20 > Where are the two NATs placed? >=20 [KC>] Let's assume that tunnels for both the users (with same IPv4 HoA) pass thorough the same NAT (if there is a NAT). The real issue is, how to distinguish the tunnels at the LMA/HA. The NAT in the middle of the MAG/MN and the LMA/HA does not matter since UDP transport addresses the NAT traversal problem. =20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 03 11:19:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjd5U-0005Gf-Tz; Thu, 03 May 2007 11:19:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjd5T-0005EU-4z for mip6@ietf.org; Thu, 03 May 2007 11:19:19 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjd4a-00031o-0z for mip6@ietf.org; Thu, 03 May 2007 11:18:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id CC98690021 for ; Thu, 3 May 2007 11:18:20 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13228-06 for ; Thu, 3 May 2007 11:18:16 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 3 May 2007 11:18:16 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 11:18:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] GRE key Date: Thu, 3 May 2007 11:18:15 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9F6A@exchtewks2.starentnetworks.com> In-Reply-To: <4639ECD8.6040904@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] GRE key Thread-Index: AceNjJZvmF/H4FpwQEGVngoIrekSAgACQJ7A From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" , "Ahmad Muhanna" X-OriginalArrivalTime: 03 May 2007 15:18:16.0423 (UTC) FILETIME=[461C7770:01C78D96] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: mip6@ietf.org, "Casati, Alessio \(Alessio\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, May 03, 2007 9:08 AM > To: Ahmad Muhanna > Cc: mip6@ietf.org; Alexandru Petrescu; Casati, Alessio (Alessio) > Subject: Re: [Mip6] GRE key >=20 > Ahmad Muhanna wrote: > > Hi Alex, Please see comment inline. > > > >> Casati, Alessio (Alessio) wrote: > >>> Kuntal's view is correct from here too. > >> Where are the NATs? I don't see them. > > > > That is the key Alex, there is no NAT in the PMIP domain for this > > case. I believe the figure in the draft is quite straight forward. >=20 > If there's no NAT then how did people end up designing their address > architecture so badly that address spaces overlap? >=20 [KC>] There are pools of addresses in the HA/LMA for each domain it supports. Some of these domains may be enterprises using private address space. So, it is often the case that pools of addresses for two domains on the same HA/LMA are private and overlapping. So, there is a valid use case for GRE keys to be used to distinguish user traffic for these domains in the LMA/HA. The placement of NAT is irrelevant in this case. If there is a NAT in between MAG/MN and LMA/HA, UDP transport takes care of the traversal. > Alex >=20 > > If you need further discussion on this we can do it offline, if you > > prefer. > > > >> Alex > >> > >>> Alessio > >>> > >>> *-----Original Message----- *From: Chowdhury, Kuntal > >>> [mailto:kchowdhury@starentnetworks.com] *Sent: 02 May 2007 17:30 > >>> *To: Alexandru Petrescu; Mohamed Khalil *Cc: mip6@ietf.org > >>> *Subject: RE: [Mip6] GRE key * *> I think all other forms of > >>> IPv6-in-IPv4 (and in UDPv4) > >> are *capable > >>> to *> deal with the problem of overlapping private IPv4 > >> addressing you > >>> cite *in *> the draft. Don't you think so? * *Alex, * *If the > >>> LMA (or the HA) has overlapping IPv4 address pools, > >> how *does > >>> it distinguish the incoming (tunneled) packets? Note that > >> *the LMA/HA > >>> needs to make this distinction for making next hop *decision. For > >>> private IPv4 addresses, that means identifying *the VLAN > >> tag or tunnel > >>> id or the network interface on the *egress side of the LMA/HA. * > >>> *AFAIK, GRE keys are used for this purpose. * *-Kuntal * * * *> > >>> -----Original Message----- *> From: Alexandru Petrescu > >>> [mailto:alexandru.petrescu@gmail.com] *> Sent: Tuesday, April 24, > >>> 2007 11:43 AM *> To: Mohamed > >> Khalil *> Cc: > >>> mip6@ietf.org *> Subject: Re: [Mip6] GRE key *> *> Mohamed Khalil > >>> wrote: *> > Hi Alexandru, *> > *> > -----Original Message----- > >>> From: Alexandru Petrescu *> > > >>> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April > >> 24, 2007 *> > >>>> 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: > >>> *mip6@ietf.org Subject: *> > Re: [Mip6] GRE key *> > *> > *> > > >>> Mohamed Khalil wrote: *> >> Hi All, *> >> *> >> The following > >>> draft has been posted on netlmm, your > >> comments and > >>> *> >> feedback is much appreciated. *> >> *> >> The Proxy Mobile > >>> IPv6 base specification defined in > >> [PMIP6-ID] > >>> *> >> allows *> > *> >> the mobile node's IPv4 and IPv6 traffic > >>> between the local *mobility *> >> anchor and the mobile > >> access gateway > >>> to be tunneled using IPv6, *> >> IPv4 or IPv4-UDP encapsulation > >>> headers. These *encapsulation modes *> >> do not offer > >> semantics for > >>> the tunnel end-points to expose a *> >> service identifier > >> that can be > >>> used to identify traffic for a *> >> certain > >> classification, such as > >>> for supporting mobile nodes that *> >> are using > >> overlapping private > >>> IPv4 addressing. The extensions *> >> defined in this > >> document allow > >>> the mobile access gateway and the *> >> local mobility > >> anchor *> > *> > >>>>> to negotiate GRE encapsulation mode and along with the GRE *> > >>>>> >> > >>> symmetric key or asymmetric keys for marking the flows, so > >> that *> >> > >>> differential processing can be applied by the tunnel peers > >> over *> >> > >>> those flows. *> > *> > Several reasons I believe GRE is not > >>> necessary for PMIPv6. *> > *> > Does GRE work transporting IPv6? > >>> I thought it only > >> *transports > >>> IPv4. *> > PMIPv6 assumes IPv6 applications first, in my > >>> understanding. *> > *> > Mohamed>> should be use to transport IP6 > >>> too. *> *> It's true that the RFC I'm referring to is relatively > >>> old, *is there an *> update on the GRE implementation as to show > >>> it can transport IPv6? *> rfc2784 says: *> > o IPv6 as Delivery > >>> and/or Payload Protocol *> > *> > This specification describes > >>> the intersection of GRE currently *> > deployed by multiple > >>> vendors. IPv6 as delivery and/or payload *> > protocol is not > >>> included in the currently deployed versions of GRE. *> *> Is > >>> there an update to this RFC or to this statement in this RFC? > >>> *Thanks. *> *> >> PMIPv6 inherits from MIPv6 tunnelling, which is > >>> *IPv6-in-IPv6 which *> >> is Generic Packet Tunnelling rfc2473 > >>> (not GRE); and > >> it maybe *> > >>>>> inherits from DS-MIPv6 whose method of transporting IPv6 > >> *over IPv4 > >>> *> >> is not yet clarified, but was discussed until now to > >> be IPv6 in > >>> *> >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol > >>> *number 41 *> >> rfc2893 (yet again not GRE). *> >> *> >> I think > >>> it is also obvious that PMIPv6 done in netlmm > >> WG should > >>> *> >> encapsulate only once at max, not twice nor more. Ie > >> a *packet > >>> from *> >> LMA to MAG should only be encapsulated once (IPv6 in > >>> UDP/IPv4 or *> >> maybe IPv6 in IPv6, but not in a double > >>> encapsulation like *> >> IPv6-in-IPv4-in-GRE). *> > *> > > >>> Mohamed>> I don't see the issue of double encapsulation, > >>> *IP4-UDP-IP6 *> > is double encapsulation (DS-MIP6). IPv4 header > >>> > >> (src=3DV4ADDR, *> > > >>> dst=3DHA_V4ADDR) UDP header IPv6 header (src=3DV4CoA, > >> dst=3DHAADDR) *DST-OPT > >>> *> > HAO (IPv6 home address) Mobility header BU [IPv4 HAO] *> *> > >>> That's simple encapsulation I believe, it's IPv6 packets in > >> UDPv4 *> > >>> packets. One may interpret that as double encapsulation. *> *> > >>> What I mean is that if the PMIP approach relies on some > >> *deployed > >>> code *> that doesn't assume GRE then where would GRE necessity > >>> come from? *Could *> you answer this? *> *> >> So in this > >>> context, can I ask why GRE? It's not used > >> by *MIPv6, > >>> was *> >> never suggested by DS-MIPv6, can't transport IPv6 and > >>> has several *> >> implemented alternatives. Why GRE? *> > *> > > >>> mohamed>> GRE is used in this draft to mark/identify > >> traffic for > >>> a *> > certain classification, such as for supporting mobile > >>> *nodes that are *> > using overlapping private IPv4 addressing. > >>> *> *> Yes, I read that in the abstract. But I don't see any NAT > >>> *throughout *> the document. *> *> I think all other forms of > >>> IPv6-in-IPv4 (and in UDPv4) > >> are *capable > >>> to *> deal with the problem of overlapping private IPv4 > >> addressing you > >>> cite *in *> the draft. Don't you think so? *> *> Please don't > >>> get me wrong. I think many forms of > >> tunnelling are *> > >>> possible and that some decisions have already been made, > >> and *that GRE > >>> *> tunnelling is straight competitor to the ones I've listed. *A > >>> dynamic *> method to choose between the available methods is > >> probably useful. > >>> *But *> I don't see why pushing solely GRE; again, where is GRE > >> coming from > >>> *into *> the PMIP picture? *> *> Alex *> *> *> > >>> > >> *_____________________________________________________________________ > >> > >>> _ *> This email has been scanned by the MessageLabs Email > >>> Security System. *> For more information please visit > >> http://www.messagelabs.com/email > >>> *> > >>> > >> *_____________________________________________________________________ > >> > >>> _ *> *> _______________________________________________ *> 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 > >>> * > >>> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security > >> System. For more information please visit > >> http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> > >> _______________________________________________ Mip6 mailing list > >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > >> > > >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ >=20 > _______________________________________________ > 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 From mip6-bounces@ietf.org Thu May 03 11:34:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjdJj-0004OM-2P; Thu, 03 May 2007 11:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjdJh-0004JA-BY for mip6@ietf.org; Thu, 03 May 2007 11:34:01 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjdJg-0007IX-KI for mip6@ietf.org; Thu, 03 May 2007 11:34:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2DFCF90021 for ; Thu, 3 May 2007 11:33:57 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13190-18 for ; Thu, 3 May 2007 11:33:51 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 3 May 2007 11:33:51 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 11:33:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] GRE key Date: Thu, 3 May 2007 11:33:51 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9F6B@exchtewks2.starentnetworks.com> In-Reply-To: <4639F3A1.1030005@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] GRE key Thread-Index: AceNkJsugc9t9av2TlqUHutrEBTi3wABbFAA From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" , "Ahmad Muhanna" X-OriginalArrivalTime: 03 May 2007 15:33:51.0701 (UTC) FILETIME=[73949050:01C78D98] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: mip6@ietf.org, "Casati, Alessio \(Alessio\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, May 03, 2007 9:37 AM > To: Ahmad Muhanna > Cc: mip6@ietf.org; Alexandru Petrescu; Casati, Alessio (Alessio) > Subject: Re: [Mip6] GRE key >=20 > Ahmad Muhanna wrote: > > Hi Alex, > > > > We are talking about the home address here for different VPNs, for > > example, that the HA supports and it is possible for two MNs from two > > different VPNs roam at the same time in the area of a single MAG with > > the same home private IP address. > > > > I hope this would help. >=20 > It helps clarifying some parts, in that it may so happen that two MNs > have the same private IPv4 Home Address. I will not go as far as saying > that I find this problem little worth exploring. > > [HEre's why: > Private IPv4 Home Addresses aren't reachable from the Internet, hence > no need to give them continuous access with Mobile IP. >=20 [KC>] Nobody is talking about internet routing here. Private IPv4 addressing is widely used in enterprises and campus networks. These networks are often hosted by operators. FYI....scenarios using private IPv4 HoA usefully has VPN links back to the respective enterprise/campus networks. > MIPv6 doesn't deal with IPv4 Home Addresses. >=20 [KC>] DS-MIP6 does. > DS-MIPv6 doesn't deal with HA behind NAT, hence doesn't deal with > private IPv4 Home Addresses.] >=20 [KC>] To support private IPv4 address pools, the HA won't have to be necessarily behind a NAT from MN/MAGs PoV. > Maybe, in this order: >=20 > -it is thought that GRE is needed for some SDO. Then it should be > stated first and foremost. [KC>] I do not think we have to bring SDOs into this discussion.=20 > -it is thought that GRE has something to do with PMIPv6 (not with > MIPv6). Then the use of GRE tunnel instead of IPv6-in-IPv6 tunnel > should be proposed to PMIPv6. [KC>] overlapping IPv4 address pool use case applies to both PMIP6 and DS-MIP6. > -it is thought that private IPv4 Addresses have something to do with > DS-MIPv6. Then the use of one IPv4 private home address should be > suggested to DS-MIPv6. [KC>] Not sure that is necessary.=20 > -it is thought that overlapping IPv4 Home Addresses are a problem with > mobility. Then it should be proposed _after_ the above two steps were > solved. > > Thanks, >=20 > Alex >=20 > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Thursday, May 03, 2007 9:08 AM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: Alexandru Petrescu; Casati, Alessio (Alessio); > >> mip6@ietf.org; Khalil, Mohamed (RICH2:2S20) > >> Subject: Re: [Mip6] GRE key > >> > >> Ahmad Muhanna wrote: > >>> Hi Alex, Please see comment inline. > >>> > >>>> Casati, Alessio (Alessio) wrote: > >>>>> Kuntal's view is correct from here too. > >>>> Where are the NATs? I don't see them. > >>> That is the key Alex, there is no NAT in the PMIP domain for this > >>> case. I believe the figure in the draft is quite straight forward. > >> If there's no NAT then how did people end up designing their > >> address architecture so badly that address spaces overlap? > >> > >> Alex > >> > >>> If you need further discussion on this we can do it offline, if you > >>> prefer. > >>> > >>>> Alex > >>>> > >>>>> Alessio > >>>>> > >>>>> *-----Original Message----- *From: Chowdhury, Kuntal > >>>>> [mailto:kchowdhury@starentnetworks.com] *Sent: 02 May 2007 17:30 > >>>>> *To: Alexandru Petrescu; Mohamed Khalil *Cc: mip6@ietf.org > >>>>> *Subject: RE: [Mip6] GRE key * *> I think all other forms of > >>>>> IPv6-in-IPv4 (and in UDPv4) > >>>> are *capable > >>>>> to *> deal with the problem of overlapping private IPv4 > >>>> addressing you > >>>>> cite *in *> the draft. Don't you think so? * *Alex, * > >> *If the LMA > >>>>> (or the HA) has overlapping IPv4 address pools, > >>>> how *does > >>>>> it distinguish the incoming (tunneled) packets? Note that > >>>> *the LMA/HA > >>>>> needs to make this distinction for making next hop > >> *decision. For > >>>>> private IPv4 addresses, that means identifying *the VLAN > >>>> tag or tunnel > >>>>> id or the network interface on the *egress side of the LMA/HA. * > >>>>> *AFAIK, GRE keys are used for this purpose. * *-Kuntal * * * *> > >>>>> -----Original Message----- *> From: Alexandru Petrescu > >>>>> [mailto:alexandru.petrescu@gmail.com] *> Sent: Tuesday, April 24, > >>>>> 2007 11:43 AM *> To: Mohamed > >>>> Khalil *> Cc: > >>>>> mip6@ietf.org *> Subject: Re: [Mip6] GRE key *> *> Mohamed Khalil > >>>>> wrote: *> > Hi Alexandru, *> > *> > -----Original Message----- > >>>>> From: Alexandru Petrescu *> > > >>>>> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, April > >>>> 24, 2007 *> > >>>>>> 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: > >>>>> *mip6@ietf.org Subject: *> > Re: [Mip6] GRE key *> > *> > *> > > >>>>> Mohamed Khalil wrote: *> >> Hi All, *> >> *> >> The > >> following draft > >>>>> has been posted on netlmm, your > >>>> comments and > >>>>> *> >> feedback is much appreciated. *> >> *> >> The Proxy Mobile > >>>>> IPv6 base specification defined in > >>>> [PMIP6-ID] > >>>>> *> >> allows *> > *> >> the mobile node's IPv4 and IPv6 traffic > >>>>> between the local *mobility *> >> anchor and the mobile > >>>> access gateway > >>>>> to be tunneled using IPv6, *> >> IPv4 or IPv4-UDP encapsulation > >>>>> headers. These *encapsulation modes *> >> do not offer > >>>> semantics for > >>>>> the tunnel end-points to expose a *> >> service identifier > >>>> that can be > >>>>> used to identify traffic for a *> >> certain > >>>> classification, such as > >>>>> for supporting mobile nodes that *> >> are using > >>>> overlapping private > >>>>> IPv4 addressing. The extensions *> >> defined in this > >>>> document allow > >>>>> the mobile access gateway and the *> >> local mobility > >>>> anchor *> > *> > >>>>>>> to negotiate GRE encapsulation mode and along with the GRE *> > >>>>> symmetric key or asymmetric keys for marking the flows, so > >>>> that *> >> > >>>>> differential processing can be applied by the tunnel peers > >>>> over *> >> > >>>>> those flows. *> > *> > Several reasons I believe GRE is not > >>>>> necessary for PMIPv6. *> > *> > Does GRE work transporting IPv6? > >>>>> I thought it only > >>>> *transports > >>>>> IPv4. *> > PMIPv6 assumes IPv6 applications first, in my > >>>>> understanding. *> > *> > Mohamed>> should be use to transport IP6 > >>>>> too. *> *> It's true that the RFC I'm referring to is relatively > >>>>> old, *is there an *> update on the GRE implementation as > >> to show it > >>>>> can transport IPv6? *> rfc2784 says: *> > o IPv6 as > >> Delivery and/or > >>>>> Payload Protocol *> > *> > This specification describes the > >>>>> intersection of GRE currently *> > deployed by multiple vendors. > >>>>> IPv6 as delivery and/or payload *> > protocol is not > >> included in the > >>>>> currently deployed versions of GRE. *> *> Is there an > >> update to this > >>>>> RFC or to this statement in this RFC? > >>>>> *Thanks. *> *> >> PMIPv6 inherits from MIPv6 tunnelling, which is > >>>>> *IPv6-in-IPv6 which *> >> is Generic Packet Tunnelling > >> rfc2473 (not > >>>>> GRE); and > >>>> it maybe *> > >>>>>>> inherits from DS-MIPv6 whose method of transporting IPv6 > >>>> *over IPv4 > >>>>> *> >> is not yet clarified, but was discussed until now to > >>>> be IPv6 in > >>>>> *> >> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol > >>>>> *number 41 *> >> rfc2893 (yet again not GRE). *> >> *> >> > >> I think it > >>>>> is also obvious that PMIPv6 done in netlmm > >>>> WG should > >>>>> *> >> encapsulate only once at max, not twice nor more. Ie > >>>> a *packet > >>>>> from *> >> LMA to MAG should only be encapsulated once (IPv6 in > >>>>> UDP/IPv4 or *> >> maybe IPv6 in IPv6, but not in a double > >>>>> encapsulation like *> >> IPv6-in-IPv4-in-GRE). *> > *> > > >>>>> Mohamed>> I don't see the issue of double encapsulation, > >>>>> *IP4-UDP-IP6 *> > is double encapsulation (DS-MIP6). IPv4 header > >>>>> > >>>> (src=3DV4ADDR, *> > > >>>>> dst=3DHA_V4ADDR) UDP header IPv6 header (src=3DV4CoA, > >>>> dst=3DHAADDR) *DST-OPT > >>>>> *> > HAO (IPv6 home address) Mobility header BU [IPv4 > >> HAO] *> *> > >>>>> That's simple encapsulation I believe, it's IPv6 packets in > >>>> UDPv4 *> > >>>>> packets. One may interpret that as double encapsulation. > >> *> *> What > >>>>> I mean is that if the PMIP approach relies on some > >>>> *deployed > >>>>> code *> that doesn't assume GRE then where would GRE > >> necessity come > >>>>> from? *Could *> you answer this? *> *> >> So in this > >> context, can I > >>>>> ask why GRE? It's not used > >>>> by *MIPv6, > >>>>> was *> >> never suggested by DS-MIPv6, can't transport > >> IPv6 and has > >>>>> several *> >> implemented alternatives. Why GRE? *> > *> > > >>>>> mohamed>> GRE is used in this draft to mark/identify > >>>> traffic for > >>>>> a *> > certain classification, such as for supporting > >> mobile *nodes > >>>>> that are *> > using overlapping private IPv4 addressing. > >>>>> *> *> Yes, I read that in the abstract. But I don't see any NAT > >>>>> *throughout *> the document. *> *> I think all other forms of > >>>>> IPv6-in-IPv4 (and in UDPv4) > >>>> are *capable > >>>>> to *> deal with the problem of overlapping private IPv4 > >>>> addressing you > >>>>> cite *in *> the draft. Don't you think so? *> *> Please > >> don't get > >>>>> me wrong. I think many forms of > >>>> tunnelling are *> > >>>>> possible and that some decisions have already been made, > >>>> and *that GRE > >>>>> *> tunnelling is straight competitor to the ones I've listed. *A > >>>>> dynamic *> method to choose between the available methods is > >>>> probably useful. > >>>>> *But *> I don't see why pushing solely GRE; again, where is GRE > >>>> coming from > >>>>> *into *> the PMIP picture? *> *> Alex *> *> *> > >>>>> > >> *____________________________________________________________________ > >>>> _ > >>>> > >>>>> _ *> This email has been scanned by the MessageLabs Email > >> Security > >>>>> System. *> For more information please visit > >>>> http://www.messagelabs.com/email > >>>>> *> > >>>>> > >> *____________________________________________________________________ > >>>> _ > >>>> > >>>>> _ *> *> _______________________________________________ *> 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 > >>>>> * > >>>>> > >>>> > >> _____________________________________________________________________ > >>>> _ This email has been scanned by the MessageLabs Email Security > >>>> System. For more information please visit > >>>> http://www.messagelabs.com/email > >>>> > >> _____________________________________________________________________ > >>>> _ > >>>> > >>>> > >>>> _______________________________________________ Mip6 mailing list > >>>> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > >>>> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit > >> http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > > >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ >=20 > _______________________________________________ > 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 From mip6-bounces@ietf.org Thu May 03 11:43:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjdT2-0003MB-7F; Thu, 03 May 2007 11:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjdT0-0003Ec-SB for mip6@ietf.org; Thu, 03 May 2007 11:43:38 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjdT0-0001jV-GA for mip6@ietf.org; Thu, 03 May 2007 11:43:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1178207017!8682290!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 24390 invoked from network); 3 May 2007 15:43:37 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-12.tower-153.messagelabs.com with SMTP; 3 May 2007 15:43:37 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l43FhaTx009321; Thu, 3 May 2007 10:43:37 -0500 (CDT) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l43FhaCP024996; Thu, 3 May 2007 10:43:36 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l43FhXAR024875; Thu, 3 May 2007 10:43:34 -0500 (CDT) Message-ID: <463A031F.6030404@gmail.com> Date: Thu, 03 May 2007 17:43:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip6] GRE key References: <7CCD07160348804497EF29E9EA5560D7024D9F68$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9F68$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000737-2, 30/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: mip6@ietf.org, Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Chowdhury, Kuntal wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, May 02, 2007 >> 5:08 PM To: Chowdhury, Kuntal Cc: Alexandru Petrescu; Mohamed >> Khalil; mip6@ietf.org Subject: Re: [Mip6] GRE key >> >> Chowdhury, Kuntal wrote: >>>> I think all other forms of IPv6-in-IPv4 (and in UDPv4) are >>>> capable to deal with the problem of overlapping private IPv4 >>>> addressing you cite >>> in >>>> the draft. Don't you think so? >>> Alex, >>> >>> If the LMA (or the HA) has overlapping IPv4 address pools, how >>> does it distinguish the incoming (tunneled) packets? >> By means of mappings between addresses in the outer and inner >> headers. In no case by means of a new identifier (key) used as an >> address. >> > [KC>] That is the problem. In case of overlapping IP4 HoA pools, two > users on the same MAG may get same IPv4 HoA, the inner and outer > headers will have identical information for two separate users. How have we solved this problem in the non-mobility case? If I have two computers, each having the same IPv4 address from a different Enterprise, and connecting to the same Access Point, and each having a VPN to its home - how can they talk to each other? >>> Note that the LMA/HA needs to make this distinction for making >>> next hop decision. For private IPv4 addresses, that means >>> identifying the VLAN tag or tunnel id or the network interface on >>> the egress side of the LMA/HA. >> Look, we don't even have a clear idea where _one_ NAT is placed in > this >> PMIPv6/v4 picture (the draft doesn't place _any_ NAT) and we >> speculate about two overlapping private spaces. >> >> Where are the two NATs placed? >> > [KC>] Let's assume that tunnels for both the users (with same IPv4 > HoA) pass thorough the same NAT (if there is a NAT). The real issue > is, how to distinguish the tunnels at the LMA/HA. I don't understand this. You seem to assume Mobile IP is already used to give continuous access and reachability to one IPv4 private Home Address. > The NAT in the middle of the MAG/MN and the LMA/HA does not matter > since UDP transport addresses the NAT traversal problem. But not reachability. I'm afraid that until we have a more precise idea about where are the NATs placed and what are the boundaries between different domains (and the Internet) we can't say whether overlapping private address spaces is a problem that can be dealt with by extending a protocol (the 'key') or by using good administration. They're exclusive. Alex > > >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> > > > "This email message and any attachments are confidential information > of Starent Networks, Corp. The information transmitted may not be > used to create or change any contractual obligations of Starent > Networks, Corp. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this e-mail and its > attachments by persons or entities other than the intended recipient > is prohibited. If you are not the intended recipient, please notify > the sender immediately -- by replying to this message or by sending > an email to postmaster@starentnetworks.com -- and destroy all copies > of this message and any attachments without reading or disclosing > their contents. Thank you." > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 03 11:47:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjdWH-0004M6-8G; Thu, 03 May 2007 11:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjdWG-0004Lt-1b for mip6@ietf.org; Thu, 03 May 2007 11:47:00 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjdWE-0002PT-NW for mip6@ietf.org; Thu, 03 May 2007 11:47:00 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1178207217!19109884!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 17740 invoked from network); 3 May 2007 15:46:57 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-6.tower-128.messagelabs.com with SMTP; 3 May 2007 15:46:57 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l43FkuEA011354; Thu, 3 May 2007 08:46:56 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l43FktP3011096; Thu, 3 May 2007 10:46:56 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l43FkrhH010959; Thu, 3 May 2007 10:46:53 -0500 (CDT) Message-ID: <463A03E4.2000307@gmail.com> Date: Thu, 03 May 2007 17:46:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip6] GRE key References: <7CCD07160348804497EF29E9EA5560D7024D9F6A$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9F6A$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000737-2, 30/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mip6@ietf.org, Alexandru Petrescu , "Casati, Alessio \(Alessio\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Chowdhury, Kuntal wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, May 03, 2007 >> 9:08 AM To: Ahmad Muhanna Cc: mip6@ietf.org; Alexandru Petrescu; >> Casati, Alessio (Alessio) Subject: Re: [Mip6] GRE key >> >> Ahmad Muhanna wrote: >>> Hi Alex, Please see comment inline. >>> >>>> Casati, Alessio (Alessio) wrote: >>>>> Kuntal's view is correct from here too. >>>> Where are the NATs? I don't see them. >>> That is the key Alex, there is no NAT in the PMIP domain for this >>> case. I believe the figure in the draft is quite straight >>> forward. >> If there's no NAT then how did people end up designing their >> address architecture so badly that address spaces overlap? >> > [KC>] There are pools of addresses in the HA/LMA for each domain it > supports. Some of these domains may be enterprises using private > address space. Are you saying that we deal here with a problem of two different Enterprises each with its own HA: an inter-domain PMIP? > So, it is often the case that pools of addresses for two domains on > the same HA/LMA are private and overlapping. YEs. But nobody said mobiles should be using these addresses to be reachable, or to hold continuos sessions, or to talk to other mobiles having same home address (they use CoAs for that). > So, there is a valid use case for GRE keys to be used to distinguish > user traffic for these domains in the LMA/HA. I would ask around more about the necessity of GRE. The overlapping private spaces is not a reason for any technology, it's a matter of poor administration. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 03 11:57:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjdgF-00065v-9g; Thu, 03 May 2007 11:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjdgE-00065K-5V for mip6@ietf.org; Thu, 03 May 2007 11:57:18 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjdgB-0003fx-RC for mip6@ietf.org; Thu, 03 May 2007 11:57:17 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1178207834!3629356!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2513 invoked from network); 3 May 2007 15:57:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 3 May 2007 15:57:14 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l43FvEXY017071; Thu, 3 May 2007 08:57:14 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l43FvDqa024347; Thu, 3 May 2007 10:57:14 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l43FvCkj024289; Thu, 3 May 2007 10:57:12 -0500 (CDT) Message-ID: <463A0652.4090504@gmail.com> Date: Thu, 03 May 2007 17:57:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip6] GRE key References: <7CCD07160348804497EF29E9EA5560D7024D9F6B$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9F6B$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000737-2, 30/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: mip6@ietf.org, "Casati, Alessio \(Alessio\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Chowdhury, Kuntal wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, May 03, 2007 >> 9:37 AM To: Ahmad Muhanna Cc: mip6@ietf.org; Alexandru Petrescu; >> Casati, Alessio (Alessio) Subject: Re: [Mip6] GRE key >> >> Ahmad Muhanna wrote: >>> Hi Alex, >>> >>> We are talking about the home address here for different VPNs, >>> for example, that the HA supports and it is possible for two MNs >>> from > two >>> different VPNs roam at the same time in the area of a single MAG > with >>> the same home private IP address. >>> >>> I hope this would help. >> It helps clarifying some parts, in that it may so happen that two >> MNs have the same private IPv4 Home Address. I will not go as far >> as > saying >> that I find this problem little worth exploring. >> >> [HEre's why: Private IPv4 Home Addresses aren't reachable from the >> Internet, > hence >> no need to give them continuous access with Mobile IP. >> > [KC>] Nobody is talking about internet routing here. We're completely out of synch :-) I wouldn't call Mobile IP "Internet routing", but maybe BGP I would (?) > Private IPv4 addressing is widely used in enterprises and campus > networks. Certainly. > These networks are often hosted by operators. Who often care little about the address plan of other operators, because the mobiles of one operator never need to talk to the mobile of another operator. > FYI....scenarios using private IPv4 HoA usefully has VPN links back > to the respective enterprise/campus networks. I think two things mixed here. A VPN user never gets the same IPv4 "Home" Address (although it is private). So the collision probabilty between two mobiles of different Enterprises is low. The second is that two mobiles using VPNs and wanting to talk to each other always have the possibliity to use their CoAs instead of potentially overlapping HoAs. So I really am not sure how the risk of overlapping private IPv4 addresses translates into a case when Mobile IPv6 is used and/or Proxy Mobile IPv6. >> MIPv6 doesn't deal with IPv4 Home Addresses. >> > [KC>] DS-MIP6 does. YEs, but not private IPv4 home addresses. >> DS-MIPv6 doesn't deal with HA behind NAT, hence doesn't deal with >> private IPv4 Home Addresses.] >> > [KC>] To support private IPv4 address pools, the HA won't have to be > necessarily behind a NAT from MN/MAGs PoV. If HA won't have to _be_ behind a NAT then will it be a NAT itself? >> -it is thought that GRE is needed for some SDO. Then it should be >> stated first and foremost. > > [KC>] I do not think we have to bring SDOs into this discussion. Thanks for confirming GRE for Proxy Mobile IPv6 is _not_ a SDO matter. Then what is the deployment need for it? >> -it is thought that GRE has something to do with PMIPv6 (not with >> MIPv6). Then the use of GRE tunnel instead of IPv6-in-IPv6 tunnel >> should be proposed to PMIPv6. > [KC>] overlapping IPv4 address pool use case applies to both PMIP6 > and DS-MIP6. It's too early for such statements. Or you may know better where PMIPv6 IPv4 support is going to. >> -it is thought that private IPv4 Addresses have something to do >> with DS-MIPv6. Then the use of one IPv4 private home address >> should be suggested to DS-MIPv6. > [KC>] Not sure that is necessary. But it is said that PMIPv6 uses DS-MIPv6 to support IPv4, right? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 04 07:42:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjwBG-00061C-BU; Fri, 04 May 2007 07:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjwBF-000617-7j for mip6@ietf.org; Fri, 04 May 2007 07:42:33 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjwBE-00041g-Jv for mip6@ietf.org; Fri, 04 May 2007 07:42:33 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 13:42:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] GRE key Date: Fri, 4 May 2007 13:42:29 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301D80EAB@SEHAN021MB.tcad.telia.se> In-Reply-To: <463A0652.4090504@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] GRE key Thread-Index: AceNm8KGW/SRx9foSvKML5nMXmmQ0QAogeIg References: <7CCD07160348804497EF29E9EA5560D7024D9F6B$0001@exchtewks2.starentnetworks.com> <463A0652.4090504@gmail.com> From: To: , X-OriginalArrivalTime: 04 May 2007 11:42:30.0925 (UTC) FILETIME=[4C67FBD0:01C78E41] X-Spam-Score: 0.2 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: mip6@ietf.org, acasati@alcatel-lucent.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, See some comments inline. > Chowdhury, Kuntal wrote: > >=20 > >> -----Original Message----- From: Alexandru Petrescu=20 > >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, May 03, 2007 > >> 9:37 AM To: Ahmad Muhanna Cc: mip6@ietf.org; Alexandru Petrescu;=20 > >> Casati, Alessio (Alessio) Subject: Re: [Mip6] GRE key > >>=20 > >> Ahmad Muhanna wrote: > >>> Hi Alex, > >>>=20 > >>> We are talking about the home address here for different=20 > VPNs, for=20 > >>> example, that the HA supports and it is possible for two MNs from > > two > >>> different VPNs roam at the same time in the area of a single MAG > > with > >>> the same home private IP address. > >>>=20 > >>> I hope this would help. > >> It helps clarifying some parts, in that it may so happen=20 > that two MNs=20 > >> have the same private IPv4 Home Address. I will not go as far as > > saying > >> that I find this problem little worth exploring. > >>=20 > >> [HEre's why: Private IPv4 Home Addresses aren't reachable from the=20 > >> Internet, > > hence > >> no need to give them continuous access with Mobile IP. > >>=20 > > [KC>] Nobody is talking about internet routing here. >=20 > We're completely out of synch :-) I wouldn't call Mobile IP=20 > "Internet routing", but maybe BGP I would (?) >=20 > > Private IPv4 addressing is widely used in enterprises and campus=20 > > networks. >=20 > Certainly. >=20 > > These networks are often hosted by operators. >=20 > Who often care little about the address plan of other=20 > operators, because the mobiles of one operator never need to=20 > talk to the mobile of another operator. That's why there are magic proxy boxes mobiles register to reach the other mobiles. Not the cleanest solution but in certain service deployments it does not really matter if terminals cannot contact each other directly. Other thing is that a mobile operator most probably would not allow direct connectivity between terminals anyway. Either because of security reasons or for some other artificial reasons. =20 > > FYI....scenarios using private IPv4 HoA usefully has VPN=20 > links back to=20 > > the respective enterprise/campus networks. >=20 > I think two things mixed here. A VPN user never gets the=20 > same IPv4 "Home" Address (although it is private). So the=20 > collision probabilty between two mobiles of different=20 > Enterprises is low. The second is that two mobiles using=20 > VPNs and wanting to talk to each other always have the=20 > possibliity to use their CoAs instead of potentially overlapping HoAs. >=20 > So I really am not sure how the risk of overlapping private=20 > IPv4 addresses translates into a case when Mobile IPv6 is=20 > used and/or Proxy Mobile IPv6. >=20 > >> MIPv6 doesn't deal with IPv4 Home Addresses. > >>=20 > > [KC>] DS-MIP6 does. >=20 > YEs, but not private IPv4 home addresses. DSMIP6 spec mentions that IPv4-HoA can be a private address. > >> DS-MIPv6 doesn't deal with HA behind NAT, hence doesn't deal with=20 > >> private IPv4 Home Addresses.] > >>=20 > > [KC>] To support private IPv4 address pools, the HA won't=20 > have to be =20 > > necessarily behind a NAT from MN/MAGs PoV. >=20 > If HA won't have to _be_ behind a NAT then will it be a NAT itself? Not necessarily.. there can be deployments where the HA has public IP, mobiles have their (virtual) private addressed network and somewhere behing the HA there is NAT box before reaching the Internet. I would say rather common deployment. > >> -it is thought that GRE is needed for some SDO. Then it=20 > should be =20 > >> stated first and foremost. > >=20 > > [KC>] I do not think we have to bring SDOs into this discussion. >=20 > Thanks for confirming GRE for Proxy Mobile IPv6 is _not_ a SDO matter. > > Then what is the deployment need for it? > > >> -it is thought that GRE has something to do with PMIPv6 (not with=20 > >> MIPv6). Then the use of GRE tunnel instead of=20 > IPv6-in-IPv6 tunnel =20 > >> should be proposed to PMIPv6. > > [KC>] overlapping IPv4 address pool use case applies to=20 > both PMIP6 and=20 > > DS-MIP6. >=20 > It's too early for such statements. Or you may know better=20 > where PMIPv6 > IPv4 support is going to. >=20 > >> -it is thought that private IPv4 Addresses have something=20 > to do with=20 > >> DS-MIPv6. Then the use of one IPv4 private home address should be=20 > >> suggested to DS-MIPv6. > > [KC>] Not sure that is necessary. >=20 > But it is said that PMIPv6 uses DS-MIPv6 to support IPv4, right? >=20 > Alex /JOuni >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 04 08:23:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjwp0-0000lo-NJ; Fri, 04 May 2007 08:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjwoz-0000lY-9H for mip6@ietf.org; Fri, 04 May 2007 08:23:37 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hjwox-0002qX-UK for mip6@ietf.org; Fri, 04 May 2007 08:23:37 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1178281014!8523757!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 28152 invoked from network); 4 May 2007 12:16:54 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-12.tower-128.messagelabs.com with SMTP; 4 May 2007 12:16:54 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l44CGrFY013022 for ; Fri, 4 May 2007 07:16:53 -0500 (CDT) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l44CGqsw006279 for ; Fri, 4 May 2007 07:16:52 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.1.41]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l44CGpYH006263 for ; Fri, 4 May 2007 07:16:51 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Fri, 4 May 2007 13:16:50 +0100 Message-ID: <463B2431.3080303@gmail.com> Date: Fri, 04 May 2007 14:16:49 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [Mip6] GRE key References: <7CCD07160348804497EF29E9EA5560D7024D9F6B$0001@exchtewks2.starentnetworks.com> <463A0652.4090504@gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED301D80EAB@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301D80EAB@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000738-1, 03/05/2007), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 04 May 2007 12:16:50.0631 (UTC) FILETIME=[18162D70:01C78E46] X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mip6@ietf.org, acasati@alcatel-lucent.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jouni, some comments... jouni.korhonen@teliasonera.com wrote: >>>> MIPv6 doesn't deal with IPv4 Home Addresses. >>>> >>> [KC>] DS-MIP6 does. >> YEs, but not private IPv4 home addresses. > > DSMIP6 spec mentions that IPv4-HoA can be a private address. It does. But that doesn't mean it makes sense [it claims HA to be reachable behind NAT but we need MN to be reachable behind NAT]. We can discuss it separately. >>>> DS-MIPv6 doesn't deal with HA behind NAT, hence doesn't deal >>>> with private IPv4 Home Addresses.] >>>> >>> [KC>] To support private IPv4 address pools, the HA won't >> have to be >>> necessarily behind a NAT from MN/MAGs PoV. >> If HA won't have to _be_ behind a NAT then will it be a NAT itself? >> > > Not necessarily.. there can be deployments where the HA has public > IP, mobiles have their (virtual) private addressed network and > somewhere behing the HA there is NAT box before reaching the > Internet. I would say rather common deployment. I think this potential DS-MIPv6 deployment does not offer reachability for MN at its private IPv4 Home Address. In all cases, DS-MIPv6 doesn't use GRE tunnelling but IPv6-in-IPv6 and/or IPv6-in-UDP-or-in-IP. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun May 06 10:55:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hki8u-0002sR-Av; Sun, 06 May 2007 10:55:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hki8t-0002ro-Ih for mip6@ietf.org; Sun, 06 May 2007 10:55:19 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hki8s-00007B-7i for mip6@ietf.org; Sun, 06 May 2007 10:55:19 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l46Esloq018037; Sun, 6 May 2007 09:54:47 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 May 2007 09:55:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Multicast Mobility mailing list Date: Sun, 6 May 2007 10:52:31 -0400 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA542DFB@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Multicast Mobility mailing list Thread-Index: AceFd94LsV+nugYqTIGyqsVQoOwCDQKdk6Ac References: <6D19CA8D71C89C43A057926FE0D4ADAA542DF2@ecamlmw720.eamcs.ericsson.se> <462C5E21.2050008@azairenet.com> From: "Suresh Krishnan \(QB/EMC\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 06 May 2007 14:55:14.0589 (UTC) FILETIME=[8DB694D0:01C78FEE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, Sorry for the late reply. I am on vacation and checking mail very = irregularly. I was not even thinking about where to place the work. The = idea of the mailing list was to get interested people working together = (that includes operators, implementers and researchers). What you = suggest may very well be what would end up happening (charters = permitting). =20 Thanks Suresh ________________________________ From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] Sent: Mon 23/04/2007 3:20 AM To: Suresh Krishnan (QB/EMC) Cc: mip6@ietf.org; Jari Arkko Subject: Re: [Mip6] Multicast Mobility mailing list Hello Suresh, I would suggest mobopts as one venue for this work. Some proposals have already been presented in the mobopts group on this topic. We could do the work in the mobopts group and once they are stable enough, bring them to the MIPSHOP or the MIP6 WG for standardization. Vijay Suresh Krishnan (QB/EMC) wrote: > Hi Folks, >=20 > We wanted to inform you that we have created a new mailing list in = order > to discuss the interactions occuring between mobility and multicast. = We > invite anyone interested in contributing to the work to subscribe and > collaborate. To register visit the list page at: >=20 > https://www1.ietf.org/mailman/listinfo/multimob >=20 > Several of you have expressed interest in this work and some documents > already exist without a home working group. >=20 > The primary problem that we foresee being discussed in the mailing = list > is issues with Multicast listener (receiver) mobility for multicast > routing. There are several other associated problems like sender > mobility, which can also be discussed. >=20 > Thanks > Suresh and Behcet > > _______________________________________________ > 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 From mip6-bounces@ietf.org Tue May 08 17:17:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlX3D-0002wN-SI; Tue, 08 May 2007 17:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlX3B-0002rH-Gm; Tue, 08 May 2007 17:16:49 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlX39-0002mr-0J; Tue, 08 May 2007 17:16:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l48LGWeV012038; Wed, 9 May 2007 00:16:45 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 00:16:39 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 16:15:17 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 May 2007 21:15:17 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 08 May 2007 16:16:24 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List , Message-ID: Thread-Topic: DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 May 2007 21:15:17.0890 (UTC) FILETIME=[FA5DAE20:01C791B5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, The DS-MIP6 I-D still has issue 93 open. This was discussed at IETF68. Vijay presented 4 options to solve the issue. These are captured in: https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf We need to make a decision on this issue and move forward with the I-D. At the meeting itself, I got the sense that option 3 was the one that had the least impact and easy to implement. Please consider this email as a consensus call for issue 93. The problem and choices are as follows (based on Vijay's slides): Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The encapculations are either: - IPv6-in-UDP-over-IPv4 - IPv4-in-UDP-over-IPv4 There is a need (or I guess desirable) to indicate the type of protocol being encapsulated in the UDP header. Choices are: 1. Parse the protocol header following the UDP header 2. Reserve a UDP port for each protocol header (i.e one UDP port for IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a DS-MIP6 "tunnel type message" 4. Encapsulated protocol header type is indicated in the BU message Pros and cons of these choices are in the slides that were presented at IETF68 (see URL above). Please provide your opinions and comments by May 15th, 07 on the MIP6 mailing list. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 08 17:27:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXDY-0003pp-JC; Tue, 08 May 2007 17:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXDX-0003pk-NN for mip6@ietf.org; Tue, 08 May 2007 17:27:31 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXDX-00059p-5h for mip6@ietf.org; Tue, 08 May 2007 17:27:31 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l48LREgc001745; Wed, 9 May 2007 00:27:23 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 00:27:22 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 16:27:19 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 May 2007 21:27:18 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 08 May 2007 16:28:25 -0500 Subject: Re: [Mip6] Dynamic HoA assignment From: Basavaraj Patil To: , Message-ID: Thread-Topic: [Mip6] Dynamic HoA assignment Thread-Index: AceRt8+FDkDTGP2rEduUrQARJNUNiA== In-Reply-To: <27165242.528561176278361285.JavaMail.weblogic@ep_ml22> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 May 2007 21:27:19.0202 (UTC) FILETIME=[A84D2820:01C791B7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Heejin, >From the discussion on the list, I do not see the need for DHCP to assign the MN an HoA. I think there is a general consensus that when IKEv2 is used to bootstrap, then the MN can obtain the HoA via the IKEv2 messages. So DHCP to assign the HoA in this case is not required. So that leaves us only the case when the auth-protocol (RFC4285) is used. As per the discussion I think we have two choices: 1. Allow the sending of the unspecified address in the MIP6 BU and obtain the HoA in the BAck 2. Assign the HoA via DHCP Option 1 will cause an update to base MIP6 (RFC3775). I have not seen any significant security issue or concern in sending a BU with the unspecified address. So I think that is a possibility. The problem with having DHCP assign the HoA is the fact that there are a lot of missing pieces as to how DHCP really gets the HoA from the address space whose scope is at an HA. The HA assigning the HoA makes more sense. I think in order to move the I-D: draft-ietf-mip6-hiopt-02.txt, we should consider removing the HoA option from the draft. -Raj On 4/11/07 2:59 AM, "ext Heejin Jang" wrote: > Hi, Raj & folks. > > I think that HoA assignment through DHCP is necessary. > > In Proxy MIP, MN has plain IP stack without any advanced functions such as > MIP client, > and there is no way to deliver HoA to MN in the last hop except DHCP. > Since, in PMIP, HoA assignment during IKEv2 or BU/BA exchanges is possible > between PMA (MAG) & HA, > not between MN & HA. Though HoA is bootstrapped through either IKEv2 or BU/BA > exchanges, > it should be delivered from the network to the MN after all and DHCP could be > a delivery mechanism for it. > > - Regards, > Heejin. > > > > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Friday, April 06, 2007 7:07 AM > To: Mobile IPv6 Mailing List > Subject: [Mip6] Dynamic HoA assignment > > > Hello, > > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as well > in addition to the HA address and prefix via DHCP. > > I think the MN should obtain the minimal information required to bootstrap. > It is better to have the HA assign the MN an HoA. To do this we would require > capability similar to MIP4 wherein the BU can be sent with an unspecified HoA. > This is currently not possible as per RFC3775. > > Should we consider allowing the MN sending a BU with the unspecified HoA and > obtain an HoA (assigned by the HA) in the BAck? > > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such capability. > Also do we need to consider standardizing the bootstrapping mechanism for the > auth protocol (RFC 4285)? > > -Basavaraj > > > _______________________________________________ > 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 From mip6-bounces@ietf.org Tue May 08 21:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlar7-0000bK-8r; Tue, 08 May 2007 21:20:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlar6-0000bC-5U; Tue, 08 May 2007 21:20:36 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlar4-0001Wv-R8; Tue, 08 May 2007 21:20:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] DS-MIP6: Consensus call to close issue 93 Date: Tue, 8 May 2007 18:20:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 thread-index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAIaHhA References: From: "Vijay Devarapalli" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, My preference is for option 4. I know many preferred option=20 3, but it adds a 4 byte per-packet overhead for each tunneled data packet. I wish we can avoid that. Vijay=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, May 08, 2007 2:16 PM > To: Mobile IPv6 Mailing List; nemo@ietf.org > Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 >=20 > Hello, >=20 > The DS-MIP6 I-D still has > issue 93 open. This was discussed at IETF68. Vijay presented 4 options > to solve the issue. These are captured in: >=20 > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >=20 > We need to make a decision on this issue and move forward with the > I-D. At the meeting itself, I got the sense that option 3 was the one > that had the least impact and easy to implement. >=20 > Please consider this email as a consensus call for issue 93. The > problem and choices are as follows (based on Vijay's slides): >=20 > Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The > encapculations are either: > - IPv6-in-UDP-over-IPv4 > - IPv4-in-UDP-over-IPv4 > There is a need (or I guess desirable) to indicate the type of > protocol being encapsulated in the UDP header. >=20 > Choices are: > 1. Parse the protocol header following the UDP header > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > 4. Encapsulated protocol header type is indicated in the BU message >=20 > Pros and cons of these choices are in the slides that were presented > at IETF68 (see URL above). >=20 > Please provide your opinions and comments by May 15th, 07 on the MIP6 > mailing list. >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 08 22:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlbWi-0002a1-LZ; Tue, 08 May 2007 22:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlbWf-0002Zm-Rd; Tue, 08 May 2007 22:03:34 -0400 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlbWb-00022r-Dv; Tue, 08 May 2007 22:03:33 -0400 Received: from oaamta02ps.mx.bigpond.com ([124.191.178.123]) by omta02ps.mx.bigpond.com with ESMTP id <20070509020325.UWIJ7838.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Wed, 9 May 2007 02:03:25 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005>; Wed, 9 May 2007 02:03:25 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Wed, 9 May 2007 12:03:21 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0Sog X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Message-Id: <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, At the meeting Sri (the author of the issue) and Kent said they didn't know that a UDP port was already reserved. Once we cleared that, the rationale for the issue was no longer applicable. I believe Sri said he wanted some time to be sure before the issue is rejected. More inline on the options: > Choices are: > 1. Parse the protocol header following the UDP header => This should be "parse the version field after the UDP header". This is what's already in the draft and it works fine today with any UDP encapsulation. > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) => This isn't needed. > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" => This is what the issue suggested but the additional 4 bytes are redundant. > 4. Encapsulated protocol header type is indicated in the BU message => Again, not needed IMO. I think option 1 is the right option. There is no reason given for a change. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 08 22:17:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlbjf-0003GZ-Uy; Tue, 08 May 2007 22:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlbje-0003GN-9d; Tue, 08 May 2007 22:16:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlbjd-0003z5-UZ; Tue, 08 May 2007 22:16:58 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 08 May 2007 19:16:57 -0700 X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="419987936:sNHT48143176" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l492GvId029797; Tue, 8 May 2007 19:16:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l492GuEi006748; Wed, 9 May 2007 02:16:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 19:16:56 -0700 Received: from sgundavewxp ([10.32.246.211]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 19:16:55 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , References: <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Tue, 8 May 2007 19:16:54 -0700 Message-ID: <019401c791e0$1d58d010$d3f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAABYFIA= X-OriginalArrivalTime: 09 May 2007 02:16:56.0143 (UTC) FILETIME=[1DC3EDF0:01C791E0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2242; t=1178677017; x=1179541017; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=uOFG3aw0cGx1awpmdUCQWK8QnurzxdauYj5Q4FjiaqU=; b=OfqinzzDQhw4lEQdiTdwPFP/kMPYlx3038E+hu5qmhtYIyUUo4RPo5FSwDOFNmVXhkCofZ/a kQURJ+fADT3C9QvYvjkPIijQ2V9cfYn7E63s7R7tMawbApXBay0KjxV9P6z+5z+9Yrna3CQ04F XRcVqzafDK/OHwgPPuV91EU64=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham: Sure. I agree that the application can switch based on the IP version field. True. I'm ok either way. You can keep it the way you have it now or use an approach below. But, just one comment. I prefere 3519 style of thin wrapper. Reason: If we need to add Keepalive messages tomorrow, a separate subtype can be defined for the keepalive messages and so we can extend this. Off course, I do realize, you guys wanted to use BU/BA as the keepalive message and that processing in my opinion is bit expensive compared to a simple keepalive message and that too with the option of skipping keepalive message when any data traffic is seen. But, if you think this 4-byte wrapper is a waste for the keepalive extension that never be defined in future, I'm ok. Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Tuesday, May 08, 2007 7:03 PM > To: 'Basavaraj Patil'; 'Mobile IPv6 Mailing List'; nemo@ietf.org > Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 > > Hi Raj, > > At the meeting Sri (the author of the issue) and Kent said > they didn't know > that a UDP port was already reserved. Once we cleared that, > the rationale > for the issue was no longer applicable. I believe Sri said he > wanted some > time to be sure before the issue is rejected. > More inline on the options: > > > > Choices are: > > 1. Parse the protocol header following the UDP header > > => This should be "parse the version field after the UDP > header". This is > what's already in the draft and it works fine today with any UDP > encapsulation. > > > 2. Reserve a UDP port for each protocol header (i.e one > UDP port for > > IPv6-in-UDP-over-IPv4 and another for > IPv4-in-UDP-over-IPv4 etc.) > > => This isn't needed. > > > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > => This is what the issue suggested but the additional 4 bytes are > redundant. > > > 4. Encapsulated protocol header type is indicated in the BU message > > => Again, not needed IMO. > > I think option 1 is the right option. There is no reason > given for a change. > > Hesham > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 08 22:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlbtv-0001n0-8n; Tue, 08 May 2007 22:27:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlbtt-0001mS-Be; Tue, 08 May 2007 22:27:33 -0400 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlbts-0005Hh-Sp; Tue, 08 May 2007 22:27:33 -0400 Received: from oaamta08ps.mx.bigpond.com ([124.191.178.123]) by omta04ps.mx.bigpond.com with ESMTP id <20070509022725.UMQQ15631.omta04ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com>; Wed, 9 May 2007 02:27:25 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta08ps.mx.bigpond.com with ESMTP id <20070509022724.LMVG26028.oaamta08ps.mx.bigpond.com@PC20005>; Wed, 9 May 2007 02:27:24 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Wed, 9 May 2007 12:27:20 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAABYFIAAAJElMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <019401c791e0$1d58d010$d3f6200a@amer.cisco.com> Message-Id: <20070509022724.LMVG26028.oaamta08ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, > Sure. I agree that the application can switch based > on the IP version field. True. I'm ok either way. You > can keep it the way you have it now or use an approach > below. But, just one comment. > > I prefere 3519 style of thin wrapper. Reason: If we > need to add Keepalive messages tomorrow, a separate > subtype can be defined for the keepalive messages and > so we can extend this. Off course, I do realize, you guys > wanted to use BU/BA as the keepalive message and that > processing in my opinion is bit expensive compared to a > simple keepalive message and that too with the option > of skipping keepalive message when any data traffic > is seen. But, if you think this 4-byte wrapper is a waste > for the keepalive extension that never be defined in > future, I'm ok. => I agree with you on the need for lighter weight keep-alive. I raised an issue a long time ago, and rejected it :), because there wasn't enough interest to justify its addition. However, I don't think it's related to this discussion because if we wanted a keep alive we could simply define a new option in the DO header or just encapsulate a "ping". So I don't see the correlation with this issue as the keepalive can always be sent in a ping using either IPv4 or IPv6 and the same parsing rules would apply. Hesham > > Sri > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Tuesday, May 08, 2007 7:03 PM > > To: 'Basavaraj Patil'; 'Mobile IPv6 Mailing List'; nemo@ietf.org > > Subject: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > > > Hi Raj, > > > > At the meeting Sri (the author of the issue) and Kent said > > they didn't know > > that a UDP port was already reserved. Once we cleared that, > > the rationale > > for the issue was no longer applicable. I believe Sri said he > > wanted some > > time to be sure before the issue is rejected. > > More inline on the options: > > > > > > > Choices are: > > > 1. Parse the protocol header following the UDP header > > > > => This should be "parse the version field after the UDP > > header". This is > > what's already in the draft and it works fine today with any UDP > > encapsulation. > > > > > 2. Reserve a UDP port for each protocol header (i.e one > > UDP port for > > > IPv6-in-UDP-over-IPv4 and another for > > IPv4-in-UDP-over-IPv4 etc.) > > > > => This isn't needed. > > > > > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > > > => This is what the issue suggested but the additional 4 bytes are > > redundant. > > > > > 4. Encapsulated protocol header type is indicated in > the BU message > > > > => Again, not needed IMO. > > > > I think option 1 is the right option. There is no reason > > given for a change. > > > > Hesham > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 03:07:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2kG-0007AM-95; Thu, 10 May 2007 03:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2kE-00075s-Qz; Thu, 10 May 2007 03:07:22 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm2kE-0000IC-HJ; Thu, 10 May 2007 03:07:22 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4A77BA16621; Thu, 10 May 2007 07:07:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 02:07:09 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711426E083@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAIaHhAAD1bsAA= References: From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, In case that we choose option 4 for the sake of saving the 4 bytes, do not we, at the same time, limit the option of carrying more than one type of traffic for the same session? I believe we can negotiate only one type in BU/BA. Right? If that is the case, would you consider option 3 again since it fits naturally in the IP packet processing without the need to peak into the encapsulated header to identify the traffic type. Regards, Ahmad =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: Tuesday, May 08, 2007 8:21 PM > To: Basavaraj Patil; Mobile IPv6 Mailing List; nemo@ietf.org > Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 > Hi, >=20 > My preference is for option 4. I know many preferred option=20 > 3, but it adds a 4 byte per-packet overhead for each tunneled=20 > data packet. I wish we can avoid that. >=20 > Vijay=20 >=20 > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Tuesday, May 08, 2007 2:16 PM > > To: Mobile IPv6 Mailing List; nemo@ietf.org > > Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > >=20 > >=20 > > Hello, > >=20 > > The DS-MIP6 I-D still has=20 > > issue 93 open. This was discussed at IETF68. Vijay=20 > presented 4 options=20 > > to solve the issue. These are captured in: > >=20 > > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >=20 > > We need to make a decision on this issue and move forward with the=20 > > I-D. At the meeting itself, I got the sense that option 3=20 > was the one=20 > > that had the least impact and easy to implement. > >=20 > > Please consider this email as a consensus call for issue 93. The=20 > > problem and choices are as follows (based on Vijay's slides): > >=20 > > Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 > traversal. The=20 > > encapculations are either: > > - IPv6-in-UDP-over-IPv4 > > - IPv4-in-UDP-over-IPv4 > > There is a need (or I guess desirable) to indicate the type of=20 > > protocol being encapsulated in the UDP header. > >=20 > > Choices are: > > 1. Parse the protocol header following the UDP header 2.=20 > Reserve a UDP=20 > > port for each protocol header (i.e one UDP port for > > IPv6-in-UDP-over-IPv4 and another for=20 > IPv4-in-UDP-over-IPv4 etc.)=20 > > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > 4. Encapsulated protocol header type is indicated in the BU message > >=20 > > Pros and cons of these choices are in the slides that were=20 > presented=20 > > at IETF68 (see URL above). > >=20 > > Please provide your opinions and comments by May 15th, 07=20 > on the MIP6=20 > > mailing list. > >=20 > > -Raj > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 03:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2pJ-0001K5-Uo; Thu, 10 May 2007 03:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2pJ-0001Jv-Bn for mip6@ietf.org; Thu, 10 May 2007 03:12:37 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm2pI-0000n5-O5 for mip6@ietf.org; Thu, 10 May 2007 03:12:37 -0400 Received: by wr-out-0506.google.com with SMTP id 71so499476wri for ; Thu, 10 May 2007 00:12:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=sokaLNY1GNX1Mw4upXzkb5hQGvyNM7P44nnFPdzaZjiN9Rs3C8jWvBQx+DHal2EE1jeV4xd4UJPdaeGsprY9EqRavIN8EPLQ2EIwYdjmzM4+gVswHr/zfIX8nqoLJykGRWdt8j+sPBL2WenGwMrVLkMQqaAy6W8i1z3Z/he7BFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=UXmd1GVZlksoFpPV9TF04dATRmet3cGR4XmEA9jOibriYY4eeEo+Qw2artmy3ZUCggfND5xG3wTG3PVkNCw2YqLdZ8Ehd0cK6adnKDZ6ixVhcGrznBFfo7Mk+H3YwIyF6fQyu4S+EvFJjlBrCjpD/xXKzCX+G07h5UIKhF810Mo= Received: by 10.115.55.1 with SMTP id h1mr388913wak.1178781156111; Thu, 10 May 2007 00:12:36 -0700 (PDT) Received: from ?133.27.59.67? ( [133.27.59.67]) by mx.google.com with ESMTP id a8sm160001poa.2007.05.10.00.12.34; Thu, 10 May 2007 00:12:35 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 16:12:28 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, In your slide, you said "If DS-MIPv6 is not implemented in the kernel, then it is still an issue" for the option-1. What kind of problem is there? I believer an userland program can parse the headers and process the received packets accordingly. regards ryuji On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > Hi, > > My preference is for option 4. I know many preferred option > 3, but it adds a 4 byte per-packet overhead for each tunneled > data packet. I wish we can avoid that. > > Vijay > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Tuesday, May 08, 2007 2:16 PM >> To: Mobile IPv6 Mailing List; nemo@ietf.org >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >> >> >> Hello, >> >> The DS-MIP6 I-D still has >> issue 93 open. This was discussed at IETF68. Vijay presented 4 >> options >> to solve the issue. These are captured in: >> >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >> >> We need to make a decision on this issue and move forward with the >> I-D. At the meeting itself, I got the sense that option 3 was the one >> that had the least impact and easy to implement. >> >> Please consider this email as a consensus call for issue 93. The >> problem and choices are as follows (based on Vijay's slides): >> >> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The >> encapculations are either: >> - IPv6-in-UDP-over-IPv4 >> - IPv4-in-UDP-over-IPv4 >> There is a need (or I guess desirable) to indicate the type of >> protocol being encapsulated in the UDP header. >> >> Choices are: >> 1. Parse the protocol header following the UDP header >> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >> 4. Encapsulated protocol header type is indicated in the BU message >> >> Pros and cons of these choices are in the slides that were presented >> at IETF68 (see URL above). >> >> Please provide your opinions and comments by May 15th, 07 on the MIP6 >> mailing list. >> >> -Raj >> >> >> _______________________________________________ >> 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 From mip6-bounces@ietf.org Thu May 10 03:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2xC-0007Ci-QU; Thu, 10 May 2007 03:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm2xB-0007CV-OF; Thu, 10 May 2007 03:20:45 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm2xA-0001Xp-9E; Thu, 10 May 2007 03:20:45 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 10 May 2007 00:20:43 -0700 X-IronPort-AV: i="4.14,516,1170662400"; d="scan'208"; a="59012483:sNHT50601834" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4A7KhCD027353; Thu, 10 May 2007 00:20:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4A7Kkwn014514; Thu, 10 May 2007 07:20:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 00:20:42 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 00:20:42 -0700 From: "Sri Gundavelli" To: "'RYUJI WAKIKAWA'" , "'Vijay Devarapalli'" References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 00:20:42 -0700 Message-ID: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3A In-Reply-To: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 10 May 2007 07:20:42.0311 (UTC) FILETIME=[B7D23570:01C792D3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3844; t=1178781643; x=1179645643; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=7tHyTJw1VkAWmsat8rgYsWdxzR+vagxYU+J7ufFGbu4=; b=Zfd2Buf0CQ8BpkyU9HrfXO736qKt72tFehh35XW5fb/xN5p4ELgptBEz6SOZFlqOTxXD7Dg5 c4M0YRLkX6UxKFz2lgoOZDw5SPhqtSl63Vux2CFLRXPKiiROxnARi0fm; Authentication-Results: sj-dkim-5; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ryuji: All protocol packets have payload qualifiers. Looking at the payload to determine the packet type, I'm not sure that is the followed convention. The protocol type in the IP header, or the next option type in the IPv6 headers, the protocol type in gre header, or the 3519 Data Message, all follow this style of containment. We can certainly switch by looking at the 1st byte of the IP packet, but that limits the payload to IP. We cannot carry GRE header over UDP tomorrow, or we cant define a separate control message such as a keepalive message. Why not use a simple type header and provide the room for carrying new payloads ? This may not address your specific comment on the user proc parsing of the packet. But, my comment is on the need for a TLV header. Sri > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > Sent: Thursday, May 10, 2007 12:12 AM > To: Vijay Devarapalli > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > Hi Vijay, > > In your slide, you said "If DS-MIPv6 is not implemented in the > kernel, then it is still an issue" > for the option-1. > > What kind of problem is there? > I believer an userland program can parse the headers > and process the received packets accordingly. > > regards > ryuji > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > Hi, > > > > My preference is for option 4. I know many preferred option > > 3, but it adds a 4 byte per-packet overhead for each tunneled > > data packet. I wish we can avoid that. > > > > Vijay > > > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Tuesday, May 08, 2007 2:16 PM > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > >> > >> > >> Hello, > >> > >> The DS-MIP6 I-D still has > >> issue 93 open. This was discussed at IETF68. Vijay presented 4 > >> options > >> to solve the issue. These are captured in: > >> > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >> > >> We need to make a decision on this issue and move forward with the > >> I-D. At the meeting itself, I got the sense that option 3 > was the one > >> that had the least impact and easy to implement. > >> > >> Please consider this email as a consensus call for issue 93. The > >> problem and choices are as follows (based on Vijay's slides): > >> > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > traversal. The > >> encapculations are either: > >> - IPv6-in-UDP-over-IPv4 > >> - IPv4-in-UDP-over-IPv4 > >> There is a need (or I guess desirable) to indicate the type of > >> protocol being encapsulated in the UDP header. > >> > >> Choices are: > >> 1. Parse the protocol header following the UDP header > >> 2. Reserve a UDP port for each protocol header (i.e one > UDP port for > >> IPv6-in-UDP-over-IPv4 and another for > IPv4-in-UDP-over-IPv4 etc.) > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > >> 4. Encapsulated protocol header type is indicated in the BU message > >> > >> Pros and cons of these choices are in the slides that were > presented > >> at IETF68 (see URL above). > >> > >> Please provide your opinions and comments by May 15th, 07 > on the MIP6 > >> mailing list. > >> > >> -Raj > >> > >> > >> _______________________________________________ > >> 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 05:37:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm55c-0005Kw-Eu; Thu, 10 May 2007 05:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm55Z-0005Kh-Mt for mip6@ietf.org; Thu, 10 May 2007 05:37:35 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm55Y-0006d7-IC for mip6@ietf.org; Thu, 10 May 2007 05:37:33 -0400 Received: by py-out-1112.google.com with SMTP id f31so407092pyh for ; Thu, 10 May 2007 02:37:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=oGIoOJ+97L+/GFT0tlilBZpNPfWL5iNSQnDcQZOi8AKELX8Op77b77CUMZT25RSHtwS7OupUrqqKOsAlLuA8rIN72QuR48i+aBk7eCMJaOtuOLxGHr7vu1ZpjYkA4E3OFrWwOggLUjkKw6Xt0lDfNDQ5RbWI3ju5qZmhakvjZvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=rBZEUHZG8wDz2vTGslc8Archi9fLO/lrpUMVl7uXxIxWRlvjhynmXYNnsowgGnCBOfnesqQsssH9vCA15F9jxsJdT3tG7KpMizDwr1sJ2ehkHzW1SX34DwT5/ZRGx4295KcZmarP6gPOOxfl9PJVeofeB4JqRf4GGgkEKTf3Dhs= Received: by 10.35.94.2 with SMTP id w2mr2708619pyl.1178789852201; Thu, 10 May 2007 02:37:32 -0700 (PDT) Received: from ?203.178.143.206? ( [203.178.143.206]) by mx.google.com with ESMTP id f77sm17781796pyh.2007.05.10.02.37.30; Thu, 10 May 2007 02:37:31 -0700 (PDT) In-Reply-To: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com> <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 18:37:25 +0900 To: Sri Gundavelli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, The problem is not yet in DSMIP, because DSMIP only supports IPv4 and IPv6 packets in UDP. As Hesham said, the receiver can simply check the followed header (IP) and can determine whether IPv4 or IPv6. I am fine with 4 bytes if there is strong reason for that, however I want to see what kind of additional payloads is considered in the future. In addition, can this 4 bytes mandate only for non IP packets followed by UDP header? If the default is either IPv4 or IPv6, it isn't much big problem for implementations. ryuji On 2007/05/10, at 16:20, Sri Gundavelli wrote: > Hi Ryuji: > > All protocol packets have payload qualifiers. > Looking at the payload to determine the packet type, > I'm not sure that is the followed convention. The protocol > type in the IP header, or the next option type in > the IPv6 headers, the protocol type in gre header, > or the 3519 Data Message, all follow this style of > containment. We can certainly switch by looking at > the 1st byte of the IP packet, but that limits the payload > to IP. We cannot carry GRE header over UDP tomorrow, > or we cant define a separate control message such as > a keepalive message. Why not use a simple type header > and provide the room for carrying new payloads ? > > This may not address your specific comment on the > user proc parsing of the packet. But, my comment > is on the need for a TLV header. > > Sri > > > > > > > > >> -----Original Message----- >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >> Sent: Thursday, May 10, 2007 12:12 AM >> To: Vijay Devarapalli >> Cc: nemo@ietf.org; Mobile IPv6 Mailing List >> Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to >> close issue 93 >> >> Hi Vijay, >> >> In your slide, you said "If DS-MIPv6 is not implemented in the >> kernel, then it is still an issue" >> for the option-1. >> >> What kind of problem is there? >> I believer an userland program can parse the headers >> and process the received packets accordingly. >> >> regards >> ryuji >> >> On 2007/05/09, at 10:20, Vijay Devarapalli wrote: >> >>> Hi, >>> >>> My preference is for option 4. I know many preferred option >>> 3, but it adds a 4 byte per-packet overhead for each tunneled >>> data packet. I wish we can avoid that. >>> >>> Vijay >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Tuesday, May 08, 2007 2:16 PM >>>> To: Mobile IPv6 Mailing List; nemo@ietf.org >>>> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >>>> >>>> >>>> Hello, >>>> >>>> The DS-MIP6 I-D still has >>>> issue 93 open. This was discussed at IETF68. Vijay presented 4 >>>> options >>>> to solve the issue. These are captured in: >>>> >>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>> >>>> We need to make a decision on this issue and move forward with the >>>> I-D. At the meeting itself, I got the sense that option 3 >> was the one >>>> that had the least impact and easy to implement. >>>> >>>> Please consider this email as a consensus call for issue 93. The >>>> problem and choices are as follows (based on Vijay's slides): >>>> >>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT >> traversal. The >>>> encapculations are either: >>>> - IPv6-in-UDP-over-IPv4 >>>> - IPv4-in-UDP-over-IPv4 >>>> There is a need (or I guess desirable) to indicate the type of >>>> protocol being encapsulated in the UDP header. >>>> >>>> Choices are: >>>> 1. Parse the protocol header following the UDP header >>>> 2. Reserve a UDP port for each protocol header (i.e one >> UDP port for >>>> IPv6-in-UDP-over-IPv4 and another for >> IPv4-in-UDP-over-IPv4 etc.) >>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>>> 4. Encapsulated protocol header type is indicated in the BU message >>>> >>>> Pros and cons of these choices are in the slides that were >> presented >>>> at IETF68 (see URL above). >>>> >>>> Please provide your opinions and comments by May 15th, 07 >> on the MIP6 >>>> mailing list. >>>> >>>> -Raj >>>> >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 10:25:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9aS-0007ed-Gc; Thu, 10 May 2007 10:25:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9aR-0007eS-K8; Thu, 10 May 2007 10:25:43 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9aP-0000hM-4Q; Thu, 10 May 2007 10:25:43 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070510142538.GPXT25724.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Thu, 10 May 2007 14:25:38 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta05sl.mx.bigpond.com with ESMTP id <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005>; Thu, 10 May 2007 14:25:37 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 00:25:24 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfA= In-Reply-To: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > All protocol packets have payload qualifiers. > Looking at the payload to determine the packet type, > I'm not sure that is the followed convention. The protocol > type in the IP header, or the next option type in > the IPv6 headers, the protocol type in gre header, > or the 3519 Data Message, all follow this style of > containment. We can certainly switch by looking at > the 1st byte of the IP packet, but that limits the payload > to IP. We cannot carry GRE header over UDP tomorrow, => Why do we want GRE in MIP6? Are we going to tunnel GRE packets to hosts? IPv6 in general doesn't need GRE, we sure don't have any overlapping address problems... You might be thinking about PMIP here, but you can extend things specifically for that purpose quite easily. The base standard certainly shouldn't be compromised for PMIP. > or we cant define a separate control message such as > a keepalive message. => I thought I answered that point in the last email. Hesham Why not use a simple type header > and provide the room for carrying new payloads ? > > This may not address your specific comment on the > user proc parsing of the packet. But, my comment > is on the need for a TLV header. > > Sri > > > > > > > > > > -----Original Message----- > > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > > Sent: Thursday, May 10, 2007 12:12 AM > > To: Vijay Devarapalli > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > > close issue 93 > > > > Hi Vijay, > > > > In your slide, you said "If DS-MIPv6 is not implemented in the > > kernel, then it is still an issue" > > for the option-1. > > > > What kind of problem is there? > > I believer an userland program can parse the headers > > and process the received packets accordingly. > > > > regards > > ryuji > > > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > > > Hi, > > > > > > My preference is for option 4. I know many preferred option > > > 3, but it adds a 4 byte per-packet overhead for each tunneled > > > data packet. I wish we can avoid that. > > > > > > Vijay > > > > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Tuesday, May 08, 2007 2:16 PM > > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > > >> > > >> > > >> Hello, > > >> > > >> The DS-MIP6 I-D > still has > > >> issue 93 open. This was discussed at IETF68. Vijay presented 4 > > >> options > > >> to solve the issue. These are captured in: > > >> > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > >> > > >> We need to make a decision on this issue and move > forward with the > > >> I-D. At the meeting itself, I got the sense that option 3 > > was the one > > >> that had the least impact and easy to implement. > > >> > > >> Please consider this email as a consensus call for issue 93. The > > >> problem and choices are as follows (based on Vijay's slides): > > >> > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > traversal. The > > >> encapculations are either: > > >> - IPv6-in-UDP-over-IPv4 > > >> - IPv4-in-UDP-over-IPv4 > > >> There is a need (or I guess desirable) to indicate the type of > > >> protocol being encapsulated in the UDP header. > > >> > > >> Choices are: > > >> 1. Parse the protocol header following the UDP header > > >> 2. Reserve a UDP port for each protocol header (i.e one > > UDP port for > > >> IPv6-in-UDP-over-IPv4 and another for > > IPv4-in-UDP-over-IPv4 etc.) > > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > >> 4. Encapsulated protocol header type is indicated in > the BU message > > >> > > >> Pros and cons of these choices are in the slides that were > > presented > > >> at IETF68 (see URL above). > > >> > > >> Please provide your opinions and comments by May 15th, 07 > > on the MIP6 > > >> mailing list. > > >> > > >> -Raj > > >> > > >> > > >> _______________________________________________ > > >> 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 > > _______________________________________________ > 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 From mip6-bounces@ietf.org Thu May 10 14:52:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDkf-0000UR-MF; Thu, 10 May 2007 14:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDke-0000UJ-7q; Thu, 10 May 2007 14:52:32 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmDkc-0005yB-Uy; Thu, 10 May 2007 14:52:32 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 11:52:16 -0700 X-IronPort-AV: i="4.14,518,1170662400"; d="scan'208"; a="484963636:sNHT4469767730" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4AIqFCo004271; Thu, 10 May 2007 11:52:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4AIqB0j029150; Thu, 10 May 2007 18:52:15 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 11:52:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 11:52:11 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5203D9CBD4@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABHx+jg From: "Kent Leung \(kleung\)" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-OriginalArrivalTime: 10 May 2007 18:52:12.0311 (UTC) FILETIME=[51C9CA70:01C79334] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=787; t=1178823135; x=1179687135; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=20=22Kent=20Leung=20\(kleung\)=22=20 |Subject:=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20call=20to=20close=2 0issue=2093 |Sender:=20; bh=5EGNv7sAcefTrp9191Tz4ujkAN66D+QigAf+lZD6En0=; b=QMNWT3kxSdWrNnkuQv8D0+H4iiJYMMFnKsn8aJROtcIwnkJDc0Wq6pZDZmE3E9V4ou5l0X0O +0/ixK7IsTc8HimGTak9ceK+Ue8X9+9a4O1T82SUkyYiTlJlbVV6D3DuUXHREYwIbWTIg/NFKf 9CEi4KwYT74O+yzIhuFD25ZIE=; Authentication-Results: sj-dkim-1; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj. I vote for #3. This method is the most flexible. It allows the inclusion of GRE support, which is used to segregate the IPv4 sessions within a tunnel. This feature is valuable to PMIPv6, which is dependant on DSMIP6 for IPv4 support. Other use case may also arise (maybe NEMO?) in the future. IMHO, it's better to provide an extensible framework. Kent=20 -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Tuesday, May 08, 2007 2:16 PM To: Mobile IPv6 Mailing List; nemo@ietf.org Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 Hello, The DS-MIP6 I-D still has issue 93 open. This was discussed at IETF68. Vijay presented 4 options to solve the issue.=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 15:00:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDsl-0007Mn-VO; Thu, 10 May 2007 15:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDsk-0007Md-7C; Thu, 10 May 2007 15:00:54 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmDsi-0006r9-UD; Thu, 10 May 2007 15:00:54 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4AJ0iA24548; Thu, 10 May 2007 19:00:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 14:00:36 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371142CE5A1@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfAAFUujYA== References: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, Please see comment inline. Regards, Ahmad =20 >=20 > > All protocol packets have payload qualifiers. > > Looking at the payload to determine the packet type, >=20 > I'm not sure that is the followed convention. The protocol >=20 > type in the IP header, or the next option type in > the IPv6=20 > headers, the protocol type in gre header, > or the 3519 Data=20 > Message, all follow this style of > containment. We can=20 > certainly switch by looking at > the 1st byte of the IP=20 > packet, but that limits the payload > to IP. We cannot carry=20 > GRE header over UDP tomorrow, >=20 > =3D> Why do we want GRE in MIP6? Are we going to tunnel GRE=20 > packets to hosts? > IPv6 in general doesn't need GRE, we sure don't have any=20 > overlapping address problems... >=20 > You might be thinking about PMIP here, but you can extend=20 > things specifically for that purpose quite easily. The base=20 > standard certainly shouldn't be compromised for PMIP. [Ahmad] Ok, But I believe it is more efficient if we choose an option (e.g. No. 3) which is flexible enough to address the current and possible (in-progress) future needs.=20 >=20 > > or we cant define a separate control message such as > a=20 > keepalive message.=20 >=20 > =3D> I thought I answered that point in the last email.=20 >=20 > Hesham >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 16:18:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmF5y-0005Tu-9d; Thu, 10 May 2007 16:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmF5w-0005SL-B2; Thu, 10 May 2007 16:18:36 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmF5u-0002uo-Rc; Thu, 10 May 2007 16:18:36 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AKIO8d018815; Thu, 10 May 2007 23:18:27 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:18:12 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 15:18:10 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 May 2007 20:18:09 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 10 May 2007 15:18:09 -0500 Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 From: Basavaraj Patil To: ext Hesham Soliman , "'Mobile IPv6 Mailing List'" , Message-ID: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAFi7P/Y= In-Reply-To: <20070509020325.QSUI1512.oaamta02ps.mx.bigpond.com@PC20005> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 May 2007 20:18:10.0587 (UTC) FILETIME=[545C3EB0:01C79340] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham, On 5/8/07 9:03 PM, "ext Hesham Soliman" wrote: > Hi Raj, > > At the meeting Sri (the author of the issue) and Kent said they didn't know > that a UDP port was already reserved. Once we cleared that, the rationale > for the issue was no longer applicable. I believe Sri said he wanted some > time to be sure before the issue is rejected. > More inline on the options: > > >> Choices are: >> 1. Parse the protocol header following the UDP header > > => This should be "parse the version field after the UDP header". This is > what's already in the draft and it works fine today with any UDP > encapsulation. Agree. So this option would impy: Do nothing. > >> 2. Reserve a UDP port for each protocol header (i.e one UDP port for >> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) > > => This isn't needed. Okay. > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > => This is what the issue suggested but the additional 4 bytes are > redundant. So are you okay with using the tunnel type message as has been done in RFC3519? Not sure what you are implying by saying that the 4 bytes are redundant in this context. > >> 4. Encapsulated protocol header type is indicated in the BU message > > => Again, not needed IMO. > > I think option 1 is the right option. There is no reason given for a change. Sure... If the encapsulated packets are only IPv4 or IPv6, you could parse the version field and figure out the encapsulated packet type. And as you have said on the list in another email, is there a need for encapsulating any other type of packets between the MN and HA in UDP? I think this is an unknown. GRE has been mentioned, but I agree that it is not generally between an MN and HA. I don't know if you have thought about this option from the NEMO perspective as well. After all this I-D is intended to address hosts and mobile routers. And the other thing is if you want to have some flexibility by introducing the 4 byte header to explicitly indicate the encapsulated packet type (akin to RFC3519) Some explicit reasons for why in the case of MIP6/NEMO would we want the 4 byte header to indicate the encapsulated packet type would be good. Reasons I have heard so far: 1. PMIP6 relies on DS-MIP6 for IPv4 support and hence encapsulation of packets other than IPv4/6 (eg. GRE) should be possible in which case the header would be useful 2. Flexibility for future use 3. Reuse 3519 (don't know if this was mentioned) It would be good to hear from the NEMO folks as well on this issue as we may be overly focused on just MIP6 MNs. -Raj > > Hesham > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 16:30:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFHk-000581-62; Thu, 10 May 2007 16:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFHj-00053A-5P; Thu, 10 May 2007 16:30:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmFHi-0004Nf-Ih; Thu, 10 May 2007 16:30:47 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 13:30:43 -0700 X-IronPort-AV: i="4.14,519,1170662400"; d="scan'208"; a="147296515:sNHT61638840" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4AKUgQr004795; Thu, 10 May 2007 13:30:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4AKUfEu016764; Thu, 10 May 2007 20:30:42 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 13:30:32 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 13:30:31 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" References: <001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 13:30:31 -0700 Message-ID: <00e801c79342$0e643000$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfAAGGqp8A== In-Reply-To: <20070510142537.KVZS7523.oaamta05sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 10 May 2007 20:30:32.0040 (UTC) FILETIME=[0E4CFE80:01C79342] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5991; t=1178829042; x=1179693042; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=L45mq37sObGlUTp9zoKyjvhSTYJL9E3eUtGpcqOwioQ=; b=nyBjJGSFba9zloGa0Y7MhadC5AktMesyM0mVMXO4RCqqs11McDVcc2F1BM6wvY/6UiqryOr2 Uq71sFQD+wbekyDKFUD1jueAO/U0d2AZy6d4z13sMo7hX84yZlDBbzFMBalVDQF7RQc237ynRl lleULIXAlSfHVjYxo5g0t55L0=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, > > All protocol packets have payload qualifiers. > > Looking at the payload to determine the packet type, > > I'm not sure that is the followed convention. The protocol > > type in the IP header, or the next option type in > > the IPv6 headers, the protocol type in gre header, > > or the 3519 Data Message, all follow this style of > > containment. We can certainly switch by looking at > > the 1st byte of the IP packet, but that limits the payload > > to IP. We cannot carry GRE header over UDP tomorrow, > > => Why do we want GRE in MIP6? Are we going to tunnel GRE > packets to hosts? > IPv6 in general doesn't need GRE, we sure don't have any > overlapping address > problems... > Agree, may not be useful for a pure MIP6 node, as the mode is in CCOA mode. But, if you enable NEMO, we need more flexibility on the marking of the MNP flows that go in the tunnel. > You might be thinking about PMIP here, but you can extend things > specifically for that purpose quite easily. The base standard > certainly > shouldn't be compromised for PMIP. > Sure. That's one use-case. PMIP leverages DSMIP6 and leaving a simple TLV wrapper will help in extensibility. I dont think it will compromise the base protocol, its just a simple wrapper, conventionally in all protocols, the prev header identifies the payload that follows. I agree from the perspective of the 3775, it may not be useful, but from 3963 or from PMIP6 perspective, it will be useful. You guys are doing this now, why not provide the hook as well. > > or we cant define a separate control message such as > > a keepalive message. > > => I thought I answered that point in the last email. > Sure. That's one way of building keepalives. > Hesham > > > > Why not use a simple type header > > and provide the room for carrying new payloads ? > > > > > This may not address your specific comment on the > > user proc parsing of the packet. But, my comment > > is on the need for a TLV header. > > > > Sri > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > > > Sent: Thursday, May 10, 2007 12:12 AM > > > To: Vijay Devarapalli > > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > > > close issue 93 > > > > > > Hi Vijay, > > > > > > In your slide, you said "If DS-MIPv6 is not implemented in the > > > kernel, then it is still an issue" > > > for the option-1. > > > > > > What kind of problem is there? > > > I believer an userland program can parse the headers > > > and process the received packets accordingly. > > > > > > regards > > > ryuji > > > > > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > > > > > Hi, > > > > > > > > My preference is for option 4. I know many preferred option > > > > 3, but it adds a 4 byte per-packet overhead for each tunneled > > > > data packet. I wish we can avoid that. > > > > > > > > Vijay > > > > > > > >> -----Original Message----- > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > >> Sent: Tuesday, May 08, 2007 2:16 PM > > > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > > > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > >> > > > >> > > > >> Hello, > > > >> > > > >> The DS-MIP6 I-D > > still has > > > >> issue 93 open. This was discussed at IETF68. Vijay > presented 4 > > > >> options > > > >> to solve the issue. These are captured in: > > > >> > > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > >> > > > >> We need to make a decision on this issue and move > > forward with the > > > >> I-D. At the meeting itself, I got the sense that option 3 > > > was the one > > > >> that had the least impact and easy to implement. > > > >> > > > >> Please consider this email as a consensus call for > issue 93. The > > > >> problem and choices are as follows (based on Vijay's slides): > > > >> > > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > traversal. The > > > >> encapculations are either: > > > >> - IPv6-in-UDP-over-IPv4 > > > >> - IPv4-in-UDP-over-IPv4 > > > >> There is a need (or I guess desirable) to indicate the type of > > > >> protocol being encapsulated in the UDP header. > > > >> > > > >> Choices are: > > > >> 1. Parse the protocol header following the UDP header > > > >> 2. Reserve a UDP port for each protocol header (i.e one > > > UDP port for > > > >> IPv6-in-UDP-over-IPv4 and another for > > > IPv4-in-UDP-over-IPv4 etc.) > > > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > > >> 4. Encapsulated protocol header type is indicated in > > the BU message > > > >> > > > >> Pros and cons of these choices are in the slides that were > > > presented > > > >> at IETF68 (see URL above). > > > >> > > > >> Please provide your opinions and comments by May 15th, 07 > > > on the MIP6 > > > >> mailing list. > > > >> > > > >> -Raj > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > _______________________________________________ > > 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 16:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFLU-0007Ma-PW; Thu, 10 May 2007 16:34:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFLU-0007MS-2q; Thu, 10 May 2007 16:34:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmFLS-0004nO-PR; Thu, 10 May 2007 16:34:40 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 13:34:38 -0700 X-IronPort-AV: i="4.14,519,1170662400"; d="scan'208"; a="147298059:sNHT42396489" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4AKYcmr010659; Thu, 10 May 2007 13:34:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4AKYbZT009635; Thu, 10 May 2007 20:34:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 13:34:37 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 13:34:36 -0700 From: "Sri Gundavelli" To: "'RYUJI WAKIKAWA'" References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com><001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 13:34:36 -0700 Message-ID: <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceS5t/naLlqAWPCTRGzcTYFZ/7GZgAWzU5g In-Reply-To: <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 10 May 2007 20:34:37.0290 (UTC) FILETIME=[A07B2CA0:01C79342] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1142; t=1178829278; x=1179693278; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=m2MgILCmhuj8mIABzK9Fi7w9xXxAFSWBphFfCdjYpEw=; b=toEhY3qVIIaQxr7hqxeT/Y2drZrFxs0tD4fi3TTJkiU0aVLRxw27LMbmtYL+2PO+G1RiKFCK wDTU3w8+c5SRqM9/r/WmO6gmulpNf0JFKD8UV6IwEkEDy24RgFwBbhxi7L8ZU5FCpFrO4NopEz OHoFPz/beVdRNbJoH5zjkQ+EU=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ryuji, > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > Sent: Thursday, May 10, 2007 2:37 AM > To: Sri Gundavelli > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Vijay Devarapalli' > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > Hi Sri, > > The problem is not yet in DSMIP, because DSMIP only supports > IPv4 and > IPv6 packets in UDP. > As Hesham said, the receiver can simply check the followed header > (IP) and can determine whether IPv4 or IPv6. > Its not just about the streams. We need GRE tunnel header for various reasons, when ever there are multiple mobile node or LFN streams, the GRE header for its key carrying capability etc. will be useful, its also useful for PMIP6. So, its a good idea to do the right thing of putting a tiny header as all protocols do. > I am fine with 4 bytes if there is strong reason for that, > however I want to see what kind of additional payloads is considered > in the future. Ok. Reasons are beyond the MIP6 node's usage, its for PMIP6 and NEMO. Will be useful. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 22:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmKr6-0005Be-8b; Thu, 10 May 2007 22:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmKr4-0005BW-T9; Thu, 10 May 2007 22:27:38 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmKr4-0002ip-3o; Thu, 10 May 2007 22:27:38 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070511022735.FEJM25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Fri, 11 May 2007 02:27:35 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005>; Fri, 11 May 2007 02:27:34 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 12:27:32 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfAAGGqp8AAMqgog In-Reply-To: <00e801c79342$0e643000$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Agree, may not be useful for a pure MIP6 node, as the mode > is in CCOA mode. But, if you enable NEMO, we need more > flexibility on the marking of the MNP flows that go in the > tunnel. => Could you elaborate on the nemo aspect you mention above? I don't understand why nemo is helped by this? Hesham > > > You might be thinking about PMIP here, but you can extend things > > specifically for that purpose quite easily. The base standard > > certainly > > shouldn't be compromised for PMIP. > > > > Sure. That's one use-case. PMIP leverages DSMIP6 and leaving > a simple TLV wrapper will help in extensibility. I dont think > it will compromise the base protocol, its just a simple wrapper, > conventionally in all protocols, the prev header identifies the > payload that follows. > > I agree from the perspective of the 3775, it may not be useful, > but from 3963 or from PMIP6 perspective, it will be useful. > You guys are doing this now, why not provide the hook as well. > > > > > or we cant define a separate control message such as > > > a keepalive message. > > > > => I thought I answered that point in the last email. > > > > Sure. That's one way of building keepalives. > > > > Hesham > > > > > > > > Why not use a simple type header > > > and provide the room for carrying new payloads ? > > > > > > > > This may not address your specific comment on the > > > user proc parsing of the packet. But, my comment > > > is on the need for a TLV header. > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > > > > Sent: Thursday, May 10, 2007 12:12 AM > > > > To: Vijay Devarapalli > > > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > > > > close issue 93 > > > > > > > > Hi Vijay, > > > > > > > > In your slide, you said "If DS-MIPv6 is not > implemented in the > > > > kernel, then it is still an issue" > > > > for the option-1. > > > > > > > > What kind of problem is there? > > > > I believer an userland program can parse the headers > > > > and process the received packets accordingly. > > > > > > > > regards > > > > ryuji > > > > > > > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > > > > > > > Hi, > > > > > > > > > > My preference is for option 4. I know many preferred option > > > > > 3, but it adds a 4 byte per-packet overhead for > each tunneled > > > > > data packet. I wish we can avoid that. > > > > > > > > > > Vijay > > > > > > > > > >> -----Original Message----- > > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >> Sent: Tuesday, May 08, 2007 2:16 PM > > > > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > > > > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > > >> > > > > >> > > > > >> Hello, > > > > >> > > > > >> The DS-MIP6 I-D > > > still has > > > > >> issue 93 open. This was discussed at IETF68. Vijay > > presented 4 > > > > >> options > > > > >> to solve the issue. These are captured in: > > > > >> > > > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > > >> > > > > >> We need to make a decision on this issue and move > > > forward with the > > > > >> I-D. At the meeting itself, I got the sense that option 3 > > > > was the one > > > > >> that had the least impact and easy to implement. > > > > >> > > > > >> Please consider this email as a consensus call for > > issue 93. The > > > > >> problem and choices are as follows (based on > Vijay's slides): > > > > >> > > > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > > traversal. The > > > > >> encapculations are either: > > > > >> - IPv6-in-UDP-over-IPv4 > > > > >> - IPv4-in-UDP-over-IPv4 > > > > >> There is a need (or I guess desirable) to indicate > the type of > > > > >> protocol being encapsulated in the UDP header. > > > > >> > > > > >> Choices are: > > > > >> 1. Parse the protocol header following the UDP header > > > > >> 2. Reserve a UDP port for each protocol header (i.e one > > > > UDP port for > > > > >> IPv6-in-UDP-over-IPv4 and another for > > > > IPv4-in-UDP-over-IPv4 etc.) > > > > >> 3. One reserved UDP port and a DS-MIP6 "tunnel > type message" > > > > >> 4. Encapsulated protocol header type is indicated in > > > the BU message > > > > >> > > > > >> Pros and cons of these choices are in the slides that were > > > > presented > > > > >> at IETF68 (see URL above). > > > > >> > > > > >> Please provide your opinions and comments by May 15th, 07 > > > > on the MIP6 > > > > >> mailing list. > > > > >> > > > > >> -Raj > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> 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 > > > > > > _______________________________________________ > > > 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 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 10 23:42:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmM1m-0002Qz-TL; Thu, 10 May 2007 23:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmM1m-0002Qr-6G; Thu, 10 May 2007 23:42:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmM1k-00051X-JR; Thu, 10 May 2007 23:42:46 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 20:42:44 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="485073156:sNHT54050090" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4B3ghie016744; Thu, 10 May 2007 20:42:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4B3ghaI011078; Fri, 11 May 2007 03:42:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 20:42:43 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 20:42:42 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" References: <00e801c79342$0e643000$d4f6200a@amer.cisco.com> <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 20:42:42 -0700 Message-ID: <014701c7937e$6e6a2180$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceS0ptSnQee4LarQceRdeHXVPsPXAAABz3AAAMxzfAAGGqp8AAMqgogAAIg/aA= In-Reply-To: <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 03:42:42.0680 (UTC) FILETIME=[6E2AA780:01C7937E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6924; t=1178854963; x=1179718963; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=QENSyye3e7DAaYRNJ6Kp1FuJUP9Qf+UHQeap5dGX/HI=; b=rKtQmAtSdoZylaUt3WN7SiFnRXb6TQU9MYTvFM9xfP70aQHiVUoeYNsfnGdeUK6z4FO81Nlf YD75fL5kvv4/cJ32gi59OmnZgoiOQp6GnAsf5Bw0K42zuEF+52qa2MW4; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham: > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, May 10, 2007 7:28 PM > To: 'Sri Gundavelli' > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > > > > Agree, may not be useful for a pure MIP6 node, as the mode > > is in CCOA mode. But, if you enable NEMO, we need more > > flexibility on the marking of the MNP flows that go in the > > tunnel. > > => Could you elaborate on the nemo aspect you mention above? I don't > understand why nemo is helped by this? > We have some use cases where we use the GRE key to tag certain MNP flows and the tunnel peers use these keys as a form of a selector for differential treatment. Its a color code. The seq number and key fields in the GRE header are used. So support for carrying the GRE header over UDP will be possible with the TLV header. Thanks Sri > > > > > > You might be thinking about PMIP here, but you can extend things > > > specifically for that purpose quite easily. The base standard > > > certainly > > > shouldn't be compromised for PMIP. > > > > > > > Sure. That's one use-case. PMIP leverages DSMIP6 and leaving > > a simple TLV wrapper will help in extensibility. I dont think > > it will compromise the base protocol, its just a simple wrapper, > > conventionally in all protocols, the prev header identifies the > > payload that follows. > > > > I agree from the perspective of the 3775, it may not be useful, > > but from 3963 or from PMIP6 perspective, it will be useful. > > You guys are doing this now, why not provide the hook as well. > > > > > > > > or we cant define a separate control message such as > > > > a keepalive message. > > > > > > => I thought I answered that point in the last email. > > > > > > > Sure. That's one way of building keepalives. > > > > > > > Hesham > > > > > > > > > > > > Why not use a simple type header > > > > and provide the room for carrying new payloads ? > > > > > > > > > > > This may not address your specific comment on the > > > > user proc parsing of the packet. But, my comment > > > > is on the need for a TLV header. > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > > > > > Sent: Thursday, May 10, 2007 12:12 AM > > > > > To: Vijay Devarapalli > > > > > Cc: nemo@ietf.org; Mobile IPv6 Mailing List > > > > > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > > > > > close issue 93 > > > > > > > > > > Hi Vijay, > > > > > > > > > > In your slide, you said "If DS-MIPv6 is not > > implemented in the > > > > > kernel, then it is still an issue" > > > > > for the option-1. > > > > > > > > > > What kind of problem is there? > > > > > I believer an userland program can parse the headers > > > > > and process the received packets accordingly. > > > > > > > > > > regards > > > > > ryuji > > > > > > > > > > On 2007/05/09, at 10:20, Vijay Devarapalli wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > My preference is for option 4. I know many > preferred option > > > > > > 3, but it adds a 4 byte per-packet overhead for > > each tunneled > > > > > > data packet. I wish we can avoid that. > > > > > > > > > > > > Vijay > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > > >> Sent: Tuesday, May 08, 2007 2:16 PM > > > > > >> To: Mobile IPv6 Mailing List; nemo@ietf.org > > > > > >> Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > > > >> > > > > > >> > > > > > >> Hello, > > > > > >> > > > > > >> The DS-MIP6 I-D > > > > still has > > > > > >> issue 93 open. This was discussed at IETF68. Vijay > > > presented 4 > > > > > >> options > > > > > >> to solve the issue. These are captured in: > > > > > >> > > > > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > > > >> > > > > > >> We need to make a decision on this issue and move > > > > forward with the > > > > > >> I-D. At the meeting itself, I got the sense that > option 3 > > > > > was the one > > > > > >> that had the least impact and easy to implement. > > > > > >> > > > > > >> Please consider this email as a consensus call for > > > issue 93. The > > > > > >> problem and choices are as follows (based on > > Vijay's slides): > > > > > >> > > > > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > > > traversal. The > > > > > >> encapculations are either: > > > > > >> - IPv6-in-UDP-over-IPv4 > > > > > >> - IPv4-in-UDP-over-IPv4 > > > > > >> There is a need (or I guess desirable) to indicate > > the type of > > > > > >> protocol being encapsulated in the UDP header. > > > > > >> > > > > > >> Choices are: > > > > > >> 1. Parse the protocol header following the UDP header > > > > > >> 2. Reserve a UDP port for each protocol header (i.e one > > > > > UDP port for > > > > > >> IPv6-in-UDP-over-IPv4 and another for > > > > > IPv4-in-UDP-over-IPv4 etc.) > > > > > >> 3. One reserved UDP port and a DS-MIP6 "tunnel > > type message" > > > > > >> 4. Encapsulated protocol header type is indicated in > > > > the BU message > > > > > >> > > > > > >> Pros and cons of these choices are in the slides > that were > > > > > presented > > > > > >> at IETF68 (see URL above). > > > > > >> > > > > > >> Please provide your opinions and comments by May > 15th, 07 > > > > > on the MIP6 > > > > > >> mailing list. > > > > > >> > > > > > >> -Raj > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> 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 > > > > > > > > _______________________________________________ > > > > 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 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 00:03:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMM7-0000Re-MP; Fri, 11 May 2007 00:03:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMM6-0000RR-QA for mip6@ietf.org; Fri, 11 May 2007 00:03:46 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmMM6-0006wl-Ip for mip6@ietf.org; Fri, 11 May 2007 00:03:46 -0400 Received: by nz-out-0506.google.com with SMTP id z6so928134nzd for ; Thu, 10 May 2007 21:03:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=X4vKykJ6SjZoloqu7NPDmrT1j8rLZr6saNYdtYkpq+bFhE1Ge/pZFdULnRZ3gj+nKkPgUcgIBjvF25Mib4KtzDKEAgI6twTc/8VbGRw4wy5YfXUTIXaaaoghfaoAAdixmJaBGJBKRwHFME/X3nYYDig7fhj33oK8fRCyEn3EFYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=T8TgvfNOZN8aJlHLkYfVyhVQYxcUaFhpP5rjtXx0Cy75cBou4wuvsdV18Q5ApaYmQgW7DO0RRMkRDf2U7SWjJNKeBeb6hqsrdqGmTm4Ik2OWX18BdkSsJXtp3jgL3OK2WkL4lPUfWKPcTOI+mnCIL3EZdJJ+wCfAEiK29TdovxE= Received: by 10.114.181.1 with SMTP id d1mr850333waf.1178856226037; Thu, 10 May 2007 21:03:46 -0700 (PDT) Received: from ?203.178.143.206? ( [203.178.143.206]) by mx.google.com with ESMTP id m28sm91566poh.2007.05.10.21.03.39; Thu, 10 May 2007 21:03:44 -0700 (PDT) In-Reply-To: <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com><001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <63944404-0BDD-41D3-90D5-1D3C8B8B52E4@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 13:03:32 +0900 To: Sri Gundavelli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, OK, if WG agree to support other payload (GRE) in UDP encapsulation, we need to have some bits indicating the header type after the UDP header. However, this consensus call is hard to make, because the current DSMIP only supports IPv4/IPv6 tunnel and not GRE. In the current DSMIP spec, it is obvious that we need nothing here. If GRE is considered, we need to pick one from choices 2-4. Is this consensus call whether we support additional tunnel in UDP? :-p regards, ryuji On 2007/05/11, at 5:34, Sri Gundavelli wrote: > Hi Ryuji, > > >> -----Original Message----- >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >> Sent: Thursday, May 10, 2007 2:37 AM >> To: Sri Gundavelli >> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Vijay Devarapalli' >> Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to >> close issue 93 >> >> Hi Sri, >> >> The problem is not yet in DSMIP, because DSMIP only supports >> IPv4 and >> IPv6 packets in UDP. >> As Hesham said, the receiver can simply check the followed header >> (IP) and can determine whether IPv4 or IPv6. >> > > Its not just about the streams. We need GRE tunnel header for > various reasons, when ever there are multiple mobile node or LFN > streams, the GRE header for its key carrying capability etc. will > be useful, its also useful for PMIP6. So, its a good idea to > do the right thing of putting a tiny header as all protocols do. > > >> I am fine with 4 bytes if there is strong reason for that, >> however I want to see what kind of additional payloads is considered >> in the future. > > Ok. Reasons are beyond the MIP6 node's usage, its for PMIP6 and NEMO. > Will be useful. > > Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 00:08:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMQO-0001SF-0r; Fri, 11 May 2007 00:08:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMQM-0001S4-Fg; Fri, 11 May 2007 00:08:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmMQL-0007rY-4d; Fri, 11 May 2007 00:08:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 21:08:09 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="485074852:sNHT46510378" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4B4884O031002; Thu, 10 May 2007 21:08:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B47k2I004663; Fri, 11 May 2007 04:08:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 21:08:04 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 21:08:04 -0700 From: "Sri Gundavelli" To: "'RYUJI WAKIKAWA'" References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com><001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> <63944404-0BDD-41D3-90D5-1D3C8B8B52E4@gmail.com> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 21:08:04 -0700 Message-ID: <014e01c79381$f96b46d0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTgWIk3Z0yy58fQBu2OkoQEoZrEAAAE+cg In-Reply-To: <63944404-0BDD-41D3-90D5-1D3C8B8B52E4@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 04:08:04.0328 (UTC) FILETIME=[F923B680:01C79381] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2427; t=1178856488; x=1179720488; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20ca ll=20to=20close=20issue=2093 |Sender:=20; bh=FXudBHboiKT3K5KP+PX4KbhEda7a4YCdz8j7T6lCvOY=; b=DIch1Vou0XgkaFNmRAsNqNcDiaZRo1NIAhep2M8qB+cVQqsdmdnGSDLq6DjVGJQsl8q1TO+w GEufyVC54a59eUtI0f05C0XAAGomydzY9F7UAkudTeg6/78YXkifx6fd; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ryuji: Ok. Fair enough. Then I'd vote for Option#3. Having a thin header or a prev header identifying the next header is the followed convention. So, TLV format gives me that and I'd like to stick with that approach. I vote for option #3. Sri > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > Sent: Thursday, May 10, 2007 9:04 PM > To: Sri Gundavelli > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Vijay Devarapalli' > Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > close issue 93 > > Hi Sri, > > OK, if WG agree to support other payload (GRE) in UDP encapsulation, > we need to have some bits indicating the header type after the UDP > header. > > However, this consensus call is hard to make, because the current > DSMIP only > supports IPv4/IPv6 tunnel and not GRE. > In the current DSMIP spec, it is obvious that we need nothing here. > If GRE is considered, we need to pick one from choices 2-4. > > Is this consensus call whether we support additional tunnel > in UDP? :-p > > regards, > ryuji > > > > On 2007/05/11, at 5:34, Sri Gundavelli wrote: > > > Hi Ryuji, > > > > > >> -----Original Message----- > >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > >> Sent: Thursday, May 10, 2007 2:37 AM > >> To: Sri Gundavelli > >> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List'; 'Vijay Devarapalli' > >> Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to > >> close issue 93 > >> > >> Hi Sri, > >> > >> The problem is not yet in DSMIP, because DSMIP only supports > >> IPv4 and > >> IPv6 packets in UDP. > >> As Hesham said, the receiver can simply check the followed header > >> (IP) and can determine whether IPv4 or IPv6. > >> > > > > Its not just about the streams. We need GRE tunnel header for > > various reasons, when ever there are multiple mobile node or LFN > > streams, the GRE header for its key carrying capability etc. will > > be useful, its also useful for PMIP6. So, its a good idea to > > do the right thing of putting a tiny header as all protocols do. > > > > > >> I am fine with 4 bytes if there is strong reason for that, > >> however I want to see what kind of additional payloads is > considered > >> in the future. > > > > Ok. Reasons are beyond the MIP6 node's usage, its for PMIP6 > and NEMO. > > Will be useful. > > > > Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 00:14:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMWL-0007LI-VX; Fri, 11 May 2007 00:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMWJ-0007JV-Um; Fri, 11 May 2007 00:14:19 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmMWI-0000OL-M0; Fri, 11 May 2007 00:14:19 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4B4EGh04148; Fri, 11 May 2007 04:14:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 10 May 2007 23:14:14 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371142CEDF9@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABzG+cg References: From: "Ahmad Muhanna" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I hinted in several emails to option #3.=20 However, since the consensus call requires clear answers, I would like to vote for option # 3. Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, May 08, 2007 4:16 PM > To: Mobile IPv6 Mailing List; nemo@ietf.org > Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 >=20 > Hello, >=20 > The DS-MIP6 I-D =20 > still has issue 93 open. This was discussed at IETF68. Vijay=20 > presented 4 options to solve the issue. These are captured in: >=20 > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >=20 > We need to make a decision on this issue and move forward=20 > with the I-D. At the meeting itself, I got the sense that=20 > option 3 was the one that had the least impact and easy to implement. >=20 > Please consider this email as a consensus call for issue 93.=20 > The problem and choices are as follows (based on Vijay's slides): >=20 > Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 > traversal. The encapculations are either: > - IPv6-in-UDP-over-IPv4 > - IPv4-in-UDP-over-IPv4 > There is a need (or I guess desirable) to indicate the type=20 > of protocol being encapsulated in the UDP header. >=20 > Choices are: > 1. Parse the protocol header following the UDP header 2.=20 > Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for=20 > IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a=20 > DS-MIP6 "tunnel type message" > 4. Encapsulated protocol header type is indicated in the BU message >=20 > Pros and cons of these choices are in the slides that were=20 > presented at IETF68 (see URL above). >=20 > Please provide your opinions and comments by May 15th, 07 on=20 > the MIP6 mailing list. >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 01:15:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNTf-0003Pb-1r; Fri, 11 May 2007 01:15:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNTd-0003PB-2O; Fri, 11 May 2007 01:15:37 -0400 Received: from mx05.syd.iprimus.net.au ([210.50.30.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNTb-0006HS-27; Fri, 11 May 2007 01:15:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACuZQ0bTG2yO/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.14,520,1170594000"; d="dat'59?scan'59,208,59";a="45771896" Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp05.syd.iprimus.net.au with ESMTP; 11 May 2007 15:15:15 +1000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 15:15:09 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C793DF.2A72B8A0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAFi7P/YAEg5cQA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-MS-TNEF-Correlator: 00000000660B30941AE58D429C64D7B799B4C29B844F2600 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C793DF.2A72B8A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > >> Choices are: > >> 1. Parse the protocol header following the UDP header > > > > => This should be "parse the version field after the UDP > header". This is > > what's already in the draft and it works fine today with any UDP > > encapsulation. > > Agree. So this option would impy: Do nothing. => Yes. > >> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > > > > => This is what the issue suggested but the additional 4 bytes are > > redundant. > > So are you okay with using the tunnel type message as has > been done in > RFC3519? Not sure what you are implying by saying that the 4 > bytes are > redundant in this context. => I meant that they are redundant because they have no justification for the operation of the spec. The rationale for the suggestion was that it was not really possible (or difficult) to tell whether the following packet was IPv4 or IPv6 if the implementation is in user space; and that it was diffcult to know the packet length. However, after we discussed this, it turned out that none of these issues are true, so I don't see why we need to add another 4 bytes to every packet. > > > > >> 4. Encapsulated protocol header type is indicated in the > BU message > > > > => Again, not needed IMO. > > > > I think option 1 is the right option. There is no reason > given for a change. > > Sure... If the encapsulated packets are only IPv4 or IPv6, > you could parse > the version field and figure out the encapsulated packet > type. And as you > have said on the list in another email, is there a need for > encapsulating > any other type of packets between the MN and HA in UDP? I > think this is an > unknown. GRE has been mentioned, but I agree that it is not generally > between an MN and HA. I don't know if you have thought about > this option > from the NEMO perspective as well. After all this I-D is > intended to address > hosts and mobile routers. => Sure, if there is something specific for nemo then we have to address it. I still don't know what that is though. I'd appreciate it if someone can explain it. And the other thing is if you want > to have some > flexibility by introducing the 4 byte header to explicitly > indicate the > encapsulated packet type (akin to RFC3519) > > Some explicit reasons for why in the case of MIP6/NEMO would > we want the 4 > byte header to indicate the encapsulated packet type would be good. > => Yes. > Reasons I have heard so far: > 1. PMIP6 relies on DS-MIP6 for IPv4 support and hence > encapsulation of > packets other than IPv4/6 (eg. GRE) should be possible in > which case the > header would be useful => I heard that too, but I don't know why we should add more overhead for every host and router just so PMIP might use GRE, unless we want to make MIP look like it's more wasteful. Also, I don't understand why GRE has to follow UDP and not run after the IP header? I need to re-read GRE to see if that's possible. > 2. Flexibility for future use > 3. Reuse 3519 (don't know if this was mentioned) => what do you mean by "reuse 3519"? You mean "make it look like 3519"? That's not a reason though is it? Hesham ------=_NextPart_000_000B_01C793DF.2A72B8A0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgoFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQYABwABAAAAAAAAAQOQBgCcCwAAJAAAAAsAAgABAAAAAwAmAAAA AAALACsAAAAAAAMALgAAAAAAAgExAAEAAAAYAAAAAAAAAGYLMJQa5Y1CnGTXt5m0wptETyYAHgBw AAEAAAAxAAAAW01pcDZdIERTLU1JUDY6IENvbnNlbnN1cyBjYWxsIHRvIGNsb3NlIGlzc3VlIDkz AAAAAAIBcQABAAAAJQAAAAHHkbYhxWB0ZzH9qRHblK0AESTVDYgACdEqIABYuz/2ABIOXEAAAAAL AAEOAAAAAAIBCg4BAAAAGAAAAAAAAABmCzCUGuWNQpxk17eZtMKbwoAAAAMAFA4BAAAAHgAoDgEA AAAnAAAAMDAwMDAwMDYBSGVzaGFtQGVsZXZhdGVtb2JpbGUuY29tAVdvcmsAAB4AKQ4BAAAAJwAA ADAwMDAwMDA2AUhlc2hhbUBlbGV2YXRlbW9iaWxlLmNvbQFXb3JrAAACARQ6AQAAABAAAACZlyk5 R4KuQZdS6xPkY33YAwDeP59OAAADAAlZAQAAAAsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAA AAAAAwAEgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAA AAAGhQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAggAggBgAAAAAAwAAA AAAAAEYAAAAADoUAAAAAAAADACSACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAPoAIIAYA AAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwAfDgEAAAACAfgPAQAAABAAAABmCzCUGuWNQpxk17eZ tMKbAgH6DwEAAAAQAAAAZgswlBrljUKcZNe3mbTCmwMA/g8FAAAAAgEJEAEAAADhBwAA3QcAAEIP AABMWkZ1ulM5lQMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IR JQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQ8wsJAWQz NhZQC6YK4wqEGQqAID4dsB3AQ2hvJw3gB5EKwGU6HVoxLkQgUBPyIHRoIABwqQNgdG8XkSAgMGEE gZogAhBsF7AD8G5nIBN4VURQIOUdWBzlI0M9SR3AVGgEACBzHiB10GxkIGIgACIKsR/1fnYEkACQ AiAhUAiQJQFh3wGAEoEiBh1XIPQiH6Akc0sEACLpdxPgdCcecWw7GCAhEHkpMAOgICJkcqsm8R6A biUQaQVAdwWwtmsEICaQbiABBHBhKuB/A/AgICvBKuAiQSLpCfBj+GFwcyTwKjAmUR+gHVfNHVdB CcIfoFNvIBEkkT5vBTAmUixAJPIHcHB56DogRDFQbiCAJIAh0HYuHPokQVkHkDObHbQz3R+gTyzB GCAUEHImECUQLSJCcBfBK8NhMuBTLRBNSVA2JVB0dW5jLMADIHR5cCAAB4Fz8GFnZSIi7yP7JJEq Ek8gEwQBClAksHVnOYBz2w6wJRF1O/QhEGQsECZR6QdAIDQlIHkOsB5zObn/GCE4gC0QAjAvnx2x MUEekawgeQhgMbBrLSZ1AJD/IdU4fzmAHoAEIBPgBCEdZn8lMAnwK2ACIDwxC5AdZlKARkMzNTE5 PwewfyCAPKFB8TvDQiJB4jKRbP55IcI+oCSwLSAhxDvlPoD/RVg+vz/nKvQkkQWgAjAOwf0znkk5 IU0SSlYq4EHiTLj/JTAu4EMAIAMq4BPgJhAzEfwgakMAL1AmkC7gMeMCEE8nNDHABJBTFG9mIBNz /TkAYyjSNkEvQwdAIABTdv88tTHzROFKUywSROEzITZRbwdASVA3IQQQaQJgIAAonwWxPfABIA3g JPB0KSzh/yAQJrADICoQFCAgMCc0IWi5CrBjaxQgV2M4IHY+gL8FsV0xOEAGkDwESTFlB4D/AjBT FCkSA6BRgQXAVQAA0HxlOyvDV7pZ8lpCWpJr/zMgB+AgI1yUVhAh0CAgH6DqSCGgZSYRLCblY+BZ 4f8E8EMAFBBgogQAZDAsEUOg/wSgNsEIYE+lMyAswVSUH/G3PFMecyAQcgpQZDBzMVD7T0BGMSdH 4QngKgEtMVJB/wngYKFBwT3gK8EzMRKBPoZ/WqFj8lkBXJM0zjm/HbQ0/R+gRS7XNsEgbjjjX2M9 8M9TATbBKwUdV0JVOSZuH38j9jDQC3FkMFhyamI2wUm8TU8zlXSuT0AzQmsxts4xO4IgIgUQZ2gF QDHEf1VDSPJYUliiaQADoR1mZ/5pJhBTVDfAE9Eh0DEQbY/7BgBIES5/QE8wVKQuyHBS/1yTaEQC IFjxXTpkMB1XQiJ/BaAk8iVzHVcl3yvDJpBnf0gSZoR/31yjhDg48R+gQb83kgQgQiEn2FIiOWBp ZmF9KxRsBABNM2smXrALcGz/ZcF5s0HxN8BqY1NyHVcuyf8h0B1XLaJrRDjjVJGAxiUwTnRj4EYB ICJNTivDSP5BKvIiQUegT0CEOXjSMXM/JJEAcB1XQ7BiQi+BR1L+RUUDReNewiZRCYBkMD1S/09A OXAJ0Vene1MFQDmALMD/K4BY4UVZkeQDkZKHf2FpRf9iQ14BQiJSEyAgCGB6MgGgP2aCk8oxph1X A1IgE05F/3cAcHAmIVURL1BSMUThY+AfIYCJIScDWNExZEktRP87gh1XC4AOsCvgaoc2YSlY3x4g PQCVEiUQBGBiAxA2Qf9mgSYhQHY0B38CZcFUo3sk/2kAB4AzQ1TzUtJTYyzABGD/IBIyESAAnWSl JywBnAJSsX9a8ZxJO8VX0leSndJ/YSf9JtFwIGCqsXAxmPNUoKny/0ZCLuADoA7AC1OtIzTaiUL/ U7NbVSHCKRKdBFdwTSGEON8xUIp0qgGf2FYQeFlgAxD/LBAq4EmxpIEDYEAAqsAh1f8+hHEHbDGy EQ3gLBBY8aP5H3IkIBKOP4eaOOMoYWv3KwIxUEc1KX3vMTEHgLqH/3ulLIEFsWnyKwUu4B/xVJH9 OBIvoPMyNB1XZLG1Y0qjf0sLuem72r0fvicyNCUxZ95vBHB93jQPHTlSwdVPQO9SEyDxCyBo8mYK wB7IH5L/OBMYIIuAB5EmYTfmU3JdM/8vELBAN0arwR5Qji8vNFSBXx1XgMa0BgORXTIvOEAo/mUz gJZiWoAkyFknKwHEuH8kgBPQwyS8aiD1yfdRgWb/JPBOX850SlTKkJfWrftqE/8kxWriBGCBUiYR IPJTY2xU/6ZCK8OnVFKDaPLQAjkgeiP/UYKWcWQwQ7BWEAQRxUcxUP8AwFyww6JjMMqQePCLgOYR fywQKlHgk1dxDrDcIYkhbP9pAGQwaTZAESYhAZAr4Wny/5Z2WqEhZCIzK9JYc0OwJunf47Eg9JOC amYYIC0qopZjv1qhabJeAyozWSY0zjIfoP5Gt6lTctwgZhHb0x1XNfH/zYBRgkdiWaCcTDFzV3KX R3+/tcvHO8NGMEITT2JJoiKrGCD0RiJHoFn4diLl8/8sEeaI+ZUkcCozWHI3wHu12520X1N0R6A0 2kgHkBPgF6CQNNo02n0BEAAAAAMADTT9PwUAAwAPNP0/BQACARQ0AQAAABAAAABOSVRB+b+4AQCq ADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDA2NjBCMzA5NDFBRTU4RDQyOUM2NEQ3Qjc5OUI0QzI5 Qjg0NEYyNjAwAAAAAAMABhBu0EMxAwAHEC0JAAADABAQAwAAAAMAERAAAAAAHgAIEAEAAABlAAAA Q0hPSUNFU0FSRToxUEFSU0VUSEVQUk9UT0NPTEhFQURFUkZPTExPV0lOR1RIRVVEUEhFQURFUj1U SElTU0hPVUxEQkUiUEFSU0VUSEVWRVJTSU9ORklFTERBRlRFUlRIRVVEUAAAAACWmg== ------=_NextPart_000_000B_01C793DF.2A72B8A0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ------=_NextPart_000_000B_01C793DF.2A72B8A0-- From mip6-bounces@ietf.org Fri May 11 01:19:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNXY-0006Wi-19; Fri, 11 May 2007 01:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNXW-0006Sz-Ag; Fri, 11 May 2007 01:19:38 -0400 Received: from mx05.syd.iprimus.net.au ([210.50.30.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNXU-0006TO-RC; Fri, 11 May 2007 01:19:38 -0400 Message-Id: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACuZQ0bTG2yO/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.14,520,1170594000"; d="scan'208";a="45772462" Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp05.syd.iprimus.net.au with ESMTP; 11 May 2007 15:19:34 +1000 From: "Hesham Soliman" To: , Date: Fri, 11 May 2007 15:19:30 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Mip6] The use of GRE X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, This concensus call on issue 93 made me a bit confused about the use of GRE. I have a simple question: Why can't people that want to use GRE (for PMIP) run it as follows: IP Heahder (proto 47 for GRE) GRE Header UDP ....etc Why do we need to add another layer to qualifiers instead of using the existing allocated numbers? It's been a couple of years since I read the GRE spec so I wanted to understand if this format is a problem Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 01:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNde-0001lw-C7; Fri, 11 May 2007 01:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNdc-0001ll-Nt; Fri, 11 May 2007 01:25:56 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNdb-00077j-C3; Fri, 11 May 2007 01:25:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 22:25:54 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="147486060:sNHT40923306" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4B5PsZE021775; Thu, 10 May 2007 22:25:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B5Po20007623; Fri, 11 May 2007 05:25:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:25:50 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:25:49 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au> Subject: RE: [Mip6] The use of GRE Date: Thu, 10 May 2007 22:25:50 -0700 Message-ID: <016001c7938c$d6695400$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQ In-Reply-To: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 05:25:50.0021 (UTC) FILETIME=[D61BF750:01C7938C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=843; t=1178861154; x=1179725154; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=XjlyYErcK8PidzHhvyPci2spG5vSdDqTv4CIVboJGus=; b=y430YYubsp+bPy2YkOm3R8wXhwua9JHf1AYmgKhUhGSsMkDD13HZK7qP648QxrJ2Cc/r+q8L B8b2BegytCmF7Hiq0EGOA/IrP03JQ5MHOrMbbKJ0rlTC2Rb/x5N1IbLT; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, May 10, 2007 10:20 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] The use of GRE > > Hi all, > > This concensus call on issue 93 made me a bit confused about > the use of GRE. > I have a simple question: > > Why can't people that want to use GRE (for PMIP) run it as follows: > > IP Heahder (proto 47 for GRE) > GRE Header > UDP > ....etc > > Why do we need to add another layer to qualifiers instead of using the > existing allocated numbers? > > It's been a couple of years since I read the GRE spec so I wanted to > understand if this format is a problem > Problem will be with the NAT/PAT device. It wont create NAT bindings from the UDP header encapped in the GRE header. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 01:32:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNju-0006Vv-65; Fri, 11 May 2007 01:32:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNjs-0006TE-KE; Fri, 11 May 2007 01:32:24 -0400 Received: from mx05.syd.iprimus.net.au ([210.50.30.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNjr-0008H0-7E; Fri, 11 May 2007 01:32:24 -0400 Message-Id: <5t7lbv$1bktaj@smtp05.syd.iprimus.net.au> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOucQ0bTG2yO/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.14,520,1170594000"; d="scan'208";a="45774163" Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp05.syd.iprimus.net.au with ESMTP; 11 May 2007 15:32:16 +1000 From: "Hesham Soliman" To: "'Sri Gundavelli'" , , Subject: RE: [Mip6] The use of GRE Date: Fri, 11 May 2007 15:32:09 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eA= In-Reply-To: <016001c7938c$d6695400$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > It's been a couple of years since I read the GRE spec so I > wanted to > > understand if this format is a problem > > > > Problem will be with the NAT/PAT device. It wont create NAT bindings > from the UDP header encapped in the GRE header. => So you want to use GRE in a *local* domain where a NAT separates the MAG and the LMA? In DSMIP we don't care or want to use GRE, therefore we don't have a NAT problem. But are you really saying that you have a NAT problem in NETLMM ? I think the reasons for this are getting very slim. I was hoping to actually see a good reason so I can say ok we've added 4 bytes but there is potenial benefits here, but given this I think it's just wasteful to do this and make it a default. If you want to use it in PMIP, I think you should add that additional UDP header specifically for PMIP and NAT cases, I don't think normal hosts and routers should carry the burden over the air interface for PMIP to avoid 8 bytes over a a wired network. Hesham > > Sri > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 01:45:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNwx-0000B2-7L; Fri, 11 May 2007 01:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNww-0000AW-3G; Fri, 11 May 2007 01:45:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNwv-0001Sm-P0; Fri, 11 May 2007 01:45:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 10 May 2007 22:45:53 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="420914011:sNHT47833132" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4B5jr5t019540; Thu, 10 May 2007 22:45:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B5jr20016667; Fri, 11 May 2007 05:45:53 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:45:52 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:45:52 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <016001c7938c$d6695400$d4f6200a@amer.cisco.com> <5t7lbv$1bktaj@smtp05.syd.iprimus.net.au> Subject: RE: [Mip6] The use of GRE Date: Thu, 10 May 2007 22:45:52 -0700 Message-ID: <016401c7938f$a2e93f70$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IA== In-Reply-To: <5t7lbv$1bktaj@smtp05.syd.iprimus.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 05:45:52.0631 (UTC) FILETIME=[A2EBB070:01C7938F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1989; t=1178862353; x=1179726353; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=E5XS4s7+1lxQUTWMuRbzv2+qBswpOamBsARQmFUxyQ0=; b=VUmwcR78Z7b2S4T+rNmRjgLJjumNoT7pE9987YHB4kZ1MtTaAPX2l/DtdAdgo6Tz07ZHeiKp 9eQ0WwTU0rlOhJ+vky35ep3sTpZEPieF0OYe8B+8dVFubSzjCcwZaZMW; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, May 10, 2007 10:32 PM > To: 'Sri Gundavelli'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > > > > > It's been a couple of years since I read the GRE spec so I > > wanted to > > > understand if this format is a problem > > > > > > > Problem will be with the NAT/PAT device. It wont create > NAT bindings > > from the UDP header encapped in the GRE header. > > => So you want to use GRE in a *local* domain where a NAT > separates the MAG > and the LMA? > In DSMIP we don't care or want to use GRE, therefore we don't > have a NAT > problem. But are you really saying that you have a NAT > problem in NETLMM ? > MIP4 has GRE support and has wide use for the MR case also for the FA-CCOA mode. So, we can keep PMIP out of this discussion. IMO, GRE mode is useful for HA-MR tunnel. > I think the reasons for this are getting very slim. I was > hoping to actually > see a good reason so I can say ok we've added 4 bytes but > there is potenial > benefits here, but given this I think it's just wasteful to > do this and make > it a default. > > If you want to use it in PMIP, I think you should add that > additional UDP > header specifically for PMIP and NAT cases, I don't think > normal hosts and > routers should carry the burden over the air interface for > PMIP to avoid 8 > bytes over a a wired network. > We dont have to justify this just for PMIP. Its just another consumer, like NEMO. IMO, having a thin header, always helps, follows the conventional way of tagging. Also, to extend this later for NEMO, we cannot use the same port, as the old and new implementation will have a problem dealing with UDP payloads with GRE and no GRE headers, at the same time. Any ways, this is my one opinion. Sri > Hesham > > > > > Sri > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 01:52:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmO3D-0002sz-AH; Fri, 11 May 2007 01:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmO3C-0002sr-9B; Fri, 11 May 2007 01:52:22 -0400 Received: from mx03.syd.iprimus.net.au ([210.50.30.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmO3A-0002WX-RZ; Fri, 11 May 2007 01:52:22 -0400 Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp03.syd.iprimus.net.au with ESMTP; 11 May 2007 15:52:14 +1000 Message-Id: <5tvsa1$iub6u@smtp03.syd.iprimus.net.au> From: "Hesham Soliman" To: "'Sri Gundavelli'" , , Subject: RE: [Mip6] The use of GRE Date: Fri, 11 May 2007 15:52:08 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHg In-Reply-To: <016401c7938f$a2e93f70$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > > > => So you want to use GRE in a *local* domain where a NAT > > separates the MAG > > and the LMA? > > In DSMIP we don't care or want to use GRE, therefore we don't > > have a NAT > > problem. But are you really saying that you have a NAT > > problem in NETLMM ? > > > > MIP4 has GRE support and has wide use for the MR case also > for the FA-CCOA mode. So, we can keep PMIP out of this > discussion. IMO, GRE mode is useful for HA-MR tunnel. => You can also keep MIP4 out of this discussion because we're talking about DSMIPv6. If we take PMIP out of the discussion then there is no reason for GRE whatsoever. > > > > I think the reasons for this are getting very slim. I was > > hoping to actually > > see a good reason so I can say ok we've added 4 bytes but > > there is potenial > > benefits here, but given this I think it's just wasteful to > > do this and make > > it a default. > > > > If you want to use it in PMIP, I think you should add that > > additional UDP > > header specifically for PMIP and NAT cases, I don't think > > normal hosts and > > routers should carry the burden over the air interface for > > PMIP to avoid 8 > > bytes over a a wired network. > > > > We dont have to justify this just for PMIP. Its just another > consumer, like NEMO. IMO, having a thin header, always helps, > follows the conventional way of tagging. => My problem here is that you're not giving me any concrete reasons for a use case. Just saying "always helps" doesn't make me understand something new. There is only two IP versions today and this is not going to change till you and I retire, so I don't find this flexibility argument realistic. Also, to extend this > later for NEMO, we cannot use the same port, as the old => Extend what for nemo??? Nemo is already supported in this spec. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 02:06:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOGw-0004hD-GE; Fri, 11 May 2007 02:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOGu-0004h2-Nl; Fri, 11 May 2007 02:06:32 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOGt-0004et-E4; Fri, 11 May 2007 02:06:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 23:06:31 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="485091739:sNHT43085656" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4B66Ums001161; Thu, 10 May 2007 23:06:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4B66UaI012117; Fri, 11 May 2007 06:06:30 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:06:30 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:06:30 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <016401c7938f$a2e93f70$d4f6200a@amer.cisco.com> <5tvsa1$iub6u@smtp03.syd.iprimus.net.au> Subject: RE: [Mip6] The use of GRE Date: Thu, 10 May 2007 23:06:26 -0700 Message-ID: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPA= In-Reply-To: <5tvsa1$iub6u@smtp03.syd.iprimus.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 06:06:30.0084 (UTC) FILETIME=[84800840:01C79392] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1566; t=1178863590; x=1179727590; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=o+q8K++hEE4gngApedzu6G7nN39FQHhErQc+1VlGapA=; b=Bsr0ogKvOz1c242V+Y4OQI52+rg84k6Y9qQ/lJZ7CZqxRy9J5WCoqiywLiiggBv0HVY8ng8p hhaCC2P+boJ4nODeUMX7GT7xbw/aB6UnlZgdONE0ie+/3K7GNIzi3KaU; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > > > > > > We dont have to justify this just for PMIP. Its just another > > consumer, like NEMO. IMO, having a thin header, always helps, > > follows the conventional way of tagging. > > => My problem here is that you're not giving me any concrete > reasons for a > use case. > Just saying "always helps" doesn't make me understand > something new. There > is only two IP versions today and this is not going to change > till you and I > retire, so I don't find this flexibility argument realistic. > GRE header is applicable when flows from multiple nodes are carried in the same tunnel. That's not the case for 3775 MN flows, but indeed is the case for 3963. The GRE header has the proper semantics that allows tunnel peers to process properly. The seq number in the header is useful when carrying real time traffic. Is this not a good reason ? Now, if you say there is no GRE tunneling for MIP6, off course, thats where I say, there is a chance we will introduce GRE tunnel mode for NEMO use cases in mind, learnt from the experience of supporting NEMOv4 deployments and applications. Sure, supporting GRE mode helps PMIP as well, I agree, if we apply it there. Second reason, I give is the convention that has been followed in all protocol designs so far, of prev header identifying the next header. No protocol is mucking around in the payloads to determine the type. Are these not good reasons ? Do they outweigh the 4 byte saving ? Again, this is my opinion. We can let others comment on this. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 02:22:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOVC-0006tn-4U; Fri, 11 May 2007 02:21:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOVB-0006tc-9k; Fri, 11 May 2007 02:21:17 -0400 Received: from mx03.syd.iprimus.net.au ([210.50.30.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOVA-0006Wu-RK; Fri, 11 May 2007 02:21:17 -0400 Received: from 142.001.vod.mel.iprimus.net.au (HELO PC20005) ([211.27.108.142]) by smtp03.syd.iprimus.net.au with ESMTP; 11 May 2007 16:21:14 +1000 Message-Id: <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> From: "Hesham Soliman" To: "'Sri Gundavelli'" , , Subject: RE: [Mip6] The use of GRE Date: Fri, 11 May 2007 16:21:04 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPAAAIS1MA== In-Reply-To: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sri, > > > > > > We dont have to justify this just for PMIP. Its just another > > > consumer, like NEMO. IMO, having a thin header, always helps, > > > follows the conventional way of tagging. > > > > => My problem here is that you're not giving me any concrete > > reasons for a > > use case. > > Just saying "always helps" doesn't make me understand > > something new. There > > is only two IP versions today and this is not going to change > > till you and I > > retire, so I don't find this flexibility argument realistic. > > > > > GRE header is applicable when flows from multiple nodes are carried > in the same tunnel. That's not the case for 3775 MN flows, but indeed > is the case for 3963. The GRE header has the proper semantics that > allows tunnel peers to process properly. The seq number in the header > is useful when carrying real time traffic. Is this not a > good reason ? => This is a classic example of hacks that lingered for such long time that it grew on people and they thought it's just the "normal" way of doing things. I think your arguments above are quite confused about GRE. It's like the very common arguments about NATs being good for security. The need for another abstraction layer for tunnelling was only to support virtual routing, especially for environments that conntain overlapping IPv4 addresses. Everything else you talk about above is available in IP and transport headers; and I won't even get into QoS for IP flows. You seem to think that this is a special case for nemo because there can be "many flows", which is not the case in a 3775 MN. This is clearly a confused view of things because a MN can of course generate many flows, from different addresses ....etc ....sigh > Now, if you say there is no GRE tunneling for MIP6, off course, thats > where I say, there is a chance we will introduce GRE tunnel mode > for NEMO use cases in mind, learnt from the experience of supporting > NEMOv4 deployments and applications. => I think I've said enough on this. I don't think I can add any more. I honestly think what you're listing above is either confused or a case of you wanting everyone else to fit some idea in your mind, which we don't know. Sure, supporting GRE mode helps > PMIP as well, I agree, if we apply it there. Second reason, I give > is the convention that has been followed in all protocol designs so > far, of prev header identifying the next header. No protocol > is mucking > around in the payloads to determine the type. => Mucking around? There is a very well known encoding mechanism called TLV where you have to inspect the first byte to know the type of information following it. I don't think that's referred to as mucking around, at least not in specs.. ;0 enuff said from me. Hesham Are these not good > reasons ? Do they outweigh the 4 byte saving ? Again, this is my > opinion. We can let others comment on this. > > > Sri > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 02:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOdc-00058w-Cp; Fri, 11 May 2007 02:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOdb-00058g-6K; Fri, 11 May 2007 02:29:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOda-0007cd-Nu; Fri, 11 May 2007 02:29:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 23:29:58 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="485095804:sNHT49901744" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4B6TwHZ028924; Thu, 10 May 2007 23:29:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B6Tr20006378; Fri, 11 May 2007 06:29:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:29:53 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:29:52 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , , References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> Subject: RE: [Mip6] The use of GRE Date: Thu, 10 May 2007 23:29:52 -0700 Message-ID: <016b01c79395$c8b82530$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPAAAIS1MAAAsbFg In-Reply-To: <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 May 2007 06:29:52.0984 (UTC) FILETIME=[C8B19580:01C79395] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3559; t=1178864998; x=1179728998; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=B0aAlybJduoV4VS+4ABxBrgZ4J0kIFsKsAwWOMcaE5o=; b=DsC7omiB85Wsbx/b1lp7E3Om7gLaQX9rDuvZKlQAlyswP7ABIHNK83qWaxBM4DRtd2ttSgxz XElSeAGWukynts5KgodgUteKRplB8UW+aE/e6w8yinfbCfcGIus1MkHt; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, Ok. Thanks for the discussion. Sri > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Thursday, May 10, 2007 11:21 PM > To: 'Sri Gundavelli'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > Sri, > > > > > > > > > We dont have to justify this just for PMIP. Its just another > > > > consumer, like NEMO. IMO, having a thin header, always helps, > > > > follows the conventional way of tagging. > > > > > > => My problem here is that you're not giving me any concrete > > > reasons for a > > > use case. > > > Just saying "always helps" doesn't make me understand > > > something new. There > > > is only two IP versions today and this is not going to change > > > till you and I > > > retire, so I don't find this flexibility argument realistic. > > > > > > > > > GRE header is applicable when flows from multiple nodes are carried > > in the same tunnel. That's not the case for 3775 MN flows, > but indeed > > is the case for 3963. The GRE header has the proper semantics that > > allows tunnel peers to process properly. The seq number in > the header > > is useful when carrying real time traffic. Is this not a > > good reason ? > > => This is a classic example of hacks that lingered for such > long time that > it grew on people and they thought it's just the "normal" way of doing > things. > I think your arguments above are quite confused about GRE. > It's like the > very common arguments about NATs being good for security. > The need for another abstraction layer for tunnelling was > only to support > virtual routing, especially for environments that conntain > overlapping IPv4 > addresses. > > Everything else you talk about above is available in IP and transport > headers; and I won't even get into QoS for IP flows. You seem > to think that > this is a special case for nemo because there can be "many > flows", which is > not the case in a 3775 MN. This is clearly a confused view of > things because > a MN can of course generate many flows, from different > addresses ....etc > ....sigh > > > Now, if you say there is no GRE tunneling for MIP6, off > course, thats > > where I say, there is a chance we will introduce GRE tunnel mode > > for NEMO use cases in mind, learnt from the experience of > supporting > > NEMOv4 deployments and applications. > > => I think I've said enough on this. I don't think I can add > any more. I > honestly think what you're listing above is either confused > or a case of you > wanting everyone else to fit some idea in your mind, which we > don't know. > > > > Sure, supporting GRE mode helps > > PMIP as well, I agree, if we apply it there. Second reason, I give > > is the convention that has been followed in all protocol designs so > > far, of prev header identifying the next header. No protocol > > is mucking > > around in the payloads to determine the type. > > => Mucking around? There is a very well known encoding > mechanism called TLV > where you have to inspect the first byte to know the type of > information > following it. I don't think that's referred to as mucking > around, at least > not in specs.. ;0 > > enuff said from me. > Hesham > > Are these not good > > reasons ? Do they outweigh the 4 byte saving ? Again, this is my > > opinion. We can let others comment on this. > > > > > > Sri > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 02:37:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOl7-0007CD-5C; Fri, 11 May 2007 02:37:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOl5-0007Bw-Mu; Fri, 11 May 2007 02:37:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOl5-00008B-AK; Fri, 11 May 2007 02:37:43 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4B6bdjJ017351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 May 2007 23:37:40 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4B6bda4027399; Thu, 10 May 2007 23:37:39 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 23:37:39 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] The use of GRE Date: Thu, 10 May 2007 23:37:38 -0700 Message-ID: In-Reply-To: <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPAAAIS1MAAA6lwA References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> <5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> From: "Narayanan, Vidya" To: "Hesham Soliman" , "Sri Gundavelli" , , X-OriginalArrivalTime: 11 May 2007 06:37:39.0012 (UTC) FILETIME=[DE77D040:01C79396] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I'm confused by this thread - could someone explain the role of GRE for NEMO? From everything I've read so far on this thread, I'm with Hesham here - I don't understand why we need GRE to parse the multiple flows sent in the MR's tunnel. =20 Vidya=20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, May 10, 2007 11:21 PM > To: 'Sri Gundavelli'; mip6@ietf.org; nemo@ietf.org > Subject: [nemo] RE: [Mip6] The use of GRE >=20 > Sri,=20 >=20 > > > > > > > > We dont have to justify this just for PMIP. Its just=20 > another > > > consumer, like NEMO. IMO, having a thin=20 > header, always helps, > > > follows the conventional way of=20 > tagging.=20 > > > > > > =3D> My problem here is that you're not giving me any=20 > concrete > > reasons for a > > use case. > > > Just saying "always helps" doesn't make me understand >=20 > > something new. There > > is only two IP versions today and=20 > this is not going to change > > till you and I > > retire,=20 > so I don't find this flexibility argument realistic.=20 > > > > > > > > > GRE header is applicable when flows from multiple nodes=20 > are carried > in the same tunnel. That's not the case for=20 > 3775 MN flows, but indeed > is the case for 3963. The GRE=20 > header has the proper semantics that > allows tunnel peers=20 > to process properly. The seq number in the header > is=20 > useful when carrying real time traffic. Is this not a > good reason ? >=20 > =3D> This is a classic example of hacks that lingered for such=20 > long time that it grew on people and they thought it's just=20 > the "normal" way of doing things.=20 > I think your arguments above are quite confused about GRE.=20 > It's like the very common arguments about NATs being good for=20 > security.=20 > The need for another abstraction layer for tunnelling was=20 > only to support virtual routing, especially for environments=20 > that conntain overlapping IPv4 addresses.=20 >=20 > Everything else you talk about above is available in IP and=20 > transport headers; and I won't even get into QoS for IP=20 > flows. You seem to think that this is a special case for nemo=20 > because there can be "many flows", which is not the case in a=20 > 3775 MN. This is clearly a confused view of things because a=20 > MN can of course generate many flows, from different=20 > addresses ....etc ....sigh=20 >=20 > > Now, if you say there is no GRE tunneling for MIP6, off=20 > course, thats > where I say, there is a chance we will=20 > introduce GRE tunnel mode > for NEMO use cases in mind,=20 > learnt from the experience of supporting > NEMOv4=20 > deployments and applications.=20 >=20 > =3D> I think I've said enough on this. I don't think I can add=20 > any more. I honestly think what you're listing above is=20 > either confused or a case of you wanting everyone else to fit=20 > some idea in your mind, which we don't know.=20 >=20 >=20 >=20 > Sure, supporting GRE mode helps > > PMIP as well, I agree, if we apply it there. Second=20 > reason, I give > is the convention that has been followed in=20 > all protocol designs so > far, of prev header identifying=20 > the next header. No protocol > is mucking > around in the=20 > payloads to determine the type.=20 >=20 > =3D> Mucking around? There is a very well known encoding=20 > mechanism called TLV where you have to inspect the first byte=20 > to know the type of information following it. I don't think=20 > that's referred to as mucking around, at least not in specs.. ;0 >=20 > enuff said from me. > Hesham >=20 > Are these not good > > reasons ? Do they outweigh the 4 byte saving ? Again, this=20 > is my > opinion. We can let others comment on this. > > > > > > Sri > >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 06:34:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSSA-0001ha-Ew; Fri, 11 May 2007 06:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSS8-0001b4-QS; Fri, 11 May 2007 06:34:24 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmSS7-0002m8-Ie; Fri, 11 May 2007 06:34:24 -0400 Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp7-g19.free.fr (Postfix) with ESMTP id 65A5817C56; Fri, 11 May 2007 12:34:22 +0200 (CEST) Message-ID: <464446AD.3020302@gmail.com> Date: Fri, 11 May 2007 12:34:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 References: <4B7483DD-2A0F-445C-BB10-98F5F694FCBC@gmail.com><001d01c792d3$b7d1e750$d4f6200a@amer.cisco.com> <59E4C5D8-D213-416A-B4D7-095509F5A4DD@gmail.com> <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> In-Reply-To: <00e901c79342$a097dc60$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-2, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Vijay Devarapalli' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sri Gundavelli wrote: >> I am fine with 4 bytes if there is strong reason for that, >> however I want to see what kind of additional payloads is >> considered in the future. > > Ok. Reasons are beyond the MIP6 node's usage, its for PMIP6 and NEMO. > Will be useful. Sri - for NEMO, I don't understand. Implementations of MIP6 and NEMOv6 today don't use GRE, neither GRE keys; NEMOv6 implementations don't need GRE. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 06:37:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSUk-0003nv-9X; Fri, 11 May 2007 06:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSUj-0003nn-Kc; Fri, 11 May 2007 06:37:05 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmSUi-00036u-Bv; Fri, 11 May 2007 06:37:05 -0400 Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp7-g19.free.fr (Postfix) with ESMTP id 8EE015478; Fri, 11 May 2007 12:37:02 +0200 (CEST) Message-ID: <4644474E.9080805@gmail.com> Date: Fri, 11 May 2007 12:37:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] DS-MIP6: Consensus call to close issue 93 References: <00e801c79342$0e643000$d4f6200a@amer.cisco.com> <20070511022734.OAKO15903.oaamta07sl.mx.bigpond.com@PC20005> <014701c7937e$6e6a2180$d4f6200a@amer.cisco.com> In-Reply-To: <014701c7937e$6e6a2180$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-2, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sri Gundavelli wrote: > Hi Hesham: > >> -----Original Message----- >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >> Sent: Thursday, May 10, 2007 7:28 PM >> To: 'Sri Gundavelli' >> Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' >> Subject: RE: [nemo] RE: [Mip6] DS-MIP6: Consensus call to >> close issue 93 >> >> >> >> > Agree, may not be useful for a pure MIP6 node, as the mode >> > is in CCOA mode. But, if you enable NEMO, we need more >> > flexibility on the marking of the MNP flows that go in the >> > tunnel. >> >> => Could you elaborate on the nemo aspect you mention above? I don't >> understand why nemo is helped by this? >> > > We have some use cases where we use the GRE key to tag > certain MNP flows and the tunnel peers use these keys as > a form of a selector for differential treatment. Its a > color code. The seq number and key fields in the GRE header > are used. So support for carrying the GRE header over UDP > will be possible with the TLV header. Errr... this is too long and complicated and... undocumented? What is that use case more exactly? We can say that we 'tag' the MNP (Mobile Network Prefix) by the Home Address (not by the GRE key). You seem to mention UDP - do you mean that DS-MIPv6 (and not NEMOv6) needs GRE? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 06:47:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSeK-0001cK-43; Fri, 11 May 2007 06:47:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSeI-0001cC-Vs; Fri, 11 May 2007 06:46:58 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmSeH-00051H-JN; Fri, 11 May 2007 06:46:58 -0400 Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp7-g19.free.fr (Postfix) with ESMTP id 971B4182B0; Fri, 11 May 2007 12:46:56 +0200 (CEST) Message-ID: <464449A0.6000502@gmail.com> Date: Fri, 11 May 2007 12:46:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: <016401c7938f$a2e93f70$d4f6200a@amer.cisco.com> <5tvsa1$iub6u@smtp03.syd.iprimus.net.au> <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> In-Reply-To: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-2, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sri Gundavelli wrote: > > >>>> >>> >>> We dont have to justify this just for PMIP. Its just another >>> consumer, like NEMO. IMO, having a thin header, always helps, >>> follows the conventional way of tagging. >> >> => My problem here is that you're not giving me any concrete >> reasons for a use case. Just saying "always helps" doesn't make me >> understand something new. There is only two IP versions today and >> this is not going to change till you and I retire, so I don't find >> this flexibility argument realistic. >> > > > GRE header is applicable when flows from multiple nodes are carried > in the same tunnel. That's not the case for 3775 MN flows, but indeed > is the case for 3963. The GRE header has the proper semantics that > allows tunnel peers to process properly Current implementations of NEMOv6 don't use GRE header and manage to distinguish the flows from different LFNs through the same MR. I don't know what is meant by 'same tunnel'. The tunnel from MR to HA has src MR's CoA and dst HA and inner is src LFN's address and dst CN. BAsed on that the HA receiving a encapsulated packet from LFN can very easily distinguish the flows. No need of GRE. > The seq number in the header is useful when carrying real time > traffic. But real-time protocols have their own mechanisms with sequence numbers no? Why an intermediary layer between network and transport when transport does it already. > Is this not a good reason ? Now, if you say there is no GRE tunneling > for MIP6, off course, thats where I say, there is a chance we will > introduce GRE tunnel mode for NEMO use cases in mind, learnt from the > experience of supporting NEMOv4 deployments and applications. _Some_ NEMOv4 deployments don't need GRE tunnels either. NEMOv4 implementations rely on MIP4 and MIP4 has three ways of encapsulating, only one them being GRE (the two others are IP-IP and UDP). Some NEMOv4 deployments don't need GRE and they work. > Sure, supporting GRE mode helps PMIP as well, I agree, if we apply it > there. Second reason, I give is the convention that has been > followed in all protocol designs so far, of prev header identifying > the next header. No protocol is mucking around in the payloads to > determine the type. Are these not good reasons ? Do they outweigh the > 4 byte saving ? Again, this is my opinion. We can let others comment > on this. Yes, I comment: I don't see the necessity of GRE in MIP6 at all, and probably _some_ necessity in MIP4 (but MIP4 can do without GRE). Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 08:52:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUbs-0006Ix-9H; Fri, 11 May 2007 08:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUbq-0006Im-5O; Fri, 11 May 2007 08:52:34 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmUbo-0005O9-Qr; Fri, 11 May 2007 08:52:34 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4BCqVZS004975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 May 2007 05:52:32 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4BCqVlr023596; Fri, 11 May 2007 05:52:31 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 05:52:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 05:53:02 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4579F25@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiACEBSSA References: From: "Tsirtsis, George" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-OriginalArrivalTime: 11 May 2007 12:52:30.0939 (UTC) FILETIME=[3CB382B0:01C793CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I support Option 1. (BTW, Option 4 does not work as far as I can tell) Please see justification below... -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Tuesday, May 08, 2007 10:16 PM To: Mobile IPv6 Mailing List; nemo@ietf.org Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 ... Choices are: 1. Parse the protocol header following the UDP header GT> This makes sense to me. It is simple, efficient and it is already defined in the draft. 2. Reserve a UDP port for each protocol header (i.e one UDP port for IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) GT> While this is a reasonable alternative, I have not heard a convincing argument to warrant a change from what the draft already defines (i.e., option 1 above). 3. One reserved UDP port and a DS-MIP6 "tunnel type message" GT> This seems wasteful and unnecessary, given (1 and 2) 4. Encapsulated protocol header type is indicated in the BU message GT> This does not seem to work at all. DSMIPv6 can register IPv4 and IPv6 addresses at the same time. This means that on a packet by packet basis the header encapsulated over UDP can change from IPv4 to IPv6 and back. Signaling one or the other in the BU (outbound indication) is clearly not sufficient and so the indication has to be inbound with the data. Regards George _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 10:46:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWNy-0003on-7R; Fri, 11 May 2007 10:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWNw-0003od-TB for mip6@ietf.org; Fri, 11 May 2007 10:46:20 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmWNw-00010Y-IU for mip6@ietf.org; Fri, 11 May 2007 10:46:20 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4BEkHh05266; Fri, 11 May 2007 14:46:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 09:46:05 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6BC5@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371142CEDF9@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABzG+cgABYTWwA= From: "Mohamed Khalil" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I vote for option # 3. > Hello, >=20 > The DS-MIP6 I-D > still has issue 93 open. This was discussed at IETF68. Vijay=20 > presented 4 options to solve the issue. These are captured in: >=20 > https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >=20 > We need to make a decision on this issue and move forward > with the I-D. At the meeting itself, I got the sense that=20 > option 3 was the one that had the least impact and easy to implement. >=20 > Please consider this email as a consensus call for issue 93. > The problem and choices are as follows (based on Vijay's slides): >=20 > Problem: UDP encapsulation is used in DS-MIP6 for NAT > traversal. The encapculations are either: > - IPv6-in-UDP-over-IPv4 > - IPv4-in-UDP-over-IPv4 > There is a need (or I guess desirable) to indicate the type=20 > of protocol being encapsulated in the UDP header. >=20 > Choices are: > 1. Parse the protocol header following the UDP header 2. > Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for=20 > IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a=20 > DS-MIP6 "tunnel type message" > 4. Encapsulated protocol header type is indicated in the BU message >=20 > Pros and cons of these choices are in the slides that were > presented at IETF68 (see URL above). >=20 > Please provide your opinions and comments by May 15th, 07 on > the MIP6 mailing list. >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ 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 From mip6-bounces@ietf.org Fri May 11 15:01:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmaMH-0004a4-Da; Fri, 11 May 2007 15:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmaMG-0004WL-QG for mip6@ietf.org; Fri, 11 May 2007 15:00:52 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmaMG-0003IY-A1 for mip6@ietf.org; Fri, 11 May 2007 15:00:52 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4BJ0RwM016824; Fri, 11 May 2007 22:00:50 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 22:00:41 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 14:00:36 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 May 2007 19:00:36 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 11 May 2007 14:00:38 -0500 Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 From: Basavaraj Patil To: ext Mohamed Khalil , Mobile IPv6 Mailing List Message-ID: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABzG+cgABYTWwAACPK0yA== In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F6BC5@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 May 2007 19:00:36.0819 (UTC) FILETIME=[A8E95A30:01C793FE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org So far there have not really been very strong reasons or arguments to include the 4 byte header (Option 3). Please provide an explanation why the 4 byte header is essential or benefits (or perceived) of doing so. Without strong reasons or arguments for including the 4 byte header (Option 3), the option of not doing anything in the scope of the MIP6 spec (ie option 1) makes sense. -Raj >> Hello, >> >> The DS-MIP6 I-D >> still has issue 93 open. This was discussed at IETF68. Vijay >> presented 4 options to solve the issue. These are captured in: >> >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >> >> We need to make a decision on this issue and move forward >> with the I-D. At the meeting itself, I got the sense that >> option 3 was the one that had the least impact and easy to implement. >> >> Please consider this email as a consensus call for issue 93. >> The problem and choices are as follows (based on Vijay's slides): >> >> Problem: UDP encapsulation is used in DS-MIP6 for NAT >> traversal. The encapculations are either: >> - IPv6-in-UDP-over-IPv4 >> - IPv4-in-UDP-over-IPv4 >> There is a need (or I guess desirable) to indicate the type >> of protocol being encapsulated in the UDP header. >> >> Choices are: >> 1. Parse the protocol header following the UDP header 2. >> Reserve a UDP port for each protocol header (i.e one UDP port for >> IPv6-in-UDP-over-IPv4 and another for >> IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a >> DS-MIP6 "tunnel type message" >> 4. Encapsulated protocol header type is indicated in the BU message >> >> Pros and cons of these choices are in the slides that were >> presented at IETF68 (see URL above). >> >> Please provide your opinions and comments by May 15th, 07 on >> the MIP6 mailing list. >> >> -Raj >> >> >> _______________________________________________ >> 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 15:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmalV-0002JG-31; Fri, 11 May 2007 15:26:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmalT-0002JA-NJ for mip6@ietf.org; Fri, 11 May 2007 15:26:55 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmalR-0006lF-CJ for mip6@ietf.org; Fri, 11 May 2007 15:26:55 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4BJQo025005; Fri, 11 May 2007 19:26:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 14:26:42 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114332A46@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABzG+cgABYTWwAACPK0yAAAirNA References: <62B9B0847CC47543B6B3B5E26BD268E60B5F6BC5@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Basavaraj Patil" , "Mohamed Khalil" , "Mobile IPv6 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, In response to your request and to a point that was raised by Hesham earlier, about how this 4 bytes could only be used in special case, e.g. GRE, in order to avoid the 4 bytes in other types of traffics, I would like to say the following: My understanding that this option requires a reserved UDP port. No? This means that the TLV will be present only in the case when the UDP port is set to the reserved port. Correct? If that the case, then if the UDP port is set otherwise, then peaking into the payload is perfectly fine (option 1), or I am missing something? Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, May 11, 2007 2:01 PM > To: Khalil, Mohamed (RICH2:2S20); Mobile IPv6 Mailing List > Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 >=20 > So far there have not really been very strong reasons or=20 > arguments to include the 4 byte header (Option 3). Please=20 > provide an explanation why the > 4 byte header is essential or benefits (or perceived) of doing so. >=20 > Without strong reasons or arguments for including the 4 byte=20 > header (Option 3), the option of not doing anything in the=20 > scope of the MIP6 spec (ie option 1) makes sense. >=20 > -Raj >=20 >=20 > >> Hello, > >>=20 > >> The DS-MIP6 I-D > >> still has issue 93 open. This was discussed at IETF68. Vijay=20 > >> presented 4 options to solve the issue. These are captured in: > >>=20 > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >>=20 > >> We need to make a decision on this issue and move forward with the=20 > >> I-D. At the meeting itself, I got the sense that option 3=20 > was the one=20 > >> that had the least impact and easy to implement. > >>=20 > >> Please consider this email as a consensus call for issue 93. > >> The problem and choices are as follows (based on Vijay's slides): > >>=20 > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 > traversal. The=20 > >> encapculations are either: > >> - IPv6-in-UDP-over-IPv4 > >> - IPv4-in-UDP-over-IPv4 > >> There is a need (or I guess desirable) to indicate the type of=20 > >> protocol being encapsulated in the UDP header. > >>=20 > >> Choices are: > >> 1. Parse the protocol header following the UDP header 2. > >> Reserve a UDP port for each protocol header (i.e one UDP port for > >> IPv6-in-UDP-over-IPv4 and another for > >> IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a > >> DS-MIP6 "tunnel type message" > >> 4. Encapsulated protocol header type is indicated in the BU message > >>=20 > >> Pros and cons of these choices are in the slides that were=20 > presented=20 > >> at IETF68 (see URL above). > >>=20 > >> Please provide your opinions and comments by May 15th, 07=20 > on the MIP6=20 > >> mailing list. > >>=20 > >> -Raj > >>=20 > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 15:45:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb3b-0005kj-QD; Fri, 11 May 2007 15:45:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb3b-0005kd-5M for mip6@ietf.org; Fri, 11 May 2007 15:45:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmb3a-00017q-MO for mip6@ietf.org; Fri, 11 May 2007 15:45:39 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 May 2007 12:45:38 -0700 X-IronPort-AV: i="4.14,523,1170662400"; d="scan'208"; a="147826695:sNHT46895616" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4BJjbOM009025; Fri, 11 May 2007 12:45:37 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4BJjXaJ024305; Fri, 11 May 2007 19:45:37 GMT Date: Fri, 11 May 2007 12:45:33 -0700 (PDT) From: Sri Gundavelli To: Ahmad Muhanna Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114332A46@zrc2hxm2.corp.nortel.com> Message-ID: References: <62B9B0847CC47543B6B3B5E26BD268E60B5F6BC5@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437114332A46@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4704; t=1178912738; x=1179776738; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20call=20to=20close=2 0issue=2093 |Sender:=20; bh=t4tcMAINub9dv1zoqebIWBDuJmqrMo5fF73NbnegqZw=; b=plV5nu4oApOGFfSGXLbwQKVoGShg4SSUJYURPSc2NjhMF3Y10LziWyeW3AmU55RVecf20qAo v1gMig2jxsX2euGmyRmiaX5yVEtLbzc66XbLpBnvl3vx39qiuG2vLZ8JxUYBZx2O5jngbz5OGp NyG1WcZFon6MWbzR7Ufqmrenk=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Raj: Following are the reasons why we need to have a thin header: 1. Protocol Design Convention Looking at IP header, Ethernet header or IPv6 options, always the prev header qualifies the payload that follows. No protocol is looking at the payload to determine the type. 2. 3519 Reference When a packet is carried in a UDP transport, its important that the payload is classified. Designers of 3519 chose that option. Please see the 4 byte TLV header. 3. Extensibility. We cannot say, we will only carry IPv4 or IPv6 and so the 1st byte lookup is sufficient. Allow the provision for carrying other types of messages. Ex: - GRE Header - Tunnel Keepalive Message with a different type number 4. What is the cost ? - 4 bytes. How often we are moving a max MTU packets. For RADIO systems, this can be argued about the time slot width and encoding, but, IMHO, its insignificant. For these reasons, I'd prefer Option#3. All we are asking for is a thin header. Not sure, if this requires so much of discussion. We are asking for a good reason, IMO. Regards Sri On Fri, 11 May 2007, Ahmad Muhanna wrote: > Hi Raj, > > In response to your request and to a point that was raised by Hesham > earlier, about how this 4 bytes could only be used in special case, e.g. > GRE, in order to avoid the 4 bytes in other types of traffics, I would > like to say the following: > > My understanding that this option requires a reserved UDP port. No? This > means that the TLV will be present only in the case when the UDP port is > set to the reserved port. Correct? > If that the case, then if the UDP port is set otherwise, then peaking > into the payload is perfectly fine (option 1), or I am missing > something? > > > Regards, > Ahmad > > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Friday, May 11, 2007 2:01 PM >> To: Khalil, Mohamed (RICH2:2S20); Mobile IPv6 Mailing List >> Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 >> >> >> So far there have not really been very strong reasons or >> arguments to include the 4 byte header (Option 3). Please >> provide an explanation why the >> 4 byte header is essential or benefits (or perceived) of doing so. >> >> Without strong reasons or arguments for including the 4 byte >> header (Option 3), the option of not doing anything in the >> scope of the MIP6 spec (ie option 1) makes sense. >> >> -Raj >> >> >>>> Hello, >>>> >>>> The DS-MIP6 I-D >>>> still has issue 93 open. This was discussed at IETF68. Vijay >>>> presented 4 options to solve the issue. These are captured in: >>>> >>>> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf >>>> >>>> We need to make a decision on this issue and move forward with the >>>> I-D. At the meeting itself, I got the sense that option 3 >> was the one >>>> that had the least impact and easy to implement. >>>> >>>> Please consider this email as a consensus call for issue 93. >>>> The problem and choices are as follows (based on Vijay's slides): >>>> >>>> Problem: UDP encapsulation is used in DS-MIP6 for NAT >> traversal. The >>>> encapculations are either: >>>> - IPv6-in-UDP-over-IPv4 >>>> - IPv4-in-UDP-over-IPv4 >>>> There is a need (or I guess desirable) to indicate the type of >>>> protocol being encapsulated in the UDP header. >>>> >>>> Choices are: >>>> 1. Parse the protocol header following the UDP header 2. >>>> Reserve a UDP port for each protocol header (i.e one UDP port for >>>> IPv6-in-UDP-over-IPv4 and another for >>>> IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a >>>> DS-MIP6 "tunnel type message" >>>> 4. Encapsulated protocol header type is indicated in the BU message >>>> >>>> Pros and cons of these choices are in the slides that were >> presented >>>> at IETF68 (see URL above). >>>> >>>> Please provide your opinions and comments by May 15th, 07 >> on the MIP6 >>>> mailing list. >>>> >>>> -Raj >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 15:49:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb7l-0000n5-PI; Fri, 11 May 2007 15:49:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb7k-0000ms-75; Fri, 11 May 2007 15:49:56 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmb7h-0001np-Mj; Fri, 11 May 2007 15:49:56 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4BJngKi024650; Fri, 11 May 2007 22:49:47 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 22:49:44 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 14:49:10 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 May 2007 19:49:09 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 11 May 2007 14:49:10 -0500 Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 From: Basavaraj Patil To: ext Hesham Soliman , Mobile IPv6 Mailing List , Message-ID: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAFi7P/YAEg5cQAAfOR18 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 May 2007 19:49:10.0404 (UTC) FILETIME=[718B2440:01C79405] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, On 5/11/07 12:15 AM, "ext Hesham Soliman" wrote: > > >>>> 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >>> >>> => This is what the issue suggested but the additional 4 bytes are >>> redundant. >> >> So are you okay with using the tunnel type message as has >> been done in >> RFC3519? Not sure what you are implying by saying that the 4 >> bytes are >> redundant in this context. > > => I meant that they are redundant because they have no justification > for the operation of the spec. The rationale for the suggestion was that > it was not really possible (or difficult) to tell whether the following > packet was IPv4 or IPv6 if the implementation is in user space; and that > it was diffcult to know the packet length. However, after we discussed > this, it turned out that none of these issues are true, so I don't see > why we need to add another 4 bytes to every packet. Whether you view it from an implementation perspective or from protocol design perspective, does it not make sense to have the header indicate the type of header or encapsulation that exists following the parsing of a header? It is a matter of processing ease and clarity of the encapsulated packet type vs the overhead of 4 bytes on every packet. > >>> I think option 1 is the right option. There is no reason >>> given for a change. >> >> Sure... If the encapsulated packets are only IPv4 or IPv6, >> you could parse >> the version field and figure out the encapsulated packet >> type. And as you >> have said on the list in another email, is there a need for >> encapsulating >> any other type of packets between the MN and HA in UDP? I >> think this is an >> unknown. GRE has been mentioned, but I agree that it is not generally >> between an MN and HA. I don't know if you have thought about >> this option >> from the NEMO perspective as well. After all this I-D is >> intended to address >> hosts and mobile routers. > > => Sure, if there is something specific for nemo then we have to address > it. I still don't know what that is though. I'd appreciate it if someone > can explain it. > >> And the other thing is if you want >> to have some >> flexibility by introducing the 4 byte header to explicitly >> indicate the >> encapsulated packet type (akin to RFC3519) >> >> Some explicit reasons for why in the case of MIP6/NEMO would >> we want the 4 >> byte header to indicate the encapsulated packet type would be good. >> > > => Yes. > >> Reasons I have heard so far: >> 1. PMIP6 relies on DS-MIP6 for IPv4 support and hence >> encapsulation of >> packets other than IPv4/6 (eg. GRE) should be possible in >> which case the >> header would be useful > > => I heard that too, but I don't know why we should add more overhead > for every host and router just so PMIP might use GRE, unless we want to > make MIP look like it's more wasteful. Also, I don't understand why GRE > has to follow UDP and not run after the IP header? I need to re-read GRE > to see if that's possible. Okay.. > >> 2. Flexibility for future use Is the flexibility argument worth considering? Design the protocol with hooks for allowing it to be used in the case there exists encapsulation of packet types other than v4/v6 in the future... >> 3. Reuse 3519 (don't know if this was mentioned) > > => what do you mean by "reuse 3519"? You mean "make it look like 3519"? > That's not a reason though is it? Agree that its not a good reason. What I was implying was that we could learn from the 3519 experience and adopt a mechanism that has worked well. -Raj > > Hesham > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 16:28:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmbin-00060K-RS; Fri, 11 May 2007 16:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmbin-00060B-3U for mip6@ietf.org; Fri, 11 May 2007 16:28:13 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmbim-0002kn-Pv for mip6@ietf.org; Fri, 11 May 2007 16:28:13 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4BKSAv07292; Fri, 11 May 2007 20:28:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 15:27:53 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6BCB@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114332A46@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABzG+cgABYTWwAACPK0yAAAirNAAAI6QjA= From: "Mohamed Khalil" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I don't think you need 4 bytes. you need only a one byte for the next type and a reserved port number to indicate that the next byte is the protocol type. This will make it easy to recognize all encapsulated protocols including GRE. > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Friday, May 11, 2007 2:01 PM > To: Khalil, Mohamed (RICH2:2S20); Mobile IPv6 Mailing List > Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 >=20 > So far there have not really been very strong reasons or > arguments to include the 4 byte header (Option 3). Please=20 > provide an explanation why the > 4 byte header is essential or benefits (or perceived) of doing so. >=20 > Without strong reasons or arguments for including the 4 byte > header (Option 3), the option of not doing anything in the=20 > scope of the MIP6 spec (ie option 1) makes sense. >=20 > -Raj >=20 >=20 > >> Hello, > >>=20 > >> The DS-MIP6 I-D > >> still has issue 93 open. This was discussed at IETF68. Vijay > >> presented 4 options to solve the issue. These are captured in: > >>=20 > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > >>=20 > >> We need to make a decision on this issue and move forward with the > >> I-D. At the meeting itself, I got the sense that option 3=20 > was the one > >> that had the least impact and easy to implement. > >>=20 > >> Please consider this email as a consensus call for issue 93. The=20 > >> problem and choices are as follows (based on Vijay's slides): > >>=20 > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > traversal. The > >> encapculations are either: > >> - IPv6-in-UDP-over-IPv4 > >> - IPv4-in-UDP-over-IPv4 > >> There is a need (or I guess desirable) to indicate the type of > >> protocol being encapsulated in the UDP header. > >>=20 > >> Choices are: > >> 1. Parse the protocol header following the UDP header 2. Reserve a=20 > >> UDP port for each protocol header (i.e one UDP port for > >> IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4=20 > >> etc.) 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > >> 4. Encapsulated protocol header type is indicated in the BU message > >>=20 > >> Pros and cons of these choices are in the slides that were > presented > >> at IETF68 (see URL above). > >>=20 > >> Please provide your opinions and comments by May 15th, 07 > on the MIP6 > >> mailing list. > >>=20 > >> -Raj > >>=20 > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 11 21:29:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmgQK-0002iP-DX; Fri, 11 May 2007 21:29:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmgQI-0002iK-BX for mip6@ietf.org; Fri, 11 May 2007 21:29:26 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmgQH-0007xn-RY for mip6@ietf.org; Fri, 11 May 2007 21:29:26 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.191.178.123]) by omta04sl.mx.bigpond.com with ESMTP id <20070512012919.USSE28583.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Sat, 12 May 2007 01:29:19 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070512012918.IYUQ16198.oaamta04sl.mx.bigpond.com@PC20005>; Sat, 12 May 2007 01:29:18 +0000 From: "Hesham Soliman" To: "'Ahmad Muhanna'" , "'Basavaraj Patil'" , "'Mohamed Khalil'" , "'Mobile IPv6 Mailing List'" Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Sat, 12 May 2007 11:29:11 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABzG+cgABYTWwAACPK0yAAAirNAAAz/yzA= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114332A46@zrc2hxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070512012918.IYUQ16198.oaamta04sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > My understanding that this option requires a reserved UDP > port. No? This > means that the TLV will be present only in the case when the > UDP port is > set to the reserved port. Correct? > If that the case, then if the UDP port is set otherwise, then peaking > into the payload is perfectly fine (option 1), or I am missing > something? => I think you missed one detail: There is *always* a reserved UDP port. In all options. It is not specific to option 3. Hesham > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Friday, May 11, 2007 2:01 PM > > To: Khalil, Mohamed (RICH2:2S20); Mobile IPv6 Mailing List > > Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > > > > So far there have not really been very strong reasons or > > arguments to include the 4 byte header (Option 3). Please > > provide an explanation why the > > 4 byte header is essential or benefits (or perceived) of doing so. > > > > Without strong reasons or arguments for including the 4 byte > > header (Option 3), the option of not doing anything in the > > scope of the MIP6 spec (ie option 1) makes sense. > > > > -Raj > > > > > > >> Hello, > > >> > > >> The DS-MIP6 I-D > > >> still has issue 93 open. This was discussed at IETF68. Vijay > > >> presented 4 options to solve the issue. These are captured in: > > >> > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > >> > > >> We need to make a decision on this issue and move > forward with the > > >> I-D. At the meeting itself, I got the sense that option 3 > > was the one > > >> that had the least impact and easy to implement. > > >> > > >> Please consider this email as a consensus call for issue 93. > > >> The problem and choices are as follows (based on > Vijay's slides): > > >> > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > traversal. The > > >> encapculations are either: > > >> - IPv6-in-UDP-over-IPv4 > > >> - IPv4-in-UDP-over-IPv4 > > >> There is a need (or I guess desirable) to indicate the type of > > >> protocol being encapsulated in the UDP header. > > >> > > >> Choices are: > > >> 1. Parse the protocol header following the UDP header 2. > > >> Reserve a UDP port for each protocol header (i.e one > UDP port for > > >> IPv6-in-UDP-over-IPv4 and another for > > >> IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port and a > > >> DS-MIP6 "tunnel type message" > > >> 4. Encapsulated protocol header type is indicated in > the BU message > > >> > > >> Pros and cons of these choices are in the slides that were > > presented > > >> at IETF68 (see URL above). > > >> > > >> Please provide your opinions and comments by May 15th, 07 > > on the MIP6 > > >> mailing list. > > >> > > >> -Raj > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > _______________________________________________ > > 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 From mip6-bounces@ietf.org Fri May 11 21:44:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmgei-0003bi-Sr; Fri, 11 May 2007 21:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmgeh-0003ba-Gr; Fri, 11 May 2007 21:44:19 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmgeh-00033n-0u; Fri, 11 May 2007 21:44:19 -0400 Received: from oaamta06sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070512014416.GBZI14178.omta01sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com>; Sat, 12 May 2007 01:44:16 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06sl.mx.bigpond.com with ESMTP id <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005>; Sat, 12 May 2007 01:44:15 +0000 From: "Hesham Soliman" To: "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" , Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Sat, 12 May 2007 11:44:12 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAAJ0SogAFi7P/YAEg5cQAAfOR18AAvywfA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I think there is some misunderstanding on this issue. Some people seem to think that there is no UDP port already allocated. I urge everyone to read the draft. Some answers to your comments inline: > > Whether you view it from an implementation perspective or > from protocol > design perspective, does it not make sense to have the > header indicate the > type of header or encapsulation that exists following the > parsing of a > header? => It certainly makes sense to to have a clear indication of the order of headers to the receiver. There are two ways of doing that: 1. Just define the format so that UDP is followed by IP (v4 or v6). This is effectively option 1 in your email. 2. Have a generic TLV to indicate the type of the header following UDP. This is effectively option 3. Honestly, the other two options are non-options, especially given George's email about option 4. The question is: when do you need 2) above? You obviously need it if there are many different things that can follow UDP and cannot all be parsed by simply reading the first byte. But this is not the case here because it's always IP. Now, I sent a separate email indicating that if someone wants to use GRE for PMIP reasons they can add the GRE header after IP and keep it transpared to the whole packet. So I don't see a reason for this "generic" header as flexible as it sounds, such flexibility is not needed. It is a matter of processing ease and clarity of the > encapsulated > packet type vs the overhead of 4 bytes on every packet. => The clarity is always there. I don't think the new header brings any thing new, it's only clearer on paper, an implementer would see no difference. > >> 2. Flexibility for future use > > Is the flexibility argument worth considering? Design the > protocol with > hooks for allowing it to be used in the case there exists > encapsulation of > packet types other than v4/v6 in the future... => Like I said, in general it sounds nice, but practically I don't see the need. There is a lot of nice and flexible things we can add but they're also wasteful by nature. I prefer to add things when needed. > > >> 3. Reuse 3519 (don't know if this was mentioned) > > > > => what do you mean by "reuse 3519"? You mean "make it > look like 3519"? > > That's not a reason though is it? > > Agree that its not a good reason. What I was implying was > that we could > learn from the 3519 experience and adopt a mechanism that > has worked well. => Ok. But this is not rocket science :) We know that either mechanism will work fine, but one of them will be 4 bytes heavier :) Hesham > > -Raj > > > > > Hesham > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat May 12 00:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmjaf-0000AM-9y; Sat, 12 May 2007 00:52:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmjae-00006g-40 for mip6@ietf.org; Sat, 12 May 2007 00:52:20 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmjac-0004ym-L8 for mip6@ietf.org; Sat, 12 May 2007 00:52:20 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4C4qF823806; Sat, 12 May 2007 04:52:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Fri, 11 May 2007 23:52:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114332FC3@zrc2hxm2.corp.nortel.com> In-Reply-To: <20070512012918.IYUQ16198.oaamta04sl.mx.bigpond.com@PC20005> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABzG+cgABYTWwAACPK0yAAAirNAAAz/yzAAAdCUcA== References: <6FC4416DDE56C44DA0AEE67BC7CA437114332A46@zrc2hxm2.corp.nortel.com> <20070512012918.IYUQ16198.oaamta04sl.mx.bigpond.com@PC20005> From: "Ahmad Muhanna" To: "Hesham Soliman" , "Basavaraj Patil" , "Mohamed Khalil" , "Mobile IPv6 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Thanks Hesham for pointing that out, I actually realized that a little late. I should have done more reading:(=20 But in this case and if optimization is a concern, Is it possible to reserve two different ports. One is used for option 1 when peaking in the payload is possible. Another Port is to be used to indicate the presence of the TLV. In other words, adopting both options 1 (optimization) and 3 (flexibility and forward compatibility). Can this be considered?=20 Regards, Ahmad =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Friday, May 11, 2007 8:29 PM > To: Muhanna, Ahmad (RICH1:2H10); 'Basavaraj Patil'; Khalil,=20 > Mohamed (RICH2:2S20); 'Mobile IPv6 Mailing List' > Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 > =20 >=20 > > My understanding that this option requires a reserved UDP =20 > > port. No? This > means that the TLV will be present only=20 > in the case when the > UDP port is > set to the reserved=20 > port. Correct? > > If that the case, then if the UDP port is set otherwise,=20 > then peaking > into the payload is perfectly fine (option=20 > 1), or I am missing > something? >=20 > =3D> I think you missed one detail: There is *always* a=20 > reserved UDP port. In all options. It is not specific to option 3.=20 >=20 > Hesham >=20 > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] =20 > > > Sent: Friday, May 11, 2007 2:01 PM > > To: Khalil,=20 > Mohamed (RICH2:2S20); Mobile IPv6 Mailing List > > Subject:=20 > Re: [Mip6] DS-MIP6: Consensus call to close issue 93 > > >=20 > > > > So far there have not really been very strong reasons=20 > or > > arguments to include the 4 byte header (Option 3).=20 > Please > > provide an explanation why the > > 4 byte header=20 > is essential or benefits (or perceived) of doing so. > > > > > > Without strong reasons or arguments for including the 4=20 > byte > > header (Option 3), the option of not doing anything=20 > in the > > scope of the MIP6 spec (ie option 1) makes sense. > > > > > > -Raj > > > > > > > > > >> Hello, > > > >> > > > >> The DS-MIP6 I-D > > > >> still has issue 93 open. This was discussed at=20 > IETF68. Vijay > > >> presented 4 options to solve the issue.=20 > These are captured in: > > > >> > > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > >> > > > >> We need to make a decision on this issue and move >=20 > forward with the > > >> I-D. At the meeting itself, I got=20 > the sense that option 3 > > was the one > > >> that had the=20 > least impact and easy to implement. > > > >> > > > >> Please consider this email as a consensus call for issue 93. > > > >> The problem and choices are as follows (based on >=20 > Vijay's slides): > > > >> > > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT=20 > > > traversal. The > > >> encapculations are either: > > > >> - IPv6-in-UDP-over-IPv4 > > > >> - IPv4-in-UDP-over-IPv4 > > > >> There is a need (or I guess desirable) to indicate=20 > the type of > > >> protocol being encapsulated in the UDP header. > > > >> > > > >> Choices are: > > > >> 1. Parse the protocol header following the UDP header 2. > > > >> Reserve a UDP port for each protocol header (i.e one =20 > > UDP port for > > > >> IPv6-in-UDP-over-IPv4 and another for > > > >> IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port=20 > and a > > >> DS-MIP6 "tunnel type message" > > > >> 4. Encapsulated protocol header type is indicated in =20 > > the BU message > > >> > > >> Pros and cons of these=20 > choices are in the slides that were > > presented > > >> at=20 > IETF68 (see URL above). > > > >> > > > >> Please provide your opinions and comments by May=20 > 15th, 07 > > on the MIP6 > > >> mailing list. > > > >> > > > >> -Raj > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat May 12 08:59:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmrCD-00055K-9C; Sat, 12 May 2007 08:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmrCC-00055F-3n for mip6@ietf.org; Sat, 12 May 2007 08:59:36 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmrCA-0006Vp-Au for mip6@ietf.org; Sat, 12 May 2007 08:59:36 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070512125931.NQVG25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Sat, 12 May 2007 12:59:31 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070512125930.QQM15903.oaamta07sl.mx.bigpond.com@PC20005>; Sat, 12 May 2007 12:59:30 +0000 From: "Hesham Soliman" To: "'Ahmad Muhanna'" , "'Basavaraj Patil'" , "'Mohamed Khalil'" , "'Mobile IPv6 Mailing List'" Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Sat, 12 May 2007 22:59:26 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiABzG+cgABYTWwAACPK0yAAAirNAAAz/yzAAAdCUcAAWPJwA In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114332FC3@zrc2hxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070512125930.QQM15903.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Thanks Hesham for pointing that out, I actually realized > that a little > late. I should have done more reading:( > > But in this case and if optimization is a concern, Is it possible to > reserve two different ports. One is used for option 1 when peaking in > the payload is possible. Another Port is to be used to indicate the > presence of the TLV. => That means that we have to specify two methods and require all HAs to implement both. I'm not in favour of that, but I think we're missing the step of explaining why we need to that in the first place. There is no compelling argument IMO to implement two different ways. Hesham > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Friday, May 11, 2007 8:29 PM > > To: Muhanna, Ahmad (RICH1:2H10); 'Basavaraj Patil'; Khalil, > > Mohamed (RICH2:2S20); 'Mobile IPv6 Mailing List' > > Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > > > > > > > My understanding that this option requires a reserved UDP > > > port. No? This > means that the TLV will be present only > > in the case when the > UDP port is > set to the reserved > > port. Correct? > > > If that the case, then if the UDP port is set otherwise, > > then peaking > into the payload is perfectly fine (option > > 1), or I am missing > something? > > > > => I think you missed one detail: There is *always* a > > reserved UDP port. In all options. It is not specific to option 3. > > > > Hesham > > > > > > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > Sent: Friday, May 11, 2007 2:01 PM > > To: Khalil, > > Mohamed (RICH2:2S20); Mobile IPv6 Mailing List > > Subject: > > Re: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > > > > > > So far there have not really been very strong reasons > > or > > arguments to include the 4 byte header (Option 3). > > Please > > provide an explanation why the > > 4 byte header > > is essential or benefits (or perceived) of doing so. > > > > > > > > Without strong reasons or arguments for including the 4 > > byte > > header (Option 3), the option of not doing anything > > in the > > scope of the MIP6 spec (ie option 1) makes sense. > > > > > > > > -Raj > > > > > > > > > > > > >> Hello, > > > > >> > > > > >> The DS-MIP6 I-D > > > > >> still has issue 93 open. This was discussed at > > IETF68. Vijay > > >> presented 4 options to solve the issue. > > These are captured in: > > > > >> > > > > >> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf > > > > >> > > > > >> We need to make a decision on this issue and move > > > forward with the > > >> I-D. At the meeting itself, I got > > the sense that option 3 > > was the one > > >> that had the > > least impact and easy to implement. > > > > >> > > > > >> Please consider this email as a consensus call for > issue 93. > > > > >> The problem and choices are as follows (based on > > > Vijay's slides): > > > > >> > > > > >> Problem: UDP encapsulation is used in DS-MIP6 for NAT > > > > traversal. The > > >> encapculations are either: > > > > >> - IPv6-in-UDP-over-IPv4 > > > > >> - IPv4-in-UDP-over-IPv4 > > > > >> There is a need (or I guess desirable) to indicate > > the type of > > >> protocol being encapsulated in the UDP header. > > > > >> > > > > >> Choices are: > > > > >> 1. Parse the protocol header following the UDP header 2. > > > > >> Reserve a UDP port for each protocol header (i.e one > > > UDP port for > > > > >> IPv6-in-UDP-over-IPv4 and another for > > > > >> IPv4-in-UDP-over-IPv4 etc.) 3. One reserved UDP port > > and a > > >> DS-MIP6 "tunnel type message" > > > > >> 4. Encapsulated protocol header type is indicated in > > > the BU message > > >> > > >> Pros and cons of these > > choices are in the slides that were > > presented > > >> at > > IETF68 (see URL above). > > > > >> > > > > >> Please provide your opinions and comments by May > > 15th, 07 > > on the MIP6 > > >> mailing list. > > > > >> > > > > >> -Raj > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> 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 > > > > > > > > > > > > _______________________________________________ > > > > 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 From mip6-bounces@ietf.org Sat May 12 11:41:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmtiD-0000tj-3F; Sat, 12 May 2007 11:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmtiB-0000sj-CL; Sat, 12 May 2007 11:40:47 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hmtgh-0008Sd-1g; Sat, 12 May 2007 11:39:16 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1178984354!16033391!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29080 invoked from network); 12 May 2007 15:39:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 12 May 2007 15:39:14 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4CFdD2M004681; Sat, 12 May 2007 08:39:14 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4CFdDf5019476; Sat, 12 May 2007 10:39:13 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-50.corp.mot.com [10.169.4.50]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4CFdAOu019469; Sat, 12 May 2007 10:39:11 -0500 (CDT) Message-ID: <4645DF9D.4050005@gmail.com> Date: Sat, 12 May 2007 17:39:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 References: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> In-Reply-To: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-3, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: [...] > => The clarity is always there. I don't think the new header brings > any thing new, it's only clearer on paper, an implementer would see > no difference. Hey, I agree with Hesham :-) It is sufficient to say in spec that the payload of the UDP packet is an IP packet that needs to be delivered back to the IP stack. This kind of behaviour is common in tunnelling implementations. If someone wants to write code about this, the pseudocode looks like this: void recv_packet (nb) { if (portnumber == DS-MIPv6) ip_input (nb - UDP_header) else udp_input (); return; } whereas the function with an intermediary layer would look like this: void recv_packet (nb { if (portnumber == DS-MIPv6) { parse_after_udp (nb); if (thin-layer says there's IP packet) ip_input (nb - UDP_header - thin-layer); else udp_input (); } return; } Remark more code (not only more headers). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat May 12 12:16:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmuGi-0006sJ-Fi; Sat, 12 May 2007 12:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmuGg-0006rv-Kl; Sat, 12 May 2007 12:16:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmuGg-00016r-4Z; Sat, 12 May 2007 12:16:26 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 May 2007 09:16:25 -0700 X-IronPort-AV: i="4.14,526,1170662400"; d="scan'208"; a="148131663:sNHT57432762" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4CGGPrf009676; Sat, 12 May 2007 09:16:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4CGGPaI001194; Sat, 12 May 2007 16:16:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 May 2007 09:16:24 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 May 2007 09:16:24 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" , "'Hesham Soliman'" References: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> <4645DF9D.4050005@gmail.com> Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Sat, 12 May 2007 09:16:24 -0700 Message-ID: <021c01c794b0$e2d42f60$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceUrBAsuOzsZrTFSLWTxTlPAe8REgAAfMaw In-Reply-To: <4645DF9D.4050005@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 12 May 2007 16:16:24.0606 (UTC) FILETIME=[E2F2B3E0:01C794B0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2414; t=1178986585; x=1179850585; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20DS-MIP6=3A=20Consensus=20call=20to=20close=2 0issue=2093 |Sender:=20; bh=3u7E6uOKaKe16jZ+UE/0cdJBORoz22FhrPbkoVaiHfc=; b=wiRDt8rvkM8TnADfeAAbc0LwfPzwGly6qW9Cnwo3Uwf4aHPKMumSOmr7XlWszAleVLz4pxiE rUfJod6djl187PIdXPY/iljrk7a2x5NV9B/LplDm3PoAL9ZRjsqA3mZB; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex: > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Saturday, May 12, 2007 8:39 AM > To: Hesham Soliman > Cc: nemo@ietf.org; 'Mobile IPv6 Mailing List' > Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 > > > Hey, I agree with Hesham :-) > > It is sufficient to say in spec that the payload of the UDP > packet is an > IP packet that needs to be delivered back to the IP stack. > This kind of > behaviour is common in tunnelling implementations. If > someone wants to > write code about this, the pseudocode looks like this: > > void > recv_packet (nb) > { > if (portnumber == DS-MIPv6) > ip_input (nb - UDP_header) > else > udp_input (); > return; > } > > whereas the function with an intermediary layer would look like this: > > void > recv_packet (nb > { > if (portnumber == DS-MIPv6) > { > parse_after_udp (nb); > if (thin-layer says there's IP packet) > ip_input (nb - UDP_header - thin-layer); > else > udp_input (); > } > return; > } > > Remark more code (not only more headers). 1 line of code is more code, for checking the type of the message, rather assuming its an IP packet ? Is this argument right ? Also, your psueo code is assuming in_input is handling both versions of the packet. In most implementations, the handlers are different. So, on the extra code you are talking about, you have to check either the type field of the TLV header or the 1st byte in the payload any case. How do you do the error handling for dropping 1st byte that is not IPv4 or IPv6. So, where is the extra code ? For one last time, GRE tunneling is widely used for the semantics it provides, GRE key field, seq number fields etc. MIP4 support GRE and IPIP for a reason. We need GRE for many reasons and also for NAT traversal. 3519 supports the same model. Instead of closing the doors and arguing on the use case, why cant this simple hook be provided and be bit more flexible. Leaving this 4-byte TLV header, allows us to add keepalive message, GRE header or some other tunneling header. What is the cost ? 1 or 0 lines of handling code ? 4-bytes in the packet ? Are we sending Max MTU packets ? In wireless tx, does it even matter ? Why cant we just follow 3519 convention ? Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat May 12 16:40:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmyNf-00066b-Gu; Sat, 12 May 2007 16:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmyNe-00066O-MS; Sat, 12 May 2007 16:39:54 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HmyNe-0004Mu-AN; Sat, 12 May 2007 16:39:54 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1179002392!9758035!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 15956 invoked from network); 12 May 2007 20:39:53 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-15.tower-128.messagelabs.com with SMTP; 12 May 2007 20:39:53 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l4CKdqZ9028627; Sat, 12 May 2007 15:39:52 -0500 (CDT) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l4CKdpmB025067; Sat, 12 May 2007 15:39:51 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.155]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l4CKdm3Y025058; Sat, 12 May 2007 15:39:49 -0500 (CDT) Message-ID: <46462613.8070303@gmail.com> Date: Sat, 12 May 2007 22:39:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 References: <20070512014415.WOIL28187.oaamta06sl.mx.bigpond.com@PC20005> <4645DF9D.4050005@gmail.com> <021c01c794b0$e2d42f60$d4f6200a@amer.cisco.com> In-Reply-To: <021c01c794b0$e2d42f60$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-3, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nemo@ietf.org, 'Mobile IPv6 Mailing List' , 'Alexandru Petrescu' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sri Gundavelli wrote: >> Hey, I agree with Hesham :-) >> >> It is sufficient to say in spec that the payload of the UDP packet >> is an IP packet that needs to be delivered back to the IP stack. >> This kind of behaviour is common in tunnelling implementations. If >> someone wants to write code about this, the pseudocode looks like >> this: >> >> void recv_packet (nb) { if (portnumber == DS-MIPv6) ip_input (nb - >> UDP_header) else udp_input (); return; } >> >> whereas the function with an intermediary layer would look like >> this: >> >> void recv_packet (nb { if (portnumber == DS-MIPv6) { >> parse_after_udp (nb); if (thin-layer says there's IP packet) >> ip_input (nb - UDP_header - thin-layer); else udp_input (); } >> return; } >> >> Remark more code (not only more headers). > > 1 line of code is more code, for checking the type of the message, > rather assuming its an IP packet ? Is this argument right ? We can go into compilation details to find out which kinds of lines take the more time to execute (and it's actually the 'if's). > Also, your psueo code is assuming in_input is handling both versions > of the packet. In most implementations, the handlers are different. Right... I meant generic. > So, on the extra code you are talking about, you have to check either > the type field of the TLV header or the 1st byte in the payload any > case. How do you do the error handling for dropping 1st byte that is > not IPv4 or IPv6. So, where is the extra code ? Ok... it was generic and pseudo. Everything can be implemented. We better discuss protocol. > For one last time, GRE tunneling is widely used for the semantics it > provides, GRE key field, seq number fields etc. MIP4 support GRE and > IPIP for a reason. Do you agree MIP4 can work without GRE? I have an implementation that does. > We need GRE for many reasons and also for NAT traversal. 3519 > supports the same model. 3519 supports both IP-in-UDP and GRE-in-UDP tunnelling. An implementer has the choice to implement only one of them and it will work fine. Proposing GRE to DS-MIPv6 is an invitation to interoperability issues (what if my MR does GRE-in-UDP) but your HA only does IP-in-UDP). Do we want to open the door to new interoperability issues by allowing GRE as an option? > Instead of closing the doors and arguing on the use case, why cant > this simple hook be provided and be bit more flexible. Leaving this > 4-byte TLV header, allows us to add keepalive message, Keepalive message can be done as a Mobile IP message type extension, doesn't need to be a new TLV or GRE. > GRE header or some other tunneling header. What is the cost ? Ok, let's talk cost in terms of interoperability, not lines of code/memory/bits on wire. I think there is a significant risk in adding GRE as an option to DS-MIPv6, in terms of interoperability. Alex > 1 or 0 lines of handling code ? 4-bytes in the packet ? Are we > sending Max MTU packets ? In wireless tx, does it even matter ? Why > cant we just follow 3519 convention ? > > Sri > > > > > > > > > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon May 14 10:04:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbAX-00042e-Sv; Mon, 14 May 2007 10:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbAW-00040B-6g; Mon, 14 May 2007 10:04:56 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbAV-0000rM-Pu; Mon, 14 May 2007 10:04:56 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4EE4pLo010930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 May 2007 07:04:52 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4EE4oKf025887; Mon, 14 May 2007 07:04:51 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 07:04:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] The use of GRE Date: Mon, 14 May 2007 07:04:27 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> In-Reply-To: <016001c7938c$d6695400$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzA= References: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au> <016001c7938c$d6695400$d4f6200a@amer.cisco.com> From: "Tsirtsis, George" To: "Sri Gundavelli" , "Hesham Soliman" , , X-OriginalArrivalTime: 14 May 2007 14:04:50.0494 (UTC) FILETIME=[D6844DE0:01C79630] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Folks, I have been trying to make sense of this discussion. After re-reading the whole thread I think we may be able to progress if we answer the following question: QUESTION: Does this group agree that GRE encapsulation needs to be supported in MIPv6? If the answer is "NO", then using the already defined UDP port and the IP version field to demux IPv4/IPv6 packets as already defined in DSMIPv6 is absolutely fine and there is no reason to change it. If the answer is "YES", then we have to consider the following: It is clear that the IP version field can not demux GRE. In that case: a) Leave GRE out of DSMIPv6 draft (which uses IP version field for demuxing). People interested in GRE should write up a draft defining how GRE is used in MIPv6. This is likely to result in a GRE specific method of encapsulation over UDP. This is likely to involve reservation of one more UDP port and the definition of a small pseudo-header as proposed by Sri and others. b) Be proactive and adopt the pseudo-header for all encapsulations. This would mean that DSMIPv6 draft is changed to indicate that over the reserved UDP port we add the TLV (or whatever structure) which indicates what the next header is i.e., IPv4, IPv6, GRE. =20 Personally, I am not a big fun of supporting GRE encapsulation for MIPv6. The reason is that in IPv6 we do not have (and must never have) to deal with overlapping address spaces (the main use of GRE tunneling in MIPv4).=20 Also note that even if we do decide to use the IP version field for demuxing now, there is nothing that prevents GRE encapsulation to be defined later, as indicated by (a) above, assuming that GRE support becomes necessary. Yes, then implementation will have to deal with two way of demuxing similar information but it is not the end of the world and it reduces the overhead (albeit not much) in the typical case. I hope this helps. Regards George -----Original Message----- From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 Sent: Friday, May 11, 2007 6:26 AM To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org Subject: RE: [Mip6] The use of GRE =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Thursday, May 10, 2007 10:20 PM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] The use of GRE >=20 > Hi all,=20 >=20 > This concensus call on issue 93 made me a bit confused about=20 > the use of GRE. > I have a simple question:=20 >=20 > Why can't people that want to use GRE (for PMIP) run it as follows: >=20 > IP Heahder (proto 47 for GRE) > GRE Header=20 > UDP > ....etc >=20 > Why do we need to add another layer to qualifiers instead of using the > existing allocated numbers? >=20 > It's been a couple of years since I read the GRE spec so I wanted to > understand if this format is a problem >=20 Problem will be with the NAT/PAT device. It wont create NAT bindings from the UDP header encapped in the GRE header. Sri _______________________________________________ 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 From mip6-bounces@ietf.org Mon May 14 10:13:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbIQ-0000FB-PM; Mon, 14 May 2007 10:13:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbIP-0000Bp-PJ; Mon, 14 May 2007 10:13:05 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbIP-0002Ba-8B; Mon, 14 May 2007 10:13:05 -0400 Received: from oaamta06sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070514141259.OQNZ14178.omta01sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com>; Mon, 14 May 2007 14:12:59 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta06sl.mx.bigpond.com with ESMTP id <20070514141258.UYKB28187.oaamta06sl.mx.bigpond.com@PC20005>; Mon, 14 May 2007 14:12:58 +0000 From: "Hesham Soliman" To: "'Tsirtsis, George'" , "'Sri Gundavelli'" , , Subject: RE: [Mip6] The use of GRE Date: Tue, 15 May 2007 00:12:54 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAANz40A== In-Reply-To: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070514141258.UYKB28187.oaamta06sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org George, That's exactly the point, I just wish this would have been made clear from the start instead of talking around the issue. I see no reason for needing GRE in v6, including MIPv6. Hesham > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Tuesday, May 15, 2007 12:04 AM > To: Sri Gundavelli; Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > Folks, > > I have been trying to make sense of this discussion. After re-reading > the whole thread I think we may be able to progress if we answer the > following question: > > QUESTION: Does this group agree that GRE encapsulation needs to be > supported in MIPv6? > > If the answer is "NO", then using the already defined UDP > port and the > IP version field to demux IPv4/IPv6 packets as already defined in > DSMIPv6 is absolutely fine and there is no reason to change it. > > If the answer is "YES", then we have to consider the following: > It is clear that the IP version field can not demux GRE. In > that case: > a) Leave GRE out of DSMIPv6 draft (which uses IP version field > for demuxing). People interested in GRE should write up a > draft defining > how GRE is used in MIPv6. This is likely to result in a GRE specific > method of encapsulation over UDP. This is likely to involve > reservation > of one more UDP port and the definition of a small pseudo-header as > proposed by Sri and others. > b) Be proactive and adopt the pseudo-header for all > encapsulations. This would mean that DSMIPv6 draft is changed to > indicate that over the reserved UDP port we add the TLV (or whatever > structure) which indicates what the next header is i.e., IPv4, IPv6, > GRE. > > > Personally, I am not a big fun of supporting GRE encapsulation for > MIPv6. The reason is that in IPv6 we do not have (and must > never have) > to deal with overlapping address spaces (the main use of GRE > tunneling > in MIPv4). > > Also note that even if we do decide to use the IP version field for > demuxing now, there is nothing that prevents GRE encapsulation to be > defined later, as indicated by (a) above, assuming that GRE support > becomes necessary. Yes, then implementation will have to > deal with two > way of demuxing similar information but it is not the end of > the world > and it reduces the overhead (albeit not much) in the typical case. > > I hope this helps. > Regards > George > > > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, May 11, 2007 6:26 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > > > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Thursday, May 10, 2007 10:20 PM > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] The use of GRE > > > > Hi all, > > > > This concensus call on issue 93 made me a bit confused about > > the use of GRE. > > I have a simple question: > > > > Why can't people that want to use GRE (for PMIP) run it as follows: > > > > IP Heahder (proto 47 for GRE) > > GRE Header > > UDP > > ....etc > > > > Why do we need to add another layer to qualifiers instead > of using the > > existing allocated numbers? > > > > It's been a couple of years since I read the GRE spec so I > wanted to > > understand if this format is a problem > > > > Problem will be with the NAT/PAT device. It wont create NAT bindings > from the UDP header encapped in the GRE header. > > Sri > > > > _______________________________________________ > 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 From mip6-bounces@ietf.org Mon May 14 13:43:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnea1-0002nO-Bs; Mon, 14 May 2007 13:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HneZz-0002nG-K5; Mon, 14 May 2007 13:43:27 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HneZy-0001QK-9H; Mon, 14 May 2007 13:43:27 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4EHhKug001986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 May 2007 10:43:20 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4EHhJlj019542; Mon, 14 May 2007 10:43:20 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 10:43:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] The use of GRE Date: Mon, 14 May 2007 10:42:21 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457A096@NAEX16.na.qualcomm.com> In-Reply-To: <02C627D961164445AFBC01BBDD0EC3245526DC@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAAZ+oYAAGjFpQ References: <5t7lbv$1bkrle@smtp05.syd.iprimus.net.au><016001c7938c$d6695400$d4f6200a@amer.cisco.com> <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <02C627D961164445AFBC01BBDD0EC3245526DC@DEEXC1U01.de.lucent.com> From: "Tsirtsis, George" To: "CASATI, Alessio (Alessio)" , "Sri Gundavelli" , "Hesham Soliman" , , X-OriginalArrivalTime: 14 May 2007 17:43:19.0592 (UTC) FILETIME=[5C25EA80:01C7964F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alessio, This is MIPv6, so I assume every mobile has a unique IPv6 Home Address. I think that (and NAT-traversal) guaranties that even if the same mobile has non-unique IPv4 addresses, routing works. I am not sure why GRE is needed for this....or is it? George -----Original Message----- From: CASATI, Alessio (Alessio) [mailto:acasati@alcatel-lucent.com]=20 Sent: Monday, May 14, 2007 6:13 PM To: Tsirtsis, George; Sri Gundavelli; Hesham Soliman; mip6@ietf.org; nemo@ietf.org Subject: RE: [Mip6] The use of GRE =20 *Folks, * *I have been trying to make sense of this discussion. After=20 *re-reading the whole thread I think we may be able to progress=20 *if we answer the following question: This is an excellent idea George! *QUESTION: Does this group agree that GRE encapsulation needs=20 *to be supported in MIPv6? YES *If the answer is "NO", then using the already defined UDP port=20 *and the IP version field to demux IPv4/IPv6 packets as already=20 *defined in *DSMIPv6 is absolutely fine and there is no reason to change it. Is port number sufficient to disambiguate a RFC 1918 "net 10"? (10.0.0.0/8). If not we need to answer Yes to the first question, most likely. Any views? Regards Alessio _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 15 00:29:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnof9-0001qH-VA; Tue, 15 May 2007 00:29:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnof6-0001q0-VH for mip6@ietf.org; Tue, 15 May 2007 00:29:24 -0400 Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnof5-0003AP-Gi for mip6@ietf.org; Tue, 15 May 2007 00:29:24 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 52E36382AF; Tue, 15 May 2007 06:29:22 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id EADB2382AB for ; Tue, 15 May 2007 06:29:21 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id D7B4037E46 for ; Tue, 15 May 2007 06:29:21 +0200 (CEST) Received: from [192.168.3.14] (helo=shiraz.levkowetz.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1Hnof2-0003Fw-IR for mip6@ietf.org; Tue, 15 May 2007 06:29:21 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Ahmad Muhanna Date: Tue, 15 May 2007 04:29:20 +0000 MIME-Version: 1.0 Message-Id: <1179203343.28.0.838421409432.issue101@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Rcpt-To: mip6@ietf.org X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=no version=3.1.7-deb X-SA-Exim-Version: 4.2.1 (built Tue, 03 Apr 2007 15:04:56 +0000) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Mip6] [issue101] A problem in setting SQN in the BA with status 135 which may cause Collision X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from Ahmad Muhanna : In response to a BU which contains an out of range sequence number, as per=20 sections 9.5.1 and 11.7.1, the CN or HA is allowed to send a BA with a stat= us=20 of 135 after inserting the last accepted sequence number received in the la= st=20 valid BU in the sequence number field (Different from the sequence number=20 received in the outstanding BU) According to MN processing of the BA as specified under section 11.7.3., th= e=20 MN will silently discard the received BA rather than picking the last accep= ted=20 sequence number and then generate a new sequence number.=20 I think the intention was to allow the HA or CN to communicate back to the = MN=20 the last accepted sequence number, however, we are breaking the protocol by=20 using this mechanism. This issue becomes critical in the case of PMIPv6 since the PMIP client wou= ld=20 have thousands of outstanding P-BU and the recieved P-BA most probably will=20 collide with another outstanding P-BU causing the PMIP client to drop the P= -BA=20 and contuinue to styay out of sync with the LMA/HA. Solution: I believe the most straightforward solution for this issue is to enable the=20 original intention opf RFC3775. i.e. by communicating back the last success= ful=20 sequenmce number in a option: Las Valid Sequence Number Mobility Option: 6=2E2.x. Last Valid Sequence Number The Last Valid Sequence Number option has an alignment requirement of 2n. Its format is as follows: 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=3DTBD | Length =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Valid Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Last Valid Sequence Number option is only valid in a BA, sent from the=20 mobile node's home agent in reply to a home registration, with a status of=20 135. The Last Valid Sequence Number is the last sequence number that the Ho= me=20 Agent received in the last successful Binding Update for the specified=20 session. In case the Home Agent receives a Binding Update with a sequence=20 number outside the valid sequence number range, the Home Agent sends a BA w= ith=20 a status of 135. HA must copy the sequence number from the BU into the=20 sequence number field of the BA. HA must include the last Valid Sequence=20 Number into the Last valid Sequence Number Mobility option. ---------- category: Technical draft: RFC3775 messages: 354 nosy: ahmad, bpatil, charles.perkins, sri, vijay priority: Must fix status: Pending title: A problem in setting SQN in the BA with status 135 which may cause C= ollision __________________________________________________ Mip6 issue tracker __________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 15 03:11:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnrBt-0005S0-Fp; Tue, 15 May 2007 03:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnrBr-0005Ro-LH; Tue, 15 May 2007 03:11:23 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnrBq-00047S-TH; Tue, 15 May 2007 03:11:23 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 May 2007 09:11:22 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4F7BMTY011027; Tue, 15 May 2007 09:11:22 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4F7BKDR023552; Tue, 15 May 2007 07:11:21 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 09:11:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] The use of GRE Date: Tue, 15 May 2007 09:11:14 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAAAV5eAAADg+IAAAgSHgAAA8zPAAAIS1MAAA6lwAAMmEb7A= References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com><5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> From: "Pascal Thubert \(pthubert\)" To: "Narayanan, Vidya" , "Hesham Soliman" , "Sri Gundavelli \(sgundave\)" , , X-OriginalArrivalTime: 15 May 2007 07:11:20.0843 (UTC) FILETIME=[3D39BDB0:01C796C0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6357; t=1179213082; x=1180077082; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[nemo]=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=+ahD7txqX32lxbmJP5znk84XDZ+d5tqG/WVpIXhSjDg=; b=AmsepvYzLlu49Cfd4D0MG7Fy7uI6cNCBPGStK0EU4pgR2DKVLlpIwU2Rg51bu/soqWOS94Qj OLptayq596lys1XxtljuRL2ZiRV4246X2nnfe+PeoueDwxFxf6DzM3QH; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya I think the discussion started with the idea of making the DSMIP tunnel more open to tunneling *anything*. This could be or have been done separately from DSMIP, for instance at the time of MIP6 or NEMO. If you look at it, all these protocols are tunnel set-up and maintenance protocols, with the HoA as the ID for the tunnel. So why tunnel only IPv6 in there?=20 That was (one of) Hesham's valid point(s) when he started his DS-MIP draft. So now we have support to tunnel IPv4, and we discriminate with protocol type. And the issue comes like is that all we'll ever need? Can't we make that more open for future use? And is this draft the right time for opening up? One question was, which future use?=20 One traditional use is L2 tunneling; if you want your MR to tunnel multiple flows treated as multiple VLANs in the mobile network, you might want to keep the VLANs up to the HA by inserting 802.1Q information, or the whole or compressed Ethernet packet in the MRHA tunnel. The L3 alternative (multiple VRFs) is much more complex to deploy on a MR. So I do agree with the original point that there will be multiple usages for that tunnel. At this point, I feel that we are back to a previous discussion on reverse Routability test: in traditional MIP or NEMO (without SeND) the MR can not be sure of its CoA, and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP the right place to solve a problem that was already there? =20 I suspect that we have made some clear room for a number of small drafts that will apply to all MIP, DS-MIP and NEMO, to improve the security of the system or like in this case make it more open to the future. The new drafts will have to cope with existing protocols, including IPv6 in the MIP6 tunnel without GRE which is already a fact of life. My own suggestion is to be ready to receive these drafts as new WG items and carry them out swiftly, but not make a dependency for DS MIP on these discussions, either. DS-MIP has been pretty stable for a while, and the recent changes that were discussed (like the mapped CoA) were more on the religious side than fixing practical problems.=20 Pascal >-----Original Message----- >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >Sent: Friday, May 11, 2007 8:38 AM >To: Hesham Soliman; Sri Gundavelli (sgundave); mip6@ietf.org; nemo@ietf.org >Subject: RE: [nemo] RE: [Mip6] The use of GRE > >I'm confused by this thread - could someone explain the role of GRE for >NEMO? From everything I've read so far on this thread, I'm with Hesham >here - I don't understand why we need GRE to parse the multiple flows >sent in the MR's tunnel. > >Vidya > >> -----Original Message----- >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >> Sent: Thursday, May 10, 2007 11:21 PM >> To: 'Sri Gundavelli'; mip6@ietf.org; nemo@ietf.org >> Subject: [nemo] RE: [Mip6] The use of GRE >> >> Sri, >> >> > > > >> > > > We dont have to justify this just for PMIP. Its just >> another > > > consumer, like NEMO. IMO, having a thin >> header, always helps, > > > follows the conventional way of >> tagging. >> > > >> > > =3D> My problem here is that you're not giving me any >> concrete > > reasons for a > > use case. >> > > Just saying "always helps" doesn't make me understand > >> > something new. There > > is only two IP versions today and >> this is not going to change > > till you and I > > retire, >> so I don't find this flexibility argument realistic. >> > > >> > >> > >> > GRE header is applicable when flows from multiple nodes >> are carried > in the same tunnel. That's not the case for >> 3775 MN flows, but indeed > is the case for 3963. The GRE >> header has the proper semantics that > allows tunnel peers >> to process properly. The seq number in the header > is >> useful when carrying real time traffic. Is this not a > good reason ? >> >> =3D> This is a classic example of hacks that lingered for such >> long time that it grew on people and they thought it's just >> the "normal" way of doing things. >> I think your arguments above are quite confused about GRE. >> It's like the very common arguments about NATs being good for >> security. >> The need for another abstraction layer for tunnelling was >> only to support virtual routing, especially for environments >> that conntain overlapping IPv4 addresses. >> >> Everything else you talk about above is available in IP and >> transport headers; and I won't even get into QoS for IP >> flows. You seem to think that this is a special case for nemo >> because there can be "many flows", which is not the case in a >> 3775 MN. This is clearly a confused view of things because a >> MN can of course generate many flows, from different >> addresses ....etc ....sigh >> >> > Now, if you say there is no GRE tunneling for MIP6, off >> course, thats > where I say, there is a chance we will >> introduce GRE tunnel mode > for NEMO use cases in mind, >> learnt from the experience of supporting > NEMOv4 >> deployments and applications. >> >> =3D> I think I've said enough on this. I don't think I can add >> any more. I honestly think what you're listing above is >> either confused or a case of you wanting everyone else to fit >> some idea in your mind, which we don't know. >> >> >> >> Sure, supporting GRE mode helps >> > PMIP as well, I agree, if we apply it there. Second >> reason, I give > is the convention that has been followed in >> all protocol designs so > far, of prev header identifying >> the next header. No protocol > is mucking > around in the >> payloads to determine the type. >> >> =3D> Mucking around? There is a very well known encoding >> mechanism called TLV where you have to inspect the first byte >> to know the type of information following it. I don't think >> that's referred to as mucking around, at least not in specs.. ;0 >> >> enuff said from me. >> Hesham >> >> Are these not good >> > reasons ? Do they outweigh the 4 byte saving ? Again, this >> is my > opinion. We can let others comment on this. >> > >> > >> > Sri >> > >> >> >> > >_______________________________________________ >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 From mip6-bounces@ietf.org Tue May 15 06:21:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnu9R-0000rP-Mo; Tue, 15 May 2007 06:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnu9Q-0000rH-SR; Tue, 15 May 2007 06:21:04 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnu9P-0007ct-DW; Tue, 15 May 2007 06:21:04 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070515102054.MFYC25724.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Tue, 15 May 2007 10:20:54 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta05sl.mx.bigpond.com with ESMTP id <20070515102054.JUIN7523.oaamta05sl.mx.bigpond.com@PC20005>; Tue, 15 May 2007 10:20:54 +0000 From: "Hesham Soliman" To: "'CASATI, Alessio \(Alessio\)'" , "'Tsirtsis, George'" , "'Sri Gundavelli'" , , Subject: RE: [Mip6] The use of GRE Date: Tue, 15 May 2007 20:20:46 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <02C627D961164445AFBC01BBDD0EC324552868@DEEXC1U01.de.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAAZ+oYAAGjFpQACELrbAAAbz04A== Message-Id: <20070515102054.JUIN7523.oaamta05sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alessio, Regardless of whether the packet is carrying IPv4 or IPv6, there is always a unique identifier in the packet, i.e. the IPv6 address. Overlapping addresses are only an issue when both the outer and inner addresses are private IPv4 addresses. But in this case the question is: where do you use GRE? Is GRE supported on your windows PC or your mobile phone? I don't think it is. So, it is natural to handle that in the network. I.e. from the FA (or v4-only AR) upwards in v4. To answer your question, I do believe GRE is useful for overlapping IP addresses to match a key to a VRF instance, but this is not what we're doing here. Hesham > -----Original Message----- > From: CASATI, Alessio (Alessio) [mailto:acasati@alcatel-lucent.com] > Sent: Tuesday, May 15, 2007 8:06 PM > To: Tsirtsis, George; Sri Gundavelli; Hesham Soliman; > mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > *Alessio, > * > *This is MIPv6, so I assume every mobile has a unique IPv6 > Home Address. > > I assume we are addressing the issue of carrying IPv4 in DSMIPv6, not > vanilla MIPv6 operation. > I agree that if there is a globally unique/routable(v6 or v4) address > carried in the "tunnel" then > there is no need of GRE (like there was no need in MIPv4 for that > matter, when a public IP address is used). > However, when private addresses are used, and we want to carry IPv4 > packets with private > Addresses encapsulated in v6 or v4, then the same issue arises as in > MIPv4, that is we need a field to > disambiguate private addresses. Does anyone know why GRE was > introduced > in MIPv4? Was it as a past time or because > there was a requirement? If there was a requirement then, can this go > away just because time has gone by? > I am just curious, as this may help in solving this case. > > (BTW, I hope we are discussing the same thing, since I am not sure > whether you mean this thread to be for vanilla MIPv6 > with v6 only operation, and not for DSMIPv6...) > > > Regards > Alessio > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 15 07:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvST-0005m3-Uu; Tue, 15 May 2007 07:44:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvSS-0005lv-1H; Tue, 15 May 2007 07:44:48 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnvSR-0005o5-8k; Tue, 15 May 2007 07:44:48 -0400 Received: from oaamta07sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070515114444.QGKN25724.omta05sl.mx.bigpond.com@oaamta07sl.mx.bigpond.com>; Tue, 15 May 2007 11:44:44 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta07sl.mx.bigpond.com with ESMTP id <20070515114444.JBAO15903.oaamta07sl.mx.bigpond.com@PC20005>; Tue, 15 May 2007 11:44:44 +0000 From: "Hesham Soliman" To: "'CASATI, Alessio \(Alessio\)'" , "'Tsirtsis, George'" , "'Sri Gundavelli'" , , Subject: RE: [Mip6] The use of GRE Date: Tue, 15 May 2007 21:44:36 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <02C627D961164445AFBC01BBDD0EC3245528C4@DEEXC1U01.de.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAAZ+oYAAGjFpQACELrbAAAbz04AAAQQfgAAGqCVA= Message-Id: <20070515114444.JBAO15903.oaamta07sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > I do agree that the main domain of application is PMIPv6 and this VRF > instance case you mention. > Is it the case PIMIPv6 support for v4 derives from DSMIPv6, then? => I don't know that it's applicable to the same scenarios. NETLMM assumed that v6 support is available in the client (AR), otherwise it's very strange to not design PMIPv4 :). Also, there is an assumption of the use of the MN_ID, which is unique. So one could either tag packets with the MN_ID or use GRE. Now, you could use GRE directly after the IP header as I suggested before. If all of that is insufficient (and I don't know why that would be the case) then, as already mentioned by George and Pascal, NETLMM can decide to do its extensions to support GRE *after* the UDP header. But there is no reason for us to mandate this feature in this spec when we clearly don't need it. It makes more sense to extend the spec for those specific cases that need it; *if* they need it. > > On support of GRE at MN, I am not sure whether concurrent access to 2 > IPv4 nets sharing the same HA address (so supported via 2 > VRFs on same > router) and with overlapping IP addresses should be > considered, as part > of use cases. > But if it was, then the case for a mux field in DSMIP at MN > should also > be assessed, as u rightly point out. => The scenario was not considered, but I don't think considering that scenario would automatically imply GRE from the host. If an ISP hosting an HA uses overlapping addresses and assumes such overlap in visited networks then I can't see how it would always rely on the host to do the job. In fixed (and mobile AFAIK) networks this scenario may happen in a wholesale/retail type split (unlikely in the fixed case though), in which case the tunnel back to the HA must be done by the visited network anyway. So I don't think there is an automatic relationship between where the tunnel starts and the existence of overlapping addresses, although I agree that it is a possible option. But realistically speaking, this support on the host doesn't exist and as we move to IPv6 it sure won't be needed, so it's strange to consider it in a standard at this stage. As we move away from band aid solutions in private addressing deployments, I hope we can leave those legacy band aids somewhere in the history alleys and avoid bringing them (in terms of development baggage) to new deployments, where they are not needed. Hesham > > Regards > Alessio > > *-----Original Message----- > *From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > *Sent: 15 May 2007 11:21 > *To: CASATI, Alessio (Alessio); 'Tsirtsis, George'; 'Sri > *Gundavelli'; mip6@ietf.org; nemo@ietf.org > *Subject: RE: [Mip6] The use of GRE > * > *Alessio, > * > *Regardless of whether the packet is carrying IPv4 or IPv6, > *there is always a unique identifier in the packet, i.e. the > *IPv6 address. Overlapping addresses are only an issue when > *both the outer and inner addresses are private IPv4 addresses. > *But in this case the question is: where do you use GRE? Is GRE > *supported on your windows PC or your mobile phone? I don't > *think it is. So, it is natural to handle that in the network. > *I.e. from the FA (or v4-only AR) upwards in v4. > * > *To answer your question, I do believe GRE is useful for > *overlapping IP addresses to match a key to a VRF instance, but > *this is not what we're doing here. > * > *Hesham > * > * > * > * > -----Original Message----- > * > From: CASATI, Alessio (Alessio) > [mailto:acasati@alcatel-lucent.com] > * > Sent: Tuesday, May 15, 2007 8:06 PM > * > To: Tsirtsis, George; Sri Gundavelli; Hesham Soliman; > > *mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of > *GRE > > *Alessio, > * > *This is MIPv6, so I assume every > *mobile has a unique IPv6 > Home Address. > * > > * > I assume we are addressing the issue of carrying IPv4 in > *DSMIPv6, not > vanilla MIPv6 operation. > * > I agree that if there is a globally unique/routable(v6 or > *v4) address > carried in the "tunnel" then > there is no > *need of GRE (like there was no need in MIPv4 for that > > *matter, when a public IP address is used). > * > However, when private addresses are used, and we want to > *carry IPv4 > packets with private > Addresses encapsulated > *in v6 or v4, then the same issue arises as in > MIPv4, that > *is we need a field to > disambiguate private addresses. Does > *anyone know why GRE was > introduced > in MIPv4? Was it as a > *past time or because > there was a requirement? If there was > *a requirement then, can this go > away just because time > has gone by? > * > I am just curious, as this may help in solving this case. > * > > * > (BTW, I hope we are discussing the same thing, since I am > *not sure > whether you mean this thread to be for vanilla > *MIPv6 > with v6 only operation, and not for DSMIPv6...) > > > * > Regards > Alessio > > * > * > * > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 15 07:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvdO-0001W1-Bb; Tue, 15 May 2007 07:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvdM-0001VK-7R; Tue, 15 May 2007 07:56:04 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HnvdJ-0000JG-TL; Tue, 15 May 2007 07:56:04 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1179230159!16126037!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24890 invoked from network); 15 May 2007 11:55:59 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 15 May 2007 11:55:59 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4FBtwIt014033; Tue, 15 May 2007 04:55:58 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l4FBtvhO003449; Tue, 15 May 2007 06:55:57 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l4FBts7o003358; Tue, 15 May 2007 06:55:54 -0500 (CDT) Message-ID: <46499FC4.5030506@gmail.com> Date: Tue, 15 May 2007 13:55:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: [nemo] RE: [Mip6] The use of GRE) References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com><5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-3, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: nemo@ietf.org, mip6@ietf.org, "Sri Gundavelli \(sgundave\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Vidya > > I think the discussion started with the idea of making the DSMIP > tunnel more open to tunneling *anything*. This could be or have been > done separately from DSMIP, for instance at the time of MIP6 or NEMO. > If you look at it, all these protocols are tunnel set-up and > maintenance protocols, with the HoA as the ID for the tunnel. So why > tunnel only IPv6 in there? > > That was (one of) Hesham's valid point(s) when he started his DS-MIP > draft. So now we have support to tunnel IPv4, and we discriminate > with protocol type. And the issue comes like is that all we'll ever > need? Can't we make that more open for future use? And is this draft > the right time for opening up? > > One question was, which future use? > > One traditional use is L2 tunneling; IMHO it is not a good idea to tunnel L3 in L2 in L3 and in L2. This is an architectural mistake: IPv6-MACheader-IPv4-MACheader. I think this is what you are proposing with encapsulating L2 tunnelling in GRE, is it so? > if you want your MR to tunnel multiple flows treated as multiple > VLANs in the mobile network, you might want to keep the VLANs up to > the HA by inserting 802.1Q information, or the whole or compressed > Ethernet packet in the MRHA tunnel. I think it is not a good idea to intersperse an L2 header between two IPv6 base headers. I think it is not good idea to propagate 802.1q information between MR and HA. > The L3 alternative (multiple VRFs) is much more complex to deploy on > a MR. I am not sure what you mean. What is VRF? Also, the L3 alternative (using NEMOv6 base spec and not using L2 headers between base IPv6 headers), is implemented widely. I am not sure why you say it is much more complex. > So I do agree with the original point that there will be multiple > usages for that tunnel. At this point, I feel that we are back to a > previous discussion on reverse Routability test: in traditional MIP > or NEMO (without SeND) the MR can not be sure of its CoA, What do you mean? Do you mean that NEMOv6+SeND is not enough for securing MR ownership of its Care-of Address? And that NEMOv6+GRE encapsulation (instead of IPv6-in-IPv6) will make sure MR has a safe Care-of Address? > and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP the > right place to solve a problem that was already there? Good question. I agree the security model with DS-MIPv6 and IPv4 Care-of Addresses is different than simple NEMOv6. But I don't see GRE a solution here. Why do you see GRE as a security solution for DS-MIPv6? If HoA is used for identitying IP tunnels then IPsec SAs can link these HoAs, because HoA is an IP address. On the contrary, if GRE key is used to identify tunnels then GRE key can not be used with IPsec SAs. Besides, I don't think there exist protocol selectors for GRE headers. > I suspect that we have made some clear room for a number of small > drafts that will apply to all MIP, DS-MIP and NEMO, to improve the > security of the system or like in this case make it more open to the > future. The new drafts will have to cope with existing protocols, > including IPv6 in the MIP6 tunnel without GRE which is already a fact > of life. I agree MIP6 tunnel without GRE is already a fact of life. But I don't see how GRE improves security of MIP6, DS-MIPv6 or NEMO. > My own suggestion is to be ready to receive these drafts as new WG > items and carry them out swiftly, but not make a dependency for DS > MIP on these discussions, either. DS-MIP has been pretty stable for a > while, and the recent changes that were discussed (like the mapped > CoA) were more on the religious side than fixing practical problems. Ok, somehow agree. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 15 12:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnznA-0007iB-2V; Tue, 15 May 2007 12:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnzn9-0007ev-D8; Tue, 15 May 2007 12:22:27 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnzn6-0003sU-Ub; Tue, 15 May 2007 12:22:27 -0400 Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 16 May 2007 10:43:40 +0530 X-IronPort-AV: i="4.14,538,1170613800"; d="scan'208"; a="80137065:sNHT80381126" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4FGMKFo019748; Wed, 16 May 2007 00:22:20 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4FGM6q2013750; Tue, 15 May 2007 16:22:10 GMT Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 00:22:05 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] The use of GRE Date: Wed, 16 May 2007 00:22:00 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAANlAPIA== From: "Yoshi Tsuda \(yotsuda\)" To: "Tsirtsis, George" , "Sri Gundavelli \(sgundave\)" , "Hesham Soliman" , , X-OriginalArrivalTime: 15 May 2007 16:22:05.0956 (UTC) FILETIME=[2DA5D440:01C7970D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4636; t=1179246140; x=1180110140; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=yotsuda@cisco.com; z=From:=20=22Yoshi=20Tsuda=20\(yotsuda\)=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=R5LZUC/wGxGSxYK/cQSV0r7CSDFLCDgHAdIyZHxaE2M=; b=Djr0caALh2TrMtysCG7k3z9h7cURSn4eg94bfioU3EOTDJwCR7zbFg4PK+EFsnjXcUhwNMk1 MeAp3WWtbLDesyaXtHZiaHN09vF42i2UUvQX+tLEqDb7lHgwc2xFaq0LQossJ2i9zVB9nEJORR tv96uoY6LdYU1kNw9DYe/F5bI=; Authentication-Results: hkg-dkim-2; header.From=yotsuda@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: yoshi@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi George, > Personally, I am not a big fun of supporting GRE=20 > encapsulation for MIPv6. The reason is that in IPv6 we do not=20 > have (and must never have) to deal with overlapping address=20 > spaces (the main use of GRE tunneling in MIPv4).=20 I'm afraid, you might be missing the main use of GRE tunneling in MIPv4. The main use of GRE tunneling in MIPv4 - is NOT to deal with overlapping address spaces, - but to encapsulate any "Protocol type" of packets. In past, when I was implementing various MIPv4 MNs, I was told to implement GRE tunneling by many voices of customers to encapsulate TCP/IPv4, AppleTalk, or whatever protocol suites without worrying about used "Protocol type"s... Thanks. -Yoshi (in Cisco) > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Monday, May 14, 2007 11:04 PM > To: Sri Gundavelli (sgundave); Hesham Soliman; mip6@ietf.org;=20 > nemo@ietf.org > Subject: RE: [Mip6] The use of GRE >=20 > Folks, >=20 > I have been trying to make sense of this discussion. After=20 > re-reading the whole thread I think we may be able to=20 > progress if we answer the following question: >=20 > QUESTION: Does this group agree that GRE encapsulation needs=20 > to be supported in MIPv6? >=20 > If the answer is "NO", then using the already defined UDP=20 > port and the IP version field to demux IPv4/IPv6 packets as=20 > already defined in > DSMIPv6 is absolutely fine and there is no reason to change it. >=20 > If the answer is "YES", then we have to consider the following: > It is clear that the IP version field can not demux GRE. In that case: > a) Leave GRE out of DSMIPv6 draft (which uses IP=20 > version field for demuxing). People interested in GRE should=20 > write up a draft defining how GRE is used in MIPv6. This is=20 > likely to result in a GRE specific method of encapsulation=20 > over UDP. This is likely to involve reservation of one more=20 > UDP port and the definition of a small pseudo-header as=20 > proposed by Sri and others. > b) Be proactive and adopt the pseudo-header for all=20 > encapsulations. This would mean that DSMIPv6 draft is changed=20 > to indicate that over the reserved UDP port we add the TLV=20 > (or whatever > structure) which indicates what the next header is i.e.,=20 > IPv4, IPv6, GRE. > =20 >=20 > Personally, I am not a big fun of supporting GRE=20 > encapsulation for MIPv6. The reason is that in IPv6 we do not=20 > have (and must never have) to deal with overlapping address=20 > spaces (the main use of GRE tunneling in MIPv4).=20 >=20 > Also note that even if we do decide to use the IP version=20 > field for demuxing now, there is nothing that prevents GRE=20 > encapsulation to be defined later, as indicated by (a) above,=20 > assuming that GRE support becomes necessary. Yes, then=20 > implementation will have to deal with two way of demuxing=20 > similar information but it is not the end of the world and it=20 > reduces the overhead (albeit not much) in the typical case. >=20 > I hope this helps. > Regards > George >=20 >=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, May 11, 2007 6:26 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE >=20 > =20 >=20 > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Thursday, May 10, 2007 10:20 PM > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] The use of GRE > >=20 > > Hi all, > >=20 > > This concensus call on issue 93 made me a bit confused=20 > about the use=20 > > of GRE. > > I have a simple question:=20 > >=20 > > Why can't people that want to use GRE (for PMIP) run it as follows: > >=20 > > IP Heahder (proto 47 for GRE) > > GRE Header > > UDP > > ....etc > >=20 > > Why do we need to add another layer to qualifiers instead=20 > of using the=20 > > existing allocated numbers? > >=20 > > It's been a couple of years since I read the GRE spec so I=20 > wanted to=20 > > understand if this format is a problem > >=20 >=20 > Problem will be with the NAT/PAT device. It wont create NAT=20 > bindings from the UDP header encapped in the GRE header. >=20 > Sri >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 05:07:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoFTh-0001rg-UB; Wed, 16 May 2007 05:07:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoFTf-0001r5-VU; Wed, 16 May 2007 05:07:24 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoFTe-0001QT-DU; Wed, 16 May 2007 05:07:23 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4G97HPB023713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 May 2007 02:07:17 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4G97G4w005603; Wed, 16 May 2007 02:07:17 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 02:07:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] The use of GRE Date: Wed, 16 May 2007 02:07:14 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> In-Reply-To: <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAANlAPIAACy75g References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> From: "Tsirtsis, George" To: "Yoshi Tsuda (yotsuda)" , "Sri Gundavelli (sgundave)" , "Hesham Soliman" , , X-OriginalArrivalTime: 16 May 2007 09:07:16.0685 (UTC) FILETIME=[99A4BFD0:01C79799] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: yoshi@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Yoshi, Yes, you are right in that GRE does allow any protocol to go over it, and I was not aware that this use of GRE is common in combination with Mobile IP. I will take your work for it though. If people feel that GRE is indeed important for MIPv6 then, I wonder if it is a good idea to just add a "hook" for GRE support in DSMIPv6 draft. Would it not be better to add GRE encapsulation on MIPv6 more properly, and deal with how it is signaled, how GRE key management is done, how GRE tunneling is used over IPv4 or IPv6 tunneling, and possibly other issues?=20 Maybe it is just me but somehow I feel that DSMIPv6 has already become too big and a kind of a kitchen-sink draft for a lot of different things. Regards George -----Original Message----- From: Yoshi Tsuda (yotsuda) [mailto:yotsuda@cisco.com]=20 Sent: Tuesday, May 15, 2007 5:22 PM To: Tsirtsis, George; Sri Gundavelli (sgundave); Hesham Soliman; mip6@ietf.org; nemo@ietf.org Cc: yoshi@cisco.com Subject: RE: [Mip6] The use of GRE Hi George, > Personally, I am not a big fun of supporting GRE=20 > encapsulation for MIPv6. The reason is that in IPv6 we do not=20 > have (and must never have) to deal with overlapping address=20 > spaces (the main use of GRE tunneling in MIPv4).=20 I'm afraid, you might be missing the main use of GRE tunneling in MIPv4. The main use of GRE tunneling in MIPv4 - is NOT to deal with overlapping address spaces, - but to encapsulate any "Protocol type" of packets. In past, when I was implementing various MIPv4 MNs, I was told to implement GRE tunneling by many voices of customers to encapsulate TCP/IPv4, AppleTalk, or whatever protocol suites without worrying about used "Protocol type"s... Thanks. -Yoshi (in Cisco) > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Monday, May 14, 2007 11:04 PM > To: Sri Gundavelli (sgundave); Hesham Soliman; mip6@ietf.org;=20 > nemo@ietf.org > Subject: RE: [Mip6] The use of GRE >=20 > Folks, >=20 > I have been trying to make sense of this discussion. After=20 > re-reading the whole thread I think we may be able to=20 > progress if we answer the following question: >=20 > QUESTION: Does this group agree that GRE encapsulation needs=20 > to be supported in MIPv6? >=20 > If the answer is "NO", then using the already defined UDP=20 > port and the IP version field to demux IPv4/IPv6 packets as=20 > already defined in > DSMIPv6 is absolutely fine and there is no reason to change it. >=20 > If the answer is "YES", then we have to consider the following: > It is clear that the IP version field can not demux GRE. In that case: > a) Leave GRE out of DSMIPv6 draft (which uses IP=20 > version field for demuxing). People interested in GRE should=20 > write up a draft defining how GRE is used in MIPv6. This is=20 > likely to result in a GRE specific method of encapsulation=20 > over UDP. This is likely to involve reservation of one more=20 > UDP port and the definition of a small pseudo-header as=20 > proposed by Sri and others. > b) Be proactive and adopt the pseudo-header for all=20 > encapsulations. This would mean that DSMIPv6 draft is changed=20 > to indicate that over the reserved UDP port we add the TLV=20 > (or whatever > structure) which indicates what the next header is i.e.,=20 > IPv4, IPv6, GRE. > =20 >=20 > Personally, I am not a big fun of supporting GRE=20 > encapsulation for MIPv6. The reason is that in IPv6 we do not=20 > have (and must never have) to deal with overlapping address=20 > spaces (the main use of GRE tunneling in MIPv4).=20 >=20 > Also note that even if we do decide to use the IP version=20 > field for demuxing now, there is nothing that prevents GRE=20 > encapsulation to be defined later, as indicated by (a) above,=20 > assuming that GRE support becomes necessary. Yes, then=20 > implementation will have to deal with two way of demuxing=20 > similar information but it is not the end of the world and it=20 > reduces the overhead (albeit not much) in the typical case. >=20 > I hope this helps. > Regards > George >=20 >=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, May 11, 2007 6:26 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE >=20 > =20 >=20 > > -----Original Message----- > > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > > Sent: Thursday, May 10, 2007 10:20 PM > > To: mip6@ietf.org; nemo@ietf.org > > Subject: [Mip6] The use of GRE > >=20 > > Hi all, > >=20 > > This concensus call on issue 93 made me a bit confused=20 > about the use=20 > > of GRE. > > I have a simple question:=20 > >=20 > > Why can't people that want to use GRE (for PMIP) run it as follows: > >=20 > > IP Heahder (proto 47 for GRE) > > GRE Header > > UDP > > ....etc > >=20 > > Why do we need to add another layer to qualifiers instead=20 > of using the=20 > > existing allocated numbers? > >=20 > > It's been a couple of years since I read the GRE spec so I=20 > wanted to=20 > > understand if this format is a problem > >=20 >=20 > Problem will be with the NAT/PAT device. It wont create NAT=20 > bindings from the UDP header encapped in the GRE header. >=20 > Sri >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 08:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoISp-0007l6-BV; Wed, 16 May 2007 08:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoISm-0007bD-U2; Wed, 16 May 2007 08:18:40 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoISm-0007GS-Jk; Wed, 16 May 2007 08:18:40 -0400 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id 08D96305EC; Wed, 16 May 2007 14:18:28 +0200 (CEST) From: Pars Mutaf To: int-area@lists.ietf.org, mip6@ietf.org, ipv6@ietf.org, namedroppers-request@ops.ietf.org Content-Type: text/plain Organization: INT Evry Date: Wed, 16 May 2007 14:18:28 +0200 Message-Id: <1179317908.5004.30.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Mip6] Private Information Queries (PIQ) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org [sorry for cross-posting] Hello, FYI the following I-D suggests replacing the phone book for cellular phones, with an end-to-end approach (cell phone number is requested from the target cell phone). http://www.ietf.org/internet-drafts/draft-mutaf-piqproblem-01.txt -Problem statement probably done (Section 1), -Abstract solution done, -There is also some new discussion on bootstrapping IKE using PIQ. Comments are welcome to the int-area ML. Thanks pars mutaf _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 11:39:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLbX-0006Eg-BU; Wed, 16 May 2007 11:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLbV-0006ER-Kv; Wed, 16 May 2007 11:39:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoLbU-0002fA-BD; Wed, 16 May 2007 11:39:53 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 16 May 2007 08:39:51 -0700 X-IronPort-AV: i="4.14,544,1170662400"; d="scan'208"; a="422581328:sNHT449709554" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4GFdpjF023519; Wed, 16 May 2007 08:39:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4GFdkaK025004; Wed, 16 May 2007 15:39:47 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 08:39:46 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 08:39:46 -0700 From: "Sri Gundavelli" To: "'Tsirtsis, George'" , "'Yoshi Tsuda \(yotsuda\)'" , "'Hesham Soliman'" , , References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> Subject: RE: [Mip6] The use of GRE Date: Wed, 16 May 2007 08:39:42 -0700 Message-ID: <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAANlAPIAACy75gAC65H4A= In-Reply-To: <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 16 May 2007 15:39:46.0375 (UTC) FILETIME=[6E5A4570:01C797D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1334; t=1179329991; x=1180193991; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=fnFgPh4SIZVobzeuafGfk27dXv3zKCkU3hS+EoDVNyA=; b=l4Cx7fuyWYftooForVQOixAwPGHeLhlV1MaJ56s5JADdq0RJuRmlidwj7VRLdTriePCv7laI zURE2TQgC07ER1QIfdZzcaS09cTyoSP6WnieCiFqllrXeQw+tZXN49C8; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: yoshi@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Wednesday, May 16, 2007 2:07 AM > To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham > Soliman; mip6@ietf.org; nemo@ietf.org > Cc: yoshi@cisco.com > Subject: RE: [Mip6] The use of GRE > > Hi Yoshi, > > Yes, you are right in that GRE does allow any protocol to go over it, > and I was not aware that this use of GRE is common in combination with > Mobile IP. I will take your work for it though. > > If people feel that GRE is indeed important for MIPv6 then, I > wonder if > it is a good idea to just add a "hook" for GRE support in > DSMIPv6 draft. > Would it not be better to add GRE encapsulation on MIPv6 more > properly, > and deal with how it is signaled, how GRE key management is done, how > GRE tunneling is used over IPv4 or IPv6 tunneling, and possibly other > issues? > > Maybe it is just me but somehow I feel that DSMIPv6 has already become > too big and a kind of a kitchen-sink draft for a lot of different > things. > Just a clarification. I dont think, the request was for extending DSMIP6 to support GRE. But, rather a request for a 4-byte TLV header that gives the room for adding new extensions, including GRE header. Again, just as in 3519. Regards Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 13:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMzq-00081Q-TR; Wed, 16 May 2007 13:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMzp-00080i-Km; Wed, 16 May 2007 13:09:05 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoMzp-0005HN-0y; Wed, 16 May 2007 13:09:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4GH8e6B032492; Wed, 16 May 2007 20:08:55 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 20:08:46 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 12:08:44 -0500 Received: from 172.19.244.141 ([172.19.244.141]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 May 2007 17:08:43 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 16 May 2007 12:08:51 -0500 Subject: Re: [Mip6] The use of GRE From: Basavaraj Patil To: "ext Tsirtsis, George" , Sri Gundavelli , Hesham Soliman , , Message-ID: Thread-Topic: [Mip6] The use of GRE Thread-Index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQ== In-Reply-To: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 May 2007 17:08:44.0468 (UTC) FILETIME=[DC1A9F40:01C797DC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Some observations about the discussion so far: 1. If the only packet types encapsulated by the UDP header are IPv4/6 then we do not need the extra 4 byte header. 2. The need for the 4 byte header to spell the encapsulated packet type arises only if we believe GRE or other types of packets may be encapsulated in the tunnel between the MN and HA. Yoshi (at least) has indicated that he has had to implement GRE tunnelling support on the MN. Would help if any others can respond and clarify if tunnelling GRE over IP at the MN is normally done. 3. The 4 byte header in every packet is an overhead. Depending on the link type 4 bytes in every packet can be considered as being wasteful. 4. The need for GRE encapsulation for NEMO is not apparent; I think there was an explicit statement that GRE is not needed for NEMO. Recommendation: The DS-MIP6 I-D has been worked on at length in this WG. Its time to get this published and implementations tested. Proceed with the current model where we only have either IPv4/6 packets being encapsulated between the MN and HA by the UDP header. No additional 4 byte header to be added. When there is a valid justification and need for supporting encapsulation of GRE and/or other packet types, we can revise the specification if needed. Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is a need to support GRE encapsulation in that context, the Netlmm I-D may extend the DS-MIP6 spec and add the 4 byte header. -Raj On 5/14/07 9:04 AM, "ext Tsirtsis, George" wrote: > Folks, > > I have been trying to make sense of this discussion. After re-reading > the whole thread I think we may be able to progress if we answer the > following question: > > QUESTION: Does this group agree that GRE encapsulation needs to be > supported in MIPv6? > > If the answer is "NO", then using the already defined UDP port and the > IP version field to demux IPv4/IPv6 packets as already defined in > DSMIPv6 is absolutely fine and there is no reason to change it. > > If the answer is "YES", then we have to consider the following: > It is clear that the IP version field can not demux GRE. In that case: > a) Leave GRE out of DSMIPv6 draft (which uses IP version field > for demuxing). People interested in GRE should write up a draft defining > how GRE is used in MIPv6. This is likely to result in a GRE specific > method of encapsulation over UDP. This is likely to involve reservation > of one more UDP port and the definition of a small pseudo-header as > proposed by Sri and others. > b) Be proactive and adopt the pseudo-header for all > encapsulations. This would mean that DSMIPv6 draft is changed to > indicate that over the reserved UDP port we add the TLV (or whatever > structure) which indicates what the next header is i.e., IPv4, IPv6, > GRE. > > > Personally, I am not a big fun of supporting GRE encapsulation for > MIPv6. The reason is that in IPv6 we do not have (and must never have) > to deal with overlapping address spaces (the main use of GRE tunneling > in MIPv4). > > Also note that even if we do decide to use the IP version field for > demuxing now, there is nothing that prevents GRE encapsulation to be > defined later, as indicated by (a) above, assuming that GRE support > becomes necessary. Yes, then implementation will have to deal with two > way of demuxing similar information but it is not the end of the world > and it reduces the overhead (albeit not much) in the typical case. > > I hope this helps. > Regards > George > > > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, May 11, 2007 6:26 AM > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] The use of GRE > > > >> -----Original Message----- >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >> Sent: Thursday, May 10, 2007 10:20 PM >> To: mip6@ietf.org; nemo@ietf.org >> Subject: [Mip6] The use of GRE >> >> Hi all, >> >> This concensus call on issue 93 made me a bit confused about >> the use of GRE. >> I have a simple question: >> >> Why can't people that want to use GRE (for PMIP) run it as follows: >> >> IP Heahder (proto 47 for GRE) >> GRE Header >> UDP >> ....etc >> >> Why do we need to add another layer to qualifiers instead of using the >> existing allocated numbers? >> >> It's been a couple of years since I read the GRE spec so I wanted to >> understand if this format is a problem >> > > Problem will be with the NAT/PAT device. It wont create NAT bindings > from the UDP header encapped in the GRE header. > > Sri > > > > _______________________________________________ > 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 13:24:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoNEa-0001Sl-MW; Wed, 16 May 2007 13:24:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoNEZ-0001Sc-3T; Wed, 16 May 2007 13:24:19 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoNEW-0002tl-M5; Wed, 16 May 2007 13:24:19 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HoNEV-0003Hz-6f; Wed, 16 May 2007 19:24:15 +0200 Message-ID: <464B3E3F.5010802@levkowetz.com> Date: Wed, 16 May 2007 19:24:15 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] DS-MIP6: Consensus call to close issue 93 References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: basavaraj.patil@nsn.com, mip6@ietf.org, nemo@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org on 2007-05-08 23:16 Basavaraj Patil said the following: ... > Choices are: > 1. Parse the protocol header following the UDP header > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" > 4. Encapsulated protocol header type is indicated in the BU message There has been some clarifications to Basavaraj's original formulation (above), and I agree with the clarifications. I'm responding to the original email to make the tallying simple. I originally thought that I'd find either 1. or 3. equally acceptable, but after the side discussion about GRE and alternative keepalives, I find that despite the small additional overhead of 4 bytes of solution 3., I prefer it because it is somewhat more future-proof. We don't strictly need 3. today, but it provides some freedom for tomorrow when compared with 1. (2. and 4. aren't tempting at all.) The choice was easier in 3519, although not obvious -- at first we thought we could do without the 4-byte overhead there too, but it looks increasingly as if it was a good idea to have the added header in that case. So: I prefer alternative 3. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 15:08:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOrL-0003gp-KB; Wed, 16 May 2007 15:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOrJ-0003g7-C5; Wed, 16 May 2007 15:08:25 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoOrJ-0006Rt-4E; Wed, 16 May 2007 15:08:25 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1179342504!15649673!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28920 invoked from network); 16 May 2007 19:08:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 16 May 2007 19:08:24 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4GJ8Nl2021161; Wed, 16 May 2007 12:08:23 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4GJ8NOe026706; Wed, 16 May 2007 14:08:23 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.95]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4GJ8JI1026634; Wed, 16 May 2007 14:08:20 -0500 (CDT) Message-ID: <464B56A2.1010408@gmail.com> Date: Wed, 16 May 2007 21:08:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> In-Reply-To: <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org, yoshi@cisco.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sri Gundavelli wrote: > > >> -----Original Message----- >> From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] >> Sent: Wednesday, May 16, 2007 2:07 AM >> To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham >> Soliman; mip6@ietf.org; nemo@ietf.org >> Cc: yoshi@cisco.com >> Subject: RE: [Mip6] The use of GRE >> >> Hi Yoshi, >> >> Yes, you are right in that GRE does allow any protocol to go over it, >> and I was not aware that this use of GRE is common in combination with >> Mobile IP. I will take your work for it though. >> >> If people feel that GRE is indeed important for MIPv6 then, I >> wonder if >> it is a good idea to just add a "hook" for GRE support in >> DSMIPv6 draft. >> Would it not be better to add GRE encapsulation on MIPv6 more >> properly, >> and deal with how it is signaled, how GRE key management is done, how >> GRE tunneling is used over IPv4 or IPv6 tunneling, and possibly other >> issues? >> >> Maybe it is just me but somehow I feel that DSMIPv6 has already become >> too big and a kind of a kitchen-sink draft for a lot of different >> things. >> > > > Just a clarification. I dont think, the request was for extending DSMIP6 > to support GRE. But, rather a request for a 4-byte TLV header that gives > the room for adding new extensions, including GRE header. Again, just as > in 3519. I really don't think 3519 has that TLV more than as an option. Probably it is there because somebody has insisted very hard to get it there. But in general I think it makes no sense at all to have TLVs or GRE between IP headers, or between TCP and UDP headers or anywhere else other than pure and last payload. It makes no sense to carry layer2 header within IP message. Alex > > Regards > Sri > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 15:19:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoP1o-0006uD-FN; Wed, 16 May 2007 15:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoP1m-0006qe-W9; Wed, 16 May 2007 15:19:15 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoP1l-00018e-DM; Wed, 16 May 2007 15:19:14 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1179343152!9947196!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9465 invoked from network); 16 May 2007 19:19:12 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 16 May 2007 19:19:12 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4GJJBmr024281; Wed, 16 May 2007 12:19:12 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l4GJJBSF011296; Wed, 16 May 2007 14:19:11 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.95]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l4GJJ8q3011239; Wed, 16 May 2007 14:19:08 -0500 (CDT) Message-ID: <464B592B.3090405@gmail.com> Date: Wed, 16 May 2007 21:19:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [nemo] Re: [Mip6] The use of GRE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Basavaraj Patil wrote: > Some observations about the discussion so far: > > 1. If the only packet types encapsulated by the UDP header are IPv4/6 then > we do not need the extra 4 byte header. > 2. The need for the 4 byte header to spell the encapsulated packet type > arises only if we believe GRE or other types of packets may be encapsulated > in the tunnel between the MN and HA. Yoshi (at least) has indicated that he > has had to implement GRE tunnelling support on the MN. Would help if any > others can respond and clarify if tunnelling GRE over IP at the MN is > normally done. > 3. The 4 byte header in every packet is an overhead. Depending on the link > type 4 bytes in every packet can be considered as being wasteful. > 4. The need for GRE encapsulation for NEMO is not apparent; I think there > was an explicit statement that GRE is not needed for NEMO. I agree with this 1-4 list, and I think it summarizes well the points discussed so far, thanks. Another need for GRE that was mentioned is security. It is not technically clear either. > Recommendation: > > The DS-MIP6 I-D has been worked on at length in this WG. Its time to get > this published and implementations tested. > > Proceed with the current model where we only have either IPv4/6 packets > being encapsulated between the MN and HA by the UDP header. No additional 4 > byte header to be added. > > When there is a valid justification and need for supporting encapsulation of > GRE and/or other packet types, we can revise the specification if needed. > > Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is a need > to support GRE encapsulation in that context, the Netlmm I-D may extend the > DS-MIP6 spec and add the 4 byte header. Raj, I find it extemely annoying the silence around the actual need for GRE. It is a known fact for anyone following WiMax SDO that WiMax needs GRE. It is also a known fact that several people expressing oppinions on this list are also expressing opinions on WiMax NWG. YEt these people are silent when the question "who needs GRE" is raised. This is very annoying. I understand very well your neutral Chair position and you summarized very well the GRE discussion so far - I appreciate that. But I think it is time to state clearly that GRE is pushed here _only_ because WiMax needs it. Every other technical reason for GRE is completely bogus: security (you didn't mention), NEMO and capacity to carry other than IPv4/IPv6 is pure speculative handwaving. Once we have that statement of interest from WiMax needs about GRE we can deal with it accordingly. Otherwise it looks as if you try to make it look as if it were a typical IETF discussion - it isn't. Alex > > -Raj > > On 5/14/07 9:04 AM, "ext Tsirtsis, George" wrote: > >> Folks, >> >> I have been trying to make sense of this discussion. After re-reading >> the whole thread I think we may be able to progress if we answer the >> following question: >> >> QUESTION: Does this group agree that GRE encapsulation needs to be >> supported in MIPv6? >> >> If the answer is "NO", then using the already defined UDP port and the >> IP version field to demux IPv4/IPv6 packets as already defined in >> DSMIPv6 is absolutely fine and there is no reason to change it. >> >> If the answer is "YES", then we have to consider the following: >> It is clear that the IP version field can not demux GRE. In that case: >> a) Leave GRE out of DSMIPv6 draft (which uses IP version field >> for demuxing). People interested in GRE should write up a draft defining >> how GRE is used in MIPv6. This is likely to result in a GRE specific >> method of encapsulation over UDP. This is likely to involve reservation >> of one more UDP port and the definition of a small pseudo-header as >> proposed by Sri and others. >> b) Be proactive and adopt the pseudo-header for all >> encapsulations. This would mean that DSMIPv6 draft is changed to >> indicate that over the reserved UDP port we add the TLV (or whatever >> structure) which indicates what the next header is i.e., IPv4, IPv6, >> GRE. >> >> >> Personally, I am not a big fun of supporting GRE encapsulation for >> MIPv6. The reason is that in IPv6 we do not have (and must never have) >> to deal with overlapping address spaces (the main use of GRE tunneling >> in MIPv4). >> >> Also note that even if we do decide to use the IP version field for >> demuxing now, there is nothing that prevents GRE encapsulation to be >> defined later, as indicated by (a) above, assuming that GRE support >> becomes necessary. Yes, then implementation will have to deal with two >> way of demuxing similar information but it is not the end of the world >> and it reduces the overhead (albeit not much) in the typical case. >> >> I hope this helps. >> Regards >> George >> >> >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Friday, May 11, 2007 6:26 AM >> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org >> Subject: RE: [Mip6] The use of GRE >> >> >> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>> Sent: Thursday, May 10, 2007 10:20 PM >>> To: mip6@ietf.org; nemo@ietf.org >>> Subject: [Mip6] The use of GRE >>> >>> Hi all, >>> >>> This concensus call on issue 93 made me a bit confused about >>> the use of GRE. >>> I have a simple question: >>> >>> Why can't people that want to use GRE (for PMIP) run it as follows: >>> >>> IP Heahder (proto 47 for GRE) >>> GRE Header >>> UDP >>> ....etc >>> >>> Why do we need to add another layer to qualifiers instead of using the >>> existing allocated numbers? >>> >>> It's been a couple of years since I read the GRE spec so I wanted to >>> understand if this format is a problem >>> >> Problem will be with the NAT/PAT device. It wont create NAT bindings >> from the UDP header encapped in the GRE header. >> >> Sri >> >> >> >> _______________________________________________ >> 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 > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 15:51:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPWS-0001jK-C7; Wed, 16 May 2007 15:50:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPW5-0000nW-Lg; Wed, 16 May 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HoPW4-0005Zi-Bc; Wed, 16 May 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4997D17623; Wed, 16 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HoPVa-0006Az-1U; Wed, 16 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 16 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : DHCP Option for Home Information Discovery in MIPv6 Author(s) : H. Jang, et al. Filename : draft-ietf-mip6-hiopt-03.txt Pages : 19 Date : 2007-5-16 This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home agent FQDN and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-hiopt-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-hiopt-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-16105108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-hiopt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-hiopt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-16105108.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed May 16 15:52:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPYP-0005b7-Ff; Wed, 16 May 2007 15:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPYO-0005a5-Fs; Wed, 16 May 2007 15:52:56 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoPYF-0004Se-VG; Wed, 16 May 2007 15:52:56 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4GJqUUW012098; Wed, 16 May 2007 22:52:39 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 22:52:38 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 14:52:18 -0500 Received: from 172.19.244.141 ([172.19.244.141]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 May 2007 19:52:18 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 16 May 2007 14:52:27 -0500 Subject: Re: [nemo] Re: [Mip6] The use of GRE From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [nemo] Re: [Mip6] The use of GRE Thread-Index: AceX87rK+RXnlQPmEdyCLAARJNUNiA== In-Reply-To: <464B592B.3090405@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 May 2007 19:52:18.0981 (UTC) FILETIME=[B6027550:01C797F3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, On 5/16/07 2:19 PM, "ext Alexandru Petrescu" wrote: > Basavaraj Patil wrote: >> Some observations about the discussion so far: >> >> 1. If the only packet types encapsulated by the UDP header are IPv4/6 then >> we do not need the extra 4 byte header. >> 2. The need for the 4 byte header to spell the encapsulated packet type >> arises only if we believe GRE or other types of packets may be encapsulated >> in the tunnel between the MN and HA. Yoshi (at least) has indicated that he >> has had to implement GRE tunnelling support on the MN. Would help if any >> others can respond and clarify if tunnelling GRE over IP at the MN is >> normally done. >> 3. The 4 byte header in every packet is an overhead. Depending on the link >> type 4 bytes in every packet can be considered as being wasteful. >> 4. The need for GRE encapsulation for NEMO is not apparent; I think there >> was an explicit statement that GRE is not needed for NEMO. > > I agree with this 1-4 list, and I think it summarizes well the points > discussed so far, thanks. > > Another need for GRE that was mentioned is security. It is not > technically clear either. I guess I missed the security argument. But as you say, the reasons are not very clear. > >> Recommendation: >> >> The DS-MIP6 I-D has been worked on at length in this WG. Its time to get >> this published and implementations tested. >> >> Proceed with the current model where we only have either IPv4/6 packets >> being encapsulated between the MN and HA by the UDP header. No additional 4 >> byte header to be added. >> >> When there is a valid justification and need for supporting encapsulation of >> GRE and/or other packet types, we can revise the specification if needed. >> >> Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is a need >> to support GRE encapsulation in that context, the Netlmm I-D may extend the >> DS-MIP6 spec and add the 4 byte header. > > Raj, I find it extemely annoying the silence around the actual need for > GRE. It is a known fact for anyone following WiMax SDO that WiMax needs > GRE. It is also a known fact that several people expressing oppinions > on this list are also expressing opinions on WiMax NWG. I am not sure if that is indeed the case. At least I have not perceived it as such from the current thread. Since I also am involved in WiMAX NWG, I can tell you that this issue of GRE support in DS-MIP6 has never been discussed in that forum. > > YEt these people are silent when the question "who needs GRE" is raised. > > This is very annoying. > > I understand very well your neutral Chair position and you summarized > very well the GRE discussion so far - I appreciate that. > > But I think it is time to state clearly that GRE is pushed here _only_ > because WiMax needs it. Every other technical reason for GRE is > completely bogus: security (you didn't mention), NEMO and capacity to > carry other than IPv4/IPv6 is pure speculative handwaving. > > Once we have that statement of interest from WiMax needs about GRE we > can deal with it accordingly. Otherwise it looks as if you try to make > it look as if it were a typical IETF discussion - it isn't. IMO, the discussion on this topic/thread was not motivated by who needs GRE. It was simply closing an issue that was raised and discussed at the Prague IETF. The argument about GRE arose only as a result of the need for the 4 byte header to indicate the encapsulated packet type. I believe this was a typical WG discussion. You may be reading much more into it than what it is. -Raj > > Alex > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 16:53:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQUz-00056p-Mo; Wed, 16 May 2007 16:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQUy-00056h-10; Wed, 16 May 2007 16:53:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoQUw-0004OH-Me; Wed, 16 May 2007 16:53:28 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 16 May 2007 13:53:26 -0700 X-IronPort-AV: i="4.14,544,1170662400"; d="scan'208"; a="422717068:sNHT49370744" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4GKrPKa014307; Wed, 16 May 2007 13:53:25 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4GKrPV2023508; Wed, 16 May 2007 20:53:25 GMT Date: Wed, 16 May 2007 13:53:25 -0700 (PDT) From: Sri Gundavelli To: Alexandru Petrescu Subject: Re: [nemo] RE: [Mip6] The use of GRE In-Reply-To: <464B56A2.1010408@gmail.com> Message-ID: References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> <464B56A2.1010408@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2655; t=1179348806; x=1180212806; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[nemo]=20RE=3A=20[Mip6]=20The=20use=20of=20GRE |Sender:=20; bh=ozDK8EEbkhQf+u4BfbjkYq6hZAayVFenMaa+oSTe6aU=; b=bhlduOoblN5ec5fFu5Bc+WEVz3gx2q1kCEPTDp0RU2u9iRP2uvsd2k4rdv2MJGLl4Ei1RwDC l1NbY35uEc2yBsX92VyTAUD12PP9dsAE80h2en2XD9/jRBzJPM3RZDvc; Authentication-Results: sj-dkim-7; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: nemo@ietf.org, yoshi@cisco.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Wed, 16 May 2007, Alexandru Petrescu wrote: > Sri Gundavelli wrote: >> >> >> > -----Original Message----- >> > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] Sent: Wednesday, >> > May 16, 2007 2:07 AM >> > To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham Soliman; >> > mip6@ietf.org; nemo@ietf.org >> > Cc: yoshi@cisco.com >> > Subject: RE: [Mip6] The use of GRE >> > >> > Hi Yoshi, >> > >> > Yes, you are right in that GRE does allow any protocol to go over it, >> > and I was not aware that this use of GRE is common in combination with >> > Mobile IP. I will take your work for it though. >> > >> > If people feel that GRE is indeed important for MIPv6 then, I wonder if >> > it is a good idea to just add a "hook" for GRE support in DSMIPv6 >> > draft. >> > Would it not be better to add GRE encapsulation on MIPv6 more properly, >> > and deal with how it is signaled, how GRE key management is done, how >> > GRE tunneling is used over IPv4 or IPv6 tunneling, and possibly other >> > issues? >> > >> > Maybe it is just me but somehow I feel that DSMIPv6 has already become >> > too big and a kind of a kitchen-sink draft for a lot of different >> > things. >> > >> >> >> Just a clarification. I dont think, the request was for extending DSMIP6 >> to support GRE. But, rather a request for a 4-byte TLV header that gives >> the room for adding new extensions, including GRE header. Again, just as >> in 3519. > > I really don't think 3519 has that TLV more than as an option. Probably it > is there because somebody has insisted very hard to get it there. > > But in general I think it makes no sense at all to have TLVs or GRE between > IP headers, or between TCP and UDP headers or anywhere else other than pure > and last payload. > Well. it makes sense to me. Gave many reasons that I dont want to repeat here. If you judge things based on your preset notion of how requirements are arriving, its hard for you to get convinced. BTW, there was no comment on any justification based on the security argument. Not sure, how you ended up with that assumption. Also, this requirement is not comming from WiMAX. But, I dont have to prove it to you. If this requirement is indeed comming from WiMax, let it be so. If there is a need, so is it. This is a technical discussion. Judge it based on the merit. Any case, we disagree on this. I gave the reasons why we should add a simple 4-byte TLV header. If the WG is convinced, let it add that. Otherwise, we need to later allocate a special port just for GRE payload. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 17:20:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQvA-0007IW-1P; Wed, 16 May 2007 17:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQv8-0007I0-JE; Wed, 16 May 2007 17:20:30 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoQv8-0000lF-9V; Wed, 16 May 2007 17:20:30 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1179350429!13999666!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6393 invoked from network); 16 May 2007 21:20:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 16 May 2007 21:20:29 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4GLKSj7025300; Wed, 16 May 2007 14:20:29 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l4GLKRvw019331; Wed, 16 May 2007 16:20:28 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.33]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l4GLKNd8019259; Wed, 16 May 2007 16:20:24 -0500 (CDT) Message-ID: <464B7596.3030806@gmail.com> Date: Wed, 16 May 2007 23:20:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: <2309978910A6A6478C2C7585692B0AF457A042@NAEX16.na.qualcomm.com> <35912544FC930E49BF20EF16C3EF2765023BC481@xmb-hkg-416.apac.cisco.com> <2309978910A6A6478C2C7585692B0AF457A2B1@NAEX16.na.qualcomm.com> <048e01c797d0$6eb44c50$d4f6200a@amer.cisco.com> <464B56A2.1010408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nemo@ietf.org, yoshi@cisco.com, Alexandru Petrescu , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sri Gundavelli wrote: > > > On Wed, 16 May 2007, Alexandru Petrescu wrote: > >> Sri Gundavelli wrote: >>> >>> >>>> -----Original Message----- From: Tsirtsis, George >>>> [mailto:tsirtsis@qualcomm.com] Sent: >>> Wednesday, > May 16, 2007 2:07 AM >>>> To: Yoshi Tsuda (yotsuda); Sri Gundavelli (sgundave); Hesham >>> Soliman; > mip6@ietf.org; nemo@ietf.org >>>> Cc: yoshi@cisco.com Subject: RE: [Mip6] The use of GRE >>>>> Hi Yoshi, Yes, you are right in that GRE does allow any >>>>> protocol to go >>> over it, >>>> and I was not aware that this use of GRE is common in >>>> combination >>> with >>>> Mobile IP. I will take your work for it though. >>>>> If people feel that GRE is indeed important for MIPv6 then, I >>>>> >>>>> >>> wonder if >>>> it is a good idea to just add a "hook" for GRE support in >>>> DSMIPv6 draft. Would it not be better to add GRE encapsulation >>>> on MIPv6 more >>> properly, >>>> and deal with how it is signaled, how GRE key management is >>>> done, how GRE tunneling is used over IPv4 or IPv6 tunneling, >>>> and possibly other issues? > > Maybe it is just me but somehow >>>> I feel that DSMIPv6 >>> has already become >>>> too big and a kind of a kitchen-sink draft for a lot of >>>> different things. >>>> >>> >>> >>> Just a clarification. I dont think, the request was for extending >>> DSMIP6 to support GRE. But, rather a request for a 4-byte TLV >>> header that gives the room for adding new extensions, including >>> GRE header. Again, just as in 3519. >> >> I really don't think 3519 has that TLV more than as an option. >> Probably it is there because somebody has insisted very hard to get >> it there. >> >> But in general I think it makes no sense at all to have TLVs or GRE >> between IP headers, or between TCP and UDP headers or anywhere >> else other than pure and last payload. >> > > Well. it makes sense to me. Gave many reasons that I dont want to > repeat here. If you judge things based on your preset notion of how > requirements are arriving, its hard for you to get convinced. > > BTW, there was no comment on any justification based on the security > argument. Not sure, how you ended up with that assumption. I think this is what I read in yestarday Pascal's comment needing GRE for security reasons. Pascal said at http://www1.ietf.org/mail-archive/web/mip6/current/msg06157.html: > So I do agree with the original point that there will be multiple > usages for that [GRE, my note] tunnel. At this point, I feel that we > are back to a previous discussion on reverse Routability test: in > traditional MIP or NEMO (without SeND) the MR can not be sure of its > CoA, and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP > the right place to solve a problem that was already there? Sri said: > Also, this requirement is not comming from WiMAX. But, I dont have to > prove it to you. If this requirement is indeed comming from WiMax, > let it be so. If there is a need, so is it. This is a technical > discussion. Judge it based on the merit. Right... The technical merit of this GRE discussion is utterly senseless, sorry for exaggerating the qualifier. > Any case, we disagree on this. I gave the reasons why we should add a > simple 4-byte TLV header. If the WG is convinced, let it add that. > Otherwise, we need to later allocate a special port just for GRE > payload. Do you agree that DS-MIPv6, MIP6 and NEMO can work ok _without_ that TLV? Do you agree MIP4 can work ok without that TLV? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 17:34:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoR8K-0001Ah-Oj; Wed, 16 May 2007 17:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoR8I-0001AJ-P0; Wed, 16 May 2007 17:34:06 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoR8I-0004ko-7Z; Wed, 16 May 2007 17:34:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] The use of GRE Date: Wed, 16 May 2007 14:33:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] The use of GRE thread-index: AceTi/PNR4cyiZTDQxuILfPQLcEyLQAAK0cQAKhmvzAAa6kGYQAInDPQ References: From: "Vijay Devarapalli" To: "Basavaraj Patil" , "ext Tsirtsis, George" , "Sri Gundavelli" , "Hesham Soliman" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Raj, We might actually end up with option 2. I see three reserved=20 UDP ports with DS-MIPv6 already. 1. One UDP port indicating IPv4/IPv6. You parse the IP version field to figure out whether it is IPv4 or IPv6. 2. One UDP port for ESP encapsulation. This happens when you=20 protect DS-MIPv6 traffic with ESP and use UDP encapsulation=20 for NAT traversal. The packet format would be IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4) UDP hdr ESP hdr IPv6 (src=3DMN-IPv6-HoA, dst=3DCN) Payload=20 3. One reserved UDP port for GRE encapsulation in DS-MIPv6. So this is almost option 2. :) Option 2 was one reserved port per protocol that follows the UDP header. Vijay > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Wednesday, May 16, 2007 10:09 AM > To: ext Tsirtsis, George; Sri Gundavelli; Hesham Soliman;=20 > mip6@ietf.org; nemo@ietf.org > Subject: Re: [Mip6] The use of GRE >=20 >=20 > Some observations about the discussion so far: >=20 > 1. If the only packet types encapsulated by the UDP header=20 > are IPv4/6 then > we do not need the extra 4 byte header. > 2. The need for the 4 byte header to spell the encapsulated=20 > packet type > arises only if we believe GRE or other types of packets may=20 > be encapsulated > in the tunnel between the MN and HA. Yoshi (at least) has=20 > indicated that he > has had to implement GRE tunnelling support on the MN. Would=20 > help if any > others can respond and clarify if tunnelling GRE over IP at the MN is > normally done. > 3. The 4 byte header in every packet is an overhead.=20 > Depending on the link > type 4 bytes in every packet can be considered as being wasteful. > 4. The need for GRE encapsulation for NEMO is not apparent; I=20 > think there > was an explicit statement that GRE is not needed for NEMO. >=20 > Recommendation: >=20 > The DS-MIP6 I-D has been worked on at length in this WG. Its=20 > time to get > this published and implementations tested. >=20 > Proceed with the current model where we only have either=20 > IPv4/6 packets > being encapsulated between the MN and HA by the UDP header.=20 > No additional 4 > byte header to be added. >=20 > When there is a valid justification and need for supporting=20 > encapsulation of > GRE and/or other packet types, we can revise the=20 > specification if needed. >=20 > Since DS-MIP6 is a component of the PMIP6 work in Netlmm and=20 > there is a need > to support GRE encapsulation in that context, the Netlmm I-D=20 > may extend the > DS-MIP6 spec and add the 4 byte header. >=20 > -Raj >=20 > On 5/14/07 9:04 AM, "ext Tsirtsis, George"=20 > wrote: >=20 > > Folks, > >=20 > > I have been trying to make sense of this discussion. After=20 > re-reading > > the whole thread I think we may be able to progress if we answer the > > following question: > >=20 > > QUESTION: Does this group agree that GRE encapsulation needs to be > > supported in MIPv6? > >=20 > > If the answer is "NO", then using the already defined UDP=20 > port and the > > IP version field to demux IPv4/IPv6 packets as already defined in > > DSMIPv6 is absolutely fine and there is no reason to change it. > >=20 > > If the answer is "YES", then we have to consider the following: > > It is clear that the IP version field can not demux GRE. In=20 > that case: > > a) Leave GRE out of DSMIPv6 draft (which uses IP version field > > for demuxing). People interested in GRE should write up a=20 > draft defining > > how GRE is used in MIPv6. This is likely to result in a GRE specific > > method of encapsulation over UDP. This is likely to involve=20 > reservation > > of one more UDP port and the definition of a small pseudo-header as > > proposed by Sri and others. > > b) Be proactive and adopt the pseudo-header for all > > encapsulations. This would mean that DSMIPv6 draft is changed to > > indicate that over the reserved UDP port we add the TLV (or whatever > > structure) which indicates what the next header is i.e., IPv4, IPv6, > > GRE. > > =20 > >=20 > > Personally, I am not a big fun of supporting GRE encapsulation for > > MIPv6. The reason is that in IPv6 we do not have (and must=20 > never have) > > to deal with overlapping address spaces (the main use of=20 > GRE tunneling > > in MIPv4).=20 > >=20 > > Also note that even if we do decide to use the IP version field for > > demuxing now, there is nothing that prevents GRE encapsulation to be > > defined later, as indicated by (a) above, assuming that GRE support > > becomes necessary. Yes, then implementation will have to=20 > deal with two > > way of demuxing similar information but it is not the end=20 > of the world > > and it reduces the overhead (albeit not much) in the typical case. > >=20 > > I hope this helps. > > Regards > > George > >=20 > >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Friday, May 11, 2007 6:26 AM > > To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > > Subject: RE: [Mip6] The use of GRE > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > >> Sent: Thursday, May 10, 2007 10:20 PM > >> To: mip6@ietf.org; nemo@ietf.org > >> Subject: [Mip6] The use of GRE > >>=20 > >> Hi all,=20 > >>=20 > >> This concensus call on issue 93 made me a bit confused about > >> the use of GRE. > >> I have a simple question: > >>=20 > >> Why can't people that want to use GRE (for PMIP) run it as follows: > >>=20 > >> IP Heahder (proto 47 for GRE) > >> GRE Header=20 > >> UDP > >> ....etc > >>=20 > >> Why do we need to add another layer to qualifiers instead=20 > of using the > >> existing allocated numbers? > >>=20 > >> It's been a couple of years since I read the GRE spec so I=20 > wanted to > >> understand if this format is a problem > >>=20 > >=20 > > Problem will be with the NAT/PAT device. It wont create NAT bindings > > from the UDP header encapped in the GRE header. > >=20 > > Sri > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 17:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoR9c-00027e-Sj; Wed, 16 May 2007 17:35:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoR9b-00026K-0f; Wed, 16 May 2007 17:35:27 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoR9a-0004wT-MB; Wed, 16 May 2007 17:35:26 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1179351325!23323774!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 30625 invoked from network); 16 May 2007 21:35:25 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-9.tower-119.messagelabs.com with SMTP; 16 May 2007 21:35:25 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l4GLZPSi018435; Wed, 16 May 2007 14:35:25 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l4GLZNIM005723; Wed, 16 May 2007 16:35:24 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.33]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4GLZKw4005651; Wed, 16 May 2007 16:35:21 -0500 (CDT) Message-ID: <464B7917.2010402@gmail.com> Date: Wed, 16 May 2007 23:35:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [nemo] Re: [Mip6] The use of GRE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Basavaraj Patil wrote: > Hi Alex, > > > On 5/16/07 2:19 PM, "ext Alexandru Petrescu" > wrote: > >> Basavaraj Patil wrote: >>> Some observations about the discussion so far: >>> >>> 1. If the only packet types encapsulated by the UDP header are >>> IPv4/6 then we do not need the extra 4 byte header. 2. The need >>> for the 4 byte header to spell the encapsulated packet type >>> arises only if we believe GRE or other types of packets may be >>> encapsulated in the tunnel between the MN and HA. Yoshi (at >>> least) has indicated that he has had to implement GRE tunnelling >>> support on the MN. Would help if any others can respond and >>> clarify if tunnelling GRE over IP at the MN is normally done. 3. >>> The 4 byte header in every packet is an overhead. Depending on >>> the link type 4 bytes in every packet can be considered as being >>> wasteful. 4. The need for GRE encapsulation for NEMO is not >>> apparent; I think there was an explicit statement that GRE is not >>> needed for NEMO. >> I agree with this 1-4 list, and I think it summarizes well the >> points discussed so far, thanks. >> >> Another need for GRE that was mentioned is security. It is not >> technically clear either. > > I guess I missed the security argument. But as you say, the reasons > are not very clear. Sorry, I think the security argument was made in a mail by Pascal yesterday http://www1.ietf.org/mail-archive/web/mip6/current/msg06157.html >> Raj, I find it extemely annoying the silence around the actual need >> for GRE. It is a known fact for anyone following WiMax SDO that >> WiMax needs GRE. It is also a known fact that several people >> expressing oppinions on this list are also expressing opinions on >> WiMax NWG. > > I am not sure if that is indeed the case. At least I have not > perceived it as such from the current thread. Right. Let me say differently: does WiMax need GRE in netlmm-PMIPv6 protocol? Is WiMax ok if netlmm-PMIPv6 protocol uses IPv6-in-IPv6 encapsulation as of rfc2473 "Generic Packet Tunnling in IPv6 Specification" instead of GRE as of rfc2784 "Generic Routing Encapsulation"? > Since I also am involved in WiMAX NWG, I can tell you > that this issue of GRE support in DS-MIP6 has never been discussed > in that forum. Ok. Did WiMax discuss at all GRE? Did WiMax already include GRE in some of its specs? >> YEt these people are silent when the question "who needs GRE" is >> raised. >> >> This is very annoying. >> >> I understand very well your neutral Chair position and you >> summarized very well the GRE discussion so far - I appreciate that. >> >> >> >> But I think it is time to state clearly that GRE is pushed here >> _only_ because WiMax needs it. Every other technical reason for >> GRE is completely bogus: security (you didn't mention), NEMO and >> capacity to carry other than IPv4/IPv6 is pure speculative >> handwaving. >> >> Once we have that statement of interest from WiMax needs about GRE >> we can deal with it accordingly. Otherwise it looks as if you try >> to make it look as if it were a typical IETF discussion - it isn't. >> >> > > IMO, the discussion on this topic/thread was not motivated by who > needs GRE. It was simply closing an issue that was raised and > discussed at the Prague IETF. The argument about GRE arose only as a > result of the need for the 4 byte header to indicate the encapsulated > packet type. I believe this was a typical WG discussion. You may be > reading much more into it than what it is. Sorry... I'm probably over-reacting on this. To come back to your recommendation, more reasonably, which was: > Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there is > a need to support GRE encapsulation in that context, the Netlmm I-D > may extend the DS-MIP6 spec and add the 4 byte header. I find it clear in your recommendation above that you consider NETLMM to need GRE. And I am not sure how to take this recommendation. I ask you: why do you consider NETLMM to need GRE? It is surprising to consider NETLMM to need GRE because NETLMM is based on MIP6 and MIP6 doesn't need nor use GRE. And then: do you make this recommendation as a MIP6 WG Chair to MIP6 WG members? Do you make this recommendation as a member of NETLMM WG? If latter I don't agree with your recommendation (as another NETLMM WG member). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 17:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRL3-0008Kh-RL; Wed, 16 May 2007 17:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRL2-0008K2-Mg; Wed, 16 May 2007 17:47:16 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoRL1-00080Y-Bw; Wed, 16 May 2007 17:47:16 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1179352034!2593045!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6693 invoked from network); 16 May 2007 21:47:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 16 May 2007 21:47:14 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4GLlDlt001143; Wed, 16 May 2007 14:47:13 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4GLlD70000862; Wed, 16 May 2007 16:47:13 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.33]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4GLlA3g000816; Wed, 16 May 2007 16:47:10 -0500 (CDT) Message-ID: <464B7BDD.6090506@gmail.com> Date: Wed, 16 May 2007 23:47:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000740-2, 16/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, Sri Gundavelli , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Hello Raj, > > We might actually end up with option 2. I see three reserved > UDP ports with DS-MIPv6 already. > > 1. One UDP port indicating IPv4/IPv6. You parse the IP version > field to figure out whether it is IPv4 or IPv6. > 2. One UDP port for ESP encapsulation. This happens when you > protect DS-MIPv6 traffic with ESP and use UDP encapsulation > for NAT traversal. The packet format would be > IPv4 hdr (src=MN-IPv4-CoA, dst=HA-IPv4) > UDP hdr > ESP hdr > IPv6 (src=MN-IPv6-HoA, dst=CN) > Payload > 3. One reserved UDP port for GRE encapsulation in DS-MIPv6. Vijay, but _why_ reserving an UDP port for GRE encapsulation? Since Sri puts the accent so much on the technical merit, what is the technical merit of using GRE (compared to existing encapsulation methods)? Why developing two different ways for doing the same thing? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 18:09:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRgQ-0005Pz-KI; Wed, 16 May 2007 18:09:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRgP-0005Pq-A1; Wed, 16 May 2007 18:09:21 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoRgJ-0005uT-EN; Wed, 16 May 2007 18:09:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [nemo] RE: [Mip6] The use of GRE Date: Wed, 16 May 2007 15:09:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: [Mip6] The use of GRE thread-index: AceYA8YenylAHriERpaTqWg2qn754wAArFNA References: <464B7BDD.6090506@gmail.com> From: "Vijay Devarapalli" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, Sri Gundavelli , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex,=20 "Why GRE?" is a separate topic. If someone wants to use GRE encapsulation to identify flows in DS-MIPv6, we would need to reserve another UDP port. Vijay > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Wednesday, May 16, 2007 2:47 PM > To: Vijay Devarapalli > Cc: Basavaraj Patil; ext Tsirtsis, George; Sri Gundavelli;=20 > Hesham Soliman; mip6@ietf.org; nemo@ietf.org > Subject: Re: [nemo] RE: [Mip6] The use of GRE >=20 > Vijay Devarapalli wrote: > > Hello Raj, > >=20 > > We might actually end up with option 2. I see three reserved=20 > > UDP ports with DS-MIPv6 already. > >=20 > > 1. One UDP port indicating IPv4/IPv6. You parse the IP version > > field to figure out whether it is IPv4 or IPv6. > > 2. One UDP port for ESP encapsulation. This happens when you=20 > > protect DS-MIPv6 traffic with ESP and use UDP encapsulation=20 > > for NAT traversal. The packet format would be > > IPv4 hdr (src=3DMN-IPv4-CoA, dst=3DHA-IPv4) > > UDP hdr > > ESP hdr > > IPv6 (src=3DMN-IPv6-HoA, dst=3DCN) > > Payload=20 > > 3. One reserved UDP port for GRE encapsulation in DS-MIPv6. >=20 > Vijay, but _why_ reserving an UDP port for GRE encapsulation? >=20 > Since Sri puts the accent so much on the technical merit, what is the=20 > technical merit of using GRE (compared to existing=20 > encapsulation methods)? >=20 > Why developing two different ways for doing the same thing? >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 19:32:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoSyz-00031s-UB; Wed, 16 May 2007 19:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoSyx-00031f-OE; Wed, 16 May 2007 19:32:35 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoSyw-0000VY-7Q; Wed, 16 May 2007 19:32:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] DS-MIP6: Consensus call to close issue 93 Date: Wed, 16 May 2007 16:32:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 thread-index: AceRtiHFYHRnMf2pEduUrQARJNUNiACEBSSAARLbbLA= References: <2309978910A6A6478C2C7585692B0AF4579F25@NAEX16.na.qualcomm.com> From: "Vijay Devarapalli" To: "Tsirtsis, George" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Option 4 needs some more work. It is incomplete when you consider what is shown in the slides. We briefly touched upon this during the IETF meeting in Prague. Option 4 can be used in environments where you actually run the signaling protocol (Binding Update/ Binding Ack) and setup a flow (for a particular session/app). You run the signaling protocol each time you want to setup a separate flow.=20 I was planning to work on it and specify it in more detail, but don't have the time for it. I think we should remove option 4 from the list of options, unless someone wants to work on it and specify=20 it in more detail. Vijay > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Friday, May 11, 2007 5:53 AM > To: Basavaraj Patil; Mobile IPv6 Mailing List; nemo@ietf.org > Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 > I support Option 1. (BTW, Option 4 does not work as far as I can tell) > Please see justification below... >=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, May 08, 2007 10:16 PM > To: Mobile IPv6 Mailing List; nemo@ietf.org > Subject: [Mip6] DS-MIP6: Consensus call to close issue 93 >=20 > ... >=20 > Choices are: > 1. Parse the protocol header following the UDP header >=20 > GT> This makes sense to me. It is simple, efficient and it is already > defined in the draft. >=20 > 2. Reserve a UDP port for each protocol header (i.e one UDP port for > IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.) >=20 > GT> While this is a reasonable alternative, I have not heard a > convincing argument to warrant a change from what the draft already > defines (i.e., option 1 above). >=20 > 3. One reserved UDP port and a DS-MIP6 "tunnel type message" >=20 > GT> This seems wasteful and unnecessary, given (1 and 2) >=20 > 4. Encapsulated protocol header type is indicated in the BU message >=20 > GT> This does not seem to work at all. DSMIPv6 can register IPv4 and > IPv6 addresses at the same time. This means that on a packet by packet > basis the header encapsulated over UDP can change from IPv4=20 > to IPv6 and > back. Signaling one or the other in the BU (outbound indication) is > clearly not sufficient and so the indication has to be=20 > inbound with the > data. >=20 > Regards > George >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 16 21:17:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoUcd-00033F-W5; Wed, 16 May 2007 21:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoUcc-0002xR-OC for mip6@ietf.org; Wed, 16 May 2007 21:17:38 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoUcZ-00061P-U5 for mip6@ietf.org; Wed, 16 May 2007 21:17:38 -0400 Received: by py-out-1112.google.com with SMTP id f31so681787pyh for ; Wed, 16 May 2007 18:17:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=tCpGupVB+NQZNZ+KWbnF+0JBXKBb+zNE51dDkKd98hJqLGCkiow8fOPuCpQBJB4HwuA2qnp0PAb46D8veYarE/+9FJ0EJ74JLNdRIghXXw5RZo2K9lAlJgyJdrkjTEzkPHnXmMvZ6HaeRjL/Ccdi+QlD79R4Iq4zdw0SahrPcwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=bVTQ1NhjePvLfPgUUeZwLdNWV7kNKteIxIizeaIOgLQgrmHGeJHJLmFPKGPceOCMeedQpL4u1HRg36ByaOj1/oTTBW3SXs0ox0F3N6HGKlQo40rh5dRg2cPG7rBQOzFoAuwpJXK3W8pa1apapDz6e/gYLwlRFD6WhpeDJaW5O/I= Received: by 10.35.27.2 with SMTP id e2mr15980372pyj.1179364655574; Wed, 16 May 2007 18:17:35 -0700 (PDT) Received: from ?203.178.143.234? ( [203.178.143.234]) by mx.google.com with ESMTP id w67sm5039443pyg.2007.05.16.18.17.32; Wed, 16 May 2007 18:17:34 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 10:17:28 +0900 To: Basavaraj Patil X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, On 2007/05/17, at 2:08, Basavaraj Patil wrote: > > Some observations about the discussion so far: > > 1. If the only packet types encapsulated by the UDP header are > IPv4/6 then > we do not need the extra 4 byte header. > 2. The need for the 4 byte header to spell the encapsulated packet > type > arises only if we believe GRE or other types of packets may be > encapsulated > in the tunnel between the MN and HA. Yoshi (at least) has indicated > that he > has had to implement GRE tunnelling support on the MN. Would help > if any > others can respond and clarify if tunnelling GRE over IP at the MN is > normally done. > 3. The 4 byte header in every packet is an overhead. Depending on > the link > type 4 bytes in every packet can be considered as being wasteful. > 4. The need for GRE encapsulation for NEMO is not apparent; I think > there > was an explicit statement that GRE is not needed for NEMO. > > Recommendation: > > The DS-MIP6 I-D has been worked on at length in this WG. Its time > to get > this published and implementations tested. > > Proceed with the current model where we only have either IPv4/6 > packets > being encapsulated between the MN and HA by the UDP header. No > additional 4 > byte header to be added. > > When there is a valid justification and need for supporting > encapsulation of > GRE and/or other packet types, we can revise the specification if > needed. > > Since DS-MIP6 is a component of the PMIP6 work in Netlmm and there > is a need > to support GRE encapsulation in that context, the Netlmm I-D may > extend the > DS-MIP6 spec and add the 4 byte header. > It seems that many people want to support GRE on DSMIP. I am fine with either 4byte header or UDP port for GRE. I personally prefer Vijay's suggestion (UDP port for GRE). I understand it is important for DSMIP to leave space for future extensions. But this additional feature can easily be re-defined in different spec as DSMIP extension. We don't need to specify it in DSMIP now. The separate doc can overwrite the DSMIP spec if needed. regards, ryuji > -Raj > > On 5/14/07 9:04 AM, "ext Tsirtsis, George" > wrote: > >> Folks, >> >> I have been trying to make sense of this discussion. After re-reading >> the whole thread I think we may be able to progress if we answer the >> following question: >> >> QUESTION: Does this group agree that GRE encapsulation needs to be >> supported in MIPv6? >> >> If the answer is "NO", then using the already defined UDP port and >> the >> IP version field to demux IPv4/IPv6 packets as already defined in >> DSMIPv6 is absolutely fine and there is no reason to change it. >> >> If the answer is "YES", then we have to consider the following: >> It is clear that the IP version field can not demux GRE. In that >> case: >> a) Leave GRE out of DSMIPv6 draft (which uses IP version field >> for demuxing). People interested in GRE should write up a draft >> defining >> how GRE is used in MIPv6. This is likely to result in a GRE specific >> method of encapsulation over UDP. This is likely to involve >> reservation >> of one more UDP port and the definition of a small pseudo-header as >> proposed by Sri and others. >> b) Be proactive and adopt the pseudo-header for all >> encapsulations. This would mean that DSMIPv6 draft is changed to >> indicate that over the reserved UDP port we add the TLV (or whatever >> structure) which indicates what the next header is i.e., IPv4, IPv6, >> GRE. >> >> >> Personally, I am not a big fun of supporting GRE encapsulation for >> MIPv6. The reason is that in IPv6 we do not have (and must never >> have) >> to deal with overlapping address spaces (the main use of GRE >> tunneling >> in MIPv4). >> >> Also note that even if we do decide to use the IP version field for >> demuxing now, there is nothing that prevents GRE encapsulation to be >> defined later, as indicated by (a) above, assuming that GRE support >> becomes necessary. Yes, then implementation will have to deal with >> two >> way of demuxing similar information but it is not the end of the >> world >> and it reduces the overhead (albeit not much) in the typical case. >> >> I hope this helps. >> Regards >> George >> >> >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Friday, May 11, 2007 6:26 AM >> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org >> Subject: RE: [Mip6] The use of GRE >> >> >> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>> Sent: Thursday, May 10, 2007 10:20 PM >>> To: mip6@ietf.org; nemo@ietf.org >>> Subject: [Mip6] The use of GRE >>> >>> Hi all, >>> >>> This concensus call on issue 93 made me a bit confused about >>> the use of GRE. >>> I have a simple question: >>> >>> Why can't people that want to use GRE (for PMIP) run it as follows: >>> >>> IP Heahder (proto 47 for GRE) >>> GRE Header >>> UDP >>> ....etc >>> >>> Why do we need to add another layer to qualifiers instead of >>> using the >>> existing allocated numbers? >>> >>> It's been a couple of years since I read the GRE spec so I wanted to >>> understand if this format is a problem >>> >> >> Problem will be with the NAT/PAT device. It wont create NAT bindings >> from the UDP header encapped in the GRE header. >> >> Sri >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 01:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoYHr-0000Nl-Sm; Thu, 17 May 2007 01:12:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoYHq-0000Nc-Du; Thu, 17 May 2007 01:12:26 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoYHn-0002zE-V2; Thu, 17 May 2007 01:12:26 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4H5BOA18540; Thu, 17 May 2007 05:11:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 00:12:17 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE Thread-Index: AceYITIRDessNkFPQNy4tPnaeacHAwAIADsA References: From: "Ahmad Muhanna" To: "RYUJI WAKIKAWA" , "Basavaraj Patil" X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ryuji, If we agree that a new UDP port for GRE, beside the one for IPv4/IPv6, is needed, then why do not we use a new UDP port to indicate the presence of the TLV which then can be used to indicate the next header for many protocols including GRE and ESP. This way we save one UDP port if we want to support ESP as per Vijay's proposal.=20 Regards, Ahmad =20 > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com]=20 > Sent: Wednesday, May 16, 2007 6:17 PM > To: Basavaraj Patil > Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli > Subject: Re: [nemo] Re: [Mip6] The use of GRE >=20 > Hi Raj, >=20 >=20 >=20 > On 2007/05/17, at 2:08, Basavaraj Patil wrote: >=20 > > > > Some observations about the discussion so far: > > > > 1. If the only packet types encapsulated by the UDP header are > > IPv4/6 then > > we do not need the extra 4 byte header. > > 2. The need for the 4 byte header to spell the encapsulated packet=20 > > type arises only if we believe GRE or other types of packets may be=20 > > encapsulated in the tunnel between the MN and HA. Yoshi (at=20 > least) has=20 > > indicated that he has had to implement GRE tunnelling=20 > support on the=20 > > MN. Would help if any others can respond and clarify if=20 > tunnelling GRE=20 > > over IP at the MN is normally done. > > 3. The 4 byte header in every packet is an overhead.=20 > Depending on the=20 > > link type 4 bytes in every packet can be considered as=20 > being wasteful. > > 4. The need for GRE encapsulation for NEMO is not apparent; I think=20 > > there was an explicit statement that GRE is not needed for NEMO. > > > > Recommendation: > > > > The DS-MIP6 I-D has been worked on at length in this WG.=20 > Its time to=20 > > get this published and implementations tested. > > > > Proceed with the current model where we only have either IPv4/6=20 > > packets being encapsulated between the MN and HA by the UDP=20 > header. No=20 > > additional 4 byte header to be added. > > > > When there is a valid justification and need for supporting=20 > > encapsulation of GRE and/or other packet types, we can revise the=20 > > specification if needed. > > > > Since DS-MIP6 is a component of the PMIP6 work in Netlmm=20 > and there is=20 > > a need to support GRE encapsulation in that context, the Netlmm I-D=20 > > may extend the > > DS-MIP6 spec and add the 4 byte header. > > >=20 > It seems that many people want to support GRE on DSMIP. > I am fine with either 4byte header or UDP port for GRE. > I personally prefer Vijay's suggestion (UDP port for GRE). >=20 > I understand it is important for DSMIP to leave space for=20 > future extensions. > But this additional feature can easily be re-defined in=20 > different spec as DSMIP extension. > We don't need to specify it in DSMIP now. > The separate doc can overwrite the DSMIP spec if needed. >=20 > regards, > ryuji >=20 >=20 >=20 >=20 >=20 >=20 > > -Raj > > > > On 5/14/07 9:04 AM, "ext Tsirtsis, George" > > wrote: > > > >> Folks, > >> > >> I have been trying to make sense of this discussion. After=20 > re-reading=20 > >> the whole thread I think we may be able to progress if we=20 > answer the=20 > >> following question: > >> > >> QUESTION: Does this group agree that GRE encapsulation needs to be=20 > >> supported in MIPv6? > >> > >> If the answer is "NO", then using the already defined UDP port and=20 > >> the IP version field to demux IPv4/IPv6 packets as already=20 > defined in > >> DSMIPv6 is absolutely fine and there is no reason to change it. > >> > >> If the answer is "YES", then we have to consider the following: > >> It is clear that the IP version field can not demux GRE. In that > >> case: > >> a) Leave GRE out of DSMIPv6 draft (which uses IP version field for=20 > >> demuxing). People interested in GRE should write up a=20 > draft defining=20 > >> how GRE is used in MIPv6. This is likely to result in a=20 > GRE specific=20 > >> method of encapsulation over UDP. This is likely to involve=20 > >> reservation of one more UDP port and the definition of a small=20 > >> pseudo-header as proposed by Sri and others. > >> b) Be proactive and adopt the pseudo-header for all=20 > encapsulations.=20 > >> This would mean that DSMIPv6 draft is changed to indicate=20 > that over=20 > >> the reserved UDP port we add the TLV (or whatever > >> structure) which indicates what the next header is i.e.,=20 > IPv4, IPv6,=20 > >> GRE. > >> > >> > >> Personally, I am not a big fun of supporting GRE encapsulation for=20 > >> MIPv6. The reason is that in IPv6 we do not have (and must never > >> have) > >> to deal with overlapping address spaces (the main use of GRE=20 > >> tunneling in MIPv4). > >> > >> Also note that even if we do decide to use the IP version=20 > field for=20 > >> demuxing now, there is nothing that prevents GRE=20 > encapsulation to be=20 > >> defined later, as indicated by (a) above, assuming that=20 > GRE support=20 > >> becomes necessary. Yes, then implementation will have to deal with=20 > >> two way of demuxing similar information but it is not the=20 > end of the=20 > >> world and it reduces the overhead (albeit not much) in the typical=20 > >> case. > >> > >> I hope this helps. > >> Regards > >> George > >> > >> > >> -----Original Message----- > >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> Sent: Friday, May 11, 2007 6:26 AM > >> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org > >> Subject: RE: [Mip6] The use of GRE > >> > >> > >> > >>> -----Original Message----- > >>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > >>> Sent: Thursday, May 10, 2007 10:20 PM > >>> To: mip6@ietf.org; nemo@ietf.org > >>> Subject: [Mip6] The use of GRE > >>> > >>> Hi all, > >>> > >>> This concensus call on issue 93 made me a bit confused=20 > about the use=20 > >>> of GRE. > >>> I have a simple question: > >>> > >>> Why can't people that want to use GRE (for PMIP) run it=20 > as follows: > >>> > >>> IP Heahder (proto 47 for GRE) > >>> GRE Header > >>> UDP > >>> ....etc > >>> > >>> Why do we need to add another layer to qualifiers instead=20 > of using=20 > >>> the existing allocated numbers? > >>> > >>> It's been a couple of years since I read the GRE spec so=20 > I wanted to=20 > >>> understand if this format is a problem > >>> > >> > >> Problem will be with the NAT/PAT device. It wont create=20 > NAT bindings=20 > >> from the UDP header encapped in the GRE header. > >> > >> Sri > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 02:48:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZmr-0004k5-Ks; Thu, 17 May 2007 02:48:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZmq-0004jf-8U; Thu, 17 May 2007 02:48:32 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoZmn-0006zz-PM; Thu, 17 May 2007 02:48:32 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4H6mQsR006961; Thu, 17 May 2007 09:48:27 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 09:48:26 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 09:48:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DS-MIP6: Consensus call to close issue 93 Date: Thu, 17 May 2007 09:48:25 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D0580A757@trebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DS-MIP6: Consensus call to close issue 93 Thread-Index: AceRtiHFYHRnMf2pEduUrQARJNUNiAGl7lBQ References: From: To: , , X-OriginalArrivalTime: 17 May 2007 06:48:26.0602 (UTC) FILETIME=[5EF0B4A0:01C7984F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, >Choices are: >1. Parse the protocol header following the UDP header=20 >2. Reserve a UDP port for each protocol header (i.e one UDP port for IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)=20 >3. One reserved UDP port and a DS-MIP6 "tunnel type message" >4. Encapsulated protocol header type is indicated in the BU message > I prefer to go with option 2. From MN perspective the extensibility that a TLV header brings (e.g. support for GRE) is not important. So my suggestion is to allocate one port for IPv4-UDP-IPv4/IPv6 and define that now in the draft. If there is a need to support other protocols later, then allocate a new port. This way we can have a "green" protocol without the extra 4-byte overhead and still allow to add support for other protocols later. Having separate ports for IPv4-UDP-IPv4 and IPv4-UDP-IPv6 is something I don't like just because we'd need to have separate keepalives for both ports. Cheers, Markku _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 04:47:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hobdy-0001jT-AA; Thu, 17 May 2007 04:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hobdu-0001jB-D2; Thu, 17 May 2007 04:47:27 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hobds-0000If-Cq; Thu, 17 May 2007 04:47:26 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Hobdk-0001Cq-TX; Thu, 17 May 2007 10:47:17 +0200 Message-ID: <464C1692.10907@levkowetz.com> Date: Thu, 17 May 2007 10:47:14 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: amuhanna@nortel.com, ryuji.wakikawa@gmail.com, basavaraj.patil@nsn.com, nemo@ietf.org, mip6@ietf.org, sgundave@cisco.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Folks, on 2007-05-17 07:12 Ahmad Muhanna said the following: > Hi Ryuji, > > If we agree that a new UDP port for GRE, beside the one for IPv4/IPv6, > is needed, then why do not we use a new UDP port to indicate the > presence of the TLV which then can be used to indicate the next header > for many protocols including GRE and ESP. This way we save one UDP port > if we want to support ESP as per Vijay's proposal. At least I am very far from agreeing on one additional assigned UDP port. The number of unassigned UDP port in the range that can be assigned by IANA (0 - 1023) is now down to 281, by my count, so this should be considered a scarce resource. I'm not even sure whether it makes sense to ask for a new port for DS-MIPv6 rather than multiplex over for instance the MIPv4 port, but I think we can at least ask the question. But asking for 2 ports, to carry 2 different kinds of DS-MIPv6 payloads, seems just wrong. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 09:25:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hofyl-0006jI-2v; Thu, 17 May 2007 09:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hofyj-0006il-V3 for mip6@ietf.org; Thu, 17 May 2007 09:25:13 -0400 Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hofyj-0001oP-B2 for mip6@ietf.org; Thu, 17 May 2007 09:25:13 -0400 Received: by wx-out-0506.google.com with SMTP id h31so565318wxd for ; Thu, 17 May 2007 06:25:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=N/9e8LCnmmuakMHI69MXN2+atM1bXNKUnCg1wcsMMhOaPyrhpZJ1sNkjHELOC6BoGr/Jcqe5mdA7LNMSJsj0gbqE6WbYDAIlSAHcpQ4LX6GNkv5nQRaWoud6GM57bkTFlgb3gYSfjRyRlqi8RiSzMJNE1IAdsiGmtVI7VfExf98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=k1IX/70rj1RBLc/8fCyiw47OpLRsSD6a32t1PmAh8I8e8iBiFK4u/U4lllsjjOTcXEQ6XQEFlQzB3MxB0tm09BlhHSxV9pwcJB9HUkJLf3n/0W6uYwJr5GmEWJdMNKqjKvcybpP/MrKJQUhLFWtwebh9McX2TCEJnmLdauW885s= Received: by 10.90.69.8 with SMTP id r8mr372750aga.1179408312723; Thu, 17 May 2007 06:25:12 -0700 (PDT) Received: from ?10.0.1.200? ( [219.110.221.36]) by mx.google.com with ESMTP id 7sm2538131agc.2007.05.17.06.25.09; Thu, 17 May 2007 06:25:11 -0700 (PDT) In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 22:25:05 +0900 To: Ahmad Muhanna X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi This is fine. I just want to avoid 4bytes in every packets over wireless. However, I noticed that if this GRE/ESP support is only for netlmm, it isn't big problem. The path between MAG and LMA is not wireless. I need to see what tunnel (GRE, ESP) is supported for which protocol (MIP6, NEMO, PMIP?) in DSMIP. ryuji On 2007/05/17, at 14:12, Ahmad Muhanna wrote: > Hi Ryuji, > > If we agree that a new UDP port for GRE, beside the one for IPv4/IPv6, > is needed, then why do not we use a new UDP port to indicate the > presence of the TLV which then can be used to indicate the next header > for many protocols including GRE and ESP. This way we save one UDP > port > if we want to support ESP as per Vijay's proposal. > > Regards, > Ahmad > > >> -----Original Message----- >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >> Sent: Wednesday, May 16, 2007 6:17 PM >> To: Basavaraj Patil >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli >> Subject: Re: [nemo] Re: [Mip6] The use of GRE >> >> Hi Raj, >> >> >> >> On 2007/05/17, at 2:08, Basavaraj Patil wrote: >> >>> >>> Some observations about the discussion so far: >>> >>> 1. If the only packet types encapsulated by the UDP header are >>> IPv4/6 then >>> we do not need the extra 4 byte header. >>> 2. The need for the 4 byte header to spell the encapsulated packet >>> type arises only if we believe GRE or other types of packets may be >>> encapsulated in the tunnel between the MN and HA. Yoshi (at >> least) has >>> indicated that he has had to implement GRE tunnelling >> support on the >>> MN. Would help if any others can respond and clarify if >> tunnelling GRE >>> over IP at the MN is normally done. >>> 3. The 4 byte header in every packet is an overhead. >> Depending on the >>> link type 4 bytes in every packet can be considered as >> being wasteful. >>> 4. The need for GRE encapsulation for NEMO is not apparent; I think >>> there was an explicit statement that GRE is not needed for NEMO. >>> >>> Recommendation: >>> >>> The DS-MIP6 I-D has been worked on at length in this WG. >> Its time to >>> get this published and implementations tested. >>> >>> Proceed with the current model where we only have either IPv4/6 >>> packets being encapsulated between the MN and HA by the UDP >> header. No >>> additional 4 byte header to be added. >>> >>> When there is a valid justification and need for supporting >>> encapsulation of GRE and/or other packet types, we can revise the >>> specification if needed. >>> >>> Since DS-MIP6 is a component of the PMIP6 work in Netlmm >> and there is >>> a need to support GRE encapsulation in that context, the Netlmm I-D >>> may extend the >>> DS-MIP6 spec and add the 4 byte header. >>> >> >> It seems that many people want to support GRE on DSMIP. >> I am fine with either 4byte header or UDP port for GRE. >> I personally prefer Vijay's suggestion (UDP port for GRE). >> >> I understand it is important for DSMIP to leave space for >> future extensions. >> But this additional feature can easily be re-defined in >> different spec as DSMIP extension. >> We don't need to specify it in DSMIP now. >> The separate doc can overwrite the DSMIP spec if needed. >> >> regards, >> ryuji >> >> >> >> >> >> >>> -Raj >>> >>> On 5/14/07 9:04 AM, "ext Tsirtsis, George" >>> wrote: >>> >>>> Folks, >>>> >>>> I have been trying to make sense of this discussion. After >> re-reading >>>> the whole thread I think we may be able to progress if we >> answer the >>>> following question: >>>> >>>> QUESTION: Does this group agree that GRE encapsulation needs to be >>>> supported in MIPv6? >>>> >>>> If the answer is "NO", then using the already defined UDP port and >>>> the IP version field to demux IPv4/IPv6 packets as already >> defined in >>>> DSMIPv6 is absolutely fine and there is no reason to change it. >>>> >>>> If the answer is "YES", then we have to consider the following: >>>> It is clear that the IP version field can not demux GRE. In that >>>> case: >>>> a) Leave GRE out of DSMIPv6 draft (which uses IP version field for >>>> demuxing). People interested in GRE should write up a >> draft defining >>>> how GRE is used in MIPv6. This is likely to result in a >> GRE specific >>>> method of encapsulation over UDP. This is likely to involve >>>> reservation of one more UDP port and the definition of a small >>>> pseudo-header as proposed by Sri and others. >>>> b) Be proactive and adopt the pseudo-header for all >> encapsulations. >>>> This would mean that DSMIPv6 draft is changed to indicate >> that over >>>> the reserved UDP port we add the TLV (or whatever >>>> structure) which indicates what the next header is i.e., >> IPv4, IPv6, >>>> GRE. >>>> >>>> >>>> Personally, I am not a big fun of supporting GRE encapsulation for >>>> MIPv6. The reason is that in IPv6 we do not have (and must never >>>> have) >>>> to deal with overlapping address spaces (the main use of GRE >>>> tunneling in MIPv4). >>>> >>>> Also note that even if we do decide to use the IP version >> field for >>>> demuxing now, there is nothing that prevents GRE >> encapsulation to be >>>> defined later, as indicated by (a) above, assuming that >> GRE support >>>> becomes necessary. Yes, then implementation will have to deal with >>>> two way of demuxing similar information but it is not the >> end of the >>>> world and it reduces the overhead (albeit not much) in the typical >>>> case. >>>> >>>> I hope this helps. >>>> Regards >>>> George >>>> >>>> >>>> -----Original Message----- >>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>> Sent: Friday, May 11, 2007 6:26 AM >>>> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org >>>> Subject: RE: [Mip6] The use of GRE >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>>>> Sent: Thursday, May 10, 2007 10:20 PM >>>>> To: mip6@ietf.org; nemo@ietf.org >>>>> Subject: [Mip6] The use of GRE >>>>> >>>>> Hi all, >>>>> >>>>> This concensus call on issue 93 made me a bit confused >> about the use >>>>> of GRE. >>>>> I have a simple question: >>>>> >>>>> Why can't people that want to use GRE (for PMIP) run it >> as follows: >>>>> >>>>> IP Heahder (proto 47 for GRE) >>>>> GRE Header >>>>> UDP >>>>> ....etc >>>>> >>>>> Why do we need to add another layer to qualifiers instead >> of using >>>>> the existing allocated numbers? >>>>> >>>>> It's been a couple of years since I read the GRE spec so >> I wanted to >>>>> understand if this format is a problem >>>>> >>>> >>>> Problem will be with the NAT/PAT device. It wont create >> NAT bindings >>>> from the UDP header encapped in the GRE header. >>>> >>>> Sri >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 09:28:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hog2H-0008VT-9u; Thu, 17 May 2007 09:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hog2G-0008VG-MF for mip6@ietf.org; Thu, 17 May 2007 09:28:52 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hog2F-00048V-ES for mip6@ietf.org; Thu, 17 May 2007 09:28:52 -0400 Received: by wx-out-0506.google.com with SMTP id h31so566534wxd for ; Thu, 17 May 2007 06:28:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=i/3zeaU2Tev4xG8/D1rj2ZROa8+mW9hUboIoPhq+9Zf11dNUtSlIv+42mK74p0TiP+8iYqdxkzJKgAZGoRCMdxNtQ5IEGi6IFotkdeHUaIa2x7/qtxTV27Zuddghdk+em5huE9zjMeWxX+fizGOcbxZ36zeyjT2ZxJks1/WEy10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=qPQQxYmWNadgXV3Yi7JMTClZj7OspObO41y/Bt1CxWKC7aHz4iqYIMFnqZiqp0ur6kNTmy6CgTlBm32SK5WQBIG/bqCZJuwQl106UOPKcbSjrwqQ9wJ2nZ/RCZOnf5Ss9UbMqJiBVAW1NhU9BpXQGDa5NGFCPXe2VwQM4Xg/nbM= Received: by 10.90.66.9 with SMTP id o9mr475037aga.1179408531241; Thu, 17 May 2007 06:28:51 -0700 (PDT) Received: from ?10.0.1.200? ( [219.110.221.36]) by mx.google.com with ESMTP id 8sm2548270agd.2007.05.17.06.28.48; Thu, 17 May 2007 06:28:50 -0700 (PDT) In-Reply-To: <464C1692.10907@levkowetz.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> <464C1692.10907@levkowetz.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 22:28:45 +0900 To: Henrik Levkowetz X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Henrik, I have to agree with you, but the additional 4 bytes in air are also consumed scarce resource, i.e wireless... regards, ryuji On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > Folks, > > on 2007-05-17 07:12 Ahmad Muhanna said the following: >> Hi Ryuji, >> >> If we agree that a new UDP port for GRE, beside the one for IPv4/ >> IPv6, >> is needed, then why do not we use a new UDP port to indicate the >> presence of the TLV which then can be used to indicate the next >> header >> for many protocols including GRE and ESP. This way we save one UDP >> port >> if we want to support ESP as per Vijay's proposal. > > At least I am very far from agreeing on one additional assigned UDP > port. The number of unassigned UDP port in the range that can be > assigned by IANA (0 - 1023) is now down to 281, by my count, so this > should be considered a scarce resource. > > I'm not even sure whether it makes sense to ask for a new port for > DS-MIPv6 > rather than multiplex over for instance the MIPv4 port, but I think > we can > at least ask the question. But asking for 2 ports, to carry 2 > different > kinds of DS-MIPv6 payloads, seems just wrong. > > > Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 10:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HogyW-0001yh-9c; Thu, 17 May 2007 10:29:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HogyV-0001yH-0x; Thu, 17 May 2007 10:29:03 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HogyU-0001db-IQ; Thu, 17 May 2007 10:29:03 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 16:29:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 16:29:01 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301D8146C@SEHAN021MB.tcad.telia.se> In-Reply-To: <464C1692.10907@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceYYAw9yOWhSYlgQ1WolRjfFMfFwgAKXmwA References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> <464C1692.10907@levkowetz.com> From: To: , X-OriginalArrivalTime: 17 May 2007 14:29:01.0080 (UTC) FILETIME=[B65F6980:01C7988F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nemo@ietf.org, mip6@ietf.org, sgundave@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I share Henrik's view. Also from management point of view any new port-to-be-allowed is cumbersome. In general I prefer more future proof extensibility over slight performance hit thus I prefer the 4 bytes header like in 3519. I would assume that from an operator point of view something has gone wrong if tunneling over IPv4 is the most frequent way of using MIP6 ;) Cheers, Jouni > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Thursday, May 17, 2007 11:47 AM > To: Ahmad Muhanna > Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli > Subject: Re: [nemo] Re: [Mip6] The use of GRE >=20 > Folks, >=20 > on 2007-05-17 07:12 Ahmad Muhanna said the following: > > Hi Ryuji, > >=20 > > If we agree that a new UDP port for GRE, beside the one for=20 > IPv4/IPv6,=20 > > is needed, then why do not we use a new UDP port to indicate the=20 > > presence of the TLV which then can be used to indicate the=20 > next header=20 > > for many protocols including GRE and ESP. This way we save one UDP=20 > > port if we want to support ESP as per Vijay's proposal. >=20 > At least I am very far from agreeing on one additional=20 > assigned UDP port. The number of unassigned UDP port in the=20 > range that can be assigned by IANA (0 - 1023) is now down to=20 > 281, by my count, so this should be considered a scarce resource. >=20 > I'm not even sure whether it makes sense to ask for a new=20 > port for DS-MIPv6 rather than multiplex over for instance the=20 > MIPv4 port, but I think we can at least ask the question. =20 > But asking for 2 ports, to carry 2 different kinds of=20 > DS-MIPv6 payloads, seems just wrong. >=20 >=20 > Henrik >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 12:39:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj0Q-0003xk-FD; Thu, 17 May 2007 12:39:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj0O-0003xS-ID; Thu, 17 May 2007 12:39:08 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hoj0M-0007Q3-5m; Thu, 17 May 2007 12:39:08 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1179419945!14048261!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29227 invoked from network); 17 May 2007 16:39:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 17 May 2007 16:39:05 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4HGd48T011882; Thu, 17 May 2007 09:39:05 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l4HGd4CH020811; Thu, 17 May 2007 11:39:04 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-31-8-211.am.mot.com [10.31.8.211]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l4HGd12N020771; Thu, 17 May 2007 11:39:02 -0500 (CDT) Message-ID: <464C8524.2080704@gmail.com> Date: Thu, 17 May 2007 18:39:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] RE: [Mip6] The use of GRE References: <464B7BDD.6090506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000741-0, 17/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: nemo@ietf.org, Alexandru Petrescu , Sri Gundavelli , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alex, > > "Why GRE?" is a separate topic. If someone wants to use GRE > encapsulation to identify flows in DS-MIPv6, we would need to > reserve another UDP port. I think we rather should recommend to use existing application standardized tools to identify flows in DS-MIP6 instead of rushing to reserve new UDP port numbers. I think that if there is no need of GRE there is no need of GRE port number either. Alex > > Vijay > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Wednesday, May 16, 2007 2:47 PM >> To: Vijay Devarapalli >> Cc: Basavaraj Patil; ext Tsirtsis, George; Sri Gundavelli; >> Hesham Soliman; mip6@ietf.org; nemo@ietf.org >> Subject: Re: [nemo] RE: [Mip6] The use of GRE >> >> Vijay Devarapalli wrote: >>> Hello Raj, >>> >>> We might actually end up with option 2. I see three reserved >>> UDP ports with DS-MIPv6 already. >>> >>> 1. One UDP port indicating IPv4/IPv6. You parse the IP version >>> field to figure out whether it is IPv4 or IPv6. >>> 2. One UDP port for ESP encapsulation. This happens when you >>> protect DS-MIPv6 traffic with ESP and use UDP encapsulation >>> for NAT traversal. The packet format would be >>> IPv4 hdr (src=MN-IPv4-CoA, dst=HA-IPv4) >>> UDP hdr >>> ESP hdr >>> IPv6 (src=MN-IPv6-HoA, dst=CN) >>> Payload >>> 3. One reserved UDP port for GRE encapsulation in DS-MIPv6. >> Vijay, but _why_ reserving an UDP port for GRE encapsulation? >> >> Since Sri puts the accent so much on the technical merit, what is the >> technical merit of using GRE (compared to existing >> encapsulation methods)? >> >> Why developing two different ways for doing the same thing? >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 12:41:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj2Q-0004ov-Jf; Thu, 17 May 2007 12:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj2P-0004ok-3P; Thu, 17 May 2007 12:41:13 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hoj2O-0007vF-FR; Thu, 17 May 2007 12:41:13 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1179420071!1605804!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13135 invoked from network); 17 May 2007 16:41:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 17 May 2007 16:41:11 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4HGfB1L012462; Thu, 17 May 2007 09:41:11 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4HGfAQP024630; Thu, 17 May 2007 11:41:10 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-31-8-211.am.mot.com [10.31.8.211]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4HGf7lc024471; Thu, 17 May 2007 11:41:08 -0500 (CDT) Message-ID: <464C85A2.6070303@gmail.com> Date: Thu, 17 May 2007 18:41:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000741-0, 17/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ahmad Muhanna wrote: > Hi Ryuji, > > If we agree that a new UDP port for GRE, beside the one for IPv4/IPv6, > is needed, then why do not we use a new UDP port to indicate the > presence of the TLV which then can be used to indicate the next header > for many protocols including GRE and ESP. This way we save one UDP port > if we want to support ESP as per Vijay's proposal. Another possibility (no GRE, no new TLV. no new port number) is to extend existing Mobile IPv4 message types to contain whatever data that TLV or GRE needs. Alex > > Regards, > Ahmad > > >> -----Original Message----- >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >> Sent: Wednesday, May 16, 2007 6:17 PM >> To: Basavaraj Patil >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli >> Subject: Re: [nemo] Re: [Mip6] The use of GRE >> >> Hi Raj, >> >> >> >> On 2007/05/17, at 2:08, Basavaraj Patil wrote: >> >>> Some observations about the discussion so far: >>> >>> 1. If the only packet types encapsulated by the UDP header are >>> IPv4/6 then >>> we do not need the extra 4 byte header. >>> 2. The need for the 4 byte header to spell the encapsulated packet >>> type arises only if we believe GRE or other types of packets may be >>> encapsulated in the tunnel between the MN and HA. Yoshi (at >> least) has >>> indicated that he has had to implement GRE tunnelling >> support on the >>> MN. Would help if any others can respond and clarify if >> tunnelling GRE >>> over IP at the MN is normally done. >>> 3. The 4 byte header in every packet is an overhead. >> Depending on the >>> link type 4 bytes in every packet can be considered as >> being wasteful. >>> 4. The need for GRE encapsulation for NEMO is not apparent; I think >>> there was an explicit statement that GRE is not needed for NEMO. >>> >>> Recommendation: >>> >>> The DS-MIP6 I-D has been worked on at length in this WG. >> Its time to >>> get this published and implementations tested. >>> >>> Proceed with the current model where we only have either IPv4/6 >>> packets being encapsulated between the MN and HA by the UDP >> header. No >>> additional 4 byte header to be added. >>> >>> When there is a valid justification and need for supporting >>> encapsulation of GRE and/or other packet types, we can revise the >>> specification if needed. >>> >>> Since DS-MIP6 is a component of the PMIP6 work in Netlmm >> and there is >>> a need to support GRE encapsulation in that context, the Netlmm I-D >>> may extend the >>> DS-MIP6 spec and add the 4 byte header. >>> >> It seems that many people want to support GRE on DSMIP. >> I am fine with either 4byte header or UDP port for GRE. >> I personally prefer Vijay's suggestion (UDP port for GRE). >> >> I understand it is important for DSMIP to leave space for >> future extensions. >> But this additional feature can easily be re-defined in >> different spec as DSMIP extension. >> We don't need to specify it in DSMIP now. >> The separate doc can overwrite the DSMIP spec if needed. >> >> regards, >> ryuji >> >> >> >> >> >> >>> -Raj >>> >>> On 5/14/07 9:04 AM, "ext Tsirtsis, George" >>> wrote: >>> >>>> Folks, >>>> >>>> I have been trying to make sense of this discussion. After >> re-reading >>>> the whole thread I think we may be able to progress if we >> answer the >>>> following question: >>>> >>>> QUESTION: Does this group agree that GRE encapsulation needs to be >>>> supported in MIPv6? >>>> >>>> If the answer is "NO", then using the already defined UDP port and >>>> the IP version field to demux IPv4/IPv6 packets as already >> defined in >>>> DSMIPv6 is absolutely fine and there is no reason to change it. >>>> >>>> If the answer is "YES", then we have to consider the following: >>>> It is clear that the IP version field can not demux GRE. In that >>>> case: >>>> a) Leave GRE out of DSMIPv6 draft (which uses IP version field for >>>> demuxing). People interested in GRE should write up a >> draft defining >>>> how GRE is used in MIPv6. This is likely to result in a >> GRE specific >>>> method of encapsulation over UDP. This is likely to involve >>>> reservation of one more UDP port and the definition of a small >>>> pseudo-header as proposed by Sri and others. >>>> b) Be proactive and adopt the pseudo-header for all >> encapsulations. >>>> This would mean that DSMIPv6 draft is changed to indicate >> that over >>>> the reserved UDP port we add the TLV (or whatever >>>> structure) which indicates what the next header is i.e., >> IPv4, IPv6, >>>> GRE. >>>> >>>> >>>> Personally, I am not a big fun of supporting GRE encapsulation for >>>> MIPv6. The reason is that in IPv6 we do not have (and must never >>>> have) >>>> to deal with overlapping address spaces (the main use of GRE >>>> tunneling in MIPv4). >>>> >>>> Also note that even if we do decide to use the IP version >> field for >>>> demuxing now, there is nothing that prevents GRE >> encapsulation to be >>>> defined later, as indicated by (a) above, assuming that >> GRE support >>>> becomes necessary. Yes, then implementation will have to deal with >>>> two way of demuxing similar information but it is not the >> end of the >>>> world and it reduces the overhead (albeit not much) in the typical >>>> case. >>>> >>>> I hope this helps. >>>> Regards >>>> George >>>> >>>> >>>> -----Original Message----- >>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>> Sent: Friday, May 11, 2007 6:26 AM >>>> To: 'Hesham Soliman'; mip6@ietf.org; nemo@ietf.org >>>> Subject: RE: [Mip6] The use of GRE >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:Hesham@elevatemobile.com] >>>>> Sent: Thursday, May 10, 2007 10:20 PM >>>>> To: mip6@ietf.org; nemo@ietf.org >>>>> Subject: [Mip6] The use of GRE >>>>> >>>>> Hi all, >>>>> >>>>> This concensus call on issue 93 made me a bit confused >> about the use >>>>> of GRE. >>>>> I have a simple question: >>>>> >>>>> Why can't people that want to use GRE (for PMIP) run it >> as follows: >>>>> IP Heahder (proto 47 for GRE) >>>>> GRE Header >>>>> UDP >>>>> ....etc >>>>> >>>>> Why do we need to add another layer to qualifiers instead >> of using >>>>> the existing allocated numbers? >>>>> >>>>> It's been a couple of years since I read the GRE spec so >> I wanted to >>>>> understand if this format is a problem >>>>> >>>> Problem will be with the NAT/PAT device. It wont create >> NAT bindings >>>> from the UDP header encapped in the GRE header. >>>> >>>> Sri >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 12:56:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojGl-0002YO-Ik; Thu, 17 May 2007 12:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojGk-0002XZ-Ay; Thu, 17 May 2007 12:56:02 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojGi-0004a9-L8; Thu, 17 May 2007 12:56:02 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HojGe-0005Kr-2T; Thu, 17 May 2007 18:55:56 +0200 Message-ID: <464C891C.9010407@levkowetz.com> Date: Thu, 17 May 2007 18:55:56 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> <464C1692.10907@levkowetz.com> <750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> In-Reply-To: <750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: ryuji.wakikawa@gmail.com, amuhanna@nortel.com, basavaraj.patil@nsn.com, nemo@ietf.org, mip6@ietf.org, sgundave@cisco.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ryuji, on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > Hi Henrik, > > I have to agree with you, but the additional 4 bytes in air > are also consumed scarce resource, i.e wireless... Humm. What is the bandwidth of your expected wireless link, how often do you send BUs, and how much other traffic? With very simple assumptions, like a voice stream and a BU every 4 minutes, you get: Voice: 16kbit/s * 4 min = 16*1024/8*4*60 bytes = 491520 bytes 4 bytes overhead per BU/BA message = 8 bytes Extra overhead due to 4-byte header: 0.0016% I think we can ignore this. Henrik > regards, > ryuji > > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > >> Folks, >> >> on 2007-05-17 07:12 Ahmad Muhanna said the following: >>> Hi Ryuji, >>> >>> If we agree that a new UDP port for GRE, beside the one for IPv4/ >>> IPv6, >>> is needed, then why do not we use a new UDP port to indicate the >>> presence of the TLV which then can be used to indicate the next >>> header >>> for many protocols including GRE and ESP. This way we save one UDP >>> port >>> if we want to support ESP as per Vijay's proposal. >> >> At least I am very far from agreeing on one additional assigned UDP >> port. The number of unassigned UDP port in the range that can be >> assigned by IANA (0 - 1023) is now down to 281, by my count, so this >> should be considered a scarce resource. >> >> I'm not even sure whether it makes sense to ask for a new port for >> DS-MIPv6 >> rather than multiplex over for instance the MIPv4 port, but I think >> we can >> at least ask the question. But asking for 2 ports, to carry 2 >> different >> kinds of DS-MIPv6 payloads, seems just wrong. >> >> >> Henrik > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 14:07:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HokNV-0007Bq-9c; Thu, 17 May 2007 14:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HokNU-0007Bi-4r; Thu, 17 May 2007 14:07:04 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HokNS-0006jh-Ra; Thu, 17 May 2007 14:07:04 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4HI6iB17602; Thu, 17 May 2007 18:06:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 13:06:41 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711451AF72@zrc2hxm2.corp.nortel.com> In-Reply-To: <464C891C.9010407@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE Thread-Index: AceYpD+DsLVp0dCOS4qqYXGVbtPRtAACaMYA References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com> <464C1692.10907@levkowetz.com> <750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> From: "Ahmad Muhanna" To: "Henrik Levkowetz" , "RYUJI WAKIKAWA" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 > Hi Ryuji, >=20 > on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > > Hi Henrik, > >=20 > > I have to agree with you, but the additional 4 bytes in air=20 > are also=20 > > consumed scarce resource, i.e wireless... >=20 > Humm. What is the bandwidth of your expected wireless link,=20 > how often do you send BUs, and how much other traffic? >=20 > With very simple assumptions, like a voice stream and a BU=20 > every 4 minutes, you get: >=20 > Voice: 16kbit/s * 4 min =3D 16*1024/8*4*60 bytes =3D 491520 bytes > 4 bytes overhead per BU/BA message =3D 8 bytes >=20 > Extra overhead due to 4-byte header: 0.0016% >=20 > I think we can ignore this. [Ahmad] Yep. I like this simple yet valuable analysis.:) >=20 >=20 > Henrik >=20 >=20 > > regards, > > ryuji > >=20 > > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > >=20 > >> Folks, > >> > >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > >>> Hi Ryuji, > >>> > >>> If we agree that a new UDP port for GRE, beside the one for IPv4/=20 > >>> IPv6, is needed, then why do not we use a new UDP port to=20 > indicate=20 > >>> the presence of the TLV which then can be used to=20 > indicate the next=20 > >>> header for many protocols including GRE and ESP. This way we save=20 > >>> one UDP port if we want to support ESP as per Vijay's proposal. > >> > >> At least I am very far from agreeing on one additional=20 > assigned UDP=20 > >> port. The number of unassigned UDP port in the range that can be=20 > >> assigned by IANA (0 - 1023) is now down to 281, by my=20 > count, so this=20 > >> should be considered a scarce resource. > >> > >> I'm not even sure whether it makes sense to ask for a new port for > >> DS-MIPv6 > >> rather than multiplex over for instance the MIPv4 port,=20 > but I think=20 > >> we can at least ask the question. But asking for 2 ports,=20 > to carry 2=20 > >> different kinds of DS-MIPv6 payloads, seems just wrong. > >> > >> > >> Henrik > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 21:02:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoqrK-0007rX-BG; Thu, 17 May 2007 21:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoqrI-0007rH-H8; Thu, 17 May 2007 21:02:16 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoqrH-00033e-7l; Thu, 17 May 2007 21:02:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [nemo] Re: [Mip6] The use of GRE Date: Thu, 17 May 2007 18:02:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceYpIK0JbIgR5eHRXuNGgD/CFGyigAQydPQ References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> From: "Vijay Devarapalli" To: "Henrik Levkowetz" , "RYUJI WAKIKAWA" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Isn't the 4 byte overhead on every data packet in the voice stream? Not just the BU/BAck. I must be missing something. Vijay=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Thursday, May 17, 2007 9:56 AM > To: RYUJI WAKIKAWA > Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli; Basavaraj=20 > Patil; Ahmad Muhanna > Subject: Re: [nemo] Re: [Mip6] The use of GRE >=20 > Hi Ryuji, >=20 > on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > > Hi Henrik, > >=20 > > I have to agree with you, but the additional 4 bytes in air > > are also consumed scarce resource, i.e wireless... >=20 > Humm. What is the bandwidth of your expected wireless link, > how often do you send BUs, and how much other traffic? >=20 > With very simple assumptions, like a voice stream and a BU > every 4 minutes, you get: >=20 > Voice: 16kbit/s * 4 min =3D 16*1024/8*4*60 bytes =3D 491520 bytes > 4 bytes overhead per BU/BA message =3D 8 bytes >=20 > Extra overhead due to 4-byte header: 0.0016% >=20 > I think we can ignore this. >=20 >=20 > Henrik >=20 >=20 > > regards, > > ryuji > >=20 > > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > >=20 > >> Folks, > >> > >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > >>> Hi Ryuji, > >>> > >>> If we agree that a new UDP port for GRE, beside the one for IPv4/=20 > >>> IPv6, > >>> is needed, then why do not we use a new UDP port to indicate the > >>> presence of the TLV which then can be used to indicate the next =20 > >>> header > >>> for many protocols including GRE and ESP. This way we=20 > save one UDP =20 > >>> port > >>> if we want to support ESP as per Vijay's proposal. > >> > >> At least I am very far from agreeing on one additional assigned UDP > >> port. The number of unassigned UDP port in the range that can be > >> assigned by IANA (0 - 1023) is now down to 281, by my=20 > count, so this > >> should be considered a scarce resource. > >> > >> I'm not even sure whether it makes sense to ask for a new=20 > port for =20 > >> DS-MIPv6 > >> rather than multiplex over for instance the MIPv4 port,=20 > but I think =20 > >> we can > >> at least ask the question. But asking for 2 ports, to carry 2 =20 > >> different > >> kinds of DS-MIPv6 payloads, seems just wrong. > >> > >> > >> Henrik > >=20 > >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 17 21:05:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoquU-0001tj-Cw; Thu, 17 May 2007 21:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoquT-0001tb-4W; Thu, 17 May 2007 21:05:33 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoquP-0003Z9-3c; Thu, 17 May 2007 21:05:33 -0400 Received: from oaamta05ps.mx.bigpond.com ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070518010526.TPMN23363.omta05ps.mx.bigpond.com@oaamta05ps.mx.bigpond.com>; Fri, 18 May 2007 01:05:26 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta05ps.mx.bigpond.com with ESMTP id <20070518010526.NGNL11252.oaamta05ps.mx.bigpond.com@PC20005>; Fri, 18 May 2007 01:05:26 +0000 From: "Hesham Soliman" To: "'Henrik Levkowetz'" , "'RYUJI WAKIKAWA'" Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Fri, 18 May 2007 11:05:16 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceYpIGdGJvQHyPgSXCMHKRdu0PQ1gAQ/X0w In-Reply-To: <464C891C.9010407@levkowetz.com> Message-Id: <20070518010526.NGNL11252.oaamta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: nemo@ietf.org, mip6@ietf.org, 'Sri Gundavelli' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > With very simple assumptions, like a voice stream and a BU > every 4 minutes, you get: > > Voice: 16kbit/s * 4 min = 16*1024/8*4*60 bytes = 491520 bytes > 4 bytes overhead per BU/BA message = 8 bytes => That's not accurate, the 4-byte o/h is in every packet, it's not just the BU/BA. Hesham > > Extra overhead due to 4-byte header: 0.0016% > > I think we can ignore this. > > > Henrik > > > > regards, > > ryuji > > > > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > > > >> Folks, > >> > >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > >>> Hi Ryuji, > >>> > >>> If we agree that a new UDP port for GRE, beside the one > for IPv4/ > >>> IPv6, > >>> is needed, then why do not we use a new UDP port to indicate the > >>> presence of the TLV which then can be used to indicate the next > >>> header > >>> for many protocols including GRE and ESP. This way we > save one UDP > >>> port > >>> if we want to support ESP as per Vijay's proposal. > >> > >> At least I am very far from agreeing on one additional > assigned UDP > >> port. The number of unassigned UDP port in the range that can be > >> assigned by IANA (0 - 1023) is now down to 281, by my > count, so this > >> should be considered a scarce resource. > >> > >> I'm not even sure whether it makes sense to ask for a new > port for > >> DS-MIPv6 > >> rather than multiplex over for instance the MIPv4 port, > but I think > >> we can > >> at least ask the question. But asking for 2 ports, to carry 2 > >> different > >> kinds of DS-MIPv6 payloads, seems just wrong. > >> > >> > >> Henrik > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 18 04:35:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoxw2-0005V5-4w; Fri, 18 May 2007 04:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoxw1-0005Uu-6w; Fri, 18 May 2007 04:35:37 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoxvz-0005FX-HI; Fri, 18 May 2007 04:35:37 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 May 2007 10:35:35 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4I8ZYmV006552; Fri, 18 May 2007 10:35:34 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4I8ZQDf001073; Fri, 18 May 2007 08:35:33 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:35:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: [nemo] RE: [Mip6] The use of GRE) Date: Fri, 18 May 2007 10:35:02 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03F2CB04@xmb-ams-337.emea.cisco.com> In-Reply-To: <46499FC4.5030506@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: [nemo] RE: [Mip6] The use of GRE) Thread-Index: AceW6AOh2ULQdzZSRw2mEixcfn2HUACPg2zg References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com><5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> <46499FC4.5030506@gmail.com> From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 18 May 2007 08:35:09.0519 (UTC) FILETIME=[71CA0DF0:01C79927] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4852; t=1179477334; x=1180341334; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20L3-in-L2-in-L3-in-L2=20and=20GRE=20improves=20MIP6=20 security=20(was=3A=20[nemo]=20RE=3A=20[Mip6]=20The=20use=20of=20GRE) |Sender:=20; bh=8urUojDdt97zzeq6J2Takytxj4+Vn1NsZVyJsJp87c8=; b=RuVHRmYFupZCyiDpXbnxyhJZD51TdWRYt5272r0voB4A52hp+/S1VRHBytRnhQKTO/5xnNA8 /ksifyLf7u7ZfjCqfM7MxGjhpuLamz3IAOgMIezLe4mZNrP7GUKD2Dyj; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: nemo@ietf.org, mip6@ietf.org, "Sri Gundavelli \(sgundave\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex: I'm surprised you're surprised. That's what L2TP has always been.=20 You might want to read about softwire, and in particular the new developments in: http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2t pv2-03.txt=20 Pascal >-----Original Message----- >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >Sent: Tuesday, May 15, 2007 1:56 PM >To: Pascal Thubert (pthubert) >Cc: Narayanan, Vidya; Hesham Soliman; Sri Gundavelli (sgundave); mip6@ietf.org; nemo@ietf.org >Subject: Re: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: [nemo] RE: [Mip6] The use of >GRE) > >Pascal Thubert (pthubert) wrote: >> Hi Vidya >> >> I think the discussion started with the idea of making the DSMIP >> tunnel more open to tunneling *anything*. This could be or have been >> done separately from DSMIP, for instance at the time of MIP6 or NEMO. >> If you look at it, all these protocols are tunnel set-up and >> maintenance protocols, with the HoA as the ID for the tunnel. So why >> tunnel only IPv6 in there? >> >> That was (one of) Hesham's valid point(s) when he started his DS-MIP >> draft. So now we have support to tunnel IPv4, and we discriminate >> with protocol type. And the issue comes like is that all we'll ever >> need? Can't we make that more open for future use? And is this draft >> the right time for opening up? >> >> One question was, which future use? >> >> One traditional use is L2 tunneling; > >IMHO it is not a good idea to tunnel L3 in L2 in L3 and in L2. This is >an architectural mistake: IPv6-MACheader-IPv4-MACheader. > >I think this is what you are proposing with encapsulating L2 tunnelling >in GRE, is it so? > >> if you want your MR to tunnel multiple flows treated as multiple >> VLANs in the mobile network, you might want to keep the VLANs up to >> the HA by inserting 802.1Q information, or the whole or compressed >> Ethernet packet in the MRHA tunnel. > >I think it is not a good idea to intersperse an L2 header between two >IPv6 base headers. > >I think it is not good idea to propagate 802.1q information between MR >and HA. > >> The L3 alternative (multiple VRFs) is much more complex to deploy on >> a MR. > >I am not sure what you mean. > >What is VRF? > >Also, the L3 alternative (using NEMOv6 base spec and not using L2 >headers between base IPv6 headers), is implemented widely. I am not >sure why you say it is much more complex. > >> So I do agree with the original point that there will be multiple >> usages for that tunnel. At this point, I feel that we are back to a >> previous discussion on reverse Routability test: in traditional MIP >> or NEMO (without SeND) the MR can not be sure of its CoA, > >What do you mean? Do you mean that NEMOv6+SeND is not enough for >securing MR ownership of its Care-of Address? And that NEMOv6+GRE >encapsulation (instead of IPv6-in-IPv6) will make sure MR has a safe >Care-of Address? > >> and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP the >> right place to solve a problem that was already there? > >Good question. I agree the security model with DS-MIPv6 and IPv4 >Care-of Addresses is different than simple NEMOv6. But I don't see GRE >a solution here. Why do you see GRE as a security solution for DS-MIPv6? > >If HoA is used for identitying IP tunnels then IPsec SAs can link these >HoAs, because HoA is an IP address. On the contrary, if GRE key is used >to identify tunnels then GRE key can not be used with IPsec SAs. >Besides, I don't think there exist protocol selectors for GRE headers. > >> I suspect that we have made some clear room for a number of small >> drafts that will apply to all MIP, DS-MIP and NEMO, to improve the >> security of the system or like in this case make it more open to the >> future. The new drafts will have to cope with existing protocols, >> including IPv6 in the MIP6 tunnel without GRE which is already a fact >> of life. > >I agree MIP6 tunnel without GRE is already a fact of life. > >But I don't see how GRE improves security of MIP6, DS-MIPv6 or NEMO. > >> My own suggestion is to be ready to receive these drafts as new WG >> items and carry them out swiftly, but not make a dependency for DS >> MIP on these discussions, either. DS-MIP has been pretty stable for a >> while, and the recent changes that were discussed (like the mapped >> CoA) were more on the religious side than fixing practical problems. > >Ok, somehow agree. > >Alex > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 18 04:40:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy17-000055-1U; Fri, 18 May 2007 04:40:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy15-0008WC-KW; Fri, 18 May 2007 04:40:51 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoy13-0005bo-Qz; Fri, 18 May 2007 04:40:51 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1Hoy11-0005nX-1r; Fri, 18 May 2007 10:40:47 +0200 Message-ID: <464D668E.5090000@levkowetz.com> Date: Fri, 18 May 2007 10:40:46 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Vijay.Devarapalli@AzaireNet.com, ryuji.wakikawa@gmail.com, nemo@ietf.org, mip6@ietf.org, sgundave@cisco.com, basavaraj.patil@nsn.com, amuhanna@nortel.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: nemo@ietf.org, Sri Gundavelli , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, on 2007-05-18 03:02 Vijay Devarapalli said the following: > Isn't the 4 byte overhead on every data packet in the voice > stream? Not just the BU/BAck. Yes, of course. Quite right. Wrong time of day for me, I guess. So the correct data depends on packet size, but not on BU interval. For a 1280 total packet size, this means the overhead is 4/1276, or 0.3%. For a 16kbps voice stream, the payload size is 40 bytes, the IPv4 header is 20bytes, the first udp header 8, the IPv6 header 40, the second udp header is 8, and the rtp header is 12 bytes. Altogether 88 bytes header and 40 bytes payload, which gives the added overhead of 4 bytes and 4/128 = 3.1%. This is more serious, but also shows that we should probably consider whether we can reduce/compress the whole set of headers, rather than focus on the demultiplexing-enabling 4 bytes. It might even be the case that having the demultiplexing-enabling 4 bytes gives us the freedom we need to define alternative tunnelling with less overhead. Henrik > I must be missing something. > > Vijay > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: Thursday, May 17, 2007 9:56 AM >> To: RYUJI WAKIKAWA >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli; Basavaraj >> Patil; Ahmad Muhanna >> Subject: Re: [nemo] Re: [Mip6] The use of GRE >> >> Hi Ryuji, >> >> on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: >> > Hi Henrik, >> > >> > I have to agree with you, but the additional 4 bytes in air >> > are also consumed scarce resource, i.e wireless... >> >> Humm. What is the bandwidth of your expected wireless link, >> how often do you send BUs, and how much other traffic? >> >> With very simple assumptions, like a voice stream and a BU >> every 4 minutes, you get: >> >> Voice: 16kbit/s * 4 min = 16*1024/8*4*60 bytes = 491520 bytes >> 4 bytes overhead per BU/BA message = 8 bytes >> >> Extra overhead due to 4-byte header: 0.0016% >> >> I think we can ignore this. >> >> >> Henrik >> >> >> > regards, >> > ryuji >> > >> > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: >> > >> >> Folks, >> >> >> >> on 2007-05-17 07:12 Ahmad Muhanna said the following: >> >>> Hi Ryuji, >> >>> >> >>> If we agree that a new UDP port for GRE, beside the one for IPv4/ >> >>> IPv6, >> >>> is needed, then why do not we use a new UDP port to indicate the >> >>> presence of the TLV which then can be used to indicate the next >> >>> header >> >>> for many protocols including GRE and ESP. This way we >> save one UDP >> >>> port >> >>> if we want to support ESP as per Vijay's proposal. >> >> >> >> At least I am very far from agreeing on one additional assigned UDP >> >> port. The number of unassigned UDP port in the range that can be >> >> assigned by IANA (0 - 1023) is now down to 281, by my >> count, so this >> >> should be considered a scarce resource. >> >> >> >> I'm not even sure whether it makes sense to ask for a new >> port for >> >> DS-MIPv6 >> >> rather than multiplex over for instance the MIPv4 port, >> but I think >> >> we can >> >> at least ask the question. But asking for 2 ports, to carry 2 >> >> different >> >> kinds of DS-MIPv6 payloads, seems just wrong. >> >> >> >> >> >> Henrik >> > >> > >> >> > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 18 04:41:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy1l-0000db-8q; Fri, 18 May 2007 04:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoy1j-0000cF-L5; Fri, 18 May 2007 04:41:31 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hoy1i-0005gQ-8U; Fri, 18 May 2007 04:41:31 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1179477689!15737789!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13826 invoked from network); 18 May 2007 08:41:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 18 May 2007 08:41:29 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4I8fS2T029026; Fri, 18 May 2007 01:41:29 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4I8fSgu016676; Fri, 18 May 2007 03:41:28 -0500 (CDT) Received: from [127.0.0.1] ([10.129.42.5]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4I8fPZV016655; Fri, 18 May 2007 03:41:26 -0500 (CDT) Message-ID: <464D66B5.2070509@gmail.com> Date: Fri, 18 May 2007 10:41:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <016901c79392$8477f1f0$d4f6200a@amer.cisco.com><5tvsa1$iv8iu@smtp03.syd.iprimus.net.au> <7892795E1A87F04CADFCCF41FADD00FC03F2BC4F@xmb-ams-337.emea.cisco.com> <46499FC4.5030506@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC03F2CB04@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03F2CB04@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000741-0, 17/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: nemo@ietf.org, Alexandru Petrescu , "Sri Gundavelli \(sgundave\)" , mip6@ietf.org Subject: [Mip6] Re: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Alex: > > I'm surprised you're surprised. That's what L2TP has always been. > You might want to read about softwire, and in particular the new > developments in: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2t > pv2-03.txt You're right, L2TP is to tunnel L2 packets. If GRE does the same thing as L2TP then why using GRE and not L2TP? Alex > > Pascal > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Tuesday, May 15, 2007 1:56 PM >> To: Pascal Thubert (pthubert) >> Cc: Narayanan, Vidya; Hesham Soliman; Sri Gundavelli (sgundave); > mip6@ietf.org; nemo@ietf.org >> Subject: Re: L3-in-L2-in-L3-in-L2 and GRE improves MIP6 security (was: > [nemo] RE: [Mip6] The use of >> GRE) >> >> Pascal Thubert (pthubert) wrote: >>> Hi Vidya >>> >>> I think the discussion started with the idea of making the DSMIP >>> tunnel more open to tunneling *anything*. This could be or have been >>> done separately from DSMIP, for instance at the time of MIP6 or NEMO. >>> If you look at it, all these protocols are tunnel set-up and >>> maintenance protocols, with the HoA as the ID for the tunnel. So why >>> tunnel only IPv6 in there? >>> >>> That was (one of) Hesham's valid point(s) when he started his DS-MIP >>> draft. So now we have support to tunnel IPv4, and we discriminate >>> with protocol type. And the issue comes like is that all we'll ever >>> need? Can't we make that more open for future use? And is this draft >>> the right time for opening up? >>> >>> One question was, which future use? >>> >>> One traditional use is L2 tunneling; >> IMHO it is not a good idea to tunnel L3 in L2 in L3 and in L2. This is >> an architectural mistake: IPv6-MACheader-IPv4-MACheader. >> >> I think this is what you are proposing with encapsulating L2 tunnelling >> in GRE, is it so? >> >>> if you want your MR to tunnel multiple flows treated as multiple >>> VLANs in the mobile network, you might want to keep the VLANs up to >>> the HA by inserting 802.1Q information, or the whole or compressed >>> Ethernet packet in the MRHA tunnel. >> I think it is not a good idea to intersperse an L2 header between two >> IPv6 base headers. >> >> I think it is not good idea to propagate 802.1q information between MR >> and HA. >> >>> The L3 alternative (multiple VRFs) is much more complex to deploy on >>> a MR. >> I am not sure what you mean. >> >> What is VRF? >> >> Also, the L3 alternative (using NEMOv6 base spec and not using L2 >> headers between base IPv6 headers), is implemented widely. I am not >> sure why you say it is much more complex. >> >>> So I do agree with the original point that there will be multiple >>> usages for that tunnel. At this point, I feel that we are back to a >>> previous discussion on reverse Routability test: in traditional MIP >>> or NEMO (without SeND) the MR can not be sure of its CoA, >> What do you mean? Do you mean that NEMOv6+SeND is not enough for >> securing MR ownership of its Care-of Address? And that NEMOv6+GRE >> encapsulation (instead of IPv6-in-IPv6) will make sure MR has a safe >> Care-of Address? >> >>> and DS-MIP makes that worse because of IPv4 roaming. Is DS-MIP the >>> right place to solve a problem that was already there? >> Good question. I agree the security model with DS-MIPv6 and IPv4 >> Care-of Addresses is different than simple NEMOv6. But I don't see GRE >> a solution here. Why do you see GRE as a security solution for > DS-MIPv6? >> If HoA is used for identitying IP tunnels then IPsec SAs can link these >> HoAs, because HoA is an IP address. On the contrary, if GRE key is > used >> to identify tunnels then GRE key can not be used with IPsec SAs. >> Besides, I don't think there exist protocol selectors for GRE headers. >> >>> I suspect that we have made some clear room for a number of small >>> drafts that will apply to all MIP, DS-MIP and NEMO, to improve the >>> security of the system or like in this case make it more open to the >>> future. The new drafts will have to cope with existing protocols, >>> including IPv6 in the MIP6 tunnel without GRE which is already a fact >>> of life. >> I agree MIP6 tunnel without GRE is already a fact of life. >> >> But I don't see how GRE improves security of MIP6, DS-MIPv6 or NEMO. >> >>> My own suggestion is to be ready to receive these drafts as new WG >>> items and carry them out swiftly, but not make a dependency for DS >>> MIP on these discussions, either. DS-MIP has been pretty stable for a >>> while, and the recent changes that were discussed (like the mapped >>> CoA) were more on the religious side than fixing practical problems. >> Ok, somehow agree. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 18 14:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7dl-0007lN-Is; Fri, 18 May 2007 14:57:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7dk-0007iZ-E4; Fri, 18 May 2007 14:57:24 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp7dk-0000Vj-2y; Fri, 18 May 2007 14:57:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [nemo] Re: [Mip6] The use of GRE Date: Fri, 18 May 2007 11:57:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceZKD2JhEPojzyBQaiTYPefHyxdogAVdT2w References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> From: "Vijay Devarapalli" To: "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: nemo@ietf.org, Sri Gundavelli , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Henrik,=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Friday, May 18, 2007 1:41 AM > To: Vijay Devarapalli > Cc: RYUJI WAKIKAWA; nemo@ietf.org; mip6@ietf.org; Sri=20 > Gundavelli; Basavaraj Patil; Ahmad Muhanna > Subject: Re: [nemo] Re: [Mip6] The use of GRE >=20 > Hi Vijay, >=20 > on 2007-05-18 03:02 Vijay Devarapalli said the following: > > Isn't the 4 byte overhead on every data packet in the voice > > stream? Not just the BU/BAck. >=20 > Yes, of course. Quite right. Wrong time of day for me, I guess. >=20 > So the correct data depends on packet size, but not on BU interval. > For a 1280 total packet size, this means the overhead is 4/1276, > or 0.3%. >=20 > For a 16kbps voice stream, the payload size is 40 bytes, the IPv4 > header is 20bytes, the first udp header 8, the IPv6 header 40, the > second udp header is 8, and the rtp header is 12 bytes. Altogether > 88 bytes header and 40 bytes payload, which gives the added overhead > of 4 bytes and 4/128 =3D 3.1%. I would divide by 40, since we are calculating the overhead compared=20 to the actual payload, 4/40 =3D 10%. Vijay > This is more serious, but also shows that we should probably consider > whether we can reduce/compress the whole set of headers, rather than > focus on the demultiplexing-enabling 4 bytes. It might even be the > case that having the demultiplexing-enabling 4 bytes gives us the > freedom we need to define alternative tunnelling with less overhead. >=20 >=20 > Henrik >=20 >=20 > > I must be missing something. > >=20 > > Vijay=20 > >=20 > >> -----Original Message----- > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > >> Sent: Thursday, May 17, 2007 9:56 AM > >> To: RYUJI WAKIKAWA > >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli; Basavaraj=20 > >> Patil; Ahmad Muhanna > >> Subject: Re: [nemo] Re: [Mip6] The use of GRE > >>=20 > >> Hi Ryuji, > >>=20 > >> on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > >> > Hi Henrik, > >> >=20 > >> > I have to agree with you, but the additional 4 bytes in air > >> > are also consumed scarce resource, i.e wireless... > >>=20 > >> Humm. What is the bandwidth of your expected wireless link, > >> how often do you send BUs, and how much other traffic? > >>=20 > >> With very simple assumptions, like a voice stream and a BU > >> every 4 minutes, you get: > >>=20 > >> Voice: 16kbit/s * 4 min =3D 16*1024/8*4*60 bytes =3D 491520 bytes > >> 4 bytes overhead per BU/BA message =3D 8 bytes > >>=20 > >> Extra overhead due to 4-byte header: 0.0016% > >>=20 > >> I think we can ignore this. > >>=20 > >>=20 > >> Henrik > >>=20 > >>=20 > >> > regards, > >> > ryuji > >> >=20 > >> > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > >> >=20 > >> >> Folks, > >> >> > >> >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > >> >>> Hi Ryuji, > >> >>> > >> >>> If we agree that a new UDP port for GRE, beside the=20 > one for IPv4/=20 > >> >>> IPv6, > >> >>> is needed, then why do not we use a new UDP port to=20 > indicate the > >> >>> presence of the TLV which then can be used to indicate=20 > the next =20 > >> >>> header > >> >>> for many protocols including GRE and ESP. This way we=20 > >> save one UDP =20 > >> >>> port > >> >>> if we want to support ESP as per Vijay's proposal. > >> >> > >> >> At least I am very far from agreeing on one additional=20 > assigned UDP > >> >> port. The number of unassigned UDP port in the range=20 > that can be > >> >> assigned by IANA (0 - 1023) is now down to 281, by my=20 > >> count, so this > >> >> should be considered a scarce resource. > >> >> > >> >> I'm not even sure whether it makes sense to ask for a new=20 > >> port for =20 > >> >> DS-MIPv6 > >> >> rather than multiplex over for instance the MIPv4 port,=20 > >> but I think =20 > >> >> we can > >> >> at least ask the question. But asking for 2 ports, to carry 2 =20 > >> >> different > >> >> kinds of DS-MIPv6 payloads, seems just wrong. > >> >> > >> >> > >> >> Henrik > >> >=20 > >> >=20 > >>=20 > >>=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 18 20:13:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpCZ7-0001gO-Dh; Fri, 18 May 2007 20:12:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpCZ6-0001gE-Eh for mip6@ietf.org; Fri, 18 May 2007 20:12:56 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpCZ6-0004I0-2p for mip6@ietf.org; Fri, 18 May 2007 20:12:56 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4J0Cs4p005493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2007 17:12:55 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4J0Csn6014511; Fri, 18 May 2007 17:12:54 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 17:12:54 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 May 2007 17:12:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised IFARE problem statement Thread-Index: AceZqFb+7Zzt3wsaQSC+M9cMgF7s1AAAN1VA From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 19 May 2007 00:12:54.0409 (UTC) FILETIME=[7246EF90:01C799AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ietf-ipsec-failover@vpnc.org Subject: [Mip6] FW: Revised IFARE problem statement X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I'm forwarding this to MIP6 so that we can get more people to review the draft. The IFARE work is targeted towards enabling a quick Home Agent recovery from an IPsec perspective and hence relates to the MIP6 HA reliability work under progress. =20 Please review and send any comments/questions either to me offline or to the IFARE mailing list (ietf-ipsec-failover@vpnc.org). Please refrain from having the discussion on the MIP6 list, unless the questions specifically relate to MIP6. In any event, copying the IFARE list would be appreciated.=20 To provide some more background, while IFARE is targeting a generic IKEv2 session resumption mechanism that would help resuming IPsec sessions rather quickly upon the need for a gateway switch (or reconnect when a gateway reboots), the mechanism is meant to help quicker recovery from Home Agent switches in MIP6. In the process, it is feasible that certain additional optimizations may be applicable specifically for the MIP6 use. Such optimizations won't be in the scope of IFARE itself. Using the mechanisms that will be developed in IFARE, it may be possible to optimize the MIP6 use of it further and we could consider that as part of the HA reliability work if applicable. So, for the purpose of the IFARE work, please review to ensure that the goals in this draft cover everything needed for IPsec usage in MIP6. =20 Thanks, Vidya > -----Original Message----- > From: Narayanan, Vidya=20 > Sent: Friday, May 18, 2007 4:58 PM > To: ietf-ipsec-failover@vpnc.org > Cc: gregory.ietf@gmail.com; 'Chowdhury, Kuntal'; 'Vijay=20 > Devarapalli'; 'Kent Leung (kleung)' > Subject: Revised IFARE problem statement >=20 > All, > After talking to some more folks in the mobility space, I've=20 > updated the PS to reflect the scenarios in 3G networks and=20 > the relation to the MIP6 Home Agent reliability work in a=20 > better fashion. Consequently, some clarifications on the=20 > goals have also been added. This revision also addresses=20 > Gregory's comments that were sent to the list. =20 >=20 > Until the updated draft is available at the IETF repository,=20 > it can be found at=20 > http://www.geocities.com/hellovidya/draft-vidya-ipsec-failover -ps-02.txt. =20 >=20 > Please review and comment. Folks on the cc list, I'd=20 > especially like a review from you all to ensure that this=20 > revised draft captures your suggestions and if the goals now=20 > cover the cases needed for the MIP6 Home Agent reliability=20 > work in your view.=20 >=20 > Thanks, > Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 18 21:26:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpDif-00030S-FT; Fri, 18 May 2007 21:26:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpDie-00030K-GJ; Fri, 18 May 2007 21:26:52 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpDid-0005Qn-61; Fri, 18 May 2007 21:26:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4J1QVf26395; Sat, 19 May 2007 01:26:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Fri, 18 May 2007 20:26:30 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371145D60D3@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE Thread-Index: AceZKD2JhEPojzyBQaiTYPefHyxdogAVdT2wAAypjwA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, > > Subject: Re: [nemo] Re: [Mip6] The use of GRE > >=20 > > Hi Vijay, > >=20 > > on 2007-05-18 03:02 Vijay Devarapalli said the following: > > > Isn't the 4 byte overhead on every data packet in the=20 > voice stream?=20 > > > Not just the BU/BAck. > >=20 > > Yes, of course. Quite right. Wrong time of day for me, I guess. > >=20 > > So the correct data depends on packet size, but not on BU interval. > > For a 1280 total packet size, this means the overhead is 4/1276, or=20 > > 0.3%. > >=20 > > For a 16kbps voice stream, the payload size is 40 bytes, the IPv4=20 > > header is 20bytes, the first udp header 8, the IPv6 header 40, the=20 > > second udp header is 8, and the rtp header is 12 bytes. Altogether > > 88 bytes header and 40 bytes payload, which gives the added=20 > overhead=20 > > of 4 bytes and 4/128 =3D 3.1%. >=20 > I would divide by 40, since we are calculating the overhead=20 > compared to the actual payload, 4/40 =3D 10%. [Ahmad] Dividing by 40, IMO, is called a misleading and statically biased methodology. The wireless link does not know nor care what is payload and what is not. The wireless link probably cares that a packet of a length of 124 is now 128 after adding the TLV. I thought what Henrik was trying to quantify is the impact on the wireless link bandwidth due to the added 4 bytes TLV. On the other hand, let me say that this is almost the worst case scenario, however, for example if FTP in the picture and let us assume a packet length of 1300 bytes, then the impact is about 0.3%. One more thing, If we think of compressing this TLV, we probably end up with one byte! My 1.5 cents. :) >=20 > Vijay >=20 >=20 > > This is more serious, but also shows that we should=20 > probably consider=20 > > whether we can reduce/compress the whole set of headers,=20 > rather than=20 > > focus on the demultiplexing-enabling 4 bytes. It might even be the=20 > > case that having the demultiplexing-enabling 4 bytes gives us the=20 > > freedom we need to define alternative tunnelling with less overhead. > >=20 > >=20 > > Henrik > >=20 > >=20 > > > I must be missing something. > > >=20 > > > Vijay > > >=20 > > >> -----Original Message----- > > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > >> Sent: Thursday, May 17, 2007 9:56 AM > > >> To: RYUJI WAKIKAWA > > >> Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli;=20 > Basavaraj Patil;=20 > > >> Ahmad Muhanna > > >> Subject: Re: [nemo] Re: [Mip6] The use of GRE > > >>=20 > > >> Hi Ryuji, > > >>=20 > > >> on 2007-05-17 15:28 RYUJI WAKIKAWA said the following: > > >> > Hi Henrik, > > >> >=20 > > >> > I have to agree with you, but the additional 4 bytes=20 > in air are=20 > > >> > also consumed scarce resource, i.e wireless... > > >>=20 > > >> Humm. What is the bandwidth of your expected wireless link, how=20 > > >> often do you send BUs, and how much other traffic? > > >>=20 > > >> With very simple assumptions, like a voice stream and a=20 > BU every 4=20 > > >> minutes, you get: > > >>=20 > > >> Voice: 16kbit/s * 4 min =3D 16*1024/8*4*60 bytes =3D 491520 = bytes > > >> 4 bytes overhead per BU/BA message =3D 8 bytes > > >>=20 > > >> Extra overhead due to 4-byte header: 0.0016% > > >>=20 > > >> I think we can ignore this. > > >>=20 > > >>=20 > > >> Henrik > > >>=20 > > >>=20 > > >> > regards, > > >> > ryuji > > >> >=20 > > >> > On 2007/05/17, at 17:47, Henrik Levkowetz wrote: > > >> >=20 > > >> >> Folks, > > >> >> > > >> >> on 2007-05-17 07:12 Ahmad Muhanna said the following: > > >> >>> Hi Ryuji, > > >> >>> > > >> >>> If we agree that a new UDP port for GRE, beside the > > one for IPv4/ > > >> >>> IPv6, > > >> >>> is needed, then why do not we use a new UDP port to > > indicate the > > >> >>> presence of the TLV which then can be used to indicate > > the next > > >> >>> header > > >> >>> for many protocols including GRE and ESP. This way we > > >> save one UDP > > >> >>> port > > >> >>> if we want to support ESP as per Vijay's proposal. > > >> >> > > >> >> At least I am very far from agreeing on one additional > > assigned UDP > > >> >> port. The number of unassigned UDP port in the range > > that can be > > >> >> assigned by IANA (0 - 1023) is now down to 281, by my > > >> count, so this > > >> >> should be considered a scarce resource. > > >> >> > > >> >> I'm not even sure whether it makes sense to ask for a new > > >> port for > > >> >> DS-MIPv6 > > >> >> rather than multiplex over for instance the MIPv4 port, > > >> but I think > > >> >> we can > > >> >> at least ask the question. But asking for 2 ports,=20 > to carry 2=20 > > >> >> different kinds of DS-MIPv6 payloads, seems just wrong. > > >> >> > > >> >> > > >> >> Henrik > > >> >=20 > > >> >=20 > > >>=20 > > >>=20 > > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat May 19 02:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpI8m-0000C9-Ft; Sat, 19 May 2007 02:10:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpI8l-00008I-59; Sat, 19 May 2007 02:10:07 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpI8j-0003Xc-Gk; Sat, 19 May 2007 02:10:07 -0400 Received: from localhost ([127.0.0.1] ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.63) (envelope-from ) id 1HpI8d-000399-M8; Sat, 19 May 2007 08:09:59 +0200 Message-ID: <464E94B7.2060501@levkowetz.com> Date: Sat, 19 May 2007 08:09:59 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Re: [Mip6] The use of GRE References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Vijay.Devarapalli@AzaireNet.com, nemo@ietf.org, sgundave@cisco.com, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, on 2007-05-18 20:57 Vijay Devarapalli said the following: ... >> on 2007-05-18 03:02 Vijay Devarapalli said the following: >> > Isn't the 4 byte overhead on every data packet in the voice >> > stream? Not just the BU/BAck. >> >> Yes, of course. Quite right. Wrong time of day for me, I guess. >> >> So the correct data depends on packet size, but not on BU interval. >> For a 1280 total packet size, this means the overhead is 4/1276, >> or 0.3%. >> >> For a 16kbps voice stream, the payload size is 40 bytes, the IPv4 >> header is 20bytes, the first udp header 8, the IPv6 header 40, the >> second udp header is 8, and the rtp header is 12 bytes. Altogether >> 88 bytes header and 40 bytes payload, which gives the added overhead >> of 4 bytes and 4/128 = 3.1%. > > I would divide by 40, since we are calculating the overhead compared > to the actual payload, 4/40 = 10%. No. That sounds as if the packet size increases by 10%, which it doesn't. As Ahmad says, that's misleading. Then you might as well pick a 1-byte payload, and claim the figure 400%. That would also be misleading. Both figures are technically correct under certain premises, but not helpful in this context. The figures 3.1% and 0.3% are the increased bandwidth consumption of the link in question, for these traffic types, if we do nothing about compression or header reduction. And regarding that, it would be interesting if you would also comment on the last part of my message (left in place below). Henrik > Vijay > > >> This is more serious, but also shows that we should probably consider >> whether we can reduce/compress the whole set of headers, rather than >> focus on the demultiplexing-enabling 4 bytes. It might even be the >> case that having the demultiplexing-enabling 4 bytes gives us the >> freedom we need to define alternative tunnelling with less overhead. >> >> >> Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon May 21 11:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq9ZY-0006JX-NR; Mon, 21 May 2007 11:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq9ZT-0006Gh-1q for mip6@ietf.org; Mon, 21 May 2007 11:13:16 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq9ZR-0006YC-Ry for mip6@ietf.org; Mon, 21 May 2007 11:13:15 -0400 Received: by an-out-0708.google.com with SMTP id c34so475762anc for ; Mon, 21 May 2007 08:13:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ey9VB2c4NZbc5gQsWEZ1zSOeQ+62becClKYD16JRa9XNclsjWDipJVR155m4ub3wut+C6BvD99Z+DxHA9vgDZKTMkTxNdE3W5uuPodi8Nd/9/k6khqRy1VKHhczq7AIK19Gc22ndvRajZA1c2Bdzf6sTDZaamGWONU7uNiUN5HE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=tBDqkajbKctvXY9jw9XD/LxkcWOXuPusQEKC3gmhh9mJc7A6PSc1XfcGRlSx8lWNbZPVGu6GgqAtfsSUjvLrTwrjN8zEU8LAzK4kVfGiVUfU4WWrF6b9g+XleTwJbnZTZ7zlENSAHoSI0wEWLO4k61JdLEOCX36t+Q3p+6V/VzQ= Received: by 10.100.153.17 with SMTP id a17mr3037913ane.1179760392156; Mon, 21 May 2007 08:13:12 -0700 (PDT) Received: by 10.100.123.15 with HTTP; Mon, 21 May 2007 08:13:12 -0700 (PDT) Message-ID: <5e2406980705210813s3e356da5g9cf5b63edaadac77@mail.gmail.com> Date: Mon, 21 May 2007 17:13:12 +0200 From: "Julien Bournelle" To: mip6@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Mip6] Question regarding RFC 4285 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, I read RFC 4285 and I have some clarifications questions. From what I understood, if we use the MN-AAA Mobility Message Authentication option in the BU, the HA have to send a BA with a MN-HA Mobility Message Authentication option (see section 5.2). Does this mean that even with the use of the MN-AAA option, we assume that the MN and HA have a pre-shared key ? or that if we do not have a MN-HA key, the MN does not request a BA ? Thanks, Julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon May 21 11:43:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqA2E-0006hN-FR; Mon, 21 May 2007 11:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqA2B-0006hH-Nz for mip6@ietf.org; Mon, 21 May 2007 11:42:56 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqA2B-0003sK-Dp for mip6@ietf.org; Mon, 21 May 2007 11:42:55 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4LFgqx25313; Mon, 21 May 2007 15:42:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Question regarding RFC 4285 Date: Mon, 21 May 2007 10:42:42 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114669386@zrc2hxm2.corp.nortel.com> In-Reply-To: <5e2406980705210813s3e356da5g9cf5b63edaadac77@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Question regarding RFC 4285 Thread-Index: AcebuphlRpS9wz9pQNCJxl0RXCWmrAAA2HtA References: <5e2406980705210813s3e356da5g9cf5b63edaadac77@mail.gmail.com> From: "Ahmad Muhanna" To: "Julien Bournelle" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Julien, I believe the assumption here is that the MN has a secret key (i.e. MN-AAA SA) with its HAAA. However, it is also assumed that the MN will be able to derive a MN-HA session key based on the MN-AAA secret key. In other words, the MN and its HAAA would have a predefined mechanism to derive the MN-HA secret key based on the MN-AAA secret + some other session parameters, e.g. HA IP address, etc. In other words, the MN is always required to have a mechanism which allows the MN to validate the BA. Regards, Ahmad =20 > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com]=20 > Sent: Monday, May 21, 2007 10:13 AM > To: mip6@ietf.org > Subject: [Mip6] Question regarding RFC 4285 >=20 > Hi all, >=20 > I read RFC 4285 and I have some clarifications questions. >=20 > From what I understood, if we use the MN-AAA Mobility=20 > Message Authentication option in the BU, the HA have to send=20 > a BA with a MN-HA Mobility Message Authentication option (see=20 > section 5.2). >=20 > Does this mean that even with the use of the MN-AAA option,=20 > we assume that the MN and HA have a pre-shared key ? or that=20 > if we do not have a MN-HA key, the MN does not request a BA ? >=20 > Thanks, >=20 > Julien >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 22 00:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqMDg-0001WU-3c; Tue, 22 May 2007 00:43:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqMDe-0001WH-LE; Tue, 22 May 2007 00:43:34 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqMDd-0002jU-CX; Tue, 22 May 2007 00:43:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [nemo] Re: [Mip6] The use of GRE Date: Mon, 21 May 2007 21:43:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceZKD2JhEPojzyBQaiTYPefHyxdogAVdT2wAAypjwAAnrCvoA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> <6FC4416DDE56C44DA0AEE67BC7CA4371145D60D3@zrc2hxm2.corp.nortel.com> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ahmad, =20 > > > For a 16kbps voice stream, the payload size is 40 bytes, the IPv4=20 > > > header is 20bytes, the first udp header 8, the IPv6=20 > header 40, the=20 > > > second udp header is 8, and the rtp header is 12 bytes. =20 > Altogether > > > 88 bytes header and 40 bytes payload, which gives the added=20 > > overhead=20 > > > of 4 bytes and 4/128 =3D 3.1%. > >=20 > > I would divide by 40, since we are calculating the overhead=20 > > compared to the actual payload, 4/40 =3D 10%. >=20 > [Ahmad] > Dividing by 40, IMO, is called a misleading and statically biased > methodology. The wireless link does not know nor care what is payload > and what is not. The wireless link probably cares that a packet of a > length of 124 is now 128 after adding the TLV. I thought what=20 > Henrik was > trying to quantify is the impact on the wireless link bandwidth due to > the added 4 bytes TLV. I was looking at how much overhead we are adding in addition to the existing overhead. Not in comparison to the existing overhead. I hope you see the difference.=20 > On the other hand, let me say that this is almost the worst case > scenario, however, for example if FTP in the picture and let=20 > us assume a > packet length of 1300 bytes, then the impact is about 0.3%. Of course. For large packets, this is not an issue. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 22 00:50:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqMK8-0007IC-Pa; Tue, 22 May 2007 00:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqMK7-0007Ca-6n; Tue, 22 May 2007 00:50:15 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqMK5-0005dO-QT; Tue, 22 May 2007 00:50:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [nemo] Re: [Mip6] The use of GRE Date: Mon, 21 May 2007 21:50:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceZ3FhanKtMaQzBQWaBmBD9ekso5wCT6huQ References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> <464E94B7.2060501@levkowetz.com> From: "Vijay Devarapalli" To: "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nemo@ietf.org, mip6@ietf.org, Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Henrik, =20 > >> This is more serious, but also shows that we should probably = consider > >> whether we can reduce/compress the whole set of headers, rather = than > >> focus on the demultiplexing-enabling 4 bytes. It might even be the > >> case that having the demultiplexing-enabling 4 bytes gives us the > >> freedom we need to define alternative tunnelling with less = overhead. Yes, this is a good idea. I have come across an IPR'ed solution (not mine) in this space. It proposes to compress the inner=20 headers when you use IP-in-IP tunneling with Mobile IP (both v4 and v6). I don't have a reference to it now. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 22 02:08:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqNXW-0001i4-Ox; Tue, 22 May 2007 02:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqNXV-0001ec-V0 for mip6@ietf.org; Tue, 22 May 2007 02:08:09 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqNXT-0001HP-GW for mip6@ietf.org; Tue, 22 May 2007 02:08:09 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 08:08:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] The use of GRE Date: Tue, 22 May 2007 08:08:02 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301D815DB@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Re: [Mip6] The use of GRE thread-index: AceZ3FhanKtMaQzBQWaBmBD9ekso5wCT6huQAALNZ6A= References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com><464E94B7.2060501@levkowetz.com> From: To: , X-OriginalArrivalTime: 22 May 2007 06:08:05.0363 (UTC) FILETIME=[8FD5B430:01C79C37] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mip6@ietf.org, sgundave@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, DO you mean the draft-vaarala-mip4-optudp-00 type of solution? Cheers, Jouni > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com]=20 > Sent: Tuesday, May 22, 2007 7:50 AM > To: Henrik Levkowetz > Cc: nemo@ietf.org; mip6@ietf.org; Sri Gundavelli > Subject: RE: [nemo] Re: [Mip6] The use of GRE >=20 > Hi Henrik, > =20 > > >> This is more serious, but also shows that we should probably=20 > > >> consider whether we can reduce/compress the whole set of=20 > headers,=20 > > >> rather than focus on the demultiplexing-enabling 4=20 > bytes. It might=20 > > >> even be the case that having the demultiplexing-enabling 4 bytes=20 > > >> gives us the freedom we need to define alternative=20 > tunnelling with less overhead. >=20 > Yes, this is a good idea. I have come across an IPR'ed=20 > solution (not mine) in this space. It proposes to compress=20 > the inner headers when you use IP-in-IP tunneling with Mobile=20 > IP (both v4 and v6). I don't have a reference to it now. >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 23 12:13:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqtSR-0005Lw-Mm; Wed, 23 May 2007 12:13:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqtSQ-0005KY-1k for mip6@ietf.org; Wed, 23 May 2007 12:13:02 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqtSP-0004cr-E4 for mip6@ietf.org; Wed, 23 May 2007 12:13:02 -0400 Received: from rly13b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly13b.srv.mailcontrol.com (MailControl) with ESMTP id l4NGCrpt030448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 May 2007 17:12:57 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly13b.srv.mailcontrol.com (MailControl) id l4NGCDU8027216 for mip6@ietf.org; Wed, 23 May 2007 17:12:13 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly13b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l4NGC7wE026994; Wed, 23 May 2007 17:12:13 +0100 (BST) Received: from eundadmi02.pan.eu(10.100.96.65) by hhe500-02.hbg.de.pan.eu via smtp id 3e9e_58c9e5ac_0946_11dc_9441_0030482aac25; Wed, 23 May 2007 17:57:45 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi02.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007052316353118-36562 ; Wed, 23 May 2007 16:35:31 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.146,BAYES_00: -1.665,TOTAL_SCORE: -1.519 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 23 May 2007 16:35:17 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-mip6-hiopt-03.txt thread-index: AceX85nYT7/OAXZ2RuWYpVoeFPlbXgET6OMg References: To: "Heejin Jang" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB1C5B80@lan-ex-02.panasonic.de> Date: Wed, 23 May 2007 16:35:15 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-07-05 (www.mailcontrol.com) on 10.66.1.123 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: mip6@ietf.org Subject: [Mip6] RE: I-D ACTION:draft-ietf-mip6-hiopt-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Heejin, I quickly went through the new version of the hiopt draft. As announced at the last meeting and on the mailing list, the assignment of HAs from an MSP that is neither ASP nor MSA but has trust relationship with MN's MSA is now supported. This is good, since it improves deployment flexibility and applicability. However, I have some questions regarding the related text in the draft. The Home Network Identifier option currently has three id-types: 0 for "Visited domain/ASP", type 1 for "target network" and type 2 for "No preference". The id-type in combination with the Home Network Identifier field allow the MN to request a specific MSP. Section 3.1 says about the Home Network Identifier field: "...This field MUST be set to the network realm as the FQDN defined in [3] when the id-type is 1.". Later, the text says "The id-type 1 indicates the mobile node is interested in learning the home network information that pertains to the given realm. ... The target network can be a home MSP or a MSP which has trust roaming relationship with the mobile node's home MSP." Isn't this contradicting? How can the MN request the assignment of an MSP different from the MSA, when the Home Network Identifier field must be set to the realm of the MN's NAI (The realm of the MN's NAI typically pertains to the MSA)? Or does the "network realm" in the cited sentence refer to something else than the MN's NAI? Another comment relates to the text about id-type 2. It is not clear to me whether id-type 2 can be used by the MN to request the assignment of an MSP that is neither ASP nor MSA. Section 4.3, case C says: "In this case, the assignment of the home information relies on the server's local policy, and the DHCP server SHOULD have its own policy so that it can reply with the proper information. " ... "When the DHCP server provides the home information that is retrieved from the MIP6 Relay Agent option, it MUST compare the NAI's realm information of MN-NAI option with the target network in Home Network Identifier option. If they match, the DHCP server replies with the Reply message after copying the home information in MIP6 Relay Agent option to Home Network Information option. In case the server cannot find any home information for the requested id-type, it MUST return a Home Network Information option with the 0-length data." What should the DHCP server do if the MIP6 relay agent option contains multiple sub-options and one of the sub-options matches the NAI's realm whereas another one does not? This situation can happen if the AAAH sends home network information for mutliple MSPs to the NAS (e.g., for home MSP/MSA and other MSPs with trust relationship to MSA). Should the server respond with multiple Home Network Information Sub-options? And why do we need this MN-NAI option check here at all? Thanks, Kilian > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Mittwoch, 16. Mai 2007 21:50 > To: i-d-announce@ietf.org > Cc: mip6@ietf.org > Subject: I-D ACTION:draft-ietf-mip6-hiopt-03.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Mobility for IPv6 Working=20 > Group of the IETF. >=20 > Title : DHCP Option for Home Information=20 > Discovery in MIPv6 > Author(s) : H. Jang, et al. > Filename : draft-ietf-mip6-hiopt-03.txt > Pages : 19 > Date : 2007-5-16 > =09 > This draft defines a DHCP-based scheme to enable dynamic discovery of > Mobile IPv6 home agent address, home agent FQDN and home=20 > subnet. New > DHCP options are defined to carry the information from a=20 > DHCP server > to the DHCP client running on the mobile node. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-03.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-mip6-hiopt-03.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip6-hiopt-03.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 23 22:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr2wD-0002BC-D7; Wed, 23 May 2007 22:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr2wC-0002Ax-1D for mip6@ietf.org; Wed, 23 May 2007 22:20:24 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr2wB-00020N-0R for mip6@ietf.org; Wed, 23 May 2007 22:20:24 -0400 Received: by py-out-1112.google.com with SMTP id u52so740118pyb for ; Wed, 23 May 2007 19:20:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=nfGwZxbguwdGumzN4UfEAuLrHEd0SUg1igdtg17VVCApoGONZ8wjV4mlaPmsgE6VGBjfzv79QfYvfm3bgaL4cfcOSF6wPzvYfDogjPxY8HW3Sb8bEvQdkVaU6IdA+Ln3CYAE0DxjNpvNbg+JEALi+H5CbQF2BgsLCnaQEaz2mW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=eN3moBZfjXRFbpFBgNPTa/mfhfGLCmV6v/l68bBve/uGiE8sdC91cxmQ8vnnOKsanxw7k9NaZQrhPXaSRTIbPxlFAMiwuzBEfIquuhkV6XM/o9k/jquyV1PGZE/1gYkZHaAiZA0bDcXcGBk1uaG6ILbW9Y0wWkEKu6v/zN4I9Is= Received: by 10.35.41.8 with SMTP id t8mr2296007pyj.1179973221166; Wed, 23 May 2007 19:20:21 -0700 (PDT) Received: from ?203.178.143.190? ( [203.178.143.190]) by mx.google.com with ESMTP id n29sm3470189pyh.2007.05.23.19.20.17; Wed, 23 May 2007 19:20:19 -0700 (PDT) In-Reply-To: <464E94B7.2060501@levkowetz.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43711451A478@zrc2hxm2.corp.nortel.com><464C1692.10907@levkowetz.com><750380BC-7CFD-4ACF-AE9F-15B80000FAF8@gmail.com> <464C891C.9010407@levkowetz.com> <464D668E.5090000@levkowetz.com> <464E94B7.2060501@levkowetz.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <627BD674-CAF4-4F0A-8FA1-157EA9B8541D@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [nemo] Re: [Mip6] The use of GRE Date: Thu, 24 May 2007 11:20:13 +0900 To: Henrik Levkowetz X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nemo@ietf.org, mip6@ietf.org, Vijay Devarapalli , Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Henrik, sorry for my silence. Thanks for good analysis. In wireless, we should also consider the number of mobile nodes attached to the same access point. I just prefer decreasing the header parts from the packet as much as possible. As you show the example of VoIP, the header part is already two times bigger than the payload. BTW, I agree that some kind of header compression may be worth to apply here. regards, ryuji On 2007/05/19, at 15:09, Henrik Levkowetz wrote: > Hi Vijay, > > on 2007-05-18 20:57 Vijay Devarapalli said the following: > ... >>> on 2007-05-18 03:02 Vijay Devarapalli said the following: >>>> Isn't the 4 byte overhead on every data packet in the voice >>>> stream? Not just the BU/BAck. >>> >>> Yes, of course. Quite right. Wrong time of day for me, I guess. >>> >>> So the correct data depends on packet size, but not on BU interval. >>> For a 1280 total packet size, this means the overhead is 4/1276, >>> or 0.3%. >>> >>> For a 16kbps voice stream, the payload size is 40 bytes, the IPv4 >>> header is 20bytes, the first udp header 8, the IPv6 header 40, the >>> second udp header is 8, and the rtp header is 12 bytes. Altogether >>> 88 bytes header and 40 bytes payload, which gives the added overhead >>> of 4 bytes and 4/128 = 3.1%. >> >> I would divide by 40, since we are calculating the overhead compared >> to the actual payload, 4/40 = 10%. > > No. That sounds as if the packet size increases by 10%, which it > doesn't. As Ahmad says, that's misleading. Then you might as well > pick a 1-byte payload, and claim the figure 400%. That would also > be misleading. Both figures are technically correct under certain > premises, but not helpful in this context. > > The figures 3.1% and 0.3% are the increased bandwidth consumption of > the link in question, for these traffic types, if we do nothing about > compression or header reduction. > > And regarding that, it would be interesting if you would also comment > on the last part of my message (left in place below). > > > Henrik > >> Vijay >> >> >>> This is more serious, but also shows that we should probably >>> consider >>> whether we can reduce/compress the whole set of headers, rather than >>> focus on the demultiplexing-enabling 4 bytes. It might even be the >>> case that having the demultiplexing-enabling 4 bytes gives us the >>> freedom we need to define alternative tunnelling with less overhead. >>> >>> >>> Henrik > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri May 25 17:19:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrhCV-0007JU-Fh; Fri, 25 May 2007 17:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrhCS-000785-Uu; Fri, 25 May 2007 17:19:52 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrhCP-0007FF-Sb; Fri, 25 May 2007 17:19:52 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l4PLJnSO013282; Fri, 25 May 2007 14:19:49 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l4PLJn2s013281; Fri, 25 May 2007 14:19:49 -0700 Date: Fri, 25 May 2007 14:19:49 -0700 Message-Id: <200705252119.l4PLJn2s013281@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mip6@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip6] RFC 4882 on IP Address Location Privacy and Mobile IPv6: Problem Statement X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4882 Title: IP Address Location Privacy and Mobile IPv6: Problem Statement Author: R. Koodli Status: Informational Date: May 2007 Mailbox: rajeev.koodli@nokia.com Pages: 11 Characters: 24987 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip6-location-privacy-ps-06.txt URL: http://www.rfc-editor.org/rfc/rfc4882.txt In this document, we discuss location privacy as applicable to Mobile IPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent. This memo provides information for the Internet community. This document is a product of the Mobility for IPv6 Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun May 27 04:26:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsE5Q-0007NR-MX; Sun, 27 May 2007 04:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsE5P-0007NL-60 for mip6@ietf.org; Sun, 27 May 2007 04:26:47 -0400 Received: from static-ip-163-194-65-202.rev.dyxnet.com ([202.65.194.163] helo=hitachihk6.hitachi.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsE5M-0004n2-Dk for mip6@ietf.org; Sun, 27 May 2007 04:26:47 -0400 Received: (qmail 26140 invoked from network); 27 May 2007 08:26:39 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk6;a380bd8ba6891ee1ebb9168ab8fa3fcb; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1) by static-ip-163-194-65-202.rev.dyxnet.com with SMTP; 27 May 2007 08:26:39 -0000 Received: (qmail 26426 invoked from network); 27 May 2007 08:26:39 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;428e0218d66c2d3bef8f2929e67f42f7; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6) by 172.16.10.9 with SMTP; 27 May 2007 08:26:39 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 16:26:12 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Sun, 27 May 2007 16:26:10 +0800 Message-ID: <8386EDF347730C46BA47710F87AE1FE902170F@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: fw: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcegOKnzxTvKI8ooSfiJx96YRwKqAg== From: "DENG, HUI -HCHBJ" To: X-OriginalArrivalTime: 27 May 2007 08:26:12.0452 (UTC) FILETIME=[AF63E240:01C7A038] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1180254399.195-26422-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.01/0.06 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk6: Virus scan performed by network-box X-Scanned-By-hitachihk6: Scanner file id is hitachihk6-1180254399.441-26133-000 X-Scanned-By-hitachihk6: No known viruses found in message (received+scanned in 0.02/0.03 secs) X-Scanned-By-hitachihk6: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk6: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Mip6] fw: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Dear Authors, I have one simple question about this draft, In the figure 1 and 2, why this message start from bit 0 other than 16? Thanks -Hui Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon May 28 01:49:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsY6w-0008Ge-Ig; Mon, 28 May 2007 01:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsY6v-0008GS-64 for mip6@ietf.org; Mon, 28 May 2007 01:49:41 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsY6u-0003D3-Cf for mip6@ietf.org; Mon, 28 May 2007 01:49:41 -0400 Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JIQ0010NLHUXT@mailout2.samsung.com> for mip6@ietf.org; Mon, 28 May 2007 14:49:06 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JIQ00DL0LHUFP@ms5.samsung.com> for mip6@ietf.org; Mon, 28 May 2007 14:49:06 +0900 (KST) Content-return: prohibited Date: Mon, 28 May 2007 05:49:06 +0000 (GMT) From: Heejin Jang To: Kilian Weniger , heejin.jang@samsung.com Message-id: <15094382.676771180331346151.JavaMail.weblogic@ep_ml19> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070528054906149@heejin.jang X-MTR: 20070528054906149@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Spam-Score: 2.1 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: "mip6@ietf.org" Subject: [Mip6] Re: RE: I-D ACTION:draft-ietf-mip6-hiopt-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1047290005==" Errors-To: mip6-bounces@ietf.org --===============1047290005== Content-return: prohibited Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGksIEtpbGlhbi4NCiANClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NClNlZSB0aGUgaW5saW5l LiANCiANClJlZ2FyZHMsIA0KSGVlamluLg0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEtpbGlhbiBXZW5pZ2VyIFttYWlsdG86S2lsaWFuLldlbmlnZXJAZXUucGFuYXNvbmlj LmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE1heSAyMywgMjAwNyAxMTozNSBQTQ0KVG86IEhlZWpp biBKYW5nDQpDYzogbWlwNkBpZXRmLm9yZw0KU3ViamVjdDogUkU6IEktRCBBQ1RJT046ZHJhZnQt aWV0Zi1taXA2LWhpb3B0LTAzLnR4dA0KIA0KSGkgSGVlamluLA0KIA0KSSBxdWlja2x5IHdlbnQg dGhyb3VnaCB0aGUgbmV3IHZlcnNpb24gb2YgdGhlIGhpb3B0IGRyYWZ0LiBBcyBhbm5vdW5jZWQg YXQgdGhlIGxhc3QgbWVldGluZyBhbmQgb24gdGhlIG1haWxpbmcgbGlzdCwgdGhlIGFzc2lnbm1l bnQgb2YgSEFzIGZyb20gYW4gTVNQIHRoYXQgaXMgbmVpdGhlciBBU1Agbm9yIE1TQSBidXQgaGFz IHRydXN0IHJlbGF0aW9uc2hpcCB3aXRoIE1OJ3MgTVNBIGlzIG5vdyBzdXBwb3J0ZWQuIFRoaXMg aXMgZ29vZCwgc2luY2UgaXQgaW1wcm92ZXMgZGVwbG95bWVudCBmbGV4aWJpbGl0eSBhbmQgYXBw bGljYWJpbGl0eS4gSG93ZXZlciwgSSBoYXZlIHNvbWUgcXVlc3Rpb25zIHJlZ2FyZGluZyB0aGUg cmVsYXRlZCB0ZXh0IGluIHRoZSBkcmFmdC4NCiANClRoZSBIb21lIE5ldHdvcmsgSWRlbnRpZmll ciBvcHRpb24gY3VycmVudGx5IGhhcyB0aHJlZSBpZC10eXBlczogMCBmb3IgIlZpc2l0ZWQgZG9t YWluL0FTUCIsIHR5cGUgMSBmb3IgInRhcmdldCBuZXR3b3JrIiBhbmQgdHlwZSAyIGZvciAiTm8g cHJlZmVyZW5jZSIuIFRoZSBpZC10eXBlIGluIGNvbWJpbmF0aW9uIHdpdGggdGhlIEhvbWUgTmV0 d29yayBJZGVudGlmaWVyIGZpZWxkIGFsbG93IHRoZSBNTiB0byByZXF1ZXN0IGEgc3BlY2lmaWMg TVNQLg0KIA0KSGVlamluPiBSaWdodC4gV2UgY2xhcmlmaWVkIHRoaXMgcG9pbnQgaW4gdGhlIGRy YWZ0Lg0KIA0KU2VjdGlvbiAzLjEgc2F5cyBhYm91dCB0aGUgSG9tZSBOZXR3b3JrIElkZW50aWZp ZXIgZmllbGQ6ICIuLi5UaGlzIGZpZWxkIE1VU1QgYmUgc2V0IHRvIHRoZSBuZXR3b3JrIHJlYWxt IGFzIHRoZSBGUUROIGRlZmluZWQgaW4gWzNdIHdoZW4gdGhlIGlkLXR5cGUgaXMgMS4iLiBMYXRl ciwgdGhlIHRleHQgc2F5cyAiVGhlIGlkLXR5cGUgMSBpbmRpY2F0ZXMgdGhlIG1vYmlsZSBub2Rl IGlzIGludGVyZXN0ZWQgaW4gbGVhcm5pbmcgdGhlIGhvbWUgbmV0d29yayBpbmZvcm1hdGlvbiB0 aGF0IHBlcnRhaW5zIHRvIHRoZSBnaXZlbiByZWFsbS4gLi4uIFRoZSB0YXJnZXQgbmV0d29yayBj YW4gYmUgYSBob21lIE1TUCBvciBhIE1TUCB3aGljaCBoYXMgdHJ1c3Qgcm9hbWluZyByZWxhdGlv bnNoaXAgd2l0aCB0aGUgbW9iaWxlIG5vZGUncyBob21lIE1TUC4iIElzbid0IHRoaXMgY29udHJh ZGljdGluZz8gSG93IGNhbiB0aGUgTU4gcmVxdWVzdCB0aGUgYXNzaWdubWVudCBvZiBhbiBNU1Ag ZGlmZmVyZW50IGZyb20gdGhlIE1TQSwgd2hlbiB0aGUgSG9tZSBOZXR3b3JrIElkZW50aWZpZXIg ZmllbGQgbXVzdCBiZSBzZXQgdG8gdGhlIHJlYWxtIG9mIHRoZSBNTidzIE5BSSAoVGhlIHJlYWxt IG9mIHRoZSBNTidzIE5BSSB0eXBpY2FsbHkgcGVydGFpbnMgdG8gdGhlIE1TQSk/IE9yIGRvZXMg dGhlICJuZXR3b3JrIHJlYWxtIiBpbiB0aGUgY2l0ZWQgc2VudGVuY2UgcmVmZXIgdG8gc29tZXRo aW5nIGVsc2UgdGhhbiB0aGUgTU4ncyBOQUk/DQogDQpIZWVqaW4+IFRoZSAibmV0d29yayByZWFs bSIgaW4gdGhpcyBjb250ZXh0IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBNTidzIE5BSS4gSXQgaXMg YSB0YXJnZXQgbmV0d29yaw0KIHdoaWNoIGlzIGhvbWUgTVNQIG9yIGEgTVNQIHdoaWNoIGhhcyB0 cnVzdCByb2FtaW5nIHJlbGF0aW9uc2hpcCB3aXRoIE1OJ3MgaG9tZSBNU1AuIFdlJ2xsIA0KZGVs ZXRlIHRoZSBmb2xsb3dpbmcgcGhhcmFncmFwIHRoYXQgbWF5IGNhdXNlIGNvbmZ1c2lvbiBpbiBz ZWN0aW9uIDMuMS4gDQoiVGhpcyB0eXBlIGNhbiBiZSB1c2VkIHRvIGRpc2NvdmVyIGhvbWUgYWdl bnRzIHRoYXQgYXJlIGhvc3RlZCBieSBhIHVzZXIncyBob21lIGRvbWFpbg0KKGFzIGluZGljYXRl ZCBieSBoaXMvaGVyIE5BSS1iYXNlZCB1c2VybmFtZSAtLSB1c2VyQCBIb21lUmVhbG0pLiINCiAN CkFub3RoZXIgY29tbWVudCByZWxhdGVzIHRvIHRoZSB0ZXh0IGFib3V0IGlkLXR5cGUgMi4gSXQg aXMgbm90IGNsZWFyIHRvIG1lIHdoZXRoZXIgaWQtdHlwZSAyIGNhbiBiZSB1c2VkIGJ5IHRoZSBN TiB0byByZXF1ZXN0IHRoZSBhc3NpZ25tZW50IG9mIGFuIE1TUCB0aGF0IGlzIG5laXRoZXIgQVNQ IG5vciBNU0EuIFNlY3Rpb24gNC4zLCBjYXNlIEMgc2F5czoNCiANCiAgIkluIHRoaXMgY2FzZSwg dGhlIGFzc2lnbm1lbnQgb2YgdGhlIGhvbWUgaW5mb3JtYXRpb24gcmVsaWVzIG9uIHRoZQ0KICAg c2VydmVyJ3MgbG9jYWwgcG9saWN5LCBhbmQgdGhlIERIQ1Agc2VydmVyIFNIT1VMRCBoYXZlIGl0 cyBvd24gcG9saWN5DQogICBzbyB0aGF0IGl0IGNhbiByZXBseSB3aXRoIHRoZSBwcm9wZXIgaW5m b3JtYXRpb24uICAiDQouLi4NCiAgICJXaGVuIHRoZSBESENQIHNlcnZlciBwcm92aWRlcyB0aGUg aG9tZSBpbmZvcm1hdGlvbiB0aGF0IGlzIHJldHJpZXZlZA0KICAgZnJvbSB0aGUgTUlQNiBSZWxh eSBBZ2VudCBvcHRpb24sIGl0IE1VU1QgY29tcGFyZSB0aGUgTkFJJ3MgcmVhbG0NCiAgIGluZm9y bWF0aW9uIG9mIE1OLU5BSSBvcHRpb24gd2l0aCB0aGUgdGFyZ2V0IG5ldHdvcmsgaW4gSG9tZSBO ZXR3b3JrDQogICBJZGVudGlmaWVyIG9wdGlvbi4gIElmIHRoZXkgbWF0Y2gsIHRoZSBESENQIHNl cnZlciByZXBsaWVzIHdpdGggdGhlDQogICBSZXBseSBtZXNzYWdlIGFmdGVyIGNvcHlpbmcgdGhl IGhvbWUgaW5mb3JtYXRpb24gaW4gTUlQNiBSZWxheSBBZ2VudA0KICAgb3B0aW9uIHRvIEhvbWUg TmV0d29yayBJbmZvcm1hdGlvbiBvcHRpb24uDQogDQogICBJbiBjYXNlIHRoZSBzZXJ2ZXIgY2Fu bm90IGZpbmQgYW55IGhvbWUgaW5mb3JtYXRpb24gZm9yIHRoZSByZXF1ZXN0ZWQNCiAgIGlkLXR5 cGUsIGl0IE1VU1QgcmV0dXJuIGEgSG9tZSBOZXR3b3JrIEluZm9ybWF0aW9uIG9wdGlvbiB3aXRo IHRoZQ0KICAgMC1sZW5ndGggZGF0YS4iDQogDQpXaGF0IHNob3VsZCB0aGUgREhDUCBzZXJ2ZXIg ZG8gaWYgdGhlIE1JUDYgcmVsYXkgYWdlbnQgb3B0aW9uIGNvbnRhaW5zIG11bHRpcGxlIHN1Yi1v cHRpb25zIGFuZCBvbmUgb2YgdGhlIHN1Yi1vcHRpb25zIG1hdGNoZXMgdGhlIE5BSSdzIHJlYWxt IHdoZXJlYXMgYW5vdGhlciBvbmUgZG9lcyBub3Q/IFRoaXMgc2l0dWF0aW9uIGNhbiBoYXBwZW4g aWYgdGhlIEFBQUggc2VuZHMgaG9tZSBuZXR3b3JrIGluZm9ybWF0aW9uIGZvciBtdXRsaXBsZSBN U1BzIHRvIHRoZSBOQVMgKGUuZy4sIGZvciBob21lIE1TUC9NU0EgYW5kIG90aGVyIE1TUHMgd2l0 aCB0cnVzdCByZWxhdGlvbnNoaXAgdG8gTVNBKS4gU2hvdWxkIHRoZSBzZXJ2ZXIgcmVzcG9uZCB3 aXRoIG11bHRpcGxlIEhvbWUgTmV0d29yayBJbmZvcm1hdGlvbiBTdWItb3B0aW9ucz8NCiANCkhl ZWppbj4gQSBESENQIHNlcnZlciBleHRyYWN0cyBvbmx5IHRoZSBhdmFpbGFibGUgSEEgaW5mbyBh bW9uZyB0aGUgaW5mbyBwcml2aWRlZCBieSBOQVMgKGZpbmFsbHkgZnJvbSBBQUEpDQphbmQgaW5j bHVkZXMgdGhlbSBpbiBhIHNpbmdsZSBIb21lIE5ldHdvcmsgaW5mb3JtYXRpb24gb3B0aW9uIHdp dGggbXVsdGlwbGUgc3ViLW9wdGlvbnMuIElmIHRoZSBzZXJ2ZXIgaGFzIG5vIA0KaW5mbyBmb3Ig dGhlIHNwZWNpZmllZCBpZC10eXBlIGluIEhvbWUgTmV0d29yaywgdGhlbiBpdCByZXBsaWVzIHdp dGggb3B0LWxlbj0wIGluIGEgSG9tZSBOZXR3b3JrIEluZm9ybWF0aW9uIG9wdGlvbi4NCiANCkFu ZCB3aHkgZG8gd2UgbmVlZCB0aGlzIE1OLU5BSSBvcHRpb24gY2hlY2sgaGVyZSBhdCBhbGw/DQoN CkhlZWppbj4gSW4gY2FzZSBhIEFBQSBzZXJ2ZXIgcHJvdmlkZWQgb25seSBIQSdzIElQIGFkZHJl c3MgKG5vdCBGUUROKSB0byBOQVMgKGZpbmFsbHkgdG8gdGhlIERIQ1Agc2VydmVyKSwgDQp0aGVy ZSBpcyBubyB3YXkgdG8gZGVjaWRlZCB3aGV0aGVyIGl0IGlzIHRoZSBIQSBpbmZvIHdoaWNoIHRo ZSBNTiByZXF1ZXN0ZWQgd2l0aCBGUUROLiBCdXQgd2UnbGwgc2ltcGxpZnkgDQp0aGlzIGJ5IGFs bG93aW5nIHRoZSBESENQIHNlcnZlciB0byBwcm92aWRlIG9ubHkgSEEgaW5mbyB3aGljaCBjYW4g YmUgbWFwcGFibGUgYmFzZWQgb24gRlFETi4gDQooYW5kIHdlJ2xsIGRlbGV0ZSBOQUktYmFzZWQg bWFwcGluZyBwcm9jZWR1cmUuKQ0KIA0KVGhhbmtzLA0KIA0KS2lsaWFuDQogDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEludGVybmV0LURyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOkludGVybmV0LURyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogTWl0dHdvY2gsIDE2LiBNYWkg MjAwNyAyMTo1MA0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBtaXA2QGlldGYu b3JnDQo+IFN1YmplY3Q6IEktRCBBQ1RJT046ZHJhZnQtaWV0Zi1taXA2LWhpb3B0LTAzLnR4dA0K PiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIA0KPiBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgTW9iaWxpdHkgZm9yIElQdjYgV29ya2luZyBHcm91cCBvZiANCj4gdGhlIElF VEYuDQo+IA0KPiAgIFRpdGxlICAgICAgIDogREhDUCBPcHRpb24gZm9yIEhvbWUgSW5mb3JtYXRp b24gDQo+IERpc2NvdmVyeSBpbiBNSVB2Ng0KPiAgIEF1dGhvcihzKSAgIDogSC4gSmFuZywgZXQg YWwuDQo+ICAgRmlsZW5hbWUgICAgOiBkcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDMudHh0DQo+ICAg UGFnZXMgICAgICAgOiAxOQ0KPiAgIERhdGUgICAgICAgIDogMjAwNy01LTE2DQo+ICAgDQo+IFRo aXMgZHJhZnQgZGVmaW5lcyBhIERIQ1AtYmFzZWQgc2NoZW1lIHRvIGVuYWJsZSBkeW5hbWljIGRp c2NvdmVyeSBvZg0KPiAgICBNb2JpbGUgSVB2NiBob21lIGFnZW50IGFkZHJlc3MsIGhvbWUgYWdl bnQgRlFETiBhbmQgaG9tZSBzdWJuZXQuICANCj4gTmV3DQo+ICAgIERIQ1Agb3B0aW9ucyBhcmUg ZGVmaW5lZCB0byBjYXJyeSB0aGUgaW5mb3JtYXRpb24gZnJvbSBhIERIQ1AgDQo+IHNlcnZlcg0K PiAgICB0byB0aGUgREhDUCBjbGllbnQgcnVubmluZyBvbiB0aGUgbW9iaWxlIG5vZGUuDQo+IA0K PiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1taXA2LWhpb3B0LTAzLnR4dA0KPiANCj4gVG8g cmVtb3ZlIHlvdXJzZWxmIGZyb20gdGhlIEktRCBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhIG1l c3NhZ2UgdG8gDQo+IGktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnIHdpdGggdGhlIHdvcmQg dW5zdWJzY3JpYmUgaW4gdGhlIGJvZHkgb2YgDQo+IHRoZSBtZXNzYWdlLg0KPiBZb3UgY2FuIGFs c28gdmlzaXQNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vSS1ELWFu bm91bmNlDQo+IHRvIGNoYW5nZSB5b3VyIHN1YnNjcmlwdGlvbiBzZXR0aW5ncy4NCj4gDQo+IElu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUC4gTG9naW4g d2l0aCB0aGUgDQo+IHVzZXJuYW1lICJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIg ZS1tYWlsIGFkZHJlc3MuIEFmdGVyIA0KPiBsb2dnaW5nIGluLCB0eXBlICJjZCBpbnRlcm5ldC1k cmFmdHMiIGFuZCB0aGVuICJnZXQgDQo+IGRyYWZ0LWlldGYtbWlwNi1oaW9wdC0wMy50eHQiLg0K PiANCj4gQSBsaXN0IG9mIEludGVybmV0LURyYWZ0cyBkaXJlY3RvcmllcyBjYW4gYmUgZm91bmQg aW4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IgDQo+IGZ0cDovL2Z0cC5p ZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgY2Fu IGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWlsLg0KPiANCj4gU2VuZCBhIG1lc3NhZ2UgdG86DQo+ ICAgbWFpbHNlcnZAaWV0Zi5vcmcuDQo+IEluIHRoZSBib2R5IHR5cGU6DQo+ICAgIkZJTEUgL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1pcDYtaGlvcHQtMDMudHh0Ii4NCj4gICANCj4gTk9U RTogVGhlIG1haWwgc2VydmVyIGF0IGlldGYub3JnIGNhbiByZXR1cm4gdGhlIGRvY3VtZW50IGlu DQo+ICAgTUlNRS1lbmNvZGVkIGZvcm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRv IHVzZSB0aGlzDQo+ICAgZmVhdHVyZSwgaW5zZXJ0IHRoZSBjb21tYW5kICJFTkNPRElORyBtaW1l IiBiZWZvcmUgdGhlICJGSUxFIg0KPiAgIGNvbW1hbmQuICBUbyBkZWNvZGUgdGhlIHJlc3BvbnNl KHMpLCB5b3Ugd2lsbCBuZWVkICJtdW5wYWNrIiBvcg0KPiAgIGEgTUlNRS1jb21wbGlhbnQgbWFp bCByZWFkZXIuICBEaWZmZXJlbnQgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXJzDQo+ICAgZXho aWJpdCBkaWZmZXJlbnQgYmVoYXZpb3IsIGVzcGVjaWFsbHkgd2hlbiBkZWFsaW5nIHdpdGgNCj4g ICAibXVsdGlwYXJ0IiBNSU1FIG1lc3NhZ2VzIChpLmUuIGRvY3VtZW50cyB3aGljaCBoYXZlIGJl ZW4gc3BsaXQNCj4gICB1cCBpbnRvIG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91ciBs b2NhbCBkb2N1bWVudGF0aW9uIG9uDQo+ICAgaG93IHRvIG1hbmlwdWxhdGUgdGhlc2UgbWVzc2Fn ZXMuDQo+IA0KPiBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29t cGxpYW50IG1haWwgcmVhZGVyIA0KPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJl dHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZSANCj4gSW50ZXJuZXQtRHJhZnQuDQo+IA0K IA0KIA0KUGFuYXNvbmljIFImRCBDZW50ZXIgR2VybWFueSBHbWJIDQo2MzIyNSBMYW5nZW4sIEhl c3NlbiwgR2VybWFueQ0KUmVnOiBBRyBPZmZlbmJhY2ggKEhlc3NlbikgSFJCIDMzOTc0DQpNYW5h Z2luZyBEaXJlY3RvcjogVGhvbWFzIE1pY2tlDQogDQogDQogDQog --===============1047290005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1047290005==-- From mip6-bounces@ietf.org Mon May 28 08:44:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HseZm-0007oL-K7; Mon, 28 May 2007 08:43:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HseZl-0007oG-MD for mip6@ietf.org; Mon, 28 May 2007 08:43:53 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HseZk-0004Y4-A4 for mip6@ietf.org; Mon, 28 May 2007 08:43:53 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4SCgjS16284; Mon, 28 May 2007 12:42:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7A125.D6666038" Date: Mon, 28 May 2007 07:43:44 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnw From: "Ahmad Muhanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A125.D6666038 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello Folks, We submitted this draft for Binding Revocation for IPv6 Mobility. It handles several use cases which are applicable to Client Mobile IPv6 and PMIPv6. Please take a look and we appreciate your comments. Thanks in advance. Regards, Ahmad Muhanna -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Friday, May 25, 2007 2:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mip6-binding-revocation-00.txt Pages : 18 Date : 2007-5-25 =09 The service binding revocation semantics are missing in Mobile IPv6 Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document defines the semantics of the revocation of a mobile node registration binding, which could have been established using a Client Mobile IPv6 or a Proxy Mobile IPv6 signaling. The proposed revocation mechanism uses generic message properties which is applicable to Mobile IPv6 and Proxy Mobile IPv6 and can be used by any two mobility entities. As an example, this mechanism allows local mobility agent, involved in providing IP mobility services to a mobile node, to notify the mobility access gateway of the termination of the mobile node registration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio n-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-muhanna-mip6-binding-revocation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C7A125.D6666038 Content-Type: application/octet-stream; name="ATT1436203.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT1436203.TXT Content-Disposition: attachment; filename="ATT1436203.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy01LTI1MTAzNzUzLkktREBpZXRmLm9yZz4NCg0KRU5D T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW11aGFubmEtbWlwNi1iaW5k aW5nLXJldm9jYXRpb24tMDAudHh0DQo= ------_=_NextPart_001_01C7A125.D6666038 Content-Type: application/octet-stream; name="draft-muhanna-mip6-binding-revocation-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-muhanna-mip6-binding-revocation-00.URL Content-Disposition: attachment; filename="draft-muhanna-mip6-binding-revocation-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tdWhhbm5hLW1pcDYtYmluZGluZy1yZXZvY2F0aW9uLTAwLnR4dA0K ------_=_NextPart_001_01C7A125.D6666038 Content-Type: text/plain; name="ATT1436204.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1436204.txt Content-Disposition: attachment; filename="ATT1436204.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C7A125.D6666038 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ------_=_NextPart_001_01C7A125.D6666038-- From mip6-bounces@ietf.org Tue May 29 13:28:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5UX-0006TR-DH; Tue, 29 May 2007 13:28:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5UV-0006TE-Hg for mip6@ietf.org; Tue, 29 May 2007 13:28:15 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ht5UU-0006AC-5P for mip6@ietf.org; Tue, 29 May 2007 13:28:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4THSAR14219; Tue, 29 May 2007 17:28:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] fw: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Tue, 29 May 2007 12:28:08 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114903B55@zrc2hxm2.corp.nortel.com> In-Reply-To: <8386EDF347730C46BA47710F87AE1FE902170F@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] fw: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcegOKnzxTvKI8ooSfiJx96YRwKqAgA9lx0A References: <8386EDF347730C46BA47710F87AE1FE902170F@hcbjdc2> From: "Ahmad Muhanna" To: "DENG, HUI -HCHBJ" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hui, Thanks a lot, that is a good catch. I actually do not know how this slipped. I went back to my record of earlier internal versions of the draft which actually reflect what you exactly just pointed out. Since this is an error, we already posted a new revision of the draft with the changes captured below: BRI: Figure 1 should have looked like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|A|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Binding Revocation Indication Message BRA: Figure 2 should have looked like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Binding Revocation Acknowledgement Message Regards, Ahmad =20 > -----Original Message----- > From: DENG, HUI -HCHBJ [mailto:hdeng@hitachi.cn]=20 > Sent: Sunday, May 27, 2007 3:26 AM > To: mip6@ietf.org > Subject: [Mip6] fw: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 > Dear Authors, >=20 > I have one simple question about this draft, In the figure 1=20 > and 2, why this message start from bit 0 other than 16? >=20 > Thanks >=20 > -Hui >=20 >=20 > Disclaimer: > The contents of this e-mail, and its attachments, if any, are=20 > confidential and may be protected by law against any=20 > unauthorized use. If you have received this e-mail by=20 > mistake or have reason to believe that you are not the=20 > intended recipient, please notify the sender by reply e-mail=20 > as soon as possible and delete it from your computer system=20 > immediately thereafter. > If you are not the intended recipient, you must not copy this=20 > e-mail or attachment or disclose the contents to any other=20 > person. While we have made every effort to keep our network=20 > virus free, we take no responsibility for any computer virus=20 > which might be transferred by way of this e-mail. >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue May 29 15:50:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7ho-0000Z6-Vt; Tue, 29 May 2007 15:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7hi-0000XK-HY; Tue, 29 May 2007 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht7hi-0006he-7c; Tue, 29 May 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 26CD526E7A; Tue, 29 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ht7hi-0007M2-1V; Tue, 29 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 29 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 bootstrapping in split scenario Author(s) : G. Giaretta, et al. Filename : draft-ietf-mip6-bootstrapping-split-05.txt Pages : 30 Date : 2007-5-29 A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials preconfigured on the Mobile Node. The solution defined in this document solves the Mobile IPv6 bootstrapping problem (RFC4640) when the Mobile Node's mobility service is authorized by a different service provider than basic network access, and is therefore generically applicable to any bootstrapping case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrapping-split-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-29113332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-split-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-29113332.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue May 29 16:48:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht8cI-0008VO-SF; Tue, 29 May 2007 16:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht8cH-0008V5-7m; Tue, 29 May 2007 16:48:29 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht8cF-0004tR-Rx; Tue, 29 May 2007 16:48:29 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4TKmPN10844; Tue, 29 May 2007 20:48:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7A232.AAA08B06" Date: Tue, 29 May 2007 15:48:09 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371149041BB@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-muhanna-mip6-binding-revocation-01.txt Thread-Index: AceiKyQi1gQAqzLLTkmHmIyo8yZjcQABr4cA From: "Ahmad Muhanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: netlmm Subject: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A232.AAA08B06 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello all, Here is the updated Binding revocation draft with the changes to address the issue that was raised by Hui on MIP6 ml. We appreciate your comments in advance. Regards, Ahmad -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, May 29, 2007 2:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-muhanna-mip6-binding-revocation-01.txt Pages : 18 Date : 2007-5-29 =09 The service binding revocation semantics are missing in Mobile IPv6 Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document defines the semantics of the revocation of a mobile node registration binding, which could have been established using a Client Mobile IPv6 or a Proxy Mobile IPv6 signaling. The proposed revocation mechanism uses generic message properties which is applicable to Mobile IPv6 and Proxy Mobile IPv6 and can be used by any two mobility entities. As an example, this mechanism allows local mobility agent, involved in providing IP mobility services to a mobile node, to notify the mobility access gateway of the termination of the mobile node registration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio n-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-muhanna-mip6-binding-revocation-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-muhanna-mip6-binding-revocation-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C7A232.AAA08B06 Content-Type: application/octet-stream; name="ATT1737940.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT1737940.TXT Content-Disposition: attachment; filename="ATT1737940.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy01LTI5MTMzNjEzLkktREBpZXRmLm9yZz4NCg0KRU5D T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW11aGFubmEtbWlwNi1iaW5k aW5nLXJldm9jYXRpb24tMDEudHh0DQo= ------_=_NextPart_001_01C7A232.AAA08B06 Content-Type: application/octet-stream; name="draft-muhanna-mip6-binding-revocation-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-muhanna-mip6-binding-revocation-01.URL Content-Disposition: attachment; filename="draft-muhanna-mip6-binding-revocation-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tdWhhbm5hLW1pcDYtYmluZGluZy1yZXZvY2F0aW9uLTAxLnR4dA0K ------_=_NextPart_001_01C7A232.AAA08B06 Content-Type: text/plain; name="ATT1737941.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1737941.txt Content-Disposition: attachment; filename="ATT1737941.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C7A232.AAA08B06 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ------_=_NextPart_001_01C7A232.AAA08B06-- From mip6-bounces@ietf.org Tue May 29 20:49:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtCNG-0005rU-LJ; Tue, 29 May 2007 20:49:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtCNE-0005rB-VX for mip6@ietf.org; Tue, 29 May 2007 20:49:12 -0400 Received: from static-ip-163-194-65-202.rev.dyxnet.com ([202.65.194.163] helo=hitachihk6.hitachi.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtCN1-00080g-Qm for mip6@ietf.org; Tue, 29 May 2007 20:49:12 -0400 Received: (qmail 15247 invoked from network); 30 May 2007 00:48:54 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk6;4cff6404de12841942956262f62d7954; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1) by static-ip-163-194-65-202.rev.dyxnet.com with SMTP; 30 May 2007 00:48:54 -0000 Received: (qmail 22674 invoked from network); 30 May 2007 00:48:54 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;b911c9a2f907700f43a7cd3d368a31bf; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6) by 172.16.10.9 with SMTP; 30 May 2007 00:48:53 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 08:48:52 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Mip6] fw: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Wed, 30 May 2007 08:48:50 +0800 Message-ID: <8386EDF347730C46BA47710F87AE1FE902BB94@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] fw: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcegOKnzxTvKI8ooSfiJx96YRwKqAgA9lx0AAElLopM= From: "DENG, HUI -HCHBJ" To: "Ahmad Muhanna" , X-OriginalArrivalTime: 30 May 2007 00:48:52.0161 (UTC) FILETIME=[4AF10310:01C7A254] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1180486133.936-22671-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.07/0.16 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk6: Virus scan performed by network-box X-Scanned-By-hitachihk6: Scanner file id is hitachihk6-1180486134.328-15236-000 X-Scanned-By-hitachihk6: No known viruses found in message (received+scanned in 0.05/0.22 secs) X-Scanned-By-hitachihk6: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk6: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2033583642==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============2033583642== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A254.4A028A08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A254.4A028A08 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFueSB0aGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4NCiANCi1IdWkNCiANCg0KCS0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEFobWFkIE11aGFubmEgW21haWx0bzphbXVo YW5uYUBub3J0ZWwuY29tXSANCglTZW50OiAyMDA3LTUtMzAgKOaYn+acn+S4iSkgMToyOCANCglU bzogREVORywgSFVJIC1IQ0hCSjsgbWlwNkBpZXRmLm9yZyANCglDYzogDQoJU3ViamVjdDogUkU6 IFtNaXA2XSBmdzogSS1EIEFDVElPTjpkcmFmdC1tdWhhbm5hLW1pcDYtYmluZGluZy1yZXZvY2F0 aW9uLTAwLnR4dA0KCQ0KCQ0KDQoJSGkgSHVpLA0KCQ0KCVRoYW5rcyBhIGxvdCwgdGhhdCBpcyBh IGdvb2QgY2F0Y2guIEkgYWN0dWFsbHkgZG8gbm90IGtub3cgaG93IHRoaXMNCglzbGlwcGVkLiBJ IHdlbnQgYmFjayB0byBteSByZWNvcmQgb2YgZWFybGllciBpbnRlcm5hbCB2ZXJzaW9ucyBvZiB0 aGUNCglkcmFmdCB3aGljaCBhY3R1YWxseSByZWZsZWN0IHdoYXQgeW91IGV4YWN0bHkganVzdCBw b2ludGVkIG91dC4gU2luY2UNCgl0aGlzIGlzIGFuIGVycm9yLCB3ZSBhbHJlYWR5IHBvc3RlZCBh IG5ldyByZXZpc2lvbiBvZiB0aGUgZHJhZnQgd2l0aCB0aGUNCgljaGFuZ2VzIGNhcHR1cmVkIGJl bG93Og0KCQ0KCUJSSTogRmlndXJlIDEgc2hvdWxkIGhhdmUgbG9va2VkIGxpa2UgdGhpczoNCgkN CgkgICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAg ICAgICAgICAgICAgMw0KCSAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCgkgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCgkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICBTZXF1ZW5jZSAjICAg ICAgICAgIHwNCgkgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCgkgICAgICAgfFB8QXxHfCAgICAgICAgICAgICAg ICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgIHwNCgkgICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCgkgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCgkgICAgICAgLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCgkgICAgICAgLiAgICAg ICAgICAgICAgICAgICAgICAgIE1vYmlsaXR5IG9wdGlvbnMgICAgICAgICAgICAgICAgICAgICAg IC4NCgkgICAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC4NCgkgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCgkgICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CgkNCgkNCgkNCgkgICAgICAgICAgICAgIEZpZ3VyZSAxOiBCaW5kaW5nIFJldm9jYXRpb24gSW5k aWNhdGlvbiBNZXNzYWdlDQoJDQoJDQoJQlJBOiBGaWd1cmUgMiBzaG91bGQgaGF2ZSBsb29rZWQg bGlrZSB0aGlzOg0KCQ0KCQ0KCSAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAg ICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQoJICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KCSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KCSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgIFNlcXVlbmNlICMgICAgICAgICAgfA0KCSAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KCSAgICAgICB8ICAg U3RhdHVzICAgICAgfFB8ICAgICAgICAgICAgICAgICAgUmVzZXJ2ZWQgICAgICAgICAgICAgICAg ICAgfA0KCSAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KCSAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KCSAgICAgICAuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Lg0KCSAgICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgTW9iaWxpdHkgb3B0aW9ucyAgICAg ICAgICAgICAgICAgICAgICAgLg0KCSAgICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KCSAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K CSAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KCQ0KCQ0KCQ0KCSAgICAgICAgICAgRmlndXJlIDI6IEJpbmRpbmcg UmV2b2NhdGlvbiBBY2tub3dsZWRnZW1lbnQgTWVzc2FnZQ0KCQ0KCVJlZ2FyZHMsDQoJQWhtYWQN CgkNCgkNCgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBGcm9tOiBERU5HLCBIVUkg LUhDSEJKIFttYWlsdG86aGRlbmdAaGl0YWNoaS5jbl0NCgk+IFNlbnQ6IFN1bmRheSwgTWF5IDI3 LCAyMDA3IDM6MjYgQU0NCgk+IFRvOiBtaXA2QGlldGYub3JnDQoJPiBTdWJqZWN0OiBbTWlwNl0g Znc6IEktRA0KCT4gQUNUSU9OOmRyYWZ0LW11aGFubmEtbWlwNi1iaW5kaW5nLXJldm9jYXRpb24t MDAudHh0DQoJPg0KCT4gRGVhciBBdXRob3JzLA0KCT4NCgk+IEkgaGF2ZSBvbmUgc2ltcGxlIHF1 ZXN0aW9uIGFib3V0IHRoaXMgZHJhZnQsIEluIHRoZSBmaWd1cmUgMQ0KCT4gYW5kIDIsIHdoeSB0 aGlzIG1lc3NhZ2Ugc3RhcnQgZnJvbSBiaXQgMCBvdGhlciB0aGFuIDE2Pw0KCT4NCgk+IFRoYW5r cw0KCT4NCgk+IC1IdWkNCgk+DQoJPg0KCT4gRGlzY2xhaW1lcjoNCgk+IFRoZSBjb250ZW50cyBv ZiB0aGlzIGUtbWFpbCwgYW5kIGl0cyBhdHRhY2htZW50cywgaWYgYW55LCBhcmUNCgk+IGNvbmZp ZGVudGlhbCBhbmQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXcgYWdhaW5zdCBhbnkNCgk+IHVuYXV0 aG9yaXplZCB1c2UuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBieQ0KCT4gbWlz dGFrZSBvciBoYXZlIHJlYXNvbiB0byBiZWxpZXZlIHRoYXQgeW91IGFyZSBub3QgdGhlDQoJPiBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1h aWwNCgk+IGFzIHNvb24gYXMgcG9zc2libGUgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgY29tcHV0 ZXIgc3lzdGVtDQoJPiBpbW1lZGlhdGVseSB0aGVyZWFmdGVyLg0KCT4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IG11c3Qgbm90IGNvcHkgdGhpcw0KCT4gZS1tYWls IG9yIGF0dGFjaG1lbnQgb3IgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlcg0KCT4g cGVyc29uLiAgV2hpbGUgd2UgaGF2ZSBtYWRlIGV2ZXJ5IGVmZm9ydCB0byBrZWVwIG91ciBuZXR3 b3JrDQoJPiB2aXJ1cyBmcmVlLCB3ZSB0YWtlIG5vIHJlc3BvbnNpYmlsaXR5IGZvciBhbnkgY29t cHV0ZXIgdmlydXMNCgk+IHdoaWNoIG1pZ2h0IGJlIHRyYW5zZmVycmVkIGJ5IHdheSBvZiB0aGlz IGUtbWFpbC4NCgk+DQoJPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KCT4gTWlwNiBtYWlsaW5nIGxpc3QNCgk+IE1pcDZAaWV0Zi5vcmcNCgk+IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pcDYNCgk+DQoJDQoNCg== ------_=_NextPart_001_01C7A254.4A028A08 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY2MDMuMCI+CjxUSVRMRT5SRTogW01pcDZdIGZ3OiBJ LUQgQUNUSU9OOmRyYWZ0LW11aGFubmEtbWlwNi1iaW5kaW5nLXJldm9jYXRpb24tMDAudHh0PC9U SVRMRT4KPC9IRUFEPgo8Qk9EWSBkaXI9bHRyPgo8RElWPk1hbnkgdGhhbmtzIGZvciB5b3VyIGNs YXJpZmljYXRpb24uPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+LUh1aTwvRElWPgo8RElW PiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBw eCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gPEJSPjxC PkZyb206PC9CPiBBaG1hZCBNdWhhbm5hIAogIFttYWlsdG86YW11aGFubmFAbm9ydGVsLmNvbV0g PEJSPjxCPlNlbnQ6PC9CPiAyMDA3LTUtMzAgKOaYn+acn+S4iSkgMToyOCAKICA8QlI+PEI+VG86 PC9CPiBERU5HLCBIVUkgLUhDSEJKOyBtaXA2QGlldGYub3JnIDxCUj48Qj5DYzo8L0I+IAogIDxC Uj48Qj5TdWJqZWN0OjwvQj4gUkU6IFtNaXA2XSBmdzogSS1EIAogIEFDVElPTjpkcmFmdC1tdWhh bm5hLW1pcDYtYmluZGluZy1yZXZvY2F0aW9uLTAwLnR4dDxCUj48QlI+PC9GT05UPjwvRElWPgog IDxQPjxGT05UIHNpemU9Mj5IaSBIdWksPEJSPjxCUj5UaGFua3MgYSBsb3QsIHRoYXQgaXMgYSBn b29kIGNhdGNoLiBJIGFjdHVhbGx5IAogIGRvIG5vdCBrbm93IGhvdyB0aGlzPEJSPnNsaXBwZWQu IEkgd2VudCBiYWNrIHRvIG15IHJlY29yZCBvZiBlYXJsaWVyIGludGVybmFsIAogIHZlcnNpb25z IG9mIHRoZTxCUj5kcmFmdCB3aGljaCBhY3R1YWxseSByZWZsZWN0IHdoYXQgeW91IGV4YWN0bHkg anVzdCBwb2ludGVkIAogIG91dC4gU2luY2U8QlI+dGhpcyBpcyBhbiBlcnJvciwgd2UgYWxyZWFk eSBwb3N0ZWQgYSBuZXcgcmV2aXNpb24gb2YgdGhlIGRyYWZ0IAogIHdpdGggdGhlPEJSPmNoYW5n ZXMgY2FwdHVyZWQgYmVsb3c6PEJSPjxCUj5CUkk6IEZpZ3VyZSAxIHNob3VsZCBoYXZlIGxvb2tl ZCAKICBsaWtlIHRoaXM6PEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgCiAgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAKICAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IAogIDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg CiAgMzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgCiAgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAKICAx PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAKICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2Vx dWVuY2UgCiAgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAKICB8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgfFB8QXxH fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBSZXNlcnZlZCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAKICB8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAK ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICB8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAKICAuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIC48 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIC4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgCiAgTW9iaWxpdHkgCiAgb3B0aW9ucyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICAu PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICAuJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IAogIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgfDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8QlI+PEJSPjxCUj48QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIEZpZ3VyZSAxOiBCaW5kaW5nIFJldm9jYXRpb24gSW5k aWNhdGlvbiBNZXNzYWdlPEJSPjxCUj48QlI+QlJBOiBGaWd1cmUgMiAKICBzaG91bGQgaGF2ZSBs b29rZWQgbGlrZSB0aGlzOjxCUj48QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAKICAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IAogIDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgCiAgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAKICAzPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyAKICA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IAogIDE8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IAogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBTZXF1ZW5jZSAKICAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IAogIHw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IAogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICB8 Jm5ic3A7Jm5ic3A7IFN0YXR1cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICB8UHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgUmVzZXJ2ZWQm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgfDxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgCiAgfDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg CiAgLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICAuPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICAuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIE1v YmlsaXR5IAogIG9wdGlvbnMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgLjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAKICAuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIHw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IAogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rPEJSPjxCUj48QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBGaWd1cmUgMjog QmluZGluZyBSZXZvY2F0aW9uIEFja25vd2xlZGdlbWVudCAKICBNZXNzYWdlPEJSPjxCUj5SZWdh cmRzLDxCUj5BaG1hZDxCUj48QlI+PEJSPiZndDsgLS0tLS1PcmlnaW5hbCAKICBNZXNzYWdlLS0t LS08QlI+Jmd0OyBGcm9tOiBERU5HLCBIVUkgLUhDSEJKIFs8QSAKICBocmVmPSJtYWlsdG86aGRl bmdAaGl0YWNoaS5jbiI+bWFpbHRvOmhkZW5nQGhpdGFjaGkuY248L0E+XTxCUj4mZ3Q7IFNlbnQ6 IAogIFN1bmRheSwgTWF5IDI3LCAyMDA3IDM6MjYgQU08QlI+Jmd0OyBUbzogbWlwNkBpZXRmLm9y ZzxCUj4mZ3Q7IFN1YmplY3Q6IFtNaXA2XSAKICBmdzogSS1EPEJSPiZndDsgCiAgQUNUSU9OOmRy YWZ0LW11aGFubmEtbWlwNi1iaW5kaW5nLXJldm9jYXRpb24tMDAudHh0PEJSPiZndDs8QlI+Jmd0 OyBEZWFyIAogIEF1dGhvcnMsPEJSPiZndDs8QlI+Jmd0OyBJIGhhdmUgb25lIHNpbXBsZSBxdWVz dGlvbiBhYm91dCB0aGlzIGRyYWZ0LCBJbiB0aGUgCiAgZmlndXJlIDE8QlI+Jmd0OyBhbmQgMiwg d2h5IHRoaXMgbWVzc2FnZSBzdGFydCBmcm9tIGJpdCAwIG90aGVyIHRoYW4gCiAgMTY/PEJSPiZn dDs8QlI+Jmd0OyBUaGFua3M8QlI+Jmd0OzxCUj4mZ3Q7IC1IdWk8QlI+Jmd0OzxCUj4mZ3Q7PEJS PiZndDsgCiAgRGlzY2xhaW1lcjo8QlI+Jmd0OyBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWws IGFuZCBpdHMgYXR0YWNobWVudHMsIGlmIGFueSwgCiAgYXJlPEJSPiZndDsgY29uZmlkZW50aWFs IGFuZCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdyBhZ2FpbnN0IGFueTxCUj4mZ3Q7IAogIHVuYXV0 aG9yaXplZCB1c2UuJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZS1tYWlsIGJ5PEJS PiZndDsgbWlzdGFrZSBvciAKICBoYXZlIHJlYXNvbiB0byBiZWxpZXZlIHRoYXQgeW91IGFyZSBu b3QgdGhlPEJSPiZndDsgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgCiAgbm90aWZ5IHRoZSBz ZW5kZXIgYnkgcmVwbHkgZS1tYWlsPEJSPiZndDsgYXMgc29vbiBhcyBwb3NzaWJsZSBhbmQgZGVs ZXRlIGl0IAogIGZyb20geW91ciBjb21wdXRlciBzeXN0ZW08QlI+Jmd0OyBpbW1lZGlhdGVseSB0 aGVyZWFmdGVyLjxCUj4mZ3Q7IElmIHlvdSBhcmUgCiAgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHlvdSBtdXN0IG5vdCBjb3B5IHRoaXM8QlI+Jmd0OyBlLW1haWwgb3IgCiAgYXR0YWNobWVu dCBvciBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyPEJSPiZndDsgcGVyc29uLiZu YnNwOyBXaGlsZSAKICB3ZSBoYXZlIG1hZGUgZXZlcnkgZWZmb3J0IHRvIGtlZXAgb3VyIG5ldHdv cms8QlI+Jmd0OyB2aXJ1cyBmcmVlLCB3ZSB0YWtlIG5vIAogIHJlc3BvbnNpYmlsaXR5IGZvciBh bnkgY29tcHV0ZXIgdmlydXM8QlI+Jmd0OyB3aGljaCBtaWdodCBiZSB0cmFuc2ZlcnJlZCBieSAK ICB3YXkgb2YgdGhpcyBlLW1haWwuPEJSPiZndDs8QlI+Jmd0OyAKICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7IE1pcDYgbWFpbGluZyAKICBs aXN0PEJSPiZndDsgTWlwNkBpZXRmLm9yZzxCUj4mZ3Q7IDxBIAogIGhyZWY9Imh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pcDYiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21pcDY8L0E+PEJSPiZndDs8QlI+PC9GT05UPjwvUD48L0JMT0NLUVVP VEU+Cgo8L0JPRFk+CjwvSFRNTD4= ------_=_NextPart_001_01C7A254.4A028A08-- --===============2033583642== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2033583642==-- From mip6-bounces@ietf.org Wed May 30 13:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRbW-0006d4-M4; Wed, 30 May 2007 13:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRbV-0006cO-OY for mip6@ietf.org; Wed, 30 May 2007 13:04:57 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtRbU-0003uX-9R for mip6@ietf.org; Wed, 30 May 2007 13:04:57 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UH4WPV000781; Wed, 30 May 2007 20:04:49 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 20:04:36 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 12:04:34 -0500 Received: from 10.241.59.148 ([10.241.59.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2007 17:04:34 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 30 May 2007 12:04:34 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: WG LC: draft-ietf-mip6-experimental-messages-01 and draft-ietf-mip6-vsm-01 Thread-Index: Acei3JiY1u3/Fg7PEdyfTgARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 May 2007 17:04:34.0753 (UTC) FILETIME=[990BA310:01C7A2DC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Gopal Dommety , Vijay Devarapalli Subject: [Mip6] WG LC: draft-ietf-mip6-experimental-messages-01 and draft-ietf-mip6-vsm-01 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This is a working group last call for the following two working group documents: 1. Mobile IPv6 Experimental Messages Status intended: Experimental 2. Mobile IPv6 Vendor Specific Option Status intended: Standards track The last call ends on June 14th, 07. Please review the I-Ds and send your comments to the mailing list. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 30 13:19:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRpf-0003WX-Al; Wed, 30 May 2007 13:19:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRpe-0003WS-KC for mip6@ietf.org; Wed, 30 May 2007 13:19:34 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtRpe-0007IY-2e for mip6@ietf.org; Wed, 30 May 2007 13:19:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UHJQE7027356; Wed, 30 May 2007 20:19:32 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 20:19:31 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 12:19:23 -0500 Received: from 10.241.59.148 ([10.241.59.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2007 17:19:23 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 30 May 2007 12:19:23 -0500 Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt From: Basavaraj Patil To: ext Ahmad Muhanna , Message-ID: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+s= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 May 2007 17:19:23.0967 (UTC) FILETIME=[AB0EECF0:01C7A2DE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ahmad, Binding revocation is a useful feature. However, we have a I-D: Mobility Header Signaling Message which can be used as the means for binding revocation as well. In Prague, we discussed this I-D and agreed to consider it as a WG document. -Raj On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: > > Hello Folks, > > We submitted this draft for Binding Revocation for IPv6 Mobility. It > handles several use cases which are applicable to Client Mobile IPv6 and > PMIPv6. Please take a look and we appreciate your comments. > > Thanks in advance. > > Regards, > Ahmad Muhanna > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, May 25, 2007 2:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mip6-binding-revocation-00.txt > Pages : 18 > Date : 2007-5-25 > > The service binding revocation semantics are missing in Mobile IPv6 > Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document > defines the semantics of the revocation of a mobile node registration > binding, which could have been established using a Client Mobile IPv6 > or a Proxy Mobile IPv6 signaling. The proposed revocation mechanism > uses generic message properties which is applicable to Mobile IPv6 > and Proxy Mobile IPv6 and can be used by any two mobility entities. > As an example, this mechanism allows local mobility agent, involved > in providing IP mobility services to a mobile node, to notify the > mobility access gateway of the termination of the mobile node > registration. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio > n-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-muhanna-mip6-binding-revocation-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > 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 From mip6-bounces@ietf.org Wed May 30 13:23:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRtZ-00062R-53; Wed, 30 May 2007 13:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRtX-00062M-TA for mip6@ietf.org; Wed, 30 May 2007 13:23:35 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtRtW-0008Qq-Dq for mip6@ietf.org; Wed, 30 May 2007 13:23:35 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UHN90B028421; Wed, 30 May 2007 20:23:31 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 20:23:27 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 12:23:25 -0500 Received: from 10.241.59.148 ([10.241.59.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2007 17:23:24 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 30 May 2007 12:23:25 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc Thread-Index: Acei3zq5eSkLSQ7SEdyfTgARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 May 2007 17:23:25.0465 (UTC) FILETIME=[3B009890:01C7A2DF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: brian.haley@hp.com, ext Sri Gundavelli Subject: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, At the Prague IETF (IETF68), the MIP6 WG discussed the following I-D: Mobility Header Signaling Message There was consensus in the meeting to make this a WG document. We would like to obtain consensus on the WG ML prior to making it a WG doc. Please review the I-D and indicate if you are in favor of this I-D becoming a WG document. We will decide after June 10th, 07 the status of this I-D following the feedback from the WG members. Abstract of the I-D: This document specifies a new Mobility Header message type that can be used between a mobile node and home agent to signal an event that requires attention. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 30 15:22:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTkF-0001e2-Vn; Wed, 30 May 2007 15:22:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTkE-0001cT-J0 for mip6@ietf.org; Wed, 30 May 2007 15:22:06 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtTkD-0006tx-70 for mip6@ietf.org; Wed, 30 May 2007 15:22:06 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4UJM2A15988; Wed, 30 May 2007 19:22:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Wed, 30 May 2007 14:21:49 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711495AB8A@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sAAsoVMA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Basavaraj Patil" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, If I remember correctly, since no new options were defined by the draft-haley, a question was asked about the scope of the notification messages and it was mentioned, Opaque. IMO, the draft-haley is intended for sending a generic notification (fyi) messages, where detailed receiver action is not required and does not need to be specified. The common use cases include, expiry of prepaid billing, service outage related notifications, new promotional information. Revocation is a detailed topic which handles many scenarios and use cases addressing both NetLMM and MIP6 scope with potential to address some very specific scenarios that need a detailed attention by the receiver and most probably a reply after processing the revocation indication message. Overloading a generic notification (fyi) messages to handle all of the revocation scenarios is similar to trying to fit an elephant in a refrigerator :)=20 IMO, the generic notification (fyi) messages would quite restrict and limit the revocation mechanism potential to address many immanent scenarios that will evolve due to the interaction of MIP6 and PMIPv6 when deployed over the heterogeneous nature of the mobile IP network at large. I strongly believe that the revocation mechanism introduced in the Binding Revocation draft needs to be addressed separately from the notification (fyi) messages proposed by draft-haley. Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Wednesday, May 30, 2007 12:19 PM > To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org > Subject: Re: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 >=20 > Ahmad, >=20 > Binding revocation is a useful feature. > However, we have a I-D: Mobility Header Signaling Message=20 > which can be used as=20 > the means for binding revocation as well. >=20 > In Prague, we discussed this I-D and agreed to consider it as=20 > a WG document. >=20 > -Raj >=20 >=20 > On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: >=20 > > =20 > > Hello Folks, > >=20 > > We submitted this draft for Binding Revocation for IPv6=20 > Mobility. It=20 > > handles several use cases which are applicable to Client=20 > Mobile IPv6=20 > > and PMIPv6. Please take a look and we appreciate your comments. > >=20 > > Thanks in advance. > >=20 > > Regards, > > Ahmad Muhanna > >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, May 25, 2007 2:50 PM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : Binding Revocation for IPv6 Mobility > > Author(s) : A. Muhanna, et al. > > Filename : draft-muhanna-mip6-binding-revocation-00.txt > > Pages : 18 > > Date : 2007-5-25 > >=20 > > The service binding revocation semantics are missing in=20 > Mobile IPv6 > > Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document > > defines the semantics of the revocation of a mobile node=20 > registration > > binding, which could have been established using a=20 > Client Mobile IPv6 > > or a Proxy Mobile IPv6 signaling. The proposed=20 > revocation mechanism > > uses generic message properties which is applicable to=20 > Mobile IPv6 > > and Proxy Mobile IPv6 and can be used by any two=20 > mobility entities. > > As an example, this mechanism allows local mobility=20 > agent, involved > > in providing IP mobility services to a mobile node, to notify the > > mobility access gateway of the termination of the mobile node > > registration. > >=20 > >=20 > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocat > > io > > n-00.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-muhanna-mip6-binding-revocation-00.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > > /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". > >=20 > > NOTE: The mail server at ietf.org can return the document in=20 > > MIME-encoded form by using the "mpack" utility. To use=20 > this feature,=20 > > insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or a=20 > > MIME-compliant mail reader. Different MIME-compliant mail readers=20 > > exhibit different behavior, especially when dealing with=20 > "multipart"=20 > > MIME messages (i.e. documents which have been split up into=20 > multiple=20 > > messages), so check your local documentation on how to manipulate=20 > > these messages. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 30 15:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU3d-0005jH-HL; Wed, 30 May 2007 15:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU3c-0005jC-2c for mip6@ietf.org; Wed, 30 May 2007 15:42:08 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtU3b-0004Mf-ND for mip6@ietf.org; Wed, 30 May 2007 15:42:08 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4UJg5n04684; Wed, 30 May 2007 19:42:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Wed, 30 May 2007 14:41:41 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6C33@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sABNV1EA== From: "Mohamed Khalil" To: "Basavaraj Patil" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I strongly disagree on the idea of designing a protocol which is used as a container for other protocols. Each protocol should have a limited scope and designed according to certain requirements. It is very difficult to design a generic protocol which satisfy all the requirements for all future protocols. This container idea has many issues, the simplest is that it increases, unnecessarily, the processing time for the contained protocol (e.g. revocation). In addition there some situations where a simple Request/Reply will not be enough to do the job. Let us leave each protocol designer(s) to do what it is required to do and don't limit their thinking.=20 -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Wednesday, May 30, 2007 12:19 PM To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Ahmad, Binding revocation is a useful feature. However, we have a I-D: Mobility Header Signaling Message which can be used as the means for binding revocation as well. In Prague, we discussed this I-D and agreed to consider it as a WG document. -Raj On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: > =20 > Hello Folks, >=20 > We submitted this draft for Binding Revocation for IPv6 Mobility. It=20 > handles several use cases which are applicable to Client Mobile IPv6=20 > and PMIPv6. Please take a look and we appreciate your comments. >=20 > Thanks in advance. >=20 > Regards, > Ahmad Muhanna >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, May 25, 2007 2:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-muhanna-mip6-binding-revocation-00.txt > Pages : 18 > Date : 2007-5-25 >=20 > The service binding revocation semantics are missing in Mobile IPv6 > Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document > defines the semantics of the revocation of a mobile node registration > binding, which could have been established using a Client Mobile IPv6 > or a Proxy Mobile IPv6 signaling. The proposed revocation mechanism > uses generic message properties which is applicable to Mobile IPv6 > and Proxy Mobile IPv6 and can be used by any two mobility entities. > As an example, this mechanism allows local mobility agent, involved > in providing IP mobility services to a mobile node, to notify the > mobility access gateway of the termination of the mobile node > registration. >=20 >=20 >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocat > io > n-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then "get=20 > draft-muhanna-mip6-binding-revocation-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in=20 > MIME-encoded form by using the "mpack" utility. To use this feature,=20 > insert the command "ENCODING mime" before the "FILE" command. To=20 > decode the response(s), you will need "munpack" or a MIME-compliant=20 > mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. _______________________________________________ > 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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 30 16:20:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUed-0006ii-6H; Wed, 30 May 2007 16:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUeb-0006iZ-6i for mip6@ietf.org; Wed, 30 May 2007 16:20:21 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtUea-0008BN-FC for mip6@ietf.org; Wed, 30 May 2007 16:20:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UKKG6e011739; Wed, 30 May 2007 23:20:18 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 23:20:17 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 15:19:25 -0500 Received: from 10.241.59.148 ([10.241.59.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2007 20:19:24 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 30 May 2007 15:19:24 -0500 Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt From: Basavaraj Patil To: ext Ahmad Muhanna , Message-ID: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sAAsoVMAADf2R7 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711495AB8A@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 May 2007 20:19:25.0067 (UTC) FILETIME=[D103FDB0:01C7A2F7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ahmad, Would you not consider binding revocation by an HA as a notification message from the HA to the MN? The subsequent actions or behavior of the MN and HA resulting from such a notification (binding revocation) is to be specified. But I am not sure if there is a need to have new signaling messages for accomplishing binding revocation. What the I-D draft-haley-mip6-mh-signaling is specifying (from what I understood) is a mechanism to do signaling between the HA<->MN. It is specifying a generic mechanism for signaling which may be for various reasons including the examples that you quote below. I don't know if there would be any limitations of using the generic notification extension for the purpose of binding revocation. -Raj On 5/30/07 2:21 PM, "ext Ahmad Muhanna" wrote: > Hi Raj, > > If I remember correctly, since no new options were defined by the > draft-haley, a question was asked about the scope of the notification > messages and it was mentioned, Opaque. > > IMO, the draft-haley is intended for sending a generic notification > (fyi) messages, where detailed receiver action is not required and does > not need to be specified. The common use cases include, expiry of > prepaid billing, service outage related notifications, new promotional > information. > > Revocation is a detailed topic which handles many scenarios and use > cases addressing both NetLMM and MIP6 scope with potential to address > some very specific scenarios that need a detailed attention by the > receiver and most probably a reply after processing the revocation > indication message. Overloading a generic notification (fyi) messages to > handle all of the revocation scenarios is similar to trying to fit an > elephant in a refrigerator :) > > IMO, the generic notification (fyi) messages would quite restrict and > limit the revocation mechanism potential to address many immanent > scenarios that will evolve due to the interaction of MIP6 and PMIPv6 > when deployed over the heterogeneous nature of the mobile IP network at > large. > > I strongly believe that the revocation mechanism introduced in the > Binding Revocation draft needs to be addressed separately from the > notification (fyi) messages proposed by draft-haley. > > > Regards, > Ahmad > > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Wednesday, May 30, 2007 12:19 PM >> To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org >> Subject: Re: [Mip6] FW: I-D >> ACTION:draft-muhanna-mip6-binding-revocation-00.txt >> >> >> Ahmad, >> >> Binding revocation is a useful feature. >> However, we have a I-D: Mobility Header Signaling Message >> which can be used as >> the means for binding revocation as well. >> >> In Prague, we discussed this I-D and agreed to consider it as >> a WG document. >> >> -Raj >> >> >> On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: >> >>> >>> Hello Folks, >>> >>> We submitted this draft for Binding Revocation for IPv6 >> Mobility. It >>> handles several use cases which are applicable to Client >> Mobile IPv6 >>> and PMIPv6. Please take a look and we appreciate your comments. >>> >>> Thanks in advance. >>> >>> Regards, >>> Ahmad Muhanna >>> >>> -----Original Message----- >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>> Sent: Friday, May 25, 2007 2:50 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Binding Revocation for IPv6 Mobility >>> Author(s) : A. Muhanna, et al. >>> Filename : draft-muhanna-mip6-binding-revocation-00.txt >>> Pages : 18 >>> Date : 2007-5-25 >>> >>> The service binding revocation semantics are missing in >> Mobile IPv6 >>> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document >>> defines the semantics of the revocation of a mobile node >> registration >>> binding, which could have been established using a >> Client Mobile IPv6 >>> or a Proxy Mobile IPv6 signaling. The proposed >> revocation mechanism >>> uses generic message properties which is applicable to >> Mobile IPv6 >>> and Proxy Mobile IPv6 and can be used by any two >> mobility entities. >>> As an example, this mechanism allows local mobility >> agent, involved >>> in providing IP mobility services to a mobile node, to notify the >>> mobility access gateway of the termination of the mobile node >>> registration. >>> >>> >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocat >>> io >>> n-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a >> message to >>> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >>> the message. >>> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then "get >>> draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE >>> /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use >> this feature, >>> insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or a >>> MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >> "multipart" >>> MIME messages (i.e. documents which have been split up into >> multiple >>> messages), so check your local documentation on how to manipulate >>> these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> _______________________________________________ >>> 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 From mip6-bounces@ietf.org Wed May 30 16:24:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUiy-0001Dr-6B; Wed, 30 May 2007 16:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUiw-0001Dj-8a for mip6@ietf.org; Wed, 30 May 2007 16:24:50 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtUiu-0001v5-Hj for mip6@ietf.org; Wed, 30 May 2007 16:24:50 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UKOfvb005673; Wed, 30 May 2007 23:24:46 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 23:24:42 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 15:24:12 -0500 Received: from 10.241.59.148 ([10.241.59.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2007 20:24:11 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 30 May 2007 15:24:11 -0500 Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt From: Basavaraj Patil To: ext Mohamed Khalil , Message-ID: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sABNV1EAABnsi+ In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F6C33@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 May 2007 20:24:12.0177 (UTC) FILETIME=[7C258010:01C7A2F8] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org MK, I don't think anyone is designing a new protocol here. In MIP6 we have a protocol (RFC3775) and are now extending it for meeting some of the requirements which would enable deployment and adding a few new limited features. The mobility header signaling message is a generic extension that can be used for various purposes as indicated in the draft itself. To me binding revocation is merely another notification. I don't understand what complexities you are refering to below or processing issue. Can you clarify why the binding revocation cannot be solved by the specification of an option in the mobility header signaling message? -Raj On 5/30/07 2:41 PM, "ext Mohamed Khalil" wrote: > Hi Raj, > > I strongly disagree on the idea of designing a protocol which is used as > a container for other protocols. Each protocol should have a limited > scope and designed according to certain requirements. It is very > difficult to design a generic protocol which satisfy all the > requirements for all future protocols. This container idea has many > issues, the simplest is that it increases, unnecessarily, the processing > time for the contained protocol (e.g. revocation). In addition there > some situations where a simple Request/Reply will not be enough to do > the job. Let us leave each protocol designer(s) to do what it is > required to do and don't limit their thinking. > > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Wednesday, May 30, 2007 12:19 PM > To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org > Subject: Re: [Mip6] FW: I-D > ACTION:draft-muhanna-mip6-binding-revocation-00.txt > > > > Ahmad, > > Binding revocation is a useful feature. > However, we have a I-D: Mobility Header Signaling Message > which can be used as the means > for binding revocation as well. > > In Prague, we discussed this I-D and agreed to consider it as a WG > document. > > -Raj > > > On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: > >> >> Hello Folks, >> >> We submitted this draft for Binding Revocation for IPv6 Mobility. It >> handles several use cases which are applicable to Client Mobile IPv6 >> and PMIPv6. Please take a look and we appreciate your comments. >> >> Thanks in advance. >> >> Regards, >> Ahmad Muhanna >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Friday, May 25, 2007 2:50 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Binding Revocation for IPv6 Mobility >> Author(s) : A. Muhanna, et al. >> Filename : draft-muhanna-mip6-binding-revocation-00.txt >> Pages : 18 >> Date : 2007-5-25 >> >> The service binding revocation semantics are missing in Mobile IPv6 >> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document >> defines the semantics of the revocation of a mobile node > registration >> binding, which could have been established using a Client Mobile > IPv6 >> or a Proxy Mobile IPv6 signaling. The proposed revocation > mechanism >> uses generic message properties which is applicable to Mobile IPv6 >> and Proxy Mobile IPv6 and can be used by any two mobility entities. >> As an example, this mechanism allows local mobility agent, involved >> in providing IP mobility services to a mobile node, to notify the >> mobility access gateway of the termination of the mobile node >> registration. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocat >> io >> n-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of > >> the message. You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then "get >> draft-muhanna-mip6-binding-revocation-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this feature, >> insert the command "ENCODING mime" before the "FILE" command. To >> decode the response(s), you will need "munpack" or a MIME-compliant >> mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. _______________________________________________ >> 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 > > _______________________________________________ > 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 From mip6-bounces@ietf.org Wed May 30 16:57:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVEC-0002y3-OC; Wed, 30 May 2007 16:57:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVEB-0002sZ-9n for mip6@ietf.org; Wed, 30 May 2007 16:57:07 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtVE8-0004IK-R5 for mip6@ietf.org; Wed, 30 May 2007 16:57:07 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4UKv2n27763; Wed, 30 May 2007 20:57:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Wed, 30 May 2007 15:57:01 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6C37@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sABNV1EAABnsi+AAEVQ7A= From: "Mohamed Khalil" To: "Basavaraj Patil" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, If we include revocation protocol in information options, we will end up with three levels of protocol complexity as follows: 1- The Information option Request message. 2- The information option containing the revocation request, let us call it revocation option. 3- the revocation attributes, or sub-options. This means that the revocation option needs to be structured very much similarly to the Binding Revocation Indication message, as per Binding Revocation draft, where it has to carry all possible options as sub-options. This simply a control protocol imbedded inside another one which introduce unnecessary complexity.=20 If we don't have this container mechanism, the process is simple. 1- The revocation protocol request message. 2- The revocation related options. Regards Mohamed -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Wednesday, May 30, 2007 3:24 PM To: Khalil, Mohamed (RICH2:2S20); mip6@ietf.org Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt MK, I don't think anyone is designing a new protocol here. In MIP6 we have a protocol (RFC3775) and are now extending it for meeting some of the requirements which would enable deployment and adding a few new limited features. The mobility header signaling message is a generic extension that can be used for various purposes as indicated in the draft itself. To me binding revocation is merely another notification. I don't understand what complexities you are refering to below or processing issue. Can you clarify why the binding revocation cannot be solved by the specification of an option in the mobility header signaling message? -Raj=20 On 5/30/07 2:41 PM, "ext Mohamed Khalil" wrote: > Hi Raj, >=20 > I strongly disagree on the idea of designing a protocol which is used=20 > as a container for other protocols. Each protocol should have a=20 > limited scope and designed according to certain requirements. It is=20 > very difficult to design a generic protocol which satisfy all the=20 > requirements for all future protocols. This container idea has many=20 > issues, the simplest is that it increases, unnecessarily, the=20 > processing time for the contained protocol (e.g. revocation). In=20 > addition there some situations where a simple Request/Reply will not=20 > be enough to do the job. Let us leave each protocol designer(s) to do=20 > what it is required to do and don't limit their thinking. >=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Wednesday, May 30, 2007 12:19 PM > To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org > Subject: Re: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 >=20 >=20 > Ahmad, >=20 > Binding revocation is a useful feature. > However, we have a I-D: Mobility Header Signaling Message=20 > which can be used as the means=20 > for binding revocation as well. >=20 > In Prague, we discussed this I-D and agreed to consider it as a WG=20 > document. >=20 > -Raj >=20 >=20 > On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: >=20 >> =20 >> Hello Folks, >>=20 >> We submitted this draft for Binding Revocation for IPv6 Mobility. It=20 >> handles several use cases which are applicable to Client Mobile IPv6=20 >> and PMIPv6. Please take a look and we appreciate your comments. >>=20 >> Thanks in advance. >>=20 >> Regards, >> Ahmad Muhanna >>=20 >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Friday, May 25, 2007 2:50 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >>=20 >>=20 >> Title : Binding Revocation for IPv6 Mobility >> Author(s) : A. Muhanna, et al. >> Filename : draft-muhanna-mip6-binding-revocation-00.txt >> Pages : 18 >> Date : 2007-5-25 >>=20 >> The service binding revocation semantics are missing in Mobile IPv6 >> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document >> defines the semantics of the revocation of a mobile node > registration >> binding, which could have been established using a Client Mobile > IPv6 >> or a Proxy Mobile IPv6 signaling. The proposed revocation > mechanism >> uses generic message properties which is applicable to Mobile IPv6 >> and Proxy Mobile IPv6 and can be used by any two mobility entities. >> As an example, this mechanism allows local mobility agent, involved >> in providing IP mobility services to a mobile node, to notify the >> mobility access gateway of the termination of the mobile node >> registration. >>=20 >>=20 >>=20 >> A URL for this Internet-Draft is:=20 >> http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revoca >> t >> io >> n-00.txt >>=20 >> To remove yourself from the I-D Announcement list, send a message to=20 >> i-d-announce-request@ietf.org with the word unsubscribe in the body=20 >> of >=20 >> the message. You can also visit=20 >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >>=20 >> Internet-Drafts are also available by anonymous FTP. Login with the=20 >> username "anonymous" and a password of your e-mail address. After=20 >> logging in, type "cd internet-drafts" and then "get=20 >> draft-muhanna-mip6-binding-revocation-00.txt". >>=20 >> A list of Internet-Drafts directories can be found in=20 >> http://www.ietf.org/shadow.html or=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> Internet-Drafts can also be obtained by e-mail. >>=20 >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". >>=20 >> NOTE: The mail server at ietf.org can return the document in=20 >> MIME-encoded form by using the "mpack" utility. To use this feature, >> insert the command "ENCODING mime" before the "FILE" command. To=20 >> decode the response(s), you will need "munpack" or a MIME-compliant=20 >> mail reader. Different MIME-compliant mail readers exhibit different >> behavior, especially when dealing with "multipart" MIME messages=20 >> (i.e. documents which have been split up into multiple messages), so=20 >> check your local documentation on how to manipulate these messages. >>=20 >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft. _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > 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 From mip6-bounces@ietf.org Wed May 30 17:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVsn-0008AZ-5U; Wed, 30 May 2007 17:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVsl-0008AQ-FF for mip6@ietf.org; Wed, 30 May 2007 17:39:03 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtVsl-0002EV-09 for mip6@ietf.org; Wed, 30 May 2007 17:39:03 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4ULd0n12466; Wed, 30 May 2007 21:39:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Wed, 30 May 2007 16:38:59 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371149B0794@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sAAsoVMAADf2R7AABQAJA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711495AB8A@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Basavaraj Patil" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, Please see my comments inline. Regards, Ahmad > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Wednesday, May 30, 2007 3:19 PM > To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org > Subject: Re: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 >=20 > Hi Ahmad, >=20 > Would you not consider binding revocation by an HA as a=20 > notification message from the HA to the MN? [Ahmad] As usual, the devil in the details. In general, as you may agree, any thing is possible. However, IMO, trying to use the generic notification messages for registration revocation introduces an unnecessary complexity and, I believe is not the best possible way to go forward. With the expected complexity of the Mobile IP network layout and the real need to support seamless mobility across heterogeneous access network, a MN binding may experience different states during one single call.=20 I am very well aware and understand that we need to restrict our discussion to Client MIPv6 on this wg mailing list. However, I strongly believe that we need to have one revocation mechanism for Client MIPv6 and PMIPv6 for the following reasons: 1. At IETF, the trend seems to be more of a consolidation of related wg trend. MIPv6 and PMIPv6 probably good candidates. 2. More importantly and due to the different access network deployment, a Client MIPv6 binding can very possibly be modified by a PMIPv6 BU during a transitional scenario. 3. Last but not least, the co-location of LMA and HA is a very possible scenario and a single protocol to handle revocation for both MIPv6 and PMIPv6 is an serious plus. In Summary: I look at the binding revocation mechanism as "the common denominator" for MIPv6 and PMIPv6 where it can be used to maintain the best possible use of the network available resources. This means that any introduced revocation mechanism needs to address all possible scenarios in MIPv6 and PMIPv6. Having this in mind, I believe sneaking the binding revocation protocol inside the generic notification messages is not probably the best we can do. A separate clean revocation mechanism has the flexibility and the potential to address many scenarios that we may not have yet identified. Best Regards, Ahmad >=20 > The subsequent actions or behavior of the MN and HA resulting=20 > from such a notification (binding revocation) is to be=20 > specified. But I am not sure if there is a need to have new=20 > signaling messages for accomplishing binding revocation.=20 >=20 > What the I-D draft-haley-mip6-mh-signaling is specifying (from what I > understood) is a mechanism to do signaling between the=20 > HA<->MN. It is specifying a generic mechanism for signaling=20 > which may be for various reasons including the examples that=20 > you quote below. I don't know if there would be any=20 > limitations of using the generic notification extension for=20 > the purpose of binding revocation. >=20 > -Raj >=20 >=20 > On 5/30/07 2:21 PM, "ext Ahmad Muhanna" wrote: >=20 > > Hi Raj, > >=20 > > If I remember correctly, since no new options were defined by the=20 > > draft-haley, a question was asked about the scope of the=20 > notification=20 > > messages and it was mentioned, Opaque. > >=20 > > IMO, the draft-haley is intended for sending a generic notification > > (fyi) messages, where detailed receiver action is not required and=20 > > does not need to be specified. The common use cases=20 > include, expiry of=20 > > prepaid billing, service outage related notifications, new=20 > promotional=20 > > information. > >=20 > > Revocation is a detailed topic which handles many scenarios and use=20 > > cases addressing both NetLMM and MIP6 scope with potential=20 > to address=20 > > some very specific scenarios that need a detailed attention by the=20 > > receiver and most probably a reply after processing the revocation=20 > > indication message. Overloading a generic notification=20 > (fyi) messages=20 > > to handle all of the revocation scenarios is similar to=20 > trying to fit=20 > > an elephant in a refrigerator :) > >=20 > > IMO, the generic notification (fyi) messages would quite=20 > restrict and=20 > > limit the revocation mechanism potential to address many immanent=20 > > scenarios that will evolve due to the interaction of MIP6=20 > and PMIPv6=20 > > when deployed over the heterogeneous nature of the mobile=20 > IP network=20 > > at large. > >=20 > > I strongly believe that the revocation mechanism introduced in the=20 > > Binding Revocation draft needs to be addressed separately from the=20 > > notification (fyi) messages proposed by draft-haley. > >=20 > >=20 > > Regards, > > Ahmad > > =20 > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Wednesday, May 30, 2007 12:19 PM > >> To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org > >> Subject: Re: [Mip6] FW: I-D > >> ACTION:draft-muhanna-mip6-binding-revocation-00.txt > >>=20 > >>=20 > >> Ahmad, > >>=20 > >> Binding revocation is a useful feature. > >> However, we have a I-D: Mobility Header Signaling Message=20 > >> which can be used=20 > as the means=20 > >> for binding revocation as well. > >>=20 > >> In Prague, we discussed this I-D and agreed to consider it as a WG=20 > >> document. > >>=20 > >> -Raj > >>=20 > >>=20 > >> On 5/28/07 7:43 AM, "ext Ahmad Muhanna"=20 > wrote: > >>=20 > >>> =20 > >>> Hello Folks, > >>>=20 > >>> We submitted this draft for Binding Revocation for IPv6 > >> Mobility. It > >>> handles several use cases which are applicable to Client > >> Mobile IPv6 > >>> and PMIPv6. Please take a look and we appreciate your comments. > >>>=20 > >>> Thanks in advance. > >>>=20 > >>> Regards, > >>> Ahmad Muhanna > >>>=20 > >>> -----Original Message----- > >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>> Sent: Friday, May 25, 2007 2:50 PM > >>> To: i-d-announce@ietf.org > >>> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt > >>>=20 > >>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > >>> directories. > >>>=20 > >>>=20 > >>> Title : Binding Revocation for IPv6 Mobility > >>> Author(s) : A. Muhanna, et al. > >>> Filename : draft-muhanna-mip6-binding-revocation-00.txt > >>> Pages : 18 > >>> Date : 2007-5-25 > >>>=20 > >>> The service binding revocation semantics are missing in > >> Mobile IPv6 > >>> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document > >>> defines the semantics of the revocation of a mobile node > >> registration > >>> binding, which could have been established using a > >> Client Mobile IPv6 > >>> or a Proxy Mobile IPv6 signaling. The proposed > >> revocation mechanism > >>> uses generic message properties which is applicable to > >> Mobile IPv6 > >>> and Proxy Mobile IPv6 and can be used by any two > >> mobility entities. > >>> As an example, this mechanism allows local mobility > >> agent, involved > >>> in providing IP mobility services to a mobile node, to=20 > notify the > >>> mobility access gateway of the termination of the mobile node > >>> registration. > >>>=20 > >>>=20 > >>>=20 > >>> A URL for this Internet-Draft is: > >>>=20 > >>=20 > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revoca > >> t > >>> io > >>> n-00.txt > >>>=20 > >>> To remove yourself from the I-D Announcement list, send a > >> message to > >>> i-d-announce-request@ietf.org with the word unsubscribe in > >> the body of > >>> the message. > >>> You can also visit > >> https://www1.ietf.org/mailman/listinfo/I-D-announce > >>> to change your subscription settings. > >>>=20 > >>> Internet-Drafts are also available by anonymous FTP.=20 > Login with the=20 > >>> username "anonymous" and a password of your e-mail address. After=20 > >>> logging in, type "cd internet-drafts" and then "get=20 > >>> draft-muhanna-mip6-binding-revocation-00.txt". > >>>=20 > >>> A list of Internet-Drafts directories can be found in=20 > >>> http://www.ietf.org/shadow.html or=20 > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>=20 > >>> Internet-Drafts can also be obtained by e-mail. > >>>=20 > >>> Send a message to: > >>> mailserv@ietf.org. > >>> In the body type: > >>> "FILE > >>> /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". > >>>=20 > >>> NOTE: The mail server at ietf.org can return the document in=20 > >>> MIME-encoded form by using the "mpack" utility. To use > >> this feature, > >>> insert the command "ENCODING mime" before the "FILE" > >>> command. To decode the response(s), you will need "munpack" or a=20 > >>> MIME-compliant mail reader. Different MIME-compliant=20 > mail readers=20 > >>> exhibit different behavior, especially when dealing with > >> "multipart"=20 > >>> MIME messages (i.e. documents which have been split up into > >> multiple > >>> messages), so check your local documentation on how to manipulate=20 > >>> these messages. > >>>=20 > >>> Below is the data which will enable a MIME compliant mail reader=20 > >>> implementation to automatically retrieve the ASCII version of the=20 > >>> Internet-Draft. > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >>=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed May 30 17:40:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVuW-0001C4-40; Wed, 30 May 2007 17:40:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVuV-0001Bz-NO for mip6@ietf.org; Wed, 30 May 2007 17:40:51 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtVuV-0002V4-Ae for mip6@ietf.org; Wed, 30 May 2007 17:40:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 0855790022 for ; Wed, 30 May 2007 17:40:48 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32155-01 for ; Wed, 30 May 2007 17:40:47 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 30 May 2007 17:40:46 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 17:40:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Wed, 30 May 2007 17:40:44 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA0C8@exchtewks2.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sACIZQUA== From: "Chowdhury, Kuntal" To: "Basavaraj Patil" , "ext Ahmad Muhanna" , X-OriginalArrivalTime: 30 May 2007 21:40:48.0538 (UTC) FILETIME=[2FCA87A0:01C7A303] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I think the confusion is regarding the scope of the two documents.=20 I think the scope of I-D: mh-signaling is quite generic with many uses cases as described in that document. Besides the uses cases that are described in that document there may be other use cases that are deployment specific. That's why I would consider this document to have a generic scope with opaque container to accommodate many uses cases. No response from the receiver is mandated in this mechanism. The scope of I-D: binding-revocation is very specific i.e. revoke the mobility binding with the MN, HA, (and MAG, LMA). The use cases for this mechanism are specific as well. A response from the receiver is mandated in some cases in this mechanism.=20 So, I think we should agree on the scope of these two documents and progress both of them through the IETF process. BR, Kuntal > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Wednesday, May 30, 2007 12:19 PM > To: ext Ahmad Muhanna; mip6@ietf.org > Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation- > 00.txt >=20 >=20 > Ahmad, >=20 > Binding revocation is a useful feature. > However, we have a I-D: Mobility Header Signaling Message > which can be used as the means for > binding revocation as well. >=20 > In Prague, we discussed this I-D and agreed to consider it as a WG > document. >=20 > -Raj >=20 >=20 > On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: >=20 > > > > Hello Folks, > > > > We submitted this draft for Binding Revocation for IPv6 Mobility. It > > handles several use cases which are applicable to Client Mobile IPv6 and > > PMIPv6. Please take a look and we appreciate your comments. > > > > Thanks in advance. > > > > Regards, > > Ahmad Muhanna > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, May 25, 2007 2:50 PM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Binding Revocation for IPv6 Mobility > > Author(s) : A. Muhanna, et al. > > Filename : draft-muhanna-mip6-binding-revocation-00.txt > > Pages : 18 > > Date : 2007-5-25 > > > > The service binding revocation semantics are missing in Mobile IPv6 > > Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document > > defines the semantics of the revocation of a mobile node registration > > binding, which could have been established using a Client Mobile IPv6 > > or a Proxy Mobile IPv6 signaling. The proposed revocation mechanism > > uses generic message properties which is applicable to Mobile IPv6 > > and Proxy Mobile IPv6 and can be used by any two mobility entities. > > As an example, this mechanism allows local mobility agent, involved > > in providing IP mobility services to a mobile node, to notify the > > mobility access gateway of the termination of the mobile node > > registration. > > > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio > > n-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-muhanna-mip6-binding-revocation-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > > /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > 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 From mip6-bounces@ietf.org Wed May 30 18:27:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWdL-0002Ed-GG; Wed, 30 May 2007 18:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWdK-0002EY-Bb for mip6@ietf.org; Wed, 30 May 2007 18:27:10 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtWdI-0000vC-Jb for mip6@ietf.org; Wed, 30 May 2007 18:27:10 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UMQwj2008080; Thu, 31 May 2007 01:27:06 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 01:27:02 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 17:26:59 -0500 Received: from 10.241.59.148 ([10.241.59.148]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2007 22:26:59 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 30 May 2007 17:26:58 -0500 Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt From: Basavaraj Patil To: "Chowdhury, Kuntal" , ext Ahmad Muhanna , Message-ID: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sACIZQUAACN7Jp In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA0C8$0001@exchtewks2.starentnetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 May 2007 22:26:59.0302 (UTC) FILETIME=[A34B9060:01C7A309] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kuntal, I agree that the mh-signaling draft is generic. But my point is that we could utilize such a generic signaling mechanism as the means to solve some of the issues such as binding revocation in addition to the examples that the I-D provides from an applicability perspective. I guess the argument here is that binding revocation is special type of signaling that needs to be specified in new messages and cannot be addressed by the mh-signaling draft. This is the point that I am not convinced about. If we have good arguments that the generic signaling mechanism is inadequate, we can specify binding revocation separately. I guess one argument is the fact that no ack is required as per the mh-signaling I-D. Some example scenarios why the mh-signaling message is not apt for binding revocations would help. -Raj On 5/30/07 4:40 PM, "ext Chowdhury, Kuntal" wrote: > Hi Raj, > > I think the confusion is regarding the scope of the two documents. > > I think the scope of I-D: mh-signaling is quite generic with many uses > cases as described in that document. Besides the uses cases that are > described in that document there may be other use cases that are > deployment specific. That's why I would consider this document to have a > generic scope with opaque container to accommodate many uses cases. No > response from the receiver is mandated in this mechanism. > > The scope of I-D: binding-revocation is very specific i.e. revoke the > mobility binding with the MN, HA, (and MAG, LMA). The use cases for this > mechanism are specific as well. A response from the receiver is mandated > in some cases in this mechanism. > > So, I think we should agree on the scope of these two documents and > progress both of them through the IETF process. > > BR, > Kuntal > > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Wednesday, May 30, 2007 12:19 PM >> To: ext Ahmad Muhanna; mip6@ietf.org >> Subject: Re: [Mip6] FW: I-D > ACTION:draft-muhanna-mip6-binding-revocation- >> 00.txt >> >> >> Ahmad, >> >> Binding revocation is a useful feature. >> However, we have a I-D: Mobility Header Signaling Message >> which can be used as the means > for >> binding revocation as well. >> >> In Prague, we discussed this I-D and agreed to consider it as a WG >> document. >> >> -Raj >> >> >> On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: >> >>> >>> Hello Folks, >>> >>> We submitted this draft for Binding Revocation for IPv6 Mobility. It >>> handles several use cases which are applicable to Client Mobile IPv6 > and >>> PMIPv6. Please take a look and we appreciate your comments. >>> >>> Thanks in advance. >>> >>> Regards, >>> Ahmad Muhanna >>> >>> -----Original Message----- >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>> Sent: Friday, May 25, 2007 2:50 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Binding Revocation for IPv6 Mobility >>> Author(s) : A. Muhanna, et al. >>> Filename : draft-muhanna-mip6-binding-revocation-00.txt >>> Pages : 18 >>> Date : 2007-5-25 >>> >>> The service binding revocation semantics are missing in Mobile > IPv6 >>> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document >>> defines the semantics of the revocation of a mobile node > registration >>> binding, which could have been established using a Client Mobile > IPv6 >>> or a Proxy Mobile IPv6 signaling. The proposed revocation > mechanism >>> uses generic message properties which is applicable to Mobile > IPv6 >>> and Proxy Mobile IPv6 and can be used by any two mobility > entities. >>> As an example, this mechanism allows local mobility agent, > involved >>> in providing IP mobility services to a mobile node, to notify the >>> mobility access gateway of the termination of the mobile node >>> registration. >>> >>> >>> >>> A URL for this Internet-Draft is: >>> > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio >>> n-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body > of >>> the message. >>> You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then >>> "get draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE >>> /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >>> readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> _______________________________________________ >>> 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 > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to create > or change any contractual obligations of Starent Networks, Corp. Any review, > retransmission, dissemination or other use of, or taking of any action in > reliance upon this e-mail and its attachments by persons or entities other > than the intended recipient is prohibited. If you are not the intended > recipient, please notify the sender immediately -- by replying to this message > or by sending an email to postmaster@starentnetworks.com -- and destroy all > copies of this message and any attachments without reading or disclosing their > contents. Thank you." _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 08:14:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjXz-0005hA-6C; Thu, 31 May 2007 08:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjXx-0005gv-9N for mip6@ietf.org; Thu, 31 May 2007 08:14:29 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtjXt-0005c7-R4 for mip6@ietf.org; Thu, 31 May 2007 08:14:29 -0400 Received: from oaamta05sl.mx.bigpond.com ([124.191.178.123]) by omta05sl.mx.bigpond.com with ESMTP id <20070531121422.TNBO25724.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com> for ; Thu, 31 May 2007 12:14:22 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta05sl.mx.bigpond.com with ESMTP id <20070531121421.ZABQ7523.oaamta05sl.mx.bigpond.com@PC20005> for ; Thu, 31 May 2007 12:14:21 +0000 From: "Hesham Soliman" To: Date: Thu, 31 May 2007 22:14:16 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcecRbsokSU7vAwVSO2HbFAk58EAoACi9jdQASrVsZA= Message-Id: <20070531121421.ZABQ7523.oaamta05sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Mip6] FW: FW: DISCUSS: draft-ietf-mip6-dsmip-problem X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Folks, George and I discussed this issue with the chairs, AD and Brian. We're all happpy to go with Brian's text recommendations below. Since no one commented before I assume this is ok. Thanks, Hesham >>> As far as this draft goes, if the recommendation to do >>> both is the consensus of the MIP6 WG, I'd be satisfied with >>> a text change in section 5 that would make it clear >>> that this is not an IETF consensus. For example >>> >>> OLD >>> In order to allow for a gradual transition based on >>> current standards >>> and deployment, the following work areas seem to be reasonable: >>> >>> NEW >>> The Mobile IPv6 Working Group has reached the view that to allow >>> for a gradual transition based on current standards and >>> deployment, >>> the following work areas would be reasonable: >>> >>> and >>> OLD >>> Following the steps listed above, a vendor can choose to >>> support one >>> mobility management protocol while avoiding the >>> incompatibility and >>> inefficiency problems listed in this document. >>> Similarly, operators >>> can decide to continue using one mobility management >>> protocol while >>> addressing the transition scenarios that a mobile node is >>> likely to >>> face when roaming within the Internet. >>> >>> NEW >>> If the IETF chooses to pursue all these paths, a vendor >>> could choose >>> to support one mobility management protocol while avoiding the >>> incompatibility and inefficiency problems listed in this document. >>> Similarly, operators could decide to continue using one mobility >>> management protocol throughout the period of IPv4 and >>> IPv6 coexistence. >>> However, a mobile node would be forced to choose one approach >>> or the other, or nevertheless to install both and use one or >>> the other according to circumstances. >>> >>> >>> >> > > ------ End of Forwarded Message > -- NEW: Preferred email for non-IBM matters: brian.e.carpenter@gmail.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 11:01:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htm95-0003lz-Fi; Thu, 31 May 2007 11:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htm94-0003lq-9b for mip6@ietf.org; Thu, 31 May 2007 11:00:58 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htm92-0000fM-Nq for mip6@ietf.org; Thu, 31 May 2007 11:00:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 3001E90030 for ; Thu, 31 May 2007 11:00:53 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15824-17 for ; Thu, 31 May 2007 11:00:50 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 31 May 2007 11:00:50 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 11:00:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Thu, 31 May 2007 11:00:47 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA0CF@exchtewks2.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sACIZQUAACN7JpACJEfuA= From: "Chowdhury, Kuntal" To: "Basavaraj Patil" , "ext Ahmad Muhanna" , X-OriginalArrivalTime: 31 May 2007 15:00:51.0663 (UTC) FILETIME=[7AF3BDF0:01C7A394] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, The revocation procedure that we proposed can be defined using the mh-signaling message framework. In order to do that, we have to embed the revocation message as a sub-type (or something like that) of the Mobility Header type.=20 Embedding a message within another message is not a clean design, IMHO. I think the scope of the two documents should be left as is: Mh-signaling message: sending opaque TLVs Revocation message: revoke mobility binding -Kuntal > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Wednesday, May 30, 2007 5:27 PM > To: Chowdhury, Kuntal; ext Ahmad Muhanna; mip6@ietf.org > Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation- > 00.txt >=20 >=20 > Hi Kuntal, >=20 > I agree that the mh-signaling draft is generic. But my point is that we > could utilize such a generic signaling mechanism as the means to solve > some > of the issues such as binding revocation in addition to the examples that > the I-D provides from an applicability perspective. > I guess the argument here is that binding revocation is special type of > signaling that needs to be specified in new messages and cannot be > addressed > by the mh-signaling draft. > This is the point that I am not convinced about. >=20 > If we have good arguments that the generic signaling mechanism is > inadequate, we can specify binding revocation separately. I guess one > argument is the fact that no ack is required as per the mh-signaling I-D. >=20 > Some example scenarios why the mh-signaling message is not apt for binding > revocations would help. >=20 > -Raj >=20 >=20 > On 5/30/07 4:40 PM, "ext Chowdhury, Kuntal" > > wrote: >=20 > > Hi Raj, > > > > I think the confusion is regarding the scope of the two documents. > > > > I think the scope of I-D: mh-signaling is quite generic with many uses > > cases as described in that document. Besides the uses cases that are > > described in that document there may be other use cases that are > > deployment specific. That's why I would consider this document to have a > > generic scope with opaque container to accommodate many uses cases. No > > response from the receiver is mandated in this mechanism. > > > > The scope of I-D: binding-revocation is very specific i.e. revoke the > > mobility binding with the MN, HA, (and MAG, LMA). The use cases for this > > mechanism are specific as well. A response from the receiver is mandated > > in some cases in this mechanism. > > > > So, I think we should agree on the scope of these two documents and > > progress both of them through the IETF process. > > > > BR, > > Kuntal > > > > > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Wednesday, May 30, 2007 12:19 PM > >> To: ext Ahmad Muhanna; mip6@ietf.org > >> Subject: Re: [Mip6] FW: I-D > > ACTION:draft-muhanna-mip6-binding-revocation- > >> 00.txt > >> > >> > >> Ahmad, > >> > >> Binding revocation is a useful feature. > >> However, we have a I-D: Mobility Header Signaling Message > >> which can be used as the means > > for > >> binding revocation as well. > >> > >> In Prague, we discussed this I-D and agreed to consider it as a WG > >> document. > >> > >> -Raj > >> > >> > >> On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: > >> > >>> > >>> Hello Folks, > >>> > >>> We submitted this draft for Binding Revocation for IPv6 Mobility. It > >>> handles several use cases which are applicable to Client Mobile IPv6 > > and > >>> PMIPv6. Please take a look and we appreciate your comments. > >>> > >>> Thanks in advance. > >>> > >>> Regards, > >>> Ahmad Muhanna > >>> > >>> -----Original Message----- > >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>> Sent: Friday, May 25, 2007 2:50 PM > >>> To: i-d-announce@ietf.org > >>> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> > >>> > >>> Title : Binding Revocation for IPv6 Mobility > >>> Author(s) : A. Muhanna, et al. > >>> Filename : draft-muhanna-mip6-binding-revocation-00.txt > >>> Pages : 18 > >>> Date : 2007-5-25 > >>> > >>> The service binding revocation semantics are missing in Mobile > > IPv6 > >>> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document > >>> defines the semantics of the revocation of a mobile node > > registration > >>> binding, which could have been established using a Client Mobile > > IPv6 > >>> or a Proxy Mobile IPv6 signaling. The proposed revocation > > mechanism > >>> uses generic message properties which is applicable to Mobile > > IPv6 > >>> and Proxy Mobile IPv6 and can be used by any two mobility > > entities. > >>> As an example, this mechanism allows local mobility agent, > > involved > >>> in providing IP mobility services to a mobile node, to notify the > >>> mobility access gateway of the termination of the mobile node > >>> registration. > >>> > >>> > >>> > >>> A URL for this Internet-Draft is: > >>> > > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio > >>> n-00.txt > >>> > >>> To remove yourself from the I-D Announcement list, send a message to > >>> i-d-announce-request@ietf.org with the word unsubscribe in the body > > of > >>> the message. > >>> You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > >>> to change your subscription settings. > >>> > >>> Internet-Drafts are also available by anonymous FTP. Login with the > >>> username "anonymous" and a password of your e-mail address. After > >>> logging in, type "cd internet-drafts" and then > >>> "get draft-muhanna-mip6-binding-revocation-00.txt". > >>> > >>> A list of Internet-Drafts directories can be found in > >>> http://www.ietf.org/shadow.html > >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >>> Internet-Drafts can also be obtained by e-mail. > >>> > >>> Send a message to: > >>> mailserv@ietf.org. > >>> In the body type: > >>> "FILE > >>> /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". > >>> > >>> NOTE: The mail server at ietf.org can return the document in > >>> MIME-encoded form by using the "mpack" utility. To use this > >>> feature, insert the command "ENCODING mime" before the "FILE" > >>> command. To decode the response(s), you will need "munpack" or > >>> a MIME-compliant mail reader. Different MIME-compliant mail > >>> readers > >>> exhibit different behavior, especially when dealing with > >>> "multipart" MIME messages (i.e. documents which have been split > >>> up into multiple messages), so check your local documentation on > >>> how to manipulate these messages. > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of the > >>> Internet-Draft. > >>> _______________________________________________ > >>> 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 > > > > > > "This email message and any attachments are confidential information of > > Starent Networks, Corp. The information transmitted may not be used to > create > > or change any contractual obligations of Starent Networks, Corp. Any > review, > > retransmission, dissemination or other use of, or taking of any action > in > > reliance upon this e-mail and its attachments by persons or entities > other > > than the intended recipient is prohibited. If you are not the intended > > recipient, please notify the sender immediately -- by replying to this > message > > or by sending an email to postmaster@starentnetworks.com -- and destroy > all > > copies of this message and any attachments without reading or disclosing > their > > contents. Thank you." _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 11:56:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn19-00034H-06; Thu, 31 May 2007 11:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn17-00033B-Tc for mip6@ietf.org; Thu, 31 May 2007 11:56:49 -0400 Received: from mxs2.siemens.at ([194.138.12.133] helo=atvies1zrx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htn13-0005dG-UZ for mip6@ietf.org; Thu, 31 May 2007 11:56:49 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by atvies1zrx.siemens.at with ESMTP id l4VFuiqA016463; Thu, 31 May 2007 17:56:44 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l4VFugfk018707; Thu, 31 May 2007 17:56:43 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 17:56:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] I-D ACTION:draft-ietf-mip6-hiopt-03.txt Date: Thu, 31 May 2007 17:56:33 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6802217E44@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-03.txt Thread-Index: AceX9GUlITHdgpWQReGk2NyvBa7vlwLor+rg References: From: "Premec, Domagoj" To: "Heejin Jang" X-OriginalArrivalTime: 31 May 2007 15:56:42.0619 (UTC) FILETIME=[48470CB0:01C7A39C] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070531175644-0AAF4BB0-2CAFEAFF/0-0/0-15 X-purgate-size: 3809/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Heejin, I have a clarification question: if the MN requests information about = several target networks it will include several Home Network Identifier = options. The following text=20 > Multiple sub-options may exist in a Home Network Information option > to carry more than one home information. leaves impression that the response message contains only one Home = Network Information option which carries the addresses, prefixes and/or = FQDNs of all target networks. I could be wrong, but I couldn't find any = text that is specific about this.=20 If the information about multiple target networks is carried in a single = Home Network Information option, the MN may not be able to match the = info from the Home Network Information option to a particular target = network. For example, the MN may ask for infomation about operator1.com = and operator2.com, and the Home Network Information option may contain = the home subnet prefix and the FQDN. How would the MN know if both = suboptions carry information about operator1.com or if subnet belongs to = operator1 and FQDN to operator 2? thanks domagoj > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: 16. svibanj 2007 21:50 > To: i-d-announce@ietf.org > Cc: mip6@ietf.org > Subject: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-03.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Mobility for IPv6 Working=20 > Group of the IETF. >=20 > Title : DHCP Option for Home Information=20 > Discovery in MIPv6 > Author(s) : H. Jang, et al. > Filename : draft-ietf-mip6-hiopt-03.txt > Pages : 19 > Date : 2007-5-16 > =09 > This draft defines a DHCP-based scheme to enable dynamic discovery of > Mobile IPv6 home agent address, home agent FQDN and home=20 > subnet. New > DHCP options are defined to carry the information from a=20 > DHCP server > to the DHCP client running on the mobile node. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-03.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-mip6-hiopt-03.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip6-hiopt-03.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 11:58:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn2t-0003gK-Nt; Thu, 31 May 2007 11:58:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn2r-0003dy-LI for mip6@ietf.org; Thu, 31 May 2007 11:58:37 -0400 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htn2q-0006Iq-7c for mip6@ietf.org; Thu, 31 May 2007 11:58:37 -0400 Received: from smtp1.fc.hp.com (smtp.cnd.hp.com [15.15.136.127]) by atlrel9.hp.com (Postfix) with ESMTP id A47473558E; Thu, 31 May 2007 11:58:32 -0400 (EDT) Received: from [16.116.112.53] (wrx.zko.hp.com [16.116.112.53]) by smtp1.fc.hp.com (Postfix) with ESMTP id 22783142E67; Thu, 31 May 2007 15:58:32 +0000 (UTC) Message-ID: <465EF0A7.4040907@hp.com> Date: Thu, 31 May 2007 11:58:31 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt References: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711495AB8A@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711495AB8A@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ahmad, Ahmad Muhanna wrote: > Hi Raj, > > If I remember correctly, since no new options were defined by the > draft-haley, a question was asked about the scope of the notification > messages and it was mentioned, Opaque. > > IMO, the draft-haley is intended for sending a generic notification > (fyi) messages, where detailed receiver action is not required and does > not need to be specified. The common use cases include, expiry of > prepaid billing, service outage related notifications, new promotional > information. The generic notification message is a delivery mechanism, the receiver action for the opaque data within is up to that draft to define. In Mobile IPv4, the generic notification message (draft-ietf-mip4-generic-notification-message-00.txt) does mention binding revocation. > Revocation is a detailed topic which handles many scenarios and use > cases addressing both NetLMM and MIP6 scope with potential to address > some very specific scenarios that need a detailed attention by the > receiver and most probably a reply after processing the revocation > indication message. Overloading a generic notification (fyi) messages to > handle all of the revocation scenarios is similar to trying to fit an > elephant in a refrigerator :) draft-haley-mip6-mh-signaling-02.txt does have Acknowledge support, so repying isn't a problem. > IMO, the generic notification (fyi) messages would quite restrict and > limit the revocation mechanism potential to address many immanent > scenarios that will evolve due to the interaction of MIP6 and PMIPv6 > when deployed over the heterogeneous nature of the mobile IP network at > large. > > I strongly believe that the revocation mechanism introduced in the > Binding Revocation draft needs to be addressed separately from the > notification (fyi) messages proposed by draft-haley. I won't disagree that binding revocation could be a very complex task when you involve many of the possible mobility scenarios. But the protocol in draft-muhanna seems pretty simple. Do you think that having multiple layers of mobility options just makes it too difficult? I could see if you had a generic notification message, with a revocation option inside, with additional "session" options, that might be a little confusing, but I don't think it's a show-stopper. Noone even mentioned the extra bytes over the air, I figured that would be the first complaint :) -Brian >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Wednesday, May 30, 2007 12:19 PM >> To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org >> Subject: Re: [Mip6] FW: I-D >> ACTION:draft-muhanna-mip6-binding-revocation-00.txt >> >> >> Ahmad, >> >> Binding revocation is a useful feature. >> However, we have a I-D: Mobility Header Signaling Message >> which can be used as >> the means for binding revocation as well. >> >> In Prague, we discussed this I-D and agreed to consider it as >> a WG document. >> >> -Raj >> >> >> On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: >> >>> >>> Hello Folks, >>> >>> We submitted this draft for Binding Revocation for IPv6 >> Mobility. It >>> handles several use cases which are applicable to Client >> Mobile IPv6 >>> and PMIPv6. Please take a look and we appreciate your comments. >>> >>> Thanks in advance. >>> >>> Regards, >>> Ahmad Muhanna >>> >>> -----Original Message----- >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>> Sent: Friday, May 25, 2007 2:50 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Binding Revocation for IPv6 Mobility >>> Author(s) : A. Muhanna, et al. >>> Filename : draft-muhanna-mip6-binding-revocation-00.txt >>> Pages : 18 >>> Date : 2007-5-25 >>> >>> The service binding revocation semantics are missing in >> Mobile IPv6 >>> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document >>> defines the semantics of the revocation of a mobile node >> registration >>> binding, which could have been established using a >> Client Mobile IPv6 >>> or a Proxy Mobile IPv6 signaling. The proposed >> revocation mechanism >>> uses generic message properties which is applicable to >> Mobile IPv6 >>> and Proxy Mobile IPv6 and can be used by any two >> mobility entities. >>> As an example, this mechanism allows local mobility >> agent, involved >>> in providing IP mobility services to a mobile node, to notify the >>> mobility access gateway of the termination of the mobile node >>> registration. >>> >>> >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocat >>> io >>> n-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a >> message to >>> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >>> the message. >>> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then "get >>> draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE >>> /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use >> this feature, >>> insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or a >>> MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >> "multipart" >>> MIME messages (i.e. documents which have been split up into >> multiple >>> messages), so check your local documentation on how to manipulate >>> these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> _______________________________________________ >>> 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 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 12:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn4N-00058F-Qf; Thu, 31 May 2007 12:00:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn4G-00056S-Qo for mip6@ietf.org; Thu, 31 May 2007 12:00:05 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htn4G-0007IH-6l for mip6@ietf.org; Thu, 31 May 2007 12:00:04 -0400 Received: from smtp2.fc.hp.com (smtp2.fc.hp.com [15.11.136.114]) by atlrel6.hp.com (Postfix) with ESMTP id 7F2013535B; Thu, 31 May 2007 12:00:03 -0400 (EDT) Received: from [16.116.112.53] (wrx.zko.hp.com [16.116.112.53]) by smtp2.fc.hp.com (Postfix) with ESMTP id D9101189461; Thu, 31 May 2007 16:00:02 +0000 (UTC) Message-ID: <465EF102.4030302@hp.com> Date: Thu, 31 May 2007 12:00:02 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Mohamed Khalil Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt References: <62B9B0847CC47543B6B3B5E26BD268E60B5F6C37@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F6C37@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Mohamed, Mohamed Khalil wrote: > Hi Raj, > > If we include revocation protocol in information options, we will end up > with three levels of protocol complexity as follows: > > 1- The Information option Request message. > 2- The information option containing the revocation request, let us call > it revocation option. > 3- the revocation attributes, or sub-options. How often do you think additional attributes/sub-options will be present? In every message? Will they be defined in a -02 version of the draft or is that something for another draft? -Brian > This means that the revocation option needs to be structured very much > similarly to the Binding Revocation Indication message, as per Binding > Revocation draft, where it has to carry all possible options as > sub-options. This simply a control protocol imbedded inside another one > which introduce unnecessary complexity. > > If we don't have this container mechanism, the process is simple. > > 1- The revocation protocol request message. > 2- The revocation related options. > > Regards > > Mohamed > > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Wednesday, May 30, 2007 3:24 PM > To: Khalil, Mohamed (RICH2:2S20); mip6@ietf.org > Subject: Re: [Mip6] FW: I-D > ACTION:draft-muhanna-mip6-binding-revocation-00.txt > > > > MK, > > I don't think anyone is designing a new protocol here. In MIP6 we have a > protocol (RFC3775) and are now extending it for meeting some of the > requirements which would enable deployment and adding a few new limited > features. > > The mobility header signaling message is a generic extension that can be > used for various purposes as indicated in the draft itself. To me > binding revocation is merely another notification. I don't understand > what complexities you are refering to below or processing issue. > > Can you clarify why the binding revocation cannot be solved by the > specification of an option in the mobility header signaling message? > > -Raj > > > On 5/30/07 2:41 PM, "ext Mohamed Khalil" wrote: > >> Hi Raj, >> >> I strongly disagree on the idea of designing a protocol which is used >> as a container for other protocols. Each protocol should have a >> limited scope and designed according to certain requirements. It is >> very difficult to design a generic protocol which satisfy all the >> requirements for all future protocols. This container idea has many >> issues, the simplest is that it increases, unnecessarily, the >> processing time for the contained protocol (e.g. revocation). In >> addition there some situations where a simple Request/Reply will not >> be enough to do the job. Let us leave each protocol designer(s) to do >> what it is required to do and don't limit their thinking. >> >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Wednesday, May 30, 2007 12:19 PM >> To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org >> Subject: Re: [Mip6] FW: I-D >> ACTION:draft-muhanna-mip6-binding-revocation-00.txt >> >> >> >> Ahmad, >> >> Binding revocation is a useful feature. >> However, we have a I-D: Mobility Header Signaling Message >> which can be used as the means >> for binding revocation as well. >> >> In Prague, we discussed this I-D and agreed to consider it as a WG >> document. >> >> -Raj >> >> >> On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: >> >>> >>> Hello Folks, >>> >>> We submitted this draft for Binding Revocation for IPv6 Mobility. It >>> handles several use cases which are applicable to Client Mobile IPv6 >>> and PMIPv6. Please take a look and we appreciate your comments. >>> >>> Thanks in advance. >>> >>> Regards, >>> Ahmad Muhanna >>> >>> -----Original Message----- >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>> Sent: Friday, May 25, 2007 2:50 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Binding Revocation for IPv6 Mobility >>> Author(s) : A. Muhanna, et al. >>> Filename : draft-muhanna-mip6-binding-revocation-00.txt >>> Pages : 18 >>> Date : 2007-5-25 >>> >>> The service binding revocation semantics are missing in Mobile > IPv6 >>> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document >>> defines the semantics of the revocation of a mobile node >> registration >>> binding, which could have been established using a Client Mobile >> IPv6 >>> or a Proxy Mobile IPv6 signaling. The proposed revocation >> mechanism >>> uses generic message properties which is applicable to Mobile IPv6 >>> and Proxy Mobile IPv6 and can be used by any two mobility > entities. >>> As an example, this mechanism allows local mobility agent, > involved >>> in providing IP mobility services to a mobile node, to notify the >>> mobility access gateway of the termination of the mobile node >>> registration. >>> >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revoca >>> t >>> io >>> n-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body >>> of >>> the message. You can also visit >>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then "get >>> draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this feature, > >>> insert the command "ENCODING mime" before the "FILE" command. To >>> decode the response(s), you will need "munpack" or a MIME-compliant >>> mail reader. Different MIME-compliant mail readers exhibit different > >>> behavior, especially when dealing with "multipart" MIME messages >>> (i.e. documents which have been split up into multiple messages), so >>> check your local documentation on how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 12:52:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htnt4-0002tw-Rm; Thu, 31 May 2007 12:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htnt3-0002tr-4B for mip6@ietf.org; Thu, 31 May 2007 12:52:33 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htnt1-0005Lf-Rq for mip6@ietf.org; Thu, 31 May 2007 12:52:33 -0400 Received: from smtp1.fc.hp.com (smtp.cnd.hp.com [15.15.136.127]) by atlrel6.hp.com (Postfix) with ESMTP id 3C9EE34A00; Thu, 31 May 2007 12:52:27 -0400 (EDT) Received: from [16.116.112.53] (wrx.zko.hp.com [16.116.112.53]) by smtp1.fc.hp.com (Postfix) with ESMTP id 9901F142FAF; Thu, 31 May 2007 16:52:27 +0000 (UTC) Message-ID: <465EFD4B.6010802@hp.com> Date: Thu, 31 May 2007 12:52:27 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt References: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711495AB8A@zrc2hxm2.corp.nortel.com> <465EF0A7.4040907@hp.com> In-Reply-To: <465EF0A7.4040907@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Brian Haley wrote: >> IMO, the draft-haley is intended for sending a generic notification >> (fyi) messages, where detailed receiver action is not required and does >> not need to be specified. The common use cases include, expiry of >> prepaid billing, service outage related notifications, new promotional >> information. > > The generic notification message is a delivery mechanism, the receiver > action for the opaque data within is up to that draft to define. In > Mobile IPv4, the generic notification message > (draft-ietf-mip4-generic-notification-message-00.txt) does mention > binding revocation. Correction. It was pointed out to me that RFC 3543 is for Mip4 registration revocation. So maybe that set a precedence to do this separately? -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 13:23:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtoMh-0003NL-VW; Thu, 31 May 2007 13:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtoMh-0003NG-Gw for mip6@ietf.org; Thu, 31 May 2007 13:23:11 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtoMg-0007e9-2E for mip6@ietf.org; Thu, 31 May 2007 13:23:11 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4VHMm8w003221; Thu, 31 May 2007 20:23:03 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 20:22:53 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 12:22:38 -0500 Received: from 172.19.244.164 ([172.19.244.164]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 May 2007 17:22:37 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 31 May 2007 12:22:38 -0500 Subject: Re: [Mip6] FW: FW: DISCUSS: draft-ietf-mip6-dsmip-problem From: Basavaraj Patil To: ext Hesham Soliman , Message-ID: Thread-Topic: [Mip6] FW: FW: DISCUSS: draft-ietf-mip6-dsmip-problem Thread-Index: AcecRbsokSU7vAwVSO2HbFAk58EAoACi9jdQASrVsZAACteVTQ== In-Reply-To: <20070531121421.ZABQ7523.oaamta05sl.mx.bigpond.com@PC20005> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 May 2007 17:22:38.0370 (UTC) FILETIME=[49583820:01C7A3A8] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I am okay with the proposed way forward. -Raj On 5/31/07 7:14 AM, "ext Hesham Soliman" wrote: > Folks, > > George and I discussed this issue with the chairs, AD and Brian. We're all > happpy to go with Brian's text recommendations below. Since no one commented > before I assume this is ok. > > Thanks, > Hesham > >>>> As far as this draft goes, if the recommendation to do >>>> both is the consensus of the MIP6 WG, I'd be satisfied with >>>> a text change in section 5 that would make it clear >>>> that this is not an IETF consensus. For example >>>> >>>> OLD >>>> In order to allow for a gradual transition based on >>>> current standards >>>> and deployment, the following work areas seem to be reasonable: >>>> >>>> NEW >>>> The Mobile IPv6 Working Group has reached the view that to allow >>>> for a gradual transition based on current standards and >>>> deployment, >>>> the following work areas would be reasonable: >>>> >>>> and >>>> OLD >>>> Following the steps listed above, a vendor can choose to >>>> support one >>>> mobility management protocol while avoiding the >>>> incompatibility and >>>> inefficiency problems listed in this document. >>>> Similarly, operators >>>> can decide to continue using one mobility management >>>> protocol while >>>> addressing the transition scenarios that a mobile node is >>>> likely to >>>> face when roaming within the Internet. >>>> >>>> NEW >>>> If the IETF chooses to pursue all these paths, a vendor >>>> could choose >>>> to support one mobility management protocol while avoiding the >>>> incompatibility and inefficiency problems listed in this document. >>>> Similarly, operators could decide to continue using one mobility >>>> management protocol throughout the period of IPv4 and >>>> IPv6 coexistence. >>>> However, a mobile node would be forced to choose one approach >>>> or the other, or nevertheless to install both and use one or >>>> the other according to circumstances. >>>> >>>> >>>> >>> >> >> ------ End of Forwarded Message >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 13:27:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtoR3-0006zv-6J; Thu, 31 May 2007 13:27:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtoR1-0006vs-QA for mip6@ietf.org; Thu, 31 May 2007 13:27:39 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtoQz-0008Ey-UN for mip6@ietf.org; Thu, 31 May 2007 13:27:39 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4VHRCCB024842; Thu, 31 May 2007 20:27:35 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 20:27:35 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 12:27:32 -0500 Received: from 172.19.244.164 ([172.19.244.164]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 May 2007 17:27:31 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 31 May 2007 12:27:33 -0500 Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt From: Basavaraj Patil To: ext Brian Haley , Ahmad Muhanna Message-ID: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejqPj1N0fHng+cEdyx6wARJNUNiA== In-Reply-To: <465EFD4B.6010802@hp.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 May 2007 17:27:32.0711 (UTC) FILETIME=[F8C91770:01C7A3A8] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On 5/31/07 11:52 AM, "ext Brian Haley" wrote: > Brian Haley wrote: >>> IMO, the draft-haley is intended for sending a generic notification >>> (fyi) messages, where detailed receiver action is not required and does >>> not need to be specified. The common use cases include, expiry of >>> prepaid billing, service outage related notifications, new promotional >>> information. >> >> The generic notification message is a delivery mechanism, the receiver >> action for the opaque data within is up to that draft to define. In >> Mobile IPv4, the generic notification message >> (draft-ietf-mip4-generic-notification-message-00.txt) does mention >> binding revocation. > > Correction. It was pointed out to me that RFC 3543 is for Mip4 > registration revocation. So maybe that set a precedence to do this > separately? Learning from experience of MIP4 is good.... But does not imply that we have to solve the issues in exactly the same way. The binding revocation capability in MIP6 is required. The solution for this can be fairly simple. I don't know what numerous suboptions are being refered to as the reasoning for having a separate message. -Raj > > -Brian > > _______________________________________________ > 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 From mip6-bounces@ietf.org Thu May 31 13:39:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htoc4-00051L-CH; Thu, 31 May 2007 13:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htoc3-000514-KW for mip6@ietf.org; Thu, 31 May 2007 13:39:03 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htoc3-0002z4-Ce for mip6@ietf.org; Thu, 31 May 2007 13:39:03 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4VHd0V08206 for ; Thu, 31 May 2007 17:39:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Thu, 31 May 2007 12:38:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A1445C@zrc2hxm2.corp.nortel.com> In-Reply-To: <465EFD4B.6010802@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejpBfWBA+lufkcRWiCTIdT/qqjfwAADeIA References: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711495AB8A@zrc2hxm2.corp.nortel.com> <465EF0A7.4040907@hp.com> <465EFD4B.6010802@hp.com> From: "Ahmad Muhanna" To: "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian,=20 please see comments inline. Regards, Ahmad =20 > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com]=20 > Sent: Thursday, May 31, 2007 11:52 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mip6@ietf.org > Subject: Re: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 > Brian Haley wrote: > >> IMO, the draft-haley is intended for sending a generic notification > >> (fyi) messages, where detailed receiver action is not required and=20 > >> does not need to be specified. The common use cases=20 > include, expiry=20 > >> of prepaid billing, service outage related notifications, new=20 > >> promotional information. > >=20 > > The generic notification message is a delivery mechanism,=20 > the receiver=20 > > action for the opaque data within is up to that draft to=20 > define. In=20 > > Mobile IPv4, the generic notification message > > (draft-ietf-mip4-generic-notification-message-00.txt) does mention=20 > > binding revocation. >=20 > Correction. It was pointed out to me that RFC 3543 is for=20 > Mip4 registration revocation. So maybe that set a precedence=20 > to do this separately? [Ahmad] I agree.=20 IMO, revocation mechanism is more of a control mechanism than informational. It is similar to the registration messages since it impacts the state of the MN binding and the allocated resources. Having said that, I believe we probably have a couple of options here: Option 1: Is to have the revocation messages stands out as a separate MH type messages. This is similar to what Mobile IPv4 has in RFC3543 and detailed in the Binding Revocation for IPv6 Mobility draft. -OR- Option 2: Since the MH generic message type allows only for options to be defined (in separate drafts) and including all the revocation related information would not be possible in a single option (unless it becomes a message), then a subtype (as the first byte after the MH) can be used to define the type of message that is included in the generic notification message.=20 I still believe that option 1 is the best way to go forward in order to address the revocation mechanism, having in mind that whatever revocation mechanism we propose here needs to be applicable to PMIPv6 too. =20 >=20 > -Brian >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 13:59:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htovp-0008PU-7T; Thu, 31 May 2007 13:59:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htovn-0008PP-Sf for mip6@ietf.org; Thu, 31 May 2007 13:59:28 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htovn-0001Tu-EI for mip6@ietf.org; Thu, 31 May 2007 13:59:27 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4VHxOV13408; Thu, 31 May 2007 17:59:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: ] RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Thu, 31 May 2007 12:59:21 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6C3F@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F6C3D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ] RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejnMSAi+j4WzNyT0G4loaXHjR5ugAAgwwwAAM17zA= From: "Mohamed Khalil" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, please, see my comments -----Original Message----- From: Brian Haley [mailto:brian.haley@hp.com]=20 Sent: Thursday, May 31, 2007 11:00 AM To: Khalil, Mohamed (RICH2:2S20) Cc: Basavaraj Patil; mip6@ietf.org Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Hi Mohamed, Mohamed Khalil wrote: > Hi Raj, >=20 > If we include revocation protocol in information options, we will end > up with three levels of protocol complexity as follows: >=20 > 1- The Information option Request message. > 2- The information option containing the revocation request, let us > call it revocation option. > 3- the revocation attributes, or sub-options. How often do you think additional attributes/sub-options will be=20 present? In every message? Will they be defined in a -02 version of=20 the draft or is that something for another draft? Mohamed>> There are multiple attributes including MNs' NAI(s), network prefix(es) (new or old), IP address(es), time for session to expire etc could be defined by this document or by other documents to specify the behavior of revoked session(s). A multiple of those attributes may be included in each message depending on the revoked session and the status of the network. =20 -Brian > This means that the revocation option needs to be structured very much > similarly to the Binding Revocation Indication message, as per Binding > Revocation draft, where it has to carry all possible options as=20 > sub-options. This simply a control protocol imbedded inside another=20 > one which introduce unnecessary complexity. >=20 > If we don't have this container mechanism, the process is simple. >=20 > 1- The revocation protocol request message. > 2- The revocation related options. >=20 > Regards >=20 > Mohamed >=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Wednesday, May 30, 2007 3:24 PM > To: Khalil, Mohamed (RICH2:2S20); mip6@ietf.org > Subject: Re: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 >=20 >=20 > MK, >=20 > I don't think anyone is designing a new protocol here. In MIP6 we have > a protocol (RFC3775) and are now extending it for meeting some of the=20 > requirements which would enable deployment and adding a few new=20 > limited features. >=20 > The mobility header signaling message is a generic extension that can > be used for various purposes as indicated in the draft itself. To me=20 > binding revocation is merely another notification. I don't understand=20 > what complexities you are refering to below or processing issue. >=20 > Can you clarify why the binding revocation cannot be solved by the > specification of an option in the mobility header signaling message? >=20 > -Raj >=20 >=20 > On 5/30/07 2:41 PM, "ext Mohamed Khalil" wrote: >=20 >> Hi Raj, >> >> I strongly disagree on the idea of designing a protocol which is used >> as a container for other protocols. Each protocol should have a=20 >> limited scope and designed according to certain requirements. It is=20 >> very difficult to design a generic protocol which satisfy all the=20 >> requirements for all future protocols. This container idea has many=20 >> issues, the simplest is that it increases, unnecessarily, the=20 >> processing time for the contained protocol (e.g. revocation). In=20 >> addition there some situations where a simple Request/Reply will not=20 >> be enough to do the job. Let us leave each protocol designer(s) to do >> what it is required to do and don't limit their thinking. >> >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Wednesday, May 30, 2007 12:19 PM >> To: Muhanna, Ahmad (RICH1:2H10); mip6@ietf.org >> Subject: Re: [Mip6] FW: I-D=20 >> ACTION:draft-muhanna-mip6-binding-revocation-00.txt >> >> >> >> Ahmad, >> >> Binding revocation is a useful feature. >> However, we have a I-D: Mobility Header Signaling Message=20 >> which can be used as the means >> for binding revocation as well. >> >> In Prague, we discussed this I-D and agreed to consider it as a WG=20 >> document. >> >> -Raj >> >> >> On 5/28/07 7:43 AM, "ext Ahmad Muhanna" wrote: >> >>> =20 >>> Hello Folks, >>> >>> We submitted this draft for Binding Revocation for IPv6 Mobility. It >>> handles several use cases which are applicable to Client Mobile IPv6 >>> and PMIPv6. Please take a look and we appreciate your comments. >>> >>> Thanks in advance. >>> >>> Regards, >>> Ahmad Muhanna >>> >>> -----Original Message----- >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>> Sent: Friday, May 25, 2007 2:50 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>> directories. >>> >>> >>> Title : Binding Revocation for IPv6 Mobility >>> Author(s) : A. Muhanna, et al. >>> Filename : draft-muhanna-mip6-binding-revocation-00.txt >>> Pages : 18 >>> Date : 2007-5-25 >>> >>> The service binding revocation semantics are missing in Mobile > IPv6 >>> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document >>> defines the semantics of the revocation of a mobile node >> registration >>> binding, which could have been established using a Client Mobile >> IPv6 >>> or a Proxy Mobile IPv6 signaling. The proposed revocation >> mechanism >>> uses generic message properties which is applicable to Mobile IPv6 >>> and Proxy Mobile IPv6 and can be used by any two mobility > entities. >>> As an example, this mechanism allows local mobility agent, > involved >>> in providing IP mobility services to a mobile node, to notify the >>> mobility access gateway of the termination of the mobile node >>> registration. >>> >>> >>> >>> A URL for this Internet-Draft is:=20 >>> http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revoc >>> a >>> t >>> io >>> n-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body=20 >>> of the message. You can also visit >>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the=20 >>> username "anonymous" and a password of your e-mail address. After=20 >>> logging in, type "cd internet-drafts" and then "get=20 >>> draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> A list of Internet-Drafts directories can be found in=20 >>> http://www.ietf.org/shadow.html or=20 >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE >>> /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in=20 >>> MIME-encoded form by using the "mpack" utility. To use this=20 >>> feature, >=20 >>> insert the command "ENCODING mime" before the "FILE" command. To=20 >>> decode the response(s), you will need "munpack" or a MIME-compliant=20 >>> mail reader. Different MIME-compliant mail readers exhibit=20 >>> different >=20 >>> behavior, especially when dealing with "multipart" MIME messages=20 >>> (i.e. documents which have been split up into multiple messages), so >>> check your local documentation on how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader=20 >>> implementation to automatically retrieve the ASCII version of the=20 >>> Internet-Draft. _______________________________________________ >>> 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 >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 14:02:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htoyu-0000et-LX; Thu, 31 May 2007 14:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htoys-0000ek-MY for mip6@ietf.org; Thu, 31 May 2007 14:02:38 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htoyr-0001xB-DD for mip6@ietf.org; Thu, 31 May 2007 14:02:38 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4VI1S329856; Thu, 31 May 2007 18:01:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Thu, 31 May 2007 13:02:29 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A144F3@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejqPj1N0fHng+cEdyx6wARJNUNiAAAaTuQ References: <465EFD4B.6010802@hp.com> From: "Ahmad Muhanna" To: "Basavaraj Patil" , "ext Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, Please see comments inline. Regards, Ahmad =20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 >=20 >=20 >=20 > On 5/31/07 11:52 AM, "ext Brian Haley" wrote: >=20 > > Brian Haley wrote: > >>> IMO, the draft-haley is intended for sending a generic=20 > notification > >>> (fyi) messages, where detailed receiver action is not=20 > required and=20 > >>> does not need to be specified. The common use cases=20 > include, expiry=20 > >>> of prepaid billing, service outage related notifications, new=20 > >>> promotional information. > >>=20 > >> The generic notification message is a delivery mechanism, the=20 > >> receiver action for the opaque data within is up to that draft to=20 > >> define. In Mobile IPv4, the generic notification message > >> (draft-ietf-mip4-generic-notification-message-00.txt) does mention=20 > >> binding revocation. > >=20 > > Correction. It was pointed out to me that RFC 3543 is for Mip4=20 > > registration revocation. So maybe that set a precedence to do this=20 > > separately? >=20 > Learning from experience of MIP4 is good.... But does not=20 > imply that we have to solve the issues in exactly the same way. > The binding revocation capability in MIP6 is required. The=20 > solution for this can be fairly simple. I don't know what=20 > numerous suboptions are being refered to as the reasoning for=20 > having a separate message. [Ahmad] In the case of MIPv6, we could have the following scenarios: 1. Revoking a single session based on the NAI and/or HoA. 2. Revoking all MN sessions based on NAI, alone for example. 3. Revoking more than one sessions by including more than one HoA or a Home Network Prefix. 4. A very possible need for the Identification of what type of IPv6 mobility session we are revoking. 5. Probably a special handling is necessary in revoking a MN session during the transition scenario, i.e. moving from MIPv6 to PMIPv6. I also believe that more options are needed to address scenarios that are related to PMIPv6 and inter-MAG handoff scenarios. >=20 > -Raj >=20 > >=20 > > -Brian > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 14:27:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtpMt-00079t-FF; Thu, 31 May 2007 14:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtpMr-00079m-QP for mip6@ietf.org; Thu, 31 May 2007 14:27:25 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtpMq-0002BM-EF for mip6@ietf.org; Thu, 31 May 2007 14:27:25 -0400 Received: from smtp2.fc.hp.com (smtp2.fc.hp.com [15.11.136.114]) by atlrel6.hp.com (Postfix) with ESMTP id BD29634736; Thu, 31 May 2007 14:27:21 -0400 (EDT) Received: from [16.116.112.53] (wrx.zko.hp.com [16.116.112.53]) by smtp2.fc.hp.com (Postfix) with ESMTP id CA87218954A; Thu, 31 May 2007 18:27:20 +0000 (UTC) Message-ID: <465F1388.5000109@hp.com> Date: Thu, 31 May 2007 14:27:20 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt References: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711495AB8A@zrc2hxm2.corp.nortel.com> <465EF0A7.4040907@hp.com> <465EFD4B.6010802@hp.com> <6FC4416DDE56C44DA0AEE67BC7CA437114A1445C@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114A1445C@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ahmad, Comments inline. Ahmad Muhanna wrote: >> Correction. It was pointed out to me that RFC 3543 is for >> Mip4 registration revocation. So maybe that set a precedence >> to do this separately? > > [Ahmad] > I agree. > > IMO, revocation mechanism is more of a control mechanism than > informational. It is similar to the registration messages since it > impacts the state of the MN binding and the allocated resources. Having > said that, I believe we probably have a couple of options here: > > Option 1: > Is to have the revocation messages stands out as a separate MH type > messages. This is similar to what Mobile IPv4 has in RFC3543 and > detailed in the Binding Revocation for IPv6 Mobility draft. > > -OR- > > Option 2: > Since the MH generic message type allows only for options to be defined > (in separate drafts) and including all the revocation related > information would not be possible in a single option (unless it becomes > a message), then a subtype (as the first byte after the MH) can be used > to define the type of message that is included in the generic > notification message. I don't follow you here. Your Binding Revocation Indication Message is very similar to the Signaling Request Message in draft-haley, having a Revoke sub-option (with some flags) doesn't seem like it's that different. The one thing that would be different is if you're sending multiple sub-options containing revocation information - they might be considered at different "levels" in each draft: Generic Notification Message Revocation option Session revocation option #1 Session revocation option #2 Revocation Indication Message Session revocation option #1 Session revocation option #2 So in the top case, how do you associate the Session options with the Revocation option, they're all just options, right? You'd just have to have very specific processing rules (like we do for Binding Cache Information Options in the ha-reliability draft). I can understand this problem, since as you define more options it could get difficult - is this the main reason you want a new message? I'm just trying to understand your reasoning here. Thanks, -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 16:07:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htqv8-00016y-JZ; Thu, 31 May 2007 16:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htqv6-00016t-M8 for mip6@ietf.org; Thu, 31 May 2007 16:06:52 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htqv3-0008Dj-S8 for mip6@ietf.org; Thu, 31 May 2007 16:06:52 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4VK6itJ009493; Thu, 31 May 2007 23:06:47 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 23:06:45 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 15:06:41 -0500 Received: from 10.241.58.122 ([10.241.58.122]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 May 2007 20:06:41 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 31 May 2007 15:06:43 -0500 Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt From: Basavaraj Patil To: "Chowdhury, Kuntal" , ext Ahmad Muhanna , Message-ID: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcefBjF6PDbVk4yIQouQBdhGOf5ixAAAEJnwAPYNp+sACIZQUAACN7JpACJEfuAACyAulg== In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA0CF$0001@exchtewks2.starentnetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 May 2007 20:06:41.0791 (UTC) FILETIME=[347B10F0:01C7A3BF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Kuntal, On 5/31/07 10:00 AM, "ext Chowdhury, Kuntal" wrote: > Hi Raj, > > The revocation procedure that we proposed can be defined using the > mh-signaling message framework. In order to do that, we have to embed > the revocation message as a sub-type (or something like that) of the > Mobility Header type. Why would you need to embed the revocation message? Why can't it be simply a notification indicating that the binding for the MS is being revoked? > > Embedding a message within another message is not a clean design, IMHO. Sure.. I don't think we want to embed any message in the generic MH signaling message. I think you can solve the binding revocation via notification just as well. -Raj > I think the scope of the two documents should be left as is: > > Mh-signaling message: sending opaque TLVs > Revocation message: revoke mobility binding > > -Kuntal > > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Wednesday, May 30, 2007 5:27 PM >> To: Chowdhury, Kuntal; ext Ahmad Muhanna; mip6@ietf.org >> Subject: Re: [Mip6] FW: I-D > ACTION:draft-muhanna-mip6-binding-revocation- >> 00.txt >> >> >> Hi Kuntal, >> >> I agree that the mh-signaling draft is generic. But my point is that > we >> could utilize such a generic signaling mechanism as the means to solve >> some >> of the issues such as binding revocation in addition to the examples > that >> the I-D provides from an applicability perspective. >> I guess the argument here is that binding revocation is special type > of >> signaling that needs to be specified in new messages and cannot be >> addressed >> by the mh-signaling draft. >> This is the point that I am not convinced about. >> >> If we have good arguments that the generic signaling mechanism is >> inadequate, we can specify binding revocation separately. I guess one >> argument is the fact that no ack is required as per the mh-signaling > I-D. >> >> Some example scenarios why the mh-signaling message is not apt for > binding >> revocations would help. >> >> -Raj >> >> >> On 5/30/07 4:40 PM, "ext Chowdhury, Kuntal" >> >> wrote: >> >>> Hi Raj, >>> >>> I think the confusion is regarding the scope of the two documents. >>> >>> I think the scope of I-D: mh-signaling is quite generic with many > uses >>> cases as described in that document. Besides the uses cases that are >>> described in that document there may be other use cases that are >>> deployment specific. That's why I would consider this document to > have a >>> generic scope with opaque container to accommodate many uses cases. > No >>> response from the receiver is mandated in this mechanism. >>> >>> The scope of I-D: binding-revocation is very specific i.e. revoke > the >>> mobility binding with the MN, HA, (and MAG, LMA). The use cases for > this >>> mechanism are specific as well. A response from the receiver is > mandated >>> in some cases in this mechanism. >>> >>> So, I think we should agree on the scope of these two documents and >>> progress both of them through the IETF process. >>> >>> BR, >>> Kuntal >>> >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Wednesday, May 30, 2007 12:19 PM >>>> To: ext Ahmad Muhanna; mip6@ietf.org >>>> Subject: Re: [Mip6] FW: I-D >>> ACTION:draft-muhanna-mip6-binding-revocation- >>>> 00.txt >>>> >>>> >>>> Ahmad, >>>> >>>> Binding revocation is a useful feature. >>>> However, we have a I-D: Mobility Header Signaling Message >>>> which can be used as the > means >>> for >>>> binding revocation as well. >>>> >>>> In Prague, we discussed this I-D and agreed to consider it as a WG >>>> document. >>>> >>>> -Raj >>>> >>>> >>>> On 5/28/07 7:43 AM, "ext Ahmad Muhanna" > wrote: >>>> >>>>> >>>>> Hello Folks, >>>>> >>>>> We submitted this draft for Binding Revocation for IPv6 Mobility. > It >>>>> handles several use cases which are applicable to Client Mobile > IPv6 >>> and >>>>> PMIPv6. Please take a look and we appreciate your comments. >>>>> >>>>> Thanks in advance. >>>>> >>>>> Regards, >>>>> Ahmad Muhanna >>>>> >>>>> -----Original Message----- >>>>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>>> Sent: Friday, May 25, 2007 2:50 PM >>>>> To: i-d-announce@ietf.org >>>>> Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : Binding Revocation for IPv6 Mobility >>>>> Author(s) : A. Muhanna, et al. >>>>> Filename : draft-muhanna-mip6-binding-revocation-00.txt >>>>> Pages : 18 >>>>> Date : 2007-5-25 >>>>> >>>>> The service binding revocation semantics are missing in Mobile >>> IPv6 >>>>> Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC]. This document >>>>> defines the semantics of the revocation of a mobile node >>> registration >>>>> binding, which could have been established using a Client > Mobile >>> IPv6 >>>>> or a Proxy Mobile IPv6 signaling. The proposed revocation >>> mechanism >>>>> uses generic message properties which is applicable to Mobile >>> IPv6 >>>>> and Proxy Mobile IPv6 and can be used by any two mobility >>> entities. >>>>> As an example, this mechanism allows local mobility agent, >>> involved >>>>> in providing IP mobility services to a mobile node, to notify > the >>>>> mobility access gateway of the termination of the mobile node >>>>> registration. >>>>> >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>> >>> > http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio >>>>> n-00.txt >>>>> >>>>> To remove yourself from the I-D Announcement list, send a message > to >>>>> i-d-announce-request@ietf.org with the word unsubscribe in the > body >>> of >>>>> the message. >>>>> You can also visit >>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>> to change your subscription settings. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP. Login with > the >>>>> username "anonymous" and a password of your e-mail address. After >>>>> logging in, type "cd internet-drafts" and then >>>>> "get draft-muhanna-mip6-binding-revocation-00.txt". >>>>> >>>>> A list of Internet-Drafts directories can be found in >>>>> http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> Internet-Drafts can also be obtained by e-mail. >>>>> >>>>> Send a message to: >>>>> mailserv@ietf.org. >>>>> In the body type: >>>>> "FILE >>>>> /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt". >>>>> >>>>> NOTE: The mail server at ietf.org can return the document in >>>>> MIME-encoded form by using the "mpack" utility. To use this >>>>> feature, insert the command "ENCODING mime" before the "FILE" >>>>> command. To decode the response(s), you will need "munpack" or >>>>> a MIME-compliant mail reader. Different MIME-compliant mail >>>>> readers >>>>> exhibit different behavior, especially when dealing with >>>>> "multipart" MIME messages (i.e. documents which have been split >>>>> up into multiple messages), so check your local documentation on >>>>> how to manipulate these messages. >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet-Draft. >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> "This email message and any attachments are confidential information > of >>> Starent Networks, Corp. The information transmitted may not be used > to >> create >>> or change any contractual obligations of Starent Networks, Corp. > Any >> review, >>> retransmission, dissemination or other use of, or taking of any > action >> in >>> reliance upon this e-mail and its attachments by persons or entities >> other >>> than the intended recipient is prohibited. If you are not the > intended >>> recipient, please notify the sender immediately -- by replying to > this >> message >>> or by sending an email to postmaster@starentnetworks.com -- and > destroy >> all >>> copies of this message and any attachments without reading or > disclosing >> their >>> contents. Thank you." > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 16:17:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htr4f-0007Qc-Er; Thu, 31 May 2007 16:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htr4e-0007PC-Dk for mip6@ietf.org; Thu, 31 May 2007 16:16:44 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htr4d-0001I5-Sy for mip6@ietf.org; Thu, 31 May 2007 16:16:44 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4VKGR1i014590; Thu, 31 May 2007 23:16:42 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 23:16:40 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 15:16:38 -0500 Received: from 10.241.58.122 ([10.241.58.122]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 May 2007 20:16:38 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 31 May 2007 15:16:32 -0500 Subject: Re: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt From: Basavaraj Patil To: ext Ahmad Muhanna , ext Brian Haley Message-ID: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejqPj1N0fHng+cEdyx6wARJNUNiAAAaTuQAAV9mbc= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114A144F3@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 May 2007 20:16:38.0756 (UTC) FILETIME=[984CB240:01C7A3C0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ahmad, Inline: On 5/31/07 1:02 PM, "ext Ahmad Muhanna" wrote: > Hi Raj, > > Please see comments inline. > > Regards, > Ahmad > > >> ACTION:draft-muhanna-mip6-binding-revocation-00.txt >> >> >> >> >> On 5/31/07 11:52 AM, "ext Brian Haley" wrote: >> >>> Brian Haley wrote: >>>>> IMO, the draft-haley is intended for sending a generic >> notification >>>>> (fyi) messages, where detailed receiver action is not >> required and >>>>> does not need to be specified. The common use cases >> include, expiry >>>>> of prepaid billing, service outage related notifications, new >>>>> promotional information. >>>> >>>> The generic notification message is a delivery mechanism, the >>>> receiver action for the opaque data within is up to that draft to >>>> define. In Mobile IPv4, the generic notification message >>>> (draft-ietf-mip4-generic-notification-message-00.txt) does mention >>>> binding revocation. >>> >>> Correction. It was pointed out to me that RFC 3543 is for Mip4 >>> registration revocation. So maybe that set a precedence to do this >>> separately? >> >> Learning from experience of MIP4 is good.... But does not >> imply that we have to solve the issues in exactly the same way. >> The binding revocation capability in MIP6 is required. The >> solution for this can be fairly simple. I don't know what >> numerous suboptions are being refered to as the reasoning for >> having a separate message. > > [Ahmad] > > In the case of MIPv6, we could have the following scenarios: > 1. Revoking a single session based on the NAI and/or HoA. What do you mean by single session??? In the MIP6 case revoking the binding implies that you are deprecating the entry from the BCE for the MS. There is no session specific information. > 2. Revoking all MN sessions based on NAI, alone for example. Again, what do you mean by "all MN sessions"... Are you refering to the scenario of deprecating the binding for all MNs served by an HA? And even if that is case, why cant you accomplish the same via notifications sent to all affected MNs (or sessions in your terminology)? > 3. Revoking more than one sessions by including more than one HoA or a > Home Network Prefix. Any why is this a problem? I mean the binding in MIP6 is between an MN and HA. So if you were to revoke the binding for all MNs that use a certain prefix (for example), you have to send notifications to all those MNs. > 4. A very possible need for the Identification of what type of IPv6 > mobility session we are revoking. ??? Not sure I understand what you mean by "type of IPv6 mobility session". > 5. Probably a special handling is necessary in revoking a MN session > during the transition scenario, i.e. moving from MIPv6 to PMIPv6. Well.. This becomes a scoping of work issue. Netlmm is dealing with interactions of MIP6 and PMIP6. I am not sure if the MIP6 base protocol needs to start considering issues which IMO are not in scope here. Moreover transition from MIP6 to PMIP6 is a topic still in discussion in Netlmm and I don't think we can really solve the binding revocation issue without having a solution for such transition in place first. > > I also believe that more options are needed to address scenarios that > are related to PMIPv6 and inter-MAG handoff scenarios. Hmmm... I think if there is a need to do binding revocation between MAGs and LMAs, that should be discussed in the Netlmm WG. In fact I don't think the MIP6 work on binding revocation needs to be overloaded with PMIP6 semantics. -Raj > >> >> -Raj >> >>> >>> -Brian >>> >>> _______________________________________________ >>> 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 From mip6-bounces@ietf.org Thu May 31 19:34:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htu8i-0005LA-B2; Thu, 31 May 2007 19:33:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htu8h-0005L3-U1 for mip6@ietf.org; Thu, 31 May 2007 19:33:07 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htu8g-00077t-JA for mip6@ietf.org; Thu, 31 May 2007 19:33:07 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4VNX4N15983 for ; Thu, 31 May 2007 23:33:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Thu, 31 May 2007 18:33:00 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A14D57@zrc2hxm2.corp.nortel.com> In-Reply-To: <465F1388.5000109@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnw References: <6FC4416DDE56C44DA0AEE67BC7CA43711486145C@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711495AB8A@zrc2hxm2.corp.nortel.com> <465EF0A7.4040907@hp.com> <465EFD4B.6010802@hp.com> <6FC4416DDE56C44DA0AEE67BC7CA437114A1445C@zrc2hxm2.corp.nortel.com> <465F1388.5000109@hp.com> From: "Ahmad Muhanna" To: "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, Please allow me to bring the discussion back to the basic functionality of binding revocation. Probably, that would help in realizing the difference between the two mechanism and what each one is trying to achieve. Although, we arguably can say that both protocols functionalities is about notifying the MN with an event, however, there is a difference between the two. In the case of Binding Revocation mechanism, the decision has been made for administrative or other reasons to immediately revoke, i.e. delete, the MN BCE. The HA possibly already executed the revocation order, BUT need to notify the MN with the new state of its BCE. This is clearly different than the nature of the informational signaling protocol introduced by the generic notification messages which may notify the MN with an event that eventually may cause the MN BCE to be deleted if the MN does not react according to the agreement with the home domain, e.g. pre-paid balance is going below $3.00, or HA is scheduled for maintenance after 2 hours. In order for the MN to avoid service termination, MN may refill its pre-paid account and later sends a BU to renew its BCE lifetime. In other words, Binding revocation involves an immediate movement/change of the control plane and impacts the MN BCE state which is very similar to Registration Signaling Control messages, i.e. BU/BA. One cause BCE to be created and one cause it to be deleted. The scope of the generic notification messages, as per the draft text, is to send opaque data with an Informational nature by introducing a new encapsulating header (generic notification message), if I may call it that, inside the Mobility Header itself to be used for communicating some generic information (fyi) to the MN.=20 Finally, I would like to make sure that we agree that PMIPv6, although, it is described under Netlmm wg, is very relevant to this wg and considered as an extension to the MIPv6 protocol. Not only that, but the same MN BCE may change from MIPv6 state to PMIPv6 and again to MIPv6 state where the change of the same BCE may require at one point a revocation message according to PMIPv6 and another according to MIPv6. If that the extent of the interaction between the MIPv6 and PMIPv6, we should design a revocation signaling mechanism that can be used in both cases to revoke different states of the same BCE. Let me explain a scenario here: 1. Let us assume that a MN is visiting Access1 and its session registered with its HA1 using MIPv6. BCE Flag=3DMIPv6. 2. MN moves to Access2, where PMIPv6 is deployed and MAG1 send a PBU to modify the MN BCE @ HA1. BCE Flag=3DPMIPv6. 3. Let us assume the MN moves within Access2 from MAG1 to MAG2 which triggers the LMA/HA1 to send a Revocation message to MAG1 in order for MAG1 to clean resources associated with the MN; Here, BRI1 revokes a PMIPv6 BCE. 4. Let us assume that the MN moved to Access 3, where PMIPv6 is not deployed and MN used MIPv6 for global mobility with the same HA1. BCE Flag=3D MIPv6. 5. If the home domain decides to revoke the MN BCE, the HA1 sends a BRI2. Here, BRI2 revokes a MIPv6 BCE. One last thing, Do you see a problem by using a separate MH types for revocation messages to define one revocation mechanism/messages which is applicable to MIPv6 and PMIPv6? Thanks in advance. Regards, Ahmad > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com]=20 > Sent: Thursday, May 31, 2007 1:27 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mip6@ietf.org > Subject: Re: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 > Hi Ahmad, >=20 > Comments inline. >=20 > Ahmad Muhanna wrote: > >> Correction. It was pointed out to me that RFC 3543 is for > >> Mip4 registration revocation. So maybe that set a=20 > precedence to do=20 > >> this separately? > >=20 > > [Ahmad] > > I agree.=20 > >=20 > > IMO, revocation mechanism is more of a control mechanism than=20 > > informational. It is similar to the registration messages since it=20 > > impacts the state of the MN binding and the allocated resources.=20 > > Having said that, I believe we probably have a couple of=20 > options here: > >=20 > > Option 1: > > Is to have the revocation messages stands out as a separate MH type=20 > > messages. This is similar to what Mobile IPv4 has in RFC3543 and=20 > > detailed in the Binding Revocation for IPv6 Mobility draft. > >=20 > > -OR- > >=20 > > Option 2: > > Since the MH generic message type allows only for options to be=20 > > defined (in separate drafts) and including all the=20 > revocation related=20 > > information would not be possible in a single option (unless it=20 > > becomes a message), then a subtype (as the first byte after the MH)=20 > > can be used to define the type of message that is included in the=20 > > generic notification message. >=20 > I don't follow you here. Your Binding Revocation Indication=20 > Message is very similar to the Signaling Request Message in=20 > draft-haley, having a Revoke sub-option (with some flags)=20 > doesn't seem like it's that different. >=20 > The one thing that would be different is if you're sending=20 > multiple sub-options containing revocation information - they=20 > might be considered at different "levels" in each draft: >=20 > Generic Notification Message > Revocation option > Session revocation option #1 > Session revocation option #2 >=20 > Revocation Indication Message > Session revocation option #1 > Session revocation option #2 >=20 > So in the top case, how do you associate the Session options=20 > with the Revocation option, they're all just options, right? =20 > You'd just have to have very specific processing rules (like=20 > we do for Binding Cache Information Options in the=20 > ha-reliability draft). I can understand this problem, since=20 > as you define more options it could get difficult - is this=20 > the main reason you want a new message? >=20 > I'm just trying to understand your reasoning here. >=20 > Thanks, >=20 > -Brian >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 19:36:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtuAl-0005dI-Rq; Thu, 31 May 2007 19:35:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtuAk-0005dD-Ch for mip6@ietf.org; Thu, 31 May 2007 19:35:14 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtuAk-0007J5-1T for mip6@ietf.org; Thu, 31 May 2007 19:35:14 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4VNZBw09498 for ; Thu, 31 May 2007 23:35:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Thu, 31 May 2007 18:35:07 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437114A14D5B@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710F50062A@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAVD3hA= References: <465F1388.5000109@hp.com> <6FC4416DDE56C44DA0AEE67BC7CA43710F50062A@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, Correction... Meant to say: "Probably, that would help *US* in realizing the difference....." Regards, Ahmad =20 > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10)=20 > Sent: Thursday, May 31, 2007 6:33 PM > To: 'Brian Haley' > Cc: 'mip6@ietf.org' > Subject: RE: [Mip6] FW: I-D=20 > ACTION:draft-muhanna-mip6-binding-revocation-00.txt >=20 > Hi Brian, >=20 > Please allow me to bring the discussion back to the basic=20 > functionality of binding revocation. Probably, that would=20 > help in realizing the difference between the two mechanism=20 > and what each one is trying to achieve. >=20 > Although, we arguably can say that both protocols=20 > functionalities is about notifying the MN with an event,=20 > however, there is a difference between the two. In the case=20 > of Binding Revocation mechanism, the decision has been made=20 > for administrative or other reasons to immediately revoke,=20 > i.e. delete, the MN BCE. The HA possibly already executed the=20 > revocation order, BUT need to notify the MN with the new=20 > state of its BCE. This is clearly different than the nature=20 > of the informational signaling protocol introduced by the=20 > generic notification messages which may notify the MN with an=20 > event that eventually may cause the MN BCE to be deleted if=20 > the MN does not react according to the agreement with the=20 > home domain, e.g. pre-paid balance is going below $3.00, or=20 > HA is scheduled for maintenance after 2 hours. In order for=20 > the MN to avoid service termination, MN may refill its=20 > pre-paid account and later sends a BU to renew its BCE lifetime. >=20 > In other words, Binding revocation involves an immediate=20 > movement/change of the control plane and impacts the MN BCE=20 > state which is very similar to Registration Signaling Control=20 > messages, i.e. BU/BA. One cause BCE to be created and one=20 > cause it to be deleted. >=20 > The scope of the generic notification messages, as per the=20 > draft text, is to send opaque data with an Informational=20 > nature by introducing a new encapsulating header (generic=20 > notification message), if I may call it that, inside the=20 > Mobility Header itself to be used for communicating some=20 > generic information (fyi) to the MN.=20 >=20 > Finally, I would like to make sure that we agree that PMIPv6,=20 > although, it is described under Netlmm wg, is very relevant=20 > to this wg and considered as an extension to the MIPv6=20 > protocol. Not only that, but the same MN BCE may change from=20 > MIPv6 state to PMIPv6 and again to MIPv6 state where the=20 > change of the same BCE may require at one point a revocation=20 > message according to PMIPv6 and another according to MIPv6.=20 > If that the extent of the interaction between the MIPv6 and=20 > PMIPv6, we should design a revocation signaling mechanism=20 > that can be used in both cases to revoke different states of=20 > the same BCE. Let me explain a scenario here: >=20 > 1. Let us assume that a MN is visiting Access1 and its=20 > session registered with its HA1 using MIPv6. BCE Flag=3DMIPv6. > 2. MN moves to Access2, where PMIPv6 is deployed and MAG1=20 > send a PBU to modify the MN BCE @ HA1. BCE Flag=3DPMIPv6. > 3. Let us assume the MN moves within Access2 from MAG1 to=20 > MAG2 which triggers the LMA/HA1 to send a Revocation message=20 > to MAG1 in order for MAG1 to clean resources associated with=20 > the MN; Here, BRI1 revokes a PMIPv6 BCE. > 4. Let us assume that the MN moved to Access 3, where PMIPv6=20 > is not deployed and MN used MIPv6 for global mobility with=20 > the same HA1. BCE Flag=3D MIPv6. > 5. If the home domain decides to revoke the MN BCE, the HA1=20 > sends a BRI2. Here, BRI2 revokes a MIPv6 BCE. >=20 > One last thing, Do you see a problem by using a separate MH=20 > types for revocation messages to define one revocation=20 > mechanism/messages which is applicable to MIPv6 and PMIPv6? >=20 > Thanks in advance. >=20 > Regards, > Ahmad >=20 > > -----Original Message----- > > From: Brian Haley [mailto:brian.haley@hp.com] > > Sent: Thursday, May 31, 2007 1:27 PM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] FW: I-D > > ACTION:draft-muhanna-mip6-binding-revocation-00.txt > >=20 > > Hi Ahmad, > >=20 > > Comments inline. > >=20 > > Ahmad Muhanna wrote: > > >> Correction. It was pointed out to me that RFC 3543 is for > > >> Mip4 registration revocation. So maybe that set a > > precedence to do > > >> this separately? > > >=20 > > > [Ahmad] > > > I agree.=20 > > >=20 > > > IMO, revocation mechanism is more of a control mechanism than=20 > > > informational. It is similar to the registration messages=20 > since it=20 > > > impacts the state of the MN binding and the allocated resources. > > > Having said that, I believe we probably have a couple of > > options here: > > >=20 > > > Option 1: > > > Is to have the revocation messages stands out as a=20 > separate MH type=20 > > > messages. This is similar to what Mobile IPv4 has in RFC3543 and=20 > > > detailed in the Binding Revocation for IPv6 Mobility draft. > > >=20 > > > -OR- > > >=20 > > > Option 2: > > > Since the MH generic message type allows only for options to be=20 > > > defined (in separate drafts) and including all the > > revocation related > > > information would not be possible in a single option (unless it=20 > > > becomes a message), then a subtype (as the first byte=20 > after the MH)=20 > > > can be used to define the type of message that is included in the=20 > > > generic notification message. > >=20 > > I don't follow you here. Your Binding Revocation=20 > Indication Message=20 > > is very similar to the Signaling Request Message in draft-haley,=20 > > having a Revoke sub-option (with some flags) doesn't seem like it's=20 > > that different. > >=20 > > The one thing that would be different is if you're sending multiple=20 > > sub-options containing revocation information - they might be=20 > > considered at different "levels" in each draft: > >=20 > > Generic Notification Message > > Revocation option > > Session revocation option #1 > > Session revocation option #2 > >=20 > > Revocation Indication Message > > Session revocation option #1 > > Session revocation option #2 > >=20 > > So in the top case, how do you associate the Session=20 > options with the=20 > > Revocation option, they're all just options, right? > > You'd just have to have very specific processing rules=20 > (like we do for=20 > > Binding Cache Information Options in the ha-reliability=20 > draft). I can=20 > > understand this problem, since as you define more options=20 > it could get=20 > > difficult - is this the main reason you want a new message? > >=20 > > I'm just trying to understand your reasoning here. > >=20 > > Thanks, > >=20 > > -Brian > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu May 31 22:41:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htx3i-0007P0-Kg; Thu, 31 May 2007 22:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htx3h-0007Ov-Jd for mip6@ietf.org; Thu, 31 May 2007 22:40:09 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htx3f-00042X-Ol for mip6@ietf.org; Thu, 31 May 2007 22:40:09 -0400 Received: from oaamta01sl.mx.bigpond.com ([124.191.178.123]) by omta01sl.mx.bigpond.com with ESMTP id <20070601024004.WSNA14178.omta01sl.mx.bigpond.com@oaamta01sl.mx.bigpond.com>; Fri, 1 Jun 2007 02:40:04 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta01sl.mx.bigpond.com with ESMTP id <20070601024004.QMMD5805.oaamta01sl.mx.bigpond.com@PC20005>; Fri, 1 Jun 2007 02:40:04 +0000 From: "Hesham Soliman" To: "'Ahmad Muhanna'" , "'Brian Haley'" Subject: RE: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt Date: Fri, 1 Jun 2007 12:39:58 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437114A14D57@zrc2hxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcejsVbfS40lMgyLQl23peLZkTLpugAFaWnwAAugWzA= Message-Id: <20070601024004.QMMD5805.oaamta01sl.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ahmad, > Please allow me to bring the discussion back to the basic > functionality > of binding revocation. Probably, that would help in realizing the > difference between the two mechanism and what each one is trying to > achieve. > > Although, we arguably can say that both protocols functionalities is > about notifying the MN with an event, however, there is a difference > between the two. In the case of Binding Revocation mechanism, the > decision has been made for administrative or other reasons to > immediately revoke, i.e. delete, the MN BCE. The HA possibly already > executed the revocation order, BUT need to notify the MN with the new > state of its BCE. This is clearly different than the nature of the > informational signaling protocol introduced by the generic > notification > messages which may notify the MN with an event that > eventually may cause > the MN BCE to be deleted if the MN does not react according to the > agreement with the home domain, e.g. pre-paid balance is going below > $3.00, or HA is scheduled for maintenance after 2 hours. In order for > the MN to avoid service termination, MN may refill its > pre-paid account > and later sends a BU to renew its BCE lifetime. => I don't think it's impossible to reconcile those different cases in the same message. The notification message can indicate all sorts of information to the MN like "binding deleted", "about ot be deleted" ...etc. > > In other words, Binding revocation involves an immediate > movement/change > of the control plane and impacts the MN BCE state which is > very similar > to Registration Signaling Control messages, i.e. BU/BA. One > cause BCE to > be created and one cause it to be deleted. > > The scope of the generic notification messages, as per the > draft text, > is to send opaque data with an Informational nature by > introducing a new > encapsulating header (generic notification message), if I may call it > that, inside the Mobility Header itself to be used for communicating > some generic information (fyi) to the MN. => So are you suggesting that the information in draft-haley should not be opaque? Opaque is a strange word anyway when the information is sent to the ultimate receiver of the message. If that's the suggestion then I think it's doable. > > 1. Let us assume that a MN is visiting Access1 and its session > registered with its HA1 using MIPv6. BCE Flag=MIPv6. > 2. MN moves to Access2, where PMIPv6 is deployed and MAG1 > send a PBU to > modify the MN BCE @ HA1. BCE Flag=PMIPv6. > 3. Let us assume the MN moves within Access2 from MAG1 to MAG2 which > triggers the LMA/HA1 to send a Revocation message to MAG1 in > order for > MAG1 to clean resources associated with the MN; Here, BRI1 revokes a > PMIPv6 BCE. > 4. Let us assume that the MN moved to Access 3, where PMIPv6 is not > deployed and MN used MIPv6 for global mobility with the same HA1. BCE > Flag= MIPv6. > 5. If the home domain decides to revoke the MN BCE, the HA1 sends a > BRI2. Here, BRI2 revokes a MIPv6 BCE. => That's fine but you didn't explain why this is not doable in draft-haley? You can simply define a message to be carried in his notification header, what's wrong with that? Hesham > > One last thing, Do you see a problem by using a separate MH types for > revocation messages to define one revocation > mechanism/messages which is > applicable to MIPv6 and PMIPv6? > > Thanks in advance. > > Regards, > Ahmad > > > -----Original Message----- > > From: Brian Haley [mailto:brian.haley@hp.com] > > Sent: Thursday, May 31, 2007 1:27 PM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] FW: I-D > > ACTION:draft-muhanna-mip6-binding-revocation-00.txt > > > > Hi Ahmad, > > > > Comments inline. > > > > Ahmad Muhanna wrote: > > >> Correction. It was pointed out to me that RFC 3543 is for > > >> Mip4 registration revocation. So maybe that set a > > precedence to do > > >> this separately? > > > > > > [Ahmad] > > > I agree. > > > > > > IMO, revocation mechanism is more of a control mechanism than > > > informational. It is similar to the registration > messages since it > > > impacts the state of the MN binding and the allocated resources. > > > Having said that, I believe we probably have a couple of > > options here: > > > > > > Option 1: > > > Is to have the revocation messages stands out as a > separate MH type > > > messages. This is similar to what Mobile IPv4 has in RFC3543 and > > > detailed in the Binding Revocation for IPv6 Mobility draft. > > > > > > -OR- > > > > > > Option 2: > > > Since the MH generic message type allows only for options to be > > > defined (in separate drafts) and including all the > > revocation related > > > information would not be possible in a single option (unless it > > > becomes a message), then a subtype (as the first byte > after the MH) > > > can be used to define the type of message that is > included in the > > > generic notification message. > > > > I don't follow you here. Your Binding Revocation Indication > > Message is very similar to the Signaling Request Message in > > draft-haley, having a Revoke sub-option (with some flags) > > doesn't seem like it's that different. > > > > The one thing that would be different is if you're sending > > multiple sub-options containing revocation information - they > > might be considered at different "levels" in each draft: > > > > Generic Notification Message > > Revocation option > > Session revocation option #1 > > Session revocation option #2 > > > > Revocation Indication Message > > Session revocation option #1 > > Session revocation option #2 > > > > So in the top case, how do you associate the Session options > > with the Revocation option, they're all just options, right? > > You'd just have to have very specific processing rules (like > > we do for Binding Cache Information Options in the > > ha-reliability draft). I can understand this problem, since > > as you define more options it could get difficult - is this > > the main reason you want a new message? > > > > I'm just trying to understand your reasoning here. > > > > Thanks, > > > > -Brian > > > > _______________________________________________ > 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